* Re: [BUGZILLA] network bugs
From: Avinash Ramanath @ 2007-10-04 16:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071004094731.04b2cfcc@freepuppy.rosehill>
Stephen,
Are there any bugs that I can look into?
I would like to get context of an area for a bug and then fix the issue.
Thanks,
Avinash.
On 10/4/07, Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> 68 bugs found.
> ID Assignee Status Resolution Version Summary
> 2803 ambx1@neo.rr.com ASSI 2.6.6 isa modem detected but does not initialize
> 3258 shemminger@osdl.org ASSI 2.4.27 or 2.6.8.1 kernel IP autoconfig with PCMCIA
> 4206 laforge@gnumonks.org ASSI 2.6.9 NAT/Masquerade not working
> 4595 kaber@trash.net ASSI 2.6.11 Error inserting ebt_ulog
> 4809 kaber@trash.net ASSI 2.6.12 AF_PACKET sockets ignore the SO_TIMESTAMP sockopt
> 4885 yoshfuji@linux-ipv6.org ASSI 2.6.12.2 IPv6 Route entry being wrongly removed
> 5088 acme@ghostprotocols.net NEW 2.6.x disable ECN per connection
> 5091 laforge@gnumonks.org NEW 2.6.10 connection tracking can give abnormal throughput result
> 5131 moin@blackhole.labs.rootshe... ASSI 2.6.13-rc3-mm1 Computer hangs when default-gw becomes unreachable
> 5248 laforge@gnumonks.org ASSI 2.4.33-pre1 Rapid loading and unloading of iptables modules gives oop...
> 5731 shemminger@osdl.org REOP 2.6.14 Zero-length write() does not generate a datagram on conne...
> 5999 laforge@gnumonks.org NEW 2.6.15.2 Iptables modules fail to load on Alpha arch
> 6036 other_other@kernel-bugs.osd... NEW 2.6.14.3-grsec mmap'ed write to socket hangs when connection remote end ...
> 6161 acme@ghostprotocols.net NEW 2.6.14 Modem Slow down speed 50% after kernel upgrade
> 6171 acme@ghostprotocols.net NEW 2.6.15 3c59x: netlink only updates online status each 60s
> 6187 acme@ghostprotocols.net NEW 2.6.16-git netlink: possible use after free in netlink_recvmsg
> 6197 kaber@trash.net NEW 2.6.15 and all ... unregister_netdevice: waiting for ppp9 to become free. Us...
> 6319 herbert@gondor.apana.org.au ASSI vanilla 2.6.16 ipsec tunnel asymmetrical mtu
> 6322 laforge@gnumonks.org NEW 2.6.17.4 Kernel Panic (tc filter delete panic)
> 6339 kaber@trash.net NEW 2.6.16 Wish: /proc or /sys-access to counters
> 6548 acme@ghostprotocols.net NEW 2.6.16.16 MPPE Encrypt Decrypt module bug.
> 6681 shemminger@osdl.org NEW 2.6.16-gentoo-r6 TC crash and rule freeze
> 6682 acme@ghostprotocols.net NEW 2.6.15.6 BUG: soft lockup detected on CPU#0! / ksoftirqd takse 100...
> 6830 acme@ghostprotocols.net NEW 2.6.9 Need a /proc to view IF-MIB counters not in /proc/net/dev
> 6917 acme@ghostprotocols.net NEW 2.6.18-rc2-git6 BUG: warning at net/core/dev.c:1171/skb_checksum_help()
> 6966 laforge@gnumonks.org NEW 2.6.17.6 ftp conntrack doesn't work
> 6998 yoshfuji@linux-ipv6.org NEW 2.6.17 rp_filter missing for ipv6
> 7058 laforge@gnumonks.org NEW 2.6.17.8 CONFIG_IP_ROUTE_FWMARK breaks rp_filter checks
> 7198 acme@ghostprotocols.net NEW 2.6.18 balance-alb bonding oops when disconnecting primary slave...
> 7202 acme@ghostprotocols.net NEW 2.6.17 sun happy meal ethernet driver problem
> 7512 samuel@sortiz.org ASSI 2.6.19-rc5 irda: sock_error in af_irda.c:irda_recvmsg_stream
> 7554 marcel@holtmann.org NEW 2.6.18 oops after insmod rfcomm and rmmod rfcomm
> 7709 acme@ghostprotocols.net NEW 2.6.19.1 Exposing the string field lengths of the ethtool_drvinfo ...
> 7732 other_other@kernel-bugs.osd... NEW 2.6.19.* System freeze every 10 days
> 7846 acme@ghostprotocols.net NEW 2.6.19.2 Strange trouble with samba and 2.6.19 kernel
> 7952 acme@ghostprotocols.net NEW 2.6.18 slattach only works every other time
> 7974 acme@ghostprotocols.net NEW 2.6.20 (bonding): scheduling while atomic
> 7983 yi.zhu@intel.com NEW 2.6.19.2 kernel BUG at kernel/workqueue.c:150!
> 8054 acme@ghostprotocols.net NEW 2.6.21-rc1 tipc_ref_discard tipc_deleteport locking dependency
> 8085 networking_netfilter-iptabl... NEW 2.6.20 performance drop in 2.6.20 (CONFIG_NF_CONNTRACK_SUPPORT)
> 8203 acme@ghostprotocols.net NEW 2.6.20.1 Race: a lock is expected before calling llc_conn_state_pr...
> 8215 shemminger@osdl.org REOP 2.6.20.1 A lock is expected before calling zero_fw_chain, but it ...
> 8218 acme@ghostprotocols.net NEW 2.6.20 8021q - Vlan - Tag lost/missing on base interface when sn...
> 8253 acme@ghostprotocols.net NEW 2.6.20-rc3 BUG: unable to handle kernel paging request at virtual ad...
> 8325 networking_netfilter-iptabl... NEW 2.6.19-1.2911.f... -j REDIRECT --to-ports 1000-1009, always first choosen
> 8338 networking_netfilter-iptabl... NEW 2.6.20.7 NAT of TCP connections broken
> 8382 yoshfuji@linux-ipv6.org NEW 2.6.20.9 2.6.20 cannot route packets outside tunnel
> 8474 acme@ghostprotocols.net NEW 2.6.20.11 regression failure, can't even ping modem
> 8525 romieu@fr.zoreil.com ASSI 2.6.20 Realtek RTL8168B does not initialize when rebooting from ...
> 8536 acme@ghostprotocols.net NEW 2.6.x Kernel drops UDP packets silently when reading from certa...
> 8561 acme@ghostprotocols.net NEW vanilla kernel ... list_add corruption. prev->next should be next (f7d28794)...
> 8654 acme@ghostprotocols.net NEW Linux version 2... possible connect() bug
> 8726 acme@ghostprotocols.net NEW 2.6.22 MSG_TRUNC not regarded in unix_dgram_recvmsg()
> 8732 romieu@fr.zoreil.com ASSI UBUNTU 7.04, PC... Samba - very slow -one way- speed on AMD 690
> 8736 acme@ghostprotocols.net NEW 2.6.22 New TC deadlock scenario
> 8754 yoshfuji@linux-ipv6.org NEW 2.6.20, 2.6.22 Kernel addrconf modifies MTU of non-kernel routes
> 8755 yoshfuji@linux-ipv6.org NEW 2.6.20, 2.6.22 "ip -6 route change " behaves like "ip -6 route add"
> 8766 acme@ghostprotocols.net NEW 2.6.20 802.1q VLAN stacking + REORDER_HDR is broken
> 8891 acme@ghostprotocols.net NEW 2.6.22.1 in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4 re...
> 8895 yoshfuji@linux-ipv6.org NEW 2.6.22.3 and al... An ioctl to delete an ipv6 tunnel leads to a kernel panic
> 8914 shemminger@osdl.org NEW 2.6.22.4 filter attached to prio qdisc breaks priomap handling of ...
> 8961 other_other@kernel-bugs.osd... NEW 2.6.22.3 BUG triggered by oidentd in netlink code
> 8962 shemminger@osdl.org REOP 2.6.23-rc4 sky2: network intermittently unavailable after ifdown/ifu...
> 8971 shemminger@osdl.org NEW 2.6.18.* - 2.6.... htb class delete causes kernelpanic and other htb bugs.
> 8996 acme@ghostprotocols.net NEW 2.6.22 atl1 driver cause kernel oops IF ram > 4Gyte and a lot of...
> 9077 rjwysocki@sisk.pl ASSI 2.6.23-rc6 build #301 failed for 2.6.23-rc6-g0d4cbb5 in linux/driver...
> 9079 other_other@kernel-bugs.osd... NEW 2.6.23-rc3 NETDEV WATCHDOG: eth0: transmit timed out
> 9080 rjwysocki@sisk.pl ASSI 2.6.23-rc2 Weird network problems with 2.6.23-rc2
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
From: Michael Wu @ 2007-10-04 16:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Daniel Drake, linville-2XuSBdqkA4R54TAoqtyWWQ,
johannes-cdvu00un1VgdHxzADdlk8Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071004085440.008216c6-s08KbqtN0aBORcJjwVk881hTQxXnIo14@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Thursday 04 October 2007 11:54, Stephen Hemminger wrote:
> Playing with the function pointer is a awkward way to do this. Shouldn't
> the state management flags be used instead (dormant, running, stop/wake)...
> I am concerned about races and dereferencing the NULL ptr.
This is all under RTNL and the pointer is only modified while the interface is
down.
-Michael Wu
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUGZILLA] network bugs
From: Stephen Hemminger @ 2007-10-04 16:57 UTC (permalink / raw)
To: Avinash Ramanath; +Cc: netdev
In-Reply-To: <abcd72470710040955u73b114b5la75a80e4f03bdc8a@mail.gmail.com>
On Thu, 4 Oct 2007 09:55:43 -0700
"Avinash Ramanath" <avinashr@gmail.com> wrote:
> Stephen,
>
> Are there any bugs that I can look into?
> I would like to get context of an area for a bug and then fix the issue.
>
> Thanks,
> Avinash.
>
Go look at the bug report on bugzilla and do what you can. No one
is going to complain if you can fix it :-) Even if you can't fix
it adding more information, test cases, etc would be helpful
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
From: Michael Wu @ 2007-10-04 17:11 UTC (permalink / raw)
To: John W. Linville
Cc: Michael Buesch, Daniel Drake, johannes, netdev, linux-wireless
In-Reply-To: <20071004151956.GE6037@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Thursday 04 October 2007 11:19, John W. Linville wrote:
> > The reason why BUG_ON exists is to catch bugs that happen, although
> > they Should Never Happen (tm) ;)
>
> Precisely.
No really, this bug will never happen. This is function is merely a helper
function which is called from interface removal code (where the interface
*has* to be down) or from changing the interface type (which ensures that the
interface is down first). There are an unlimited number of bugs which Should
Never Happen. That doesn't mean we should start adding BUG_ONs for every
single one of them. That gives some sort of protection against cosmic rays
flipping bits, but down here on earth, it's bloat.
-Michael Wu
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Bugzilla: open bug reports
From: Chuck Ebbert @ 2007-10-04 17:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20071004094426.5321af0e@freepuppy.rosehill>
On 10/04/2007 12:44 PM, Stephen Hemminger wrote:
> Bugzilla report of open bugs. Yes you could run it yourself but
> many of these bugs seem to be old and need some attention or work
> to get resolved.
>
> Would this be useful to regularly run/automate?
> What format?
Yes, run it. And add links to the bugs, or at least a generic
URL at the top so people can easily find them:
http://bugzilla.kernel.org/show_bug.cgi?id=<number>
NOTE:
In Firefox you can create "keyword" bookmarks:
Name: Kernel Bug
Location: http://bugzilla.kernel.org/show_bug.cgi?id=%s
Keyword: bz
Then you can type "bz <number>" in the address bar to go right to
the bug.
^ permalink raw reply
* netconsole problems
From: Tina Yang @ 2007-10-04 17:59 UTC (permalink / raw)
To: Matt Mackall, netdev
We recently run into a few problems with netconsole
in at least 2.6.9, 2.6.18 and 2.6.23. It either panicked
at netdevice.h:890 or hung the system, and sometimes depending
on which NIC we are using, the following console message,
e1000:
"e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang"
tg3:
"NETDEV WATCHDOG: eth4: transmit timed out"
"tg3: eth4: transmit timed out, resetting"
The postmortem vmcore analysis indicated race between normal
network stack (net_rx_action) and netpoll, and disabling the
following code segment cures all the problems.
netpoll.c
178 /* Process pending work on NIC */
179 np->dev->poll_controller(np->dev);
180 if (np->dev->poll)
181 poll_napi(np);
Big or small, there seems to be several race windows in the code,
and fixing them probably has consequence on overall system performance.
Maybe this code should only run when the machine is single-threaded ?
Suggestions ? Thanks.
^ permalink raw reply
* Vague maybe ppp-related panic report for 2.6.23-rc9
From: Roland Dreier @ 2007-10-04 18:12 UTC (permalink / raw)
To: linux-kernel, netdev
I'm running 2.6.23-rc9 on my laptop, and when in a coffee shop I use
a Verizon EVDO card to get network access. This is a kyocera device
that looks like a serial adapter behind an ohci usb controller, and
uses the airprime driver (for usb device 0c88:17da). The actual IP
networking is ppp over that serial adapter.
The connection is slightly flaky (I blame this on the Verizon
coverage), so I end up restarting things every so often. The point of
this email (at last) is that I've just seen my second panic (only
info: blinking caps lock led, since I've been in X) that seems
correlated to stopping/restarting pppd.
Sorry for the lack of detail -- I've just switched to running in the
console so if I can provoke the crash again I'll get a little more
info. I just wanted to mention this in case someone has seen
something similar or has any good ideas about how to capture debugging
output on a laptop (when I'm not home and have no other boxes handy).
- R.
^ permalink raw reply
* Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
From: Johannes Berg @ 2007-10-04 18:12 UTC (permalink / raw)
To: Michael Wu; +Cc: Daniel Drake, linville, netdev, linux-wireless
In-Reply-To: <200710041034.48533.flamingice@sourmilk.net>
[-- Attachment #1: Type: text/plain, Size: 780 bytes --]
On Thu, 2007-10-04 at 10:34 -0400, Michael Wu wrote:
> On Thursday 04 October 2007 07:33, Daniel Drake wrote:
> > Fix this by unsetting the hard_start_xmit handler in ieee80211_if_reinit.
> > It will then be reinitialised to the default (ieee80211_subif_start_xmit)
> > in ieee80211_if_set_type.
> >
> Well.. this kinda sucks, but we can clean up the logic here later.
I kinda agree, but the hack in 50e1f4d76a9d45c940733f05ccd42c5bbe6ca132
which caused this was is hack too. Somebody really need to rewrite the
whole interface handling, it's a total mess with the master being
specially treated but initialised by the same functions etc. I think we
should start having a IEEE80211_IF_TYPE_MASTER for this, maybe then
things will fall into place nicer.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: PROBLEM: system freezes on starting ne2k-pci + bridge
From: Mirko Parthey @ 2007-10-04 18:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <20071002141217.GA23610@stilzchen.informatik.tu-chemnitz.de>
On Tue, Oct 02, 2007 at 04:12:17PM +0200, I wrote:
> On a machine running Debian testing, I get complete lockups
> (Num lock LED not responding anymore)
>
> Kernel versions tried (all of them show this problem):
> - linux-image-2.6.18-5-amd64 (Debian etch)
> - linux-image-2.6.22-2-amd64 (Debian testing)
> - plain kernel.org 2.6.23-rc8-git4 (with allmodconfig and ATKBD=y)
>
> The 2.6.18 kernel sometimes prints
> Losing some ticks ... checking if CPU frequency changed.
> Your time source seems to be instable or some driver is hogging
> interrupts.
> rip __do_softirq + 0x53/0xd5
> before freezing.
I was able to narrow this down a bit - the problem can be reproduced with
the ne2k-pci driver alone, sky2 is not needed.
Powering off isn't necessary, either.
Hardware preparation:
- eth0: Compex ReadyLink 2000 (BNC+TP), ne2k-pci driver,
network cable disconnected
How to reproduce the problem:
brctl addbr br0
brctl addif br0 eth0
ifconfig eth0 0 up
ifconfig br0 192.168.1.17 up
sync
find / >/dev/null &
ping -b 192.168.1.255
This will lock up my system, usually within a few seconds.
Some additional information:
- I could not reproduce the problem when using eth0 directly,
without a bridge.
- Booting with "maxcpus=1" does not help, the problem remains.
My system doesn't boot with "nosmp", otherwise I would have
tried this too.
- Mainboard: Gigabyte GA-965P-S3
- /proc/cpuinfo:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
stepping : 6
cpu MHz : 2133.394
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4269.87
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz
stepping : 6
cpu MHz : 2133.394
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 4267.07
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
- /proc/interrupts:
CPU0 CPU1
0: 46738 0 IO-APIC-edge timer
1: 690 0 IO-APIC-edge i8042
7: 0 0 IO-APIC-edge parport0
8: 0 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 4 0 IO-APIC-edge i8042
16: 25552 0 IO-APIC-fasteoi uhci_hcd:usb1, ide0, radeon@pci:0000:01:00.0
18: 2 0 IO-APIC-fasteoi uhci_hcd:usb5, ehci_hcd:usb6
19: 15146 0 IO-APIC-fasteoi uhci_hcd:usb4, libata, libata, ahci, eth0
20: 3 0 IO-APIC-fasteoi bttv0, Bt87x audio
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 192 0 IO-APIC-fasteoi HDA Intel
23: 5009 0 IO-APIC-fasteoi uhci_hcd:usb3, ehci_hcd:usb7
NMI: 0 0
LOC: 46261 46240
ERR: 0
- /proc/ioports:
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0378-037a : parport0
03c0-03df : vga+
03f8-03ff : serial
0400-047f : 0000:00:1f.0
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0428-042f : ACPI GPE0_BLK
0460-047f : iTCO_wdt
0480-04bf : 0000:00:1f.0
0500-051f : 0000:00:1f.3
0500-051f : i801_smbus
0778-077a : parport0
0cf8-0cff : PCI conf1
4000-4fff : PCI Bus #02
5000-5fff : PCI Bus #01
5000-50ff : 0000:01:00.0
6000-7fff : PCI Bus #03
6000-6007 : 0000:03:00.1
6000-6007 : ide0
6400-6403 : 0000:03:00.1
6402-6402 : ide0
6800-6807 : 0000:03:00.1
6c00-6c03 : 0000:03:00.1
7000-700f : 0000:03:00.1
7000-7007 : ide0
7008-700f : ide1
8000-8fff : PCI Bus #04
8000-80ff : 0000:04:00.0
9000-9fff : PCI Bus #05
9000-901f : 0000:05:01.0
9000-901f : ne2k-pci
9400-947f : 0000:05:02.0
a000-a01f : 0000:00:1a.1
a000-a01f : uhci_hcd
a400-a41f : 0000:00:1d.0
a400-a41f : uhci_hcd
a800-a81f : 0000:00:1d.1
a800-a81f : uhci_hcd
ac00-ac1f : 0000:00:1d.2
ac00-ac1f : uhci_hcd
b000-b01f : 0000:00:1a.0
b000-b01f : uhci_hcd
b400-b407 : 0000:00:1f.2
b400-b407 : libata
b800-b803 : 0000:00:1f.2
b800-b803 : libata
bc00-bc07 : 0000:00:1f.2
bc00-bc07 : libata
c000-c003 : 0000:00:1f.2
c000-c003 : libata
c400-c40f : 0000:00:1f.2
c400-c40f : libata
c800-c80f : 0000:00:1f.2
d000-d007 : 0000:00:1f.5
d000-d007 : libata
d400-d403 : 0000:00:1f.5
d400-d403 : libata
d800-d807 : 0000:00:1f.5
d800-d807 : libata
dc00-dc03 : 0000:00:1f.5
dc00-dc03 : libata
e000-e00f : 0000:00:1f.5
e000-e00f : libata
e400-e40f : 0000:00:1f.5
- /proc/iomem:
00000000-0009f7ff : System RAM
00000000-00000000 : Crash kernel
0009f800-0009ffff : reserved
000d2800-000d3fff : pnp 00:0b
000f0000-000fffff : reserved
00100000-7fedffff : System RAM
00200000-003f6749 : Kernel code
003f674a-004e2b7f : Kernel data
7fee0000-7fee2fff : ACPI Non-volatile Storage
7fee3000-7feeffff : ACPI Tables
7fef0000-7fefffff : reserved
80000000-800fffff : PCI Bus #04
80000000-8001ffff : 0000:04:00.0
e0000000-e7ffffff : PCI Bus #01
e0000000-e7ffffff : 0000:01:00.0
e8000000-ebffffff : reserved
ec000000-edffffff : PCI Bus #01
ec000000-ec01ffff : 0000:01:00.0
ed000000-ed00ffff : 0000:01:00.0
ed010000-ed01ffff : 0000:01:00.1
ee000000-efffffff : PCI Bus #04
ef000000-ef003fff : 0000:04:00.0
f0000000-f1ffffff : PCI Bus #05
f1000000-f100007f : 0000:05:02.0
f2000000-f20fffff : PCI Bus #03
f2000000-f2001fff : 0000:03:00.0
f2000000-f2001fff : ahci
f2100000-f21fffff : PCI Bus #05
f2100000-f2100fff : 0000:05:00.0
f2100000-f2100fff : bttv0
f2101000-f2101fff : 0000:05:00.1
f2101000-f2101fff : Bt87x audio
f2108000-f210ffff : 0000:05:01.0
f2120000-f213ffff : 0000:05:02.0
f2200000-f2203fff : 0000:00:1b.0
f2200000-f2203fff : ICH HD audio
f2204000-f22043ff : 0000:00:1a.7
f2204000-f22043ff : ehci_hcd
f2205000-f22053ff : 0000:00:1d.7
f2205000-f22053ff : ehci_hcd
f2206000-f22060ff : 0000:00:1f.3
fec00000-fec00fff : IOAPIC 0
fee00000-fee00fff : Local APIC
- # lspci -s 5:1 -vvv
05:01.0 Ethernet controller: Compex ReadyLink 2000 (rev 0a)
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 A routed to IRQ 19
Region 0: I/O ports at 9000 [size=32]
[virtual] Expansion ROM at f2108000 [disabled] [size=32K]
- ver_linux output:
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux guitar2 2.6.22-2-amd64 #1 SMP Thu Aug 30 23:43:59 UTC 2007 x86_64 GNU/Linux
Gnu C 4.2.1
Gnu make 3.81
binutils Binutils
util-linux 2.12r
mount 2.12r
module-init-tools 3.3-pre11
e2fsprogs 1.40.2
Linux C Library 6.1
Dynamic linker (ldd) 2.6.1
Procps 3.2.7
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.97
udev 114
wireless-tools 29
Modules Loaded radeon drm nfsd exportfs ppdev lp button ac battery cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative cpufreq_stats freq_table nfs lockd nfs_acl sunrpc ipv6 bridge ext2 nls_iso8859_1 nls_cp437 vfat fat loop snd_bt87x bt878 snd_hda_intel snd_pcm_oss snd_pcm snd_mixer_oss tuner snd_seq_dummy tvaudio msp3400 snd_seq_oss bttv snd_seq_midi video_buf firmware_class snd_rawmidi ir_common snd_seq_midi_event compat_ioctl32 i2c_algo_bit i2c_i801 btcx_risc iTCO_wdt snd_seq tveeprom parport_pc parport videodev i2c_core serio_raw psmouse snd_timer snd_seq_device v4l2_common v4l1_compat pcspkr snd soundcore snd_page_alloc intel_agp tsdev evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_cd cdrom sd_mod usbhid hid generic usb_storage jmicron ide_core a
hci ne2k_pci 8390 ata_piix ata_generic libata scsi_mod ehci_hcd uhci_hcd thermal processor fan
Regards,
Mirko
^ permalink raw reply
* [PATCH] ethtool: Add e1000e reg dump support (using e1000 decode function)
From: Auke Kok @ 2007-10-04 18:37 UTC (permalink / raw)
To: jeff; +Cc: netdev
The e1000 register dump code can print out e1000e register dump
information as well, so enable it for e1000e devices.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
ethtool.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 651529e..6c7a2e3 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1003,6 +1003,7 @@ static struct {
{ "r8169", realtek_dump_regs },
{ "de2104x", de2104x_dump_regs },
{ "e1000", e1000_dump_regs },
+ { "e1000e", e1000_dump_regs },
{ "igb", igb_dump_regs },
{ "ixgb", ixgb_dump_regs },
{ "ixgbe", ixgbe_dump_regs },
^ permalink raw reply related
* Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
From: John W. Linville @ 2007-10-04 18:07 UTC (permalink / raw)
To: Daniel Drake; +Cc: johannes, netdev, linux-wireless
In-Reply-To: <20071004113343.552139D502B@zog.reactivated.net>
On Thu, Oct 04, 2007 at 12:33:43PM +0100, Daniel Drake wrote:
> Fix this by unsetting the hard_start_xmit handler in ieee80211_if_reinit. It
> will then be reinitialised to the default (ieee80211_subif_start_xmit) in
> ieee80211_if_set_type.
I think I'd rather fix this by making the check in
ieee80211_if_set_type more explicit for master devices. Patch to
follow.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [PATCH] ieee80211_if_set_type: make check for master dev more explicit
From: John W. Linville @ 2007-10-04 18:09 UTC (permalink / raw)
To: Daniel Drake; +Cc: johannes, netdev, linux-wireless
In-Reply-To: <20071004113343.552139D502B@zog.reactivated.net>
Problem description by Daniel Drake <dsd@gentoo.org>:
"This sequence of events causes loss of connectivity:
<plug in>
<associate as normal in managed mode>
ifconfig eth7 down
iwconfig eth7 mode monitor
ifconfig eth7 up
ifconfig eth7 down
iwconfig eth7 mode managed
<associate as normal>
At this point you are associated but TX does not work. This is because
the eth7 hard_start_xmit is still ieee80211_monitor_start_xmit."
The problem is caused by ieee80211_if_set_type checking for a non-zero
hard_start_xmit pointer value in order to avoid changing that value for
master devices. The fix is to make that check more explicitly linked to
master devices rather than simply checking if the value has been
previously set.
CC: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/ieee80211_iface.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/ieee80211_iface.c b/net/mac80211/ieee80211_iface.c
index be7e77f..6607b80 100644
--- a/net/mac80211/ieee80211_iface.c
+++ b/net/mac80211/ieee80211_iface.c
@@ -106,7 +106,7 @@ void ieee80211_if_set_type(struct net_device *dev, int type)
* which already has a hard_start_xmit routine assigned
* which must not be changed.
*/
- if (!dev->hard_start_xmit)
+ if (dev->type != ARPHRD_IEEE80211)
dev->hard_start_xmit = ieee80211_subif_start_xmit;
/*
--
1.5.2.4
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
From: John W. Linville @ 2007-10-04 18:15 UTC (permalink / raw)
To: Michael Wu; +Cc: Michael Buesch, Daniel Drake, johannes, netdev, linux-wireless
In-Reply-To: <200710041311.37997.flamingice@sourmilk.net>
On Thu, Oct 04, 2007 at 01:11:33PM -0400, Michael Wu wrote:
> On Thursday 04 October 2007 11:19, John W. Linville wrote:
> > > The reason why BUG_ON exists is to catch bugs that happen, although
> > > they Should Never Happen (tm) ;)
> >
> > Precisely.
> No really, this bug will never happen. This is function is merely a helper
> function which is called from interface removal code (where the interface
> *has* to be down) or from changing the interface type (which ensures that the
> interface is down first). There are an unlimited number of bugs which Should
> Never Happen. That doesn't mean we should start adding BUG_ONs for every
> single one of them. That gives some sort of protection against cosmic rays
> flipping bits, but down here on earth, it's bloat.
Falling back on bloat as an argument against a BUG_ON in a
configuration path seems a bit weak. :-)
Programming with assertions (and BUG_ON is a form of that) is
generally a good practice. Almost any book or other source on
good programming practices will agree. Yes, it can be overdone.
But I don't really think that is the case here, since the check is
relatively inexpensive and the consequence should it ever *somehow*
happen could be a something wierd (crash, corruption, etc) w/o any
other indication of what occured.
Anyway, the point is probably moot in this case if there is no great
objection to the alternative patch I proposed.
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [PATCH] e1000e: fix debugging printout code
From: Auke Kok @ 2007-10-04 18:38 UTC (permalink / raw)
To: jeff; +Cc: netdev
A small bug crawled in the -DDEBUG enabled code. Fix this to
properly call the backreference device name.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/hw.h | 2 +-
drivers/net/e1000e/netdev.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
index 848217a..aa82f1a 100644
--- a/drivers/net/e1000e/hw.h
+++ b/drivers/net/e1000e/hw.h
@@ -852,7 +852,7 @@ struct e1000_hw {
#ifdef DEBUG
#define hw_dbg(hw, format, arg...) \
- printk(KERN_DEBUG, "%s: " format, e1000_get_hw_dev_name(hw), ##arg);
+ printk(KERN_DEBUG, "%s: " format, e1000e_get_hw_dev_name(hw), ##arg);
#else
static inline int __attribute__ ((format (printf, 2, 3)))
hw_dbg(struct e1000_hw *hw, const char *format, ...)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 4a21d7d..3a0bb2a 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -66,9 +66,7 @@ static const struct e1000_info *e1000_info_tbl[] = {
**/
char *e1000e_get_hw_dev_name(struct e1000_hw *hw)
{
- struct e1000_adapter *adapter = hw->back;
- struct net_device *netdev = adapter->netdev;
- return netdev->name;
+ return hw->adapter->netdev->name;
}
#endif
^ permalink raw reply related
* Re: [PATCH] ieee80211_if_set_type: make check for master dev more explicit
From: Johannes Berg @ 2007-10-04 18:44 UTC (permalink / raw)
To: John W. Linville; +Cc: Daniel Drake, netdev, linux-wireless
In-Reply-To: <20071004180900.GG6037@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
On Thu, 2007-10-04 at 14:09 -0400, John W. Linville wrote:
> --- a/net/mac80211/ieee80211_iface.c
> +++ b/net/mac80211/ieee80211_iface.c
> @@ -106,7 +106,7 @@ void ieee80211_if_set_type(struct net_device *dev, int type)
> * which already has a hard_start_xmit routine assigned
> * which must not be changed.
> */
> - if (!dev->hard_start_xmit)
> + if (dev->type != ARPHRD_IEEE80211)
> dev->hard_start_xmit = ieee80211_subif_start_xmit;
That should work as well although I think you should update the comment
above :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* wireless-dev dead, long live wireless-2.6
From: John W. Linville @ 2007-10-04 18:47 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev
Greetings,
This message is perhaps a few days late -- better late than never. :-)
The big news is that wireless-dev is now dead, defunct, kaput.
Please discontinue any use of wireless-dev or any of its clones.
If you need access to the contents of that tree for historical
purposes, please see the snapshot in my wireless-legacy tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-legacy.git wireless-dev-2007-09-24
I will remove the wireless-dev repository from kernel.org shortly
after sending this message. From now on, please use the 'everything'
branch of wireless-2.6 as the base for new wireless development.
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git everything
Please note that this branch is subject to rebasing. In general
it will be rebased whenever Linus christens a new -rcX release,
sometimes more often than that. "git rebase" and "git cherry-pick"
are your friends.
As always, patches based on a vanilla tree from Linus (or the
'master' branch of wireless-2.6) are acceptable or even preferable
for those patches which do not depend on other pathes already in the
wireless-2.6 tree. Otherwise, base your patches on the 'everything'
branch as described above.
Most of the other branches in wireless-2.6 are only there for
administrative purposes. You can and should ignore them, with possibly
a couple of exceptions.
One of two possible branches of interest to some is the
'mac80211-attic' branch. This branch mostly contains patches
supporting hostap functionality for mac80211. These patches will
not be merged as-is due to unsettled user interface issues. I have
preserved them on this branch solely as a courtesy to those who need
this functionality. I expect for this functionality to be replaced
RSN by work underway from Johannes Berg.
The other possible branch of interest is the 'mac80211-dungeon'
branch. This branch contains several patches for 802.11n and other
advanced functionality (e.g. DLS). However, the mac80211 component
maintainers have strongly objected to these patches for a variety
of reasons. The various parties are still working to resolve the
issues preventing these patches from being merged. In the meantime
I have preserved these patches on this branch as a courtesy to those
who need them as well.
I hope this message clears-up some questions that people have been
expressing. If there are other questions, please feel free to ask.
Thanks!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] ieee80211_if_set_type: make check for master dev more explicit
From: John W. Linville @ 2007-10-04 19:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Daniel Drake, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1191523488.7367.16.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Thu, Oct 04, 2007 at 08:44:48PM +0200, Johannes Berg wrote:
> On Thu, 2007-10-04 at 14:09 -0400, John W. Linville wrote:
>
> > --- a/net/mac80211/ieee80211_iface.c
> > +++ b/net/mac80211/ieee80211_iface.c
> > @@ -106,7 +106,7 @@ void ieee80211_if_set_type(struct net_device *dev, int type)
> > * which already has a hard_start_xmit routine assigned
> > * which must not be changed.
> > */
> > - if (!dev->hard_start_xmit)
> > + if (dev->type != ARPHRD_IEEE80211)
> > dev->hard_start_xmit = ieee80211_subif_start_xmit;
>
> That should work as well although I think you should update the comment
> above :)
The comment still seem applicable. How would you word it?
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply
* [PATCH net-2.6.24] [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed
From: Ilpo Järvinen @ 2007-10-04 20:20 UTC (permalink / raw)
To: Cedric Le Goater, David Miller; +Cc: Netdev
In-Reply-To: <4704FE75.2030104@fr.ibm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2784 bytes --]
On Thu, 4 Oct 2007, Cedric Le Goater wrote:
> so here are the results on a net-2.6.24 kernel.
>
> I've put the patchset here to make sure it's correct:
>
> http://legoater.free.fr/patches/2.6.23/net-2.6.24.git-tcp_fastretrans/
>
> and plenty of logs :
>
> http://legoater.free.fr/patches/2.6.23/net-2.6.24.git-tcp_fastretrans.messages
Thanks a lot, the bug itself seems to occur far more common than I
thought... It just very rarely manifests in significant behavior (requires
non-trivial ACK/SACK pattern to occur). This same bug is present in the
soon to be released 2.6.23 and in stable too though it's nearly impossible
to ever see that by human eye and there's a silent fackets_out "fix up" in
place due to known (and intentional) fackets_out inaccuracy (and nobody is
really looking that large number of TCP traces)...
The fix below, you can test it with the debug patch quite easily, all
those messages should of course vanish :-). In case you want to
test, please mix those three patches (fixes a real bug too), this one and
the debug patch together...
Dave should apply both the three patch series fix and this one as well to
net-2.6.24 (Dave, in case you want me to resubmit, just ask... :-)). I'll
send one against .23-rc9 soon after this (sadly enough, it will cause a
conflict...).
--
i.
[PATCH net-2.6.24] [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed
I used to be under impression that all hints are cleared in
clean_rtx_queue whenever cumulative ACKs occur. Yet, when only
GSO skb was partially ACKed, no hints were reset, therefore
fastpath_cnt_hint must be tweaked too or else it can corrupt
fackets_out. In case there was also a skb that got fully ACKed,
the fastpath_skb_hint is set to NULL which causes a recount for
fastpath_cnt_hint (the old value won't be accessed anymore),
thus it can safely be decremented without additional checking.
Reported by Cedric Le Goater <clg@fr.ibm.com>, two other bugs
have been already found and patched due to that report, and
third one (unrelated to this fix) is under evaluation
currently :-)...
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 87c9ef5..4268cd1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2674,6 +2674,9 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p)
tcp_rearm_rto(sk);
tp->fackets_out -= min(pkts_acked, tp->fackets_out);
+ /* hint's skb might be NULL but we don't need to care */
+ tp->fastpath_cnt_hint -= min_t(u32, pkts_acked,
+ tp->fastpath_cnt_hint);
if (tcp_is_reno(tp))
tcp_remove_reno_sacks(sk, pkts_acked);
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2.6.23-rc9] [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed
From: Ilpo Järvinen @ 2007-10-04 20:38 UTC (permalink / raw)
To: David Miller; +Cc: Netdev, Cedric Le Goater
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1585 bytes --]
When only GSO skb was partially ACKed, no hints are reset,
therefore fastpath_cnt_hint must be tweaked too or else it can
corrupt fackets_out. The corruption to occur, one must have
non-trivial ACK/SACK sequence, so this bug is not very often
that harmful. There's a fackets_out state reset in TCP because
fackets_out is known to be inaccurate and that fixes the issue
eventually anyway.
In case there was also at least one skb that got fully ACKed,
the fastpath_skb_hint is set to NULL which causes a recount for
fastpath_cnt_hint (the old value won't be accessed anymore),
thus it can safely be decremented without additional checking.
Reported by Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
Dave, here's the same fix to upcoming 2.6.23, hopefully it can
make it in time. Probably minor enough to skip stable-2.6.22,
especially since 2.6.23 is soooo close :-), but I leave that
up to you.
net/ipv4/tcp_input.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index bbad2cd..f893e90 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2420,6 +2420,9 @@ static int tcp_tso_acked(struct sock *sk, struct sk_buff *skb,
__u32 dval = min(tp->fackets_out, packets_acked);
tp->fackets_out -= dval;
}
+ /* hint's skb might be NULL but we don't need to care */
+ tp->fastpath_cnt_hint -= min_t(u32, packets_acked,
+ tp->fastpath_cnt_hint);
tp->packets_out -= packets_acked;
BUG_ON(tcp_skb_pcount(skb) == 0);
--
1.5.0.6
^ permalink raw reply related
* [PATCH] net: fix kernel_accept() error path
From: Tony Battersby @ 2007-10-04 20:20 UTC (permalink / raw)
To: netdev, davem
If accept() returns an error, kernel_accept() releases the new socket
but passes a pointer to the released socket back to the caller. Make it
pass back NULL instead.
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
---
--- linux-2.6.23-rc9/net/socket.c.bak 2007-10-04 15:21:17.000000000 -0400
+++ linux-2.6.23-rc9/net/socket.c 2007-10-04 15:21:22.000000000 -0400
@@ -2230,6 +2230,7 @@ int kernel_accept(struct socket *sock, s
err = sock->ops->accept(sock, *newsock, flags);
if (err < 0) {
sock_release(*newsock);
+ *newsock = NULL;
goto done;
}
^ permalink raw reply
* Re: Vague maybe ppp-related panic report for 2.6.23-rc9
From: David Miller @ 2007-10-04 20:51 UTC (permalink / raw)
To: rdreier; +Cc: linux-kernel, netdev, herbert
In-Reply-To: <ada4ph6da05.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Thu, 04 Oct 2007 11:12:42 -0700
> Sorry for the lack of detail -- I've just switched to running in the
> console so if I can provoke the crash again I'll get a little more
> info. I just wanted to mention this in case someone has seen
> something similar or has any good ideas about how to capture debugging
> output on a laptop (when I'm not home and have no other boxes handy).
I don't want to jump the gun on the analysis but it just might
be the packet sharing fixes Herbert put in a short time ago.
What you could do is go back to say rc2 and see if you still get
the panics, then bisect from there to narrow it down.
If rc2 still gives the panic, it's something else, perhaps device
specific.
^ permalink raw reply
* Re: Vague maybe ppp-related panic report for 2.6.23-rc9
From: Roland Dreier @ 2007-10-04 20:53 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, herbert
In-Reply-To: <20071004.135113.48807663.davem@davemloft.net>
> I don't want to jump the gun on the analysis but it just might
> be the packet sharing fixes Herbert put in a short time ago.
>
> What you could do is go back to say rc2 and see if you still get
> the panics, then bisect from there to narrow it down.
>
> If rc2 still gives the panic, it's something else, perhaps device
> specific.
OK thanks. I'm still trying to find a good way to reproduce it, so
I'm going to try to get it to happen with -rc9 while running in the
console, and at least take a picture of the backtrace. If I find a
good way to make it happen then I'll try rc2 and let you know.
- R.
^ permalink raw reply
* Skb over panic on TUN device (2.6.18)
From: Max Krasnyansky @ 2007-10-04 20:58 UTC (permalink / raw)
To: netdev
Folks,
I just got this panic report against 2.6.18 kernel and was wondering if some of you have
an idea of why this might happen.
The panic looks like this:
skb_over_panic: text:ffffffff880463db len:2840 put:1454 head:ffff81005df81000 data:ffff81005df81020
tail:ffff81005df81b38 end:ffff81005df81840 dev:tun0
skb_over_panic: text:ffffffff880463db len:1354 put:1314 head:ffff81007d77ee00 data:ffff81007d77ee20
tail:ffff81007d77f36a end:ffff81007d77ee80 dev:tun0
Those are two are unrelated and happened at different times.
It's coming from this piece of code:
if (!(skb = alloc_skb(len + align, GFP_KERNEL))) {
tun->stats.rx_dropped++;
return -ENOMEM;
}
if (align)
skb_reserve(skb, align);
if (memcpy_fromiovec(skb_put(skb, len), iv, len)) {
tun->stats.rx_dropped++;
kfree_skb(skb);
return -EFAULT;
}
As you can see there is not a whole lot that can go wrong with skb in there.
'align' is set to 0 for TUN devices.
First dumps looks as if skb already had no zero length right after allocation.
In the second dump skb is only 128 byte in size (end - head) even though
we're clearly allocating and trying to write more than that.
So, my conclusion at this point is that for whatever reason alloc_skb() returned
busted SKB. Probably because something in the slab got corrupted.
Any other thoughts ?
Thanx
Max
^ permalink raw reply
* Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
From: Michael Wu @ 2007-10-04 21:16 UTC (permalink / raw)
To: John W. Linville
Cc: Michael Buesch, Daniel Drake, johannes, netdev, linux-wireless
In-Reply-To: <20071004181516.GH6037@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]
On Thursday 04 October 2007 14:15, John W. Linville wrote:
> Falling back on bloat as an argument against a BUG_ON in a
> configuration path seems a bit weak. :-)
>
Seems strong to me. Bloat slows me down and distracts me from what code really
needs to do. Bloat is an indication that one does not understand what the
code really needs to do.
> Programming with assertions (and BUG_ON is a form of that) is
> generally a good practice. Almost any book or other source on
> good programming practices will agree. Yes, it can be overdone.
> But I don't really think that is the case here, since the check is
> relatively inexpensive and the consequence should it ever *somehow*
> happen could be a something wierd (crash, corruption, etc) w/o any
> other indication of what occured.
>
A line has to be drawn somewhere. There's about a billion places where we can
add checks like this because if an assumption should ever break, the code
will break into pieces. However, we don't, and there's no reason to do so
here other than to needlessly add code just because it makes you feel safer.
-Michael Wu
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ieee80211_if_set_type: make check for master dev more explicit
From: Michael Wu @ 2007-10-04 21:26 UTC (permalink / raw)
To: John W. Linville
Cc: Daniel Drake, johannes-cdvu00un1VgdHxzADdlk8Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071004180900.GG6037-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Thursday 04 October 2007 14:09, John W. Linville wrote:
> diff --git a/net/mac80211/ieee80211_iface.c
> b/net/mac80211/ieee80211_iface.c index be7e77f..6607b80 100644
> --- a/net/mac80211/ieee80211_iface.c
> +++ b/net/mac80211/ieee80211_iface.c
> @@ -106,7 +106,7 @@ void ieee80211_if_set_type(struct net_device *dev, int
> type) * which already has a hard_start_xmit routine assigned
> * which must not be changed.
> */
> - if (!dev->hard_start_xmit)
> + if (dev->type != ARPHRD_IEEE80211)
The standard way of checking for the master device is
dev == sdata->local->mdev
wme.c doesn't quite follow this but that code needs to die anyway.
This does look nicer than the other patch.
-Michael Wu
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox