Re: What is in bcm43xx-wireless-dev.git?
On Sunday 14 January 2007 03:10, Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: I haven't looked at the code yet, but I tried to locate the bad commit. I tried commit a13f85d8a8eb40dfd157ab78c2fb91b5765b7b9d, which is your last merge, just before the SSB changes. Yeah, sure. I know that this is the commit which introduced this. Basically, you set up DMA on the PCI device, but use it on the SSB device. That's inconsistent. dma_alloc_coherent() is very picky on x86_64 and crashes if dev-dma_mask is NULL, which was the case for the SSB device. Looking at the patch, it's clear that the SSB device is used instead of the PCI device in some places. I restored the old logic. If you meant to switch to SSB devices, then please remove the last PCI references from that file. Already done. Please pull my tree and check if it still crashes. The patch is attached. It fixes the crash. I didn't check that it's complete. I really don't like the long chain of dereferences, and I hope you'll come up with something better. No. I don't think we have shorter chains in other subsystems like PCI. They are just hidden. We could probably get rid of one level in the DMA code, by embedding the DMA structs into the device struct. But I think there are more important things to do at the moment. I still cannot associate. The kernel log is attached. Notice massive assertion failures. Note that LO calibration is horribly broken in my tree. I guess that's what the assertion failures are about. You're right. So you have a very weak signal, if any. My 4318 has no signal, for example. So basically don't expect to be able to transmit any data. This includes association. Actually, I could scan, and I got 7 access points around. Only one is in my apartment. RX sensitivity is not quite as bad. But I think you should be able to assoc with a plain linville tree. Nope. Although I got DadWifi to work, and this message will we sent over it. So it's not like I'm missing something essential about d80211 stack. Well, I don't really know what to do all about this. It's strange. I have people reporting that exactly the same cards work and people reporting that exactly the same cards don't work over and over again. So, well. What to do? :) -- 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
Re: [patch]IPv6: fix BUG of ndisc_send_redirect()
In article [EMAIL PROTECTED] (at Sat, 13 Jan 2007 17:12:40 +0800), Li Yewang [EMAIL PROTECTED] says: When I tested IPv6 redirect function about kernel 2.6.19.1, and found that the kernel can send redirect packets whose target address is global address, and the target is not the actual endpoint of communication. : So, I think the send redirect function must check the target address also. It is not mandatory, however, it is better to do this. I agree. (Note: In usual, we do not install gateway'ed route with global next-hop.) Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - 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: What is in bcm43xx-wireless-dev.git?
Quoting Michael Buesch [EMAIL PROTECTED]: Already done. Please pull my tree and check if it still crashes. The crash is gone! Thanks! Still no association though. Actually, I could scan, and I got 7 access points around. Only one is in my apartment. RX sensitivity is not quite as bad. I see, the problem must be on the tx side then. Well, I don't really know what to do all about this. It's strange. I have people reporting that exactly the same cards work and people reporting that exactly the same cards don't work over and over again. So, well. What to do? :) I'll check in with a HostAP based AP and a separate sniffer, so I can see what's on the air and what the AP sees. -- Regards, Pavel Roskin - 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: What is in bcm43xx-wireless-dev.git?
On Sunday 14 January 2007 15:18, Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: Already done. Please pull my tree and check if it still crashes. The crash is gone! Thanks! Still no association though. Ok, nice. Can you send me a complete dmesg log after you brought up the card and tried to assoc/send some packets? -- 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
Re: What is in bcm43xx-wireless-dev.git?
Quoting Michael Buesch [EMAIL PROTECTED]: Ok, nice. Can you send me a complete dmesg log after you brought up the card and tried to assoc/send some packets? Attached. -- Regards, Pavel Roskin ACPI: PCI Interrupt :0c:00.0[A] - GSI 17 (level, low) - IRQ 17 PCI: Setting latency timer of device :0c:00.0 to 64 ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) ssb: Switching to ChipCommon core, index 0 ssb: Switching to PCI-E core, index 3 ssb: PCIcore in client mode found wmaster0: Selected rate control algorithm 'simple' ssb: Switching to IEEE 802.11 core, index 1 ssb: Switching to PCI-E core, index 3 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_d80211: Adding Interface type 2 bcm43xx_d80211: Found PHY: Version 4, Type 2, Revision 8 bcm43xx_d80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_d80211: Loading firmware version 351.126 (2006-07-29 05:54:02) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_d80211: Radio turned on bcm43xx_d80211: FIXME: Possibly broken code in bcm43xx_phy_initg() at drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c:1650 bcm43xx_d80211: Chip initialized bcm43xx_d80211: 32-bit DMA initialized bcm43xx_d80211: Wireless interface started wmaster0: Does not support passive scan, disabled wlan0: starting scan wlan0: scan completed bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0f:66:2f:ef:59 wlan0: authenticate with AP 00:0f:66:2f:ef:59 wlan0: authenticate with AP 00:0f:66:2f:ef:59 wlan0: authentication with AP 00:0f:66:2f:ef:59 timed out bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: starting scan wlan0: scan completed bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: starting scan wlan0: scan completed bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: starting scan bcm43xx_d80211: Wireless interface stopped bcm43xx_d80211: Removing Interface type 2 bcm43xx_d80211: DMA-32 0x0200 (RX) max used slots: 1/64 bcm43xx_d80211: DMA-32 0x02A0 (TX) max used slots: 0/128 bcm43xx_d80211: DMA-32 0x0280 (TX) max used slots: 0/128 bcm43xx_d80211: DMA-32 0x0260 (TX) max used slots: 0/128 bcm43xx_d80211: DMA-32 0x0240 (TX) max used slots: 0/128 bcm43xx_d80211: DMA-32 0x0220 (TX) max used slots: 2/128 bcm43xx_d80211: DMA-32 0x0200 (TX) max used slots: 0/128 bcm43xx_d80211: Radio turned off ssb: Switching to ChipCommon core, index 0 bcm43xx_d80211: Adding Interface type 2 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_d80211: Found PHY: Version 4, Type 2, Revision 8 bcm43xx_d80211: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 bcm43xx_d80211: Loading firmware version 351.126 (2006-07-29 05:54:02) ssb: Switching to ChipCommon core, index 0 ssb: Switching to IEEE 802.11 core, index 1 bcm43xx_d80211: Radio turned on bcm43xx_d80211: FIXME: Possibly broken code in bcm43xx_phy_initg() at drivers/net/wireless/d80211/bcm43xx/bcm43xx_phy.c:1650 bcm43xx_d80211: Chip initialized bcm43xx_d80211: 32-bit DMA initialized bcm43xx_d80211: Wireless interface started wmaster0: Does not support passive scan, disabled bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: starting scan wlan0: scan completed bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: starting scan wlan0: scan completed bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0f:66:2f:ef:59 wlan0: authenticate with AP 00:0f:66:2f:ef:59 wlan0: authenticate with AP 00:0f:66:2f:ef:59 wlan0: authentication with AP 00:0f:66:2f:ef:59 timed out bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff wlan0: starting scan wlan0: scan completed bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_d80211: Using hardware based encryption for keyidx: 0, mac: ff:ff:ff:ff:ff:ff bcm43xx_d80211: Wireless interface stopped bcm43xx_d80211: Removing Interface type 2 bcm43xx_d80211: DMA-32 0x0200 (RX) max used slots: 1/64 bcm43xx_d80211: DMA-32 0x02A0 (TX) max used slots: 0/128 bcm43xx_d80211: DMA-32 0x0280 (TX) max used slots: 0/128 bcm43xx_d80211: DMA-32 0x0260 (TX) max used slots: 0/128
Re: What is in bcm43xx-wireless-dev.git?
On Sunday 14 January 2007 17:39, Pavel Roskin wrote: Quoting Michael Buesch [EMAIL PROTECTED]: Ok, nice. Can you send me a complete dmesg log after you brought up the card and tried to assoc/send some packets? Attached. Ok, thanks. I don't see something unusual. You should try to monitor traffic and see if the card is able to transmit packets. It seems like it's able to receive. -- 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] [IPV6] MCAST: Fix joining all-node multicast group on device initialization.
[IPV6] MCAST: Fix joining all-node multicast group on device initialization.
Join all-node multicast group after assignment of dev-ip6_ptr
because it must be assigned when ipv6_dev_mc_inc() is called.
This fixes Bug#7817, reported by [EMAIL PROTECTED].
Closes: 7817
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 171e5b5..2a7e461 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -341,6 +341,7 @@ void in6_dev_finish_destroy(struct inet6_dev *idev)
static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
{
struct inet6_dev *ndev;
+ struct in6_addr maddr;
ASSERT_RTNL();
@@ -425,6 +426,11 @@ static struct inet6_dev * ipv6_add_dev(struct net_device
*dev)
#endif
/* protected by rtnl_lock */
rcu_assign_pointer(dev-ip6_ptr, ndev);
+
+ /* Join all-node multicast group */
+ ipv6_addr_all_nodes(maddr);
+ ipv6_dev_mc_inc(dev, maddr);
+
return ndev;
}
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index a1c231a..882cde4 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -2258,8 +2258,6 @@ void ipv6_mc_up(struct inet6_dev *idev)
void ipv6_mc_init_dev(struct inet6_dev *idev)
{
- struct in6_addr maddr;
-
write_lock_bh(idev-lock);
rwlock_init(idev-mc_lock);
idev-mc_gq_running = 0;
@@ -2275,10 +2273,6 @@ void ipv6_mc_init_dev(struct inet6_dev *idev)
idev-mc_maxdelay = IGMP6_UNSOLICITED_IVAL;
idev-mc_v1_seen = 0;
write_unlock_bh(idev-lock);
-
- /* Add all-nodes address. */
- ipv6_addr_all_nodes(maddr);
- ipv6_dev_mc_inc(idev-dev, maddr);
}
/*
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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 V2] bcm43xx: Fix failure to deliver PCI-E interrupts
I sent this to the list but I don't know if it got to the list. On 1/14/07, evan foss [EMAIL PROTECTED] wrote: Results so far In a word Wow. It still doesn't work but I suspect that is could just be my configuration. Power levels are not being reported correctly all the time iwlist works but nothing else to my knowledge. I remember there being talk of power level reporting patches. Is there anything I can try adding. For the first time in a long time it does associate with AP's but I can't dhcpcd eth1. I am using an access point next door. Mine is down. I will test it with a good one at school on Tuesday. To recap I am on... MFG: Compaq V3000 (V3019US) CPU: AMD Turion 64 x2 Kernel: linux-2.6.18-gentoo-r2 I have SMP on and I am in 64 bit. BCM Chip: BCM4311 BCM FW: V3 Sorry I don't recall exactly what version Patches used patch_2.6.18.1_fix_leds patch_2.6.18.1_for_PCI-E radio_hwenable_for_2.6.18 The following work ifconfig eth1 up iwconfig eth1 essid NAME channel # kismet -c bcm43xx,eth1,bcm43xx iwlist eth1 scan-the power levels are reported here The following don't work iwconfig-the power levels are reported as always being 0 kismet -no power levels are reported LED -always off (I have a slider switch on the front to turn radio on/off) dhcpcd eth1 -low transmit power??? #The following don't work but might be my fault (I will get back to you later on these) dhcpcd eth1 #example bad iwconfig power level reporting eth1 IEEE 802.11b/g ESSID:linksys Nickname:Broadcom 4311 Mode:Managed Frequency=2.437 GHz Access Point: 00:16:B6:43:DE:C4 Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 -- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.com/ -- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.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
[Fwd: [Netem] [PATCH 2.6.18 0/2] LARTC: trace control for netem]
Hi Stephen I just wanted to ask you, if you already had time to test our trace extension for netem as discussed on the 13th of December. Cheers Rainer Rainer Baumann wrote: Hi Stephen As discussed yesterday, here our patches to integrate trace control into netem Trace Control for Netem: Emulate network properties such as long range dependency and self-similarity of cross-traffic. A new option (trace) has been added to the netem command. If the trace option is used, the values for packet delay etc. are read from a pregenerated trace file, afterwards the packets are processed by the normal netem functions. The packet action values are readout from the trace file in user space and sent to kernel space via configfs. ___ Netem mailing list [EMAIL PROTECTED] https://lists.osdl.org/mailman/listinfo/netem - 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 V2] bcm43xx: Fix failure to deliver PCI-E interrupts
evan foss wrote: Results so far In a word Wow. It still doesn't work but I suspect that is could just be my configuration. Power levels are not being reported correctly all the time iwlist works but nothing else to my knowledge. I remember there being talk of power level reporting patches. Is there anything I can try adding. For the first time in a long time it does associate with AP's but I can't dhcpcd eth1. I am using an access point next door. Mine is down. I will test it with a good one at school on Tuesday. To recap I am on... MFG: Compaq V3000 (V3019US) CPU: AMD Turion 64 x2 Kernel: linux-2.6.18-gentoo-r2 I have SMP on and I am in 64 bit. BCM Chip: BCM4311 BCM FW: V3 Sorry I don't recall exactly what version Patches used patch_2.6.18.1_fix_leds patch_2.6.18.1_for_PCI-E radio_hwenable_for_2.6.18 To get signal levels reported correctly, you also need patch_2.6.18.1_signal_quality. The following work ifconfig eth1 up iwconfig eth1 essid NAME channel # kismet -c bcm43xx,eth1,bcm43xx iwlist eth1 scan -the power levels are reported here The following don't work iwconfig -the power levels are reported as always being 0 kismet-no power levels are reported LED -always off (I have a slider switch on the front to turn radio on/off) This one needs watching. The LED has worked on previous computers. dhcpcd eth1 -low transmit power??? Most likely. How far are you from the AP? #The following don't work but might be my fault (I will get back to you later on these) dhcpcd eth1 #example bad iwconfig power level reporting eth1 IEEE 802.11b/g ESSID:linksys Nickname:Broadcom 4311 Mode:Managed Frequency=2.437 GHz Access Point: 00:16:B6:43:DE:C4 Bit Rate=1 Mb/s Tx-Power=18 dBm RTS thr:off Fragment thr:off Encryption key:off Link Quality=0/100 Signal level=-256 dBm Noise level=-256 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 The received signal and noise levels should be fixed by the patch listed above. Larry - 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]IPv6: fix BUG of ndisc_send_redirect()
YOSHIFUJI Hideaki / 吉藤英明 says: It is not mandatory, however, it is better to do this. I agree. (Note: In usual, we do not install gateway'ed route with global next-hop.) Yes, but if somebody set the route with global next-hop, or some other reasons, the next-hop with global address. The kernel must deal with this situation correctly. So, for the strongly of the kernel, I think redirect function must check the target address when send redirect packets. Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - 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 - 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: [Bugme-new] [Bug 7817] New: commit edfe21a29b1dca9ce5a938317868066d2e21c385 breaks IPv6 address autoconfiguration
On Sat, 13 Jan 2007, Andrew Morton wrote: On Sat, 13 Jan 2007 05:44:39 -0800 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=7817 Summary: commit edfe21a29b1dca9ce5a938317868066d2e21c385 breaks IPv6 address autoconfiguration Kernel Version: 2.6.19.2 Status: NEW Severity: high Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.19.1 Distribution: Debian Testing Hardware Environment: About 100 different x86 boxes Software Environment: no special software involved, just the kernel. No modules are loaded on the affected machines (everything needed is built into the kernel) I got hit by this as well. 2.6.20rc4-git4 is also affected. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - 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
