headers
Frank Wille | 10 Dec 2010 20:35
Picon

Pegasos2 hangs during usb_discover()

Hi!

Did anybody notice system hangs during usb_discover(), when you just
connected a USB device? I'm seeing the problem since at least two months in
current (probably much longer, as I didn't test with my Peg during the
summer).

It might be ofppc- or Pegasos2-specific, because I couldn't reproduce it
with macppc hardware.

When enabling USB_DEBUG, I run into a DSI trap instead:

---8<--
trap: kernel read DSI trap  <at>  0xee938101 by 0x35a608 (DSISR 0x40000000):
USER_SR unset
Press a key to panic.

cpu0: Begin traceback...
0xaa70db30: at trap+0x140
0xaa70dbc0: kernel DSI read trap  <at>  0xee938101 by usb_allocmem+0xf4:
srr1=0x9032
            r1=0xaa70dc80 cr=0x24000048 xer=0 ctr=0x332758 dsisr=0x40000000
0xaa70dc80: at printf+0x94
0xaa70dcc0: at uhci_allocm+0xcc
0xaa70dcf0: at usbd_transfer+0x110
0xaa70dd20: at usbd_do_request_flags_pipe+0xf4
0xaa70dd80: at usbd_get_port_status+0x44
0xaa70dda0: at usbd_reset_port+0xec
0xaa70dde0: at usbd_new_device+0x31c
0xaa70dea0: at uhub_explore+0x3f4
(Continue reading)

Permalink | Reply |
headers
Frank Wille | 15 Dec 2010 23:25
Picon

Re: Pegasos2 hangs during usb_discover()

Some more information on this problem. Maybe somebody has an idea:

The Pegasos enters an infinite loop in usb_allocmem() due to a corrupted
usb_frag_freelist entry, which was just allocated in the previous call.

Probably caused by a USB DMA transfer, the block, offs and next fields of
the head usb_frag_dma node are trashed. This is an uhci controller.

Is it possible to do USB transfers without DMA for testing? I see not many
possibilities to debug it further.

USB worked some months ago. No other PPC port seems to be affected. Are
other ofppc (non-Pegasos) machines affected? Any information is welcome.

--

-- 
Frank Wille
Permalink | Reply |
headers
Michael | 15 Dec 2010 23:39
Picon

Re: Pegasos2 hangs during usb_discover()


Hello,

On Dec 15, 2010, at 5:25 PM, Frank Wille wrote:

> Some more information on this problem. Maybe somebody has an idea:
>
> The Pegasos enters an infinite loop in usb_allocmem() due to a  
> corrupted
> usb_frag_freelist entry, which was just allocated in the previous  
> call.
>
> Probably caused by a USB DMA transfer, the block, offs and next  
> fields of
> the head usb_frag_dma node are trashed. This is an uhci controller.
>
> Is it possible to do USB transfers without DMA for testing? I see  
> not many
> possibilities to debug it further.
>
> USB worked some months ago. No other PPC port seems to be affected.  
> Are
> other ofppc (non-Pegasos) machines affected? Any information is  
> welcome.

This may be because all PowerMacs with onboard USB use OHCIs. Most USB  
cards sold these days seem to be OHCIs as well, in fact I have only  
one UHCI card which did have some trouble with sparc64.
So, any chance to see if you have the same problem with an ohci card?
(Continue reading)

Permalink | Reply |
headers
Matt Thomas | 16 Dec 2010 00:44

Re: Pegasos2 hangs during usb_discover()


On Dec 15, 2010, at 2:25 PM, Frank Wille wrote:

> Some more information on this problem. Maybe somebody has an idea:
> 
> The Pegasos enters an infinite loop in usb_allocmem() due to a corrupted
> usb_frag_freelist entry, which was just allocated in the previous call.
> 
> Probably caused by a USB DMA transfer, the block, offs and next fields of
> the head usb_frag_dma node are trashed. This is an uhci controller.
> 
> Is it possible to do USB transfers without DMA for testing? I see not many
> possibilities to debug it further.
> 
> USB worked some months ago. No other PPC port seems to be affected. Are
> other ofppc (non-Pegasos) machines affected? Any information is welcome.

I've found usb_mem.c fragments to be a problem on many ppc.
I just checked in a workaround which seems to work for me.  Maybe it
will work for you.

I blame the lack of problem bus_dma for this problem but I have no proof.
Permalink | Reply |
headers
Frank Wille | 17 Dec 2010 00:15
Picon

Re: Pegasos2 hangs during usb_discover()

Matt Thomas wrote:

> I've found usb_mem.c fragments to be a problem on many ppc.
> I just checked in a workaround which seems to work for me.  Maybe it
> will work for you.

Yes, that was exactly my problem! After enabling your workaround USB works
again for me! Thanks.

I guess I should put this option into the GENERIC config for ofppc.

> I blame the lack of problem bus_dma for this problem but I have no
> proof. 

Possible. Will somebody try to fix that before 6.0?

But why does it only affect so few platforms? And why did it work in the
past? Very strange...

--

-- 
Frank Wille
Permalink | Reply |

Gmane