"cg 0: bad magic number" with umass

[Marius Strobl]

On Fri, Jul 17, 2009 at 09:59:38AM +0200, Hans Petter Selasky wrote:
> On Tuesday 30 June 2009 19:57:28 Ari Sovijärvi wrote:
> > Hans Petter Selasky wrote:
> > > Could you show the dmesg of the USB controller? At which bus is it
> > > connected? Nexus? There might be bugs in the actual USB device/host
> > > hardware.
> >
> > Here's all I could find of the USB controller from the dmesg's output.
> >
> > ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem 0x1000000-0x1000fff
> > at device 10.0 on pci0
> > ohci0: [GIANT-LOCKED]
> > ohci0: [ITHREAD]
> > usb0: OHCI version 1.0, legacy support
> > usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
> > usb0: USB revision 1.0
> > uhub0: <AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
> > uhub0: 2 ports with 2 removable, self powered
> >
> > If you need to see anything else from the dmesg, here's the full output:
> > http://pastebin.ca/1479774
> >
> > The USB-enclosure I used was LaCie's "design by porsche" with 1 terabyte
> > Seagate disk.
> >
> > > Are you using 8-current ?
> >
> > No, 7.2.
> 
> Hi,
> 
> If you do a simple test on the disk:
> 
> dd if=/dev/urandom of=test.img bs=65536 count=16
> 
> cat test.img > /dev/daX
> 
> dd if=/dev/daX of=test_rb.img bs=65536 count=16
> 
> diff test.img test_rb.img
> 
> The only problem I can see is that there is something wrong with the cache 
> invalidate/flush instruction wrappers on the sparc.
> 

If you are refering to bus_dmamap_sync(9) that hardly can be
the cause as we don't take advantage of the streaming cache
of sparc64 IOMMUs so far as traditionally drivers used
bus_dmamap_sync(9) incorrectly if they did at all, let alone
the fact that this particular machine has no streaming cache.
I.e. currently the use of bus_dmamap_sync(9) actually is
unnecessary on sparc64, my plan is to enable the used of
the streaming caches some time after the freeze for 8.0
is over though.
I'd rather suspect this to either be one of the typical
!x86 LP64, alignment or endianness problems in usb(4) or
the firmware initializing the on-board Ali controller to
some non-(x86-)default values. The latter is something
that ata(4) is also struggeling with.

Marius