dwc_otg: FIQ not disabling IRQ SOF interrupts after serial access

[P33M]

Problem is as follows:

At boot, a nominal 320 interrupts/sec happen versus IRQ32 (dwc_otg). On opening a PL2303 serial port adapter e.g. in Minicom, this number leaps to 10,000 per second give or take a few.

However when the serial port is closed (program exit) these IRQ32 interrupt rates do not decrease and continue at the same rate as previously.

I added some printk stats reporting to the interrupt handler and found out in the normal state, about 140 SOF interrupts are processed per second with a corresponding Host Channel Halted interrupts at about 140 as well. The FIQ gets hammered with about 25k interrupts a second.

After closing the serial port, the only counter incrementing at the specified rate is the SOF (IRQ) interrupt.

Unplugging the device, unplugging the hub have no effect. The only solution to get back to FIQ-handling mode is to reboot.

If I disable via dwc_otg.fiq_fix_enable=0 on the command line, behaviour is 8000 IRQs per second (idle) and 10000 per second (serial port open) but this then reverts back to 8000 on serial port closure.

lsusb -v:
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x067b Prolific Technology, Inc.
  idProduct          0x2303 PL2303 Serial Port
  bcdDevice            3.00
  iManufacturer           1 Prolific Technology Inc.
  iProduct                2 USB-Serial Controller
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x000a  1x 10 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

[ghollingworth]

The problem is almost definitely in the calculation of g_np_count and
g_np_sent. What happens is I increment the g_np_sent whenever I add a
non-periodic transaction to the active queue. I then increment the
g_np_count when I actually send a non-periodic transaction (i.e. bulk or
control)

In the FIQ I will trigger the main interrupt if g_np_count != g_np_sent
(i.e. we have unsent non-periodic transactions). What I've found before is
that when you close the serial port and remove the qh from the schedule if
there is an outstanding transmission then the g_np_count and g_np_sent are
not reset correctly and you always end up with the two values offset by one!

So I thought I fixed this by adding a test in dwc_otg_hcd_qh_deactivate,
but it only checks items in the inactive list, if it is ready or active
when deactivated then this wouldn't happen....

Gordon

On 13 January 2013 01:40, P33M notifications@github.com wrote:

Problem is as follows:

At boot, a nominal 320 interrupts/sec happen versus IRQ32 (dwc_otg). On
opening a PL2303 serial port adapter e.g. in Minicom, this number leaps to
10,000 per second give or take a few.

However when the serial port is closed (program exit) these IRQ32
interrupt rates do not decrease and continue at the same rate as
previously.

I added some printk stats reporting to the interrupt handler and found out
in the normal state, about 140 SOF interrupts are processed per second with
a corresponding Host Channel Halted interrupts at about 140 as well. The
FIQ gets hammered with about 25k interrupts a second.

After closing the serial port, the only counter incrementing at the
specified rate is the SOF (IRQ) interrupt.

Unplugging the device, unplugging the hub have no effect. The only
solution to get back to FIQ-handling mode is to reboot.

If I disable via dwc_otg.fiq_fix_enable=0 on the command line, behaviour
is 8000 IRQs per second (idle) and 10000 per second (serial port open) but
this then reverts back to 8000 on serial port closure.

lsusb -v:
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x067b Prolific Technology, Inc.
idProduct 0x2303 PL2303 Serial Port
bcdDevice 3.00
iManufacturer 1 Prolific Technology Inc.
iProduct 2 USB-Serial Controller
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/193.

[P33M]

The way I read it currently, g_np_sent is incremented iff a non periodic qh is assigned to a host channel (i.e. from the inactive queues to active). Usually this mechanism works OK because bulk or control URBs are submitted one at a time - leading to a single HC dealing with a single transaction for a single endpoint. This I think is a bit prone to error, easily reproducible with the serial example above. Shouldn't we set g_np_sent to qh->ntd instead?

This would also mean changing the conditions for reducing the g_np_count variable - i.e. on xfercomplete interrupt on a non-periodic endpoint and also reducing g_np_count by qh->ntds if we dequeue it.

Amusingly the driver doesn't seem to even deal with ntds in non-periodic cases - we could steal the functionality of this somewhat (or implement it as it seems to be needing - what happens if we enqueue more than 1 bulk URB at a time?).

[ghollingworth]

Fixed