Bug#383849: linux-image-2.6.16-2-686: Problem with atkbd.c
On Sun, Feb 04, 2007 at 09:46:41PM -0500, Luis Uribe wrote: > Hi Max, > On Mon, Jan 22, 2007 at 11:22:05AM +0100, maximilian attems wrote: > > then please check out latest linux images trunk 2.6.19 and/or > > 2.6.20-rc5, see apt lines > > Nop, it has the same problem. ok > > if the issue is fixed in one of those we need to checkout the > > patch for backport, if not upstream need to be bugged. > > All right, looking in the MAINTAINERS file in the kernel source looks that the > responsable for the i8k module is Massimo dal Zotto, i'm gonna send him a > report about the bug. please file it at bugzilla.kernel.org and add him there to CC, these days Dmitry Torokhov takes care of the INPUT drivers. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409243: fails to boot.
Il giorno ven, 02/02/2007 alle 10.59 +0100, maximilian attems ha scritto: > On Thu, Feb 01, 2007 at 08:27:58AM +0100, Mauro Sanna wrote: > > > > -- Package-specific info: > > -- /proc/cmdline > > root=/dev/mapper/vg00-root ro > > ok looks good. > > > I've installed sarge with lvm and kernel 2.6.8 with initrd. > > At the end of installation I reboot the system and all works > > well. > > Then I upgrade to etch. > > I install the new kernel 2.6.18 and initramfs-tools. > > I create the new initrd then, at the end of upgrade, reboot the > > system. > > It hangs saying that cannot find my volume group and is "waiting > > for root filesystem..." > > In my preceding upgrades, months ago, I didn't had this problem. > > I have this problem with newer upgrades to etch. > > please boot with bootarg rootdelay=1 > and check in the rescue shell which devices exists > ls /dev/hd* > ls /dev/sd* > > also attach your /etc/fstab to your response. Ok, I've booted with rootdelay=1 ls /dev/hd* dev/hda, dev/hda1, dev/hda2, dev/hdd ls /dev/sd* no such file o directory. etc/fstab: proc/proc procdefaults0 0 /dev/mapper/vg00-root /ext3defaults,errors=remount-ro 0 1 /dev/hda1 /boot ext3defaults0 2 /dev/mapper/vg00-usr /usr ext3defaults0 2 /dev/mapper/vg00-tmp /tmp ext3defaults0 2 /dev/mapper/vg00-var /var ext3defaults0 2 /dev/mapper/vg00-swap none swapsw 0 0 /dev/hdd/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 That's all. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409243: fails to boot.
On Mon, Feb 05, 2007 at 01:19:38PM +0100, Mauro Sanna wrote: > > Ok, I've booted with rootdelay=1 > > ls /dev/hd* > > dev/hda, dev/hda1, dev/hda2, dev/hdd hmm ok so i need to know where your lvm is on, please attach the output of vgdisplay i guess it's on /dev/hda2, so your device node should be there? can you try please to boot with break=mount wait a bit of a time in the rescue shell and then exit it, does that work? best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409435: linux-image-2.6.18-4-amd64: old version of libdevmapper1.02 installed == eat filesystem on pvmove
On Fri, Feb 02, 2007 at 08:16:38PM -0800, Steve Langasek <[EMAIL PROTECTED]> wrote: > According to #383418, this bug only affects versions of libdevmapper1.02 > previous to the version currently in etch, and there is no libdevmapper1.02 > in sarge. There is a libdevmapper1.01, but it's not clear that version of > the lib is also affected. Thats fine, the bug still eats disks, and while I don't know anything about the chances of this happening I would still assume its a pretty common occurence as upgrading both lvm2 and dmsetup didn't upgrade the library used by them, leaving the broken one in place. > > indeed, upgrading it made pvmove seemingly work (neither upgrading dmsetup > > nor lvm2 upgrades this library to the required version). I think I had > > 1.02.06-1 and upgraded to 1.02.12-1. > > > Please, I urge you, add an antidependency to the kernel against old and > > incompatible versions of libdevmapper. This problem is *severe*, causes > > serious data loss, is a known issue, and is so easily avoidable and so > > hard to diagnose. > > But it's not a bug in the kernel -- it's a bug in an obsolete, First of all, while the data corruption can be conceivably be a userspace bug, remember that the lvm2 commands went into uninterruptible sleep (no kill -9), which cannot be a userspace problem unless you assume libdevmapper opens /dev/mem and pokes into the kernel directly. To put it otherwise, a broken libdevmapper (thta happens to work with older kernels) may easily eat my data, but processes in uninterruptible sleep is still a kernel bug. > never released, and unsupported version of devmapper. Right, but just for the sake of helping people who used the never released and unsupported version of devmapper that likely many people using unstable or testing still have installed and doesn't get upgraded it would make sense to do that, won't you think? I mean, it eats data, and users did nothing wrong, except using debian testing at some point in the past. You can only win by helping that case, especially as upgrading to the current lvm2 version does not fix that. (Maybe lvm2 needs a dependency on a newer libdevmapper, but as this only happens with 2.6.18 and not 2.6.16, it would probably make sense for the kernel). Are you really telling me that destroying data just because the version of libdevmapper that once was in debian was never part of a debian release? Thats really a poor excuse. I cna understand your point of "its not a kernel bug" (even if there is some bug), but is it really too much to ask? I mean, lets repeat it, it _eats_ data because some obscure, not directly user-visible version of libdevmapper which usually gets installed as an dependency only fails to work with 2.6.18. Even if accoridng to policy this is correct behaviour, I cannot accept such a position at all. Turning your back to such a serious bug is really unfair. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409806: kernel: general protection fault: 0000 [1] SMP
Package: kernel Version: 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux Severity: normal While using a debian ethc system in an usual way: the following two lines happend: Message from [EMAIL PROTECTED] at Mon Feb 5 18:08:22 2007 ... simi kernel: general protection fault: [1] SMP This deals with 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux :~$ lsmod Module Size Used by smbfs 69648 2 ext2 70288 0 udf81416 1 radeon116384 2 drm87080 3 radeon nfsd 256200 17 exportfs 10368 1 nfsd button 12192 0 ac 10376 0 battery15496 0 ipv6 285664 49 nfs 236216 3 lockd 67600 3 nfsd,nfs nfs_acl 8320 2 nfsd,nfs sunrpc166984 13 nfsd,nfs,lockd,nfs_acl sk98lin 146656 0 dm_snapshot20536 0 dm_mirror 25216 0 dm_mod 62800 2 dm_snapshot,dm_mirror sbp2 28680 0 loop 20112 0 tsdev 13056 0 snd_hda_intel 23708 1 snd_hda_codec 184192 1 snd_hda_intel snd_pcm_oss48672 0 snd_mixer_oss 21888 1 snd_pcm_oss i2c_i801 13076 0 snd_pcm88968 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss parport_pc 41640 0 parport44684 1 parport_pc psmouse44432 0 snd_timer 29192 1 snd_pcm i2c_core 27776 1 i2c_i801 serio_raw 12036 0 pcspkr 7808 0 shpchp 42156 0 pci_hotplug20872 1 shpchp snd65256 8 snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 15392 1 snd snd_page_alloc 14864 2 snd_hda_intel,snd_pcm evdev 15360 1 sky2 46212 0 eth139424840 0 ext3 138256 6 jbd65392 1 ext3 mbcache14216 2 ext2,ext3 ide_cd 45088 1 cdrom 40488 1 ide_cd sd_mod 25856 7 generic10756 0 [permanent] usbhid 45088 0 ata_piix 19976 0 libata106784 1 ata_piix ohci1394 38216 0 ieee1394 361976 3 sbp2,eth1394,ohci1394 aacraid63616 6 scsi_mod 152880 4 sbp2,sd_mod,libata,aacraid skge 43536 0 piix 15492 0 [permanent] ide_core 147584 3 ide_cd,generic,piix uhci_hcd 28432 0 ehci_hcd 36104 0 thermal20240 0 processor 38248 1 thermal fan 9864 0 this happend trying some zip commands, from local drive to udf filesystem removable Iomega drive, working with /dev/hda. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409811: kernel: general protection fault: 0000 [1] SMP
Package: kernel Version: s Severity: normal Some data file content are loged in syslogfile. The first I see is: Feb 5 17:12:34 computername kernel: UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'Cartouche hebdomadaire E', timestamp 2006/12/21 20:49 (103c) Feb 5 17:13:00 computername kernel: udf: unknown compression code (69) stri=17675A821} */^M Feb 5 17:13:00 computername kernel: private TypeNotationContrepartie typeNotatio Feb 5 17:13:00 computername kernel: smb_add_request: request [810006595e00, mid=304] timed out! Feb 5 17:13:30 computername kernel: smb_add_request: request [810006595e00, mid=305] timed out! Feb 5 17:15:02 computername /USR/SBIN/CRON[21892]: (gnats) CMD (test -x /usr/lib/gnats/queue-pr && /usr/lib/gnats/queue-pr --run ; exit 0) Feb 5 17:15:24 computername kernel: udf: unknown compression code (70) stri=f\214lyJG!\216>>@l\210^^\204e\211Zxs^LW\203`^Bf<6\231\206^Lk65E Feb 5 17:17:02 computername /USR/SBIN/CRON[22019]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Feb 5 17:20:31 computername kernel: udf: unknown compression code (118) stri=oking method Feb 5 17:20:31 computername kernel: ^I^I(*this).sigRefresh(); Feb 5 17:20:32 computername kernel: ^I^I Feb 5 17:20:32 computername kernel: ^I^Ireturn SW_TRUE; Note that ^I^I(*this).sigRefresh(); seems to be a line from a file being copied/compressed with zip or tar. Some more data are logged. Then, there is five udf: unknown compression code (207) then one udf: unknown compression code (191) stri=^OGPD^E^TPX^HeOJ^H^_buf) Feb 5 17:29:55 computername kernel: ^I^ISW_SIZEOF_STELEM(SSTGDCPackage_priv::StoredProc::CommonParametersStoredProc::_string_100, buf), Feb 5 17:29:55 computername kernel: src/SSTGDCPackage_ctype.cpp:8228: Note 1924: C-style cast Feb 5 17:29:55 computername kernel: Feb 5 17:29:55 computername kernel: udf: unknown compression code (58) stri=:_string_100 *)0)->buf) Feb 5 17:29:55 computername kernel: ^I^ISW_SIZEOF_STELEM(SSTGDCPackage_priv::StoredProc::CommonParametersStoredProc::_string_100, buf), Feb 5 17:29:55 computername kernel: src/SSTGDCPackage_ctype.cpp:8228: Note 1924: C-style cast Feb 5 17:29:55 computername kernel: Feb 5 17:30:03 computername kernel: udf: unknown compression code (58) stri=:_string_100 *)0)->buf) Feb 5 17:30:03 computername kernel: ^I^ISW_SIZEOF_STELEM(SSTGDCPackage_priv::StoredProc::CommonParametersStoredProc::_string_100, buf), Feb 5 17:30:03 computername kernel: src/SSTGDCPackage_ctype.cpp:8228: Note 1924: C-style cast Feb 5 17:30:03 computername kernel: Feb 5 17:30:03 computername kernel: udf: unknown compression code (58) stri=:_string_100 *)0)->buf) Feb 5 17:30:03 computername kernel: ^I^ISW_SIZEOF_STELEM(SSTGDCPackage_priv::StoredProc::CommonParametersStoredProc::_string_100, buf), Feb 5 17:30:03 computername kernel: src/SSTGDCPackage_ctype.cpp:8228: Note 1924: C-style cast Feb 5 17:30:03 computername kernel: Feb 5 17:33:02 computername /USR/SBIN/CRON[22872]: (nobody) CMD ([ -x /usr/sbin/greylistclean ] && /usr/sbin/greylistclean) Feb 5 17:35:01 computername /USR/SBIN/CRON[22981]: (gnats) CMD (test -x /usr/lib/gnats/queue-pr && /usr/lib/gnats/queue-pr --run ; exit 0) Feb 5 17:36:22 computername kernel: udf: unknown compression code (28) stri=>[EMAIL PROTECTED]?\223J\214\2047*W5^Y Feb 5 17:36:22 computername kernel: udf: unknown compression code (28) stri=>[EMAIL PROTECTED]?\223J\214\2047*W5^Y and so on. The history finishes with: Feb 5 17:46:29 computername kernel: udf: unknown compression code (114) stri=ties Feb 5 17:46:31 computername kernel: hald[7060]: segfault at 014c rip 2b4565370fd0 rsp 7fff4606f7b8 error 4 Feb 5 17:46:33 computername kernel: udf: unknown compression code (112) stri=]^V Feb 5 17:46:33 computername kernel: udf: unknown compression code (112) stri=]^V Feb 5 17:46:56 computername kernel: NMI Watchdog detected LOCKUP on CPU 0 Feb 5 17:46:56 computername kernel: CPU 0 Feb 5 17:46:56 computername kernel: Modules linked in: smbfs ext2 udf radeon drm nfsd exportfs button ac battery ipv6 nfs lockd nfs_acl sunrpc sk98lin dm_snapshot dm_mirror dm_mod sbp2 loop tsdev snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss i2c_i801 snd_pcm parport_pc parport psmouse snd_timer i2c_core serio_raw pcspkr shpchp pci_hotplug snd soundcore snd_page_alloc evdev sky2 eth1394 ext3 jbd mbcache ide_cd cdrom sd_mod generic usbhid ata_piix libata ohci1394 ieee1394 aacraid scsi_mod skge piix ide_core uhci_hcd ehci_hcd thermal processor fan Feb 5 17:46:56 computername kernel: Pid: 23620, comm: zip Not tainted 2.6.18-3-amd64 #1 Feb 5 17:46:56 computername kernel: RIP: 0010:[] [] __write_lock_failed+0x9/0x20 Feb 5 17:46:56 computername kernel: RSP: 0018:81002b5a19d8 EFLAGS: 0087 Feb 5 17:46:56 computername kernel: RAX: 81001d775240 RBX: 81003f495360 RCX: 00d0 Feb 5 17:46:56 computername kernel: RDX: 81002b5a1a18 RSI: 81001d775228 RDI: 81001d775
Bug#409820: initramfs-tools: mbr_check() does not work reliable with lilo and grub around
Package: initramfs-tools
Severity: important
Inside the mbr_check function in /usr/sbin/update-initramfs we have:
dd if="${boot}" bs=512 skip=0 count=1 2> /dev/null | grep -q LILO \
&& run_lilo && return 0
This does not work reliable in the following scenario:
* lilo is installed first
* grub is installed afterwards
It does not work in that case because grub does *not* clear lilo's
signature. So the string LILO might be found even though grub is the
used and present bootmanager. With the above code we install lilo
in the MBR wheras we want to use grub. => The system might not even
boot anymore after upgrading and executing update-initramfs.
My proposed fix is to use:
dd if="${boot}" bs=512 skip=0 count=1 2> /dev/null | hexdump | \
grep -q '000 ebfa 494c 4f4c' \
&& run_lilo && return 0
This will check for lilo's clear interrupt instruction (fa), the
jump instruction (eb) and the string LILO itself (494c 4f4c).
(hexdump is part of bsdmainutils, if you have another variant you
prefer feel free to adjust above code, I can test it for you of
course.)
JFTR the header looks like the following on a x86 32 bit system
(notice the use of hexdump's -C option in the second command):
# dd if=/dev/hda bs=512 skip=0 count=1 2> /dev/null | hexdump | head -1
000 ebfa 0121 01b5 494c 4f4c 0616 b884 4575
# dd if=/dev/hda bs=512 skip=0 count=1 2> /dev/null | hexdump -C | head -1
fa eb 21 01 b5 01 4c 49 4c 4f 16 06 84 b8 75 45 |úë!.µ.LILO...žuE|
On another x86 32 bit system where initramfs-tools' current check
fails:
# dd if=/dev/sda bs=512 skip=0 count=1 2> /dev/null | hexdump | head -1
000 48eb 0190 01b4 494c 4f4c 0716 0783 45c7
# dd if=/dev/sda bs=512 skip=0 count=1 2> /dev/null | hexdump -C | head -1
eb 48 90 01 b4 01 4c 49 4c 4f 16 07 83 07 c7 45 |.HLILO.E|
I'v tested my proposed fix on several boxes with lilo 22.6.1 and
22.7.3 and on one system where lilo was around and grub is present
now. The tested lilo versions are the ones used in current stable,
testing and unstable so we should have an appropriate fix which
should enter Etch. If you have any package(s) for testing please let
me know...
regards,
-mika-
Bug#409822: linux-image-2.6.18-4-vserver-686: pcmcia wireless card doesn't work until inserting usb ethernet
Package: linux-image-2.6.18-4-vserver-686 Version: 2.6.18.dfsg.1-10 Severity: normal so, i've got this old pcmcia wireless card, and the strange thing is that it doesn't work until i insert a usb ethernet device. i don't know what could be causing this behavior ... from my syslog: Feb 2 11:10:00 ghig kernel: ADDRCONF(NETDEV_UP): eth0: link is not ready Feb 2 11:10:04 ghig kernel: eth0: New link status: Connected (0001) Feb 2 11:10:04 ghig kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Feb 2 11:10:04 ghig kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2 Feb 2 11:10:05 ghig kernel: usb 1-1: configuration #1 chosen from 1 choice Feb 2 11:10:05 ghig kernel: pegasus: v0.6.13 (2005/11/13), Pegasus/Pegasus II USB Ethernet driver Feb 2 11:10:05 ghig kernel: pegasus 1-1:1.0: setup Pegasus II specific registers Feb 2 11:10:05 ghig kernel: pegasus 1-1:1.0: eth1, D-Link DSB-650TX, 00:40:05:8e:d4:a0 Feb 2 11:10:05 ghig kernel: usbcore: registered new driver pegasus if i don't insert the usb ethernet device, i can wait 5-10 hours and still not get the "ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready" message. i've tried at least a dozen times over the past couple months, and it seems reproduceable on my system. could somehow the link status on the usb ethernet device trigger some sort of link status event for the pcmcia wireless card? certainly got me a little confused. lsusb Bus 001 Device 003: ID 2001:400b D-Link Corp. [hex] Bus 001 Device 001: ID : pccardctl info PRODID_1="Lucent Technologies" PRODID_2="WaveLAN/IEEE" PRODID_3="Version 01.01" PRODID_4="" MANFID=0156,0002 FUNCID=6 live well, vagrant -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-vserver-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-4-vserver-686 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85e tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.18-4-vserver-686 recommends: ii libc6-i686 2.3.6.ds1-10 GNU C Library: Shared libraries [i ii util-vserver0.30.211-6 user-space tools for Linux-VServer -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: [bts-link] source package linux-2.6
Processing commands for [EMAIL PROTECTED]: > # > # bts-link upstream status pull for source package linux-2.6 > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). > # remote status report for #360773 > # * http://bugzilla.kernel.org/show_bug.cgi?id=6822 > # * remote status changed: NEW -> CLOSED > # * remote resolution changed: (?) -> PATCH-ALREADY-AVAILABLE > # * closed upstream > tags 360773 + fixed-upstream Bug#360773: linux-image-2.6.16-1-686: p4-clockmod does not work anymore There were no tags set. Tags added: fixed-upstream > usertags 360773 - status-NEW Bug#360773: linux-image-2.6.16-1-686: p4-clockmod does not work anymore Usertags were: status-NEW. Usertags are now: . > usertags 360773 + status-CLOSED resolution-PATCH-ALREADY-AVAILABLE Bug#360773: linux-image-2.6.16-1-686: p4-clockmod does not work anymore There were no usertags set. Usertags are now: status-CLOSED resolution-PATCH-ALREADY-AVAILABLE. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407759: Same problem with DG965SS
I had the same issue with the Intel DG965SS motherboard - CD was unable to be detected. I had to do a USB install to get Debian installed. Toby -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408928: ipw3945d: please allow /var/run as tmpfs
Hi Luca, Thanks for the report. I've prepared a new version of ipw3945d which should handle the /var/run on tmpfs properly. I would appreciate if you could test it and confirm that it works ok in your setup. You can download the source package and the deb from http://www.wooyd.org/debian/ipw3945d/ Thanks, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 408928
Processing commands for [EMAIL PROTECTED]: > tags 408928 + pending Bug#408928: ipw3945d: please allow /var/run as tmpfs Tags were: patch Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405270: machine hangs after loading ipw3945d
Hi Michael, I just wanted to check whether you had better luck using ipw3945/ipw3945d with newer versions of the kernel and/or driver. Does the daemon still hang when kill switch is on? Best regards, -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
