pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28

[Mark Lord]

Greg,

With 2.6.17-rc6-git2, I'm seeing this kernel message during start-up:

pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28

The pl2303 serial port is part of a USB1.1 Hub/dock device,
plugged into a USB2 port on my notebook.

I get the same failure again when trying to use the port with Kermit.
This device was working fine here not long ago -- on the -rc5 kernels I think.

Unplugging the hub/dock does this:

kernel BUG at kernel/workqueue.c:110!
invalid opcode: 0000 [#1]
PREEMPT
Modules linked in: nfsd exportfs lockd nfs_acl sunrpc speedstep_centrino cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave freq_table cpufreq_ondemand thermal fan battery ac processor container video button rfcomm l2cap bluetooth cfq_iosched deflate zlib_deflate twofish serpent aes blowfish des sha256 sha1 crypto_null af_key sbp2 af_packet pl2303 usbserial ipw2200 pcmcia usblp usbhid snd_intel8x0 snd_ac97_codec snd_ac97_bus ieee80211 ieee80211_crypt yenta_socket sdhci mmc_core snd_pcm_oss snd_mixer_oss mousedev firmware_class rsrc_nonstatic pcmcia_core ohci1394 ieee1394 b44 mii snd_pcm snd_timer snd serio_raw pcspkr ehci_hcd uhci_hcd psmouse soundcore snd_page_alloc intel_agp agpgart usbcore sg sr_mod cdrom unix
CPU: 0
EIP: 0060:[queue_work+81/96] Not tainted VLI
EFLAGS: 00210296 (2.6.17-rc6-git2 #1)
EIP is at queue_work+0x51/0x60
eax: f701113c ebx: 00000000 ecx: b21b9f80 edx: f7011138
esi: f79bcc80 edi: f79bcc80 ebp: f78a7614 esp: f79e3e4c
ds: 007b es: 007b ss: 0068
Process khubd (pid: 1733, threadinfo=f79e2000 task=f7e86a90)
Stack: 00000000 f8b09d63 b01ca38f b02e136b f8972ad3 f78a7600 f8b17080 f8b170a4
f78a7614 f89747f2 f78a767c f78a7614 b022240f f78a7614 f78a7614 f8989ae0
b02226a6 f78a7614 b0221c87 f78a7614 f7be9058 00000001 b0220e35 f78a7600
Call Trace:
<f8b09d63> usb_serial_disconnect+0x53/0xd0 [usbserial] <b01ca38f> kref_put+0x2f/0x80
<f8972ad3> usb_disable_interface+0x53/0x70 [usbcore] <f89747f2> usb_unbind_interface+0x32/0x70 [usbcore]
<b022240f> __device_release_driver+0x5f/0xc0 <b02226a6> device_release_driver+0x16/0x30
<b0221c87> bus_remove_device+0x77/0x90 <b0220e35> device_del+0x35/0x70
<f8973733> usb_disable_device+0xb3/0x100 [usbcore] <f896d404> usb_disconnect+0x94/0x100 [usbcore]
<f896d3f2> usb_disconnect+0x82/0x100 [usbcore] <f896d3f2> usb_disconnect+0x82/0x100 [usbcore]
<f896fc1e> hub_thread+0x3be/0xc75 [usbcore] <b012efc0> autoremove_wake_function+0x0/0x50
<b02b6d9f> preempt_schedule+0x4f/0x70 <b012eed6> kthread+0xd6/0xe0
<f896f860> hub_thread+0x0/0xc75 [usbcore] <b012ee00> kthread+0x0/0xe0
<b0101005> kernel_thread_helper+0x5/0x10
Code: a8 08 75 1c 89 d8 5b c3 89 f6 8d 42 04 3b 42 04 75 19 8b 01 bb 01 00 00 00 e8 dc fa ff ff eb d3 e8 85 ae 18 00 89 d8 5b 89 f6 c3 <0f> 0b 6e 00 d1 de 2c b0 eb dd 90 8d 74 26 00 89 c2 a1 d4 d1 38
EIP: [queue_work+81/96] queue_work+0x51/0x60 SS:ESP 0068:f79e3e4c
<6>note: khubd[1733] exited with preempt_count 1

???
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Mark Lord]

Mark Lord wrote:
> Greg,
>
> With 2.6.17-rc6-git2, I'm seeing this kernel message during start-up:
>
> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28
>
> The pl2303 serial port is part of a USB1.1 Hub/dock device,
> plugged into a USB2 port on my notebook.
>
> I get the same failure again when trying to use the port with Kermit.
> This device was working fine here not long ago -- on the -rc5 kernels I
> think.
>
> Unplugging the hub/dock does this:
>
> kernel BUG at kernel/workqueue.c:110!
> invalid opcode: 0000 [#1]
> PREEMPT

>...

MMmm.. entire USB subsystem is toast after that -- reboot required.

Cheers

[Lee Revell]

On Mon, 2006-06-12 at 16:06 -0400, Mark Lord wrote:
> Greg,
>
> With 2.6.17-rc6-git2, I'm seeing this kernel message during start-up:
>
> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28

Do you have USB bandwidth checking enabled? It's known to be broken.

Lee

[Mark Lord]

Mark Lord wrote:
> Greg,
>
> With 2.6.17-rc6-git2, I'm seeing this kernel message during start-up:
>
> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28
>
> The pl2303 serial port is part of a USB1.1 Hub/dock device,
> plugged into a USB2 port on my notebook.
>
> I get the same failure again when trying to use the port with Kermit.
> This device was working fine here not long ago -- on the -rc5 kernels I
> think.

Mmm.. no, it's broken in 2.6.17-rc5 as well.
I'll go back to 2.6.16.xx now, and see about that.

>
> Unplugging the hub/dock does this:
>
> kernel BUG at kernel/workqueue.c:110!
> invalid opcode: 0000 [#1]
> PREEMPT

..

[Greg KH]

On Mon, Jun 12, 2006 at 04:06:22PM -0400, Mark Lord wrote:
> Greg,
>
> With 2.6.17-rc6-git2, I'm seeing this kernel message during start-up:
>
> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28
>
> The pl2303 serial port is part of a USB1.1 Hub/dock device,
> plugged into a USB2 port on my notebook.

Known issue for years. Either plug it directly into the USB 2.0 root
hub, or disable the ehci driver.

> I get the same failure again when trying to use the port with Kermit.
> This device was working fine here not long ago -- on the -rc5 kernels I
> think.

It's a flaky thing.

Also, look in the -mm tree, there is a fix for this direct error, and
hopefully some ehci fixes that enable the whole thing to work properly.

thanks,

greg k-h

[Mark Lord]

Greg KH wrote:
.
> It's a flaky thing.

No kidding. Okay, it is also now failing for me with 2.6.16.18.

BUT.. with exactly that same binary kernel, it worked fine
not long ago --> but I've swapped out userland since then,
upgrading from Breezy to Dapper. So something userland in Dapper
is triggering this failure, in a way that Breezy never did before.

This device has been quite usable until now (the upgrade to Dapper).

> Known issue for years. Either plug it directly into the USB 2.0 root
> hub, or disable the ehci driver.

MMm.. yes, that makes some sense. I have a pl2303 standalone that works fine,
but the one integrated into the 1.1 hub/dock is the one that fails.

If I plug the 1.1 hub/dock into another external hub, no problems.

> Also, look in the -mm tree, there is a fix for this direct error, and
> hopefully some ehci fixes that enable the whole thing to work properly.

Okay, I'll hunt for that. Do you know of the exact patch?

Thanks

[Mark Lord]

Greg KH wrote:
> On Mon, Jun 12, 2006 at 04:06:22PM -0400, Mark Lord wrote:
>> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28
>>
>> The pl2303 serial port is part of a USB1.1 Hub/dock device,
>> plugged into a USB2 port on my notebook.
>
> Known issue for years. Either plug it directly into the USB 2.0 root
> hub, or disable the ehci driver.
>
>> I get the same failure again when trying to use the port with Kermit.
>> This device was working fine here not long ago -- on the -rc5 kernels I
>> think.
>
> It's a flaky thing.
>
> Also, look in the -mm tree, there is a fix for this direct error, and
> hopefully some ehci fixes that enable the whole thing to work properly.

I found this fix in -mm: gregkh-usb-usb-rmmod-pl2303-after-28.patch
It did *not* fix the problem.

Any other candidates available?

Thanks

[Greg KH]

On Mon, Jun 12, 2006 at 05:15:20PM -0400, Mark Lord wrote:
> Greg KH wrote:
> >On Mon, Jun 12, 2006 at 04:06:22PM -0400, Mark Lord wrote:
> >> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28
> >>
> >>The pl2303 serial port is part of a USB1.1 Hub/dock device,
> >>plugged into a USB2 port on my notebook.
> >
> >Known issue for years. Either plug it directly into the USB 2.0 root
> >hub, or disable the ehci driver.
> >
> >>I get the same failure again when trying to use the port with Kermit.
> >>This device was working fine here not long ago -- on the -rc5 kernels I
> >>think.
> >
> >It's a flaky thing.
> >
> >Also, look in the -mm tree, there is a fix for this direct error, and
> >hopefully some ehci fixes that enable the whole thing to work properly.
>
> I found this fix in -mm: gregkh-usb-usb-rmmod-pl2303-after-28.patch
> It did *not* fix the problem.

That should fix the memory leak after getting that error and let you
unload the module, right?

> Any other candidates available?

Look at the ehci patch:
improved-tt-scheduling-for-ehci.patch

And enable that option.

On Mon, Jun 12, 2006 at 04:56:47PM -0400, Mark Lord wrote:
> Greg KH wrote:
> ..

> >It's a flaky thing.
>

> No kidding. Okay, it is also now failing for me with 2.6.16.18.
>
> BUT.. with exactly that same binary kernel, it worked fine
> not long ago --> but I've swapped out userland since then,
> upgrading from Breezy to Dapper. So something userland in Dapper
> is triggering this failure, in a way that Breezy never did before.
>
> This device has been quite usable until now (the upgrade to Dapper).

Yeah, it's a timing issue with the EHCI TT code. It's never been
"correct" and we have had this problem since we first got USB 2.0
support. You were just lucky in not hitting it before.

> >Known issue for years. Either plug it directly into the USB 2.0 root
> >hub, or disable the ehci driver.
>

> MMm.. yes, that makes some sense. I have a pl2303 standalone that works
> fine, but the one integrated into the 1.1 hub/dock is the one that
> fails.
>
> If I plug the 1.1 hub/dock into another external hub, no problems.

I recommend doing that :)

It's not like you get _any_ speed differences by using a USB 2.0 hub
with this device...

thanks,

greg k-h

[Mark Lord]

>> I found this fix in -mm: gregkh-usb-usb-rmmod-pl2303-after-28.patch
>> > It did *not* fix the problem.
>
> That should fix the memory leak after getting that error and let you
> unload the module, right?

Nope. No difference here.

>> If I plug the 1.1 hub/dock into another external hub, no problems.
>
>I recommend doing that :)
>It's not like you get _any_ speed differences by using a USB 2.0 hub
>with this device...

I suppose not! ;)

