sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64)

Sun Apr 1 10:50:16 UTC 2012

The following reply was made to PR sparc64/141918; it has been noted by GNATS.

From: Marius Strobl <marius at alchemy.franken.de>
To: Manuel Tobias Schiller <mala at hinterbergen.de>
Cc: bug-followup at FreeBSD.org
Subject: Re: sparc64/141918: [ehci] ehci_interrupt: unrecoverable error, controller halted (sparc64)
Date: Sun, 1 Apr 2012 12:41:24 +0200

 On Sun, Apr 01, 2012 at 09:33:03AM +0200, Manuel Tobias Schiller wrote:
 > On Fri, 30 Mar 2012 16:04:13 +0200
 > Manuel Tobias Schiller <mala at hinterbergen.de> wrote:
 > 
 > > On Fri, 30 Mar 2012 15:50:19 +0200
 > > Marius Strobl <marius at alchemy.franken.de> wrote:
 > > 
 > > > On Fri, Mar 30, 2012 at 03:34:26PM +0200, Manuel Tobias Schiller
 > > > wrote:
 > > > > On Fri, 30 Mar 2012 15:30:26 +0200
 > > > > Marius Strobl <marius at alchemy.franken.de> wrote:
 > > > > 
 > > > > > On Fri, Mar 30, 2012 at 01:00:25PM +0000, Manuel Tobias Schiller
 > > > > > wrote:
 > > > > > > The following reply was made to PR sparc64/141918; it has been
 > > > > > > noted by GNATS.
 > > > > > > 
 > > > > > > From: Manuel Tobias Schiller <mala at hinterbergen.de>
 > > > > > > To: bug-followup at FreeBSD.org, bel at orel.ru
 > > > > > > Cc:  
 > > > > > > Subject: Re: sparc64/141918: [ehci] ehci_interrupt:
 > > > > > > unrecoverable error, controller halted (sparc64)
 > > > > > > Date: Fri, 30 Mar 2012 14:58:07 +0200
 > > > > > > 
 > > > > > >  --Sig_/VHMCV0/0GzXjMMwv0Mf__N+
 > > > > > >  Content-Type: text/plain; charset=US-ASCII
 > > > > > >  Content-Transfer-Encoding: quoted-printable
 > > > > > >  
 > > > > > >  Dear all,
 > > > > > >  
 > > > > > >  has there been any progress on this one? I'm seeing basically
 > > > > > > the same thing with FreeBSD 9, but in my case the problem turns
 > > > > > > up when I try to mount one of my ZFS filesystems built in a
 > > > > > > RAIDZ configuration on real hard disks connected over USB. The
 > > > > > > disks are fine, and the ZFS filesystem was unexported cleanly
 > > > > > > on a different machine. You can find the kernel messages from
 > > > > > > dmesg below. 
 > > > > > >  I'm willing to test patches, but it might take a while, since
 > > > > > > my machine (Netra T1 AC200 with a 500 MHz CPU) is not quite
 > > > > > > that fast when recompiling kernels.
 > > > > > >  
 > > > > > 
 > > > > > Have you given the two patches mentioned earlier in the
 > > > > > audit-trail of this PR a try? It's probably a good idea to
 > > > > > additionally put "options USB_HOST_ALIGN=64" into the kernel
 > > > > > configuration file when testing the one for usb_transfer.c.
 > > > > > 
 > > > > > Marius
 > > > > 
 > > > > Hi Marius,
 > > > > 
 > > > > ok, so you did not get feedback on those patches.
 > > > 
 > > > No; so far I also couldn't reproduce this problem using the on-board
 > > > EHCI controllers in sun4u machines or the add-on cards I have. What
 > > > controller is this? If I'm not mistaken, the T1-AC200 don't have an
 > > > on-board EHCI controller.
 > > > 
 > > > Marius
 > > 
 > > Correct. These are "no-name" VIA PCI USB 2.0 controllers. In the past,
 > > I've swapped several of these (bought more than one year apart - this is
 > > what you got at the time when buying a USB controller in the area where
 > > I used to live) between the two Netra machines I administer, and it does
 > > not seems to be specific to the machine or a specific controller card
 > > (in the sense that these PCI cards run fine and without hiccups on
 > > Linux/ppc and Linux/x86).
 > > 
 > > These are the kernel-messages:
 > > 
 > > uhci0: <VIA 83C572 USB controller> port 0xc00200-0xc0021f at device 5.0
 > > on pci2 usbus2: <VIA 83C572 USB controller> on uhci0
 > > uhci1: <VIA 83C572 USB controller> port 0xc00220-0xc0023f at device 5.1
 > > on pci2 usbus3: <VIA 83C572 USB controller> on uhci1
 > > ehci0: <VIA VT6202 USB 2.0 controller> mem 0xa000-0xa0ff at device 5.2
 > > on pci2 ehci0: VIA-quirk applied
 > > usbus4: EHCI version 1.0
 > > usbus4: <VIA VT6202 USB 2.0 controller> on ehci0
 > > 
 > > The relevant part of "pciconf -l" is:
 > > 
 > > uhci0 at pci0:2:5:0:       class=0x0c0300 card=0x30381106 chip=0x30381106
 > > rev=0x62 hdr=0x00 uhci1 at pci0:2:5:1:       class=0x0c0300
 > > card=0x30381106 chip=0x30381106 rev=0x62 hdr=0x00
 > > ehci0 at pci0:2:5:2:       class=0x0c0320 card=0x31041106 chip=0x31041106
 > > rev=0x65 hdr=0x00
 > > 
 > > (World and kernel build for the latest 9-STABLE is on its way, first a
 > > reference kernel without patches so I know what I compare to...)
 > > 
 > > Manuel
 > 
 > Hi Marius,
 > 
 > it seems that the first patch alone
 > (http://people.freebsd.org/~kan/usb_rspro.diff)
 > does not solve the issue. I'm currently compiling a kernel with the second
 > patch on its own (with "options USB_HOST_ALIGN=64" in the kernel options
 > as you suggested), and I'll let you know what comes out.
 > 
 > Should I also build a kernel with both patches (assuming the one I'm
 > currently building does not work either)?
 > 

 Well, the individual patches shouldn't make things worse except for
 the second one causing more memory to be used so I'd suggest to
 combine them. If in the end things actually work we still can check
 what changes are needed for that.
 Looking at the Linux USB code, the FreeBSD one doesn't some to honor
 some DMA constraints and at least for the alignment it's actually
 hard to follow what value eventually is used. One thing that stands
 out is that for EHCI, the boundary is 4096. This is most easily fixed
 by defining USB_PAGE_SIZE to 4096 in sys/dev/usb/usb_busdma.h.

 Marius