Re: 2.6.24-rc1: hangs when logging in to X session
Herbert Xu wrote: My laptop hangs when I try to log in to X with the current git kernel (commit 2a397e82c7db18019e408f953dd58dc1963a328c). It runs fine with 2.6.23. At boot time kdm starts normally, but hangs with the caps lock LED blinking immediately after I press Enter after typing the password. This was fixed after the changeset you quoted so if you update to the latest it should work again. Yes, it works now. Thanks, Marcus - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Krzysztof Halasa wrote: Lennert Buytenhek [EMAIL PROTECTED] writes: There _is_ an ARM BE version of Debian. It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is. Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround? Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there. Marcus - 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] Intel IXP4xx network drivers v.2 - Ethernet and HSS
Lennert Buytenhek wrote: Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better? Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver. Marcus pgpXZAXckxl8V.pgp Description: PGP signature
Re: dscape doesn't auto associate
Jon Smirl wrote: Has this project moved elsewhere? http://hostap.epitest.fi/wpa_supplicant Apparently it's down at this moment: http://permalink.gmane.org/gmane.linux.drivers.hostap/15287 - 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] d80211: select CRC32 functions
The d80211 stack requires CRC32 functions for the WEP implementation. Signed-off-by: Marcus Better [EMAIL PROTECTED] --- net/d80211/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/d80211/Kconfig b/net/d80211/Kconfig index 7e2635f..d91f0db 100644 --- a/net/d80211/Kconfig +++ b/net/d80211/Kconfig @@ -3,6 +3,7 @@ config D80211 select CRYPTO select CRYPTO_ARC4 select CRYPTO_AES + select CRC32 select WIRELESS_EXT ---help--- This option enables the hardware independent IEEE 802.11 -- - 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] cfg80211: Correct conditional compile of wext-common.c.
wext-common.o is required if CONFIG_WIRELESS_EXT is set. Looks like `CONFIG_NET_WIRELESS' is a typo. Signed-off-by: Marcus Better [EMAIL PROTECTED] --- a/net/wireless/Makefile +++ b/net/wireless/Makefile @@ -12,5 +12,5 @@ obj-ny := # this needs to be compiled in... obj-$(CONFIG_CFG80211_WEXT_COMPAT) += wext-compat.o -obj-$(CONFIG_CFG80211_WEXT_COMPAT)$(CONFIG_NET_WIRELESS) += wext-common.o +obj-$(CONFIG_CFG80211_WEXT_COMPAT)$(CONFIG_WIRELESS_EXT) += wext-common.o obj-y += $(obj-yy) $(obj-yn) $(obj-ny) -- - 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] nl80211: Allocate array of pointers for nla_parse
The code allocates an array of struct nlattr, but it seems to me that it should allocate an array of pointers. Signed-off-by: Marcus Better [EMAIL PROTECTED] --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -843,7 +843,7 @@ static int nl80211_initiate_scan(struct sk_buff *skb, struct genl_info *info) channels = kmalloc(count * sizeof(struct scan_channel), GFP_KERNEL); - tb = kmalloc((NL80211_ATTR_MAX+1) * sizeof(struct nlattr), + tb = kmalloc((NL80211_ATTR_MAX+1) * sizeof(struct nlattr *), GFP_KERNEL); count = 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: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Thomas Hellström wrote: Does the noirqdebug option fix the problem? Yes... but it breaks switching to a text console. I get an interesting fluid effect on the screen (a bright static pattern), and the keyboard locks up. Marcus signature.asc Description: OpenPGP digital signature
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Thomas Hellström wrote: Does the noirqdebug option fix the problem? Yes... but it breaks switching to a text console. Are you _sure_ these are related? Yes. (I tried a few times and it always crashed, whereas without noirqdebug I've switched mode successfully hundreds of times.) Without the i915 module both network and console switching work. Marcus signature.asc Description: OpenPGP digital signature
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Hellström wrote: Strange. I've also seen the i915 sending false interrupts on its own line, though. Here's the interrupt table with i915 loaded: ~$ cat /proc/interrupts CPU0 0: 401031 XT-PIC timer 1: 3681 XT-PIC i8042 2: 0 XT-PIC cascade 8: 0 XT-PIC rtc 9: 0 XT-PIC acpi 10:997 XT-PIC yenta, Intel 82801CA-ICH3, Intel 82801CA-ICH3 Modem 11: 93823 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2, eth0, [EMAIL PROTECTED]::00:02.0 12: 75631 XT-PIC i8042 14: 18284 XT-PIC ide0 15: 13901 XT-PIC ide1 NMI: 0 ERR: 0 Does the noirqdebug option fix the problem? Yes, it appears to fix it. Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEsTArXjXn6TzcAQkRAn/vAKCZUAVd45xQae4FthvNr68x/jTS4QCgyE7N CzPv0R9okmIjrsGykMXrfPk= =gU6D -END PGP SIGNATURE- - 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
-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? Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEroy7XjXn6TzcAQkRAp7bAJ9F7HgWg+VsvQ0fwkK3+b4Ne+tASwCg8+m3 8i5BoW+ujUjoX3DLW0QKAPQ= =MDAc -END PGP SIGNATURE- - 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
rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
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. The problem appears in kernel 2.6.16 and 2.6.17, but not in 2.6.15. It prints the following in the syslog: Jun 28 07:50:36 kelev kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 28 07:50:39 kelev kernel: eth0: link up, 100Mbps, half-duplex, lpa 0x40A1 Jun 28 07:50:51 kelev kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 28 07:50:54 kelev kernel: eth0: link up, 100Mbps, half-duplex, lpa 0x40A1 Jun 28 07:51:06 kelev kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 28 07:51:09 kelev kernel: eth0: link up, 100Mbps, half-duplex, lpa 0x40A1 Jun 28 07:51:21 kelev kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 28 07:51:24 kelev kernel: eth0: link up, 100Mbps, half-duplex, lpa 0x40A1 I've exchanged the hub and network cables, to no avail. Results of lspci -vvv: 01:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (8000ns min, 16000ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 9000 [size=256] Region 1: Memory at a010 (32-bit, non-prefetchable) [size=512] Capabilities: [60] Vital Product Data Marcus - 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] bcm43xx-d80211: proper implementation of virtual interface support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jiri Benc wrote: This is unnecessary. AFAIK bcm43xx hardware doesn't support more than one interface at a time (not counting monitor interfaces as those are somewhat special). I wonder what exactly is causing this limitation? Why isn't it just a matter of software support? Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEWlUrXjXn6TzcAQkRAoa6AJ97kI8F7Q42orjNQC6HBIXwj3I/DwCgux18 RBkhEcOFBDtQGEHFq2eMxKU= =3WoL -END PGP SIGNATURE- - 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: Wireless tap device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kershaw wrote: Josh Wright and I have been working on a library to make a common injection layer across the drivers, Looks very interesting, but I had in mind exactly the opposite (if I understand correctly): packets written to the virtual device would be received by the kernel, instead of going out to the radio. The kernel would think it had a real wireless device. So this would be independent of hardware (in fact no wireless hardware is necessary). Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENBuhXjXn6TzcAQkRAnCuAKCUC6AIfJfNCdBsStahNgi98yBU0wCcCC+b hU+aAosgDSInrg/2gWLpAYU= =cyOo -END PGP SIGNATURE- - 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: Wireless tap device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kershaw wrote: Looks very interesting, but I had in mind exactly the opposite (if I understand correctly): packets written to the virtual device would be received by the kernel, instead of going out to the radio. The kernel would think it had a real wireless device. So this would be independent of hardware (in fact no wireless hardware is necessary). I think the problem with that idea lies in the linktype handling. Linux doesn't currently talk 802.11 -- all the wireless drivers turn the packets into 802.3 before they hit the kernel layer. I'm looking at the wireless development tree, let's say with the Devicescape stack. A virtual wireless device, using this stack, should be able to inject 802.11 frames. Such a wltap driver would be analogous to tuntap but at the 802.11 level. One of the goals for the stack in the future is, I believe, supporting 802.11 linktypes. Ok, in that case it could be even simpler. Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFENC50XjXn6TzcAQkRAp1+AKDsFR2AHF59zB9oYa+/RuD61S/6OgCgqP4p nxDb1mRpQEgRRmW2JnBY9GQ= =xGf3 -END PGP SIGNATURE- - 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
Wireless tap device
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi developers, is there a convenient way to inject 802.11 frames into the stack from user-space? I am thinking about something analogous to the tap device for Ethernet. That is, a virtual wireless device that would receive frames from user-space. I think this could be useful for testing and experimenting in various situations, and would appreciate any comments and thoughts on this. Thanks, Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMnfxXjXn6TzcAQkRAnTmAKDY/gzbq0bdASYg3mSHQiK97cckkACeMadG ak5paKw7KBMNBvYcjLkb3Vc= =6su6 -END PGP SIGNATURE- - 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
