* kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 @ 2007-04-07 18:11 Bartek 2007-04-08 6:47 ` David Miller 0 siblings, 1 reply; 21+ messages in thread From: Bartek @ 2007-04-07 18:11 UTC (permalink / raw) To: linux-kernel Hallo I have problem with a Linux kernel oops. It mostly appears when I download files using bittorrent or other large file. I have a phone modem based Internet access using Home Internet Solution (http://en.wikipedia.org/wiki/Home_internet_Solution). I use Debian testing, Linux vanilla version: 2.6.21-rc6 (however I noticed that problem since Linux ver. 2.6.15, doesn't matter if that was vanilla kernel or from Debian distro), Here my sys info: Linux mars 2.6.21-rc6 #3 Sat Apr 7 16:11:12 CEST 2007 i686 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP xfsprogs 2.8.11 PPP 2.4.4 Linux C Library 2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 105 Modules Loaded nvidia vmnet vmmon nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs eeprom w83781d w83627hf hwmon_vid i2c_isa ide_generic parport_pc parport rtc floppy serio_raw pcspkr psmouse i2c_viapro snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart i2c_core via_ircc snd_rawmidi snd_seq_device via_agp agpgart snd irda crc_ccitt soundcore evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan If there are needs for more info, don't hesitate to ask. If anyone can help me and write a patch, I'll be appreciated. Here is a log from syslog: Apr 7 17:45:52 localhost kernel: skb_under_panic: text:f8e36c0e len:107 put:1 head:df928000 data:df927fff tail:df92806a end:df928600 dev:<NULL> Apr 7 17:45:52 localhost kernel: ------------[ cut here ]------------ Apr 7 17:45:52 localhost kernel: kernel BUG at net/core/skbuff.c:111! Apr 7 17:45:52 localhost kernel: invalid opcode: 0000 [#1] Apr 7 17:45:52 localhost kernel: Modules linked in: w83781d w83627hf i2c_dev nvidia(P) nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs eeprom hwmon_vid i2c_isa ide_generic rtc snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart i2c_viapro i2c_core serio_raw snd_rawmidi snd_seq_device via_ircc psmouse pcspkr floppy irda snd crc_ccitt soundcore via_agp agpgart evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan Apr 7 17:45:52 localhost kernel: CPU: 0 Apr 7 17:45:52 localhost kernel: EIP: 0060:[<c021af98>] Tainted: P VLI Apr 7 17:45:52 localhost kernel: EFLAGS: 00010096 (2.6.21-rc6 #2) Apr 7 17:45:52 localhost kernel: EIP is at skb_under_panic+0x59/0x5d Apr 7 17:45:52 localhost kernel: eax: 00000072 ebx: df928000 ecx: 00000000 edx: 00000000 Apr 7 17:45:52 localhost kernel: esi: 00000000 edi: df92806c ebp: df92806b esp: c17e5ed8 Apr 7 17:45:52 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Apr 7 17:45:52 localhost kernel: Process events/0 (pid: 3, ti=c17e4000 task=dfd02030 task.ti=c17e4000) Apr 7 17:45:52 localhost kernel: Stack: c02c4d51 f8e36c0e 0000006b 00000001 df928000 df927fff df92806a df928600 Apr 7 17:45:52 localhost kernel: c02b83d5 e366f8e0 000000ff f8e36c13 ffffffff c01044d7 00000000 c17e4000 Apr 7 17:45:52 localhost kernel: f7f9f576 f7f9f476 f6b9a800 00000202 dfe60c00 00000001 f7f9f400 f6b9a80c Apr 7 17:45:52 localhost kernel: Call Trace: Apr 7 17:45:52 localhost kernel: [<f8e36c0e>] ppp_asynctty_receive+0x3b0/0x584 [ppp_async] Apr 7 17:45:52 localhost kernel: [<f8e36c13>] ppp_asynctty_receive+0x3b5/0x584 [ppp_async] Apr 7 17:45:52 localhost kernel: [<c01044d7>] common_interrupt+0x23/0x28 Apr 7 17:45:52 localhost kernel: [<c01ea3c6>] flush_to_ldisc+0xe6/0x124 Apr 7 17:45:52 localhost kernel: [<c01ea2e0>] flush_to_ldisc+0x0/0x124 Apr 7 17:45:52 localhost kernel: [<c0122983>] run_workqueue+0x70/0x101 Apr 7 17:45:52 localhost kernel: [<c0122ecc>] worker_thread+0x105/0x12e Apr 7 17:45:52 localhost kernel: [<c0114a9e>] default_wake_function+0x0/0xc Apr 7 17:45:52 localhost kernel: [<c0122dc7>] worker_thread+0x0/0x12e Apr 7 17:45:52 localhost kernel: [<c0125090>] kthread+0xa0/0xc8 Apr 7 17:45:52 localhost kernel: [<c0124ff0>] kthread+0x0/0xc8 Apr 7 17:45:52 localhost kernel: [<c0104657>] kernel_thread_helper+0x7/0x10 Apr 7 17:45:52 localhost kernel: ======================= Apr 7 17:45:52 localhost kernel: Code: 00 00 89 5c 24 14 8b 98 a0 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c 24 04 c7 04 24 51 4d 2c c0 89 44 24 08 e8 f2 c8 ef ff <0f> 0b eb fe 56 53 bb d5 83 2b c0 83 ec 24 8b 70 14 85 f6 0f 45 Apr 7 17:45:52 localhost kernel: EIP: [<c021af98>] skb_under_panic+0x59/0x5d SS:ESP 0068:c17e5ed8 Apr 7 17:46:01 localhost /USR/SBIN/CRON[16193]: (root) CMD (/usr/local/bin/pppd_test.sh) Apr 7 17:46:41 localhost pppd[2132]: No response to 5 echo-requests Apr 7 17:46:41 localhost pppd[2132]: Serial link appears to be disconnected. Apr 7 17:46:41 localhost pppd[2132]: Connect time 423.3 minutes. Apr 7 17:46:41 localhost pppd[2132]: Sent 72441222 bytes, received 121032582 bytes. Apr 7 17:46:41 localhost pppd[2132]: Script /etc/ppp/ip-down started (pid 16196) Apr 7 17:46:41 localhost pppd[2132]: sent [LCP TermReq id=0x3d "Peer not responding"] Apr 7 17:46:41 localhost pppd[2132]: Script /etc/ppp/ip-down finished (pid 16196), status = 0x0 Apr 7 17:46:44 localhost pppd[2132]: sent [LCP TermReq id=0x3e "Peer not responding"] Apr 7 17:46:47 localhost pppd[2132]: Connection terminated. Bartek ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-07 18:11 kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 Bartek @ 2007-04-08 6:47 ` David Miller 2007-04-08 20:15 ` Bartek 0 siblings, 1 reply; 21+ messages in thread From: David Miller @ 2007-04-08 6:47 UTC (permalink / raw) To: poemann; +Cc: linux-kernel From: Bartek <poemann@gmail.com> Date: Sat, 7 Apr 2007 20:11:13 +0200 > I have problem with a Linux kernel oops. It mostly appears when I > download files using bittorrent or other large file. I have a phone > modem based Internet access using Home Internet Solution > (http://en.wikipedia.org/wiki/Home_internet_Solution). I use Debian > testing, Linux vanilla version: 2.6.21-rc6 (however I noticed that > problem since Linux ver. 2.6.15, doesn't matter if that was vanilla > kernel or from Debian distro), Here my sys info: Please reproduce and provide a new crash dump without the nvidia binary-only module loaded. Thank you. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-08 6:47 ` David Miller @ 2007-04-08 20:15 ` Bartek 2007-04-10 9:19 ` Bartek 0 siblings, 1 reply; 21+ messages in thread From: Bartek @ 2007-04-08 20:15 UTC (permalink / raw) To: David Miller; +Cc: linux-kernel > Please reproduce and provide a new crash dump without the nvidia > binary-only module loaded. Hi again, Here is a new crash dump (I also removed vmnet and vmmon properitary modules), this time I also included a lspci output: Apr 8 21:47:21 localhost pppd[2114]: rcvd [proto=0xfc3b] bc d4 80 eb 43 62 d0 7e 6d 27 0a e0 22 e4 8d e6 3e f1 a3 10 39 c8 fd cb e7 23 db f1 cf a8 e0 4d ... Apr 8 21:47:21 localhost pppd[2114]: Unsupported protocol 0xfc3b received Apr 8 21:47:21 localhost pppd[2114]: sent [LCP ProtRej id=0x75 fc 3b bc d4 80 eb 43 62 d0 7e 6d 27 0a e0 22 e4 8d e6 3e f1 a3 10 39 c8 fd cb e7 23 db f1 cf a8 ...] Apr 8 21:47:22 localhost pppd[2114]: rcvd [proto=0xcd] f7 4e 69 54 c1 d2 82 d3 bf 1c 33 46 a1 ee 90 97 14 7c a7 23 9d 84 c3 d4 ff 6c ec 25 a7 65 a3 bd ... Apr 8 21:47:22 localhost pppd[2114]: Unsupported protocol 0xcd received Apr 8 21:47:22 localhost pppd[2114]: sent [LCP ProtRej id=0x76 00 cd f7 4e 69 54 c1 d2 82 d3 bf 1c 33 46 a1 ee 90 97 14 7c a7 23 9d 84 c3 d4 ff 6c ec 25 a7 65 ...] Apr 8 21:47:22 localhost kernel: skb_under_panic: text:f8c3cc0e len:1268 put:1 head:c399f800 data:c399f7ff tail:c399fcf3 end:c399fe00 dev:<NULL> Apr 8 21:47:22 localhost kernel: ------------[ cut here ]------------ Apr 8 21:47:22 localhost kernel: kernel BUG at net/core/skbuff.c:111! Apr 8 21:47:22 localhost kernel: invalid opcode: 0000 [#1] Apr 8 21:47:22 localhost kernel: Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs eeprom w83781d w83627hf hwmon_vid i2c_isa ide_generic snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc i2c_viapro snd_mpu401_uart i2c_core via_ircc snd_rawmidi snd_seq_device floppy snd serio_raw soundcore irda rtc psmouse via_agp agpgart crc_ccitt pcspkr evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan Apr 8 21:47:22 localhost kernel: CPU: 0 Apr 8 21:47:22 localhost kernel: EIP: 0060:[<c021b4d7>] Tainted: P VLI Apr 8 21:47:22 localhost kernel: EFLAGS: 00010096 (2.6.21-rc6 #3) Apr 8 21:47:22 localhost kernel: EIP is at skb_under_panic+0x59/0x5d Apr 8 21:47:22 localhost kernel: eax: 00000073 ebx: c399f800 ecx: 00000000 edx: 00000000 Apr 8 21:47:22 localhost kernel: esi: 00000000 edi: c399fcf5 ebp: c399fcf1 esp: c1ce5ed8 Apr 8 21:47:22 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Apr 8 21:47:22 localhost kernel: Process events/0 (pid: 3, ti=c1ce4000 task=dfd02030 task.ti=c1ce4000) Apr 8 21:47:22 localhost kernel: Stack: c02c47d0 f8c3cc0e 000004f4 00000001 c399f800 c399f7ff c399fcf3 c399fe00 Apr 8 21:47:22 localhost kernel: c02b7ed8 f7ef5600 000000ff f8c3cc13 ffffffff dfff5c20 c1fee800 00000208 Apr 8 21:47:22 localhost kernel: c1fee5ad c1fee4ad c1fee800 00000202 dfd7ce00 00000004 c1fee400 c1fee80c Apr 8 21:47:22 localhost kernel: Call Trace: Apr 8 21:47:22 localhost kernel: [<f8c3cc0e>] ppp_asynctty_receive+0x3b0/0x584 [ppp_async] Apr 8 21:47:22 localhost kernel: [<f8c3cc13>] ppp_asynctty_receive+0x3b5/0x584 [ppp_async] Apr 8 21:47:22 localhost kernel: [<c01eacd2>] flush_to_ldisc+0xe6/0x124 Apr 8 21:47:22 localhost kernel: [<c01eabec>] flush_to_ldisc+0x0/0x124 Apr 8 21:47:22 localhost kernel: [<c0122b7f>] run_workqueue+0x70/0x101 Apr 8 21:47:22 localhost kernel: [<c01230c8>] worker_thread+0x105/0x12e Apr 8 21:47:22 localhost kernel: [<c0114c86>] default_wake_function+0x0/0xc Apr 8 21:47:22 localhost kernel: [<c0122fc3>] worker_thread+0x0/0x12e Apr 8 21:47:23 localhost kernel: [<c012528c>] kthread+0xa0/0xc8 Apr 8 21:47:23 localhost kernel: [<c01251ec>] kthread+0x0/0xc8 Apr 8 21:47:23 localhost kernel: [<c0104657>] kernel_thread_helper+0x7/0x10 Apr 8 21:47:23 localhost kernel: ======================= Apr 8 21:47:23 localhost kernel: Code: 00 00 89 5c 24 14 8b 98 a0 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c 24 04 c7 04 24 d0 47 2c c0 89 44 24 08 e8 af c5 ef ff <0f> 0b eb fe 56 53 bb d8 7e 2b c0 83 ec 24 8b 70 14 85 f6 0f 45 Apr 8 21:47:23 localhost kernel: EIP: [<c021b4d7>] skb_under_panic+0x59/0x5d SS:ESP 0068:c1ce5ed8 Apr 8 21:48:01 localhost /USR/SBIN/CRON[6287]: (root) CMD (/usr/local/bin/pppd_test.sh) Apr 8 21:48:09 localhost pppd[2114]: No response to 5 echo-requests Apr 8 21:48:09 localhost pppd[2114]: Serial link appears to be disconnected. Apr 8 21:48:09 localhost pppd[2114]: Connect time 522.7 minutes. Apr 8 21:48:09 localhost pppd[2114]: Sent 57811374 bytes, received 186299345 bytes. Apr 8 21:48:09 localhost pppd[2114]: Script /etc/ppp/ip-down started (pid 6289) Apr 8 21:48:09 localhost pppd[2114]: sent [LCP TermReq id=0x77 "Peer not responding"] Apr 8 21:48:09 localhost pppd[2114]: Script /etc/ppp/ip-down finished (pid 6289), status = 0x0 Apr 8 21:48:12 localhost pppd[2114]: sent [LCP TermReq id=0x78 "Peer not responding"] Apr 8 21:48:15 localhost pppd[2114]: Connection terminated. Apr 8 21:49:04 localhost /usr/sbin/gpm[3303]: oops() invoked from gpm.c(159) Apr 8 21:49:04 localhost /usr/sbin/gpm[3303]: /dev/tty0: Input/output error Apr 8 21:49:17 localhost init: open(/dev/console): Input/output error Apr 8 21:49:17 localhost shutdown[6328]: shutting down for system reboot Apr 8 21:49:18 localhost init: Switching to runlevel: 6 Apr 8 21:49:27 localhost kernel: SysRq : Emergency Remount R/O The output of lspci -vvv 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none> Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: dda00000-dfafffff Prefetchable memory behind bridge: cd800000-dd8fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:06.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08) Subsystem: Compaq Computer Corporation NC3123 Fast Ethernet NIC (WOL) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (2000ns min, 14000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 12 Region 0: Memory at dffbf000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at d800 [size=64] Region 2: Memory at dfe00000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at dfd00000 [disabled] [size=1M] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge Subsystem: VIA Technologies, Inc. VT8233 PCI to ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1] Region 4: I/O ports at ff00 [size=16] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 5 Region 4: I/O ports at c800 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 5 Region 4: I/O ports at cc00 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:11.4 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 5 Region 4: I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 10) Subsystem: Micro-Star International Co., Ltd. KT266 onboard audio Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin C routed to IRQ 10 Region 0: I/O ports at d400 [size=256] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 01:00.0 VGA compatible controller: nVidia Corporation NV11DDR [GeForce2 MX 100 DDR/200 DDR] (rev b2) (prog-if 00 [VGA]) Subsystem: LeadTek Research Inc. Unknown device 2838 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (1250ns min, 250ns max) Interrupt: pin A routed to IRQ 11 Region 0: Memory at de000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M] Expansion ROM at dfaf0000 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [44] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none> Bartek ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-08 20:15 ` Bartek @ 2007-04-10 9:19 ` Bartek 2007-04-10 11:25 ` Jesper Juhl 0 siblings, 1 reply; 21+ messages in thread From: Bartek @ 2007-04-10 9:19 UTC (permalink / raw) To: linux-kernel > Apr 8 21:47:22 localhost kernel: EIP: 0060:[<c021b4d7>] > Tainted: P VLI Someone in private took me a noticed of a still tainted kernel. I didn't noticed that, I am sorry for that. I was sure that unloaded proprietary modules should resolve the problem. My fault. I will try to reproduce the crash again. Regards Bartek ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-10 9:19 ` Bartek @ 2007-04-10 11:25 ` Jesper Juhl 2007-04-12 5:18 ` Bartek 0 siblings, 1 reply; 21+ messages in thread From: Jesper Juhl @ 2007-04-10 11:25 UTC (permalink / raw) To: Bartek; +Cc: linux-kernel On 10/04/07, Bartek <poemann@gmail.com> wrote: > > Apr 8 21:47:22 localhost kernel: EIP: 0060:[<c021b4d7>] > > Tainted: P VLI > > Someone in private took me a noticed of a still tainted kernel. I > didn't noticed that, I am sorry for that. I was sure that unloaded > proprietary modules should resolve the problem. My fault. I will try > to reproduce the crash again. > It is not enough to unload proprietary modules. As long as they have ever been loaded at all the kernel is tainted. You need to ensure that the proprietary modules never get loaded at all. I guess you probably already worked that out, just wanted to point it out just in case :-) -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-10 11:25 ` Jesper Juhl @ 2007-04-12 5:18 ` Bartek 2007-04-12 5:43 ` Patrick McHardy 0 siblings, 1 reply; 21+ messages in thread From: Bartek @ 2007-04-12 5:18 UTC (permalink / raw) To: linux-kernel > It is not enough to unload proprietary modules. As long as they have > ever been loaded at all the kernel is tainted. > You need to ensure that the proprietary modules never get loaded at > all. I guess you probably already worked that out, just wanted to > point it out just in case :-) Hopefully, this time it my bug report should be ok :): Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 bf 44 cc ac 3b ... Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0x7689 received Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0x9 76 89 e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 bf 44 cc ...] Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0xda7d] 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc cd a6 8e d5 77 ... Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0xda7d received Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0xa da 7d 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc cd a6 8e ...] Apr 11 23:53:40 localhost kernel: skb_under_panic: text:f8c62c0e len:291 put:1 head:ddc94800 data:ddc947ff tail:ddc94922 end:ddc94e00 dev:<NULL> Apr 11 23:53:40 localhost kernel: ------------[ cut here ]------------ Apr 11 23:53:40 localhost kernel: kernel BUG at net/core/skbuff.c:111! Apr 11 23:53:40 localhost kernel: invalid opcode: 0000 [#1] Apr 11 23:53:40 localhost kernel: Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs fuse eeprom w83781d w83627hf hwmon_vid i2c_isa ide_generic parport_pc parport i2c_viapro floppy i2c_core serio_raw snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart via_ircc snd_rawmidi snd_seq_device irda rtc psmouse via_agp agpgart snd soundcore pcspkr crc_ccitt evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan Apr 11 23:53:40 localhost kernel: CPU: 0 Apr 11 23:53:40 localhost kernel: EIP: 0060:[<c021b4d7>] Not tainted VLI Apr 11 23:53:40 localhost kernel: EFLAGS: 00010096 (2.6.21-rc6 #3) Apr 11 23:53:40 localhost kernel: EIP is at skb_under_panic+0x59/0x5d Apr 11 23:53:40 localhost kernel: eax: 00000072 ebx: ddc94800 ecx: 00000000 edx: 00000000 Apr 11 23:53:40 localhost kernel: esi: 00000000 edi: ddc94924 ebp: ddc9491e esp: c1ce5ed8 Apr 11 23:53:40 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Apr 11 23:53:40 localhost kernel: Process events/0 (pid: 3, ti=c1ce4000 task=dfd02030 task.ti=c1ce4000) Apr 11 23:53:40 localhost kernel: Stack: c02c47d0 f8c62c0e 00000123 00000001 ddc94800 ddc947ff ddc94922 ddc94e00 Apr 11 23:53:40 localhost kernel: c02b7ed8 dfd23a60 000000ff f8c62c13 00000282 dfff5c20 f7e67c00 00000208 Apr 11 23:53:40 localhost kernel: f0e45d34 f0e45c34 f7e67c00 00000202 e0f7d600 00000006 f0e45c00 f7e67c0c Apr 11 23:53:40 localhost kernel: Call Trace: Apr 11 23:53:40 localhost kernel: [<f8c62c0e>] ppp_asynctty_receive+0x3b0/0x584 [ppp_async] Apr 11 23:53:40 localhost kernel: [<f8c62c13>] ppp_asynctty_receive+0x3b5/0x584 [ppp_async] Apr 11 23:53:40 localhost kernel: [<c01eacd2>] flush_to_ldisc+0xe6/0x124 Apr 11 23:53:40 localhost kernel: [<c01eabec>] flush_to_ldisc+0x0/0x124 Apr 11 23:53:40 localhost kernel: [<c0122b7f>] run_workqueue+0x70/0x101 Apr 11 23:53:40 localhost kernel: [<c01230c8>] worker_thread+0x105/0x12e Apr 11 23:53:40 localhost kernel: [<c0114c86>] default_wake_function+0x0/0xc Apr 11 23:53:40 localhost kernel: [<c0122fc3>] worker_thread+0x0/0x12e Apr 11 23:53:40 localhost kernel: [<c012528c>] kthread+0xa0/0xc8 Apr 11 23:53:40 localhost kernel: [<c01251ec>] kthread+0x0/0xc8 Apr 11 23:53:40 localhost kernel: [<c0104657>] kernel_thread_helper+0x7/0x10 Apr 11 23:53:40 localhost kernel: ======================= Apr 11 23:53:40 localhost kernel: Code: 00 00 89 5c 24 14 8b 98 a0 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c 24 04 c7 04 24 d0 47 2c c0 89 44 24 08 e8 af c5 ef ff <0f> 0b eb fe 56 53 bb d8 7e 2b c0 83 ec 24 8b 70 14 85 f6 0f 45 Apr 11 23:53:40 localhost kernel: EIP: [<c021b4d7>] skb_under_panic+0x59/0x5d SS:ESP 0068:c1ce5ed8 Apr 11 23:54:01 localhost /USR/SBIN/CRON[32147]: (root) CMD (/usr/local/bin/pppd_test.sh) Apr 11 23:54:31 localhost pppd[31289]: No response to 5 echo-requests Apr 11 23:54:31 localhost pppd[31289]: Serial link appears to be disconnected. Apr 11 23:54:31 localhost pppd[31289]: Connect time 34.0 minutes. Apr 11 23:54:31 localhost pppd[31289]: Sent 6451377 bytes, received 21004296 bytes. Apr 11 23:54:31 localhost pppd[31289]: Script /etc/ppp/ip-down started (pid 32149) Apr 11 23:54:31 localhost pppd[31289]: sent [LCP TermReq id=0xb "Peer not responding"] Apr 11 23:54:31 localhost pppd[31289]: Script /etc/ppp/ip-down finished (pid 32149), status = 0x0 Apr 11 23:54:34 localhost pppd[31289]: sent [LCP TermReq id=0xc "Peer not responding"] Apr 11 23:54:37 localhost pppd[31289]: Connection terminated. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-12 5:18 ` Bartek @ 2007-04-12 5:43 ` Patrick McHardy 2007-04-13 23:16 ` David Miller 0 siblings, 1 reply; 21+ messages in thread From: Patrick McHardy @ 2007-04-12 5:43 UTC (permalink / raw) To: Bartek; +Cc: linux-kernel, Linux Netdev List [-- Attachment #1: Type: text/plain, Size: 1193 bytes --] Bartek wrote: > Hopefully, this time it my bug report should be ok :): > > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6 > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 > bf 44 cc ac 3b ... > Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0x7689 received > Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0x9 76 89 > e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 > 0a 1c 87 59 bf 44 cc ...] > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0xda7d] 15 19 45 3c > e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc > cd a6 8e d5 77 ... > Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0xda7d received > Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0xa da 7d > 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 > 98 47 62 bc cd a6 8e ...] > Apr 11 23:53:40 localhost kernel: skb_under_panic: text:f8c62c0e > len:291 put:1 head:ddc94800 data:ddc947ff tail:ddc94922 end:ddc94e00 > dev:<NULL> It seems we fail to reserve enough headroom for the case buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. Can you try this patch please? [-- Attachment #2: x --] [-- Type: text/plain, Size: 841 bytes --] diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c index 933e2f3..c68e37f 100644 --- a/drivers/net/ppp_async.c +++ b/drivers/net/ppp_async.c @@ -890,6 +890,8 @@ ppp_async_input(struct asyncppp *ap, const unsigned char *buf, ap->rpkt = skb; } if (skb->len == 0) { + int headroom = 0; + /* Try to get the payload 4-byte aligned. * This should match the * PPP_ALLSTATIONS/PPP_UI/compressed tests in @@ -897,7 +899,10 @@ ppp_async_input(struct asyncppp *ap, const unsigned char *buf, * enough chars here to test buf[1] and buf[2]. */ if (buf[0] != PPP_ALLSTATIONS) - skb_reserve(skb, 2 + (buf[0] & 1)); + headroom += 2; + if (buf[0] & 1) + headroom += 1; + skb_reserve(skb, headroom); } if (n > skb_tailroom(skb)) { /* packet overflowed MRU */ ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-12 5:43 ` Patrick McHardy @ 2007-04-13 23:16 ` David Miller 2007-04-14 6:00 ` Herbert Xu ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: David Miller @ 2007-04-13 23:16 UTC (permalink / raw) To: kaber; +Cc: poemann, linux-kernel, netdev From: Patrick McHardy <kaber@trash.net> Date: Thu, 12 Apr 2007 07:43:39 +0200 > Bartek wrote: > > Hopefully, this time it my bug report should be ok :): > > > > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6 > > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 > > bf 44 cc ac 3b ... > > Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0x7689 received > > Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0x9 76 89 > > e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 > > 0a 1c 87 59 bf 44 cc ...] > > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0xda7d] 15 19 45 3c > > e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc > > cd a6 8e d5 77 ... > > Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0xda7d received > > Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0xa da 7d > > 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 > > 98 47 62 bc cd a6 8e ...] > > Apr 11 23:53:40 localhost kernel: skb_under_panic: text:f8c62c0e > > len:291 put:1 head:ddc94800 data:ddc947ff tail:ddc94922 end:ddc94e00 > > dev:<NULL> > > > It seems we fail to reserve enough headroom for the case > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > Can you try this patch please? Any confirmation of this fix yet? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-13 23:16 ` David Miller @ 2007-04-14 6:00 ` Herbert Xu 2007-04-14 16:49 ` Paul Mackerras 2007-04-15 10:45 ` Bartek 2 siblings, 0 replies; 21+ messages in thread From: Herbert Xu @ 2007-04-14 6:00 UTC (permalink / raw) To: David Miller; +Cc: kaber, poemann, linux-kernel, netdev, paulus David Miller <davem@davemloft.net> wrote: > >> It seems we fail to reserve enough headroom for the case >> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. >> >> Can you try this patch please? > > Any confirmation of this fix yet? FWIW the fix definitely looks correct (the bug has been there for years at least) and it does match the crash dump. In fact, there is only a single skb_push (the only thing that can generate an under panic) in ppp_async.c and this is the one that Patrick has fixed. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-13 23:16 ` David Miller 2007-04-14 6:00 ` Herbert Xu @ 2007-04-14 16:49 ` Paul Mackerras 2007-04-14 17:04 ` David Miller 2007-04-15 10:45 ` Bartek 2 siblings, 1 reply; 21+ messages in thread From: Paul Mackerras @ 2007-04-14 16:49 UTC (permalink / raw) To: David Miller; +Cc: kaber, poemann, linux-kernel, netdev David Miller writes: > > It seems we fail to reserve enough headroom for the case > > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > > > Can you try this patch please? > > Any confirmation of this fix yet? Indeed, ppp_async doesn't handle that case correctly. RFC 1662 says: The Control field is a single octet, which contains the binary sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the Poll/Final (P/F) bit set to zero. The use of other Control field values may be defined at a later time, or by prior agreement. Frames with unrecognized Control field values SHOULD be silently discarded. In what situation were we getting the frames that cause the problem? I didn't see the patch (the message that this is a reply to is the first one that I have seen in this thread), so I can't comment on it. Paul. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-14 16:49 ` Paul Mackerras @ 2007-04-14 17:04 ` David Miller 2007-04-14 17:10 ` Patrick McHardy 2007-04-15 0:50 ` Paul Mackerras 0 siblings, 2 replies; 21+ messages in thread From: David Miller @ 2007-04-14 17:04 UTC (permalink / raw) To: paulus; +Cc: kaber, poemann, linux-kernel, netdev From: Paul Mackerras <paulus@samba.org> Date: Sun, 15 Apr 2007 02:49:28 +1000 > I didn't see the patch (the message that this is a reply to is the > first one that I have seen in this thread), so I can't comment on it. Here is Patrick McHardy's patch: diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c index 933e2f3..c68e37f 100644 --- a/drivers/net/ppp_async.c +++ b/drivers/net/ppp_async.c @@ -890,6 +890,8 @@ ppp_async_input(struct asyncppp *ap, const unsigned char *buf, ap->rpkt = skb; } if (skb->len == 0) { + int headroom = 0; + /* Try to get the payload 4-byte aligned. * This should match the * PPP_ALLSTATIONS/PPP_UI/compressed tests in @@ -897,7 +899,10 @@ ppp_async_input(struct asyncppp *ap, const unsigned char *buf, * enough chars here to test buf[1] and buf[2]. */ if (buf[0] != PPP_ALLSTATIONS) - skb_reserve(skb, 2 + (buf[0] & 1)); + headroom += 2; + if (buf[0] & 1) + headroom += 1; + skb_reserve(skb, headroom); } if (n > skb_tailroom(skb)) { /* packet overflowed MRU */ ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-14 17:04 ` David Miller @ 2007-04-14 17:10 ` Patrick McHardy 2007-04-15 0:50 ` Paul Mackerras 1 sibling, 0 replies; 21+ messages in thread From: Patrick McHardy @ 2007-04-14 17:10 UTC (permalink / raw) To: David Miller; +Cc: paulus, poemann, linux-kernel, netdev David Miller wrote: > From: Paul Mackerras <paulus@samba.org> > Date: Sun, 15 Apr 2007 02:49:28 +1000 > > >>I didn't see the patch (the message that this is a reply to is the >>first one that I have seen in this thread), so I can't comment on it. > > > Here is Patrick McHardy's patch: > > [..] I haven't heard back from Bartek yet. In case the patch is correct, ppp_synctty seems to need the same fix. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-14 17:04 ` David Miller 2007-04-14 17:10 ` Patrick McHardy @ 2007-04-15 0:50 ` Paul Mackerras 2007-04-15 1:05 ` Paul Mackerras ` (2 more replies) 1 sibling, 3 replies; 21+ messages in thread From: Paul Mackerras @ 2007-04-15 0:50 UTC (permalink / raw) To: David Miller; +Cc: kaber, poemann, linux-kernel, netdev David Miller writes: > Here is Patrick McHardy's patch: So this doesn't change process_input_packet(), which treats the case where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and the RFC does envision the possibility of receiving frames where the control field has values other than 0x03. Therefore I think this patch is probably better. Could people try it out and let me know if it fixes the problem? Paul. diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c index 933e2f3..caabbc4 100644 --- a/drivers/net/ppp_async.c +++ b/drivers/net/ppp_async.c @@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap) /* check for address/control and protocol compression */ p = skb->data; - if (p[0] == PPP_ALLSTATIONS && p[1] == PPP_UI) { + if (p[0] == PPP_ALLSTATIONS) { /* chop off address/control */ - if (skb->len < 3) + if (p[1] != PPP_UI || skb->len < 3) goto err; p = skb_pull(skb, 2); } ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-15 0:50 ` Paul Mackerras @ 2007-04-15 1:05 ` Paul Mackerras 2007-04-19 20:07 ` David Miller 2007-04-18 12:42 ` Jarek Poplawski 2007-04-18 21:35 ` Herbert Xu 2 siblings, 1 reply; 21+ messages in thread From: Paul Mackerras @ 2007-04-15 1:05 UTC (permalink / raw) To: David Miller, kaber, poemann, linux-kernel, netdev I wrote: > So this doesn't change process_input_packet(), which treats the case > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of I meant "the second byte is NOT 0x03", of course. Paul. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-15 1:05 ` Paul Mackerras @ 2007-04-19 20:07 ` David Miller 0 siblings, 0 replies; 21+ messages in thread From: David Miller @ 2007-04-19 20:07 UTC (permalink / raw) To: paulus; +Cc: kaber, poemann, linux-kernel, netdev From: Paul Mackerras <paulus@samba.org> Date: Sun, 15 Apr 2007 11:05:53 +1000 > I wrote: > > > So this doesn't change process_input_packet(), which treats the case > > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of > > I meant "the second byte is NOT 0x03", of course. I've applied this patch, thanks Paul. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-15 0:50 ` Paul Mackerras 2007-04-15 1:05 ` Paul Mackerras @ 2007-04-18 12:42 ` Jarek Poplawski 2007-04-18 21:35 ` Herbert Xu 2 siblings, 0 replies; 21+ messages in thread From: Jarek Poplawski @ 2007-04-18 12:42 UTC (permalink / raw) To: Paul Mackerras; +Cc: David Miller, kaber, poemann, linux-kernel, netdev Hi, I didn't analyse this bug report but probably it is nearly connected with one of the bugs visible in a log from this submit: http://bugzilla.kernel.org/show_bug.cgi?id=8132 On 15-04-2007 02:50, Paul Mackerras wrote: > David Miller writes: > >> Here is Patrick McHardy's patch: > > So this doesn't change process_input_packet(), which treats the case > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of > 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and > the RFC does envision the possibility of receiving frames where the > control field has values other than 0x03. > > Therefore I think this patch is probably better. Could people try it > out and let me know if it fixes the problem? > > Paul. > > diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c > index 933e2f3..caabbc4 100644 > --- a/drivers/net/ppp_async.c > +++ b/drivers/net/ppp_async.c > @@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap) > > /* check for address/control and protocol compression */ > p = skb->data; > - if (p[0] == PPP_ALLSTATIONS && p[1] == PPP_UI) { > + if (p[0] == PPP_ALLSTATIONS) { > /* chop off address/control */ > - if (skb->len < 3) > + if (p[1] != PPP_UI || skb->len < 3) > goto err; > p = skb_pull(skb, 2); > } Let's look farther: > proto = p[0]; > if (proto & 1) { > /* protocol is compressed */ > skb_push(skb, 1)[0] = 0; BTW - about Patrick's patch: skb_push seems to be dependent here on the 1-st char of skb->data, if above (p[0] != PPP_ALLSTATIONS), but on the 3-rd char otherwise (after skb_pull). But, Patrick's patch reserves the place for this, looking always at 1-st char (buf[0]) independently of PPP_ALLSTATIONS char presence, or otherwise - always treating this char as protocol char. It looks safe because of PPP_ALLSTATION current value, but isn't too understandable. On the other hand, without any reservation in the ppp_async_input for the (buf[0] == PPP_ALLSTATIONS) case, probably 4-byte alignement isn't achieved as planned. > } else { > if (skb->len < 2) > goto err; > proto = (proto << 8) + p[1]; > if (proto == PPP_LCP) > async_lcp_peek(ap, p, skb->len, 1); > } > > /* queue the frame to be processed */ > skb->cb[0] = ap->state; > skb_queue_tail(&ap->rqueue, skb); > ap->rpkt = NULL; > ap->state = 0; > return; > > err: > /* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */ > ap->state = SC_PREV_ERROR; > if (skb) { > /* make skb appear as freshly allocated */ Probably this isn't always true and here the problem started... > skb_trim(skb, 0); > skb_reserve(skb, - skb_headroom(skb)); Isn't here lost e.g. NET_SKB_PAD probably reserved by dev_alloc_skb? On the other hand - this kind of pad can very good hide similar reservation problems in many other places - maybe it should be omitted or somehow counted in WARNs when some debugging options are active? Regards, Jarek P. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-15 0:50 ` Paul Mackerras 2007-04-15 1:05 ` Paul Mackerras 2007-04-18 12:42 ` Jarek Poplawski @ 2007-04-18 21:35 ` Herbert Xu 2007-04-19 8:49 ` Bartek 2007-04-19 11:41 ` Herbert Xu 2 siblings, 2 replies; 21+ messages in thread From: Herbert Xu @ 2007-04-18 21:35 UTC (permalink / raw) To: Paul Mackerras; +Cc: davem, kaber, poemann, linux-kernel, netdev Hi Paul: Paul Mackerras <paulus@samba.org> wrote: > > So this doesn't change process_input_packet(), which treats the case > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of > 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and > the RFC does envision the possibility of receiving frames where the > control field has values other than 0x03. Your fix is probably needed too. However, I think the issue that Patrick was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore we'd still have a problem there. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-18 21:35 ` Herbert Xu @ 2007-04-19 8:49 ` Bartek 2007-04-19 11:41 ` Herbert Xu 1 sibling, 0 replies; 21+ messages in thread From: Bartek @ 2007-04-19 8:49 UTC (permalink / raw) To: Herbert Xu; +Cc: Paul Mackerras, davem, kaber, linux-kernel, netdev > Your fix is probably needed too. However, I think the issue that Patrick > was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore > we'd still have a problem there. I tested Paul's patch for last few days and I think everything seems ok. The system is stable. Regards Bartek ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-18 21:35 ` Herbert Xu 2007-04-19 8:49 ` Bartek @ 2007-04-19 11:41 ` Herbert Xu 1 sibling, 0 replies; 21+ messages in thread From: Herbert Xu @ 2007-04-19 11:41 UTC (permalink / raw) To: Herbert Xu; +Cc: paulus, davem, kaber, poemann, linux-kernel, netdev Herbert Xu <herbert@gondor.apana.org.au> wrote: > > Paul Mackerras <paulus@samba.org> wrote: >> >> So this doesn't change process_input_packet(), which treats the case >> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is >> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of >> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and >> the RFC does envision the possibility of receiving frames where the >> control field has values other than 0x03. > > Your fix is probably needed too. However, I think the issue that Patrick > was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore > we'd still have a problem there. Nevermind, I mixed up != with == so your patch is all we need. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-13 23:16 ` David Miller 2007-04-14 6:00 ` Herbert Xu 2007-04-14 16:49 ` Paul Mackerras @ 2007-04-15 10:45 ` Bartek 2007-04-16 4:06 ` Patrick McHardy 2 siblings, 1 reply; 21+ messages in thread From: Bartek @ 2007-04-15 10:45 UTC (permalink / raw) To: linux-kernel 2007/4/14, David Miller <davem@davemloft.net>: > From: Patrick McHardy <kaber@trash.net> > Date: Thu, 12 Apr 2007 07:43:39 +0200 > > > It seems we fail to reserve enough headroom for the case > > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > > > Can you try this patch please? > > Any confirmation of this fix yet? I'm testing that patch, till now everything seems ok. Regards Bartek ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 2007-04-15 10:45 ` Bartek @ 2007-04-16 4:06 ` Patrick McHardy 0 siblings, 0 replies; 21+ messages in thread From: Patrick McHardy @ 2007-04-16 4:06 UTC (permalink / raw) To: Bartek; +Cc: linux-kernel Bartek wrote: > 2007/4/14, David Miller <davem@davemloft.net>: > >> From: Patrick McHardy <kaber@trash.net> >> Date: Thu, 12 Apr 2007 07:43:39 +0200 >> >> > It seems we fail to reserve enough headroom for the case >> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. >> > >> > Can you try this patch please? >> >> Any confirmation of this fix yet? > > > I'm testing that patch, till now everything seems ok. Please test Paul's patch instead and keep everyone CCed. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2007-04-19 20:07 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-04-07 18:11 kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6 Bartek 2007-04-08 6:47 ` David Miller 2007-04-08 20:15 ` Bartek 2007-04-10 9:19 ` Bartek 2007-04-10 11:25 ` Jesper Juhl 2007-04-12 5:18 ` Bartek 2007-04-12 5:43 ` Patrick McHardy 2007-04-13 23:16 ` David Miller 2007-04-14 6:00 ` Herbert Xu 2007-04-14 16:49 ` Paul Mackerras 2007-04-14 17:04 ` David Miller 2007-04-14 17:10 ` Patrick McHardy 2007-04-15 0:50 ` Paul Mackerras 2007-04-15 1:05 ` Paul Mackerras 2007-04-19 20:07 ` David Miller 2007-04-18 12:42 ` Jarek Poplawski 2007-04-18 21:35 ` Herbert Xu 2007-04-19 8:49 ` Bartek 2007-04-19 11:41 ` Herbert Xu 2007-04-15 10:45 ` Bartek 2007-04-16 4:06 ` Patrick McHardy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox