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
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: [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
[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
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] 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. > 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
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
-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
Thomas Hellström wrote: > 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. I thought I double-checked that it was the right commit, but will check again. > If the network sits on the same IRQ line, it will be disabled as well. It appears to be on a different IRQ: ~$ cat /proc/interrupts CPU0 0: 202574 XT-PIC timer 1: 2649 XT-PIC i8042 2: 0 XT-PIC cascade 8: 0 XT-PIC rtc 9: 0 XT-PIC acpi 10: 1059 XT-PIC yenta, Intel 82801CA-ICH3 Modem, Intel 82801CA-ICH3 11: 40776 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2, eth0 12: 100433 XT-PIC i8042 14: 63563 XT-PIC ide0 15: 6773 XT-PIC ide1 NMI: 0 ERR: 0 (This is without i915 loaded though.) > If you check your kernel logs, you will probably have > messages about disabled IRQs. Correct. Here's an example: Jul 7 16:43:39 kelev kernel: irq 11: nobody cared (try booting with the "irqpoll" option) Jul 7 16:43:39 kelev kernel: [] __report_bad_irq+0x24/0x90 Jul 7 16:43:39 kelev kernel: [] note_interrupt+0x72/0xc0 Jul 7 16:43:39 kelev kernel: [] __do_IRQ+0xae/0xc0 Jul 7 16:43:39 kelev kernel: [] do_IRQ+0x19/0x30 Jul 7 16:43:39 kelev kernel: [] common_interrupt+0x1a/0x20 Jul 7 16:43:39 kelev kernel: [] __do_softirq+0x2e/0xa0 Jul 7 16:43:39 kelev kernel: [] do_softirq+0x27/0x30 Jul 7 16:43:39 kelev kernel: [] do_IRQ+0x1e/0x30 Jul 7 16:43:39 kelev kernel: [] common_interrupt+0x1a/0x20 Jul 7 16:43:39 kelev kernel: [] syscall_call+0x7/0xb Jul 7 16:43:39 kelev kernel: handlers: Jul 7 16:43:39 kelev kernel: [] (usb_hcd_irq+0x0/0x60 [usbcore]) Jul 7 16:43:39 kelev kernel: [] (usb_hcd_irq+0x0/0x60 [usbcore]) Jul 7 16:43:39 kelev kernel: [] (rtl8139_interrupt+0x0/0x1d0 [8139too] ) Jul 7 16:43:39 kelev kernel: Disabling IRQ #11 Jul 7 16:44:03 kelev kernel: NETDEV WATCHDOG: eth0: transmit timed out Jul 7 16:44:03 kelev kernel: eth0: Transmit timeout, status 0c 0005 c07f media 9 0. Jul 7 16:44:03 kelev kernel: eth0: Tx queue start entry 48 dirty entry 44. Jul 7 16:44:03 kelev kernel: eth0: Tx descriptor 0 is 0008a062. (queue head) Jul 7 16:44:03 kelev kernel: eth0: Tx descriptor 1 is 0008a062. Jul 7 16:44:03 kelev kernel: eth0: Tx descriptor 2 is 0008a062. Jul 7 16:44:03 kelev kernel: eth0: Tx descriptor 3 is 0008a062. Jul 7 16:44:03 kelev kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 - 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
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Francois Romieu wrote: > In a better world, you would narrow the suspect with a git bissect [1] > between v2.6.15 and v2.6.16. Will try. It may take some time... 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
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- SERR- 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: >>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
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
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
