Date: Mon, 05 Apr 2004 17:45:00 +0200 From: Heinrich Rebehn <rebehn@ant.uni-bremen.de> To: ticso@cicely.de Cc: freebsd-questions@freebsd.org Subject: Re: Recommended USB 2.0 controller fr. 5.2+ Message-ID: <40717EFC.9040406@ant.uni-bremen.de> In-Reply-To: <20040405152144.GB81325@cicely12.cicely.de> References: <200403221348.52786.peter.schuller@infidyne.com> <200403221409.01443.peter.schuller@infidyne.com> <20040329113642.GF26269@cicely12.cicely.de> <407157F9.4080701@ant.uni-bremen.de> <20040405130526.GA81325@cicely12.cicely.de> <407176AC.3010604@ant.uni-bremen.de> <20040405152144.GB81325@cicely12.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote:
> On Mon, Apr 05, 2004 at 05:09:32PM +0200, Heinrich Rebehn wrote:
>
>>Bernd Walter wrote:
>>
>>>On Mon, Apr 05, 2004 at 02:58:33PM +0200, Heinrich Rebehn wrote:
>>>
>>>
>>>>i am using a NEC USB2 controller and am just about to give up on using
>>>>it. I don't know if it's the controller, the disk or the ehci driver.
>>>>However, man ehci(4) states that "The driver is not finished and is
>>>>quite buggy." This seems to be true. I get all sorts of trouble ranging
>>>
>>>>from hangs during boot to system crashes.
>>>
>>>>I am reverting back to USB1 although its terribly slow.
>>>>
>>>>FreeBSD 5.2.1-RELEASE-p3
>>>>
>>>>usb4: EHCI version 1.0
>>>>usb4: companion controllers, 2 ports each: usb2 usb3
>>>>usb4: <NEC uPD 720100 USB 2.0 controller> on ehci0
>>>>usb4: USB revision 2.0
>>>>uhub4: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
>>>>uhub4: 3 ports with 3 removable, self powered
>>>>
>>>>umass0: Maxtor OneTouch, rev 2.00/2.00, addr 2
>>>>umass0: Get Max Lun not supported (STALLED)
>>>>GEOM: create disk da0 dp=0xc82ad450
>>>>da0 at umass-sim0 bus 0 target 0 lun 0
>>>>da0: <Maxtor OneTouch 0200> Fixed Direct Access SCSI-0 device
>>>>da0: 1.000MB/s transfers
>>>>da0: 239371MB (490232832 512 byte sectors: 255H 63S/T 30515C)
>>>>
>>>>Sorry i can't report anything posivtive on this.
>>>
>>>
>>>And I can't see anything wrong with your log.
>>>
>>
>>Sorry, the log should only show what hardware i am using.
>>I could not find any log for the hangs, probably because it occurs while
>>the kernel is starting and i have to press reset, so it never gets
>>written to a logfile.
>>
>>The crash happend when i hotplugged an MP3 Jukebox and tried to mount it:
>>
>>Apr 3 12:32:26 antsrv1 kernel: umass1: ARCHOS ARCHOS USB2.0 (P4a), rev
>>2.00/11.01, addr 3
>>Apr 3 12:32:32 antsrv1 kernel: GEOM: create disk da1 dp=0xca5f0850
>>Apr 3 12:32:32 antsrv1 kernel: da1 at umass-sim1 bus 1 target 0 lun 0
>>Apr 3 12:32:32 antsrv1 kernel: da1: <HITACHI_ DK23EA-20 00K5> Fixed
>>Direct Access SCSI-0 device
>
>
> SCSI-0 - how funny - there was never a SCSI revision 0.
> If we would have been strict then da driver wouldn't attach, because
> it can't really know a SCSI-0 direct access.
> At least a disk should be SCSI-1 with CCS which is the first revision
> that definied the command set.
>
>
>>Apr 3 12:32:32 antsrv1 kernel: da1: 1.000MB/s transfers
>
>
> Also not very smart - but harmless.
>
>
>>Apr 3 12:32:32 antsrv1 kernel: da1: 19077MB (39070080 512 byte sectors:
>>255H 63S/T 2432C)
>>Apr 3 12:33:03 antsrv1 login: ROOT LOGIN (root) ON ttyv0
>>Apr 3 12:38:08 antsrv1 syslogd: kernel boot file is /boot/kernel/kernel
>>Apr 3 12:38:08 antsrv1 kernel: panic: ehci_abort_xfer: not in process
>>context
>
>
> OK - we have an abort_xfer without any reason given.
> The panic is because the aborted transfer doesn't exist, which could
> mean that someone aborted an already completed transfer.
> Can you please add USB_DEBUG to your kernel and retry.
I will, if i find an opportunity. Problem is that the machine is our
main server and each crash dirties all our filesystems. Luckily, 5.2.1
permits fsck in the background, so we don't have 30 min. downtime
anymore. I hope i can retry this week.
>
>
>>Apr 3 12:38:08 antsrv1 kernel: cpuid = 0;
>>Apr 3 12:38:08 antsrv1 kernel:
>>Apr 3 12:38:08 antsrv1 kernel: syncing disks, buffers remaining... 6418
>>6418 6418 6418 6418 6418 6418 6418 6418 6418 6418 6418 6418 6418 6418
>>6418 6418 6418 6418 6418
>>Apr 3 12:38:08 antsrv1 kernel: giving up on 3004 buffers
>>Apr 3 12:38:08 antsrv1 kernel: Uptime: 22h44m54s
>
>
> A stack trace would be fine too so we see the function issuing the
> abort.
> The cause might be with USB-1.1 too, but not triggered because of less
> speed.
>
>
>>Also, i get I/O-errors and the disk is inaccessible after having worked
>>ok for days. Rebooting the machine fixes this.
>
>
> Which kind of IO errors?
> USB / SCSI / DA / Application?
>
This i from "ktrace tunefs -p /dev/da0s1a"
4640 tunefs RET read 0
4640 tunefs CALL stat(0xbfbfea4a,0xbfbfe5a0)
4640 tunefs NAMI "/dev/da0s1a"
4640 tunefs RET stat 0
4640 tunefs CALL open(0xbfbfea4a,0,0)
4640 tunefs NAMI "/dev/da0s1a"
4640 tunefs RET open -1 errno 5 Input/output error
4640 tunefs CALL write(0x2,0xbfbfdf30,0x8)
4640 tunefs GIO fd 2 wrote 8 bytes
"tunefs: "
4640 tunefs RET write 8
4640 tunefs CALL write(0x2,0xbfbfdf50,0x2a)
4640 tunefs GIO fd 2 wrote 42 bytes
"/dev/da0s1a: could not open special device"
4640 tunefs RET write 42/0x2a
-- Heinrich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40717EFC.9040406>