Misaligned Resource Pointer (2.6.15-22 Kernel issues)

It seems there is an issue with the 2.6.15-22 kernel's APIC code for VIA chipsets.

Without adjusting anything, I attempted to upgrade directly to MEPIS 6.0Beta4 and still encountered kernel panics and unexpected lock-ups. After disabling the APIC on my mobo (via the BIOS) and successfully upgrading to MEPIS 6.0Beta4, the whole thing rebooted and functioned better than it ever has before. I had no idea an old, worn-out 1.7GHz P4 could run so well! To say the least, it flat out screams now! For comparison: My CAD station at work is a 3.4GHz P4 (800MHz FSB) with 2GB RAM running XP Pro from a SATA drive. It literally jumps up at boot time. My MEPIS box at home, with it's OLD P4 (100MHz FSB), 512MB RAM, and ATA66 HDD; boots in about 1.333 the time of my CAD station.

I haven't tried switching the APIC back on yet under the 2.6.15-23 kernel. I'm saving that for tonight. I'll keep everyone posted with the results.

Try adding " noapm acpi=force " to the boot code and see if that helps.

Interesting i have the same brand but with an amd chip & little later i suppose via chipset vt8366 north and 82xxx south and it didnt do anything but stop the xwindow system from loading . Startx didnt work as well as ctrl alt f7 . Didnt push it didnt want to reinstall or play with xorg.

Reason i tried it is i have a couple of those errors on b3 and 4 . Amd 2600 in my case so it seems its particular to the intel type configs. Just had to try it though ya never know.... Allso tried live cd with it off slowed it to a crawl all i know is its over my head...

jim

1) Re-enabled APIC and forced "noacpi noapm" when booting. Bad move. Switched off APIC. Reboot OK.

2) Upgraded to "New" nvidia-glx via OS Center, set Twin-view mode "ON" with "TV" as the second display and rebooted. X refused to start IN TWIN-VIEW MODE. Machine also refused to find some PCI devices and kicked out ehci errors on reboot before config of PCI devices. Unplugged Lexar RW-022 media card reader. Reboot sort of OK but still no X. Fixed XOrg config from CD. (Turned OFF Twin-View.) Reboot OK.

Now, what the heck is causing all of this? This has to be in the kernel itself or, depending on when it starts, in udevd. Being that the kernel relies on other programs to communicate with some devices and udev handles a great deal of the un/loading of drivers, I'm beginning to suspect udev has a problem which remains either undetected or under acknowledged.

All that being said, I want to say I'm NOT knocking MEPIS. I still think MEPIS rocks but these hardware interface issues need some serious fix thrown at them.

The issues mentioned here remind me of some that I've been having.

One of my systems has a PC Chips 825G mainboard running a Sempron 2700. Sometime after Mepis 3.4, I starting getting complete system crashes (required re-installation) after updates. Turned out to be the new kernel. None of the M6 betas will boot (even from CD) on this machine. Neither will Knoppix 4.0 or Mandriva. FC5 won't install. Kubuntu 6.06 will load from CD, but will not boot after an install. All of these crash during system initialization. I think that the PCI subsystem on the board is not being initialized properly and thus devices are not found (some distros don't even find the memory, and some don't find the video subsystem, thus no X).

Older distros with older kernels boot fine and run solid, so I do believe that there is an issue in the newer kernels that is causing the trouble.

I reported this to Warren after m6b1, and have updated him as I have learned more about the issue, but m6b4 shows the same behavior.

IANAP, and I wouldn't have the foggiest idea how to file a kernel issue, but I think that the kernel is the "root" of the problem, and it will have to be solved at that level.

Irv

Which chipset do you have on that 825G? If it's VIA, then that may be part of the problem. As I said in an earlier post, my mobo has the VIA Rhine/82xx chipset. I've had problems with VIA chipsets with other distros in the past. My thoughts are that VIA is somewhat aberrant when compared to Intel but that's only my opinion.

There are other problems that have arisen out of the new kernels as well which don't necessarily point to it being at fault here. UDEV seems to be the growing trend within Linux because it adds functionality that only appeared in commercial OSes, like intelligent automounting and device management, but there seems to be something wrong with certain kernel level stuff not being available at boot time, i.e. USB device drivers, et al. Allow me to explain...