But the USB2.0 "hub" is built-into my notebook,
and the "cascading hubs" solution is likely to stop
working when we begin enforcing per-port power limits
on these devices.

I'm rebuilding to try the suggested patch now.

Cheers

[Mark Lord]

Okay, with these two patches from -mm, the USB no longer dies
when I plug in my hub/dock device:

gregkh-usb-improved-tt-scheduling-for-ehci.patch
gregkh-usb-usb-rmmod-pl2303-after-28.patch

So let's get these pushed upstream sooner than later, please!

(Original 2.6.17-rc6-git2 crash quoted below)

> With 2.6.17-rc6-git2, I'm seeing this kernel message during start-up:
>

> pl2303 ttyUSB0: pl2303_open - failed submitting interrupt urb, error -28
>
> The pl2303 serial port is part of a USB1.1 Hub/dock device,
> plugged into a USB2 port on my notebook.
>

> I get the same failure again when trying to use the port with Kermit.
> This device was working fine here not long ago -- on the -rc5 kernels I think.
>

> Unplugging the hub/dock does this:
>
> kernel BUG at kernel/workqueue.c:110!
> invalid opcode: 0000 [#1]
> PREEMPT

[Greg KH]

On Mon, Jun 12, 2006 at 05:54:21PM -0400, Mark Lord wrote:
> Okay, with these two patches from -mm, the USB no longer dies
> when I plug in my hub/dock device:
>
> gregkh-usb-improved-tt-scheduling-for-ehci.patch
> gregkh-usb-usb-rmmod-pl2303-after-28.patch
>
> So let's get these pushed upstream sooner than later, please!

It will happen after 2.6.17 is out, as they are in the queue to do so.

And it's not a "must rush" fix, this has _always_ been like this, you
just got lucky in the past :)

