Recommended USB 2.0 controller fr. 5.2+

Bernd Walter ticso at cicely12.cicely.de
Mon Apr 5 08:23:23 PDT 2004


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.

> 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?

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso at bwct.de                                  info at bwct.de



More information about the freebsd-questions mailing list