[Gutsy] Kernel Oops after calling synce-serial-start

[exactt]

Binary package hint: synce-serial

I get the following errors after calling synce-serial-start:

[ 1109.032000] PPP generic driver version 2.4.2
[ 1109.124000] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 1109.208000] BUG: unable to handle kernel NULL pointer dereference at virtual address 0000002c
[ 1109.208000] printing eip:
[ 1109.208000] f8f94ba4
[ 1109.208000] *pde = 00000000
[ 1109.208000] Oops: 0002 [#1]
[ 1109.208000] SMP
[ 1109.208000] Modules linked in: iptable_filter ip_tables x_tables ppp_async ppp_generic slhc crc_ccitt rndis_host ipaq cdc_ether usbnet usbserial mii michael_mic arc4 ecb blkcipher ieee80211_crypt_tkip ipv6 binfmt_misc rfcomm l2cap bluetooth ppdev acpi_cpufreq cpufreq_powersave cpufreq_userspace cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container ac battery button video sbs dock sbp2 parport_pc lp parport snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi pcmcia snd_seq_midi_event af_packet ipw3945 snd_seq nvidia(P) snd_timer snd_seq_device ieee80211 ieee80211_crypt tpm_infineon tpm tpm_bios sdhci mmc_core yenta_socket rsrc_nonstatic pcmcia_core iTCO_wdt iTCO_vendor_support i2c_core snd soundcore intel_agp serio_raw psmouse snd_page_alloc agpgart shpchp pci_hotplug evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_piix ata_generic libata scsi_mod ehci_hcd ohci1394 ieee1394 r8169 uhci_hcd usbcore thermal processor fan fuse apparmor commoncap
[ 1109.208000] CPU: 0
[ 1109.208000] EIP: 0060:[<f8f94ba4>] Tainted: P VLI
[ 1109.208000] EFLAGS: 00210286 (2.6.22-11-generic #1)
[ 1109.208000] EIP is at ipaq_open+0x1e4/0x340 [ipaq]
[ 1109.208000] eax: f14c4000 ebx: 00000100 ecx: f1ef3800 edx: 00000000
[ 1109.208000] esi: f1610fa0 edi: f57160f4 ebp: f57160e0 esp: f14ade60
[ 1109.208000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 1109.208000] Process pppd (pid: 6579, ti=f14ac000 task=f15ff9f0 task.ti=f14ac000)
[ 1109.208000] Stack: f55f9000 f1a48340 00200292 c0242257 00000000 c0242f3d f1ef3800 f1a48ec0
[ 1109.208000] 00000064 f1ef3800 f1a48ec0 f55f9000 f1ef380c f8f7131a c0242114 f1a48c40
[ 1109.208000] f3bb87f8 f158e300 ffffffed 00000000 0bc00000 f158e300 00000000 c0245ec7
[ 1109.208000] Call Trace:
[ 1109.208000] [<c0242257>] tty_ldisc_enable+0x27/0x30
[ 1109.208000] [<c0242f3d>] init_dev+0x24d/0x5f0
[ 1109.208000] [<f8f7131a>] serial_open+0x10a/0x160 [usbserial]
[ 1109.208000] [<c0242114>] check_tty_count+0x14/0xb0
[ 1109.208000] [<c0245ec7>] tty_open+0x147/0x2f0
[ 1109.208000] [<c0245d80>] tty_open+0x0/0x2f0
[ 1109.208000] [<c0183456>] chrdev_open+0xa6/0x190
[ 1109.208000] [<c01833b0>] chrdev_open+0x0/0x190
[ 1109.208000] [<c017ec38>] __dentry_open+0xb8/0x1c0
[ 1109.208000] [<c017edf5>] nameidata_to_filp+0x35/0x40
[ 1109.208000] [<c017ee50>] do_filp_open+0x50/0x60
[ 1109.208000] [<c017eeae>] do_sys_open+0x4e/0xf0
[ 1109.208000] [<c017ef8c>] sys_open+0x1c/0x20
[ 1109.208000] [<c01041d2>] sysenter_past_esp+0x6b/0xa9
[ 1109.208000] =======================
[ 1109.208000] Code: ff ba d0 00 00 00 b8 40 af 3d c0 e8 e7 80 1e c7 8b 4c 24 18 85 c0 89 41 4c 0f 84 26 01 00 00 8b 44 24 18 89 c1 8b 50 44 8b 40 3c <89> 42 2c 8b 41 4c 8b 51 54 89 42 2c 8b 41 44 c7 40 34 00 10 00
[ 1109.208000] EIP: [<f8f94ba4>] ipaq_open+0x1e4/0x340 [ipaq] SS:ESP 0068:f14ade60

[Jacob (jacob-kleerekoper)]

I get exactly the same error when trying to synchronise with my Windows Mobile 5 Device

[Jean-Christophe Dubois (jcd)]

Same for me when trying to synchronize with a Qtek 9100 running Windows Mobile 5:

[291275.346347] BUG: unable to handle kernel NULL pointer dereference at virtual address 0000002c
[291275.346359] printing eip:
[291275.346361] f8b6bba4
[291275.346363] *pde = 00000000
[291275.346368] Oops: 0002 [#1]
[291275.346370] SMP
[291275.346374] Modules linked in: iptable_filter ip_tables x_tables ppp_async ppp_generic slhc crc_ccitt rndis_host cdc_ether usbnet ipaq usbserial kqemu isofs snd_rtctimer nfs binfmt_misc af_packet rfcomm l2cap bluetooth nfsd exportfs lockd sunrpc autofs4 ppdev ipv6 capifs video container sbs button dock ac battery w83627hf hwmon_vid eeprom i2c_isa lp rsrc_nonstatic pcmcia_core snd_intel8x0 snd_ac97_codec ac97_bus snd_usb_audio snd_pcm_oss snd_mixer_oss snd_pcm snd_usb_lib snd_hwdep snd_seq_dummy pwc snd_seq_oss compat_ioctl32 snd_seq_midi videodev v4l2_common v4l1_compat xpad snd_rawmidi snd_seq_midi_event parport_pc parport snd_seq snd_timer psmouse serio_raw pcspkr snd_seq_device snd soundcore snd_page_alloc shpchp i2c_sis96x i2c_core pci_hotplug sis_agp agpgart evdev reiserfs usbhid hid sg sr_mod cdrom sd_mod ehci_hcd sis900 mii ohci_hcd usbcore pata_sis ata_generic libata scsi_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod dm_mirror dm_snapshot dm_mod thermal processor fan fuse apparmor commoncap
[291275.346460] CPU: 0
[291275.346462] EIP: 0060:[<f8b6bba4>] Not tainted VLI
[291275.346463] EFLAGS: 00210286 (2.6.22-14-generic #1)
[291275.346494] EIP is at ipaq_open+0x1e4/0x340 [ipaq]
[291275.346497] eax: cd61d000 ebx: 00000100 ecx: e1185000 edx: 00000000
[291275.346501] esi: d8d9b720 edi: e88707d4 ebp: e88707c0 esp: c98cfe60
[291275.346505] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[291275.346508] Process pppd (pid: 16932, ti=c98ce000 task=dad6b9f0 task.ti=c98ce000)
[291275.346511] Stack: c9836800 cc51f080 00200292 c0241c47 00000000 c024292d e1185000 ca546980
[291275.346519] 00000064 e1185000 ca546980 c9836800 e118500c f8e8e31a c0241b04 cc51f400
[291275.346526] d27e47f8 c89fc280 ffffffed 00000000 0bc00000 c89fc280 00000000 c02458b7
[291275.346532] Call Trace:
[291275.346541] [<c0241c47>] tty_ldisc_enable+0x27/0x30
[291275.346558] [<c024292d>] init_dev+0x24d/0x5f0
[291275.346572] [<f8e8e31a>] serial_open+0x10a/0x160 [usbserial]
[291275.346589] [<c0241b04>] check_tty_count+0x14/0xb0
[291275.346604] [<c02458b7>] tty_open+0x147/0x2f0
[291275.346612] [<c0245770>] tty_open+0x0/0x2f0
[291275.346619] [<c0183416>] chrdev_open+0xa6/0x190
[291275.346635] [<c0183370>] chrdev_open+0x0/0x190
[291275.346639] [<c017ebf8>] __dentry_open+0xb8/0x1c0
[291275.346656] [<c017edb5>] nameidata_to_filp+0x35/0x40
[291275.346664] [<c017ee10>] do_filp_open+0x50/0x60
[291275.346695] [<c017ee6e>] do_sys_open+0x4e/0xf0
[291275.346701] [<c0106b20>] do_IRQ+0x40/0x70
[291275.346715] [<c017ef4c>] sys_open+0x1c/0x20
[291275.346720] [<c01041d2>] sysenter_past_esp+0x6b/0xa9
[291275.346744] =======================
[291275.346746] Code: ff ba d0 00 00 00 b8 40 9f 3d c0 e8 a7 10 61 c7 8b 4c 24 18 85 c0 89 41 4c 0f 84 26 01 00 00 8b 44 24 18 89 c1 8b 50 44 8b 40 3c <89> 42 2c 8b 41 4c 8b 51 5...

[Jean-Christophe Dubois (jcd)]

This bug seems to be quite similar to bug 98701 except it is still present in Gusty while 98701 was applied to Fiesty. so it was present in 2.6.20 and is still present in 2.6.22.

[Jean-Christophe Dubois (jcd)]

A bit more analysis on this:

When the smartphone is connected, 2 USB serial lines are created (ttyUSB0 and ttyUSB1). But the first line (ttyUSB0) has no bulk in/out, only an interupt in support. Therefore no read_urb/write_urb are associated to this line. On the opposite the second line (ttyUSB1) has a bulk in/out but no interrupt support.

By default we use ttyUSB0 but the ipaq_open() code in ipaq.c assumes that the port used has a read_urb/write_urb and will segfault (causing the OOPS reported here) if this is not the case.

I tried to use the second line (ttyUSB1) but for some reason the ipaq_open is not called on this one and the pppd daemon will fail to read anything from the device and exit.

In any case it sounds the code in ipaq_open() should not make assumptions about the read_urb/write_urb being initialized as it happens they are not in my case.

[Jean-Christophe Dubois (jcd)]

So it seems my device (qtek 9100 under windows mobile 5) is not supposed to be handled by usbserial/ipaq with the help of synce-serial-start. Instead it is supposed to be managed as an RNDIS device (rndis_host,cdc_ether,usbnet).
Indeed I got "connected using RNDIS after applying the following patch to the kernel:

http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/linux-2.6.22-rndis_host-wm5.patch

So first we need to make sure this patch is applied to the Gusty kernel

Second, I believe having an OOPS is still bad and should just not happen. I think it would be beneficial to add some code in ipaq_open() to test if read_urb/write_urb are indeed set. If not (as it is the case on ttyUSB0), ipaq_open() could return an error code.

Does it make sense?

Please note that there is a linux bug report about this problem:

http://bugzilla.kernel.org/show_bug.cgi?id=8094

[Jean-Christophe Dubois (jcd)]

In order to prevent the ipaq driver to be enabled for the "wrong" USB endpoint we also need to integrate this patch to the kernel (as proposed in http://bugzilla.kernel.org/show_bug.cgi?id=8094):

http://bugzilla.kernel.org/attachment.cgi?id=12918&action=view

[Jean-Christophe Dubois (jcd)]

while patch http://bugzilla.kernel.org/attachment.cgi?id=12918&action=view is applied to the latest 2.6.24 ubuntu kernel (Hardy), the other patch (http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/linux-2.6.22-rndis_host-wm5.patch) is still not integrated making it impossible to connect my device using RNDIS.

We should also make sure this patch is available in Hardy (as well as Gusty).

[Jean-Christophe Dubois (jcd)]

hum ... It doesn't seem to be fixed even in Linus latest GIT tree ...

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/usb/rndis_host.c;h=a61324757b179b04d67673d26c2484580d5a8676;hb=HEAD

[Jean-Christophe Dubois (jcd)]

Just to confirm that once the synce patch is applied to the current 2.6.24 linux kernel of Hardy the RNDIS feature is then working properly.

[Jean-Christophe Dubois (jcd)]

So considering that:

a) the problem seems to be understood
b) there are available patches for linux 2.6.22 and 2.6.24

Is it reasonable to expect:

1) an updated kernel for Gusty with the appropriate patches
2) the integration of the required patch in Hardy to get thing working out of the box

Anybody has a clue?

[Jean-Christophe Dubois (jcd)]

The kernel guys don't seem to like the WM5 patch. Therefore I tried to propose a new patch.

See my proposal at: http://bugzilla.kernel.org/show_bug.cgi?id=8094#c37

Any feedback is appreciated.

[Leann Ogasawara (leannogasawara)]

Just adding a note that I'm reassigning the Ubuntu Hardy kernel source package from 'linux-source-2.6.24' to just 'linux'. Beginning with the Hardy release the package naming convention changed from linux-source-2.6.x to just linux. Sorry for any confusion.

[Leann Ogasawara (leannogasawara)]

Hi jcd,

Your efforts to get the necessary patch into the upstream mainline kernel is the correct approach. It is a lot of extra work for the Ubuntu kernel team to maintain out of tree patches. As such they require evidence of upstream submission and acceptance before considering to maintain community patches locally. I've also went ahead and linked this launchpad report to monitor the upstream bug report. Thanks!

[Leann Ogasawara (leannogasawara)]

Also just adding a note that this report will remain open against the actively developed kernel, but will be closed against linux-source-2.6.22. Thanks!

[Jean-Christophe Dubois (jcd)]

It is a bit desapointing to consider that people using Gusty are doomed if they try to connect their smartphone as this will never get fixed (according to your decision). After all this bug triggers an OOPS which should be considered critical.

Also as things go the fix will not be in the kernel tree before 2.6.25. Does this mean Hardy (based on 2.6.24) is doomed too?

As a side note the fix (for RNDIS) is now discussed directly on the linux-usb mailing list.

[Leann Ogasawara (leannogasawara)]

Hi jcd,

Thank you for your concern. I'll elaborate a little more - according to the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With Gutsy 7.10 now released and Hardy 8.04 under development, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates. If the state of this bug should change such that it qualifies for the SRU process it will definitely be re-evaluated. Hope that helps. Thanks.

[Jean-Christophe Dubois (jcd)]

Hello Leann,

Just a small update to make things clear. The OOPS by itself doesn't happen anymore on 2.6.24 (Hardy) because the following patch is applied to the standard 2.6.24 kernel.

http://bugzilla.kernel.org/attachment.cgi?id=12918&action=view

This patch could be applied right now to 2.6.22 (Gusty) and it would prevent the OOPS reported above.

Then there is a second problem which is to make RNDIS USB devices work with Linux. It is my understanding that at the moment neither 2.6.22 nor 2.6.24 would work with such devices. Since the synce patch (pointed above) was not correct I proposed another one which should soon be merged to linux kernel main tree. The actual proposal is here:

http://www.mail-archive.com/linux-usb%40vger.kernel.org/msg01608.html

[Jean-Christophe Dubois (jcd)]

So Leann, I guess this report should be split in 2 independent bugs (as I should have done from the beginning).

One (the original) with the kernel OOPS problem should be nominated for Gusty release following the SRU policy by applying http://bugzilla.kernel.org/attachment.cgi?id=12918&action=view to the 2.6.22 kernel

And I will create another bug for the RNDIS problem that will be nominated for both Gusty and Hardy release once the patch http://www.mail-archive.com/linux-usb%40vger.kernel.org/msg01608.html is accepted in the Linux kernel tree.

Does it sound right?

[Jean-Christophe Dubois (jcd)]

I created bug 192411 for the RNDIS part. I will therefore nominate this bug for release with the appropriate required information.

1) A statement explaining the impact: with the Gusty 2.6.22 kernel 2 ttyUSB serial lines are created when you plug in the smartphone into the USB. Unfortunately the first of these 2 lines (ttyUSB0) is inadequate to be used with some programs like synce-serial-config/synce-serial-start. If it was used anyway, it would trigger the OOPS reported above. OOPS are never good and should be fixed if possible.

