linux-kernel - Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1198967334.5049.3.camel@iamer-laptop>
Date:	Sun, 30 Dec 2007 00:28:54 +0200
From:	Islam Amer <pharon@...il.com>
To:	"David P. Reed" <dpreed@...d.com>
Cc:	Richard Harman <richard@...hardharman.com>,
	Eduard-Gabriel Munteanu <eduard.munteanu@...ux360.ro>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Rene Herman <rene.herman@...access.nl>
Subject: Re: [PATCH] Option to disable AMD C1E (allows dynticks to work)

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/