Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Greetings, Arjan van de Ven
On Wed, 2004-06-09 at 09:28 +0200, Arjan van de Ven wrote:
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
So far, it looks like only the .422 kernel is there, not the .424.
Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Greetings, Arjan van de Ven
Is this supposed to work without the psmouse.proto=imps given as a kernel argument? (at least in the grub.conf file)
I had trouble logging in using runlevel 3. It took about 4 attempts to actually get past the login prompt. I eventually was able to login. Was there a change that would effect login?
The tapping with psmouse.proto=imps as an argument to the kernel works as before. (pretty much like 2.4 worked).
Jim
On Wed, Jun 09, 2004 at 07:21:46AM -0400, Jim Cornette wrote:
Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Greetings, Arjan van de Ven
Is this supposed to work without the psmouse.proto=imps given as a kernel argument? (at least in the grub.conf file)
yes
Arjan van de Ven wrote:
On Wed, Jun 09, 2004 at 07:21:46AM -0400, Jim Cornette wrote:
Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Greetings, Arjan van de Ven
Is this supposed to work without the psmouse.proto=imps given as a kernel argument? (at least in the grub.conf file)
yes
Without adding psmouse.proto=imps in grub.conf, the tapping does not work. The scrolling and tapping functionality is not present.
Jim
On Wed, Jun 09, 2004 at 09:28:46AM +0200, Arjan van de Ven wrote:
One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Vanilla 2.6.6. was totally broken on the VIA Athlon64 - continual stream of interrupts on the PS/2 port. The -424 kernel seems to be working in this situation
However - ide-scsi is STILL missing so my Nakamichi CD changer STILL doesn't work (I only first pointed this out for beta1) - powernow-k8 support is missing although the discussion as I understand it was that it was now stable - AMI megaraid crashes on boot - should either be disabled for x86_64 or AMI's patches applied
I can't easily test the aacraid updates on this box but other than that it seems an improvement, although its short some rather important and trivial changes.
Given that the megaraid crash on boot, powernow-k8 and ide-scsi can all be fixed by sorting out the default .config it would be a shame not to sort that out. Other stuff like the velocity ethernet driver I can understand being higher risk, or wanting to wait until it comes in from upstream.
Alan
On Wed, 2004-06-09 at 19:53, Alan Cox wrote:
On Wed, Jun 09, 2004 at 09:28:46AM +0200, Arjan van de Ven wrote:
One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Vanilla 2.6.6. was totally broken on the VIA Athlon64 - continual stream of interrupts on the PS/2 port. The -424 kernel seems to be working in this situation
However
- ide-scsi is STILL missing so my Nakamichi CD changer STILL doesn't work (I only first pointed this out for beta1)
- powernow-k8 support is missing although the discussion as I understand it was that it was now stable
- AMI megaraid crashes on boot - should either be disabled for x86_64 or AMI's patches applied
I can't easily test the aacraid updates on this box but other than that it seems an improvement, although its short some rather important and trivial changes.
Given that the megaraid crash on boot, powernow-k8 and ide-scsi can all be fixed by sorting out the default .config it would be a shame not to sort that out. Other stuff like the velocity ethernet driver I can understand being higher risk, or wanting to wait until it comes in from upstream.
Alan
Since it seems like AMD64 is getting some love, any possibility someone can look at the patches I need to apply to make it work reasonably well on the eMachines laptops? While not perfect, you kernel gods might be able to figure out a better way to fix things like making the keyboard work without:
# perl -pi -e 's,HCI_HCD=m,HCI_HCD=y,g' SOURCES/kernel-2.6.6*.config
Or beat the the buggy bios' acpi and apic into submission. To that end, tell me what to run on my box so I can put it in bugzilla in a format that will do us both some good. The patch I apply is the one for the 2.6.x kernel I got from:
http://bugme.osdl.org/show_bug.cgi?id=2641
but even with that I need to pass 'noacpi pci=noapic,usepirqmask' to make everything work.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 09 June 2004 07:15, Chris Kloiber wrote:
Since it seems like AMD64 is getting some love, any possibility someone can look at the patches I need to apply to make it work reasonably well on the eMachines laptops? While not perfect, you kernel gods might be able to figure out a better way to fix things like making the keyboard work without:
# perl -pi -e 's,HCI_HCD=m,HCI_HCD=y,g' SOURCES/kernel-2.6.6*.config
Looks to me that you're compiling the usb into the kernel rather than as modules. If this is true, this would fix the ps/2 not working on dual xeon supermicro systems. Please do seriously consider this 'fix'.
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
On Wed, Jun 09, 2004 at 10:11:11AM -0700, Jesse Keating wrote:
# perl -pi -e 's,HCI_HCD=m,HCI_HCD=y,g' SOURCES/kernel-2.6.6*.config
Looks to me that you're compiling the usb into the kernel rather than as modules. If this is true, this would fix the ps/2 not working on dual xeon supermicro systems. Please do seriously consider this 'fix'.
It also breaks some systems 8(
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 09 June 2004 10:41, Alan Cox wrote:
It also breaks some systems 8(
Does it break more than the existing dual xeon supermicro systems? I know quite a few of those puppies out there. This ps/2 not working has been causing many of our customers to refuse looking at Fedora as an install choice.
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
On Wed, Jun 09, 2004 at 10:43:22AM -0700, Jesse Keating wrote:
It also breaks some systems 8(
Does it break more than the existing dual xeon supermicro systems? I know quite a few of those puppies out there. This ps/2 not working has been causing many of our customers to refuse looking at Fedora as an install choice.
As far as people can currently tell that is down to supermicro bios bugs. Compiling the HCD in hides this by turning off USB legacy emulation before the bios can get involved - so the kernel ends up talking to the real PS/2 hardware.
The 2.6.x kernel is much smarter about PS/2 devices. Unfortunately it turns out that half the worlds bios vendors and a small percentage of the hardware people have apparently never read the spec 8(
On your dual xeon it would be interesting to know if it behaves if you turn off USB legacy keyboard/mouse stuff before booting Fedora
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 09 June 2004 10:45, Alan Cox wrote:
The 2.6.x kernel is much smarter about PS/2 devices. Unfortunately it turns out that half the worlds bios vendors and a small percentage of the hardware people have apparently never read the spec 8(
On your dual xeon it would be interesting to know if it behaves if you turn off USB legacy keyboard/mouse stuff before booting Fedora
USB legacy keyboard/mouse stuff in the bios you mean? I'll certianly try that. I still don't understand why this would even come into play when pure ps/2 devices are used, or is that where the buggy bios comes into play?
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
On Wed, Jun 09, 2004 at 10:49:54AM -0700, Jesse Keating wrote:
USB legacy keyboard/mouse stuff in the bios you mean? I'll certianly try that. I still don't understand why this would even come into play when pure ps/2 devices are used, or is that where the buggy bios comes into play?
Every access to the keyboard controller when USB legacy support is enabled instead of accessing the hardware causes an SMM exception which then runs a load of BIOS code which investigates both the real and USB devices and fakes up a reply as if the device was PS/2. This allows things like DOS to work with USB keyboards, its also an endless source of bugs because SMM code is *hard* for even good BIOS people to get right.
Looks to me that you're compiling the usb into the kernel rather than as modules. If this is true, this would fix the ps/2 not working on dual xeon supermicro systems. Please do seriously consider this 'fix'.
I do have a plan for trying building the usb host controllers into the kernel. But it's post this update to give it a reasonable testing time....
On Wed, Jun 09, 2004 at 09:47:31PM +0200, Arjan van de Ven wrote:
Looks to me that you're compiling the usb into the kernel rather than as modules. If this is true, this would fix the ps/2 not working on dual xeon supermicro systems. Please do seriously consider this 'fix'.
I do have a plan for trying building the usb host controllers into the kernel. But it's post this update to give it a reasonable testing time....
I have two machines here that won't boot if you do that. There is also a much better way to achieve the relevant effect if you know the problems are USB legacy caused.
Vojtech I think posted a proposed patch that uses pci quirks as an optional way to simply turn off USB legacy support. That fixes the problem but means systems that need USB legacy fail - thankfully 2.6.x and the later USB is now probing very like windows so all the buggy crap that assumes MS windows works.
The second better way to do it would be to turn off USB legacy, do the initial probe, turn USB legacy back to its old state and then speak slowly to the crappy SMM emulation just to check for USB emulation.
On Wed, Jun 09, 2004 at 10:15:37PM +0800, Chris Kloiber wrote:
on the eMachines laptops? While not perfect, you kernel gods might be able to figure out a better way to fix things like making the keyboard work without:
# perl -pi -e 's,HCI_HCD=m,HCI_HCD=y,g' SOURCES/kernel-2.6.6*.config
There has been some discussion about BIOSes with buggy USB legacy emulation - that may be what this is indicating
Dunno about the others
On Wed, 2004-06-09 at 08:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Does this kernel have FireWire re-enabled?
On Wed, 2004-06-09 at 14:02, D. D. Brierton wrote:
On Wed, 2004-06-09 at 08:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Does this kernel have FireWire re-enabled?
yes so if you have firewire hw, do beat on it too...
Arjan
Does this kernel have FireWire re-enabled?
yes so if you have firewire hw, do beat on it too...
In short: the ipod wasn't detected, modprobe worked but later rmmod hung.
I tried plugging in my ipod and it wasn't detected. I thought to put something into modprobe.conf so I took a line from my backed up 2.4 modules.conf:
alias ieee1394-controller ohci1394
That didn't help so I modprobed ohci1394 and sbp2 manually. Then I saw the ipod, and was able to mount it. I built gtkpod according to instructions:
http://fedoranews.org/casper/gtkpod/
I used gtkpod for a bit then exited and unmounted /mnt/ipod, then tried rmmod sbp2 - which hung. I couldn't even use strace on it.
Last few log messages:
Jun 9 21:03:43 localhost scsi.agent[3416]: disk at /devices/pci0000:00/0000:00:0c.2/fw-host0/000a2700020795ec/000a2700020795ec-0/host1/1:0:0:0 Jun 9 21:29:18 localhost kernel: ieee1394: sbp2: Logged out of SBP-2 device
-Cam
On Wed, 2004-06-09 at 13:12, Arjan van de Ven wrote:
On Wed, 2004-06-09 at 14:02, D. D. Brierton wrote:
On Wed, 2004-06-09 at 08:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Does this kernel have FireWire re-enabled?
yes so if you have firewire hw, do beat on it too...
So, I finally installed FC2 yesterday, and immediately updated to 2.6.6-1.427. FireWire seems to be working absolutely fine: my external Iomega 120GB FireWire drive was detected and the nightly backup onto it seems to have gone without incident. I have copied large (~400MB) files to and from it without incident so far.
There was only one thing regarding this that struck me as not quite right, but it's not a problem with the kernel but rather with kudzu. When I first booted into 2.6.6-1.427 with the FireWire drive attached kudzu recognised the device and asked if I wanted to configure it to which I said yes. However, kudzu did not create a mount point for it like it does for CD drives and floppies which I think it should. I created an entry in fstab and a mount point in /mnt, but still no icon for the drive showed up on my GNOME desktop even when the device was mounted. I then added the option "users" to the fstab entry and an icon appeared on the desktop. None of that was really a problem for me, but a newbie would have just thought that FC2 was failing to see the external drive. Should I bugzilla this (against kudzu/updfstab)?
Best, Darren
On Sun, Jun 13, 2004 at 03:02:32PM +0100, D. D. Brierton wrote:
drive. Should I bugzilla this (against kudzu/updfstab)?
The answer to "should I bugzilla this" is pretty much always "yes". :)
On Mon, 2004-06-14 at 04:18, Matthew Miller wrote:
The answer to "should I bugzilla this" is pretty much always "yes". :)
Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125966
Best, Darren
On Mon, 2004-06-14 at 18:46, D. D. Brierton wrote:
On Mon, 2004-06-14 at 04:18, Matthew Miller wrote:
The answer to "should I bugzilla this" is pretty much always "yes". :)
Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125966
ok the nfs things was a miscommunication between my development box and the buildsystem; I wanted my development box to cvs commit the nfs change before build but that somehow didn't make it. THere's now a 521 kernel with the fix in the testing area
Did anybody managed to install Nvidia drivers on this Kernel?
and if so how? :-)
TIA
_____________________________________________________________________________________
Bart Kalita MCP
Registered Linux User #347493 Fedora Core 3 test 1
Still the same problem I'm attaching Nvidia-installer log for those interested or willing to help
TIA
_____________________________________________________________________________________
Bart Kalita MCP
Registered Linux User #347493 Fedora Core 3 test 1
On Mon, 16 Aug 2004, Bart Kalita wrote:
Still the same problem I'm attaching Nvidia-installer log for those interested or willing to help
Maybe its because FC2 kernel-update is compiled with gcc-3.3 & you are building this on rawhide with gcc-3.4?
Satish
On Mon, 2004-08-16 at 16:48, Satish Balay wrote:
On Mon, 16 Aug 2004, Bart Kalita wrote:
Still the same problem I'm attaching Nvidia-installer log for those interested or willing to help
Maybe its because FC2 kernel-update is compiled with gcc-3.3 & you are building this on rawhide with gcc-3.4?
Satish
If that is the case, then you might want to try the workaround that some of us used back with FC1:
./NVIDIA-Linux-x86-1.0-6111-pkg1.run --add-this-kernel
That should then create a new installer called:
./NVIDIA-Linux-x86-1.0-6111-pkg1-custom.run
Run the second 'custom' installer and see if that works.
HTH,
Marc Schwartz
Custom build driver doesn't work either.
I'm attaching installer-log form the custom build installation.
Looks like we have to wait for new driver or for some nice person to find a workaround.
On Mon, 2004-08-16 at 17:18 -0500, Marc Schwartz wrote:
On Mon, 2004-08-16 at 16:48, Satish Balay wrote:
On Mon, 16 Aug 2004, Bart Kalita wrote:
Still the same problem I'm attaching Nvidia-installer log for those interested or willing to help
Maybe its because FC2 kernel-update is compiled with gcc-3.3 & you are building this on rawhide with gcc-3.4?
Satish
If that is the case, then you might want to try the workaround that some of us used back with FC1:
./NVIDIA-Linux-x86-1.0-6111-pkg1.run --add-this-kernel
That should then create a new installer called:
./NVIDIA-Linux-x86-1.0-6111-pkg1-custom.run
Run the second 'custom' installer and see if that works.
HTH,
Marc Schwartz
On Tue, 2004-08-17 at 08:19 +0100, Bart Kalita wrote:
Custom build driver doesn't work either.
I'm attaching installer-log form the custom build installation.
Looks like we have to wait for new driver or for some nice person to find a workaround.
I have had some problems but the work around that has worked twice for me is:
boot to level 3, at grub press a take off rhgb and replace with 3. run the Nvidia installer, then run it again, then startx and then reboot...
Don't ask why it works for me doing the above but it does!
Simon
I've looked around but I can't find sourcecode for 524 kernel
On Fri, 2004-08-20 at 18:39 +0100, Si wrote:
On Tue, 2004-08-17 at 08:19 +0100, Bart Kalita wrote:
Custom build driver doesn't work either.
I'm attaching installer-log form the custom build installation.
Looks like we have to wait for new driver or for some nice person to find a workaround.
I have had some problems but the work around that has worked twice for me is:
boot to level 3,
at grub press a take off rhgb and replace with 3.
Could you explain the above bit of instructions?
run the Nvidia installer, then run it again, then startx and then reboot...
Don't ask why it works for me doing the above but it does!
Simon
On Fri, 2004-08-20 at 19:13 +0100, Bart Kalita wrote:
On Fri, 2004-08-20 at 18:39 +0100, Si wrote:
On Tue, 2004-08-17 at 08:19 +0100, Bart Kalita wrote:
Custom build driver doesn't work either.
I'm attaching installer-log form the custom build installation.
Looks like we have to wait for new driver or for some nice person to find a workaround.
I have had some problems but the work around that has worked twice for me is:
boot to level 3,
at grub press a take off rhgb and replace with 3.
Could you explain the above bit of instructions?
At the grub boot logo, press the 'a' key (modify kernel arguments before booting). This will show you the kernel boot line. If you have the text rhgb (for graphical boot), remove it. Either way, add the number 3 at the end of the arguments to boot into runlevel 3 instead of the default (which is probably 5).
Runlevel 3 is text mode. This will give you a chance to log into the console and re-run the nvidia installer which can build a new nvidia driver for your new kernel.
You probably don't need to reboot at this point. '/sbin/telinit 5' will bring you back to a graphical login.
On Mon, 2004-08-16 at 20:52, Arjan van de Ven wrote:
On Mon, 2004-06-14 at 18:46, D. D. Brierton wrote:
On Mon, 2004-06-14 at 04:18, Matthew Miller wrote:
The answer to "should I bugzilla this" is pretty much always "yes". :)
Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125966
ok the nfs things was a miscommunication between my development box and the buildsystem; I wanted my development box to cvs commit the nfs change before build but that somehow didn't make it. THere's now a 521 kernel with the fix in the testing area
FWIW: The nfs issues seem to be gone with this kernel.
A minor packaging bug:
Symptom: Installing the kernel prints a '/' to the console # rpm -i kernel-2.6.8-1.521.i686.rpm /
AFAIS, the cause is a missing output redirection of a popd in the postinstall scriptlet.
# rpm -q --scripts kernel-2.6.8-1.521 .. postinstall scriptlet (using /bin/sh): [ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --mkinitrd --depmod --install 2.6.8-1.521 if [ -x /usr/sbin/hardlink ] ; then pushd /lib/modules/2.6.8-1.521/build > /dev/null ; { cd /lib/modules/2.6.8-1.521/build find . -type f | while read f; do hardlink -c /lib/modules/*/build/$f $f ; done } popd fi ...
The "popd" should be "popd > /dev/null"
Ralf
On Tue, 2004-08-17 at 07:49 +0200, Ralf Corsepius wrote:
On Mon, 2004-08-16 at 20:52, Arjan van de Ven wrote:
On Mon, 2004-06-14 at 18:46, D. D. Brierton wrote:
On Mon, 2004-06-14 at 04:18, Matthew Miller wrote:
The answer to "should I bugzilla this" is pretty much always "yes". :)
Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125966
ok the nfs things was a miscommunication between my development box and the buildsystem; I wanted my development box to cvs commit the nfs change before build but that somehow didn't make it. THere's now a 521 kernel with the fix in the testing area
FWIW: The nfs issues seem to be gone with this kernel.
Correct, nfs issues seem to be gone and now working again :)
A minor packaging bug:
Symptom: Installing the kernel prints a '/' to the console # rpm -i kernel-2.6.8-1.521.i686.rpm /
Saw the same error as above, although it at least still installs.
Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Greetings, Arjan van de Ven
Would just like to note that running kernel 424 without psmouse.proto=imps doesn't allow my touchpad to tap-to-click. Although my pointing stick now works, as well as it's corresponding buttons (it never did before). This is on an IBM Thinkpad T30 2366-81A. Running with psmouse.proto=imps allows my touchpad to tap-to-click with 424.
dex
Any radeon resume updates in this?
Philip
On Wed, 2004-06-09 at 03:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6 One of the last minute changes is a series of patches to the input subsystem that are supposed to fix a lot of the "tapping my laptops touchpad doesn't work" bugs. So please beat hard on this kernel...
Greetings, Arjan van de Ven
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, 2004-06-09 at 03:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6
Just tried the new 424 kernel and it has PCMCIA problems on my ThinkPad A22p that did not occur with 2.6.5-1.358 or 2.6.6-1.422. When manually ejecting cards, 424 produces the following error messages on all Xterms:
kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 1
and then there was no apparent way of restarting any networking or getting the prompts back. A shutdown failed to complete as systemlogger just kept repeating the above error message (pulled power and ejected battery to eventually shut it off).
Also, due to the above pcmcia problems, I was only able to test APM suspend once but it did work using the method described at:
http://eh3.com/thinkpad_A22p.html
Ed
Ed Hill wrote:
On Wed, 2004-06-09 at 03:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6
Just tried the new 424 kernel and it has PCMCIA problems on my ThinkPad A22p that did not occur with 2.6.5-1.358 or 2.6.6-1.422. When manually ejecting cards, 424 produces the following error messages on all Xterms:
kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 1
and then there was no apparent way of restarting any networking or getting the prompts back. A shutdown failed to complete as systemlogger just kept repeating the above error message (pulled power and ejected battery to eventually shut it off).
Hi all!
I just had the same problem with ppp0 and kernel 424.
unregistered_netdevice: waiting for ppp0 to become free. Usage count = 1
First I couldn't reach outside networks anymore, I tried to restart the VPN connection. Then the above message appeared in the console. Killing pppd failed (even with -9). I tried to reboot, but reboot didn't complete cause syslogd was repeating the message as in Ed's case. I ended up in a power cycle - now it works again.
It worked perfect in kernel 391custom (just added NTFS support)
Cheers, Hannes.
Hannes Mayer wrote:
Ed Hill wrote:
On Wed, 2004-06-09 at 03:28, Arjan van de Ven wrote:
Hi,
the plan is to do a kernel update friday or monday (depending on the amount of things that turn up in this testing). There is a 424 kernel in the testing dir on the ftp repository and on http://people.redhat.com/arjanv/2.6
Just tried the new 424 kernel and it has PCMCIA problems on my ThinkPad A22p that did not occur with 2.6.5-1.358 or 2.6.6-1.422. When manually ejecting cards, 424 produces the following error messages on all Xterms:
kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 1
and then there was no apparent way of restarting any networking or getting the prompts back. A shutdown failed to complete as systemlogger just kept repeating the above error message (pulled power and ejected battery to eventually shut it off).
Hi all!
I just had the same problem with ppp0 and kernel 424.
unregistered_netdevice: waiting for ppp0 to become free. Usage count = 1
First I couldn't reach outside networks anymore, I tried to restart the VPN connection. Then the above message appeared in the console. Killing pppd failed (even with -9). I tried to reboot, but reboot didn't complete cause syslogd was repeating the message as in Ed's case. I ended up in a power cycle - now it works again.
It worked perfect in kernel 391custom (just added NTFS support)
Just a quick update for you Arjan: Today I installed kernel 427 and I'm running it for 6+ hours now and the unregistered_netdevice problem is gone. Thank you very much for the great work! :-)
Cheers, Hannes.