Hi Mike. In my case, I wrote the image with a Mac. I run FreeBSD inside virtualbox because I no longer have FreeBSD machines at home.
You may have multiple cards with the same problem. More comments below. On 1/26/11 1:31 PM, Mike Tancsa wrote: > On 1/26/2011 3:45 PM, Robert Sexton wrote: >> I just ran into something similar with 4G cards, where the nanobsd >> numbers for 4G sandisk cards were wrong. >> >> It looks like in these most recent cards, Sandisk has reserved more >> flash for wear leveling and spare sectors, >> so a 4G nanobsd image won't fit onto a 4G card. I used the numbers from >> fdisk to calculate the new device size, and used that in my nanobsd >> script, and all was well. You're getting errors at the 3.9G boundary. >> You may be running off the end of the device. > Hmmm, even if I make the media size just 2G, I still get the errors. How > are you burning the image onto the CF ? What values did you use to > create the image ? Or is it CF reader dependent ? > > >> On 1/24/11 6:41 PM, Mike Tancsa wrote: >>> On the latest SANDisk batch of CFs I got, I am getting periodic errors >>> reading from the flash on my 5501 (FreeBSD RELENG_8). However, when I >>> put the flash in different readers-- e.g. attached to a regular >>> server, no errors. On the 5501 I get periodic >>> >>> ad0: FAILURE - READ_DMA status=51<READY,DSC,ERROR> >>> error=10<NID_NOT_FOUND> LBA=7813103 >>> <SNIP> >>> the 2G flashes work just fine in the same box. The only difference I >>> can see between the 2G and 4G CF is that that atacontrol says "lba48 >>> supported".... Could this be the issue ? If so, is there a way to turn >>> it off or work around it ? My supplier is not carrying 2G anymore and >>> the 4 is the same price as the 2G :( >>> >>> >>> >>> Protocol ATA/ATAPI revision 0 >>> device model SanDisk SDCFH-004G >>> serial number ACZ120910191749 >>> firmware revision HDX 6.02 >>> cylinders 7751 >>> heads 16 >>> sectors/track 63 >>> CFA supported >>> lba supported 7813120 sectors >>> lba48 supported 7813120 sectors >>> dma supported >>> overlap not supported 7751 * 16 * 63 = 7813008, so the system is reporting a sector count thats larger than that calculated from C/H/S. If anything in the filesystem refers to these blocks, interesting things will happen. I'd try 7750/16/63, or 7812000 - Robert _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
