Re: [arch-general] [signoff] kernel 2.6.36-3
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..
Re: [arch-general] [signoff] kernel 2.6.36-3
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 -- 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
Re: [arch-general] [signoff] kernel 2.6.36-3
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.
Re: [arch-general] [signoff] kernel 2.6.36-3
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...
Re: [arch-general] [signoff] kernel 2.6.36-3
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). Wireless is still working alright so far ( = 2 hours usage), suspend/resume worked, and nothing else seems odd about my system either. Signoff x86_64. (Is that too hasty? Should I wait a day? I'll report back if anything goes wrong, anyway.) -Isaac
Re: [arch-general] [signoff] kernel 2.6.36-3
On 11/01/2010 01:47 PM, Tobias Powalowski wrote: Hi guys, please signoff 2.6.36 series for both arches and give feedback if real issues arise. snip greetings tpowa Tobias, 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. Heinz Mauelshagen had the following suggestions: Hi David, because you're able to access your config fine with some arch LTS kernels, it doesn't make sense to analyze your metadata upfront and the following reasons may cause the failures: - initramfs issue not activating ATARAID mappings properly via dmraid - drivers missing to access the mappings - host protected area changes going together with the kernel changes (eg. the Error 24: Attempt to access block outside partition); try the libata.ignore_hpa kernel paramaters described in the kernel source Documentation/kernel-parameters.txt to test for this one FYI: in general dmraid doesn't rely on a particular controller, just metadata signatures it discovers. You could attach the disks to some other SATA controller and still access your RAID sets. Regards, Heinz I will try the libata.ignore_hpa setting and let you know. If you can think of anything else, any other diagnostics, on the Arch side to try, please let me know and I'll be happy to try it. Thanks. -- 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
Re: [arch-general] [signoff] kernel 2.6.36-3
On 11/01/2010 01:47 PM, Tobias Powalowski wrote: Hi guys, please signoff 2.6.36 series for both arches and give feedback if real issues arise. snip greetings tpowa Tobias, Per the suggestions of the dm-devel guys, I have tested with both libata.ignore_hpa=0 (default) and libata.ignore_hpa=1 (ignore limits, using full disk), but there is no change. I still get grub Error 24: (this is with the 2.6.36-3 kernel). So I'm stumped again. If you have any other ideas, please let me know. I'm happy to test on this end. -- 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
Re: [arch-general] [signoff] kernel 2.6.36-3
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. Boot the kernel and initrd from a medium that is not part of the dmraid (like a flash drive) and you'll be fine. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [signoff] kernel 2.6.36-3
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
Re: [arch-general] [signoff] kernel 2.6.36-3
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
Re: [arch-general] [signoff] kernel 2.6.36-3
Norbert Zeh [2010.11.03 2043 -0300]: 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? 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? - Norbert
Re: [arch-general] [signoff] kernel 2.6.36-3
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
Re: [arch-general] [signoff] kernel 2.6.36-3
Am Wed, 03 Nov 2010 20:57:35 -0500 schrieb David C. Rankin drankina...@suddenlinkmail.com: 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
Re: [arch-general] [signoff] kernel 2.6.36-3
On 11/03/2010 10:03 PM, Heiko Baums wrote: Am Wed, 03 Nov 2010 20:57:35 -0500 schrieb David C. Rankin drankina...@suddenlinkmail.com: 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
Re: [arch-general] [signoff] kernel 2.6.36-3
On 11/01/2010 02:47 PM, Tobias Powalowski wrote: Hi guys, please signoff 2.6.36 series for both arches and give feedback if real issues arise. I had a problem with .34 which was fixed in .35 and started reappearing in .36. When resuming from suspend, I would often not get video back, I have an r600 radeon gpu. I think it has to do with the new pm profile functionality. (un)fortunately, it doesn't always happen. In fact, it seems like it happens after long periods of suspend, rather than a few minutes to an hour... Anyone notice this?
