Re: [freebsd-current] re: fsck_4.2bsd: cannot alloc 4294967292

On Fri, Apr 04, 2008 at 12:45:06AM -0400, Tuc at T-B-O-H.NET wrote:
> > On Thu, Apr 03, 2008 at 08:51:53AM -0400, Tuc at T-B-O-H.NET wrote:
> > >not the drive... As soon as I mount the drive and try to create
> > >filesystems on it I get a kernel panic
> > >(http://www.freebsd.org/cgi/query-pr.cgi?pr=3D122380)
> > >
> > >	I even brought a 7.0 system up elsewhere, formatted it there,
> > >and mounted it on the Soekris system, and as soon as I start to use
> > >it it panics.
> > 
> > This sounds very much like data corruption between the flash and the
> > filesystem layer.
> > 
> > How does the flash connect to valhalla?  USB or card slot or ...?
> > Can you provide a verbose dmesg of da0 and all its parents?
> >
> 	USB
> 
> 	At the risk of cutting/pasting too little....
> 
> 	http://204.107.90.128/dmesg.txt 
> >
> > Try dd'ing off the first 1MB or so using valhalla and also using one
> > of your other systems and compare the results.  My suspicion is that
> > there is either an off-by-1-sector or similar error or you will find
> > valhalla is reading chunks of 0xff bytes where it shouldn't.
> > 
> setup# 
> MD5 (1Mcu) = f6886afdcdb7dcc6205d4e29649fbdb7
> MD5 (1Mdu) = f6886afdcdb7dcc6205d4e29649fbdb7
> 
> valhalla# md5 1M*
> MD5 (1Mcu) = f6886afdcdb7dcc6205d4e29649fbdb7
> MD5 (1Mdu) = f6886afdcdb7dcc6205d4e29649fbdb7
> 
> 	These were both with the disk unmounted. "cu" is partition
> da0s1c, and "du" is partition da0s1d (Which is the partition I use
> to mount)
> 
> valhalla# disklabel /dev/da0s1
> # /dev/da0s1:
> 8 partitions:
> #        size   offset    fstype   [fsize bsize bps/cpg]
>   c:  8048502        0    unused        0     0         # "raw" part, don't edit
>   d:  8048502        0    4.2BSD     2048 16384 28552
> 
> 	Looks like matches all around. (And yes, I SHA256'd too)
> 
> 	:-/ So now where?

Did you use a block size argument to "dd"?  If so, what was it?

I'm wondering if the USB stick goes wonky with lots of small (512 byte)
reads instead of lots of big reads which is what might have happened
with dd.  

There could also be some weird interaction with mixed reads and
writes, but I have no ideas on how to test that