2) An explanation of how the bug has been addressed: This bug has been fixed in the current kernel tree by applying the following patch (http://bugzilla.kernel.org/attachment.cgi?id=12918&action=view). this patch is not applied to kernel 2.6.22 (and therefore to Gusty). Basically this patch is making sure that any ttyUSB line has a buk in and a buk out endpoint. As a result the interrupt in interface doesn't qualify anymore and there is only one ttyUSB created when the martphone is connected.

3) A patch applicable to the stable version of the package: the patch referenced above (http://bugzilla.kernel.org/attachment.cgi?id=12918&action=view) should apply cleanly.

4) Detailed instructions how to reproduce the bug:
# synce-serial-config ttyUSB0
# synce-serial-start
Then:
# dmesg

[Leann Ogasawara (leannogasawara)]

Hi jcd,

Thanks for opening up the bug report for the RNDIS problem. That was the correct thing to do. I'll go ahead and open the Gutsy nomination for the kernel team to take into consideration. I'm also including the hardy git commit id for the patch that you are proposing to be backported to Gutsy. Thanks.

ogasawara@yoji:~/ubuntu-hardy$ git log -p 063a2da8f01806906f7d7b1a1424b9afddebc443

commit 063a2da8f01806906f7d7b1a1424b9afddebc443

