* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Stephen Hemminger @ 2009-09-09 21:35 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AA819D8.1020306@Sun.COM>
On Wed, 09 Sep 2009 14:10:48 -0700
Joyce Yu <Joyce.Yu@sun.com> wrote:
> From: Joyce Yu <joyce.yu@sun.com>
> Date: Wed, 9 Sep 2009 08:43:00 -0700
> Subject: [PATCH] VLAN does not work with niu driver
> Signed-off-by: Joyce Yu <joyce.yu@sun.com>
>
> ---
> drivers/net/niu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/niu.h b/drivers/net/niu.h
> index 3bd0b59..35678db 100644
> --- a/drivers/net/niu.h
> +++ b/drivers/net/niu.h
> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
> #define RCR_PKT_TYPE_UDP 0x2
> #define RCR_PKT_TYPE_SCTP 0x3
>
> -#define NIU_RXPULL_MAX ETH_HLEN
> +#define NIU_RXPULL_MAX 64
>
> struct rx_pkt_hdr0 {
> #if defined(__LITTLE_ENDIAN_BITFIELD)
> --
> 1.6.4
>
Shouldn't the vlan driver being doing pskb_may_pull()
or pskb_pull() instead?
--
^ permalink raw reply
* Re: questions / potential bug: e1000e and tx delay setting in msi-x mode
From: Brandeburg, Jesse @ 2009-09-09 21:59 UTC (permalink / raw)
To: Michal Soltys; +Cc: Linux Netdev List, e1000-devel
In-Reply-To: <4AA80CEE.5030704@ziu.info>
I CCd the maintainers list, which since you are talking about the out of
tree driver (I think) is probably more appropriate for future postings.
On Wed, 9 Sep 2009, Michal Soltys wrote:
> While experimenting a bit with intel PRO/1000 CT nic (reported by lspci as Intel
> Corporation 82574L Gigabit Network Connection), I noticed following issues (?):
>
> 1) under default IntMode (MSI-X), TxAbsIntDelay doesn't seem to limit interrupt
> rate (as seen via /proc/interrupts), although it is capped by InterruptThrottleRate
> (or not at all, if this one is disabled).
Tx[Abs]IntDelay is not meant to work when MSI-X mode is enabled. The only
interrupt throttling you should need is the InterruptThrottleRate (btw you
can use ethtool -C ethX rx-usecs <usecs between interrupts> to modify this
on the fly.)
> For example: with TxIntDelay 100 and TxAbsIntDelay 1000 - rate (as read from
> /proc/interrupts) under simple udp netcat bombarding (1k packet size):
>
> nc -u somehost someport </dev/zero
>
> ... will be around 115k int/sec - expected value w/o any interrupt moderation.
>
> When IntMode is set to 0 or 1 (so either regular or MSI) - both TxIntDelay and
> TxAbsIntDelay seem to work properly - in the above example, rate would stay below
> 1500 int/sec. But ...
>
> 2) ... at the same time, cpu load (as reported by mpstat -P ALL 1) is barely better
> in the latter case. Furthermore, if I disable any delays, e.g. load e1000e module with:
>
> options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
>
> .. then netcat test will max cpu core, and it will be unable to reach full 1gbit, while:
>
> options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
>
> .. will easily handle 1gbit with ~50%+ idle core (in my case at least).
>
>
> Should the difference between MSI and MSI-X modes be so large ?
It is, because in the case of MSI-X we don't have to check the ICR
register, which avoids a huge amount of CPU stall to read the single
register. It is the main reason for using MSI-X and MSI (in our case we
still have to read ICR in the case of MSI on some hardware - hardware bug)
> Earlier tests (pt. #1):
>
> options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=1
>
> .. handles 1gbit with ~60%+ idle core.
>
> and:
>
> options e1000e TxIntDelay=100 TxAbsIntDelay=1000 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
> options e1000e TxIntDelay=0 TxAbsIntDelay=0 RxIntDelay=0 RxAbsIntDelay=0 InterruptThrottleRate=0 IntMode=2
>
> .. are roughly identical as far as cpu load goes.
>
what it comes down to is that the TxAbsIntDelay and TxIntDelay registers
were introduced in the time before InterruptThrottleRate, back in the day
where we only had PCI and PCI-X adapters. Later PCI/PCI-X/PCIe adapters
have the hardware to support the InterruptThrottleRate.
These module parameters equate directly to registers in our NIC
TADV = TxAbsIntDelay
TIDV = TxIntDelay
ITR = InterruptThrottleRate
The 82574L datasheet[1] mentions that in MSI-X mode the IDE (interrupt
delay enable) bit should *NOT* be set, and the TADV and TIDV registers do
nothing when the IDE bit is not set, so that pretty well explains what you
see. Because the ITR register uses a different mechanism to coalese
interrupts, it will still apply even without IDE enabled.
> Those quick tests were done with nic interrupt(s) and netcat pinned at the same core.
>
>
> Tested with current 2.6.31-rc9 and stable 2.6.30 tree.
[1] http://download.intel.com/design/network/datashts/82574.pdf
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-09 22:11 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <313388.35529.qm@web111617.mail.gq1.yahoo.com>
On Wed, 2009-09-09 at 06:12 -0700, Xiaofei Wu wrote:
>
> After run 'tcpdump -i wlan1 -e', I can not capture any packets.
Could it be related to the wireless driver? Here's something i tried
on my laptop
---
dogo:/home/hadi# tc qdisc add dev lo handle 1: root prio
dogo:/home/hadi# tc filter add dev lo parent 1: protocol ip prio 10 u32
match ip src 127.0.0.1/24 flowid 1:16 action pedit munge offset -14 u16
set 0x0023 munge offset -12 u32 set 0xcdafecda munge offset -8 u32 set
0x0023cdaf munge offset -4 u32 set 0xd0740800 pipe action mirred egress
mirror dev eth0
---
On window1: tcpdump -n -i eth0
on window2: ping 127.0.0.2
On window1 i see:
----
dogo:/home/hadi# tcpdump -n -i eth0 -e
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
18:05:23.184602 00:23:cd:af:d0:74 > 00:23:cd:af:ec:da, ethertype IPv4
(0x0800), length 98: 127.0.0.2 > 127.0.0.2: ICMP echo request, id 53329,
seq 1, length 64
18:05:23.558949 00:06:dc:44:4b:ed > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 60: arp who-has 10.0.0.34 tell 10.0.0.33
18:05:24.199184 00:23:cd:af:d0:74 > 00:23:cd:af:ec:da, ethertype IPv4
(0x0800), length 98: 127.0.0.2 > 127.0.0.2: ICMP echo request, id 53329,
seq 2, length 64
--------
Try the exact example, if it doesnt work then you have other problems;
cheers,
jamal
^ permalink raw reply
* [AX25] kernel panic
From: Bernard Pidoux @ 2009-09-09 22:28 UTC (permalink / raw)
To: Ralf Baechle DL5RB; +Cc: Linux Netdev List, linux-hams
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Hi Ralf,
Here is a set of not so frequent kernel panics captured via netconsole
that seem related to AX25 timer.
Regards,
Bernard Pidoux
[-- Attachment #2: kernel_panic_AX25 --]
[-- Type: text/plain, Size: 33053 bytes --]
------------------------
sam. août 8 22:08:26 CEST 2009
------------------------
BUG: unable to handle kernel paging request at ffff880004c90648
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 7e2067 PTE 4c90160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm i2c_viapro snd_timer snd_page_alloc snd_mixer_oss snd i2c_core soundcore sr_mod 8139cp 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos thermal via_agp processor evdev button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880004c90400 RCX: 0000000000000058
RDX: ffffe200009cb3d8 RSI: ffffffff8067f060 RDI: ffff880004c90618
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 0000000000000490
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880004c90618
R13: ffff880004c90400 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff880004c90648 CR3: 0000000074843000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff880004c90400 ffff880004c90400 ffff880004c90400 ffffffffa035bb30
ffffffff80717e30 ffffffffa035b850 ffffffff80717e60 ffffffffa035edb4
ffff880004c90400 ffff880004c90400 0000000000000000 ffffffffa035bb30
Call Trace:
<IRQ> <0> [<ffffffffa035bb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa035b850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa035edb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa035bb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa035b045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa035bb55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880004c90648
---[ end trace 366e8cf762bbf316 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..BUG: unable to handle kernel paging request at ffff88001bbee248
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 899067 PTE 1bbee160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm 8139cp snd_timer snd_page_alloc snd_mixer_oss snd soundcore sr_mod 8139too mii i2c_viapro i2c_core shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table thermal processor floppy rtc_cmos via_agp button sg evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff88001bbee000 RCX: 0000000000000058
RDX: ffffe2000060cbb8 RSI: ffffffff8067f060 RDI: ffff88001bbee218
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000003ee
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff88001bbee218
R13: ffff88001bbee000 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88001bbee248 CR3: 00000000296e7000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff88001bbee000 ffff88001bbee000 ffff88001bbee000 ffffffffa0355b30
ffffffff80717e30 ffffffffa0355850 ffffffff80717e60 ffffffffa0358db4
ffff88001bbee000 ffff88001bbee000 0000000000000000 ffffffffa0355b30
Call Trace:
<IRQ> <0> [<ffffffffa0355b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0355850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0358db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0355b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0355045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa0355b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff88001bbee248
---[ end trace b7e0c620509cd638 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..------------------------
jeu. août 13 00:13:13 CEST 2009
------------------------
BUG: unable to handle kernel paging request at ffff880071c80e48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 9bc067 PMD b4b067 PTE 71c80160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: loop netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss 8139cp i2c_viapro snd soundcore sr_mod 8139too i2c_core mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table thermal floppy rtc_cmos processor via_agp button sg evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880071c80c00 RCX: 0000000000000058
RDX: ffffe200010313d8 RSI: ffffffff8067f060 RDI: ffff880071c80e18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 0000000000000480
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880071c80e18
R13: ffff880071c80c00 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff880071c80e48 CR3: 000000007a11c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff880071c80c00 ffff880071c80c00 ffff880071c80c00 ffffffffa0358b30
ffffffff80717e30 ffffffffa0358850 ffffffff80717e60 ffffffffa035bdb4
ffff880071c80c00 ffff880071c80c00 0000000000000000 ffffffffa0358b30
Call Trace:
<IRQ> <0> [<ffffffffa0358b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0358850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa035bdb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0358b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0358045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa0358b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880071c80e48
---[ end trace d516331eccbfb939 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..------------------------
sam. août 15 10:15:34 CEST 2009
------------------------
------------------------
sam. août 15 10:16:32 CEST 2009
------------------------
-------------------------------
sam. août 15 13:11:53 CEST 2009
-------------------------------
-------------------------------
sam. août 15 13:16:21 CEST 2009
-------------------------------
-------------------------------
sam. août 15 14:36:50 CEST 2009
-------------------------------
-------------------------------
Sun Aug 16 04:03:12 CEST 2009
-------------------------------
-------------------------------
Mon Aug 17 04:03:21 CEST 2009
-------------------------------
-------------------------------
lun. août 17 12:43:33 CEST 2009
-------------------------------
-------------------------------
lun. août 17 14:03:50 CEST 2009
-------------------------------
-------------------------------
Tue Aug 18 04:03:17 CEST 2009
-------------------------------
-------------------------------
Wed Aug 19 04:03:22 CEST 2009
-------------------------------
-------------------------------
Thu Aug 20 04:03:24 CEST 2009
-------------------------------
-------------------------------
jeu. août 20 14:21:57 CEST 2009
-------------------------------
-------------------------------
jeu. août 20 15:42:15 CEST 2009
-------------------------------
general protection fault: 0000 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa6/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc i2c_viapro snd_mixer_oss snd i2c_core soundcore sr_mod 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos via_agp thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 30904, comm: astropulse_5.06 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffffa034fb3d>] [<ffffffffa034fb3d>] ax25_heartbeat_expiry+0xd/0x60 [ax25]
RSP: 0000:ffffffff80717ea0 EFLAGS: 00010206
RAX: ffff880061829fd8 RBX: ffff88006f59b000 RCX: ffffffffa034fb30
RDX: 6e75203a7473696c RSI: 0000000000000e3f RDI: ffff88006f59b000
RBP: ffffffff80717ea0 R08: ffff88006f59b250 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000100
R13: ffffffff8075a600 R14: ffffffffa034fb30 R15: ffffffff80717ed0
FS: 0000000001493860(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f771ebbd000 CR3: 000000006b867000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process astropulse_5.06 (pid: 30904, threadinfo ffff880061828000, task ffff8800618641a0)
Stack:
ffffffff80717f10 ffffffff8024976c ffffffff8075c210 ffffffff8075be10
ffffffff8075ba10 ffffffff8075b610 ffff88006f512970 ffff88006f512970
ffffffff8025f8ff 0000000000000008 0000000000000001 0000000000000100
Call Trace:
<IRQ> <0> [<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 80 7a 58 00 66 90 74 da c9 0f 1f 44 00 00 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 57 28 48 89 e5 48 85 d2 74 0c <8b> 42 50 85 c0 78 11 83 f8 01 7f 17 0f 1f 80 00 00 00 00 e8 fb
RIP [<ffffffffa034fb3d>] ax25_heartbeat_expiry+0xd/0x60 [ax25]
RSP <ffffffff80717ea0>
---[ end trace 0dee287bd3d290a3 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Fri Aug 21 04:03:18 CEST 2009
-------------------------------
-------------------------------
Sat Aug 22 04:03:24 CEST 2009
-------------------------------
-------------------------------
Sun Aug 23 04:03:27 CEST 2009
-------------------------------
-------------------------------
Mon Aug 24 04:03:26 CEST 2009
-------------------------------
-------------------------------
Tue Aug 25 04:03:23 CEST 2009
-------------------------------
-------------------------------
Wed Aug 26 04:03:25 CEST 2009
-------------------------------
general protection fault: 0000 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa12/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 8139too mii i2c_viapro soundcore i2c_core sr_mod shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos via_agp thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 28253, comm: astropulse_5.06 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffffa0342ae8>] [<ffffffffa0342ae8>] ax25_t1timer_expiry+0x8/0x50 [ax25]
RSP: 0000:ffffffff80717ea0 EFLAGS: 00010246
RAX: ffff880074023fd8 RBX: ffff88007bc90000 RCX: ffffffffa0342ae0
RDX: a86496acda711900 RSI: 0000000000000000 RDI: ffff88007bc90000
RBP: ffffffff80717ea0 R08: ffff88007bc90078 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000100
R13: ffffffff8075a600 R14: ffffffffa0342ae0 R15: ffffffff80717ed0
FS: 000000000224b860(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa029a4e000 CR3: 000000007e8e9000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process astropulse_5.06 (pid: 28253, threadinfo ffff880074022000, task ffff8800714c2bc0)
Stack:
ffffffff80717f10 ffffffff8024976c ffffffff8075c210 ffffffff8075be10
ffffffff8075ba10 ffffffff8075b610 ffffffff80717ed0 ffffffff80717ed0
ffffffff8025f8ff 0000000000000008 0000000000000001 0000000000000100
Call Trace:
<IRQ> <0> [<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 44 00 00 75 e7 80 7a 58 00 66 90 74 da c9 0f 1f 44 00 00 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 57 28 48 89 e5 <8b> 42 50 85 c0 78 0a 83 f8 01 7f 14 e8 e7 f1 ff ff c9 66 0f 1f
RIP [<ffffffffa0342ae8>] ax25_t1timer_expiry+0x8/0x50 [ax25]
RSP <ffffffff80717ea0>
---[ end trace 963e5b19794631dc ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Thu Aug 27 04:03:22 CEST 2009
-------------------------------
-------------------------------
Fri Aug 28 04:03:26 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff880077ca0e48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 9bc067 PMD b7b067 PTE 77ca0160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa6/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd i2c_viapro soundcore i2c_core sr_mod 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table floppy sg rtc_cmos via_agp thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 30841, comm: setiathome-5.28 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0000:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff880077ca0c00 RCX: 0000000000000058
RDX: ffffe20001a29a48 RSI: ffffffff8067f060 RDI: ffff880077ca0e18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000004a0
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff880077ca0e18
R13: ffff880077ca0c00 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000041b93940(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff880077ca0e48 CR3: 000000006e1fc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process setiathome-5.28 (pid: 30841, threadinfo ffff88007957c000, task ffff8800750cabc0)
Stack:
ffff880077ca0c00 ffff880077ca0c00 ffff880077ca0c00 ffffffffa034fb30
ffffffff80717e30 ffffffffa034f850 ffffffff80717e60 ffffffffa0352db4
ffff880077ca0c00 ffff880077ca0c00 0000000000000000 ffffffffa034fb30
Call Trace:
<IRQ> <0> [<ffffffffa034fb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034f850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0352db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa034fb30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034f045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa034fb55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff880077ca0e48
---[ end trace 2278e28e8ee624db ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Sat Aug 29 04:03:23 CEST 2009
-------------------------------
-------------------------------
Sun Aug 30 04:03:21 CEST 2009
-------------------------------
-------------------------------
Mon Aug 31 04:03:24 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff88006eca8a48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 9bc067 PMD b33067 PTE 6eca8160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd i2c_viapro 8139too i2c_core soundcore sr_mod mii shpchp pci_hotplug binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table via_agp rtc_cmos floppy thermal processor button sg evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff88006eca8800 RCX: 0000000000000058
RDX: ffffe200017e8f68 RSI: ffffffff8067f060 RDI: ffff88006eca8a18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000004a8
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff88006eca8a18
R13: ffff88006eca8800 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88006eca8a48 CR3: 000000006e00b000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff88006eca8800 ffff88006eca8800 ffff88006eca8800 ffffffffa0345b30
ffffffff80717e30 ffffffffa0345850 ffffffff80717e60 ffffffffa0348db4
ffff88006eca8800 ffff88006eca8800 0000000000000000 ffffffffa0345b30
Call Trace:
<IRQ> <0> [<ffffffffa0345b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0345850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0348db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0345b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0345045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa0345b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff88006eca8a48
---[ end trace 62fd644f9e0af320 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Tue Sep 1 04:03:25 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff88000ad0a248
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 812067 PTE ad0a160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa5/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore i2c_viapro i2c_core sr_mod 8139too mii shpchp pci_hotplug binfmt_misc ext3 jbd rtc_cmos floppy thermal button cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table processor via_agp evdev sg pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 0, comm: swapper Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0018:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff88000ad0a000 RCX: 0000000000000058
RDX: ffffe200019d57a8 RSI: ffffffff8067f060 RDI: ffff88000ad0a218
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 000000000000050a
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff88000ad0a218
R13: ffff88000ad0a000 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000000000000(0000) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88000ad0a248 CR3: 00000000751da000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 0, threadinfo ffffffff8068c000, task ffffffff80632360)
Stack:
ffff88000ad0a000 ffff88000ad0a000 ffff88000ad0a000 ffffffffa0350b30
ffffffff80717e30 ffffffffa0350850 ffffffff80717e60 ffffffffa0353db4
ffff88000ad0a000 ffff88000ad0a000 0000000000000000 ffffffffa0350b30
Call Trace:
<IRQ> <0> [<ffffffffa0350b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0350850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa0353db4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa0350b30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa0350045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffffa0350b55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0> [<ffffffff80218afd>] ? mwait_idle+0x5d/0x70
[<ffffffff8020fdd2>] ? enter_idle+0x22/0x30
[<ffffffff8020fe2e>] ? cpu_idle+0x4e/0x80
[<ffffffff804eb5cd>] ? rest_init+0x5d/0x70
Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff88000ad0a248
---[ end trace 8cace7d340707eda ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Wed Sep 2 04:03:25 CEST 2009
-------------------------------
-------------------------------
Thu Sep 3 04:03:19 CEST 2009
-------------------------------
-------------------------------
Fri Sep 4 04:03:21 CEST 2009
-------------------------------
BUG: unable to handle kernel paging request at ffff8800141b6a48
IP: [<ffffffff80249451>] del_timer+0x11/0xb0
PGD 202063 PUD 206063 PMD 85c067 PTE 141b6160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/class/vc/vcsa6/dev
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd shpchp i2c_viapro 8139too pci_hotplug soundcore i2c_core sr_mod mii binfmt_misc ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table via_agp floppy sg rtc_cmos thermal evdev processor button pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 32129, comm: setiathome-5.28 Not tainted 2.6.29.6-nosmp #8 MS-7258
RIP: 0010:[<ffffffff80249451>] [<ffffffff80249451>] del_timer+0x11/0xb0
RSP: 0000:ffffffff80717e00 EFLAGS: 00010246
RAX: ffffffff8067f0b8 RBX: ffff8800141b6800 RCX: 0000000000000058
RDX: ffffe200004610c8 RSI: ffffffff8067f060 RDI: ffff8800141b6a18
RBP: ffffffff80717e20 R08: 0000000000000001 R09: 00000000000001b6
R10: 0000000000000002 R11: ffffffff8067f008 R12: ffff8800141b6a18
R13: ffff8800141b6800 R14: 0000000000000000 R15: ffffffff80717ed0
FS: 0000000041ee4940(0063) GS:ffffffff80720000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8800141b6a48 CR3: 00000000781d5000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process setiathome-5.28 (pid: 32129, threadinfo ffff8800781e2000, task ffff8800183641a0)
Stack:
ffff8800141b6800 ffff8800141b6800 ffff8800141b6800 ffffffffa034ab30
ffffffff80717e30 ffffffffa034a850 ffffffff80717e60 ffffffffa034ddb4
ffff8800141b6800 ffff8800141b6800 0000000000000000 ffffffffa034ab30
Call Trace:
<IRQ> <0> [<ffffffffa034ab30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034a850>] ax25_stop_heartbeat+0x10/0x20 [ax25]
[<ffffffffa034ddb4>] ax25_destroy_socket+0x64/0x210 [ax25]
[<ffffffffa034ab30>] ? ax25_heartbeat_expiry+0x0/0x60 [ax25]
[<ffffffffa034a045>] ax25_std_heartbeat_expiry+0xf5/0x100 [ax25]
[<ffffffff80217c56>] ? read_tsc+0x16/0x40
[<ffffffffa034ab55>] ax25_heartbeat_expiry+0x25/0x60 [ax25]
[<ffffffff8024976c>] run_timer_softirq+0x15c/0x230
[<ffffffff8025f8ff>] ? clockevents_program_event+0x4f/0x90
[<ffffffff8024506c>] __do_softirq+0x7c/0x110
[<ffffffff8021271c>] call_softirq+0x1c/0x30
[<ffffffff8021407d>] do_softirq+0x5d/0xa0
[<ffffffff80244c95>] irq_exit+0x45/0x50
[<ffffffff80223e85>] smp_apic_timer_interrupt+0x55/0x90
[<ffffffff80212253>] apic_timer_interrupt+0x13/0x20
<EOI> <0>Code: 10 18 00 00 eb a6 0f 1f 40 00 48 0f b6 c2 48 c1 e0 04 48 8d 54 07 10 eb 93 90 55 48 89 e5 41 56 45 31 f6 41 55 41 54 49 89 fc 53 <48> c7 47 30 00 00 00 00 48 83 3f 00 75 16 eb 76 0f 1f 80 00 00
RIP [<ffffffff80249451>] del_timer+0x11/0xb0
RSP <ffffffff80717e00>
CR2: ffff8800141b6a48
---[ end trace 469a474dc114bf10 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 60 seconds..
-------------------------------
Sat Sep 5 04:03:26 CEST 2009
-------------------------------
-------------------------------
Sun Sep 6 04:03:11 CEST 2009
-------------------------------
-------------------------------
Mon Sep 7 04:03:20 CEST 2009
-------------------------------
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-09 22:32 UTC (permalink / raw)
To: Daniel Walker
Cc: i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp,
netdev-u79uwXL29TY76Z2rM5mHXA, Hansjoerg Lipp,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Daniel Walker wrote 07.09.09 16:30:
> Yeah, it looks like the whole file needs a checkpatch clean up.. Sounds
like your not willing to do that?
It's not a question of willingness. You may notice I did a lot of cleanup work already. But it's very time consuming work, and there has been more important work to attend to first.
> Usually if a checkpatch cleanup comes
first prior to all your other changes , it doesn't usually cloud the
rest of the changes..
Sure. But that would mean postponing the merging of bugfixes until someone finds the time to do a complete checkpatch cleanup of the affected code. I don't think that's a sensible approach.
Thanks,
Tilman
^ permalink raw reply
* Re: TCP kernel tables overflowing after sustained 1000 new connections per second
From: David Miller @ 2009-09-10 0:08 UTC (permalink / raw)
To: paulsheer; +Cc: linux-kernel, roque, netdev
In-Reply-To: <c67e3dc60909091146j4aeaf422v4e0543eff87c7f9a@mail.gmail.com>
From: Paul Sheer <paulsheer@gmail.com>
Date: Wed, 9 Sep 2009 20:46:07 +0200
Can you please send networking reports and questions at least
CC:'d to netdev@vger.kernel.org, which is where the networking
developers are subscribed? I've added it to the CC:
> I am developing a high-performance application, and testing against Apache.
> It makes 1000 new connections to Apache per second.
>
> After 16 seconds the test grinds to a halt. A Linux kernel problem. There are
> several hurdles to overcome when trying to sustain such through-put. Some
> are configuration issues, others I believe are real problems with the kernel
> internals. I'll discuss these all below.
>
> Configuration:
>
> These are the relavent kernel configuration parameters:
>
> /proc/sys/net/ipv4/tcp_tw_recycle
> /proc/sys/net/ipv4/tcp_tw_reuse
> /proc/sys/net/ipv4/tcp_max_tw_buckets
> /proc/sys/net/ipv4/ip_local_port_range
> /proc/sys/net/ipv4/tcp_timestamps
> /proc/sys/net/ipv4/tcp_fin_timeout
> /proc/sys/net/ipv4/tcp_orphan_retries
> /proc/sys/net/ipv4/tcp_rfc1337
> /proc/sys/net/ipv4/tcp_max_orphans
> /proc/sys/net/ipv4/tcp_max_syn_backlog
> /proc/sys/net/ipv4/tcp_mem
>
> On a gigabit local LAN I can set the timeouts very low to encourage
> port reuse. A well known configuration issue with all OS's - just search
> for MyOS+TIMED_WAIT on google. No problems here.
>
>
> The second problem is the ip_conntrack module.
>
> If you don't know that your distribution has enabled this module
> by default, it not easy to work out that it has internal tables
> that max out at 16384. So this explains why my system
> stops accepting connections after exactly 16 seconds.
> If you stop the application, give it a few minutes, try again,
> then you can do another 16 seconds of flat out load for it
> grinds to a halt again. Doing an rm on the module ko and
> rebooting fixed *this* problem.
>
> The third problem seems to be connected to /proc/net/tcp6
>
> look at the output of the script
>
> while true ; do echo "`date`: `cat /proc/net/tcp6 | wc -l` vs `cat
> /proc/net/tcp | wc -l`" ; sleep 1 ; done
>
> while I run my load test:
>
>
> Wed Sep 9 20:39:26 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:27 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:28 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:29 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:31 SAST 2009: 1233 vs 20
> Wed Sep 9 20:39:32 SAST 2009: 2640 vs 21
> Wed Sep 9 20:39:33 SAST 2009: 4190 vs 20
> Wed Sep 9 20:39:34 SAST 2009: 5813 vs 20
> Wed Sep 9 20:39:35 SAST 2009: 7527 vs 20
> Wed Sep 9 20:39:37 SAST 2009: 9568 vs 44
> Wed Sep 9 20:39:38 SAST 2009: 11819 vs 21
> Wed Sep 9 20:39:40 SAST 2009: 14510 vs 21
> Wed Sep 9 20:39:42 SAST 2009: 16971 vs 20
> Wed Sep 9 20:39:44 SAST 2009: 16971 vs 20
> Wed Sep 9 20:39:46 SAST 2009: 17013 vs 20
> Wed Sep 9 20:39:48 SAST 2009: 17013 vs 20
> Wed Sep 9 20:39:50 SAST 2009: 17013 vs 20
>
> So it is clear "something" is filling up in tcp_ipv6.c
>
> any ideas Pedro?
> anyone?
>
> Many thanks.
>
> -paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-09
From: John W. Linville @ 2009-09-10 0:10 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
One last batch of wireless bits for the 2.6.32 merge window... :-)
This includes a number of ath9k updates related especially to bluetooth
coexistance, as well as a number of b43 changes related to support of SDIO
and the associated SSB over SDIO bus support.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 6ec1c69a8f6492fd25722f4762721921da074c12:
David S. Miller (1):
net_sched: add classful multiqueue dummy scheduler
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Albert Herranz (1):
ssb: Implement SDIO host bus support
Christian Lamparter (1):
ar9170: implement frequency calibration for one-stage/openfw
Holger Schurig (1):
cfg80211: allow scanning on specified frequencies when using wext-compatibility
Ivo van Doorn (1):
rt2x00: Hardcode TX ack timeout and consume time
Joe Perches (1):
MAINTAINERS: Add Atheros Linux wireless drivers home page
Joerg Albert (3):
ar9170: added phy register initialisation from eeprom values
ath,ar9170: move CTL_ defines into regd.h
ath,ar9170: implemented conformance test limit calc. for tx power
Luis R. Rodriguez (5):
ath9k: propagate ieee80211_alloc_hw() failure
ath9k: propagate errors on ath_init_device() and request_irq()
ath9k: claim irq for ath9k, not ath for pci
wireless: update cfg80211 kconfig entry
wireless: mark prism54 as deprecated and mark for removal
Michael Buesch (10):
b43: Use a threaded IRQ handler
b43: Remove TX spinlock
b43: Remove DMA/PIO queue locks
b43: Remove PIO RX workqueue
b43: remove SHM spinlock
ssb: Fail ssb modinit, if attach of the buses failed.
b43: PCMCIA is not experimental anymore
b43: Really disable QoS, if requested
b43: Fix sparse warning in hw-tkip code
b44/b43/b43legacy: Fix switch warnings introduced by SSB-SDIO
Sujith (2):
ath9k: Fix RX Filter handling for BAR
ath9k: Fix channelFlags for 2GHZ
Vasanthakumar Thiagarajan (6):
ath9k: Disable ASPM when btcoex is active
ath9k: Remove unnecessary casting to u8 in pci_read_config_byte() call
ath9k: Store subsystem id in struct hw_version
ath9k: Enable btcoex based on the subsystem id of the device
ath9k: Get rid of the modparam btcoex_enable
ath9k: Initialize the priority gpio for BT coex 3-wire
Documentation/feature-removal-schedule.txt | 29 ++
MAINTAINERS | 2 +
drivers/net/b44.c | 10 +-
drivers/net/wireless/Kconfig | 57 +--
drivers/net/wireless/ath/ar9170/phy.c | 420 +++++++++++++++++++-
drivers/net/wireless/ath/ath9k/ahb.c | 10 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 23 +
drivers/net/wireless/ath/ath9k/btcoex.h | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 30 +-
drivers/net/wireless/ath/ath9k/hw.h | 10 +
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/ath/ath9k/pci.c | 22 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +
drivers/net/wireless/ath/ath9k/reg.h | 1 -
drivers/net/wireless/ath/regd.h | 6 +
drivers/net/wireless/ath/regd_common.h | 6 -
drivers/net/wireless/b43/Kconfig | 4 +-
drivers/net/wireless/b43/b43.h | 30 +-
drivers/net/wireless/b43/debugfs.c | 67 +---
drivers/net/wireless/b43/debugfs.h | 3 +-
drivers/net/wireless/b43/dma.c | 31 +--
drivers/net/wireless/b43/dma.h | 3 -
drivers/net/wireless/b43/main.c | 460 +++++++++++-----------
drivers/net/wireless/b43/main.h | 4 -
drivers/net/wireless/b43/phy_common.c | 1 -
drivers/net/wireless/b43/phy_common.h | 3 +-
drivers/net/wireless/b43/phy_g.c | 7 -
drivers/net/wireless/b43/phy_g.h | 3 +-
drivers/net/wireless/b43/pio.c | 71 +---
drivers/net/wireless/b43/pio.h | 6 -
drivers/net/wireless/b43/sysfs.c | 3 -
drivers/net/wireless/b43/xmit.c | 10 +-
drivers/net/wireless/b43legacy/main.c | 8 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 5 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 5 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 4 -
drivers/net/wireless/rt2x00/rt2800usb.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00.h | 3 -
drivers/net/wireless/rt2x00/rt2x00config.c | 11 -
drivers/net/wireless/rt2x00/rt61pci.c | 2 +-
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
drivers/ssb/Kconfig | 14 +
drivers/ssb/Makefile | 1 +
drivers/ssb/main.c | 64 +++-
drivers/ssb/scan.c | 11 +
drivers/ssb/sdio.c | 610 ++++++++++++++++++++++++++++
drivers/ssb/ssb_private.h | 40 ++
include/linux/ssb/ssb.h | 25 +-
net/wireless/Kconfig | 11 +-
net/wireless/scan.c | 41 ++-
52 files changed, 1673 insertions(+), 539 deletions(-)
create mode 100644 drivers/ssb/sdio.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-09-09.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 0:15 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AA819D8.1020306@Sun.COM>
From: Joyce Yu <Joyce.Yu@sun.com>
Date: Wed, 09 Sep 2009 14:10:48 -0700
> drivers/net/niu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Can I get a more verbose commit message than this?
> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
> #define RCR_PKT_TYPE_UDP 0x2
> #define RCR_PKT_TYPE_SCTP 0x3
>
> -#define NIU_RXPULL_MAX ETH_HLEN
> +#define NIU_RXPULL_MAX 64
>
See, that's why I want a detailed commit message, because if you
described things more clearly I'd understand why you choose the value
'64' as opposed to, say, the size of a VLAN header which to me would
be a more appropriate value to use here.
You just seem to be reverting a change I made a while back, and it
just so happens to fix your problem. But '64' is too large a value
to use here and it will impact performance.
You did check to see if there were any performance regressions
resulting from your change, right?
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 0:16 UTC (permalink / raw)
To: shemminger; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909143514.0bd1e7ba@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 9 Sep 2009 14:35:14 -0700
> Shouldn't the vlan driver being doing pskb_may_pull()
> or pskb_pull() instead?
I thought about it, and my answer is 'probably not'.
Just like for eth_type_trans(), it's pretty reasonable to
expect the link level header to be linearized already.
^ permalink raw reply
* Re: TCP kernel tables overflowing after sustained 1000 new connections per second
From: Brian Haley @ 2009-09-10 0:26 UTC (permalink / raw)
To: paulsheer; +Cc: David Miller, linux-kernel, roque, netdev
In-Reply-To: <20090909.170824.141343404.davem@davemloft.net>
>> The third problem seems to be connected to /proc/net/tcp6
>>
>> look at the output of the script
>>
>> while true ; do echo "`date`: `cat /proc/net/tcp6 | wc -l` vs `cat
>> /proc/net/tcp | wc -l`" ; sleep 1 ; done
>>
>> while I run my load test:
>>
>>
>> Wed Sep 9 20:39:26 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:27 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:28 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:29 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:31 SAST 2009: 1233 vs 20
>> Wed Sep 9 20:39:32 SAST 2009: 2640 vs 21
>> Wed Sep 9 20:39:33 SAST 2009: 4190 vs 20
>> Wed Sep 9 20:39:34 SAST 2009: 5813 vs 20
>> Wed Sep 9 20:39:35 SAST 2009: 7527 vs 20
>> Wed Sep 9 20:39:37 SAST 2009: 9568 vs 44
>> Wed Sep 9 20:39:38 SAST 2009: 11819 vs 21
>> Wed Sep 9 20:39:40 SAST 2009: 14510 vs 21
>> Wed Sep 9 20:39:42 SAST 2009: 16971 vs 20
>> Wed Sep 9 20:39:44 SAST 2009: 16971 vs 20
>> Wed Sep 9 20:39:46 SAST 2009: 17013 vs 20
>> Wed Sep 9 20:39:48 SAST 2009: 17013 vs 20
>> Wed Sep 9 20:39:50 SAST 2009: 17013 vs 20
>>
>> So it is clear "something" is filling up in tcp_ipv6.c
By default, apache is going to open an IPv6 socket, so every connection,
even IPv4, will use an IPv6 socket with a mapped address:
# netstat -anp | grep apache
tcp6 0 0 :::80 :::* LISTEN 27795/apache2
tcp6 0 0 ::ffff:10.0.0.1:80 ::ffff:10.0.0.2:35271 ESTABLISHED27813/apache2
I'm guessing that 17013 is your 16384 plus a few in time-wait, right?
There's a way to change it to be IPv4-only in the conf file from what I remember.
-Brian
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-09-09
From: David Miller @ 2009-09-10 0:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090910001025.GA19645@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Sep 2009 20:10:25 -0400
> One last batch of wireless bits for the 2.6.32 merge window... :-)
>
> This includes a number of ath9k updates related especially to bluetooth
> coexistance, as well as a number of b43 changes related to support of SDIO
> and the associated SSB over SDIO bus support.
Pulled, thanks John!
^ permalink raw reply
* Re: [PATCH] ipv6: Add IFA_F_DADFAILED flag
From: Brian Haley @ 2009-09-10 0:41 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: david Miller, netdev@vger.kernel.org, YOSHIFUJI Hideaki
In-Reply-To: <1252424623.5827.14.camel@fnki-nb00130>
Jens Rosenboom wrote:
> On Tue, 2009-09-08 at 11:18 -0400, Brian Haley wrote:
>> Jens Rosenboom wrote:
>>>> --- a/net/ipv6/addrconf.c
>>>> +++ b/net/ipv6/addrconf.c
>>>> @@ -1376,7 +1376,7 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
>>>> if (ifp->flags&IFA_F_PERMANENT) {
>>>> spin_lock_bh(&ifp->lock);
>>>> addrconf_del_timer(ifp);
>>>> - ifp->flags |= IFA_F_TENTATIVE;
>>>> + ifp->flags |= IFA_F_DADFAILED;
>>> I think you still have to set IFA_F_TENTATIVE here, too, otherwise
>>> ipv6_dev_get_saddr() will use this address.
>> The tentative bit is still set from when this address was added back
>> in ipv6_add_addr() from what I can tell, re-setting it here is actually
>> unnecessary. At least /sbin/ip was still showing it set during my
>> testing.
>
> There is the possibility of a race when the dad_timer expires at the
> same time the NA triggering DAD failure is received. There isn't a big
> chance to see that during real world testing, though.
Ok, how does this look? I changed it to set the tentative flag as it did
before, plus clear the dad_failed flag if the device got restarted,
triggering DAD to happen again for any tentative address, that was an
oversight on my part.
I'd still like to know if using this last ifa_flag is going to be an issue,
I actually finished a similar patch that uses a new IFA_ADDRFLAGS structure
to pass in/out this additional info.
-Brian
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index a60c821..fd97404 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -41,6 +41,7 @@ enum
#define IFA_F_NODAD 0x02
#define IFA_F_OPTIMISTIC 0x04
+#define IFA_F_DADFAILED 0x08
#define IFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE 0x40
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 43b3c9f..c9b3690 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1371,12 +1371,14 @@ struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net, const struct in6_addr *add
/* Gets referenced address, destroys ifaddr */
-static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
+static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
{
if (ifp->flags&IFA_F_PERMANENT) {
spin_lock_bh(&ifp->lock);
addrconf_del_timer(ifp);
ifp->flags |= IFA_F_TENTATIVE;
+ if (dad_failed)
+ ifp->flags |= IFA_F_DADFAILED;
spin_unlock_bh(&ifp->lock);
in6_ifa_put(ifp);
#ifdef CONFIG_IPV6_PRIVACY
@@ -1422,7 +1424,7 @@ void addrconf_dad_failure(struct inet6_ifaddr *ifp)
}
}
- addrconf_dad_stop(ifp);
+ addrconf_dad_stop(ifp, 1);
}
/* Join to solicited addr multicast group. */
@@ -2778,7 +2780,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
idev->cnf.accept_dad < 1 ||
!(ifp->flags&IFA_F_TENTATIVE) ||
ifp->flags & IFA_F_NODAD) {
- ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
+ ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC|IFA_F_DADFAILED);
spin_unlock_bh(&ifp->lock);
read_unlock_bh(&idev->lock);
@@ -2795,7 +2797,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
* - otherwise, kill it.
*/
in6_ifa_hold(ifp);
- addrconf_dad_stop(ifp);
+ addrconf_dad_stop(ifp, 0);
return;
}
@@ -2829,7 +2831,7 @@ static void addrconf_dad_timer(unsigned long data)
* DAD was successful
*/
- ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
+ ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC|IFA_F_DADFAILED);
spin_unlock_bh(&ifp->lock);
read_unlock_bh(&idev->lock);
^ permalink raw reply related
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:01 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.171517.34998160.davem@davemloft.net>
David Miller wrote:
> From: Joyce Yu <Joyce.Yu@sun.com>
> Date: Wed, 09 Sep 2009 14:10:48 -0700
>
>> drivers/net/niu.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Can I get a more verbose commit message than this?
>
>> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
>> #define RCR_PKT_TYPE_UDP 0x2
>> #define RCR_PKT_TYPE_SCTP 0x3
>>
>> -#define NIU_RXPULL_MAX ETH_HLEN
>> +#define NIU_RXPULL_MAX 64
>>
>
> See, that's why I want a detailed commit message, because if you
> described things more clearly I'd understand why you choose the value
> '64' as opposed to, say, the size of a VLAN header which to me would
> be a more appropriate value to use here.
Dave,
The frame type in NIU HW is embedded in a HW header, so it is
possible to check the HW header and decide whether to pull up ETH_HLEN
or VLAN header size of bytes. However, considering the amount of work
required to get and examine the HW header (including endianess issues),
we thought pulling up 64 bytes by default (as used in cassini.c) would
be efficient.
Regards,
Matheos
>
> You just seem to be reverting a change I made a while back, and it
> just so happens to fix your problem. But '64' is too large a value
> to use here and it will impact performance.
>
> You did check to see if there were any performance regressions
> resulting from your change, right?
> --
> 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] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 1:10 UTC (permalink / raw)
To: Matheos.Worku; +Cc: Joyce.Yu, netdev
In-Reply-To: <4AA84FE3.6030407@sun.com>
From: Matheos Worku <Matheos.Worku@Sun.COM>
Date: Wed, 09 Sep 2009 18:01:23 -0700
> The frame type in NIU HW is embedded in a HW header, so it is possible
> to check the HW header and decide whether to pull up ETH_HLEN or VLAN
> header size of bytes. However, considering the amount of work required
> to get and examine the HW header (including endianess issues), we
> thought pulling up 64 bytes by default (as used in cassini.c) would be
> efficient.
Well, it was 64 in early versions of the driver, and I decreased it
down to ETH_HLEN.
The less the better since for forwarding applications anything past
the IPV4 header pulled is going to be a waste of CPU cache lines and
thus negatively effect forwarding rates.
That's why I asked if this change was performance regression tested,
because I know it's going to slow down forwarding rates for small
packets.
^ permalink raw reply
* Re: net_sched: fix estimator lock selection for mq child qdiscs
From: David Miller @ 2009-09-10 1:11 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4AA7D0C5.9080601@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 09 Sep 2009 17:59:01 +0200
> net_sched: fix estimator lock selection for mq child qdiscs
>
> When new child qdiscs are attached to the mq qdisc, they are actually
> attached as root qdiscs to the device queues. The lock selection for
> new estimators incorrectly picks the root lock of the existing and
> to be replaced qdisc, which results in a use-after-free once the old
> qdisc has been destroyed.
>
> Mark mq qdisc instances with a new flag and treat qdiscs attached to
> mq as children similar to regular root qdiscs.
>
> Additionally prevent estimators from being attached to the mq qdisc
> itself since it only updates its byte and packet counters during dumps.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: fix tx descriptor structure
From: David Miller @ 2009-09-10 1:13 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, amit
In-Reply-To: <1252526963-25621-2-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Wed, 9 Sep 2009 13:09:23 -0700
> From: Amit Kumar Salecha <amit@qlogic.com>
>
> Fix the offset of vlan_TCI field in cmd_desc_type0.
>
> Signed-off-by: Amit Kumar Salecha <amit@qlogic.com>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:19 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.181033.25374239.davem@davemloft.net>
David Miller wrote:
> From: Matheos Worku <Matheos.Worku@Sun.COM>
> Date: Wed, 09 Sep 2009 18:01:23 -0700
>
>> The frame type in NIU HW is embedded in a HW header, so it is possible
>> to check the HW header and decide whether to pull up ETH_HLEN or VLAN
>> header size of bytes. However, considering the amount of work required
>> to get and examine the HW header (including endianess issues), we
>> thought pulling up 64 bytes by default (as used in cassini.c) would be
>> efficient.
>
> Well, it was 64 in early versions of the driver, and I decreased it
> down to ETH_HLEN.
>
> The less the better since for forwarding applications anything past
> the IPV4 header pulled is going to be a waste of CPU cache lines and
> thus negatively effect forwarding rates.
>
> That's why I asked if this change was performance regression tested,
> because I know it's going to slow down forwarding rates for small
> packets.
Dave,
We did throughput testing (netperf) and didn't notice any performance
degradation. We haven't done forwarding testing however.
We can work on a version which implements HW header checking and do
pullup accordingly.
Regards,
Matheos
> --
> 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] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 1:44 UTC (permalink / raw)
To: Matheos.Worku; +Cc: Joyce.Yu, netdev
In-Reply-To: <4AA85404.5020300@sun.com>
From: Matheos Worku <Matheos.Worku@Sun.COM>
Date: Wed, 09 Sep 2009 18:19:00 -0700
> We can work on a version which implements HW header checking and do
> pullup accordingly.
I think using a constant based on the vlan header size would be
sufficient to fix this.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:48 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.184410.64382338.davem@davemloft.net>
David Miller wrote:
> From: Matheos Worku <Matheos.Worku@Sun.COM>
> Date: Wed, 09 Sep 2009 18:19:00 -0700
>
>> We can work on a version which implements HW header checking and do
>> pullup accordingly.
>
> I think using a constant based on the vlan header size would be
> sufficient to fix this.
We will have a patch based on vlan header size.
Regards
Matheos
> --
> 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] dm9000: Use resource_size instead of private macro
From: David Miller @ 2009-09-10 1:55 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1252494464-4633-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 9 Sep 2009 13:07:43 +0200
> The macro res_size in drivers/net/dm9000.c is a copy of resource_size in
> linux/ioport.h. Remove the function and use resource_size instead.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH] dm9000: Remove unnecessary memset of netdev private data
From: David Miller @ 2009-09-10 1:55 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1252494464-4633-2-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 9 Sep 2009 13:07:44 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* [PATCH 1/3] phy/marvell: Make non-aneg speed/duplex forcing work for 88E1111 PHYs
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller
Cc: Andy Fleming, Timur Tabi, Li Yang, Kumar Gala, netdev,
linuxppc-dev
According to specs, when auto-negotiation is disabled, Marvell PHYs need
a software reset after changing speed/duplex forcing bits. Otherwise,
the modified bits have no effect.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/marvell.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index dd6f54d..6f69b9b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -155,8 +155,27 @@ static int marvell_config_aneg(struct phy_device *phydev)
return err;
err = genphy_config_aneg(phydev);
+ if (err < 0)
+ return err;
- return err;
+ if (phydev->autoneg != AUTONEG_ENABLE) {
+ int bmcr;
+
+ /*
+ * A write to speed/duplex bits (that is performed by
+ * genphy_config_aneg() call above) must be followed by
+ * a software reset. Otherwise, the write has no effect.
+ */
+ bmcr = phy_read(phydev, MII_BMCR);
+ if (bmcr < 0)
+ return bmcr;
+
+ err = phy_write(phydev, MII_BMCR, bmcr | BMCR_RESET);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
}
static int m88e1121_config_aneg(struct phy_device *phydev)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] ucc_geth: Rearrange some code to avoid forward declarations
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller
Cc: Andy Fleming, Timur Tabi, Li Yang, Kumar Gala, netdev,
linuxppc-dev
We'll need ugeth_disable() and ugeth_enable() calls earlier in the
file, so rearrange some code to avoid forward declarations.
The patch doesn't contain any functional changes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 300 ++++++++++++++++++++++++------------------------
1 files changed, 149 insertions(+), 151 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 33ed69e..2a2c973 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1411,6 +1411,155 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
return 0;
}
+static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+ u32 temp;
+ int i = 10;
+
+ uccf = ugeth->uccf;
+
+ /* Mask GRACEFUL STOP TX interrupt bit and clear it */
+ clrbits32(uccf->p_uccm, UCC_GETH_UCCE_GRA);
+ out_be32(uccf->p_ucce, UCC_GETH_UCCE_GRA); /* clear by writing 1 */
+
+ /* Issue host command */
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_GRACEFUL_STOP_TX, cecr_subblock,
+ QE_CR_PROTOCOL_ETHERNET, 0);
+
+ /* Wait for command to complete */
+ do {
+ msleep(10);
+ temp = in_be32(uccf->p_ucce);
+ } while (!(temp & UCC_GETH_UCCE_GRA) && --i);
+
+ uccf->stopped_tx = 1;
+
+ return 0;
+}
+
+static int ugeth_graceful_stop_rx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+ u8 temp;
+ int i = 10;
+
+ uccf = ugeth->uccf;
+
+ /* Clear acknowledge bit */
+ temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
+ temp &= ~GRACEFUL_STOP_ACKNOWLEDGE_RX;
+ out_8(&ugeth->p_rx_glbl_pram->rxgstpack, temp);
+
+ /* Keep issuing command and checking acknowledge bit until
+ it is asserted, according to spec */
+ do {
+ /* Issue host command */
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.
+ ucc_num);
+ qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
+ QE_CR_PROTOCOL_ETHERNET, 0);
+ msleep(10);
+ temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
+ } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
+
+ uccf->stopped_rx = 1;
+
+ return 0;
+}
+
+static int ugeth_restart_tx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+
+ uccf = ugeth->uccf;
+
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_RESTART_TX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET, 0);
+ uccf->stopped_tx = 0;
+
+ return 0;
+}
+
+static int ugeth_restart_rx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+
+ uccf = ugeth->uccf;
+
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_RESTART_RX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET,
+ 0);
+ uccf->stopped_rx = 0;
+
+ return 0;
+}
+
+static int ugeth_enable(struct ucc_geth_private *ugeth, enum comm_dir mode)
+{
+ struct ucc_fast_private *uccf;
+ int enabled_tx, enabled_rx;
+
+ uccf = ugeth->uccf;
+
+ /* check if the UCC number is in range. */
+ if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: ucc_num out of range.", __func__);
+ return -EINVAL;
+ }
+
+ enabled_tx = uccf->enabled_tx;
+ enabled_rx = uccf->enabled_rx;
+
+ /* Get Tx and Rx going again, in case this channel was actively
+ disabled. */
+ if ((mode & COMM_DIR_TX) && (!enabled_tx) && uccf->stopped_tx)
+ ugeth_restart_tx(ugeth);
+ if ((mode & COMM_DIR_RX) && (!enabled_rx) && uccf->stopped_rx)
+ ugeth_restart_rx(ugeth);
+
+ ucc_fast_enable(uccf, mode); /* OK to do even if not disabled */
+
+ return 0;
+
+}
+
+static int ugeth_disable(struct ucc_geth_private *ugeth, enum comm_dir mode)
+{
+ struct ucc_fast_private *uccf;
+
+ uccf = ugeth->uccf;
+
+ /* check if the UCC number is in range. */
+ if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: ucc_num out of range.", __func__);
+ return -EINVAL;
+ }
+
+ /* Stop any transmissions */
+ if ((mode & COMM_DIR_TX) && uccf->enabled_tx && !uccf->stopped_tx)
+ ugeth_graceful_stop_tx(ugeth);
+
+ /* Stop any receptions */
+ if ((mode & COMM_DIR_RX) && uccf->enabled_rx && !uccf->stopped_rx)
+ ugeth_graceful_stop_rx(ugeth);
+
+ ucc_fast_disable(ugeth->uccf, mode); /* OK to do even if not enabled */
+
+ return 0;
+}
+
/* Called every time the controller might need to be made
* aware of new link state. The PHY code conveys this
* information through variables in the ugeth structure, and this
@@ -1586,157 +1735,6 @@ static int init_phy(struct net_device *dev)
return 0;
}
-
-
-static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
- u32 temp;
- int i = 10;
-
- uccf = ugeth->uccf;
-
- /* Mask GRACEFUL STOP TX interrupt bit and clear it */
- clrbits32(uccf->p_uccm, UCC_GETH_UCCE_GRA);
- out_be32(uccf->p_ucce, UCC_GETH_UCCE_GRA); /* clear by writing 1 */
-
- /* Issue host command */
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_GRACEFUL_STOP_TX, cecr_subblock,
- QE_CR_PROTOCOL_ETHERNET, 0);
-
- /* Wait for command to complete */
- do {
- msleep(10);
- temp = in_be32(uccf->p_ucce);
- } while (!(temp & UCC_GETH_UCCE_GRA) && --i);
-
- uccf->stopped_tx = 1;
-
- return 0;
-}
-
-static int ugeth_graceful_stop_rx(struct ucc_geth_private * ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
- u8 temp;
- int i = 10;
-
- uccf = ugeth->uccf;
-
- /* Clear acknowledge bit */
- temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- temp &= ~GRACEFUL_STOP_ACKNOWLEDGE_RX;
- out_8(&ugeth->p_rx_glbl_pram->rxgstpack, temp);
-
- /* Keep issuing command and checking acknowledge bit until
- it is asserted, according to spec */
- do {
- /* Issue host command */
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.
- ucc_num);
- qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
- QE_CR_PROTOCOL_ETHERNET, 0);
- msleep(10);
- temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
-
- uccf->stopped_rx = 1;
-
- return 0;
-}
-
-static int ugeth_restart_tx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
-
- uccf = ugeth->uccf;
-
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_RESTART_TX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET, 0);
- uccf->stopped_tx = 0;
-
- return 0;
-}
-
-static int ugeth_restart_rx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
-
- uccf = ugeth->uccf;
-
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_RESTART_RX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET,
- 0);
- uccf->stopped_rx = 0;
-
- return 0;
-}
-
-static int ugeth_enable(struct ucc_geth_private *ugeth, enum comm_dir mode)
-{
- struct ucc_fast_private *uccf;
- int enabled_tx, enabled_rx;
-
- uccf = ugeth->uccf;
-
- /* check if the UCC number is in range. */
- if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
- if (netif_msg_probe(ugeth))
- ugeth_err("%s: ucc_num out of range.", __func__);
- return -EINVAL;
- }
-
- enabled_tx = uccf->enabled_tx;
- enabled_rx = uccf->enabled_rx;
-
- /* Get Tx and Rx going again, in case this channel was actively
- disabled. */
- if ((mode & COMM_DIR_TX) && (!enabled_tx) && uccf->stopped_tx)
- ugeth_restart_tx(ugeth);
- if ((mode & COMM_DIR_RX) && (!enabled_rx) && uccf->stopped_rx)
- ugeth_restart_rx(ugeth);
-
- ucc_fast_enable(uccf, mode); /* OK to do even if not disabled */
-
- return 0;
-
-}
-
-static int ugeth_disable(struct ucc_geth_private * ugeth, enum comm_dir mode)
-{
- struct ucc_fast_private *uccf;
-
- uccf = ugeth->uccf;
-
- /* check if the UCC number is in range. */
- if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
- if (netif_msg_probe(ugeth))
- ugeth_err("%s: ucc_num out of range.", __func__);
- return -EINVAL;
- }
-
- /* Stop any transmissions */
- if ((mode & COMM_DIR_TX) && uccf->enabled_tx && !uccf->stopped_tx)
- ugeth_graceful_stop_tx(ugeth);
-
- /* Stop any receptions */
- if ((mode & COMM_DIR_RX) && uccf->enabled_rx && !uccf->stopped_rx)
- ugeth_graceful_stop_rx(ugeth);
-
- ucc_fast_disable(ugeth->uccf, mode); /* OK to do even if not enabled */
-
- return 0;
-}
-
static void ugeth_dump_regs(struct ucc_geth_private *ugeth)
{
#ifdef DEBUG
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] ucc_geth: Fix hangs after switching from full to half duplex
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller
Cc: Andy Fleming, Timur Tabi, Li Yang, Kumar Gala, netdev,
linuxppc-dev
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: mdio@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
PHY: mdio@e0102120:00 - Link is Down
PHY: mdio@e0102120:00 - Link is Up - 100/Half
NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at c01fcbd0 [verbose debug info unavailable]
NIP: c01fcbd0 LR: c01fcbd0 CTR: c0194e44
...
The cure is to disable the controller before changing speed/duplex
and enable it afterwards.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 2a2c973..9ad9015 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1631,9 +1631,13 @@ static void adjust_link(struct net_device *dev)
ugeth->oldspeed = phydev->speed;
}
+ ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
+
out_be32(&ug_regs->maccfg2, tempval);
out_be32(&uf_regs->upsmr, upsmr);
+ ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
+
if (!ugeth->oldlink) {
new_state = 1;
ugeth->oldlink = 1;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Daniel Walker @ 2009-09-10 3:47 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: davem, linux-kernel, netdev, i4ldeveloper, Hansjoerg Lipp
In-Reply-To: <20090909223205.E9D632269516@fifo99.com>
On Thu, 2009-09-10 at 00:32 +0200, Tilman Schmidt wrote:
> Daniel Walker wrote 07.09.09 16:30:
> > Yeah, it looks like the whole file needs a checkpatch clean up..
> Sounds
> like your not willing to do that?
>
> It's not a question of willingness. You may notice I did a lot of
> cleanup work already. But it's very time consuming work, and there has
> been more important work to attend to first.
>
> > Usually if a checkpatch cleanup comes
> first prior to all your other changes , it doesn't usually cloud the
> rest of the changes..
>
> Sure. But that would mean postponing the merging of bugfixes until
> someone finds the time to do a complete checkpatch cleanup of the
> affected code. I don't think that's a sensible approach.
You shouldn't be adding any new checkpatch errors, but you currently
are .. Just clean up the individual patches w/o the entire gigaset
driver, that should be do-able (it's even a basic submission
requirement). The other issue is that your adding new files which aren't
clean, those can certainly be cleaned up.
Daniel
^ 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