thanks,

greg k-h

[Mark Lord]

Greg KH wrote:
> On Mon, Jun 12, 2006 at 05:54:21PM -0400, Mark Lord wrote:
>> Okay, with these two patches from -mm, the USB no longer dies
>> when I plug in my hub/dock device:
>>
>> gregkh-usb-improved-tt-scheduling-for-ehci.patch
>> gregkh-usb-usb-rmmod-pl2303-after-28.patch
>>
>> So let's get these pushed upstream sooner than later, please!
>
> It will happen after 2.6.17 is out, as they are in the queue to do so.

2.6.18 will do, I suppose.

But has the *real* bug been fixed with these patches,
or merely "avoided" ?

Eg. If usb_submit_urb() ever fails again (low on memory, etc..)
inside pl2303_open(), will we be back with the same bug?

What's the *real* actual bug here?

Thanks

[Greg KH]

On Mon, Jun 12, 2006 at 06:12:58PM -0400, Mark Lord wrote:
> Greg KH wrote:
> >On Mon, Jun 12, 2006 at 05:54:21PM -0400, Mark Lord wrote:
> >>Okay, with these two patches from -mm, the USB no longer dies
> >>when I plug in my hub/dock device:
> >>
> >>gregkh-usb-improved-tt-scheduling-for-ehci.patch
> >>gregkh-usb-usb-rmmod-pl2303-after-28.patch
> >>
> >>So let's get these pushed upstream sooner than later, please!
> >
> >It will happen after 2.6.17 is out, as they are in the queue to do so.
>
> 2.6.18 will do, I suppose.
>
> But has the *real* bug been fixed with these patches,
> or merely "avoided" ?

