Date: Thu, 23 Jul 2009 20:30:34 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Ari =?unknown-8bit?Q?Sovij=E4rvi?= <listat@apz.fi>, freebsd-sparc64@freebsd.org Subject: Re: "cg 0: bad magic number" with umass Message-ID: <20090723183034.GA56079@alchemy.franken.de> In-Reply-To: <200907170959.39640.hselasky@c2i.net> References: <4A444374.3090008@apz.fi> <200906301037.40138.hselasky@c2i.net> <4A4A5208.9020307@apz.fi> <200907170959.39640.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090723183034.GA56079>