On 11/03/2010 06:28 PM, Thomas Bächler wrote:

You don't seem to understand at all. There is NOTHING the dm-devel guys, we, or you for that matter can do about this. There is no problem with Linux accessing or activating your dmraid.

If grub fails to access the partition properly, then your BIOS is broken, and you can only fix the problem by fixing your BIOS. If there is no update for the BIOS (and/or the dmraid BIOS), then you are simply screwed.

Boot the kernel and initrd from a medium that is not part of the dmraid (like a flash drive) and you'll be fine.

Now that is what I didn't understand... If this is a BIOS issue, then we may just be hosed. What always makes me wonder is why it works fine with some kernels and not others. It isn't inconsistent with any 1 kernel. If a kernel-A boots - then it boots every time. If the kernel-B hangs -- then kernel-B hangs every time. What I was exploring is "what the heck is the difference between kernel-A (that works) and kernel-B (that fails)?" Some code is doing something that causes this, but I haven't got a clue what code that is. I only see it when I change kernels. However, I don't rule out it just being a screwy bios. This box has worked with SuSE 11.0-11.3 and with Arch beginning with 200809 and since. The boot issue only began with 2.6.34X. That's the only reason I think it has to be something that changed with the software, because the hardware has been consistent throughout. I'll just relegate the box to using the kernels that work on it and quit reporting the ones that work and ones that fail. I know that I don't know enough to debug it further, so we will leave it here. If the dm-devel guys come up with something, I'll pass that along. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

Thomas Bächler [2010.11.04 0028 +0100]:

Am 03.11.2010 23:23, schrieb David C. Rankin:

...

As mentioned, I have the same boot failure with 2.6.36-3 (grub Error 24:) However, I have received the first bit of feedback from the dm-devel list.

You don't seem to understand at all. There is NOTHING the dm-devel guys, we, or you for that matter can do about this. There is no problem with Linux accessing or activating your dmraid.

If grub fails to access the partition properly, then your BIOS is broken, and you can only fix the problem by fixing your BIOS. If there is no update for the BIOS (and/or the dmraid BIOS), then you are simply screwed.