The tt-scheduling patch should have fixed the "real" bug.

> Eg. If usb_submit_urb() ever fails again (low on memory, etc..)
> inside pl2303_open(), will we be back with the same bug?
>
> What's the *real* actual bug here?

There are two of them.

The fact that the urb submission in the pl2303 driver fails, and is now
handled properly is fixed in the pl2303 patch.

The fact that we can (hopefully) handle scheduling TT in the EHCI driver
fixes the real problem with plugging slow or full speed devices into a
USB 2.0 hub (not root hub). That's fixed by the tt patch.

So we should have finally covered both of them now.

thanks,

greg k-h

[Mark Lord]

Greg KH wrote:
> On Mon, Jun 12, 2006 at 06:12:58PM -0400, Mark Lord wrote:
.
>> Eg. If usb_submit_urb() ever fails again (low on memory, etc..)
>> inside pl2303_open(), will we be back with the same bug?
>>
>> What's the *real* actual bug here?
>
> There are two of them.
>
> The fact that the urb submission in the pl2303 driver fails, and is now
> handled properly is fixed in the pl2303 patch.
>
> The fact that we can (hopefully) handle scheduling TT in the EHCI driver
> fixes the real problem with plugging slow or full speed devices into a
> USB 2.0 hub (not root hub). That's fixed by the tt patch.
>
> So we should have finally covered both of them now.

Yes, agreed.

