[arch-general] Update to 2.6.34.3-1 & LTS 2.6.32.18-1 killed dmraid box??
Guys, This one caught me by surprise. I have my test server that I update before updating my regular server. It is based on a MSI K9N2 board (MS-7374) with a Phenom 9850 proc & 8G of ram. The box has 2 dmraid arrays: [22:00 ecstasy:/mnt/arch] # dmraid -r /dev/sdd: nvidia, "nvidia_baaccaja", mirror, ok, 1465149166 sectors, data@ 0 /dev/sdc: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_baaccaja", mirror, ok, 1465149166 sectors, data@ 0 /dev/sda: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 [22:00 ecstasy:/mnt/arch] # dmraid -s *** Active Set name : nvidia_baaccaja size : 1465149056 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 *** Active Set name : nvidia_fdaacfde size : 976773120 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 The kernel updates applied tonight were: [2010-08-16 20:13] upgraded kernel26 (2.6.34.2-2 -> 2.6.34.3-1) [2010-08-16 20:13] upgraded kernel26-headers (2.6.34.2-2 -> 2.6.34.3-1) [2010-08-16 20:14] upgraded kernel26-lts (2.6.32.17-2 -> 2.6.32.18-1) Both completed successfully. The pacman.log info is here: http://www.3111skyline.com/dl/Archlinux/bugs/pm-updt-8-16.txt After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with: /sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from). I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back? I believe I have the correct modules in mkinitcpio.conf (they are the same ones I have had in the conf file since I first loaded Arch with the 200902 install media in March '09). Here is the lspci info (running suse): The raid controller is the standard nvraid soft raid controller: 00:09.0 RAID bus controller: nVidia Corporation Device 0ad8 (rev a2) Subsystem: Micro-Star International Co., Ltd. Device 7374 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 4347 I/O ports at b080 [size=8] I/O ports at b000 [size=4] I/O ports at ac00 [size=8] I/O ports at a880 [size=4] I/O ports at a800 [size=16] Memory at f9e76000 (32-bit, non-prefetchable) [size=8K] Capabilities: [44] Power Management version 2 Capabilities: [8c] SATA HBA <?> Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable+ Capabilities: [ec] HyperTransport: MSI Mapping Enable+ Fixed+ Kernel driver in use: ahci Kernel modules: ahci What say the gurus? (Tobias what could have changed here?) Any help would be greatly appreciated. I'll keep dorking with it, but I'm at a loss here... Additional Info: The partitions on the box are: [22:02 ecstasy:/mnt/arch] # cat /proc/partitions major minor #blocks name 8 0 488386584 sda 8 1 1 sda1 8 5 72229 sda5 8 6 2104483 sda6 8 7 20972826 sda7 8 8 465234336 sda8 8 16 732574584 sdb 8 17 1 sdb1 8 21 19534977 sdb5 8 22 120456 sdb6 8 23 39062016 sdb7 8 24 1951866 sdb8 8 25 15358108 sdb9 8 26 30716248 sdb10 8 27 7510356 sdb11 8 28 618317721 sdb12 8 32 488386584 sdc 8 33 1 sdc1 8 37 72229 sdc5 8 38 2104483 sdc6 8 39 20972826 sdc7 8 40 465234336 sdc8 8 48 732574584 sdd 8 49 1 sdd1 8 53 19534977 sdd5 8 54 120456 sdd6 8 55 39062016 sdd7 8 56 1951866 sdd8 8 57 15358108 sdd9 8 58 30716248 sdd10 8 59 7510356 sdd11 8 60 618317721 sdd12 253 0 732574583 dm-0 253 1 488386583 dm-1 253 2 732572001 dm-2 253 3 19534977 dm-3 253 4 120456 dm-4 253 5 39062016 dm-5 253 6 1951866 dm-6 253 7 15358108 dm-7 253 8 30716248 dm-8 253 9 7510356 dm-9 253 10 618317721 dm-10 253 11 488384001 dm-11 253 12 72229 dm-12 253 13 2104483 dm-13 253 14 20972826 dm-14 253 15 465234336 dm-15 -- 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 08/16/2010 10:17 PM, David C. Rankin wrote:
After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from).
I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back?
When 2.6.34-3 starts, you only get the first few lines of the boot process like: root(1,5) bzimage..... it sits there for a while just doing nothing, then when it hits a timeout or something - boom it reboots. I was able to reboot into LTS so I have that, but the normal kernel is hosed. I'll hold off downgrading or jumping ahead into 2.6.35 from testing to see if we can determine what is broken. That may help keep it from biting us again in 2.6.36. Let me know your thoughts on this. I'm stumped. Also, since this box has a nvidia graphics card, I get no X with LTS. The first time I asked (no too long after LTS came to life), the answer was you don't get X with LTS, it has no support. But I know X works now due to my laptop running X fine on LTS (radeon based). Is there any way this box will run X too? It would be nice to have in situations like this. I didn't have to do anything to the laptop to get it to run X with LTS, what is the trick to get X working with LTS on this test server box? The video card is an nvidia 8800GT and I normally use the proprietary nvida module. Can I configure LTS to use it somehow? Rebuild the kernel module? The X issue is secondary to the boot fail issue, but I thought I would ask. As always any help would be appreciated. -- 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
David C. Rankin (2010-08-17 00:48):
On 08/16/2010 10:17 PM, David C. Rankin wrote:
After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from).
I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back?
When 2.6.34-3 starts, you only get the first few lines of the boot process like:
root(1,5) bzimage.....
it sits there for a while just doing nothing, then when it hits a timeout or something - boom it reboots.
Remove the 'quiet' option from the kernel command line and look for more useful information (if you are using grub, press 'e' during grub prompt and delete the word 'quiet').
I was able to reboot into LTS so I have that, but the normal kernel is hosed. I'll hold off downgrading or jumping ahead into 2.6.35 from testing to see if we can determine what is broken. That may help keep it from biting us again in 2.6.36. Let me know your thoughts on this. I'm stumped.
Also, since this box has a nvidia graphics card, I get no X with LTS. The first time I asked (no too long after LTS came to life), the answer was you don't get X with LTS, it has no support. But I know X works now due to my laptop running X fine on LTS (radeon based). Is there any way this box will run X too? It would be nice to have in situations like this. I didn't have to do anything to the laptop to get it to run X with LTS, what is the trick to get X working with LTS on this test server box? The video card is an nvidia 8800GT and I normally use the proprietary nvida module. Can I configure LTS to use it somehow? Rebuild the kernel module?
The X issue is secondary to the boot fail issue, but I thought I would ask. As always any help would be appreciated.
If you need X only for testing, use a simpler driver: xf86-video-vesa xf86-video-nv xf86-video-nouveau (probably won't work with an older kernel) -- -- Rogutės Sparnuotos
On 08/17/2010 05:53 AM, Rogutės Sparnuotos wrote:
David C. Rankin (2010-08-17 00:48):
On 08/16/2010 10:17 PM, David C. Rankin wrote:
After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from).
I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back?
When 2.6.34-3 starts, you only get the first few lines of the boot process like:
root(1,5) bzimage.....
it sits there for a while just doing nothing, then when it hits a timeout or something - boom it reboots.
Remove the 'quiet' option from the kernel command line and look for more useful information (if you are using grub, press 'e' during grub prompt and delete the word 'quiet').
# (0) Arch Linux title Arch Linux on Archangel root (hd1,5) kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro initrd /kernel26.img # (1) Arch Linux title Arch Linux Fallback root (hd1,5) kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro initrd /kernel26-fallback.img Unfortunately -- there was no quiet to begin with. It only gets that far and then dies. Any other thoughts?
The X issue is secondary to the boot fail issue, but I thought I would ask. As always any help would be appreciated.
If you need X only for testing, use a simpler driver: xf86-video-vesa xf86-video-nv xf86-video-nouveau (probably won't work with an older kernel)
Thanks, I'll give the nv driver a shot. -- 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
David C. Rankin (2010-08-17 08:20):
On 08/17/2010 05:53 AM, Rogutės Sparnuotos wrote:
David C. Rankin (2010-08-17 00:48):
On 08/16/2010 10:17 PM, David C. Rankin wrote:
After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from).
I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back?
When 2.6.34-3 starts, you only get the first few lines of the boot process like:
root(1,5) bzimage.....
it sits there for a while just doing nothing, then when it hits a timeout or something - boom it reboots.
Remove the 'quiet' option from the kernel command line and look for more useful information (if you are using grub, press 'e' during grub prompt and delete the word 'quiet').
# (0) Arch Linux title Arch Linux on Archangel root (hd1,5) kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro initrd /kernel26.img
# (1) Arch Linux title Arch Linux Fallback root (hd1,5) kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro initrd /kernel26-fallback.img
Unfortunately -- there was no quiet to begin with. It only gets that far and then dies. Any other thoughts?
So all that you see after the grub prompt is this (including the dots)? root(1,5) bzimage..... What if you put 'debug' there, so that the line reads: kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug Does anything change if you rebuild the initrd image with mkinitcpio? Did you try booting the fallback image? -- -- Rogutės Sparnuotos
On 08/17/2010 10:39 AM, Rogutės Sparnuotos wrote:
David C. Rankin (2010-08-17 08:20):
On 08/17/2010 05:53 AM, Rogutės Sparnuotos wrote:
David C. Rankin (2010-08-17 00:48):
On 08/16/2010 10:17 PM, David C. Rankin wrote:
After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with:
/sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from).
I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back?
When 2.6.34-3 starts, you only get the first few lines of the boot process like:
root(1,5) bzimage.....
it sits there for a while just doing nothing, then when it hits a timeout or something - boom it reboots.
Remove the 'quiet' option from the kernel command line and look for more useful information (if you are using grub, press 'e' during grub prompt and delete the word 'quiet').
# (0) Arch Linux title Arch Linux on Archangel root (hd1,5) kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro initrd /kernel26.img
# (1) Arch Linux title Arch Linux Fallback root (hd1,5) kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro initrd /kernel26-fallback.img
Unfortunately -- there was no quiet to begin with. It only gets that far and then dies. Any other thoughts?
So all that you see after the grub prompt is this (including the dots)?
root(1,5) bzimage.....
Well, there are complete sentences there, I'll take a pad with me and copy it down verbatim
What if you put 'debug' there, so that the line reads:
kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug
Does anything change if you rebuild the initrd image with mkinitcpio? Did you try booting the fallback image?
I've already tried rebuilding initrd, and nothing changed. I'll go give debug a shot and report back. Thank you for your help! -- 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 08/17/2010 10:39 AM, Rogutės Sparnuotos wrote:
So all that you see after the grub prompt is this (including the dots)?
root(1,5) bzimage.....
What if you put 'debug' there, so that the line reads:
kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug
What it says in total is: Booting 'Arch Linux on Archangel' root (hd1,5) Filesystem Type ext2fs, partition type 0x83 kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug [Linux-BzImage, setup=0x3200, size=0x1ff440] (then it sits and reboots) This must have something to do with how 2.6.34.3 handles dmraid, because after a failed boot, the bios reports the second array as "Unhealthy". (It is fine). Simply powering off and back on re-syncs the array and it boots into LTS just fine. Adding debug makes no difference. What does this look like to you? Broken dmraid for nv8200 chipset in 2.6.34.3? I know this is *not* a generic dmraid, nvraid or 2.6.34.3 issue, because to trouble-shoot I updated my *regular* server (Tyan Computer Tomcat K8E (S2865)) to 2.6.34.3 and it uses nv_sata and dmraid as well. Updated without an issue. The working server has the following dmraid config and lspci info: [12:57 nirvana:/home/david] # dmraid -r /dev/sdb: nvidia, "nvidia_ddddhhfh", mirror, ok, 1465149166 sectors, data@ 0 /dev/sda: nvidia, "nvidia_ddddhhfh", mirror, ok, 1465149166 sectors, data@ 0 [12:57 nirvana:/home/david] # dmraid -s *** Active Set name : nvidia_ddddhhfh size : 1465149056 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 lspci info: 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Tyan Computer Tomcat K8E (S2865) Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at 09f0 [size=8] I/O ports at 0bf0 [size=4] I/O ports at 0970 [size=8] I/O ports at 0b70 [size=4] I/O ports at d400 [size=16] Memory at febfc000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Kernel driver in use: sata_nv Kernel modules: ata_generic, pata_acpi, sata_nv, ide-pci-generic 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO]) Subsystem: Tyan Computer Tomcat K8E (S2865) Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 I/O ports at 09e0 [size=8] I/O ports at 0be0 [size=4] I/O ports at 0960 [size=8] I/O ports at 0b60 [size=4] I/O ports at c000 [size=16] Memory at febfb000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 Kernel driver in use: sata_nv Kernel modules: ata_generic, pata_acpi, sata_nv, ide-pci-generic On the test server where 2.6.34.3 will *not* boot you have (running LTS): [13:04 archangel:/home/david] # dmraid -r /dev/sda: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_baaccaja", mirror, ok, 1465149166 sectors, data@ 0 /dev/sdc: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 /dev/sdd: nvidia, "nvidia_baaccaja", mirror, ok, 1465149166 sectors, data@ 0 [13:04 archangel:/home/david] # dmraid -s *** Active Set name : nvidia_fdaacfde size : 976773120 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 *** Active Set name : nvidia_baaccaja size : 1465149056 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 lspci info: 00:09.0 RAID bus controller: nVidia Corporation MCP78S [GeForce 8200] SATA Controller (RAID mode) (rev a2) Subsystem: Micro-Star International Co., Ltd. Device 7374 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 28 I/O ports at b080 [size=8] I/O ports at b000 [size=4] I/O ports at ac00 [size=8] I/O ports at a880 [size=4] I/O ports at a800 [size=16] Memory at f9e76000 (32-bit, non-prefetchable) [size=8K] Capabilities: [44] Power Management version 2 Capabilities: [8c] SATA HBA v1.0 Capabilities: [b0] MSI: Enable+ Count=1/8 Maskable- 64bit+ Capabilities: [ec] HyperTransport: MSI Mapping Enable+ Fixed+ Kernel driver in use: ahci Kernel modules: ahci The big difference I see is that my main server 'nirvana' uses: Kernel driver in use: sata_nv Kernel modules: ata_generic, pata_acpi, sata_nv, ide-pci-generic which is working just fine with 2.6.34.3 while the test box 'archangel' uses: Kernel driver in use: ahci Kernel modules: ahci so it looks like the problem is in the ahci module and dmraid. Now how to fix? I have always used this box with mkinitcpio.conf configured with: MODULES="dm_mod dm_mirror sata_nv" I'll go see if I can rebuild with the ahci module loaded in the initramfs and see if that helps. But regardless, there is a bug somewhere. LTS boots fine in this config and 2.6.34.3 doesn't?? -- 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 08/17/2010 01:27 PM, David C. Rankin wrote:
I'll go see if I can rebuild with the ahci module loaded in the initramfs and see if that helps. But regardless, there is a bug somewhere. LTS boots fine in this config and 2.6.34.3 doesn't??
adding ahci to the MODULES line in mkinitcpio.conf and rebuilding the initramfs made no difference. The box still freezes on boot at the very beginning of the boot process with: Booting 'Arch Linux on Archangel' root (hd1,5) Filesystem Type ext2fs, partition type 0x83 kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug [Linux-BzImage, setup=0x3200, size=0x1ff440] showing on the screen. The box sits like that for 30-60 seconds and then automagically reboots. Booting back into LTS works fine. I guess we need to open a report on this one.... -- 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 08/17/2010 01:44 PM, David C. Rankin wrote:
On 08/17/2010 01:27 PM, David C. Rankin wrote:
I'll go see if I can rebuild with the ahci module loaded in the initramfs and see if that helps. But regardless, there is a bug somewhere. LTS boots fine in this config and 2.6.34.3 doesn't??
adding ahci to the MODULES line in mkinitcpio.conf and rebuilding the initramfs made no difference. The box still freezes on boot at the very beginning of the boot process with:
Booting 'Arch Linux on Archangel'
root (hd1,5) Filesystem Type ext2fs, partition type 0x83 kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug [Linux-BzImage, setup=0x3200, size=0x1ff440]
showing on the screen. The box sits like that for 30-60 seconds and then automagically reboots. Booting back into LTS works fine. I guess we need to open a report on this one....
Added as: http://bugs.archlinux.org/task/20499 -- 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
David C. Rankin (2010-08-17 14:45):
On 08/17/2010 01:44 PM, David C. Rankin wrote:
On 08/17/2010 01:27 PM, David C. Rankin wrote:
I'll go see if I can rebuild with the ahci module loaded in the initramfs and see if that helps. But regardless, there is a bug somewhere. LTS boots fine in this config and 2.6.34.3 doesn't??
adding ahci to the MODULES line in mkinitcpio.conf and rebuilding the initramfs made no difference. The box still freezes on boot at the very beginning of the boot process with:
Booting 'Arch Linux on Archangel'
root (hd1,5) Filesystem Type ext2fs, partition type 0x83 kernel /vmlinuz26 root=/dev/mapper/nvidia_baaccajap5 ro debug [Linux-BzImage, setup=0x3200, size=0x1ff440]
showing on the screen. The box sits like that for 30-60 seconds and then automagically reboots. Booting back into LTS works fine. I guess we need to open a report on this one....
Added as: http://bugs.archlinux.org/task/20499
It's strange that the kernel locks up so soon. The bug report won't be useful until you test the newest kernel releases (2.6.34.4 or 2.6.35.2). For the report to be interesting to Arch developers, you should test against 2.6.35.2, because 2.6.34 has been superseded by it. If only a testing machine is affected, you could simply wait until 2.6.35 leaves testing/, update and see what happens. -- -- Rogutės Sparnuotos
On 08/17/2010 05:53 AM, Rogutės Sparnuotos wrote:
If you need X only for testing, use a simpler driver: xf86-video-vesa xf86-video-nv xf86-video-nouveau (probably won't work with an older kernel)
Thanks, The nv module works fine. The only issue is that X will not autoconfigure to use it, so you must create a minimal xorg.conf telling X to use the nv driver. Then it works like a champ. Thankfully, the only thing required was to: cp /etc/X11/xorg.conf /etc/X11/xorg.conf.nvida edit /etc/X11/xorg.conf and change Driver "nvidia" to Driver "nv" and remove any nvidia specific options like "option coolbits = 1". The restarting kdm did the trick. -- 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
participants (2)
-
David C. Rankin
-
Rogutės Sparnuotos