I don't know anything about the inner workings of grub, dmraid or the kernel. However, what I don't understand about your explanation is that, according to David, the machine boots just fine under some kernels and not under others. So, unless the error is intermittent (which it doesn't sound like) or there have been changes in how one of grub/dmraid/kernel interact with the BIOS, shouldn't he be seeing the same error also with 2.6.35-7? Just curious. - Norbert

On 11/03/2010 06:50 PM, Norbert Zeh wrote:

Aah, it just hit me: the problem may in fact be fairly random in that it may depend on where the initramfs is stored. So, if the BIOS is broken, you may be lucky to be able to boot under one kernel, and the next upgrade places things in a place on disk where the BIOS bug kicks in, and you're screwed. So it has nothing to do with the kernel version, grub or dmraid in this case. Do I understand this correctly?

I think that is exactly the understanding I got from Thomas, and it makes an uncanny amount of sense. Though it doesn't have a 100% correlation, it does explain why just about ever-other kernel has exhibited this problem. I'll do a test. Right now I have 2.6.35-7 installed. I have upgraded to 2.6.35-8 (wouldn't boot), downgraded to 2.6.35-7 (worked), upgraded to 2.6.36-3 (wouldn't boot). So if this theory is correct, I should be able to start with 2.6.35-7 (working), upgrade to 2.6.35-8 (expect failure), then upgrade directly to 2.6.36-3 and (expect success) -- even though a direct update from 2.6.35-7 to 2.6.36-3 originally resulted in failure. If this works I'll.... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On 11/03/2010 10:03 PM, Heiko Baums wrote:

Am Wed, 03 Nov 2010 20:57:35 -0500 schrieb "David C. Rankin" :

...

I think that is exactly the understanding I got from Thomas, and it makes an uncanny amount of sense. Though it doesn't have a 100% correlation, it does explain why just about ever-other kernel has exhibited this problem.

I'll do a test. Right now I have 2.6.35-7 installed. I have upgraded to 2.6.35-8 (wouldn't boot), downgraded to 2.6.35-7 (worked), upgraded to 2.6.36-3 (wouldn't boot).

So if this theory is correct, I should be able to start with 2.6.35-7 (working), upgrade to 2.6.35-8 (expect failure), then upgrade directly to 2.6.36-3 and (expect success) -- even though a direct update from 2.6.35-7 to 2.6.36-3 originally resulted in failure.

If this works I'll....

I guess there has been something changed in the kernel26 2.6.35.8 and above which doesn't work with your BIOS or your RAID. Either this is a bug in kernel26 2.6.35.8 and newer or it is not a bug but a new feature or a change which doesn't work with your probably outdated BIOS.

I'd suggest asking kernel upstream by either filing a bug report at kernel.org or asking on their mailing list.

It definitely must have something to do with the kernel. Otherwise it wouldn't work again after a kernel downgrade.

Heiko

Heiko, I think you are correct. Because I did the test starting with 2.6.35-7 (working), upgrade to 2.6.35-8 (expect failure -- it did), then upgrade directly to 2.6.36-3 and (expect success -- it failed too). Just to be sure, I re-made the initramfs a couple of times and tried booting with them - they all failed as well. Then downgraded to 2.6.35-7 -> it works like a champ -- no matter what order it gets installed in. I'll follow up with the kernel folks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

Excerpts from Isaac Dupree's message of 2010-11-08 05:08:25 +0100:

On 11/07/10 18:23, Matthew Monaco wrote:

...

Anyone have issues changing from Xorg to one of the tty's? I've got a radeon r600.

No problems on my Intel 945 (aside from the long-standing "sometimes randomly, on boot after mode-setting but before entering X for the first time, it doesn't display anything").

For me it's the long-standing "always, on boot after mode-setting but before entering X for the first time, it doesn't display anything, unless something is plugged into the VGA port." I wonder when this will get fixed..

On 11/08/2010 03:14 PM, David C. Rankin wrote:

On 11/07/2010 05:23 PM, Matthew Monaco wrote:

...

Anyone have issues changing from Xorg to one of the tty's? I've got a radeon r600.

Mathhew,

I'll give it a go after install 2.6.36-3. (Which I'm somewhat scared to do.) This box has an X800PE card that is running perfectly (fast as hell) with compiz, etc.. with 2.6.35-8 and the radeon driver. (never thought I would say that)

So it's with a bit of trepidation, I update :p

Ok, just boot into X and then try ctrl+alt+f1... I had initially noticed that my screen wasn't coming back after a resume, and I think this is related. When the screen doesn't come back, I can play around with the terminals until a ctrl+alt+f7 lands me back at a functioning screen.

On 11/08/2010 07:49 PM, Matthew Monaco wrote:

On 11/08/2010 07:34 PM, Matthew Monaco wrote:

...

On 11/08/2010 03:14 PM, David C. Rankin wrote:

...

On 11/07/2010 05:23 PM, Matthew Monaco wrote:

...

Anyone have issues changing from Xorg to one of the tty's? I've got a radeon r600.

Mathhew,

I'll give it a go after install 2.6.36-3. (Which I'm somewhat scared to do.) This box has an X800PE card that is running perfectly (fast as hell) with compiz, etc.. with 2.6.35-8 and the radeon driver. (never thought I would say that)

So it's with a bit of trepidation, I update :p

Ok, just boot into X and then try ctrl+alt+f1... I had initially noticed that my screen wasn't coming back after a resume, and I think this is related. When the screen doesn't come back, I can play around with the terminals until a ctrl+alt+f7 lands me back at a functioning screen.

Hmm, this appears to be related to the fact that I had "video=VGA-1:d" in my grub kernel command line. I used to have a TV connected to the VGA port and didn't like the way KMS set a small resolution on my main computer monitor. I don't need the VGA-1:d anymore, but this still shouldn't cause the black screen...

Started happening again w/o video=VGA-1:d, so there goes that idea.