lkml.org 
[lkml]   [2007]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Option to disable AMD C1E (allows dynticks to work)
    From
    Date
    Thanks for the detailed response.

    I thought I had gotten to the bottom of my problems when I found that
    udev workaround, I guess I was naive.

    I did the two tests you described and they predictably caused the hard
    hangs. I needed to run the port80 program only once to get the hard
    hang.

    The output of the dmidecode commands were :

    Quanta
    30B7

    I applied the patch you provided ( luckily I am using 2.6.24-rc6-git3
    kernel because I need the b43 driver ), added these values and compiled.


    {
    .callback = dmi_io_delay_port_alt,
    .ident = "Compaq Presario v6000",
    .matches = {
    DMI_MATCH(DMI_BOARD_VENDOR, "Quanta"),
    DMI_MATCH(DMI_BOARD_NAME, "30B7")
    }
    },

    I was able to boot without the udev workaround and can now use hwclock
    without hanging the system. In dmesg I can see this new line :



    On Sat, 2007-12-29 at 09:43 -0500, David P. Reed wrote:
    > Islam Amer wrote:
    > > Hello.
    > > I was interested in getting dynticks to work on my compaq presario v6000
    > > to help with the 1 hour thirty minutes battery time, but after this
    > > discussion I lost interest.
    > >
    > > I too had the early boot time hang, and found it was udev triggering the
    > > bug.
    > >
    > This early boot time hang is *almost certainly* due to the in/out port
    > 80 bug, which I discovered a few weeks ago, which affects hwclock and
    > other I/O device drivers on a number of HP/Compaq machines in exactly
    > this way. The proper fix for this bug is in dispute, and will probably
    > not occur in the 2.6.24 release because it touches code in many, many
    > drivers. The simplest way to test if you have a problem of this sort is
    > to try this shell line as root, after you boot successfully. If your
    > machine hangs hard, you have a problem that really looks like the port
    > 80 problem.
    >
    > for ((i = 0; i < 1000; i = i + 1)); do cat /dev/nvram > /dev/null; done
    >
    > I have also attached a c program that only touches port 80. Compile it
    > for 32-bit mode (see comment), run it as root, and after two or three
    > runs, it will hang a system that has the port 80 bug.
    >
    > If you then run:
    >
    > dmidecode -s baseboard-manufacturer
    > dmidecode -s baseboard-product-name
    >
    > are the values you should plug into the .matches field in the
    > dmi_system_id struct in the attached patch. It would be great if you
    > could do that, test, and post back with those values so they can be
    > accumulated. HP/Compaq machines with quanta m/b's are very popular, and
    > very common - so at least a quirk patch for all the broken models would
    > be worth doing in 2.6.25 or downstream in the distros. The right
    > patches will probably take a long time - there is a dispute as to what
    > the semantics of port 80 writes even mean among the core kernel
    > developers, because the hack is lost in the dim dark days of history,
    > and safe resolution will take time
    >
    > There is also a C1E issue with the BIOS in my machine (an HP Pavilion
    > dv9000z). I don't know if it is a bug, yet, but that's a different
    > problem - associated with dynticks, perhaps. I have to say that
    > researching the AMD Kernel/BIOS docs on C1E (a very new feature in the
    > last year on AMD) leaves me puzzled as to whether the dynticks problem
    > exists on my machine at all, but the patch for it turns off dynticks!
    >
    >
    >
    > > Changing the /etc/init.d/udev script so that the line containing
    > >
    > > /sbin/udevtrigger
    > >
    > > to
    > >
    > > /sbin/udevtrigger --subsystem-nomatch="*misc*"
    > >
    > > seemed to fix things.
    > >
    > > the hang is triggered specifically by
    > >
    > > echo add > /sys/class/misc/rtc/uevent
    > > after inserting rtc.ko
    > >
    > > Also using hwclock to set the rtc , will cause a hard hang, if you are
    > > using 64bit linux. Disable the init scripts that set the time, or use
    > > the 32bit binary, as suggested here :
    > >
    > > http://www.mail-archive.com/opensuse@opensuse.org/msg41964.html
    > >
    > > I hope this helps. But your hardware is slightly different though.
    > >
    >



    \
     
     \ /
      Last update: 2007-12-30 01:31    [W:0.061 / U:59.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site