On Mon, 9 Apr 2001, Brad Hards wrote:
> The basic principle of operation is that a USB interrupt gets delivered when there
>is a
> packet to be received. Then I read it the packet with a bulk transfer. However
>everytime I
> submit the bulk URB, the whole machine locks up solid. No Magic SysReq, nothing
>except a
> power cycle (and fsck).
What I'm worried about is your bulk xfer buffers beeing part of your
device struct:
> struct catc_device {
>
[...]
> __u8 tx_buf[USB_CATC_BUFF_SIZE]; /* outwards data */
> __u8 rx_buf[USB_CATC_BUFF_SIZE]; /* inwards data */
So there is no way to control proper alignment required for PCI BM-DMA
when submitting the urb to the HC. Chances are the buffer location gets
misaligned or something along the path of virt_to_bus()/pci_map_single()
and the HC under-/overruns the buffer memory.
Same thing for the interrupt EP transfer buffer!
While I'm not absolutely sure whether this is the only trigger of your
problems, it's at least a pretty likely one. The normal way to handle this
issue is to switch to individual allocations for the transfer buffers:
catc->tx_buf = kmalloc(USB_CATC_BUFF_SIZE,GFP_KERNEL);
BTW, I'm not sure whether individually GFP_KERNEL-allocated and aligned
buffers are still required with Dave's recent pci_pool-related patches,
but at least it should not cause any harm.
BTW2, since it is ok to call the DMA mapping API functions from interrupt
context it should be ok to call usb_submit_urb() from your urb completion
handler catc_irq(), regardless whether you use the pci_pool patches or
not, IMHO.
Martin
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