So if modify pl2303_open() to have it simulate -ENOMEM from usb_submit_urb(),
then this should not crash the entire USB subsystem. Right?

Ditto if it happens due to low-memory, rather than me hacking the code to test it?

Cheers

[Mark Lord]

Mark Lord wrote:
> Greg KH wrote:

>> So we should have finally covered both of them now.
>
> Yes, agreed.
>
> So if modify pl2303_open() to have it simulate -ENOMEM from
> usb_submit_urb(),
> then this should not crash the entire USB subsystem. Right?
>
> Ditto if it happens due to low-memory, rather than me hacking the code
> to test it?

Mmmm.. looks like it's still buggy, but we manage to avoid the bug
under *most* circumstances. Which is good!

But the bug will still need to be fixed. A failure from usb_submit_urb()
should not require a reboot to recover.
Here's the results of a simulated -ENOMEM test:

kernel BUG at kernel/workqueue.c:110!
invalid opcode: 0000 [#1]
PREEMPT

Modules linked in: pl2303 mct_u232 usblp usbserial usbhid snd_pcm_oss uhci_hcd ehci_hcd vmnet vmmon nfsd exportfs lockd nfs_acl sunrpc speedstep_centrino cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave freq_table cpufreq_ondemand thermal fan battery ac processor container video button rfcomm l2cap bluetooth cfq_iosched deflate zlib_deflate twofish serpent aes blowfish des sha256 sha1 crypto_null af_key af_packet sbp2 pcmcia ipw2200 ieee80211 ieee80211_crypt snd_intel8x0 snd_ac97_codec snd_ac97_bus yenta_socket ohci1394 ieee1394 snd_mixer_oss mousedev rsrc_nonstatic pcmcia_core mmc_core b44 mii firmware_class snd_pcm snd_timer snd soundcore serio_raw pcspkr snd_page_alloc psmouse intel_agp agpgart usbcore sg sr_mod cdrom unix
CPU: 0
EIP: 0060:[queue_work+81/96] Tainted: P VLI
EFLAGS: 00010286 (2.6.17-rc6-git2 #3)
EIP is at queue_work+0x51/0x60
eax: f317093c ebx: 00000000 ecx: b21b9f80 edx: f3170938
esi: f4782640 edi: f4782640 ebp: f7333414 esp: f7cc3e4c

ds: 007b es: 007b ss: 0068

Process khubd (pid: 1737, threadinfo=f7cc2000 task=b21bb070)
Stack: 00000000 f8a30d63 b01ca38f b02e136b f8884ad3 f7333400 f8c52080 f8c520a4
f7333414 f88867f2 f733347c f7333414 b022240f f7333414 f7333414 f889bae0
b02226a6 f7333414 b0221c87 f7333414 f7519c58 00000001 b0220e35 f7333400
Call Trace:
<f8a30d63> usb_serial_disconnect+0x53/0xd0 [usbserial] <b01ca38f> kref_put+0x2f/0x80
<f8884ad3> usb_disable_interface+0x53/0x70 [usbcore] <f88867f2> usb_unbind_interface+0x32/0x70 [usbcore]

<b022240f> __device_release_driver+0x5f/0xc0 <b02226a6> device_release_driver+0x16/0x30
<b0221c87> bus_remove_device+0x77/0x90 <b0220e35> device_del+0x35/0x70

<f8885733> usb_disable_device+0xb3/0x100 [usbcore] <f887f404> usb_disconnect+0x94/0x100 [usbcore]
<f887f3f2> usb_disconnect+0x82/0x100 [usbcore] <f887f3f2> usb_disconnect+0x82/0x100 [usbcore]
<f8881c1e> hub_thread+0x3be/0xc75 [usbcore] <b012efc0> autoremove_wake_function+0x0/0x50
<b02b6d9f> preempt_schedule+0x4f/0x70 <b012eed6> kthread+0xd6/0xe0
<f8881860> hub_thread+0x0/0xc75 [usbcore] <b012ee00> kthread+0x0/0xe0

<b0101005> kernel_thread_helper+0x5/0x10
Code: a8 08 75 1c 89 d8 5b c3 89 f6 8d 42 04 3b 42 04 75 19 8b 01 bb 01 00 00 00 e8 dc fa ff ff eb d3 e8 85 ae 18 00 89 d8 5b 89 f6 c3 <0f> 0b 6e 00 d1 de 2c b0 eb dd 90 8d 74 26 00 89 c2 a1 d4 d1 38

EIP: [queue_work+81/96] queue_work+0x51/0x60 SS:ESP 0068:f7cc3e4c
<6>note: khubd[1737] exited with preempt_count 1

[Frank Gevaerts]

On Mon, Jun 12, 2006 at 07:21:26PM -0400, Mark Lord wrote:
> Mark Lord wrote:
> >Greg KH wrote:
> >>So we should have finally covered both of them now.
> >
> >Yes, agreed.
> >
> >So if modify pl2303_open() to have it simulate -ENOMEM from
> >usb_submit_urb(),
> >then this should not crash the entire USB subsystem. Right?
> >
> >Ditto if it happens due to low-memory, rather than me hacking the code
> >to test it?
>
> Mmmm.. looks like it's still buggy, but we manage to avoid the bug
> under *most* circumstances. Which is good!
>
> But the bug will still need to be fixed. A failure from usb_submit_urb()
> should not require a reboot to recover.
> Here's the results of a simulated -ENOMEM test:
>
> kernel BUG at kernel/workqueue.c:110!

We had the exact same error here with ipaq.ko. Our problems only went
away once we applied the following (the first part might already be
applied).
Apart from that, we also needed a lot of fixes in ipaq.c. I still have
to clean up and submit the complete patch.

Frank

Signed-of-byA Frank Gevaerts <frank.g...@fks.be>

--- linux-2.6.17-rc4/drivers/usb/serial/usb-serial.c 2006-05-30 19:01:16.000000000 +0200
+++ linux-2.6.17-rc4.test/drivers/usb/serial/usb-serial.c 2006-06-02 21:50:07.000000000 +0200
@@ -162,6 +162,8 @@ static void destroy_serial(struct kref *
}
}

+ flush_scheduled_work(); /* port->work */
+
usb_put_dev(serial->dev);

/* free up any memory that we allocated */
@@ -223,6 +225,8 @@ static int serial_open (struct tty_struc
return 0;

bailout_module_put:
+ tty->driver_data = NULL;
+ port->tty = NULL;
module_put(serial->type->driver.owner);
bailout_kref_put:
kref_put(&serial->kref, destroy_serial);

Frank

--
Frank Gevaerts frank.g...@fks.be
fks bvba - Formal and Knowledge Systems http://www.fks.be/
Stationsstraat 108 Tel: ++32-(0)11-21 49 11
B-3570 ALKEN Fax: ++32-(0)11-22 04 19

[Luiz Fernando N. Capitulino]

On Tue, 13 Jun 2006 13:46:06 +0200
Frank Gevaerts <frank.g...@fks.be> wrote:

| On Mon, Jun 12, 2006 at 07:21:26PM -0400, Mark Lord wrote:
| > Mark Lord wrote:
| > >Greg KH wrote:
| > >>So we should have finally covered both of them now.
| > >
| > >Yes, agreed.
| > >
| > >So if modify pl2303_open() to have it simulate -ENOMEM from
| > >usb_submit_urb(),
| > >then this should not crash the entire USB subsystem. Right?
| > >
| > >Ditto if it happens due to low-memory, rather than me hacking the code
| > >to test it?
| >
| > Mmmm.. looks like it's still buggy, but we manage to avoid the bug
| > under *most* circumstances. Which is good!
| >
| > But the bug will still need to be fixed. A failure from usb_submit_urb()
| > should not require a reboot to recover.
| > Here's the results of a simulated -ENOMEM test:
| >
| > kernel BUG at kernel/workqueue.c:110!
|
| We had the exact same error here with ipaq.ko. Our problems only went
| away once we applied the following (the first part might already be
| applied).

Interesting, I couldn't reproduce this with ftdio_sio.

(and unfortunatally I'm w/o my pl2303 device).

--
Luiz Fernando N. Capitulino

[Luiz Fernando N. Capitulino]

On Tue, 13 Jun 2006 13:26:55 -0300
"Luiz Fernando N. Capitulino" <lcapi...@mandriva.com.br> wrote:

| On Tue, 13 Jun 2006 13:46:06 +0200
| Frank Gevaerts <frank.g...@fks.be> wrote:
|
| | On Mon, Jun 12, 2006 at 07:21:26PM -0400, Mark Lord wrote:
| | > Mark Lord wrote:
| | > >Greg KH wrote:
| | > >>So we should have finally covered both of them now.
| | > >
| | > >Yes, agreed.
| | > >
| | > >So if modify pl2303_open() to have it simulate -ENOMEM from
| | > >usb_submit_urb(),
| | > >then this should not crash the entire USB subsystem. Right?
| | > >
| | > >Ditto if it happens due to low-memory, rather than me hacking the code
| | > >to test it?
| | >
| | > Mmmm.. looks like it's still buggy, but we manage to avoid the bug
| | > under *most* circumstances. Which is good!
| | >
| | > But the bug will still need to be fixed. A failure from usb_submit_urb()
| | > should not require a reboot to recover.
| | > Here's the results of a simulated -ENOMEM test:
| | >
| | > kernel BUG at kernel/workqueue.c:110!
| |
| | We had the exact same error here with ipaq.ko. Our problems only went
| | away once we applied the following (the first part might already be
| | applied).
|
| Interesting, I couldn't reproduce this with ftdio_sio.

Ok, managed to reproduce it (in fact it happens at disconnection
time).

Frank, the second hunk of your patch fixes it, but the right
label is bailout_mutex_unlock. Like this:

diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 9c36f0e..0b7bc20 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -230,6 +230,7 @@ bailout_module_put:
module_put(serial->type->driver.owner);
bailout_mutex_unlock:
port->open_count = 0;
+ tty->driver_data = port->tty = NULL;
mutex_unlock(&port->mutex);
bailout_kref_put:
kref_put(&serial->kref, destroy_serial);

Could you redo and submit please?

[Frank Gevaerts]

On Tue, Jun 13, 2006 at 02:45:12PM -0300, Luiz Fernando N. Capitulino wrote:
> Could you redo and submit please?

OK. Here it is:

Fixes a BUG on disconnect. gregkh-usb-usb-rmmod-pl2303-after-28.patch (from -mm trees)
is also needed to fix all problems.

Signed-off-by: Frank Gevaerts <frank.g...@fks.be>

diff -urp linux-2.6.17-rc6/drivers/usb/serial/usb-serial.c linux-2.6.17-rc6.a/drivers/usb/serial/usb-serial.c
--- linux-2.6.17-rc6/drivers/usb/serial/usb-serial.c 2006-06-14 13:03:55.000000000 +0200
+++ linux-2.6.17-rc6.a/drivers/usb/serial/usb-serial.c 2006-06-14 13:23:34.000000000 +0200
@@ -230,6 +232,8 @@ bailout_module_put:

module_put(serial->type->driver.owner);
bailout_mutex_unlock:
port->open_count = 0;

+ tty->driver_data = NULL;
+ port->tty = NULL;

mutex_unlock(&port->mutex);
bailout_kref_put:
kref_put(&serial->kref, destroy_serial);

--

Frank Gevaerts frank.g...@fks.be
fks bvba - Formal and Knowledge Systems http://www.fks.be/
Stationsstraat 108 Tel: ++32-(0)11-21 49 11
B-3570 ALKEN Fax: ++32-(0)11-22 04 19

[Luiz Fernando N. Capitulino]

On Wed, 14 Jun 2006 13:52:30 +0200
Frank Gevaerts <frank.g...@fks.be> wrote:

| On Tue, Jun 13, 2006 at 02:45:12PM -0300, Luiz Fernando N. Capitulino wrote:
| > Could you redo and submit please?
|
| OK. Here it is:
|
| Fixes a BUG on disconnect. gregkh-usb-usb-rmmod-pl2303-after-28.patch (from -mm trees)
| is also needed to fix all problems.

Hmm, I'd prefer something like this:

"""
If either the driver's open() method or try_module_get() fails, we need to
set 'tty->driver_data' and 'port->tty' to NULL in serial_open(), otherwise
we'll get an OOPS in usb_device_disconnect() when the device is disconnected.
"""

--
Luiz Fernando N. Capitulino

[Frank Gevaerts]

On Wed, Jun 14, 2006 at 10:49:18AM -0300, Luiz Fernando N. Capitulino wrote:
> Hmm, I'd prefer something like this:

OK

If either the driver's open() method or try_module_get() fails, we need to
set 'tty->driver_data' and 'port->tty' to NULL in serial_open(), otherwise
we'll get an OOPS in usb_device_disconnect() when the device is disconnected.

Signed-off-by: Frank Gevaerts <frank.g...@fks.be>

diff -urp linux-2.6.17-rc6/drivers/usb/serial/usb-serial.c linux-2.6.17-rc6.a/drivers/usb/serial/usb-serial.c
--- linux-2.6.17-rc6/drivers/usb/serial/usb-serial.c 2006-06-14 13:03:55.000000000 +0200
+++ linux-2.6.17-rc6.a/drivers/usb/serial/usb-serial.c 2006-06-14 13:23:34.000000000 +0200
@@ -230,6 +232,8 @@ bailout_module_put:
module_put(serial->type->driver.owner);
bailout_mutex_unlock:
port->open_count = 0;
+ tty->driver_data = NULL;
+ port->tty = NULL;
mutex_unlock(&port->mutex);
bailout_kref_put:
kref_put(&serial->kref, destroy_serial);

--
Frank Gevaerts frank.g...@fks.be
fks bvba - Formal and Knowledge Systems http://www.fks.be/
Stationsstraat 108 Tel: ++32-(0)11-21 49 11
B-3570 ALKEN Fax: ++32-(0)11-22 04 19

[Luiz Fernando N. Capitulino]

On Wed, 14 Jun 2006 15:52:05 +0200
Frank Gevaerts <frank.g...@fks.be> wrote:

| On Wed, Jun 14, 2006 at 10:49:18AM -0300, Luiz Fernando N. Capitulino wrote:
| > Hmm, I'd prefer something like this:
|
| OK
|
| If either the driver's open() method or try_module_get() fails, we need to
| set 'tty->driver_data' and 'port->tty' to NULL in serial_open(), otherwise
| we'll get an OOPS in usb_device_disconnect() when the device is disconnected.
|
| Signed-off-by: Frank Gevaerts <frank.g...@fks.be>

Acked-by: Luiz Fernando N. Capitulino <lcapi...@mandriva.com.br>

|
| diff -urp linux-2.6.17-rc6/drivers/usb/serial/usb-serial.c linux-2.6.17-rc6.a/drivers/usb/serial/usb-serial.c
| --- linux-2.6.17-rc6/drivers/usb/serial/usb-serial.c 2006-06-14 13:03:55.000000000 +0200
| +++ linux-2.6.17-rc6.a/drivers/usb/serial/usb-serial.c 2006-06-14 13:23:34.000000000 +0200
| @@ -230,6 +232,8 @@ bailout_module_put:
| module_put(serial->type->driver.owner);
| bailout_mutex_unlock:
| port->open_count = 0;
| + tty->driver_data = NULL;
| + port->tty = NULL;
| mutex_unlock(&port->mutex);
| bailout_kref_put:
| kref_put(&serial->kref, destroy_serial);
|
| --
| Frank Gevaerts frank.g...@fks.be
| fks bvba - Formal and Knowledge Systems http://www.fks.be/
| Stationsstraat 108 Tel: ++32-(0)11-21 49 11
| B-3570 ALKEN Fax: ++32-(0)11-22 04 19

--
Luiz Fernando N. Capitulino