FAQ
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?

--
---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
The Lord detests the way of the wicked
but he loves those who pursue righteousness.
----------------------------- Proverbs 15:9 (niv) -----------------------------

Search Discussions

  • Corey Henderson at Dec 21, 2011 at 9:56 pm

    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 Henderson
    http://cormander.com/
  • Fred smith at Dec 21, 2011 at 10:23 pm

    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!

    --
    ---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
    "Not everyone who says to me, 'Lord, Lord,' will enter the kingdom of
    heaven, but only he who does the will of my Father who is in heaven."
    ------------------------------ Matthew 7:21 (niv) -----------------------------
  • Corey Henderson at Dec 21, 2011 at 10:30 pm

    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.

    --
    Corey Henderson
    http://cormander.com/
  • Fred smith at Dec 21, 2011 at 11:14 pm

    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos
    --
    ---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
    But God demonstrates his own love for us in this:
    While we were still sinners,
    Christ died for us.
    ------------------------------- Romans 5:8 (niv) ------------------------------
  • Fred smith at Dec 22, 2011 at 5:46 pm

    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!

    --
    ---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
    The Lord is like a strong tower.
    Those who do what is right can run to him for safety.
    --------------------------- Proverbs 18:10 (niv) -----------------------------
  • Johnny Hughes at Dec 22, 2011 at 5:56 pm

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111222/e7821444/attachment.bin
  • Fred smith at Dec 22, 2011 at 6:44 pm

    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) ?


    --
    ---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
    "For the word of God is living and active. Sharper than any double-edged
    sword, it penetrates even to dividing soul and spirit, joints and marrow;
    it judges the thoughts and attitudes of the heart."
    ---------------------------- Hebrews 4:12 (niv) ------------------------------
  • Johnny Hughes at Dec 22, 2011 at 6:53 pm

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20111222/9b2fbde0/attachment.bin
  • Rainer Traut at Dec 23, 2011 at 1:41 am

    Am 23.12.2011 00:53, schrieb Johnny Hughes:

    http://users.rcn.com/fredricksmith/dump.jpg
    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
  • Rainer Traut at Dec 23, 2011 at 3:28 am

    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
  • Fred smith at Dec 23, 2011 at 1:02 pm

    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


    --
    ---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
    "For the word of God is living and active. Sharper than any double-edged
    sword, it penetrates even to dividing soul and spirit, joints and marrow;
    it judges the thoughts and attitudes of the heart."
    ---------------------------- Hebrews 4:12 (niv) ------------------------------
  • Fred smith at Dec 23, 2011 at 2:47 pm

    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


    --
    -------------------------------------------------------------------------------
    Under no circumstances will I ever purchase anything offered to me as
    the result of an unsolicited e-mail message. Nor will I forward chain
    letters, petitions, mass mailings, or virus warnings to large numbers
    of others. This is my contribution to the survival of the online
    community.
    --Roger Ebert, December, 1996
    ----------------------------- The Boulder Pledge -----------------------------
  • Ross Walker at Dec 23, 2011 at 5:44 pm

    On Dec 23, 2011, at 2:47 PM, fred smith 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:

    http://users.rcn.com/fredricksmith/100_2020.JPG
    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
  • Fred smith at Dec 23, 2011 at 7:00 pm

    On Fri, Dec 23, 2011 at 05:44:11PM -0500, Ross Walker wrote:
    On Dec 23, 2011, at 2:47 PM, fred smith 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:

    http://users.rcn.com/fredricksmith/100_2020.JPG
    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....

    --
    ---- Fred Smith -- fredex at fcshome.stoneham.ma.us -----------------------------
    The Lord detests the way of the wicked
    but he loves those who pursue righteousness.
    ----------------------------- Proverbs 15:9 (niv) -----------------------------
  • Corey Henderson at Dec 23, 2011 at 7:33 pm

    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 smithwrote:
    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
    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.

    --
    Corey Henderson
    http://cormander.com/
  • Fred smith at Dec 24, 2011 at 10:45 pm

    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 smithwrote:
    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:

    http://users.rcn.com/fredricksmith/100_2020.JPG
    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
    --
    -------------------------------------------------------------------------------
    Under no circumstances will I ever purchase anything offered to me as
    the result of an unsolicited e-mail message. Nor will I forward chain
    letters, petitions, mass mailings, or virus warnings to large numbers
    of others. This is my contribution to the survival of the online
    community.
    --Roger Ebert, December, 1996
    ----------------------------- The Boulder Pledge -----------------------------
  • Corey Henderson at Dec 25, 2011 at 1:28 am

    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.

    --
    Corey Henderson
    http://cormander.com/
  • Ljubomir Ljubojevic at Dec 23, 2011 at 7:37 pm

    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?


    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Fred smith at Dec 23, 2011 at 8:09 pm

    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.

    --
    -------------------------------------------------------------------------------
    .---- Fred Smith /
    ( /__ ,__. __ __ / __ : /
    / / / /__) / / /__) .+' Home: fredex at fcshome.stoneham.ma.us
    / / (__ (___ (__(_ (___ / :__ 781-438-5471
    -------------------------------- Jude 1:24,25 ---------------------------------
  • An Yang at Dec 26, 2011 at 2:50 am
    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).
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 490 bytes
    Desc: =?gb2312?Q?�����ż�������ǩ? =?gb2312?Q?������?Url : http://lists.centos.org/pipermail/centos/attachments/20111226/4feffbfa/attachment.bin

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedDec 21, '11 at 9:44p
activeDec 26, '11 at 2:50a
posts21
users7
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase