Jump to content

Kernel 2.6.17.14mdv causing hardware trouble


Recommended Posts

I recently introduced my son to the world of Linux on a home-built computer (I usually build my own) and I installed Mandriva Linux 2007.1 Free on a P4 with 1GB RAM, NVidia GeForce 4200, DVD+RW, RT61 wireless, Gigabit LAN, Epox 4VKM3I motherboard.

 

Everything appeared fine once installed. When the kernel update was released from 2.6.17.13mdv to 2.6.17.14mdv, I updated as usual. I run Mandriva Linux 2007.0 Powerpack on my computer. I had no problems with the update on my computer. However, not so lucky on my son's computer.

 

The mouse is choppy, almost unusable; the RT61 wireless card will not work and is unable to see my wireless network. I have a better experience doing a CTRL-ALT-F1 and work in console mode. But my son is still learning and he wants to be able to do whatever he wants (he's 9 and his Internet habits consist of looking up Pokemon and cheats for his Pokemon games).

 

I had just about given up, and decided to reboot into 13mdv again. Lo and behold, everything works again. I can't seem to find anything in the logs that would give me a hint as to what the problem might be. I've checked X logs, network logs, syslog and messages, boot.log; all come up with nothing other than 'unable to connect to network' (already know that). Any idea what may be the problem? I don't usually compile my own kernel, and the kernels provided by Mandriva have always worked fine for me.

 

 

[moved from Software by spinynorman]

Link to comment
Share on other sites

It could simply be a bad corrupted download of the 14 kernel for your sons machine. It can happen. I have been using the 14 ever since it was released and the fact that it works on yours indicates it should be OK.

Try Deleting it and do a fresh download of the 14 kernel rpm and see if that makes a difference.

 

Cheers. John

Link to comment
Share on other sites

Good experiences with -14 as it solved an USB problem (which was consistenly hanging my machine if disconnecting any type of USB device). However, the fact that something was fixed, means something was chanegd. Would these devices be USB by any chance?

 

I wouldn't know how to help you further if the answer is yes or no, but it may be a start...

Link to comment
Share on other sites

Good experiences with -14 as it solved an USB problem (which was consistenly hanging my machine if disconnecting any type of USB device). However, the fact that something was fixed, means something was chanegd. Would these devices be USB by any chance?

 

I wouldn't know how to help you further if the answer is yes or no, but it may be a start...

 

Thanks for responding. Yes. The mouse is USB, but the RT61 wireless card is an add-on PCI card (I didn't feel like running cable to my son's room, but will worst case scenario). Thus far, those two devices appear to be troublesome with the -14 kernel on my son's machine.

 

Also, AussieJohn - thanks for your response as well. I will try your suggestion and try to reinstall the kernel rpm. I'll let you know how it goes.

Link to comment
Share on other sites

I believe that you will likely find a good reason in the kernel revision 14 changelog, but errrm... just curious: Why don't you follow the old rule "if it ain't broke, don't fix it"?

I was rolling the kernels myself for quite a while in my distro (Arch Linux), because the "revised" kernels included a patch which made my NIC losing a lot of packets- so I had either to use an older one, or roll one of my own. This lasted some four months, and not less than nine kernel revisions (kernels update pretty frequently in a bleeding edge distro). Since you have no real need to upgrade, or roll a custom kernel, why don't you just use revision 13 and wait to test 15 later on?

Link to comment
Share on other sites

I believe that you will likely find a good reason in the kernel revision 14 changelog, but errrm... just curious: Why don't you follow the old rule "if it ain't broke, don't fix it"?

I was rolling the kernels myself for quite a while in my distro (Arch Linux), because the "revised" kernels included a patch which made my NIC losing a lot of packets- so I had either to use an older one, or roll one of my own. This lasted some four months, and not less than nine kernel revisions (kernels update pretty frequently in a bleeding edge distro). Since you have no real need to upgrade, or roll a custom kernel, why don't you just use revision 13 and wait to test 15 later on?

 

I may have to do just that scarecrow. I tried re-downloaded and re-installed the -14 kernel and it still didn't fix my problem. So I rebooted back into the -13 kernel. All is well for now and since I do, at least, have the -14 kernel installed, it shouldn't complain. In the meantime, I'll review the changelog, as you suggest, and wait for the next kernel revision.

Link to comment
Share on other sites

You may want to try installing the package kernel-source-stripped-latest and rebooting to the 14mdv kernel - see if that improves matters.

 

Thanks adamw, but I already do have those installed. No change. As an FYI, I do have issues with the USB subsystem using the -13 kernel. This is why I "rejoiced" when the -14 kernel was released. However, that caused the issues in this thread.

Link to comment
Share on other sites

Hi, I'm interested in this topic too, because I'm upgrading kernel from -13mdv (legacy) to the bugfix -14mdv, and I'm also getting a problem.

 

So far, I did the update on a desktop machine (in order to solve the hangup bug when opening-up/closing down with a USB device plugged in). The new -14mdv kernel boots up fine and I get the GUI to start fine. (The box also shuts down without a hangup/freeze when the USB device is still plugged in -- which I understood to be the purpose of the bugfix. So far so good, but that's still not quite problem-free, becase in the presence of the USB device during shutdown, the video display goes to snow. It does at least shutdown though, and there was no 'improper shutdown' to cause complaint at the next bootup.)

 

But one effect of the kernel update now is that the kernel modules (non-updated) 'complain' during init. They give exit messages with 'bad build' message no.8.

 

What can I do about this? In part it's been a good lesson already, because some of the non-functioning kernel modules identified themselves as not needed at all. So I could simply uninstall their packages without loss, for quicker boot/init time (e.g. not-needed drivers for not-present video hardware).

 

However, the HAL daemon is one of the 'bad build' non-installers. I can't uninstall that (even for the sole purpose of re-installing) because urpmi would want to take away, uninstall, zillions of other important packages at the same time as it removes HAL. I'm afraid that if I let this happen, the cure would be worse than the disease....

 

I would like to get HAL back to order again (partly because in the present state the machine takes an appreciably longer length of time than it did before to recognise a newly-plugged USB device... I'm guessing that possibly the absence of the effective HAL kernel module could be contributory).

 

Also, on another machine (laptop) I am contemplating doing the update, to the bugfix kernel -14mdv (legacy), the laptop is currently at -13mdv. But the laptop depends crucially on a kernel module for its wireless network connectivity. So I don't want to risk doing a kernel update there, until I'm confident that the question is solved of fixing up kernel modules to play happily with the new 'bugfix' kernel.

 

I installed the stripped kernel sources for the new kernel when updating the kernel for the desktop -- because I guessed that might be important for getting kernel modules to play ok. But that doesn't seem to be effective at least on its own.

 

I can't find any other instructions for adapting kernel modules to an updated kernel -- and any useful pointers would be appreciated.

 

Terry

Link to comment
Share on other sites

  • 1 month later...

Well..... fixed the issue.

 

In trying to resolve a problem with Suspend To Disk on this same machine, I solved this issue by adding a kernel option to my 2.6.17-14mdv line in Grub. I added 'noapic'. Now, I am able to boot into 2.6.17-14mdv with no problems.

 

FYI - I had the Suspend To Disk issue before as well. But hey, one down, one to go.

 

-----------

 

Adamw, I do have a NVidia card in this machine (NVidia GeForce 4200 Ti) using the nv96xx rpm package for it.

 

-----------

 

Terry, you might be able to do something with the symlinks in the /boot partition to get it to use the old modules..... not sure though what this might do.

 

[edited by tyme to fix link code. remember: no html code in posts, only bbcode]

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...