Re: skge error; hangs w/ hardware memory hole
* Andi Kleen [EMAIL PROTECTED] [2006-07-07 23:28]: Is that a board with VIA chipset? Yes, according to lspci, there's a VIA K8T800Pro and VT8237. :00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] (prog-if 00 [Normal decode]) :00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: starting mc triggers lockdep
On Sat, 2006-07-08 at 13:00 +1000, Herbert Xu wrote: Arjan van de Ven [EMAIL PROTECTED] wrote: i_mutex is taken within rtln_mutex like this: [8030f4a0] create_dir+0x2c/0x1e2 [8030fa5b] sysfs_create_dir+0x59/0x78 [8034d2e2] kobject_add+0x114/0x1d8 [803bb1e7] class_device_add+0xb5/0x49d [804300b1] netdev_register_sysfs+0x98/0xa2 [80426f58] register_netdevice+0x28c/0x376 [8042709c] register_netdev+0x5a/0x69 creating the AB dependency This is a sysfs inode. now for the third part, which involves the nfs client: stat on an nfs file, which ends up taken the i_mutex of a directory in the path (obvious), and then does [8022800b] tcp_sendmsg+0x1e/0xb1a [80248f4b] inet_sendmsg+0x45/0x53 [80259d25] sock_sendmsg+0x110/0x130 [8041f462] kernel_sendmsg+0x3c/0x52 [885399e9] xs_tcp_send_request+0x117/0x320 [sunrpc] [885388d5] xprt_transmit+0x105/0x21e [sunrpc] [8853771e] call_transmit+0x1f4/0x239 [sunrpc] [8853c06e] __rpc_execute+0x9b/0x1e6 [sunrpc] [8853c1de] rpc_execute+0x1a/0x1d [sunrpc] [885364ad] rpc_call_sync+0x87/0xb9 [sunrpc] [885a2587] nfs3_rpc_wrapper+0x2e/0x74 [nfs] [885a2a14] nfs3_proc_lookup+0xe0/0x163 [nfs] where tcp_sendmsg calls lock_sock. So this is the BC dependency. This is an nfs inode. Did I miss something? is it not possible to nfs export /sys, and then mount it over loopback? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] correct dev_alloc_skb kerneldoc
On Fri, Jul 07, 2006 at 04:55:27PM -0700, David Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 15:52:55 -0700 What is the point of dev_alloc_skb anyway? all it does is add header space. In stone-age times it actually had specific semantics, but yes today it is just a synonym. It's going to be hard to get rid of it, every single network driver out there references it. On powerpc64 it actually makes a difference because it now allocates the right headerspace as pad to ge the higher layer protocol headers aligned for best dma performance. Now what lead me up to this patch is something else. On the Cell hardware we badly need to allocate rx buffers on the local node, because the access to memory on a different node is horrible slow (thank rambus!) My plan is to give dev_alloc_skb a struct netdevice * argument and introduce a alloc_netdev_node so the driver can tell what node the device is on. This gives a significant speedup for cell. I already have this implemented in fact but only converted a handfull of drivers. Does this approach sound okay? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-mm3
Stephen Hemminger napisał(a):
On Tue, 27 Jun 2006 16:12:42 +0200
Michal Piotrowski [EMAIL PROTECTED] wrote:
Hi,
On 27/06/06, Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm3/
It looks like a skge bug
=
[ INFO: possible irq lock inversion dependency detected ]
-
swapper/0 just changed the state of lock:
(tasklist_lock){..-?}, at: [c0128092] send_group_sig_info+0x16/0x34
but this lock took another, soft-irq-unsafe lock in the past:
(sig-stats_lock){--..}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
no locks held by swapper/0.
the first lock's dependencies:
- (tasklist_lock){..-?} ops: 13763 {
initial-use at:
[c01353ab] lock_acquire+0x60/0x80
[c02d0ce2] _write_lock_irq+0x29/0x38
[c011c4e3] copy_process+0xea7/0x13c0
[c011cc6a] do_fork+0x8d/0x18f
[c010136c] kernel_thread+0x6c/0x74
[c0100518] rest_init+0x14/0x3c
[c03b6769] start_kernel+0x388/0x390
[c0100210] 0xc0100210
in-softirq-R at:
[..]
Here is a dmesg log
http://www.stardust.webpages.pl/files/mm/2.6.17-mm3/mm-dmesg
That file no longer exists...
It was moved, sorry.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
* jamal [EMAIL PROTECTED] 2006-07-01 09:35 On Sat, 2006-01-07 at 13:28 +0200, Thomas Graf wrote: Please enlighten me, I may be making a wrong assumption again. 1) tc_verd is reset to 0 after dq in ri_tasklet() 2) TC_AT is set to AT_EGRESS in dev_queue_xmit() 3) TC_FROM being derived from TC_AT in tcf_mirred() when redirecting 4) TC_FROM has the value AT_EGRESS when entering ifb_xmit() Let me answer the next bit and it may clear this. It's pretty clear actually, given eth0-ifb0-ifb1 it would look like: dev_queue_xmit(eth0) tcf_mirred - ifb0 dev_queue_xmit(ifb0) tcf_mirred - ifb1 dev_queue_xmit(ifb1) ifb_xmit(ifb1) QUEUE /* Here we queue the packet for the first time and release the stack of tx locks acquired on the way. TC_FROM was never reset up here so this can't possibly prevent any tx deadlocks. However, the !from check is effective later on ... */ ri_tasklet(ifb1) dev_queue_xmit(ifb0) ifb_xmit(ifb0) /* classification disabled */ /* Drop due to !from with input_dev = ifb1 which is good as it prevents to loop the packet back to ifb1 again which I refered to earlier */ Is this how it was intented? using what i said as looping in the case of A-B-C-D-A for the case of egress since that is what you are alluding to; note that ifb0 will be entered twice: First for example the tasklet in ifb0 will emit the packet, and then it will go all the way back to xmit on ifb0. This is where the issue is. Does that clear it? I tried to stay out of A-B-A for now since that's currently broken due to mirred unless the deadlock is intentional, f.e. when setting up eth0-ifb0-eth0 like this: ip link set ifb0 up tc qdisc add dev ifb0 parent root handle 1: prio tc qdisc add dev eth0 parent root handle 1: prio tc filter add dev eth0 parent 1: protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:1 action mirred egress redirect dev ifb0 tc filter add dev ifb0 parent 1: protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:1 action mirred egress redirect dev eth0 The following deadlock will ocur: dev_queue_xmit(eth0) tcf_mirred - ifb0 /* acquire tcf_mirred-lock on eth0 */ dev_queue_xmit(ifb0) tcf_mirred - eth0 /* acquire tcf_mirred-lock on ifb0 dev_queue_xmit(eth0) tcf_mirred - ifb0 /* deadlock */ This is assuming that no tx deadlock happens of course. I did try this out just to make sure, the machine just hung. I can't see any code trying to prevent this but this is another discussion as ifb is not involved in this, I think it's purely a problem of mirred. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: Fix IPv4/DECnet routing rule dumping
[NET]: Fix IPv4/DECnet routing rule dumping
When more rules are present than fit in a single skb, the remaining rules
are incorrectly skipped.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 68fb2d31c9c960fea945f8ed81ba2200cde104d4
tree 603c24a722ebe9834b7ae337ba9f6d69cbb6258f
parent 120bda20c6f64b32e8bfbdd7b34feafaa5f5332e
author Patrick McHardy [EMAIL PROTECTED] Fri, 07 Jul 2006 22:32:11 +0200
committer Patrick McHardy [EMAIL PROTECTED] Fri, 07 Jul 2006 22:32:11 +0200
net/decnet/dn_rules.c |3 ++-
net/ipv4/fib_rules.c |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/decnet/dn_rules.c b/net/decnet/dn_rules.c
index 06e785f..22f321d 100644
--- a/net/decnet/dn_rules.c
+++ b/net/decnet/dn_rules.c
@@ -399,9 +399,10 @@ int dn_fib_dump_rules(struct sk_buff *sk
rcu_read_lock();
hlist_for_each_entry(r, node, dn_fib_rules, r_hlist) {
if (idx s_idx)
- continue;
+ goto next;
if (dn_fib_fill_rule(skb, r, cb, NLM_F_MULTI) 0)
break;
+next:
idx++;
}
rcu_read_unlock();
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index 6c642d1..773b12b 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -457,13 +457,13 @@ int inet_dump_rules(struct sk_buff *skb,
rcu_read_lock();
hlist_for_each_entry(r, node, fib_rules, hlist) {
-
if (idx s_idx)
- continue;
+ goto next;
if (inet_fill_rule(skb, r, NETLINK_CB(cb-skb).pid,
cb-nlh-nlmsg_seq,
RTM_NEWRULE, NLM_F_MULTI) 0)
break;
+next:
idx++;
}
rcu_read_unlock();
Re: starting mc triggers lockdep
On Sat, Jul 08, 2006 at 11:53:20AM +0200, Arjan van de Ven wrote:
now for the third part, which involves the nfs client:
stat on an nfs file, which ends up taken the i_mutex of a directory in
the path (obvious), and then does
[8022800b] tcp_sendmsg+0x1e/0xb1a
[80248f4b] inet_sendmsg+0x45/0x53
[80259d25] sock_sendmsg+0x110/0x130
[8041f462] kernel_sendmsg+0x3c/0x52
[885399e9] xs_tcp_send_request+0x117/0x320 [sunrpc]
[885388d5] xprt_transmit+0x105/0x21e [sunrpc]
[8853771e] call_transmit+0x1f4/0x239 [sunrpc]
[8853c06e] __rpc_execute+0x9b/0x1e6 [sunrpc]
[8853c1de] rpc_execute+0x1a/0x1d [sunrpc]
[885364ad] rpc_call_sync+0x87/0xb9 [sunrpc]
[885a2587] nfs3_rpc_wrapper+0x2e/0x74 [nfs]
[885a2a14] nfs3_proc_lookup+0xe0/0x163 [nfs]
where tcp_sendmsg calls lock_sock. So this is the BC dependency.
This is an nfs inode.
Did I miss something?
is it not possible to nfs export /sys, and then mount it over loopback?
Possibly, but not with the backtrace above. You'd need an nfs server
backtrace to get the real sysfs inode.
In any case, the sock lock from the other backtrace that you had
(udp setsockopt) cannot be held by the kernel nfs client or server
since the kernel nfs sockets are not visible to user space.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: airo maybe should select crypto_aes
Hi, Herbert Xu schrieb: First of your patch is space-damaged. Please make sure that the original tabs are preserved and resend. Sorry for that, hope it fits this time. Also, wireless patches should be sent to this list with a cc to John W. Linville [EMAIL PROTECTED]. Didn't know that. With kind regards, Robert Schulze --- linux-2.6.17.1/drivers/net/wireless/Kconfig.orig 2006-07-03 17:37:02.0 +0200 +++ linux-2.6.17.1/drivers/net/wireless/Kconfig 2006-07-03 17:36:44.0 +0200 @@ -419,6 +419,7 @@ config AIRO_CS tristate Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards depends on NET_RADIO PCMCIA (BROKEN || !M32R) select CRYPTO + select CRYPTO_AES ---help--- This is the standard Linux driver to support Cisco/Aironet PCMCIA 802.11 wireless cards. This driver is the same as the Aironet - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211 sysfs
Hi,
I have recently updated the 80211 stack located in the rt2x00 CVS tree to
use the latest version of the stack from the dscape#devel git tree.
I also added the scanning patch from GertJan that was only available
in the dscape#main tree.
Since I didn't want to loose any tested because of the new field in
the net_device structure,
I have used the base_addr field instead and used the following access functions:
static inline void* get_80211_ptr(struct net_device *dev)
{
return (void*)dev-base_addr;
}
static inline void set_80211_ptr(struct net_device *dev, void* ptr)
{
dev-base_addr = (unsigned long)ptr;
}
But since this update my testers are reporting the following issue:
unmounting old /sys
INIT: version 2.86 booting
Welcome to Fedora Core
Press 'I' to enter interactive startup.
Setting clock (localtime): Tue Jul 4 21:59:40 BST 2006
[ OK ]
Starting udev: [ cut here ]
kernel BUG at fs/sysfs/symlink.c:88!
invalid opcode: [#1]
SMP
last sysfs file: /class/usb_device/usbdev5.1/dev
Modules linked in: rt2500usb(U) 80211(U) tuner
snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy
snd_seq_oss snd_seq_midi_event snd_seq ohci1394
ieee1394 saa7134 video_buf compat_ioctl32 v4l2_common
v4l1_compat ir_kbd_i2c ir_common snd_seq_device
ehci_hcd uhci_hcd 8139cp sg snd_pcm_oss snd_mixer_oss
videodev nvidia(U) snd_pcm 8139too mii snd_timer snd
e1000 soundcore snd_page_alloc i2c_i801 i2c_core
hw_random i82875p_edac edac_mc ext3 jbd ata_piix
sata_promise libata aic7xxx scsi_transport_spi sd_mod
scsi_mod
CPU: 2
EIP: 0060:[c019bca4] Tainted: P VLI
EFLAGS: 00010246 (2.6.16-1.2133_FC5smp #1)
EIP is at sysfs_create_link+0x17/0xd3
eax: f6f442fc ebx: f6f46470 ecx: f8d61cd2 edx: f6d8f090
esi: f8d61cd2 edi: f6f442fc ebp: esp: f6c8cd50
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1722, threadinfo=f6c8c000
task=c33f95b0)
Stack: 0f6d8f090 f6f46470 f6f44000
f6f442fc f8d5ac59
f6f46470 f6d8f000 f6f44000 f8d4e982
f6f46470 f6f46460
0010 f8ba4d80 f6f44000 f6f46468 14850001 dead4ead
d7851400 100a
Call Trace:
[f8d5ac59] ieee80211_sysfs_add_netdevice+0x20/0x55
[80211] [f8d4e982] ieee80211_register_hw+0xbe/0x20e
[80211]
[f8ba4d80] rt2500usb_alloc_dev+0x387/0x995
[rt2500usb] [c023d34a] __driver_attach+0x0/0x8f
[f8ba6be0] rt2500usb_probe+0x55/0x80 [rt2500usb]
[c02769e2] usb_probe_interface+0x58/0x86
[c023d295] driver_probe_device+0x42/0x8b [c023d3af]
__driver_attach+0x65/0x8f
[c023cd8b] bus_for_each_dev+0x33/0x55 [c023d1f9]
driver_attach+0x11/0x13
[c023d34a] __driver_attach+0x0/0x8f [c023caac]
bus_add_driver+0x64/0xfd
[c02767e5] usb_register_driver+0x73/0xd0 [c013bfdb]
sys_init_module+0x1701/0x18a8
[c0160d8e] __kmalloc+0x0/0x81 [c01639fb]
do_sync_read+0xb8/0xf3
[c0134c83] autoremove_wake_function+0x0/0x2d
[c0163943] do_sync_read+0x0/0xf3
[c01642c5] vfs_read+0x9f/0x13e [c0164711]
sys_read+0x3c/0x63
[c0103db9] syscall_call+0x7/0xb 0Code: 81 20 31 c0
83 c4 10 5b 5e 5f 5d c3 8b 40 30 e9 f1 e4 ff ff 55 57
56 53 83 ec 0c 89 14 24 89 ce 8b 68 30 85 ed 74 04 85
c9 75 08 0f 0b 58 00 f7 c0 31 c0 8b 45 18 83 e8 80 e8
e4 bf 15 00 8b 45
The kernel BUG at fs/sysfs/symlink.c:88! means that the dev argument
in ieee80211_sysfs_add_netdevice has a problem since
dev-class_dev.kobj or dev-class_dev.kobj.dentry are NULL.
Could this problem be caused by my compatibility hack (which is indeed
ugly, but if I want testers that are willing to test rt2x00, than I
have to workaround that ieee80211_ptr field)
or is this some issue in the dscape stack?
Thanks.
Ivo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: starting mc triggers lockdep
On Sat, Jul 08, 2006 at 11:53:20AM +0200, Arjan van de Ven wrote: Did I miss something? is it not possible to nfs export /sys, and then mount it over loopback? No, it's not. A filesystem needs dedicated routines to support nfs exporting and sysfs doesn't have those. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
On Sat, 2006-08-07 at 10:14 -0400, Jamal Hadi Salim wrote:
I have a dated patch to mirred (may not apply cleanly)
Sorry forgot to attach the patch. Attached for real this time;-
that i believe
will fix this specific one. Try to see if it also fixes this case you
have.
I meant i know this works for eth0-eth0 i am not sure if it will fix
your specific case. I need my laptop at the moment ;-
If it does it will be an ok solution but not the best (because it
introduces an unnecessary check for the common case).
cheers,
jamal
diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 4fcccbd..d8946b3 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -208,6 +208,12 @@ bad_mirred:
skb2-dev = dev;
skb2-input_dev = skb-dev;
+ if (skb2-input_dev == skb2-dev) {
+ if (net_ratelimit())
+ printk( Mirred: Loop detected to %s\n,skb2-dev-name);
+ goto bad_mirred;
+ }
+
dev_queue_xmit(skb2);
spin_unlock(p-lock);
return p-action;
[PATCH] airo: make debug-like messages printed by airo_print_dbg()
I don't think that messages like
airo(eth1): cmd= 111
airo(eth1): status= 7f11
airo(eth1): Rsp0= 2
airo(eth1): Rsp1= 0
airo(eth1): Rsp2= 0
are interesting to normal users, so switch them from airo_print_err() to
airo_print_dbg().
Furthermore, remove implicit linefeed in those messages, as they are handled by
airo_print().
with kind regards,
Robert Schulze
--- linux-2.6.17.1/drivers/net/wireless/airo.c.orig 2006-07-08
14:02:12.0 +0200
+++ linux-2.6.17.1/drivers/net/wireless/airo.c 2006-07-08 17:36:08.0
+0200
@@ -3897,11 +3897,11 @@ static u16 issuecommand(struct airo_info
pRsp-rsp1 = IN4500(ai, RESP1);
pRsp-rsp2 = IN4500(ai, RESP2);
if ((pRsp-status 0xff00)!=0 pCmd-cmd != CMD_SOFTRESET) {
- airo_print_err(ai-dev-name, cmd= %x\n, pCmd-cmd);
- airo_print_err(ai-dev-name, status= %x\n, pRsp-status);
- airo_print_err(ai-dev-name, Rsp0= %x\n, pRsp-rsp0);
- airo_print_err(ai-dev-name, Rsp1= %x\n, pRsp-rsp1);
- airo_print_err(ai-dev-name, Rsp2= %x\n, pRsp-rsp2);
+ airo_print_dbg(ai-dev-name, cmd= %x, pCmd-cmd);
+ airo_print_dbg(ai-dev-name, status= %x, pRsp-status);
+ airo_print_dbg(ai-dev-name, Rsp0= %x, pRsp-rsp0);
+ airo_print_dbg(ai-dev-name, Rsp1= %x, pRsp-rsp1);
+ airo_print_dbg(ai-dev-name, Rsp2= %x, pRsp-rsp2);
}
// clear stuck command busy if necessary
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Hi! Marcus Better wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (For those haven't followed, this is about http://permalink.gmane.org/gmane.linux.network/38493 ) Francois Romieu wrote: Marcus Better [EMAIL PROTECTED] : I'm seeing this problem on my Acer Travelmate 223X laptop with built-in Realtek 8139: The ethernet stops working, usually after at most a few minutes operation. In a better world, you would narrow the suspect with a git bissect [1] between v2.6.15 and v2.6.16. I did, and the winner after 13 reboots is... commit de227f5f32775d86e5c780a7cffdd2e08574f7fb Author: Dave Airlie [EMAIL PROTECTED](none) Date: Wed Jan 25 15:31:43 2006 +1100 drm: i915 patches from Tungsten Graphics Fix CMDBUFFER path, add heap destroy and flesh out sarea for rotation (Tungsten Graphics) From: Alan Hourihane [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] I didn't believe it at first either, but blacklisting the i915 module actually fixes the problem. Now that I know what to look for, I notice that the network errors always started cropping up after X11 started. Wonder what's going on here. Why is the graphics driver killing my network? I guess you got the wrong commit, and the correct one should be the one where Dave adds vblank interrupts. It should be close to the one you listed. Some i915 chips have buggy interrupts. What happens is that the display interrupts are duplicated on the sound interrupt channel. Usually there's no interrupt handler there that recognizes them, and after a while, the kernel detects too many spurious interrupts and disables the sound IRQ line. If the network sits on the same IRQ line, it will be disabled as well. If you check your kernel logs, you will probably have messages about disabled IRQs. A workaround is to add the noirqdebug (I hope I remember the spelling correctly) kernel option at boot time. /Thomas Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEroy7XjXn6TzcAQkRAp7bAJ9F7HgWg+VsvQ0fwkK3+b4Ne+tASwCg8+m3 8i5BoW+ujUjoX3DLW0QKAPQ= =MDAc -END PGP SIGNATURE- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] work around/fix deadlock in the bcm43xx driver by making netlink irq safe
Arjan van de Ven wrote:
Joseph Jezak wrote:
Can you provide the details to the list? I'll look into getting
SoftMAC fixed if you do.
sure
the basic issue is that bcm43xx does it's rx processing in a softirq,
and holds the bcm-irq_lock during that time. The rx processing calls
into the softmac layer, which in turn calls into netlink.
With this you can get a deadlock that looks like this
cpu 0: user context |cpu1: softirq context
netlink_table_grab takes nl_table_lock as |take bcm-irq_lock in
write_lock_bh, but leaves irqs enabled |bcm43xx_interrupt_tasklet()
|which then in a few steps
|leads to a call to
|bcm43xx_rx
hardirq comes in and the isr tries to take |in bcm43xx_rx, call
bcm-irq_lock but has to wait on cpu 1 |ieee80211_rx_mgt which
|leads to a call to
|wireless_send_event which
|tries to take nl_table_lock
|for read but has to wait
|for cpu0
according to Michael Buesch, the softmac layer should queue the packet
internally for another softirq, similar to what DeviceScape does, so
that the rx softirq can just drop all packets quickly and drop its locks.
I think the deadlock dump shown below is related; however, since I have a uniprocessor system and
the deadlock is not exactly the same, I'll include it here. This is using v2.6.18-rc1 from Linus's tree.
kernel: - (af_callback_keys + sk-sk_family#2){-.-?} ops: 431 {
kernel:initial-use at:
kernel: [c0135d48] lock_acquire+0x68/0x90
kernel: [c030c195] _read_lock+0x45/0x60
kernel: [c02a786f] sock_def_readable+0x1f/0x90
kernel: [c02bf072] netlink_broadcast+0x282/0x320
kernel: [c01ef236] kobject_uevent+0x366/0x4c0
kernel: [c01eed08] kobject_register+0x48/0x60
kernel: [c013ce89] sys_init_module+0x1439/0x1870
kernel: [c01031cd] sysenter_past_esp+0x56/0x8d
kernel:hardirq-on-W at:
kernel: [c0135d48] lock_acquire+0x68/0x90
kernel: [c030c37a] _write_lock_bh+0x4a/0x60
kernel: [c02beba3] netlink_release+0xe3/0x330
kernel: [c02a439d] sock_release+0x1d/0xf0
kernel: [c02a44a7] sock_close+0x37/0x60
kernel: [c0163688] __fput+0xd8/0x210
kernel: [c01637d8] fput+0x18/0x20
kernel: [c0160574] filp_close+0x54/0x80
kernel: [c011a5df] put_files_struct+0x7f/0xd0
kernel: [c011b6cc] do_exit+0x12c/0x9a0
kernel: [c011bf7d] do_group_exit+0x3d/0xa0
kernel: [c011bff5] sys_exit_group+0x15/0x20
kernel: [c01031cd] sysenter_past_esp+0x56/0x8d
kernel:in-softirq-R at:
kernel: [c0135d48] lock_acquire+0x68/0x90
kernel: [c030c195] _read_lock+0x45/0x60
kernel: [c02a786f] sock_def_readable+0x1f/0x90
kernel: [c02bf072] netlink_broadcast+0x282/0x320
kernel: [c02bb6e4] wireless_send_event+0x244/0x3b0
kernel: [e4a2c586] ieee80211softmac_call_events_locked+0x86/0x140
[ieee80211softmac]
kernel: [e4a2c674]
ieee80211softmac_call_events+0x34/0x6f [ieee80211softmac]
kernel: [e4a28faf]
ieee80211softmac_auth_resp+0x19f/0x620 [ieee80211softmac]
kernel: [e4a1e413] ieee80211_rx_mgt+0x543/0x810
[ieee80211]
kernel: [e4a7ea2b] bcm43xx_rx+0x34b/0x980 [bcm43xx]
kernel: [e4a820bc] bcm43xx_dma_rx+0x23c/0x550
[bcm43xx]
kernel: [e4a6751e]
bcm43xx_interrupt_tasklet+0x38e/0x970 [bcm43xx]
kernel: [c011e4de] tasklet_action+0x4e/0x90
kernel: [c011ecc2] __do_softirq+0x62/0xe0
kernel: [c01055cb] do_softirq+0x9b/0xf0
kernel:softirq-on-R at:
kernel: [c0135d48] lock_acquire+0x68/0x90
kernel: [c030c195] _read_lock+0x45/0x60
kernel: [c02a786f] sock_def_readable+0x1f/0x90
kernel: [c02bf072] netlink_broadcast+0x282/0x320
kernel: [c01ef236] kobject_uevent+0x366/0x4c0
kernel: [c01eed08] kobject_register+0x48/0x60
kernel: [c013ce89] sys_init_module+0x1439/0x1870
Re: [patch] work around/fix deadlock in the bcm43xx driver by making netlink irq safe
On Saturday 08 July 2006 19:59, you wrote: kernel: stack backtrace: kernel: [c0103d1d] show_trace_log_lvl+0x13d/0x160 kernel: [c010525b] show_trace+0x1b/0x20 kernel: [c0105286] dump_stack+0x26/0x30 kernel: [c0133f7d] check_usage+0x26d/0x280 kernel: [c013536f] __lock_acquire+0x77f/0xdd0 kernel: [c0135d48] lock_acquire+0x68/0x90 kernel: [c030c195] _read_lock+0x45/0x60 kernel: [c02a786f] sock_def_readable+0x1f/0x90 kernel: [c02bf072] netlink_broadcast+0x282/0x320 kernel: [c02bb6e4] wireless_send_event+0x244/0x3b0 This is another fscking deadlock. But it should be fixed by the suggested workaround as well. So I see this problem solved for now, too. kernel: [e4a2c586] ieee80211softmac_call_events_locked+0x86/0x140 [ieee80211softmac] kernel: [e4a2c674] ieee80211softmac_call_events+0x34/0x6f [ieee80211softmac] kernel: [e4a28faf] ieee80211softmac_auth_resp+0x19f/0x620 [ieee80211softmac] kernel: [e4a1e413] ieee80211_rx_mgt+0x543/0x810 [ieee80211] kernel: [e4a7ea2b] bcm43xx_rx+0x34b/0x980 [bcm43xx] kernel: [e4a820bc] bcm43xx_dma_rx+0x23c/0x550 [bcm43xx] kernel: [e4a6751e] bcm43xx_interrupt_tasklet+0x38e/0x970 [bcm43xx] kernel: [c011e4de] tasklet_action+0x4e/0x90 kernel: [c011ecc2] __do_softirq+0x62/0xe0 kernel: [c01055cb] do_softirq+0x9b/0xf0 kernel: [c01056d1] do_IRQ+0xb1/0x110 kernel: [c0103439] common_interrupt+0x25/0x2c kernel: [c015e01e] kmem_cache_free+0x6e/0xa0 kernel: [c019631d] proc_destroy_inode+0x1d/0x20 kernel: [c017d7eb] destroy_inode+0x2b/0x60 kernel: [c017e753] generic_delete_inode+0xb3/0x100 kernel: [c017d8fd] iput+0x6d/0x80 kernel: [c017b79b] dentry_iput+0x7b/0xd0 kernel: [c017bee4] dput+0x84/0x190 kernel: [c0172194] path_release+0x14/0x30 kernel: [c017295a] __link_path_walk+0x3ea/0xef0 kernel: [c01734b4] link_path_walk+0x54/0xf0 kernel: [c017394e] do_path_lookup+0xae/0x260 kernel: [c017403a] __path_lookup_intent_open+0x4a/0x90 kernel: [c017410a] path_lookup_open+0x2a/0x30 kernel: [c01743a7] open_namei+0x77/0x6d0 kernel: [c0161898] do_filp_open+0x38/0x60 kernel: [c016190b] do_sys_open+0x4b/0x100 kernel: [c0161a17] sys_open+0x27/0x30 kernel: [c01031cd] sysenter_past_esp+0x56/0x8d kernel: [b7fb9410] 0xb7fb9410 kernel: SoftMAC: sent association request! kernel: SoftMAC: associated! kernel: SoftMAC: Scanning finished So far, this situation has only occurred during the initial association/authorization steps during bootup. BTW: Jiri, As you can see, various deadlocks are possible when calling directly from a driver tasklet into the 802.11 stack, because by the nature of the 802.11 we must call back into the driver at some places. So, I would like to get rid of the not _irqsafe functions in devicescape. The _irqsafe functions could be stripped by the postfix and the unsafe functions should be strictly internal to the stack. I don't see valid usages for them outside of the stack. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: init routine rewrite
Hi John,
Please apply this to wireless-2.6.
--
Rewrite of the bcm43xx initialization routines.
This fixes several issues:
* up-down-up-down-up... stale data issue
(May fix some DHCP issues)
* Fix the init vs IRQ handler race (and remove the workaround)
* Fix init for cards with multiple cores (APHY)
As softmac has no internal PHY handling (unlike dscape),
this adds the file phymode to sysfs.
The active PHY can be selected by writing either a, b or g
to this file. Current PHY can be determined by reading from it.
* Fix the controller restart code.
Controller restart can now also be triggered through
echo 1 /debug/bcm43xx/ethX/restart
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h2006-07-08
18:31:40.0 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-07-08
19:24:54.0 +0200
@@ -502,6 +502,12 @@
* This lock is only used by bcm43xx_phy_{un}lock()
*/
spinlock_t lock;
+
+ /* Firmware. */
+ const struct firmware *ucode;
+ const struct firmware *pcm;
+ const struct firmware *initvals0;
+ const struct firmware *initvals1;
};
@@ -591,12 +597,14 @@
u8 available:1,
enabled:1,
initialized:1;
- /** core_id ID number */
- u16 id;
/** core_rev revision number */
u8 rev;
/** Index number for _switch_core() */
u8 index;
+ /** core_id ID number */
+ u16 id;
+ /** Core-specific data. */
+ void *priv;
};
/* Additional information for each 80211 core. */
@@ -645,7 +653,10 @@
BCM43xx_STAT_RESTARTING,/* controller_restart() called. */
};
#define bcm43xx_status(bcm)atomic_read((bcm)-init_status)
-#define bcm43xx_set_status(bcm, stat) atomic_set((bcm)-init_status, (stat))
+#define bcm43xx_set_status(bcm, stat) do {\
+ atomic_set((bcm)-init_status, (stat));\
+ smp_wmb(); \
+ } while (0)
struct bcm43xx_private {
struct ieee80211_device *ieee;
@@ -706,10 +717,6 @@
struct bcm43xx_coreinfo core_80211[ BCM43xx_MAX_80211_CORES ];
/* Additional information, specific to the 80211 cores. */
struct bcm43xx_coreinfo_80211 core_80211_ext[ BCM43xx_MAX_80211_CORES ];
- /* Index of the current 80211 core. If current_core is not
-* an 80211 core, this is -1.
-*/
- int current_80211_core_idx;
/* Number of available 80211 cores. */
int nr_80211_available;
@@ -744,12 +751,6 @@
struct bcm43xx_key key[54];
u8 default_key_idx;
- /* Firmware. */
- const struct firmware *ucode;
- const struct firmware *pcm;
- const struct firmware *initvals0;
- const struct firmware *initvals1;
-
/* Debugging stuff follows. */
#ifdef CONFIG_BCM43XX_DEBUG
struct bcm43xx_dfsentry *dfsentry;
@@ -857,34 +858,33 @@
* any of these functions.
*/
static inline
+struct bcm43xx_coreinfo_80211 *
+bcm43xx_current_80211_priv(struct bcm43xx_private *bcm)
+{
+ assert(bcm-current_core-id == BCM43xx_COREID_80211);
+ return bcm-current_core-priv;
+}
+static inline
struct bcm43xx_pio * bcm43xx_current_pio(struct bcm43xx_private *bcm)
{
assert(bcm43xx_using_pio(bcm));
- assert(bcm-current_80211_core_idx = 0);
- assert(bcm-current_80211_core_idx BCM43xx_MAX_80211_CORES);
- return (bcm-core_80211_ext[bcm-current_80211_core_idx].pio);
+ return (bcm43xx_current_80211_priv(bcm)-pio);
}
static inline
struct bcm43xx_dma * bcm43xx_current_dma(struct bcm43xx_private *bcm)
{
assert(!bcm43xx_using_pio(bcm));
- assert(bcm-current_80211_core_idx = 0);
- assert(bcm-current_80211_core_idx BCM43xx_MAX_80211_CORES);
- return (bcm-core_80211_ext[bcm-current_80211_core_idx].dma);
+ return (bcm43xx_current_80211_priv(bcm)-dma);
}
static inline
struct bcm43xx_phyinfo * bcm43xx_current_phy(struct bcm43xx_private *bcm)
{
- assert(bcm-current_80211_core_idx = 0);
- assert(bcm-current_80211_core_idx BCM43xx_MAX_80211_CORES);
- return (bcm-core_80211_ext[bcm-current_80211_core_idx].phy);
+ return (bcm43xx_current_80211_priv(bcm)-phy);
}
static inline
struct bcm43xx_radioinfo * bcm43xx_current_radio(struct bcm43xx_private *bcm)
{
- assert(bcm-current_80211_core_idx = 0);
- assert(bcm-current_80211_core_idx BCM43xx_MAX_80211_CORES);
- return (bcm-core_80211_ext[bcm-current_80211_core_idx].radio);
+ return (bcm43xx_current_80211_priv(bcm)-radio);
}
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
[2.6 patch] net/atm/clip.c: fix PROC_FS=n compile
This patch fixes the following compile error with CONFIG_PROC_FS=n by
reverting commit dcdb02752ff13a64433c36f2937a58d93ae7a19e:
-- snip --
...
CC net/atm/clip.o
net/atm/clip.c: In function ‘atm_clip_init’:
net/atm/clip.c:975: error: ‘atm_proc_root’ undeclared (first use in this
function)
net/atm/clip.c:975: error: (Each undeclared identifier is reported only once
net/atm/clip.c:975: error: for each function it appears in.)
net/atm/clip.c:977: error: ‘arp_seq_fops’ undeclared (first use in this
function)
make[2]: *** [net/atm/clip.o] Error 1
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
net/atm/clip.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
--- linux-2.6.17-mm6-full/net/atm/clip.c.old2006-07-08 13:58:07.0
+0200
+++ linux-2.6.17-mm6-full/net/atm/clip.c2006-07-08 13:55:48.0
+0200
@@ -962,7 +962,6 @@
static int __init atm_clip_init(void)
{
- struct proc_dir_entry *p;
neigh_table_init_no_netlink(clip_tbl);
clip_tbl_hook = clip_tbl;
@@ -972,9 +971,15 @@
setup_timer(idle_timer, idle_timer_check, 0);
- p = create_proc_entry(arp, S_IRUGO, atm_proc_root);
- if (p)
- p-proc_fops = arp_seq_fops;
+#ifdef CONFIG_PROC_FS
+ {
+ struct proc_dir_entry *p;
+
+ p = create_proc_entry(arp, S_IRUGO, atm_proc_root);
+ if (p)
+ p-proc_fops = arp_seq_fops;
+ }
+#endif
return 0;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2][ATM]: Typo in drivers/atm/Kconfig...
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Fri, 07 Jul 2006 20:50:00 -0400 please consider for 2.6.18 -- thanks! [ATM]: Typo in drivers/atm/Kconfig... From: Matt LaPlante [EMAIL PROTECTED] Signed-off-by: Charles Williams [EMAIL PROTECTED] Applied, thanks Chas. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2][ATM]: fix possible recursive locking in skb_migrate()
From: chas williams - CONTRACTOR [EMAIL PROTECTED] Date: Fri, 07 Jul 2006 20:50:23 -0400 please consider for 2.6.18 -- thanks! [ATM]: fix possible recursive locking in skb_migrate() ok this is a real potential deadlock in a way, it takes two locks of 2 skbuffs without doing any kind of lock ordering; I think the following patch should fix it. Just sort the lock taking order by address of the skb.. it's not pretty but it's the best this can do in a minimally invasive way. Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] Signed-off-by: Chas Williams [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]NET: Add ECN support for TSO
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 18:01:34 -0700 However, Large Receive Offload will be a different story. If packets are accumulated in the hardware and presented to the stack as one large packet, the stack will not be able to calculate the cumulative NS correctly. Unless the hardware calculates the partial NS over the LRO packet and puts it in the SKB when handing over the packet. This is correct, LRO hardware would need to do something to make sure the nonce parity works out. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] fix drivers/net/irda/ali-ircc.c:ali_ircc_init()
From: Adrian Bunk [EMAIL PROTECTED] Date: Sat, 8 Jul 2006 03:28:05 +0200 The Coverity checker spotted, that from the changes from commit 898b1d16f8230fb912a0c2248df685735c6ceda3 the if (ret) platform_driver_unregister(ali_ircc_driver); was dead code. This patch changes this function to what seems to have been the intention. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: Fix IPv4/DECnet routing rule dumping
Applied, and pushed to -stable. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: jumbo frames and memory fragmentation
On Fri, Jun 30, 2006 at 05:35:34PM -0600, Chris Friesen ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: It definitely will. Packet split in hardware means separating data and headers into different pages in different reads, while software page split means that skb has a list of fragments where part of the packet will be DMAed, so jumbo frame will be converted into several pages. Maybe I'm looking at the wrong code then. Can you point me to where this software page split is handled? Yes, you are correct, e1000 only supports receiving page split for 82571 and greater adapters. Chris -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device
* Thomas Graf [EMAIL PROTECTED] 2006-07-09 01:46 __LINK_STATE_QDISC_RUNNING will prevent an eventual tx deadlock, it will not prevent the mirred deadlock. BTW, it will also not protect you from deadlocking on dev-queue_lock while enqueueing. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx-d80211: AccessPoint mode
Hi John,
Please apply this to wireless-dev.
--
This patch adds AP mode support to the bcm43xx-d80211 driver.
Initial patch from Alexander Tsvyashchenko. Thanks a lot!
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Cc: Francois Barre [EMAIL PROTECTED]
Cc: Alexander Tsvyashchenko [EMAIL PROTECTED]
Index:
wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===
---
wireless-dev-dscapeports.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-06-17 21:26:10.0 +0200
+++ wireless-dev-dscapeports/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
2006-06-19 11:25:02.0 +0200
@@ -151,8 +151,10 @@
{
u32 status;
+ assert(offset % 4 == 0);
+
status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- if (!(status BCM43xx_SBF_XFER_REG_BYTESWAP))
+ if (status BCM43xx_SBF_XFER_REG_BYTESWAP)
val = swab32(val);
bcm43xx_write32(bcm, BCM43xx_MMIO_RAM_CONTROL, offset);
@@ -312,7 +314,7 @@
}
}
-void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf)
+static void bcm43xx_time_lock(struct bcm43xx_private *bcm)
{
u32 status;
@@ -320,7 +322,19 @@
status |= BCM43xx_SBF_TIME_UPDATE;
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
mmiowb();
+}
+
+static void bcm43xx_time_unlock(struct bcm43xx_private *bcm)
+{
+ u32 status;
+
+ status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
+ status = ~BCM43xx_SBF_TIME_UPDATE;
+ bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
+}
+static void bcm43xx_tsf_write_locked(struct bcm43xx_private *bcm, u64 tsf)
+{
/* Be careful with the in-progress timer.
* First zero out the low register, so we have a full
* register-overflow duration to complete the operation.
@@ -350,10 +364,13 @@
mmiowb();
bcm43xx_write16(bcm, BCM43xx_MMIO_TSF_0, v0);
}
+}
- status = bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD);
- status = ~BCM43xx_SBF_TIME_UPDATE;
- bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
+void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf)
+{
+ bcm43xx_time_lock(bcm);
+ bcm43xx_tsf_write_locked(bcm, tsf);
+ bcm43xx_time_unlock(bcm);
}
static void bcm43xx_measure_channel_change_time(struct bcm43xx_private *bcm)
@@ -415,10 +432,11 @@
static void bcm43xx_write_mac_bssid_templates(struct bcm43xx_private *bcm)
{
static const u8 zero_addr[ETH_ALEN] = { 0 };
- const u8 *mac = NULL;
- const u8 *bssid = NULL;
+ const u8 *mac;
+ const u8 *bssid;
u8 mac_bssid[ETH_ALEN * 2];
int i;
+ u32 tmp;
bssid = bcm-interface.bssid;
if (!bssid)
@@ -431,12 +449,13 @@
memcpy(mac_bssid + ETH_ALEN, bssid, ETH_ALEN);
/* Write our MAC address and BSSID to template ram */
- for (i = 0; i ARRAY_SIZE(mac_bssid); i += sizeof(u32))
- bcm43xx_ram_write(bcm, 0x20 + i, *((u32 *)(mac_bssid + i)));
- for (i = 0; i ARRAY_SIZE(mac_bssid); i += sizeof(u32))
- bcm43xx_ram_write(bcm, 0x78 + i, *((u32 *)(mac_bssid + i)));
- for (i = 0; i ARRAY_SIZE(mac_bssid); i += sizeof(u32))
- bcm43xx_ram_write(bcm, 0x478 + i, *((u32 *)(mac_bssid + i)));
+ for (i = 0; i ARRAY_SIZE(mac_bssid); i += sizeof(u32)) {
+ tmp = (u32)(mac_bssid[i + 0]);
+ tmp |= (u32)(mac_bssid[i + 1]) 8;
+ tmp |= (u32)(mac_bssid[i + 2]) 16;
+ tmp |= (u32)(mac_bssid[i + 3]) 24;
+ bcm43xx_ram_write(bcm, 0x20 + i, tmp);
+ }
}
static void bcm43xx_set_slot_time(struct bcm43xx_private *bcm, u16 slot_time)
@@ -460,49 +479,6 @@
bcm-short_slot = 0;
}
-/* FIXME: To get the MAC-filter working, we need to implement the
- *following functions (and rename them :)
- */
-#if 0
-static void bcm43xx_disassociate(struct bcm43xx_private *bcm)
-{
- bcm43xx_mac_suspend(bcm);
- bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
-
- bcm43xx_ram_write(bcm, 0x0026, 0x);
- bcm43xx_ram_write(bcm, 0x0028, 0x);
- bcm43xx_ram_write(bcm, 0x007E, 0x);
- bcm43xx_ram_write(bcm, 0x0080, 0x);
- bcm43xx_ram_write(bcm, 0x047E, 0x);
- bcm43xx_ram_write(bcm, 0x0480, 0x);
-
- if (bcm-current_core-rev 3) {
- bcm43xx_write16(bcm, 0x0610, 0x8000);
- bcm43xx_write16(bcm, 0x060E, 0x);
- } else
- bcm43xx_write32(bcm, 0x0188, 0x8000);
-
- bcm43xx_shm_write32(bcm, BCM43xx_SHM_WIRELESS, 0x0004, 0x03ff);
-
-#if 0
- if (bcm43xx_current_phy(bcm)-type == BCM43xx_PHYTYPE_G
- ieee80211_is_ofdm_rate(bcm-softmac-txrates.default_rate))
- bcm43xx_short_slot_timing_enable(bcm);
-#endif
-
Re: [2.6 patch] net/ipv4/netfilter/: fix SYSCTL=n compile
Adrian Bunk wrote: This patch fixes the following compile error with CONFIG_SYSCTL=n introduced by commit 39a27a35c5c1b5be499a0576a35c45a011788bf8: My fault I guess. -- snip -- ... LD .tmp_vmlinux1 net/built-in.o: In function `tcp_error': ip_conntrack_proto_tcp.c:(.text+0x77af6): undefined reference to `ip_conntrack_checksum' net/built-in.o: In function `udp_error': ip_conntrack_proto_udp.c:(.text+0x78456): undefined reference to `ip_conntrack_checksum' net/built-in.o: In function `icmp_error': ip_conntrack_proto_icmp.c:(.text+0x7868f): undefined reference to `ip_conntrack_checksum' make: *** [.tmp_vmlinux1] Error 1 Thanks Adrian. Usually all bugs in ip_conntrack are duplicated in nf_conntrack, please update your patch to take care of that as well. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