Author: Alan Stern <email address hidden>

Date: Wed Oct 10 16:24:06 2007 -0400

    USB: serial core should respect driver requirements

    This patch (as997) fixes a bug in the USB serial core. The core needs

    to pay attention to drivers' requirements regarding the number and

    type of endpoints a device has.

    At the same time, the patch changes the NUM_DONT_CARE constant (which

    is stored in a single-byte field) from -1 to a safer, unsigned value.

    It also improves the kerneldoc for several fields in the

    usb_serial_driver structure.

    Finally, the patch replaces a list_for_each() with list_for_each_entry().

    Signed-off-by: Alan Stern <email address hidden>

    Signed-off-by: Greg Kroah-Hartman <email address hidden>

[Leann Ogasawara (leannogasawara)]

Just closing invalid Gutsy nomination against the Hardy kernel. Gutsy nomination remains open against the appropriate 2.6.22 Gutsy kernel.

[Colin Ian King (colin-king)]

Hi jcd,

I have pack ported commit 063a2da8f01806906f7d7b1a1424b9afddebc443 and I have build a set of kernels with this patch in. Can you download the appropriate deb from:

http://people.ubuntu.com/~cking/sru-138583/

and try it out to see if this fixed the bug.

Thanks, Colin

[Colin Ian King (colin-king)]

Hi,

If anyone would like to test this, please do, as I can then see if the patch resolves the issue. I do not have the specific hardware, so this bug is not going to be resolved without some testing. Thanks

Colin

[Colin Ian King (colin-king)]

Hi, I suspect this bug will end up in the Won't Fix state if it's not tested. Any volunteers to test this?

Colin

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Leann Ogasawara (leannogasawara)]

The Gutsty Gibbon 7.10 release has reached it's end of life. As a result I'm closing the linux-source-2.6.22 task as well as it's Gutsy nomination. Thanks.

http://www.ubuntu.com/news/ubuntu-7.10-eol