After updating the nVidia driver and switching on TwinView, M6b4 booted but cacked out with an ehci_hcd error. This was due to my Lexar RW022 card reader being plugged in. My mobo is capable of booting from a USB card reader so the device is immediately visible through the BIOS when the PC is switched on. I tested this behaviour after fixing the XOrg config and found that I'd lost all my PCI devices, in particular the wireless card.

With all this in mind, if the kernel hasn't been able to load the proper drivers via UDEV at boot, what stops it from dropping into a panic state? Further, if UDEV cacks out with an error during boot, where does that leave the kernel when it looks at other devices or rather, can the kernel even SEE other devices if UDEV errs out? This prompts a question from me: Has UDEV been hardened to sustain a potentially fatal error and recover sufficiently to keep running _properly_? Also, how early in the boot are we starting UDEV? If UDEV is starting too early, some USB devices won't have had enough time to settle and be ready to respond to queries.

IMHO, I think the culprit is UDEV and not so much the kernel. Irv, I hope you've tried the "noacpi noapm" at boot to get M6b4 installed and running because it is really a spectacular OS. Warren, should you be reading this, WELL DONE!!!

You're right, it's VIA. However, there is _nothing_ USB plugged in to it at all.

You could be right that it's UDEV - I'm 80% end-user and only 20% nerd.

The system DOES run solid on 3.4.3, however, as long as I lock down all the kernel stuff so it deosn't get upgraded.

'noacpi noapm' make no difference.

But I agree with you about Mepis - it's the only Linux I run.

Irv

Ok, Irv, here's something to look for. These are the exact same methods I used to get M6b4 installed and running smoothly. In case anything doesn't go smoothly, I'll post back where to find these settings in your BIOS _IF_ your BIOS is the same brand as mine. I am using an AMI BIOS.

When you boot, go into the BIOS and see if there is a setting to turn OFF your APIC. If so, switch it off! There should also be a setting to reset all ESCD data in the PCI cards. Enabled it to reset your PCI device configuration data at the next boot. The PCI config reset will occur as soon as you exit your BIOS. Now with the APIC switched off and your PCI devices cleared of config data, boot to M6b4 and add "noacpi noapm" to the init line at the bottom of the screen. You *should* get a successful boot and be able to install without issue. If there was a way I could talk you through it, I would.

Give it a shot and get back to me. And looking over your post, I'm starting to think the APIC code in the kernel or UDEV itself is causing our problems. Like I said, VIA chipsets are a little aberrant when compared to Intel.

Oh, and who says I'm a "nerd" anyway? I'm a GEEK to be exact...

I think I tried this at some point, but will give it a shot just in case.

Probably should have said 'geek' not 'nerd,' but it was _me_ to whom I was referring.

Irv

I've updated my Debian repos list and found that there is a new ACPI driver available in the Debian pool at ftp.us.debian.org. I'm not sure which portion of the pool it is in but have a look around and see if you can find it. If it's in the experimental pool, I don't recommend trying it until it's been tested. With that in mind, I'll be the guinea pig and see what happens. I'll post back the results.

Also, when you add "noacpi noapm" to the init line, be sure there are no other references to ACPI and APM. Conflicting references will force init to go with the defaults; ACPI and APM turned on.

"Reality? Oh, yeah. That has nothing to do with me."

Gave it another try. The bios on this board has no way I can find to reset the PCI card data [bummer]. Turned off ACPI, booted using 'noapm noacpi'. The system failed to see the wireless card, then seg faulted and quit right around when meauto was starting.

It runs solid on 3.4.3, so I guess I'm staying with that.

Irv

There has to be a switch to reset ESCD data! Practically every BIOS made has a reset ESCD switch. It would be really odd if yours didn't.

Turning off ACPI in the BIOS doesn't do much. It's the APIC (Advanced Programmable Interrupt Controller) that has to be turned off. It would surprise me if every new BIOS had an APIC switch.

Also, be certain there are no other references to ACPI or APM on the init line when booting to the CD. Conflicts resolve to the default with ACPI and APM "on."

"Reality? Oh, yeah. That has nothing to do with me."