Just did an in-place update from 6.1 to 6.2 on my eeepc 901 (Atom CPU).
during boot, (if I hit ESC to see the boot messages) it says "starging udev" then nothing else for a few seconds, then a huge register dump scrolls by. it's too big to see the beginning of it.
If I boot from the prior kernel and look in /var/log/messages, I don't see any evidence of the failed boot.
I've seen the other thread titled "kernel panic", and it seems to be due to a missing initramfs, but there is an initramfs for 2.6.32-220.el6 already in /boot, so I don't think that would be the problem.
Can anyone suggest how I would isolate what's going on here?
On 12/21/2011 7:44 PM, fred smith wrote:
Just did an in-place update from 6.1 to 6.2 on my eeepc 901 (Atom CPU).
during boot, (if I hit ESC to see the boot messages) it says "starging udev" then nothing else for a few seconds, then a huge register dump scrolls by. it's too big to see the beginning of it.
If I boot from the prior kernel and look in /var/log/messages, I don't see any evidence of the failed boot.
I've seen the other thread titled "kernel panic", and it seems to be due to a missing initramfs, but there is an initramfs for 2.6.32-220.el6 already in /boot, so I don't think that would be the problem.
Can anyone suggest how I would isolate what's going on here?
Take a peek at what is inside the initramfs file:
~ $ mkdir initramfs ~ $ cd initramfs/ ~/initramfs $ gzip -d < /boot/initramfs-2.6.32-220.el6.x86_64.img | cpio -id 73012 blocks ~/initramfs $ ls bin cmdline dev dracut-004-256.el6 emergency etc init initqueue initqueue-finished initqueue-settled initqueue-timeout lib lib64 mount pre-pivot pre-trigger pre-udev proc sbin sys sysroot tmp usr var ~/initramfs $ find lib/modules -name '*.ko' <snip>
If a module that is required to mount your system (ext3/4, dm_dm-raid, etc - very system dependent) isn't in there, then the system won't be able to boot. Sometimes they don't get added automatically, for whatever reason. If you're able to identify the missing driver, edit this file:
/etc/dracut.conf
And add a line like this:
add_drivers+="name-of-driver"
Then re-run dracut. If you don't know how to do that, then you probably should just rpm -e that kernel package, then re-install it.
Hope this helps.
On Wed, Dec 21, 2011 at 07:56:51PM -0700, Corey Henderson wrote:
On 12/21/2011 7:44 PM, fred smith wrote:
Just did an in-place update from 6.1 to 6.2 on my eeepc 901 (Atom CPU).
during boot, (if I hit ESC to see the boot messages) it says "starging udev" then nothing else for a few seconds, then a huge register dump scrolls by. it's too big to see the beginning of it.
If I boot from the prior kernel and look in /var/log/messages, I don't see any evidence of the failed boot.
I've seen the other thread titled "kernel panic", and it seems to be due to a missing initramfs, but there is an initramfs for 2.6.32-220.el6 already in /boot, so I don't think that would be the problem.
Can anyone suggest how I would isolate what's going on here?
Take a peek at what is inside the initramfs file:
~ $ mkdir initramfs ~ $ cd initramfs/ ~/initramfs $ gzip -d < /boot/initramfs-2.6.32-220.el6.x86_64.img | cpio -id 73012 blocks ~/initramfs $ ls bin cmdline dev dracut-004-256.el6 emergency etc init initqueue initqueue-finished initqueue-settled initqueue-timeout lib lib64 mount pre-pivot pre-trigger pre-udev proc sbin sys sysroot tmp usr var ~/initramfs $ find lib/modules -name '*.ko'
<snip>
If a module that is required to mount your system (ext3/4, dm_dm-raid, etc - very system dependent) isn't in there, then the system won't be able to boot. Sometimes they don't get added automatically, for whatever reason. If you're able to identify the missing driver, edit this file:
/etc/dracut.conf
And add a line like this:
add_drivers+="name-of-driver"
Then re-run dracut. If you don't know how to do that, then you probably should just rpm -e that kernel package, then re-install it.
Hope this helps.
Corey, would it be a ligitimate comparison to unpack both the initramfs for the new kernel and for the most recent prior one, then compare the list of kernel modules?
thanks for the suggestion!
On 12/21/2011 8:23 PM, fred smith wrote:
On Wed, Dec 21, 2011 at 07:56:51PM -0700, Corey Henderson wrote:
On 12/21/2011 7:44 PM, fred smith wrote:
Just did an in-place update from 6.1 to 6.2 on my eeepc 901 (Atom CPU).
during boot, (if I hit ESC to see the boot messages) it says "starging udev" then nothing else for a few seconds, then a huge register dump scrolls by. it's too big to see the beginning of it.
If I boot from the prior kernel and look in /var/log/messages, I don't see any evidence of the failed boot.
I've seen the other thread titled "kernel panic", and it seems to be due to a missing initramfs, but there is an initramfs for 2.6.32-220.el6 already in /boot, so I don't think that would be the problem.
Can anyone suggest how I would isolate what's going on here?
Take a peek at what is inside the initramfs file:
~ $ mkdir initramfs ~ $ cd initramfs/ ~/initramfs $ gzip -d< /boot/initramfs-2.6.32-220.el6.x86_64.img | cpio -id 73012 blocks ~/initramfs $ ls bin cmdline dev dracut-004-256.el6 emergency etc init initqueue initqueue-finished initqueue-settled initqueue-timeout lib lib64 mount pre-pivot pre-trigger pre-udev proc sbin sys sysroot tmp usr var ~/initramfs $ find lib/modules -name '*.ko'
<snip>
If a module that is required to mount your system (ext3/4, dm_dm-raid, etc - very system dependent) isn't in there, then the system won't be able to boot. Sometimes they don't get added automatically, for whatever reason. If you're able to identify the missing driver, edit this file:
/etc/dracut.conf
And add a line like this:
add_drivers+="name-of-driver"
Then re-run dracut. If you don't know how to do that, then you probably should just rpm -e that kernel package, then re-install it.
Hope this helps.
Corey, would it be a ligitimate comparison to unpack both the initramfs for the new kernel and for the most recent prior one, then compare the list of kernel modules?
thanks for the suggestion!
Yes, that's a good thing to do.
If you come up empty (all the same kernel modules exist in both) then it's likely a bug in some kernel module. The "emergency_shell" part of dracut may be useful in debug this. When you reboot, during the grub menu, add this to the kernel's command line:
rdbreak=cmdline
During the boot process, you'll get dropped to a command line, and can run some of the basic commands provided intisde the initramfs.
If you look at the "init" file inside the initramfs, you can see the different points you'll end up with with different arguments to rdbreak; ie, pre-udev, initqueue, etc.
On Wed, Dec 21, 2011 at 08:30:23PM -0700, Corey Henderson wrote:
On 12/21/2011 8:23 PM, fred smith wrote:
On Wed, Dec 21, 2011 at 07:56:51PM -0700, Corey Henderson wrote:
On 12/21/2011 7:44 PM, fred smith wrote:
Just did an in-place update from 6.1 to 6.2 on my eeepc 901 (Atom CPU).
during boot, (if I hit ESC to see the boot messages) it says "starging udev" then nothing else for a few seconds, then a huge register dump scrolls by. it's too big to see the beginning of it.
If I boot from the prior kernel and look in /var/log/messages, I don't see any evidence of the failed boot.
I've seen the other thread titled "kernel panic", and it seems to be due to a missing initramfs, but there is an initramfs for 2.6.32-220.el6 already in /boot, so I don't think that would be the problem.
Can anyone suggest how I would isolate what's going on here?
Take a peek at what is inside the initramfs file:
~ $ mkdir initramfs ~ $ cd initramfs/ ~/initramfs $ gzip -d< /boot/initramfs-2.6.32-220.el6.x86_64.img | cpio -id 73012 blocks ~/initramfs $ ls bin cmdline dev dracut-004-256.el6 emergency etc init initqueue initqueue-finished initqueue-settled initqueue-timeout lib lib64 mount pre-pivot pre-trigger pre-udev proc sbin sys sysroot tmp usr var ~/initramfs $ find lib/modules -name '*.ko'
<snip>
If a module that is required to mount your system (ext3/4, dm_dm-raid, etc - very system dependent) isn't in there, then the system won't be able to boot. Sometimes they don't get added automatically, for whatever reason. If you're able to identify the missing driver, edit this file:
/etc/dracut.conf
And add a line like this:
add_drivers+="name-of-driver"
Then re-run dracut. If you don't know how to do that, then you probably should just rpm -e that kernel package, then re-install it.
Hope this helps.
Corey, would it be a ligitimate comparison to unpack both the initramfs for the new kernel and for the most recent prior one, then compare the list of kernel modules?
thanks for the suggestion!
Yes, that's a good thing to do.
well, I got the list of .ko for both the new (bad) initramfs and the old (bood) one, stripped off the start of each line so that it beings with "kernel" (so the different path won't confuse diff) and ran:
diff good bad | less
and here's what I got:
131a132
kernel/drivers/scsi/iscsi_boot_sysfs.ko
140a142
kernel/drivers/md/dm-raid.ko
146a149
kernel/drivers/md/dm-raid45.ko
158a162
kernel/drivers/md/dm-flakey.ko
163a168
kernel/drivers/md/dm-memcache.ko
177a183,184
kernel/drivers/platform/x86/mxm-wmi.ko kernel/drivers/platform/x86/wmi.ko
249a257,258
kernel/drivers/target/loopback/tcm_loop.ko kernel/drivers/target/target_core_mod.ko
272d280 < kernel/drivers/hwmon/hwmon.ko
which seems to show that the "bad" one contains some that aren't in the "good"one. the only exception is hwmon.ko doesn't exist in "good", but I can't see how that would be important, can you?
If you come up empty (all the same kernel modules exist in both) then it's likely a bug in some kernel module. The "emergency_shell" part of dracut may be useful in debug this. When you reboot, during the grub menu, add this to the kernel's command line:
rdbreak=cmdline
I guess I'll try this, though I'm not sure I know how to poke around productively. what have I to lose? :)
During the boot process, you'll get dropped to a command line, and can run some of the basic commands provided intisde the initramfs.
If you look at the "init" file inside the initramfs, you can see the different points you'll end up with with different arguments to rdbreak; ie, pre-udev, initqueue, etc.
-- Corey Henderson http://cormander.com/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, Dec 21, 2011 at 08:30:23PM -0700, Corey Henderson wrote:
On 12/21/2011 8:23 PM, fred smith wrote:
<snip>
If you come up empty (all the same kernel modules exist in both) then it's likely a bug in some kernel module. The "emergency_shell" part of dracut may be useful in debug this. When you reboot, during the grub menu, add this to the kernel's command line:
rdbreak=cmdline
During the boot process, you'll get dropped to a command line, and can run some of the basic commands provided intisde the initramfs.
If you look at the "init" file inside the initramfs, you can see the different points you'll end up with with different arguments to rdbreak; ie, pre-udev, initqueue, etc.
Having gotten nowhere, so far, I tried the above. I haven't any clue what would be helpful to do when it hits a "breakpoint", but I just typed "exit" to drop back out of the shell, a couple of times. it eventually got to where it said "starting udev" then a few seconds later the dump appeard on the screen again. but there seemed to be more of it shown so I took a photo of it. If you feel like taking a look to see if you can figure it out, you can find it at:
http://users.rcn.com/fredricksmith/dump.jpg
I don't know what any of it means, except that it mentions modprobe, and it appears that the stack trace has something to do with sound, perhaps modprobe croaks when loading/munging drivers for sound.
If anyone of you can make more sense of it than I, I'd appreciate the help.
thanks!
On 12/22/2011 04:46 PM, fred smith wrote:
On Wed, Dec 21, 2011 at 08:30:23PM -0700, Corey Henderson wrote:
On 12/21/2011 8:23 PM, fred smith wrote:
<snip> > > If you come up empty (all the same kernel modules exist in both) then > it's likely a bug in some kernel module. The "emergency_shell" part of > dracut may be useful in debug this. When you reboot, during the grub > menu, add this to the kernel's command line: > > rdbreak=cmdline > > During the boot process, you'll get dropped to a command line, and can > run some of the basic commands provided intisde the initramfs. > > If you look at the "init" file inside the initramfs, you can see the > different points you'll end up with with different arguments to rdbreak; > ie, pre-udev, initqueue, etc.
Having gotten nowhere, so far, I tried the above. I haven't any clue what would be helpful to do when it hits a "breakpoint", but I just typed "exit" to drop back out of the shell, a couple of times. it eventually got to where it said "starting udev" then a few seconds later the dump appeard on the screen again. but there seemed to be more of it shown so I took a photo of it. If you feel like taking a look to see if you can figure it out, you can find it at:
http://users.rcn.com/fredricksmith/dump.jpg
I don't know what any of it means, except that it mentions modprobe, and it appears that the stack trace has something to do with sound, perhaps modprobe croaks when loading/munging drivers for sound.
If anyone of you can make more sense of it than I, I'd appreciate the help.
There is a new kernel building right now that might fix something ... though I do not see anything specifically about your cpu.
Here is the errata link:
http://rhn.redhat.com/errata/RHSA-2011-1849.html
If everything builds it should be released in a couple of hours.
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
On 12/22/2011 04:46 PM, fred smith wrote:
On Wed, Dec 21, 2011 at 08:30:23PM -0700, Corey Henderson wrote:
On 12/21/2011 8:23 PM, fred smith wrote:
<snip> > > If you come up empty (all the same kernel modules exist in both) then > it's likely a bug in some kernel module. The "emergency_shell" part of > dracut may be useful in debug this. When you reboot, during the grub > menu, add this to the kernel's command line: > > rdbreak=cmdline > > During the boot process, you'll get dropped to a command line, and can > run some of the basic commands provided intisde the initramfs. > > If you look at the "init" file inside the initramfs, you can see the > different points you'll end up with with different arguments to rdbreak; > ie, pre-udev, initqueue, etc.
Having gotten nowhere, so far, I tried the above. I haven't any clue what would be helpful to do when it hits a "breakpoint", but I just typed "exit" to drop back out of the shell, a couple of times. it eventually got to where it said "starting udev" then a few seconds later the dump appeard on the screen again. but there seemed to be more of it shown so I took a photo of it. If you feel like taking a look to see if you can figure it out, you can find it at:
http://users.rcn.com/fredricksmith/dump.jpg
I don't know what any of it means, except that it mentions modprobe, and it appears that the stack trace has something to do with sound, perhaps modprobe croaks when loading/munging drivers for sound.
If anyone of you can make more sense of it than I, I'd appreciate the help.
There is a new kernel building right now that might fix something ... though I do not see anything specifically about your cpu.
Here is the errata link:
http://rhn.redhat.com/errata/RHSA-2011-1849.html
If everything builds it should be released in a couple of hours.
so it'll show up in a release channel (or CR repo) ?
On 12/22/2011 05:44 PM, fred smith wrote:
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
On 12/22/2011 04:46 PM, fred smith wrote:
On Wed, Dec 21, 2011 at 08:30:23PM -0700, Corey Henderson wrote:
On 12/21/2011 8:23 PM, fred smith wrote:
<snip> > > If you come up empty (all the same kernel modules exist in both) then > it's likely a bug in some kernel module. The "emergency_shell" part of > dracut may be useful in debug this. When you reboot, during the grub > menu, add this to the kernel's command line: > > rdbreak=cmdline > > During the boot process, you'll get dropped to a command line, and can > run some of the basic commands provided intisde the initramfs. > > If you look at the "init" file inside the initramfs, you can see the > different points you'll end up with with different arguments to rdbreak; > ie, pre-udev, initqueue, etc.
Having gotten nowhere, so far, I tried the above. I haven't any clue what would be helpful to do when it hits a "breakpoint", but I just typed "exit" to drop back out of the shell, a couple of times. it eventually got to where it said "starting udev" then a few seconds later the dump appeard on the screen again. but there seemed to be more of it shown so I took a photo of it. If you feel like taking a look to see if you can figure it out, you can find it at:
http://users.rcn.com/fredricksmith/dump.jpg
I don't know what any of it means, except that it mentions modprobe, and it appears that the stack trace has something to do with sound, perhaps modprobe croaks when loading/munging drivers for sound.
If anyone of you can make more sense of it than I, I'd appreciate the help.
There is a new kernel building right now that might fix something ... though I do not see anything specifically about your cpu.
Here is the errata link:
http://rhn.redhat.com/errata/RHSA-2011-1849.html
If everything builds it should be released in a couple of hours.
so it'll show up in a release channel (or CR repo) ?
It will be in 6.2/updates/
Still building right now.
Am 23.12.2011 00:53, schrieb Johnny Hughes:
There is a new kernel building right now that might fix something ... though I do not see anything specifically about your cpu.
Here is the errata link:
http://rhn.redhat.com/errata/RHSA-2011-1849.html
If everything builds it should be released in a couple of hours.
so it'll show up in a release channel (or CR repo) ?
It will be in 6.2/updates/
Still building right now.
Are you sure this will help? It looks to me he's already using RHEL6.2 with latest kernel 220.
Rainer
Am 23.12.2011 07:41, schrieb Rainer Traut:
It will be in 6.2/updates/
Still building right now.
Are you sure this will help? It looks to me he's already using RHEL6.2 with latest kernel 220.
Sorry forget my post, he's running 2.6.32-220.el6.x86_64 and the new one is 2.6.32-220.2.1.el6
Rainer
On Thu, Dec 22, 2011 at 05:53:13PM -0600, Johnny Hughes wrote:
On 12/22/2011 05:44 PM, fred smith wrote:
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
<snip>
There is a new kernel building right now that might fix something ... though I do not see anything specifically about your cpu.
Here is the errata link:
http://rhn.redhat.com/errata/RHSA-2011-1849.html
If everything builds it should be released in a couple of hours.
so it'll show up in a release channel (or CR repo) ?
It will be in 6.2/updates/
Still building right now.
Johnny, I got that kernel, and it dies what appears to be the same death as the prior one. the register dump is different than the one I showed, but even before that the dump didn't always look the same. this one also mentions something about alsa or snd. I can put it up on the same web site as the last one if anyone would find it useful to see (I certainly don't know how to interpret it).
also, this is a netbook, so it has no serial port. If it did I'd look into a serial console on the theory that I could capture the entire dump. Can anyone suggest how I would do that without a serial console? ... or if not exactly that, other things that would be useful to do to help clarify/diagnose this?
thanks all!
Fred
On Fri, Dec 23, 2011 at 01:02:12PM -0500, fred smith wrote:
On Thu, Dec 22, 2011 at 05:53:13PM -0600, Johnny Hughes wrote:
On 12/22/2011 05:44 PM, fred smith wrote:
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
<snip> > >> > >> There is a new kernel building right now that might > >> fix something ... though I do not see anything specifically about your cpu. > >> > >> Here is the errata link: > >> > >> http://rhn.redhat.com/errata/RHSA-2011-1849.html > >> > >> If everything builds it should be released in a couple of hours. > >> > > > > so it'll show up in a release channel (or CR repo) ? > > > > > It will be in 6.2/updates/ > > Still building right now. >
Johnny, I got that kernel, and it dies what appears to be the same death as the prior one. the register dump is different than the one I showed, but even before that the dump didn't always look the same. this one also mentions something about alsa or snd. I can put it up on the same web site as the last one if anyone would find it useful to see (I certainly don't know how to interpret it).
also, this is a netbook, so it has no serial port. If it did I'd look into a serial console on the theory that I could capture the entire dump. Can anyone suggest how I would do that without a serial console? ... or if not exactly that, other things that would be useful to do to help clarify/diagnose this?
thanks all!
Fred
here's th e register dump for this failure. it looks like it may be more useful than the last one:
http://users.rcn.com/fredricksmith/100_2020.JPG
On Dec 23, 2011, at 2:47 PM, fred smith fredex@fcshome.stoneham.ma.us wrote:
On Fri, Dec 23, 2011 at 01:02:12PM -0500, fred smith wrote:
On Thu, Dec 22, 2011 at 05:53:13PM -0600, Johnny Hughes wrote:
On 12/22/2011 05:44 PM, fred smith wrote:
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
<snip> >>> >>> There is a new kernel building right now that might >>> fix something ... though I do not see anything specifically about your cpu. >>> >>> Here is the errata link: >>> >>> http://rhn.redhat.com/errata/RHSA-2011-1849.html >>> >>> If everything builds it should be released in a couple of hours. >>> >> >> so it'll show up in a release channel (or CR repo) ? >> >> > It will be in 6.2/updates/ > > Still building right now. >
Johnny, I got that kernel, and it dies what appears to be the same death as the prior one. the register dump is different than the one I showed, but even before that the dump didn't always look the same. this one also mentions something about alsa or snd. I can put it up on the same web site as the last one if anyone would find it useful to see (I certainly don't know how to interpret it).
also, this is a netbook, so it has no serial port. If it did I'd look into a serial console on the theory that I could capture the entire dump. Can anyone suggest how I would do that without a serial console? ... or if not exactly that, other things that would be useful to do to help clarify/diagnose this?
thanks all!
Fred
here's th e register dump for this failure. it looks like it may be more useful than the last one:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
-Ross
On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
On Dec 23, 2011, at 2:47 PM, fred smith fredex@fcshome.stoneham.ma.us wrote:
On Fri, Dec 23, 2011 at 01:02:12PM -0500, fred smith wrote:
On Thu, Dec 22, 2011 at 05:53:13PM -0600, Johnny Hughes wrote:
On 12/22/2011 05:44 PM, fred smith wrote:
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
<snip> >>> >>> There is a new kernel building right now that might >>> fix something ... though I do not see anything specifically about your cpu. >>> >>> Here is the errata link: >>> >>> http://rhn.redhat.com/errata/RHSA-2011-1849.html >>> >>> If everything builds it should be released in a couple of hours. >>> >> >> so it'll show up in a release channel (or CR repo) ? >> >> > It will be in 6.2/updates/ > > Still building right now. >
Johnny, I got that kernel, and it dies what appears to be the same death as the prior one. the register dump is different than the one I showed, but even before that the dump didn't always look the same. this one also mentions something about alsa or snd. I can put it up on the same web site as the last one if anyone would find it useful to see (I certainly don't know how to interpret it).
also, this is a netbook, so it has no serial port. If it did I'd look into a serial console on the theory that I could capture the entire dump. Can anyone suggest how I would do that without a serial console? ... or if not exactly that, other things that would be useful to do to help clarify/diagnose this?
thanks all!
Fred
here's th e register dump for this failure. it looks like it may be more useful than the last one:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
the Bios has only a very few options, and disabling sound isn't one of them. :( since it's a laptop (netbook) it's probably not possible to yank the sound hardware (which, btw, works fine on Centos 6.1).
I suppose I could try rebuilding the initial ram disk without the sound module(s), though I'm not sure I know exactly the right way to do that....
On 12/23/2011 5:00 PM, fred smith wrote:
On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
On Dec 23, 2011, at 2:47 PM, fred smithfredex@fcshome.stoneham.ma.us wrote:
On Fri, Dec 23, 2011 at 01:02:12PM -0500, fred smith wrote:
On Thu, Dec 22, 2011 at 05:53:13PM -0600, Johnny Hughes wrote:
On 12/22/2011 05:44 PM, fred smith wrote:
On Thu, Dec 22, 2011 at 04:56:42PM -0600, Johnny Hughes wrote:
<snip> >>> >>> There is a new kernel building right now that might >>> fix something ... though I do not see anything specifically about your cpu. >>> >>> Here is the errata link: >>> >>> http://rhn.redhat.com/errata/RHSA-2011-1849.html >>> >>> If everything builds it should be released in a couple of hours. >>> >> >> so it'll show up in a release channel (or CR repo) ? >> >> > It will be in 6.2/updates/ > > Still building right now. >
Johnny, I got that kernel, and it dies what appears to be the same death as the prior one. the register dump is different than the one I showed, but even before that the dump didn't always look the same. this one also mentions something about alsa or snd. I can put it up on the same web site as the last one if anyone would find it useful to see (I certainly don't know how to interpret it).
also, this is a netbook, so it has no serial port. If it did I'd look into a serial console on the theory that I could capture the entire dump. Can anyone suggest how I would do that without a serial console? ... or if not exactly that, other things that would be useful to do to help clarify/diagnose this?
thanks all!
Fred
here's th e register dump for this failure. it looks like it may be more useful than the last one:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
the Bios has only a very few options, and disabling sound isn't one of them. :( since it's a laptop (netbook) it's probably not possible to yank the sound hardware (which, btw, works fine on Centos 6.1).
I suppose I could try rebuilding the initial ram disk without the sound module(s), though I'm not sure I know exactly the right way to do that....
Add the modules to:
/etc/modprobe.d/blacklist.conf
And re-install the kernel. The dracut util that builds the initramfs includes this file at install time.
On Fri, Dec 23, 2011 at 05:33:07PM -0700, Corey Henderson wrote:
On 12/23/2011 5:00 PM, fred smith wrote:
On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
On Dec 23, 2011, at 2:47 PM, fred smithfredex@fcshome.stoneham.ma.us wrote:
On Fri, Dec 23, 2011 at 01:02:12PM -0500, fred smith wrote:
<snip>
here's th e register dump for this failure. it looks like it may be more useful than the last one:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
the Bios has only a very few options, and disabling sound isn't one of them. :( since it's a laptop (netbook) it's probably not possible to yank the sound hardware (which, btw, works fine on Centos 6.1).
I suppose I could try rebuilding the initial ram disk without the sound module(s), though I'm not sure I know exactly the right way to do that....
Add the modules to:
/etc/modprobe.d/blacklist.conf
And re-install the kernel. The dracut util that builds the initramfs includes this file at install time.
at last, I've had the opportunity to pursue this. all I have to do is blacklist the snd_hda_codec_realtek module, reboot and voila, it boots right up. Of course, there's no sound,... Seems odd that I don't need to rebuild the initramfs (dracut), but I don't seem to need to do that.
Is this enough info, along with the core dump photos, to make a worthwhile bugzilla report? if not, I'm open to ideas on how to further track it.
thanks to all!
Fred
Add the modules to:
/etc/modprobe.d/blacklist.conf
And re-install the kernel. The dracut util that builds the initramfs includes this file at install time.
at last, I've had the opportunity to pursue this. all I have to do is blacklist the snd_hda_codec_realtek module, reboot and voila, it boots right up. Of course, there's no sound,... Seems odd that I don't need to rebuild the initramfs (dracut), but I don't seem to need to do that.
Then the sound module doesn't get loaded until after the initramfs does the switchroot, which would mean the blacklist is read from your filesystem, and not from the copy that exists inside the initramfs itself. Either way, glad it worked out.
Is this enough info, along with the core dump photos, to make a worthwhile bugzilla report? if not, I'm open to ideas on how to further track it.
Should be, yes.
Vreme: 12/24/2011 01:00 AM, fred smith piše:
On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
the Bios has only a very few options, and disabling sound isn't one of them. :( since it's a laptop (netbook) it's probably not possible to yank the sound hardware (which, btw, works fine on Centos 6.1).
I suppose I could try rebuilding the initial ram disk without the sound module(s), though I'm not sure I know exactly the right way to do that....
Is that ATI sound card? I read somewhere something about adding 'radeon.audio=1' in kernel line (grub) to enable it. Maybe 'radeon.audio=0' would disable it?
On Sat, Dec 24, 2011 at 01:37:03AM +0100, Ljubomir Ljubojevic wrote:
Vreme: 12/24/2011 01:00 AM, fred smith piše:
On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
the Bios has only a very few options, and disabling sound isn't one of them. :( since it's a laptop (netbook) it's probably not possible to yank the sound hardware (which, btw, works fine on Centos 6.1).
I suppose I could try rebuilding the initial ram disk without the sound module(s), though I'm not sure I know exactly the right way to do that....
Is that ATI sound card? I read somewhere something about adding 'radeon.audio=1' in kernel line (grub) to enable it. Maybe 'radeon.audio=0' would disable it?
it appears to be some realtek audio chipset.
At 2011-12-23 Fri 20:09 -0500，fred smith wrote：
On Sat, Dec 24, 2011 at 01:37:03AM +0100, Ljubomir Ljubojevic wrote:
Vreme: 12/24/2011 01:00 AM, fred smith piše:
On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
Is that sound on-board? If it is disable it in BIOS, if it isn't, remove the card.
See if it breaks after that.
the Bios has only a very few options, and disabling sound isn't one of them. :( since it's a laptop (netbook) it's probably not possible to yank the sound hardware (which, btw, works fine on Centos 6.1).
I suppose I could try rebuilding the initial ram disk without the sound module(s), though I'm not sure I know exactly the right way to do that....
Is that ATI sound card? I read somewhere something about adding 'radeon.audio=1' in kernel line (grub) to enable it. Maybe 'radeon.audio=0' would disable it?
it appears to be some realtek audio chipset.
You can try the driver provided by realtek. After fix two compile problems in include/adriver.h, I can compile/install and use it (My NB have a ALC269 chipset).
-
An Yang -
Corey Henderson -
fred smith -
Johnny Hughes -
Ljubomir Ljubojevic -
Rainer Traut -
Ross Walker