Re: [PATCH 1/2] I8K: Allow i8k driver to be built on x86_64 systems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik wrote:
> Bradley Smith wrote:
>> From: Bradley Smith <[EMAIL PROTECTED]>
>>
>> Adds #if clause and additional inline assembly so that the driver
>> builds on x86_64 systems.
>>
>> Signed-off-by: Bradley Smith <[EMAIL PROTECTED]>
>
> Is this actually known to be working on a Dell laptop?
>
> Jeff
Yes, the patch works well on my Dell, and I've got several
follow-up patches to Brad's. During the last i8k refresh
(http://lkml.org/lkml/2005/2/24/11), not everything made it
into mainline, so i8k is due for another facelift.
Needs the following in order to work correctly on my Inspiron E1705:
Add DMI Product name to i8k for Dell MP061 hardware (Inspiron 9400/E1705)
Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]>
- ---
drivers/char/i8k.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6.24-rc1/drivers/char/i8k.c
===
- --- linux-2.6.24-rc1.orig/drivers/char/i8k.c 2007-10-29 00:27:21.0
-0500
+++ linux-2.6.24-rc1/drivers/char/i8k.c 2007-10-29 00:30:05.0 -0500
@@ -468,6 +468,13 @@
DMI_MATCH(DMI_PRODUCT_NAME, "Latitude"),
},
},
+ {
+ .ident = "Dell Inspiron 3",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MP061"),
+ },
+ },
{ }
};
Frank
- --
Frank Sorenson - KD7TZK
Linux Systems Engineer, DSS Engineering, UBS AG
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHJXnUaI0dwg4A47wRApQrAKDKb0Zq+QrG+CUsXrpfoxVxLyM+PQCg5uZc
kvUjuY3a1F7MIx0Z9DSrYbg=
=IcmN
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] I8K: Allow i8k driver to be built on x86_64 systems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Garzik wrote:
Bradley Smith wrote:
From: Bradley Smith [EMAIL PROTECTED]
Adds #if clause and additional inline assembly so that the driver
builds on x86_64 systems.
Signed-off-by: Bradley Smith [EMAIL PROTECTED]
Is this actually known to be working on a Dell laptop?
Jeff
Yes, the patch works well on my Dell, and I've got several
follow-up patches to Brad's. During the last i8k refresh
(http://lkml.org/lkml/2005/2/24/11), not everything made it
into mainline, so i8k is due for another facelift.
Needs the following in order to work correctly on my Inspiron E1705:
Add DMI Product name to i8k for Dell MP061 hardware (Inspiron 9400/E1705)
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
- ---
drivers/char/i8k.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-2.6.24-rc1/drivers/char/i8k.c
===
- --- linux-2.6.24-rc1.orig/drivers/char/i8k.c 2007-10-29 00:27:21.0
-0500
+++ linux-2.6.24-rc1/drivers/char/i8k.c 2007-10-29 00:30:05.0 -0500
@@ -468,6 +468,13 @@
DMI_MATCH(DMI_PRODUCT_NAME, Latitude),
},
},
+ {
+ .ident = Dell Inspiron 3,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MP061),
+ },
+ },
{ }
};
Frank
- --
Frank Sorenson - KD7TZK
Linux Systems Engineer, DSS Engineering, UBS AG
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHJXnUaI0dwg4A47wRApQrAKDKb0Zq+QrG+CUsXrpfoxVxLyM+PQCg5uZc
kvUjuY3a1F7MIx0Z9DSrYbg=
=IcmN
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Combined mode quirk removal kills performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The patch to "remove combined mode quirk" (git bisect says 8cdfb29c0cd8018f92214c11c631d8926f4cb032) makes my laptop run slower than a dead sloth. "hdparm -T" indicates that buffered disk reads on my hard drive drop from 48-50 MB/sec to 1-2MB/sec, and the system is nearly unusable. System is a Dell Inspiron E1705 (Core 2 Duo 2.16GHz) running x86_64 FC6. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGXt+JaI0dwg4A47wRAqJmAJ4k4E9ekkitOdQ72HUXbky11nD1cACghGu6 y7Y71PPaKHYcQhYSfL55bNk= =MPYY -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Combined mode quirk removal kills performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The patch to remove combined mode quirk (git bisect says 8cdfb29c0cd8018f92214c11c631d8926f4cb032) makes my laptop run slower than a dead sloth. hdparm -T indicates that buffered disk reads on my hard drive drop from 48-50 MB/sec to 1-2MB/sec, and the system is nearly unusable. System is a Dell Inspiron E1705 (Core 2 Duo 2.16GHz) running x86_64 FC6. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGXt+JaI0dwg4A47wRAqJmAJ4k4E9ekkitOdQ72HUXbky11nD1cACghGu6 y7Y71PPaKHYcQhYSfL55bNk= =MPYY -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: > On Sun, 2007-05-20 at 14:25 +0200, Maarten Maathuis wrote: >> When i try to boot a kernel higher than 2.6.21-rt1, it boots very >> slowly. It takes minutes to even detect two cdrom players. I noticed >> in the changelog: >> >> - x86/64 high-res timers and dynticks update (Thomas Gleixner) >> >> I included the .config from 2.6.21-rt1, which i ran make oldconfig on. >> >> I cannot provide any other information, since i estimate it will take >> ages to bootup. > > Does the same problem show up with > > http://tglx.de/projects/hrtimers/2.6.22-rc2/linux-2.6.22-rc2-x86_64-highres-v1.patch > > tglx I see the slow bootup as well, even with 2.6.22-rc2-hrt1. It takes at least 5 times as long to boot, for X to start, to login, etc. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGUSd4aI0dwg4A47wRAog8AJ9QkOlDEweqxeLxC3Bx7C5TQbMbjACfeM6k pDJzhXJYwoH39CzIYy3eAnw= =qNW6 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: On Sun, 2007-05-20 at 14:25 +0200, Maarten Maathuis wrote: When i try to boot a kernel higher than 2.6.21-rt1, it boots very slowly. It takes minutes to even detect two cdrom players. I noticed in the changelog: - x86/64 high-res timers and dynticks update (Thomas Gleixner) I included the .config from 2.6.21-rt1, which i ran make oldconfig on. I cannot provide any other information, since i estimate it will take ages to bootup. Does the same problem show up with http://tglx.de/projects/hrtimers/2.6.22-rc2/linux-2.6.22-rc2-x86_64-highres-v1.patch tglx I see the slow bootup as well, even with 2.6.22-rc2-hrt1. It takes at least 5 times as long to boot, for X to start, to login, etc. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGUSd4aI0dwg4A47wRAog8AJ9QkOlDEweqxeLxC3Bx7C5TQbMbjACfeM6k pDJzhXJYwoH39CzIYy3eAnw= =qNW6 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Lameter wrote: > On Thu, 17 May 2007, Frank Sorenson wrote: >> Frank Sorenson wrote: >> >>> Hrm. Looks like it gets past the hpet_is_known There's still something >>> in the hpet detection code, but I didn't get to the bottom of it yet. >>> I'll do some more debugging to track down where it's really hanging. >>> Sorry for the noise. >> I've tracked down this hang to a kzalloc in the hpet code that never >> returns. But only when using SLUB. Using SLAB, the highres/dyntick >> patch boots without problem. >> >> ...adding Christoph to the CC list... > > Please boot with slub_debug. No debugging output at all. Still hangs with only: Kernel alive Kernel direct mapping tables up to 1 @ 8000-d000 Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTSPMaI0dwg4A47wRAkiaAJ0X80qq/ASp6zDEDAibOebZ1awBLACgh0OM mHK5zxK+rwSNoiDlVRv6p8g= =vegA -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: > Hrm. Looks like it gets past the hpet_is_known There's still something > in the hpet detection code, but I didn't get to the bottom of it yet. > I'll do some more debugging to track down where it's really hanging. > Sorry for the noise. I've tracked down this hang to a kzalloc in the hpet code that never returns. But only when using SLUB. Using SLAB, the highres/dyntick patch boots without problem. ...adding Christoph to the CC list... Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTKkLaI0dwg4A47wRArYeAJwLs4fJDfj8CuYmUpCaifou6DBsHgCg9nvP ilEqTd1DdOD13LSl7xVeKls= =RT2W -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: Hrm. Looks like it gets past the hpet_is_known There's still something in the hpet detection code, but I didn't get to the bottom of it yet. I'll do some more debugging to track down where it's really hanging. Sorry for the noise. I've tracked down this hang to a kzalloc in the hpet code that never returns. But only when using SLUB. Using SLAB, the highres/dyntick patch boots without problem. ...adding Christoph to the CC list... Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTKkLaI0dwg4A47wRArYeAJwLs4fJDfj8CuYmUpCaifou6DBsHgCg9nvP ilEqTd1DdOD13LSl7xVeKls= =RT2W -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Lameter wrote: On Thu, 17 May 2007, Frank Sorenson wrote: Frank Sorenson wrote: Hrm. Looks like it gets past the hpet_is_known There's still something in the hpet detection code, but I didn't get to the bottom of it yet. I'll do some more debugging to track down where it's really hanging. Sorry for the noise. I've tracked down this hang to a kzalloc in the hpet code that never returns. But only when using SLUB. Using SLAB, the highres/dyntick patch boots without problem. ...adding Christoph to the CC list... Please boot with slub_debug. No debugging output at all. Still hangs with only: Kernel alive Kernel direct mapping tables up to 1 @ 8000-d000 Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGTSPMaI0dwg4A47wRAkiaAJ0X80qq/ASp6zDEDAibOebZ1awBLACgh0OM mHK5zxK+rwSNoiDlVRv6p8g= =vegA -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: > After adding *lots* of early_printks, I see that it hangs in > hpet_is_known(hdp) called from hpet_alloc(), so something in the hpet > code is still buggy. Adding nohpet to the kernel command line allows it > to boot correctly. Hrm. Looks like it gets past the hpet_is_known There's still something in the hpet detection code, but I didn't get to the bottom of it yet. I'll do some more debugging to track down where it's really hanging. Sorry for the noise. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGS9lFaI0dwg4A47wRApdSAJoDsFphRHZq/tu3d4nJaqMvt+tLGQCghf1L OCuPEpCRr9tBSnBdVNiShRE= =NDZn -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: > I'm pleased to announce an updated version of the x86_64 highres/dyntick > support patches against 2.6.22-rc1: > > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v5.patch > > Broken out version is available here: > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v5.patches.tar.bz2 > > Changes since the last version: > > - Enforced enabling of HPET (Venki Pallipadi) > Detects and enables HPET on Intel ICHx chipsets, when the BIOS > hides it. > > Venki, great work, thanks ! > > - Another variant of PIT wreckage fixup > Frank, does this one work for you ? Unfortunately, no. After adding *lots* of early_printks, I see that it hangs in hpet_is_known(hdp) called from hpet_alloc(), so something in the hpet code is still buggy. Adding nohpet to the kernel command line allows it to boot correctly. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGS1/3aI0dwg4A47wRAuaIAKD1MG5x4cvWXGRCwkHEGBzhUHyJlQCfez+S ODHcJ4FEJ4W4LB7NzW32X6Q= =r1q5 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: I'm pleased to announce an updated version of the x86_64 highres/dyntick support patches against 2.6.22-rc1: http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v5.patch Broken out version is available here: http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v5.patches.tar.bz2 Changes since the last version: - Enforced enabling of HPET (Venki Pallipadi) Detects and enables HPET on Intel ICHx chipsets, when the BIOS hides it. Venki, great work, thanks ! - Another variant of PIT wreckage fixup Frank, does this one work for you ? Unfortunately, no. After adding *lots* of early_printks, I see that it hangs in hpet_is_known(hdp) called from hpet_alloc(hd), so something in the hpet code is still buggy. Adding nohpet to the kernel command line allows it to boot correctly. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGS1/3aI0dwg4A47wRAuaIAKD1MG5x4cvWXGRCwkHEGBzhUHyJlQCfez+S ODHcJ4FEJ4W4LB7NzW32X6Q= =r1q5 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: After adding *lots* of early_printks, I see that it hangs in hpet_is_known(hdp) called from hpet_alloc(hd), so something in the hpet code is still buggy. Adding nohpet to the kernel command line allows it to boot correctly. Hrm. Looks like it gets past the hpet_is_known There's still something in the hpet detection code, but I didn't get to the bottom of it yet. I'll do some more debugging to track down where it's really hanging. Sorry for the noise. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGS9lFaI0dwg4A47wRApdSAJoDsFphRHZq/tu3d4nJaqMvt+tLGQCghf1L OCuPEpCRr9tBSnBdVNiShRE= =NDZn -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: > Thomas Gleixner wrote: >> Frank, > >> On Tue, 2007-05-15 at 09:06 -0500, Frank Sorenson wrote: >>> Hangs at boot here: >>> Kernel alive >>> Kernel direct mapping tables up to 1 @ 8000-d000 >>> (and that's it) >>> >>> This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz >>> >>> highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked >>> 2.6.22-rc1 boots without problem >> Can you please try the following three command line option addons ? > >> 1: highres=off nohz=off >> 2: highres=off >> 3: nohz=off > >> Thanks, > >> tglx > > All 3 hang at the same point. I have tracked down the offending patch in the series to x86-64-convert-to-clockevents.patch Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSpB2aI0dwg4A47wRAglRAJ4mJgbJClPd0hkXKp+YHq7G5VxQvgCgkVkv TtOjrSrjrwiHQPkNCqlq314= =lu8g -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: > Frank, > > On Tue, 2007-05-15 at 09:06 -0500, Frank Sorenson wrote: >> Hangs at boot here: >> Kernel alive >> Kernel direct mapping tables up to 1 @ 8000-d000 >> (and that's it) >> >> This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz >> >> highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked >> 2.6.22-rc1 boots without problem > > Can you please try the following three command line option addons ? > > 1: highres=off nohz=off > 2: highres=off > 3: nohz=off > > Thanks, > > tglx All 3 hang at the same point. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSkA6aI0dwg4A47wRAuQzAKDcmAMR2e2Ce/3ytR+39XxgG76XjwCfVtbj vWlY59M1gHz2Z8dIJWRYqTk= =algX -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: > I've uploaded a new version of the x86_64 highres/dyntick patches: > > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v4.patch Hangs at boot here: Kernel alive Kernel direct mapping tables up to 1 @ 8000-d000 (and that's it) This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked 2.6.22-rc1 boots without problem Is there any information I can provide to help track down the problem? Thanks, Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSb5JaI0dwg4A47wRAjkgAJ9Urvpo+cTAbRvblYovBYy3PD76jACfbtjj EZSrOZDFMnOYjc02nHSAxaM= =/ffY -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: I've uploaded a new version of the x86_64 highres/dyntick patches: http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-highres-v4.patch Hangs at boot here: Kernel alive Kernel direct mapping tables up to 1 @ 8000-d000 (and that's it) This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked 2.6.22-rc1 boots without problem Is there any information I can provide to help track down the problem? Thanks, Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSb5JaI0dwg4A47wRAjkgAJ9Urvpo+cTAbRvblYovBYy3PD76jACfbtjj EZSrOZDFMnOYjc02nHSAxaM= =/ffY -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Gleixner wrote: Frank, On Tue, 2007-05-15 at 09:06 -0500, Frank Sorenson wrote: Hangs at boot here: Kernel alive Kernel direct mapping tables up to 1 @ 8000-d000 (and that's it) This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked 2.6.22-rc1 boots without problem Can you please try the following three command line option addons ? 1: highres=off nohz=off 2: highres=off 3: nohz=off Thanks, tglx All 3 hang at the same point. Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSkA6aI0dwg4A47wRAuQzAKDcmAMR2e2Ce/3ytR+39XxgG76XjwCfVtbj vWlY59M1gHz2Z8dIJWRYqTk= =algX -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: Thomas Gleixner wrote: Frank, On Tue, 2007-05-15 at 09:06 -0500, Frank Sorenson wrote: Hangs at boot here: Kernel alive Kernel direct mapping tables up to 1 @ 8000-d000 (and that's it) This is a Dell Inspiron E1705 with a Core 2 Duo 2.16GHz highres-v3 also hung at the same point, but 2.6.21-git2-v2 worked 2.6.22-rc1 boots without problem Can you please try the following three command line option addons ? 1: highres=off nohz=off 2: highres=off 3: nohz=off Thanks, tglx All 3 hang at the same point. I have tracked down the offending patch in the series to x86-64-convert-to-clockevents.patch Frank - -- Frank Sorenson - KD7TZK Linux Systems Engineer, DSS Engineering, UBS AG [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGSpB2aI0dwg4A47wRAglRAJ4mJgbJClPd0hkXKp+YHq7G5VxQvgCgkVkv TtOjrSrjrwiHQPkNCqlq314= =lu8g -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel panic at boot with recent pci quirks patch
Remi Colinet wrote: Frank Sorenson <[EMAIL PROTECTED]> wrote: The latest -git tree panics at boot for me. git-bisect traced the offending commit to: 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Author: Alan Cox <[EMAIL PROTECTED]> Date: Wed Oct 4 00:41:26 2006 +0100 PCI: quirks: fix the festering mess that claims to handle IDE quirks Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64. Could you try the following patch (already included in mm tree)? http://www.uwsg.indiana.edu/hypermail/linux/kernel/0611.1/1568.html Remi Yes, that patch does seem to fix the problem. Is it the right fix? Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel panic at boot with recent pci quirks patch
The latest -git tree panics at boot for me. git-bisect traced the offending commit to: 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Author: Alan Cox <[EMAIL PROTECTED]> Date: Wed Oct 4 00:41:26 2006 +0100 PCI: quirks: fix the festering mess that claims to handle IDE quirks Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64. I've attached a netcconsole dump of the panic, as well as lspci output. Is there any additional information I can provide? Thanks, Frank [0.00] Linux version 2.6.19-bs1 ([EMAIL PROTECTED]) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #11 SMP PREEMPT Wed Dec 6 09:43:25 CST 2006 [0.00] Command line: ro root=/dev/VolGroup00/RootVol vga=794 apic=verbose nmi_watchdog=1 [EMAIL PROTECTED]/,@64.62.190.123/00:0F:66:99:97:4F loglevel=8 console=tty0 console=ttyUSB0,9600n8 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f000 (usable) [0.00] BIOS-e820: 0009f000 - 000a (reserved) [0.00] BIOS-e820: 0010 - 7fed3400 (usable) [0.00] BIOS-e820: 7fed3400 - 8000 (reserved) [0.00] BIOS-e820: e000 - f0007000 (reserved) [0.00] BIOS-e820: f0008000 - f000c000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed2 - feda (reserved) [0.00] BIOS-e820: fee0 - fee1 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 523987) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP (v000 DELL ) @ 0x000fc1b0 [0.00] ACPI: RSDT (v001 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed39cd [0.00] ACPI: FADT (v001 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed4800 [0.00] ACPI: MADT (v001 DELLM07 0x27d6071d ASL 0x0047) @ 0x7fed5000 [0.00] ACPI: MCFG (v016 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed4fc0 [0.00] ACPI: BOOT (v001 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed4bc0 [0.00] ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20050624) @ 0x7fed3a05 [0.00] ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 INTL 0x20050624) @ 0x [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 523987) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 523987 [0.00] On node 0 totalpages: 523890 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 8 pages reserved [0.00] DMA zone: 3935 pages, LIFO batch:0 [0.00] DMA32 zone: 7107 pages used for memmap [0.00] DMA32 zone: 512784 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to physical flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] mapped APIC to ff5fd000 (fee0) [0.00] mapped IOAPIC to ff5fc000 (fec0) [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 0010 [0.00] Allocating PCI resources starting at 8800 (gap: 8000:6000) [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] PERCPU: Allocating 32768 bytes of per cpu data [
Kernel panic at boot with recent pci quirks patch
The latest -git tree panics at boot for me. git-bisect traced the offending commit to: 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Author: Alan Cox [EMAIL PROTECTED] Date: Wed Oct 4 00:41:26 2006 +0100 PCI: quirks: fix the festering mess that claims to handle IDE quirks Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64. I've attached a netcconsole dump of the panic, as well as lspci output. Is there any additional information I can provide? Thanks, Frank [0.00] Linux version 2.6.19-bs1 ([EMAIL PROTECTED]) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #11 SMP PREEMPT Wed Dec 6 09:43:25 CST 2006 [0.00] Command line: ro root=/dev/VolGroup00/RootVol vga=794 apic=verbose nmi_watchdog=1 [EMAIL PROTECTED]/,@64.62.190.123/00:0F:66:99:97:4F loglevel=8 console=tty0 console=ttyUSB0,9600n8 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f000 (usable) [0.00] BIOS-e820: 0009f000 - 000a (reserved) [0.00] BIOS-e820: 0010 - 7fed3400 (usable) [0.00] BIOS-e820: 7fed3400 - 8000 (reserved) [0.00] BIOS-e820: e000 - f0007000 (reserved) [0.00] BIOS-e820: f0008000 - f000c000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed2 - feda (reserved) [0.00] BIOS-e820: fee0 - fee1 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 523987) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] ACPI: RSDP (v000 DELL ) @ 0x000fc1b0 [0.00] ACPI: RSDT (v001 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed39cd [0.00] ACPI: FADT (v001 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed4800 [0.00] ACPI: MADT (v001 DELLM07 0x27d6071d ASL 0x0047) @ 0x7fed5000 [0.00] ACPI: MCFG (v016 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed4fc0 [0.00] ACPI: BOOT (v001 DELLM07 0x27d6071d ASL 0x0061) @ 0x7fed4bc0 [0.00] ACPI: SSDT (v001 PmRefCpuPm 0x3000 INTL 0x20050624) @ 0x7fed3a05 [0.00] ACPI: DSDT (v001 INT430 SYSFexxx 0x1001 INTL 0x20050624) @ 0x [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 523987) 1 entries of 256 used [0.00] No mptable found. [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 523987 [0.00] On node 0 totalpages: 523890 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 8 pages reserved [0.00] DMA zone: 3935 pages, LIFO batch:0 [0.00] DMA32 zone: 7107 pages used for memmap [0.00] DMA32 zone: 512784 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to physical flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] mapped APIC to ff5fd000 (fee0) [0.00] mapped IOAPIC to ff5fc000 (fec0) [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 0010 [0.00] Allocating PCI resources starting at 8800 (gap: 8000:6000) [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] PERCPU: Allocating 32768 bytes of per cpu data [0.00]
Re: Kernel panic at boot with recent pci quirks patch
Remi Colinet wrote: Frank Sorenson [EMAIL PROTECTED] wrote: The latest -git tree panics at boot for me. git-bisect traced the offending commit to: 368c73d4f689dae0807d0a2aa74c61fd2b9b075f is first bad commit commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f Author: Alan Cox [EMAIL PROTECTED] Date: Wed Oct 4 00:41:26 2006 +0100 PCI: quirks: fix the festering mess that claims to handle IDE quirks Hardware is a Dell Inspiron E1705 laptop running FC6 x86_64. Could you try the following patch (already included in mm tree)? http://www.uwsg.indiana.edu/hypermail/linux/kernel/0611.1/1568.html Remi Yes, that patch does seem to fix the problem. Is it the right fix? Frank - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 2.6.19 git compile error - "current_is_keventd" [drivers/net/phy/libphy.ko] undefined
[EMAIL PROTECTED] wrote: to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2006/12/04/18:00 CST Building modules, stage 2. Kernel: arch/x86_64/boot/bzImage is ready (#2) MODPOST 1256 modules WARNING: "current_is_keventd" [drivers/net/phy/libphy.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 xboom Here's a patch with the easy fix, but I'm not certain it's a permanent fix. Frank This patch fixes a compile error when CONFIG_PHYLIB is a module. Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]> --- kernel/workqueue.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.19-fs1/kernel/workqueue.c === --- linux-2.6.19-fs1.orig/kernel/workqueue.c 2006-12-04 22:21:06.0 -0600 +++ linux-2.6.19-fs1/kernel/workqueue.c 2006-12-04 22:59:55.0 -0600 @@ -608,6 +608,7 @@ return ret; } +EXPORT_SYMBOL_GPL(current_is_keventd); #ifdef CONFIG_HOTPLUG_CPU /* Take the work from this (downed) CPU. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: 2.6.19 git compile error - current_is_keventd [drivers/net/phy/libphy.ko] undefined
[EMAIL PROTECTED] wrote: to: linux-kernel@vger.kernel.org cc: [EMAIL PROTECTED] 2006/12/04/18:00 CST Building modules, stage 2. Kernel: arch/x86_64/boot/bzImage is ready (#2) MODPOST 1256 modules WARNING: current_is_keventd [drivers/net/phy/libphy.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 xboom Here's a patch with the easy fix, but I'm not certain it's a permanent fix. Frank This patch fixes a compile error when CONFIG_PHYLIB is a module. Signed-off-by: Frank Sorenson [EMAIL PROTECTED] --- kernel/workqueue.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.19-fs1/kernel/workqueue.c === --- linux-2.6.19-fs1.orig/kernel/workqueue.c 2006-12-04 22:21:06.0 -0600 +++ linux-2.6.19-fs1/kernel/workqueue.c 2006-12-04 22:59:55.0 -0600 @@ -608,6 +608,7 @@ return ret; } +EXPORT_SYMBOL_GPL(current_is_keventd); #ifdef CONFIG_HOTPLUG_CPU /* Take the work from this (downed) CPU. */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make the bzImage format self-terminating
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: > I'm proposing the attached patch to replace Frank Sorenson's > i386-buildc-write-out-larger-system-size-to-bootsector patch currently > in -mm. The goal (presumably) is to make the bzImage format > self-terminating. > > Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> Looks good to me. Using the 2 additional bytes allows the header to contain the full system size for a very long time, and your patch includes documentation and x86_64. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDGMiTaI0dwg4A47wRAghjAJ9p5sElrA0kDpbwmX4kW9N6WoE3TwCg0Slp yq/DxrzJ32DlG+Scp4I7zDM= =DKHC -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make the bzImage format self-terminating
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: I'm proposing the attached patch to replace Frank Sorenson's i386-buildc-write-out-larger-system-size-to-bootsector patch currently in -mm. The goal (presumably) is to make the bzImage format self-terminating. Signed-off-by: H. Peter Anvin [EMAIL PROTECTED] Looks good to me. Using the 2 additional bytes allows the header to contain the full system size for a very long time, and your patch includes documentation and x86_64. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDGMiTaI0dwg4A47wRAghjAJ9p5sElrA0kDpbwmX4kW9N6WoE3TwCg0Slp yq/DxrzJ32DlG+Scp4I7zDM= =DKHC -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] i386: build.c: Write out larger system size to bootsector
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch allows build.c to write out the full system size to the bootsector
for system sizes larger than about 1 MB (1048560 bytes) by using another byte
(a 4th byte would allow system sizes larger than 268 MB).
Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]>
- --- a/arch/i386/boot/tools/build.c2005-08-07 18:08:29.0 -0600
+++ b/arch/i386/boot/tools/build.c 2005-08-07 18:09:51.0 -0600
@@ -177,7 +177,8 @@
die("Output: seek failed");
buf[0] = (sys_size & 0xff);
buf[1] = ((sys_size >> 8) & 0xff);
- - if (write(1, buf, 2) != 2)
+ buf[2] = ((sys_size >> 16) & 0xff);
+ if (write(1, buf, 3) != 3)
die("Write of image length failed");
return 0; /* Everything is OK
*/
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9r+raI0dwg4A47wRAtXCAKCm3f2Afx/SC5H+6HJz2JzM9cA1ZQCgjMbg
qt7Rmo23aWfG1cvsZrcsQvA=
=0iHd
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch] i386: build.c: Write out larger system size to bootsector
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This patch allows build.c to write out the full system size to the bootsector for system sizes larger than about 1 MB (1048560 bytes) by using another byte (a 4th byte would allow system sizes larger than 268 MB). Signed-off-by: Frank Sorenson [EMAIL PROTECTED] - --- a/arch/i386/boot/tools/build.c2005-08-07 18:08:29.0 -0600 +++ b/arch/i386/boot/tools/build.c 2005-08-07 18:09:51.0 -0600 @@ -177,7 +177,8 @@ die(Output: seek failed); buf[0] = (sys_size 0xff); buf[1] = ((sys_size 8) 0xff); - - if (write(1, buf, 2) != 2) + buf[2] = ((sys_size 16) 0xff); + if (write(1, buf, 3) != 3) die(Write of image length failed); return 0; /* Everything is OK */ Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC9r+raI0dwg4A47wRAtXCAKCm3f2Afx/SC5H+6HJz2JzM9cA1ZQCgjMbg qt7Rmo23aWfG1cvsZrcsQvA= =0iHd -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix up i386 compile after the "i386: clean up user_mode macros" patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The "i386: clean up user_mode macros" patch that recently went into the kernel doesn't know the definition of VM_MASK, so the current -git doesn't compile. This patch includes the header where VM_MASK is defined. Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]> Fix up i386 compile after the "i386: clean up user_mode macros" patch diff --git a/include/asm-i386/ptrace.h b/include/asm-i386/ptrace.h - --- a/include/asm-i386/ptrace.h +++ b/include/asm-i386/ptrace.h @@ -1,8 +1,10 @@ #ifndef _I386_PTRACE_H #define _I386_PTRACE_H +#include + #define EBX 0 #define ECX 1 #define EDX 2 #define ESI 3 #define EDI 4 Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC5/U+aI0dwg4A47wRAsdOAJ9hzY9aQ0pQTY1QikQ0MzobJzJG7QCeI9C7 zU+Gyxyp933jK0ahLWDhzq0= =90nz -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix up i386 compile after the i386: clean up user_mode macros patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The i386: clean up user_mode macros patch that recently went into the kernel doesn't know the definition of VM_MASK, so the current -git doesn't compile. This patch includes the header where VM_MASK is defined. Signed-off-by: Frank Sorenson [EMAIL PROTECTED] Fix up i386 compile after the i386: clean up user_mode macros patch diff --git a/include/asm-i386/ptrace.h b/include/asm-i386/ptrace.h - --- a/include/asm-i386/ptrace.h +++ b/include/asm-i386/ptrace.h @@ -1,8 +1,10 @@ #ifndef _I386_PTRACE_H #define _I386_PTRACE_H +#include asm-i386/vm86.h + #define EBX 0 #define ECX 1 #define EDX 2 #define ESI 3 #define EDI 4 Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC5/U+aI0dwg4A47wRAsdOAJ9hzY9aQ0pQTY1QikQ0MzobJzJG7QCeI9C7 zU+Gyxyp933jK0ahLWDhzq0= =90nz -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New timeofday subsystem: Lockups
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John, Nish, others:
I'm not sure whether this is an issue with John's TOD patches, John's
NTP rework, or Nish's softtimer patches, but something in this
combination seems to be locking up my system frequently. Often, it will
completely hang during boot, and it periodically hangs while starting X
or even just under normal (unstressed) use.
During several of the boot-ups, the NMI Watchdog has caught lockups.
Here is the output of one of those lockups (hand-copied, so hopefully no
mistakes):
NMI Watchdog detected LOCKUP on CPU0, eip c01248bb, registers:
Modules linked in: ipw2200 ieee80211 ieee80211_crypt
CPU:0
EIP:0060:[] Not tainted VLI
EFLAGS: 0046 (2.6.13-rc3-skas3-v9-pre7-fs6)
EIP is at get_jiffies_64+0x2b/0x40
eax: ebx: ffbf503ecx: 00011c84 edx:
esi: edi: ebp: c05cba00 esp: c065ff00
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c065f000 task=c0552b80)
Stack: 94ad 88e3 c03b01d7 c06aca50 c0330d90 67347457 000c
88e1
c0558080 c065f000 f7c42de4 0082 c05cba00
c013e908
c06ac9c0 0080 0aa2 0aa2 fffb7e00 f7c42de4
0082
Call Trace:
[] read_tsc_interp+0x17/0x120
[] __ide_do_rw_disk+0x200/0540
[] do_monotonic_clock+0x28/0x130
[] add_timer+0x16/0x60
[] ide_set_handler+0x28/0x60
[] task_in_intr+0x4f/0x100
[] ide_intr+0x95/0x1d0
[] task_in_intr+0x0/0x100
[] handle_IRQ_event+0x33/0x70
[] __do_IRQ+0x53/0xa0
=
[] read_tsc_interp+0x17/0x120
[] common_interrupt+0x1a/0x20
[] alloc_pidmap+0x8b/0x1f0
[] tsc_interp_sync+0x4f/0xa0
[] tsc_interp_sync+0x0/0xa0
[] run_timer_softirq+0xb4/0x1d0
[] __do_softirq+0x42/0xa0
[] do_softirq+0x4e/0x60
===
[] irq_exit+0x35/0x40
[] do_IRQ+0x5a/0xa0
[] common_interrupt+0x1a/0x20
[] acpi_processor_idle+0x10e/0x28e
[] default_idle+0x0/0x30
[] cpu_idle+0x34/0x50
[] start_kernel+0x186/0x1f0
Code: 8b 0d 64 da 68 c0 56 53 90 8d b4 26 00 00 00 00 89 c8 8b 1d 80 5e
55 c0 8b 35 84 5e 55 c0 89 ca 8b 0d 64 da 68 c0 83 e2 01 31 c8 <09> c2
75 e1 89 d8 89 f2 5b 5e c3 90 90 90 90 90 90 90 90 90 90
console shuts up ...
Hopefully someone can make something out of this!
Any ideas?
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC4KloaI0dwg4A47wRAiosAKD7Hn+nzJEizqKvXDaXIfXw0T+0RACgrQnF
NikzhdmXzPjL0Bi2D2aBOk4=
=EN1O
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
New timeofday subsystem: Lockups
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John, Nish, others:
I'm not sure whether this is an issue with John's TOD patches, John's
NTP rework, or Nish's softtimer patches, but something in this
combination seems to be locking up my system frequently. Often, it will
completely hang during boot, and it periodically hangs while starting X
or even just under normal (unstressed) use.
During several of the boot-ups, the NMI Watchdog has caught lockups.
Here is the output of one of those lockups (hand-copied, so hopefully no
mistakes):
NMI Watchdog detected LOCKUP on CPU0, eip c01248bb, registers:
Modules linked in: ipw2200 ieee80211 ieee80211_crypt
CPU:0
EIP:0060:[c01248bb] Not tainted VLI
EFLAGS: 0046 (2.6.13-rc3-skas3-v9-pre7-fs6)
EIP is at get_jiffies_64+0x2b/0x40
eax: ebx: ffbf503ecx: 00011c84 edx:
esi: edi: ebp: c05cba00 esp: c065ff00
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=c065f000 task=c0552b80)
Stack: 94ad 88e3 c03b01d7 c06aca50 c0330d90 67347457 000c
88e1
c0558080 c065f000 f7c42de4 0082 c05cba00
c013e908
c06ac9c0 0080 0aa2 0aa2 fffb7e00 f7c42de4
0082
Call Trace:
[c03b01d7] read_tsc_interp+0x17/0x120
[c0330d90] __ide_do_rw_disk+0x200/0540
[c013e908] do_monotonic_clock+0x28/0x130
[c01283e6] add_timer+0x16/0x60
[c0328738] ide_set_handler+0x28/0x60
[c032c7df] task_in_intr+0x4f/0x100
[c0327405] ide_intr+0x95/0x1d0
[c032c790] task_in_intr+0x0/0x100
[c014cae3] handle_IRQ_event+0x33/0x70
[c014cbe6] __do_IRQ+0x53/0xa0
=
[c03b01d7] read_tsc_interp+0x17/0x120
[c0104b86] common_interrupt+0x1a/0x20
[c013007b] alloc_pidmap+0x8b/0x1f0
[c03b016f] tsc_interp_sync+0x4f/0xa0
[c03b0120] tsc_interp_sync+0x0/0xa0
[c0128884] run_timer_softirq+0xb4/0x1d0
[c0124912] __do_softirq+0x42/0xa0
[c010688e] do_softirq+0x4e/0x60
===
[c0124a35] irq_exit+0x35/0x40
[c010674a] do_IRQ+0x5a/0xa0
[c0104b86] common_interrupt+0x1a/0x20
[c02b16fa] acpi_processor_idle+0x10e/0x28e
[c0102030] default_idle+0x0/0x30
[c01020d4] cpu_idle+0x34/0x50
[c0621856] start_kernel+0x186/0x1f0
Code: 8b 0d 64 da 68 c0 56 53 90 8d b4 26 00 00 00 00 89 c8 8b 1d 80 5e
55 c0 8b 35 84 5e 55 c0 89 ca 8b 0d 64 da 68 c0 83 e2 01 31 c8 09 c2
75 e1 89 d8 89 f2 5b 5e c3 90 90 90 90 90 90 90 90 90 90
console shuts up ...
Hopefully someone can make something out of this!
Any ideas?
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC4KloaI0dwg4A47wRAiosAKD7Hn+nzJEizqKvXDaXIfXw0T+0RACgrQnF
NikzhdmXzPjL0Bi2D2aBOk4=
=EN1O
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/6] new timeofday core subsystem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> +extern nsec_t do_monotonic_clock(void);
This looks okay ...
> +/**
> + * do_monotonic_clock - Returns monotonically increasing nanoseconds
> + *
> + * Returns the monotonically increasing number of nanoseconds
> + * since the system booted via __monotonic_clock()
> + */
> +nsec_t do_monotonic_clock(void)
> +{
> + nsec_t ret;
> + unsigned long seq;
> +
> + /* atomically read __monotonic_clock() */
> + do {
> + seq = read_seqbegin(_time_lock);
> +
> + ret = __monotonic_clock();
> +
> + } while (read_seqretry(_time_lock, seq));
> +
> + return ret;
> +}
... but this conflicts with Nish's softtimer patches, which is
implemented slightly differently. For those of us who are real gluttons
for punishment, and want both sets of patches, are there problems just
removing one of the do_monotonic_clock definitions?
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC2MYNaI0dwg4A47wRAiQoAJ9vUvpjE7KmhCNW7NJ6kfd0SuyvXwCg+NtN
pXqoz0v5Tbf5OMFjhYSzPp0=
=LT9E
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 1/6] new timeofday core subsystem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
+extern nsec_t do_monotonic_clock(void);
This looks okay ...
+/**
+ * do_monotonic_clock - Returns monotonically increasing nanoseconds
+ *
+ * Returns the monotonically increasing number of nanoseconds
+ * since the system booted via __monotonic_clock()
+ */
+nsec_t do_monotonic_clock(void)
+{
+ nsec_t ret;
+ unsigned long seq;
+
+ /* atomically read __monotonic_clock() */
+ do {
+ seq = read_seqbegin(system_time_lock);
+
+ ret = __monotonic_clock();
+
+ } while (read_seqretry(system_time_lock, seq));
+
+ return ret;
+}
... but this conflicts with Nish's softtimer patches, which is
implemented slightly differently. For those of us who are real gluttons
for punishment, and want both sets of patches, are there problems just
removing one of the do_monotonic_clock definitions?
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC2MYNaI0dwg4A47wRAiQoAJ9vUvpjE7KmhCNW7NJ6kfd0SuyvXwCg+NtN
pXqoz0v5Tbf5OMFjhYSzPp0=
=LT9E
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Updating hard disk firmware (Was: Re: Head parking)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Knoblauch wrote: > Download is simple, just don't use the "IBM Download Manager". Main > problem is that one needs a bootable floopy drive and "the other OS" to > create a bootable floppy. It would be great if IBM could provide floppy > images for use with "dd" for the poor Linux users. You may be able to use this process to avoid using either a floppy drive or "the other OS": 1) Download the appropriate firmware exe from http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-41008 (in my case, this looks like fwhd3313.exe) 2) Find a freedos disk image (I used one that came with biosdisk - http://linux.dell.com/biosdisk/) 3) Create a disk image for the firmware executable: cp /usr/share/biosdisk/dosdisk.img /tmp/fwdisk1.img mount -oloop /tmp/fwtemp.img /mnt/tmp cp fwhd3313.exe /mnt/tmp umount /mnt/tmp 4) Create a blank disk image for the extracted contents: dd if=/dev/zero of=/boot/fwdisk.img bs=1474560 count=1 5) Run qemu to extract files and write the disk image: qemu -fda /tmp/fwtemp.img -fdb /boot/fwdisk.img A:\>fwhd3313 ... exit qemu 6) Set up grub to boot the new disk image (requires memdisk from syslinux - http://syslinux.zytor.com/): $EDITOR /boot/grub/grub.conf title IBM Hard Drive Firmware update kernel /memdisk initrd=/fwdisk.img floppy 7) Reboot and select the "IBM Hard Drive Firmware update" option It allowed me to run the firmware update program, however it didn't believe my drive needed updating, so I haven't even successfully tried the entire process. Please let me know if it works for you. DISCLAIMER: I also provide no guarantees. Hopefully your hard disk won't fly off the spindle or anything else bad. If it does, blame someone else. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzX4MaI0dwg4A47wRAnXUAKCEsQQSj4aHkwMr8vZLei23+DhUuwCfb1Mb NTmyLHJDa602Iex/QAr/N2I= =fexM -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Updating hard disk firmware (Was: Re: Head parking)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Knoblauch wrote: Download is simple, just don't use the IBM Download Manager. Main problem is that one needs a bootable floopy drive and the other OS to create a bootable floppy. It would be great if IBM could provide floppy images for use with dd for the poor Linux users. You may be able to use this process to avoid using either a floppy drive or the other OS: 1) Download the appropriate firmware exe from http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-41008 (in my case, this looks like fwhd3313.exe) 2) Find a freedos disk image (I used one that came with biosdisk - http://linux.dell.com/biosdisk/) 3) Create a disk image for the firmware executable: cp /usr/share/biosdisk/dosdisk.img /tmp/fwdisk1.img mount -oloop /tmp/fwtemp.img /mnt/tmp cp fwhd3313.exe /mnt/tmp umount /mnt/tmp 4) Create a blank disk image for the extracted contents: dd if=/dev/zero of=/boot/fwdisk.img bs=1474560 count=1 5) Run qemu to extract files and write the disk image: qemu -fda /tmp/fwtemp.img -fdb /boot/fwdisk.img A:\fwhd3313 ... exit qemu 6) Set up grub to boot the new disk image (requires memdisk from syslinux - http://syslinux.zytor.com/): $EDITOR /boot/grub/grub.conf title IBM Hard Drive Firmware update kernel /memdisk initrd=/fwdisk.img floppy 7) Reboot and select the IBM Hard Drive Firmware update option It allowed me to run the firmware update program, however it didn't believe my drive needed updating, so I haven't even successfully tried the entire process. Please let me know if it works for you. DISCLAIMER: I also provide no guarantees. Hopefully your hard disk won't fly off the spindle or anything else bad. If it does, blame someone else. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzX4MaI0dwg4A47wRAnXUAKCEsQQSj4aHkwMr8vZLei23+DhUuwCfb1Mb NTmyLHJDa602Iex/QAr/N2I= =fexM -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: > That does not make sense. > > Are you saying you cannot trust your own sshfs userspace daemon? The user who wrote the userspace code may be able to, but the system shouldn't trust the userspace daemon. Permissions will be enforced by the ssh server. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCW+ZLaI0dwg4A47wRAnDVAKCb2Hk39ouYkjEDgTlz+RTsPsAn5QCgpKvZ rfYjOi+x6+RSie+t8GIxX74= =qShM -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] FUSE permission modell (Was: fuse review bits)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jamie Lokier wrote: That does not make sense. Are you saying you cannot trust your own sshfs userspace daemon? The user who wrote the userspace code may be able to, but the system shouldn't trust the userspace daemon. Permissions will be enforced by the ssh server. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCW+ZLaI0dwg4A47wRAnDVAKCb2Hk39ouYkjEDgTlz+RTsPsAn5QCgpKvZ rfYjOi+x6+RSie+t8GIxX74= =qShM -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: > * Frank Sorenson <[EMAIL PROTECTED]> [050408 01:49]: >>This updated patch seems to work just fine on my machine with lapic on >>the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. >> >>Also, you were correct that removing lapic from the cmdline allowed the >>previous version to run at full speed. > > > Cool. > > >>Now, how can I tell if the patch is doing its thing? What should I be >>seeing? :) > > > Download pmstats from http://www.muru.com/linux/dyntick/, you may > need to edit it a bit for correct ACPI battery values. But it should > show you HZ during idle and load. I believe idle still does not go > to ACPI C3 with dyn-tick though... > > Then you might as well run timetest from same location too to make > sure your clock keeps correct time. Seems to be going up when under load, and down when idle, so I suppose it's working :) The clock is only a little jittery, but not more than I'd expect across the network, so it looks like it's keeping time okay. Would it be possible to determine whether the system will wake to the APIC interrupt at system boot, rather than hardcoded in the config? After you explained the problem, I noticed that creating my own interrupts (holding down a key on the keyboard for example) kept the system moving and not slow. For example, something like this (sorry, I don't know the code well enough yet to attempt to code it myself): set the APIC timer to fire in X set another timer/interrupt to fire in 2X wait for the interrupt if (time_elapsed >= 2X) disable the APIC timer else APIC timer should work Or, determine which timer woke us up, etc. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVvriaI0dwg4A47wRAhhyAJ928wgPEY/9X4KmyJcsaJ+WZk0XRQCfTfcj x3yKiwYOhMac/SQ7El9N0q0= =2QVB -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: | * Tony Lindgren <[EMAIL PROTECTED]> [050407 23:28]: | |>I think I have an idea on what's going on; Your system does not wake to |>APIC interrupt, and the system timer updates time only on other interrupts. |>I'm experiencing the same on a loaner ThinkPad T30. |> |>I'll try to do another patch today. Meanwhile it now should work |>without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as "initialization from incompatible pointer type" several times in dyn-tick-timer.c and a "too many arguments for format" in dyn_tick_late_init. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVkWDaI0dwg4A47wRAgzOAKCHcx8p59ZbihYtZJ84p62v2rMauQCfUuzz D7O98hHvjtTa/CvFHHtJe4c= =G2I/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: | * Tony Lindgren [EMAIL PROTECTED] [050407 23:28]: | |I think I have an idea on what's going on; Your system does not wake to |APIC interrupt, and the system timer updates time only on other interrupts. |I'm experiencing the same on a loaner ThinkPad T30. | |I'll try to do another patch today. Meanwhile it now should work |without lapic in cmdline. | | | Following is an updated patch. Anybody having trouble, please try | disabling CONFIG_DYN_TICK_USE_APIC Kconfig option. | | I'm hoping this might work on Pavel's machine too? | | Tony This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Functionally, it looks like it's working. There were a number of compiler warnings you might wish to fix before calling it good. Such as initialization from incompatible pointer type several times in dyn-tick-timer.c and a too many arguments for format in dyn_tick_late_init. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVkWDaI0dwg4A47wRAgzOAKCHcx8p59ZbihYtZJ84p62v2rMauQCfUuzz D7O98hHvjtTa/CvFHHtJe4c= =G2I/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: * Frank Sorenson [EMAIL PROTECTED] [050408 01:49]: This updated patch seems to work just fine on my machine with lapic on the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. Also, you were correct that removing lapic from the cmdline allowed the previous version to run at full speed. Cool. Now, how can I tell if the patch is doing its thing? What should I be seeing? :) Download pmstats from http://www.muru.com/linux/dyntick/, you may need to edit it a bit for correct ACPI battery values. But it should show you HZ during idle and load. I believe idle still does not go to ACPI C3 with dyn-tick though... Then you might as well run timetest from same location too to make sure your clock keeps correct time. Seems to be going up when under load, and down when idle, so I suppose it's working :) The clock is only a little jittery, but not more than I'd expect across the network, so it looks like it's keeping time okay. Would it be possible to determine whether the system will wake to the APIC interrupt at system boot, rather than hardcoded in the config? After you explained the problem, I noticed that creating my own interrupts (holding down a key on the keyboard for example) kept the system moving and not slow. For example, something like this (sorry, I don't know the code well enough yet to attempt to code it myself): set the APIC timer to fire in X set another timer/interrupt to fire in 2X wait for the interrupt if (time_elapsed = 2X) disable the APIC timer else APIC timer should work Or, determine which timer woke us up, etc. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVvriaI0dwg4A47wRAhhyAJ928wgPEY/9X4KmyJcsaJ+WZk0XRQCfTfcj x3yKiwYOhMac/SQ7El9N0q0= =2QVB -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic Tick version 050406-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: > Tony Lindgren wrote: > >>Thanks for trying it out. What kind of hardware do you have? Does it >>have HPET? It looks like no suitable timer for dyn-tick is found... >>Maybe the following patch helps? >> >>Tony > > > Does 'different crash' qualify as "helping"? :) Update: The patch does seem to fix the crash. This "different crash" I mentioned appears to be related to the netconsole I was using (serial console produces stairstepping text, netconsole seems to duplicate lines--go figure). Without netconsole, dynamic tick appears to be working, so I'm not sure whether this is a netconsole bug or a dynamic tick bug. While dynamic tick no longer panics, with dynamic tick, my system slows to whatever is slower than a crawl. It now takes 6 minutes 50 seconds to boot all the way up, compared to 1 minute 35 seconds with my 2.6.12 kernel without the dynamic tick patch. I'm not sure where this slowdown is occurring yet. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVbJHaI0dwg4A47wRAmijAKCRgg9MTxrrNWKanMmmSS010BTWdgCeNMnJ 4YJWhHAcizMgZNH/+643Hvk= =w9Ii -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic Tick version 050406-1
Tony Lindgren wrote: > Thanks for trying it out. What kind of hardware do you have? Does it > have HPET? It looks like no suitable timer for dyn-tick is found... > Maybe the following patch helps? > > Tony Does 'different crash' qualify as "helping"? :) With this additional patch, I get this line followed by a system hang: [4294688.246000] dyn-tick: Maximum ticks to skip limited to 2693 With "nmi_watchdog=1", the "dyn-tick: Maximum..." line is followed by (my serial console stops logging): <4>[4294688.741000] NMI Watchdog detected LOCKUP on CPU0, eip c011a2ab, registers: Modules linked in: CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 0046 (2.6.12-rc2-dyntick) EIP is at smp_apic_timer_interrupt ... etc ... This is on my Dell Inspiron 9200: /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 2.00GHz stepping: 6 cpu MHz : 598.130 cache size : 2048 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips: 1183.74 Attached are the serial log and the .config. HPET is enabled, and appears to be detected. Let me know if you need any additional info or need me to try anything else out. Frank -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc2 # Thu Apr 7 13:09:54 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-dyntick" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NO_IDLE_HZ=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CON
Re: [PATCH] Dynamic Tick version 050406-1
Tony Lindgren wrote: Thanks for trying it out. What kind of hardware do you have? Does it have HPET? It looks like no suitable timer for dyn-tick is found... Maybe the following patch helps? Tony Does 'different crash' qualify as helping? :) With this additional patch, I get this line followed by a system hang: [4294688.246000] dyn-tick: Maximum ticks to skip limited to 2693 With nmi_watchdog=1, the dyn-tick: Maximum... line is followed by (my serial console stops logging): 4[4294688.741000] NMI Watchdog detected LOCKUP on CPU0, eip c011a2ab, registers: Modules linked in: CPU: 0 EIP: 0060:[c011a2ab] Not tainted VLI EFLAGS: 0046 (2.6.12-rc2-dyntick) EIP is at smp_apic_timer_interrupt ... etc ... This is on my Dell Inspiron 9200: /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 2.00GHz stepping: 6 cpu MHz : 598.130 cache size : 2048 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips: 1183.74 Attached are the serial log and the .config. HPET is enabled, and appears to be detected. Let me know if you need any additional info or need me to try anything else out. Frank -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc2 # Thu Apr 7 13:09:54 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-dyntick CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set CONFIG_MPENTIUMM=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NO_IDLE_HZ=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y
Re: [PATCH] Dynamic Tick version 050406-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frank Sorenson wrote: Tony Lindgren wrote: Thanks for trying it out. What kind of hardware do you have? Does it have HPET? It looks like no suitable timer for dyn-tick is found... Maybe the following patch helps? Tony Does 'different crash' qualify as helping? :) Update: The patch does seem to fix the crash. This different crash I mentioned appears to be related to the netconsole I was using (serial console produces stairstepping text, netconsole seems to duplicate lines--go figure). Without netconsole, dynamic tick appears to be working, so I'm not sure whether this is a netconsole bug or a dynamic tick bug. While dynamic tick no longer panics, with dynamic tick, my system slows to whatever is slower than a crawl. It now takes 6 minutes 50 seconds to boot all the way up, compared to 1 minute 35 seconds with my 2.6.12 kernel without the dynamic tick patch. I'm not sure where this slowdown is occurring yet. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVbJHaI0dwg4A47wRAmijAKCRgg9MTxrrNWKanMmmSS010BTWdgCeNMnJ 4YJWhHAcizMgZNH/+643Hvk= =w9Ii -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dynamic Tick version 050406-1
Tony Lindgren wrote: > Hi all, > > Here's an updated dyn-tick patch. Some minor fixes: Doesn't look so good here. I get this with 2.6.12-rc2 (plus a few other patches). Disabling Dynamic Tick makes everything happy again (it boots). [4294688.655000] Unable to handle kernel NULL pointer dereference at virtual address [4294688.656000] printing eip: [4294688.657000] c077f818 [4294688.659000] *pde = [4294688.66] Oops: [#1] [4294688.661000] PREEMPT [4294688.662000] Modules linked in: [4294688.663000] CPU:0 [4294688.663000] EIP:0060:[]Not tainted VLI [4294688.663000] EFLAGS: 00010202 (2.6.12-rc2-fs3) [4294688.666000] EIP is at dyn_tick_late_init+0x38/0x80 [4294688.667000] eax: ebx: c079f0c0 ecx: edx: f7c15d4c [4294688.668000] esi: f7f02000 edi: ebp: f7f03fb8 esp: f7f03fb4 [4294688.669000] ds: 007b es: 007b ss: 0068 [4294688.67] Process swapper (pid: 1, threadinfo=f7f02000 task=f7f01830) [4294688.67] Stack: c077a0e2 f7f03fd8 c076a956 c019bde8 c01002a0 c01002a0 000 [4294688.671000] f7f03fec c01002d5 007b 007b c0101365 [4294688.672000] [4294688.673000] Call Trace: [4294688.675000] [] show_stack+0x7a/0x90 [4294688.676000] [] show_registers+0x149/0x1c0 [4294688.677000] [] die+0x14a/0x2d0 [4294688.678000] [] do_page_fault+0x44e/0x633 [4294688.679000] [] error_code+0x4f/0x54 [4294688.68] [] do_initcalls+0x56/0xc0 [4294688.681000] [] init+0x35/0x110 [4294688.682000] [] kernel_thread_helper+0x5/0x10 [4294688.683000] Code: 83 ec 04 e8 3b 6b c0 ff ba 14 b7<7>eth0: no IPv6 routers present Frank -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] [4294667.296000] Linux version 2.6.12-rc2-fs3 ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #3 Wed Apr 6 13:14:48 MDT 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: - 0009f000 (usable) [4294667.296000] BIOS-e820: 0009f000 - 000a (reserved) [4294667.296000] BIOS-e820: 0010 - 5ffae000 (usable) [4294667.296000] BIOS-e820: 5ffae000 - 6000 (reserved) [4294667.296000] BIOS-e820: feda - fee0 (reserved) [4294667.296000] BIOS-e820: ffb0 - 0001 (reserved) [4294667.296000] 639MB HIGHMEM available. [4294667.296000] 896MB LOWMEM available. [4294667.296000] DMI 2.3 present. [4294667.296000] ACPI: PM-Timer IO Port: 0x808 [4294667.296000] Allocating PCI resources starting at 6000 (gap: 6000:9eda) [4294667.296000] Built 1 zonelists [4294667.296000] Kernel command line: ro root=LABEL=/1 vga=794 nmi_watchdog=1 lapic console=tty0 console=ttyUSB0,9600 psmouse.proto=exps i8k.ignore_dmi:bool=true [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ single [4294667.296000] Unknown boot option `i8k.ignore_dmi:bool=true': ignoring [4294667.296000] netconsole: local port 6665 [4294667.296000] netconsole: local IP 128.187.171.101 [4294667.296000] netconsole: interface eth0 [4294667.296000] netconsole: remote port 5515[4294667.296000] netconsole: remote IP 128.187.171.102 [4294667.[4294667.296000] Console: colour dummy device 80x25 [4294667.298[4294667.472000] Capability LSM initialized as secondary [429466[4294667.472000] Checking 'hlt' instruction... OK. [4294667.4830[4294667.616000] checking if image is initramfs... it is [429466[4294667.75] Completing Region/Field/Buffer/Package initiali[4294667.881000] PCI: Transparent bridge - :00:1e.0 [4294667[4294668.309000] pnp: PnP ACPI: found 10 devices [4294668.31[4294668.534000] pnp: 00:01: ioport range 0x808-0x80f could not [4294668.607000] audit(1112798526.606:0): initialized [4294668.6[4294668.625000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ [4294668.947000] * connector 1 of type 2 (CRT) : 2320 [4294668[4294671.384000] radeonfb: Monitor 1 type LCD found [4294671.384[4294671.384000] 320 x 400 [4294671.384000] 320 x 400 [4294671[4294671.384000] 1024 x 768 [4294671.384000] 1280 x 1024 [4294[4294671.384000] Setting up default mode based on panel info [42[4294671.492000] fb1: VESA VGA frame buffer device [4294671.4980[4294673.099000] agpgart: AGP aperture is 128M @ 0xe800 [429[4294673.156000] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ [4294673.205000] PPP generic driver version 2.4.2 [4294673.20800[4294676.218000] b44: eth0: Link is up at 100 Mbps, full duplex.[4294677.477000] ICH4: not 100% native mode: will probe irqs lat[4294682.079000] hda: cache flushes supported [4294682.081000] [4294682.253000] PCI: Enabling device :02:01.0 ( -> 0002[4294682.646000] Badness in device_release at drivers/base/core.[4294682.657000] Databook TCIC-2 PCMCIA probe: not found. [42946[4294682.683000] hub 1-0:1.0: 6 ports detected [4294682.705000] [42
Re: [PATCH] Dynamic Tick version 050406-1
Tony Lindgren wrote: Hi all, Here's an updated dyn-tick patch. Some minor fixes: Doesn't look so good here. I get this with 2.6.12-rc2 (plus a few other patches). Disabling Dynamic Tick makes everything happy again (it boots). [4294688.655000] Unable to handle kernel NULL pointer dereference at virtual address [4294688.656000] printing eip: [4294688.657000] c077f818 [4294688.659000] *pde = [4294688.66] Oops: [#1] [4294688.661000] PREEMPT [4294688.662000] Modules linked in: [4294688.663000] CPU:0 [4294688.663000] EIP:0060:[c077f818]Not tainted VLI [4294688.663000] EFLAGS: 00010202 (2.6.12-rc2-fs3) [4294688.666000] EIP is at dyn_tick_late_init+0x38/0x80 [4294688.667000] eax: ebx: c079f0c0 ecx: edx: f7c15d4c [4294688.668000] esi: f7f02000 edi: ebp: f7f03fb8 esp: f7f03fb4 [4294688.669000] ds: 007b es: 007b ss: 0068 [4294688.67] Process swapper (pid: 1, threadinfo=f7f02000 task=f7f01830) [4294688.67] Stack: c077a0e2 f7f03fd8 c076a956 c019bde8 c01002a0 c01002a0 000 [4294688.671000] f7f03fec c01002d5 007b 007b c0101365 [4294688.672000] [4294688.673000] Call Trace: [4294688.675000] [c0104bfa] show_stack+0x7a/0x90 [4294688.676000] [c0104d79] show_registers+0x149/0x1c0 [4294688.677000] [c0104fea] die+0x14a/0x2d0 [4294688.678000] [c011e3ee] do_page_fault+0x44e/0x633 [4294688.679000] [c01046e3] error_code+0x4f/0x54 [4294688.68] [c076a956] do_initcalls+0x56/0xc0 [4294688.681000] [c01002d5] init+0x35/0x110 [4294688.682000] [c0101365] kernel_thread_helper+0x5/0x10 [4294688.683000] Code: 83 ec 04 e8 3b 6b c0 ff ba 14 b77eth0: no IPv6 routers present Frank -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] [4294667.296000] Linux version 2.6.12-rc2-fs3 ([EMAIL PROTECTED]) (gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #3 Wed Apr 6 13:14:48 MDT 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: - 0009f000 (usable) [4294667.296000] BIOS-e820: 0009f000 - 000a (reserved) [4294667.296000] BIOS-e820: 0010 - 5ffae000 (usable) [4294667.296000] BIOS-e820: 5ffae000 - 6000 (reserved) [4294667.296000] BIOS-e820: feda - fee0 (reserved) [4294667.296000] BIOS-e820: ffb0 - 0001 (reserved) [4294667.296000] 639MB HIGHMEM available. [4294667.296000] 896MB LOWMEM available. [4294667.296000] DMI 2.3 present. [4294667.296000] ACPI: PM-Timer IO Port: 0x808 [4294667.296000] Allocating PCI resources starting at 6000 (gap: 6000:9eda) [4294667.296000] Built 1 zonelists [4294667.296000] Kernel command line: ro root=LABEL=/1 vga=794 nmi_watchdog=1 lapic console=tty0 console=ttyUSB0,9600 psmouse.proto=exps i8k.ignore_dmi:bool=true [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ single [4294667.296000] Unknown boot option `i8k.ignore_dmi:bool=true': ignoring [4294667.296000] netconsole: local port 6665 [4294667.296000] netconsole: local IP 128.187.171.101 [4294667.296000] netconsole: interface eth0 [4294667.296000] netconsole: remote port 5515[4294667.296000] netconsole: remote IP 128.187.171.102 [4294667.[4294667.296000] Console: colour dummy device 80x25 [4294667.298[4294667.472000] Capability LSM initialized as secondary [429466[4294667.472000] Checking 'hlt' instruction... OK. [4294667.4830[4294667.616000] checking if image is initramfs... it is [429466[4294667.75] Completing Region/Field/Buffer/Package initiali[4294667.881000] PCI: Transparent bridge - :00:1e.0 [4294667[4294668.309000] pnp: PnP ACPI: found 10 devices [4294668.31[4294668.534000] pnp: 00:01: ioport range 0x808-0x80f could not [4294668.607000] audit(1112798526.606:0): initialized [4294668.6[4294668.625000] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ [4294668.947000] * connector 1 of type 2 (CRT) : 2320 [4294668[4294671.384000] radeonfb: Monitor 1 type LCD found [4294671.384[4294671.384000] 320 x 400 [4294671.384000] 320 x 400 [4294671[4294671.384000] 1024 x 768 [4294671.384000] 1280 x 1024 [4294[4294671.384000] Setting up default mode based on panel info [42[4294671.492000] fb1: VESA VGA frame buffer device [4294671.4980[4294673.099000] agpgart: AGP aperture is 128M @ 0xe800 [429[4294673.156000] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ [4294673.205000] PPP generic driver version 2.4.2 [4294673.20800[4294676.218000] b44: eth0: Link is up at 100 Mbps, full duplex.[4294677.477000] ICH4: not 100% native mode: will probe irqs lat[4294682.079000] hda: cache flushes supported [4294682.081000] [4294682.253000] PCI: Enabling device :02:01.0 ( - 0002[4294682.646000] Badness in device_release at drivers/base/core.[4294682.657000] Databook TCIC-2 PCMCIA probe: not found. [42946[4294682.683000
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Torokhov wrote: > I have implemented arrays of groups of attributes: Works great here. The i8k-cumulative patch claimed to be malformed, but I merged it in just fine by hand. In arch/i386/kernel/dmi_scan.c, I had to EXPORT dmi_get_system_info in order to get the i8k module to load. That may have been a mistake on my end (lots of odd patches in my tree right now). I'm a little curious to see how many people are going to find they need the ignore_dmi flag versus working without it. Everything works great, and it is a big step up from the existing code. I say lets go with it. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCP1B7aI0dwg4A47wRAufNAJ9tJODed2rcndtytGCZbJHr5AQJPgCgqbA1 zWnRrePRdJ/+5K1yu5HM3jg= =OzaL -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Torokhov wrote: I have implemented arrays of groups of attributes: Works great here. The i8k-cumulative patch claimed to be malformed, but I merged it in just fine by hand. In arch/i386/kernel/dmi_scan.c, I had to EXPORT dmi_get_system_info in order to get the i8k module to load. That may have been a mistake on my end (lots of odd patches in my tree right now). I'm a little curious to see how many people are going to find they need the ignore_dmi flag versus working without it. Everything works great, and it is a big step up from the existing code. I say lets go with it. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCP1B7aI0dwg4A47wRAufNAJ9tJODed2rcndtytGCZbJHr5AQJPgCgqbA1 zWnRrePRdJ/+5K1yu5HM3jg= =OzaL -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Torokhov wrote: | Hrm, can we be a little more explicit and not poke in the sysfs guts right | in the driver? What do you think about the patch below athat implements | "attribute arrays"? And I am attaching cumulative i8k patch using these | arrays so they can be tested. Also, with power_status being a module parameter defaulting to 0/off, we can leave out the device_create_file for the i8k_power_status_attr. No need to expose it in sysfs if it will always return -EIO. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCOVHjaI0dwg4A47wRAgquAJ49qf5qFZX9twSbLetJiliEnES5GwCg41z2 r6AWC22/zAcz54xAIfNQJ4I= =0BtE -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
| Hrm, can we be a little more explicit and not poke in the sysfs guts right
| in the driver? What do you think about the patch below athat implements
| "attribute arrays"? And I am attaching cumulative i8k patch using these
| arrays so they can be tested.
|
| I am CC-ing Greg to see what he thinks about it.
Well, yes. That would probably be the better way to go about it, though
I have to admit I was somewhat pleased with myself that I came up with
something that worked. :)
Your patches work well, with a few minor notes:
1: My Inspiron 9200 (and perhaps others) doesn't seem to respond to the
I8K_SMM_BIOS_VERSION function call, so it fails the check in i8k_probe.
~ The check of i8k_get_bios_version doesn't seem critical, and removing
the return -ENODEV makes it work again for me. That's the current
behavior, so perhaps the printk level should just be changed to
KERN_WARNING rather than KERN_ALERT.
2: To compile 2.6.11 cleanly, I needed two hunks from your original
patch 2 (perhaps you're working from a more up-to-date tree than I am?
If so, these are probably already addressed.):
- --- dtor.orig/arch/i386/kernel/dmi_scan.c
+++ dtor/arch/i386/kernel/dmi_scan.c
@@ -416,6 +416,7 @@ static void __init dmi_decode(struct dmi
~ dmi_save_ident(dm, DMI_PRODUCT_VERSION, 6);
~ dmi_printk(("Serial Number: %s\n",
~ dmi_string(dm, data[7])));
+ dmi_save_ident(dm, DMI_PRODUCT_SERIAL, 7);
~ break;
~ case 2:
~ dmi_printk(("Board Vendor: %s\n",
- --- dtor.orig/include/linux/dmi.h
+++ dtor/include/linux/dmi.h
@@ -9,6 +9,7 @@ enum dmi_field {
~ DMI_SYS_VENDOR,
~ DMI_PRODUCT_NAME,
~ DMI_PRODUCT_VERSION,
+ DMI_PRODUCT_SERIAL,
~ DMI_BOARD_VENDOR,
~ DMI_BOARD_NAME,
~ DMI_BOARD_VERSION,
I also have a question about the structure created using sysfs attribute
arrays. Applying it in this case, I get:
./temp
./temp/3
./temp/2
./temp/1
./temp/0
./fan_speed
./fan_speed/1
./fan_speed/0
./fan_state
./fan_state/1
./fan_state/0
The 'temp' entries make sense, however I'm not sure about the fan_speed
and fan_state entries. From the perspective of how the objects are
ordered, a fan would have 'speed' and 'state' attributes, but a
'fan_state' attribute wouldn't normally have a fan. Maybe something
along these lines would make more sense from that perspective:
./fan/0
./fan/0/speed
./fan/0/state
./fan/1
./fan/1/speed
./fan/1/state
I'm not certain about the best way to do this, so this may just be a
thought. It would certainly be more complex to reorder it, and it
appears usable in its current form.
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFCOU/0aI0dwg4A47wRAjgDAJwLsvd14J/qAmgv7JzkXG2xgAmTGwCY6RUc
Nomk0pwTSfymHtIuF7ylzQ==
=85eA
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
| Hrm, can we be a little more explicit and not poke in the sysfs guts right
| in the driver? What do you think about the patch below athat implements
| attribute arrays? And I am attaching cumulative i8k patch using these
| arrays so they can be tested.
|
| I am CC-ing Greg to see what he thinks about it.
Well, yes. That would probably be the better way to go about it, though
I have to admit I was somewhat pleased with myself that I came up with
something that worked. :)
Your patches work well, with a few minor notes:
1: My Inspiron 9200 (and perhaps others) doesn't seem to respond to the
I8K_SMM_BIOS_VERSION function call, so it fails the check in i8k_probe.
~ The check of i8k_get_bios_version doesn't seem critical, and removing
the return -ENODEV makes it work again for me. That's the current
behavior, so perhaps the printk level should just be changed to
KERN_WARNING rather than KERN_ALERT.
2: To compile 2.6.11 cleanly, I needed two hunks from your original
patch 2 (perhaps you're working from a more up-to-date tree than I am?
If so, these are probably already addressed.):
- --- dtor.orig/arch/i386/kernel/dmi_scan.c
+++ dtor/arch/i386/kernel/dmi_scan.c
@@ -416,6 +416,7 @@ static void __init dmi_decode(struct dmi
~ dmi_save_ident(dm, DMI_PRODUCT_VERSION, 6);
~ dmi_printk((Serial Number: %s\n,
~ dmi_string(dm, data[7])));
+ dmi_save_ident(dm, DMI_PRODUCT_SERIAL, 7);
~ break;
~ case 2:
~ dmi_printk((Board Vendor: %s\n,
- --- dtor.orig/include/linux/dmi.h
+++ dtor/include/linux/dmi.h
@@ -9,6 +9,7 @@ enum dmi_field {
~ DMI_SYS_VENDOR,
~ DMI_PRODUCT_NAME,
~ DMI_PRODUCT_VERSION,
+ DMI_PRODUCT_SERIAL,
~ DMI_BOARD_VENDOR,
~ DMI_BOARD_NAME,
~ DMI_BOARD_VERSION,
I also have a question about the structure created using sysfs attribute
arrays. Applying it in this case, I get:
./temp
./temp/3
./temp/2
./temp/1
./temp/0
./fan_speed
./fan_speed/1
./fan_speed/0
./fan_state
./fan_state/1
./fan_state/0
The 'temp' entries make sense, however I'm not sure about the fan_speed
and fan_state entries. From the perspective of how the objects are
ordered, a fan would have 'speed' and 'state' attributes, but a
'fan_state' attribute wouldn't normally have a fan. Maybe something
along these lines would make more sense from that perspective:
./fan/0
./fan/0/speed
./fan/0/state
./fan/1
./fan/1/speed
./fan/1/state
I'm not certain about the best way to do this, so this may just be a
thought. It would certainly be more complex to reorder it, and it
appears usable in its current form.
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD4DBQFCOU/0aI0dwg4A47wRAjgDAJwLsvd14J/qAmgv7JzkXG2xgAmTGwCY6RUc
Nomk0pwTSfymHtIuF7ylzQ==
=85eA
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
Okay, I replaced the sysfs_ops with ops of my own, and now all the show
and store functions also accept the name of the attribute as a parameter.
This lets the functions know what attribute is being accessed, and allows
us to create attributes that share show and store functions, so things
don't need to be defined at compile time (I feel slightly evil!).
This patch puts the correct number of temp sensors and fans into sysfs,
and only exposes power_status if enabled by the power_status module
parameter.
This patch applies on top of Dmitry Torokov's patches. Comments welcome!
Thanks,
Frank
Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]>
--- 2.6.11-a/drivers/char/i8k.c 2005-03-12 18:47:55.0 -0700
+++ 2.6.11-b/drivers/char/i8k.c 2005-03-16 14:23:40.0 -0700
@@ -23,12 +23,14 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
-#define I8K_VERSION"1.14 21/02/2005"
+#define I8K_VERSION"2005-03-16"
#define I8K_SMM_FN_STATUS 0x0025
#define I8K_SMM_POWER_STATUS 0x0069
@@ -36,7 +38,8 @@
#define I8K_SMM_GET_FAN0x00a3
#define I8K_SMM_GET_SPEED 0x02a3
#define I8K_SMM_GET_TEMP 0x10a3
-#define I8K_SMM_GET_DELL_SIG 0xffa3
+#define I8K_SMM_GET_DELL_SIG1 0xfea3
+#define I8K_SMM_GET_DELL_SIG2 0xffa3
#define I8K_SMM_BIOS_VERSION 0x00a6
#define I8K_FAN_MULT 30
@@ -54,7 +57,12 @@
#define I8K_TEMPERATURE_BUG1
+#define to_dev(d) container_of(d, struct device, kobj)
+#define to_dev_attr(_attr) container_of(_attr,struct device_attribute,attr)
+
static char bios_version[4];
+static int num_temps = 0;
+static int num_fans = 0;
MODULE_AUTHOR("Massimo Dal Zotto ([EMAIL PROTECTED])");
MODULE_DESCRIPTION("Driver for accessing SMM BIOS on Dell laptops");
@@ -80,6 +88,8 @@
static int i8k_ioctl(struct inode *, struct file *, unsigned int,
unsigned long);
+static struct kobj_type *backup_ktype;
+
static struct file_operations i8k_fops = {
.open = i8k_open_fs,
.read = seq_read,
@@ -94,7 +104,7 @@
};
static struct platform_device *i8k_device;
-
+
struct smm_regs {
unsigned int eax;
unsigned int ebx __attribute__ ((packed));
@@ -156,7 +166,7 @@
{
struct smm_regs regs = { .eax = I8K_SMM_BIOS_VERSION, };
- return i8k_smm() < 0 ? : regs.eax;
+ return i8k_smm() ? : regs.eax;
}
/*
@@ -201,10 +211,10 @@
*/
static int i8k_get_fan_status(int fan)
{
- struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, .ebx = (fan & 0xff)};
regs.ebx = fan & 0xff;
- return i8k_smm() < 0 ? : regs.eax & 0xff;
+ return i8k_smm() ? : regs.eax & 0xff;
}
/*
@@ -215,7 +225,7 @@
struct smm_regs regs = { .eax = I8K_SMM_GET_SPEED, };
regs.ebx = fan & 0xff;
- return i8k_smm() < 0 ? : (regs.eax & 0x) * I8K_FAN_MULT;
+ return i8k_smm() ? : (regs.eax & 0x) * I8K_FAN_MULT;
}
/*
@@ -228,15 +238,15 @@
speed = (speed < 0) ? 0 : ((speed > I8K_FAN_MAX) ? I8K_FAN_MAX : speed);
regs.ebx = (fan & 0xff) | (speed << 8);
- return i8k_smm() < 0 ? : i8k_get_fan_status(fan);
+ return i8k_smm() ? : i8k_get_fan_status(fan);
}
/*
* Read the cpu temperature.
*/
-static int i8k_get_cpu_temp(void)
+static int i8k_get_temp(int sensor)
{
- struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, .ebx = sensor };
int rc;
int temp;
@@ -268,9 +278,14 @@
return temp;
}
-static int i8k_get_dell_signature(void)
+static int i8k_get_cpu_temp(void)
{
- struct smm_regs regs = { .eax = I8K_SMM_GET_DELL_SIG, };
+ return i8k_get_temp(0);
+}
+
+static int i8k_get_dell_sig_aux(int fn)
+{
+ struct smm_regs regs = { .eax = fn, };
int rc;
if ((rc = i8k_smm()) < 0)
@@ -279,6 +294,17 @@
return regs.eax == 1145651527 && regs.edx == 1145392204 ? 0 : -1;
}
+static int i8k_get_dell_signature(void)
+{
+ int rc;
+
+ if (((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG1)) < 0) &&
+ ((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG2)) < 0)) {
+ return rc;
+ }
+ return 0;
+}
+
static int i8k_ioctl(struct inode *ip, struct file *fp, unsigned int cmd,
unsigned long arg)
{
@@ -414,87 +440,112 @@
return single_open(file, i8k_proc_show, NULL);
}
-static ssize_t i8k_sysfs_cpu_temp_show(struct device *dev, char *buf)
+static ssize_t i8k_sysfs_cpu_temp_show(struct device *dev, char *buf,
+ const char *name)
{
int temp = i8k_get_cpu_temp();
return temp < 0 ? -EIO : sprintf(buf, "%d\n", temp
Re: [PATCH 0/5] I8K driver facelift
Okay, I replaced the sysfs_ops with ops of my own, and now all the show
and store functions also accept the name of the attribute as a parameter.
This lets the functions know what attribute is being accessed, and allows
us to create attributes that share show and store functions, so things
don't need to be defined at compile time (I feel slightly evil!).
This patch puts the correct number of temp sensors and fans into sysfs,
and only exposes power_status if enabled by the power_status module
parameter.
This patch applies on top of Dmitry Torokov's patches. Comments welcome!
Thanks,
Frank
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
--- 2.6.11-a/drivers/char/i8k.c 2005-03-12 18:47:55.0 -0700
+++ 2.6.11-b/drivers/char/i8k.c 2005-03-16 14:23:40.0 -0700
@@ -23,12 +23,14 @@
#include linux/seq_file.h
#include linux/dmi.h
#include linux/device.h
+#include linux/sysfs.h
+#include linux/kobject.h
#include asm/uaccess.h
#include asm/io.h
#include linux/i8k.h
-#define I8K_VERSION1.14 21/02/2005
+#define I8K_VERSION2005-03-16
#define I8K_SMM_FN_STATUS 0x0025
#define I8K_SMM_POWER_STATUS 0x0069
@@ -36,7 +38,8 @@
#define I8K_SMM_GET_FAN0x00a3
#define I8K_SMM_GET_SPEED 0x02a3
#define I8K_SMM_GET_TEMP 0x10a3
-#define I8K_SMM_GET_DELL_SIG 0xffa3
+#define I8K_SMM_GET_DELL_SIG1 0xfea3
+#define I8K_SMM_GET_DELL_SIG2 0xffa3
#define I8K_SMM_BIOS_VERSION 0x00a6
#define I8K_FAN_MULT 30
@@ -54,7 +57,12 @@
#define I8K_TEMPERATURE_BUG1
+#define to_dev(d) container_of(d, struct device, kobj)
+#define to_dev_attr(_attr) container_of(_attr,struct device_attribute,attr)
+
static char bios_version[4];
+static int num_temps = 0;
+static int num_fans = 0;
MODULE_AUTHOR(Massimo Dal Zotto ([EMAIL PROTECTED]));
MODULE_DESCRIPTION(Driver for accessing SMM BIOS on Dell laptops);
@@ -80,6 +88,8 @@
static int i8k_ioctl(struct inode *, struct file *, unsigned int,
unsigned long);
+static struct kobj_type *backup_ktype;
+
static struct file_operations i8k_fops = {
.open = i8k_open_fs,
.read = seq_read,
@@ -94,7 +104,7 @@
};
static struct platform_device *i8k_device;
-
+
struct smm_regs {
unsigned int eax;
unsigned int ebx __attribute__ ((packed));
@@ -156,7 +166,7 @@
{
struct smm_regs regs = { .eax = I8K_SMM_BIOS_VERSION, };
- return i8k_smm(regs) 0 ? : regs.eax;
+ return i8k_smm(regs) ? : regs.eax;
}
/*
@@ -201,10 +211,10 @@
*/
static int i8k_get_fan_status(int fan)
{
- struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, .ebx = (fan 0xff)};
regs.ebx = fan 0xff;
- return i8k_smm(regs) 0 ? : regs.eax 0xff;
+ return i8k_smm(regs) ? : regs.eax 0xff;
}
/*
@@ -215,7 +225,7 @@
struct smm_regs regs = { .eax = I8K_SMM_GET_SPEED, };
regs.ebx = fan 0xff;
- return i8k_smm(regs) 0 ? : (regs.eax 0x) * I8K_FAN_MULT;
+ return i8k_smm(regs) ? : (regs.eax 0x) * I8K_FAN_MULT;
}
/*
@@ -228,15 +238,15 @@
speed = (speed 0) ? 0 : ((speed I8K_FAN_MAX) ? I8K_FAN_MAX : speed);
regs.ebx = (fan 0xff) | (speed 8);
- return i8k_smm(regs) 0 ? : i8k_get_fan_status(fan);
+ return i8k_smm(regs) ? : i8k_get_fan_status(fan);
}
/*
* Read the cpu temperature.
*/
-static int i8k_get_cpu_temp(void)
+static int i8k_get_temp(int sensor)
{
- struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, .ebx = sensor };
int rc;
int temp;
@@ -268,9 +278,14 @@
return temp;
}
-static int i8k_get_dell_signature(void)
+static int i8k_get_cpu_temp(void)
{
- struct smm_regs regs = { .eax = I8K_SMM_GET_DELL_SIG, };
+ return i8k_get_temp(0);
+}
+
+static int i8k_get_dell_sig_aux(int fn)
+{
+ struct smm_regs regs = { .eax = fn, };
int rc;
if ((rc = i8k_smm(regs)) 0)
@@ -279,6 +294,17 @@
return regs.eax == 1145651527 regs.edx == 1145392204 ? 0 : -1;
}
+static int i8k_get_dell_signature(void)
+{
+ int rc;
+
+ if (((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG1)) 0)
+ ((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG2)) 0)) {
+ return rc;
+ }
+ return 0;
+}
+
static int i8k_ioctl(struct inode *ip, struct file *fp, unsigned int cmd,
unsigned long arg)
{
@@ -414,87 +440,112 @@
return single_open(file, i8k_proc_show, NULL);
}
-static ssize_t i8k_sysfs_cpu_temp_show(struct device *dev, char *buf)
+static ssize_t i8k_sysfs_cpu_temp_show(struct device *dev, char *buf,
+ const char *name)
{
int temp = i8k_get_cpu_temp();
return temp 0 ? -EIO : sprintf(buf, %d\n, temp);
}
-static ssize_t i8k_sysfs_fan1_show(struct
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > Well, (a) the next rev of the patch will hopefully provide more access to the > second thermal probe than just detecting its existence (it still doesn't do > the sysfs or whatever magic to make the actual value accessible), and (b) the > probe I *know* about is on the CPU, and runs over 40C easily as well (it's > sitting > at 49C right now). Remember we're talking about a laptop here, there's not > a lot of room for a big heat sink in there.. ;) I've been trying to work out how to do this through dynamic sysfs attributes, but I have not found a way to create arbitrary attributes like this. It's not hard to define them at kernel compile time, but selecting the right number of sensors to compile in seems arbitrary. My Inspiron 9200 has 4 sensors, and who knows how many next year's model will have. It just doesn't seem like the Linux Kernel way of doing things to arbitrarily limit it like this. I've looked into several ways of creating sysfs attributes, but haven't found anything that works right/well. One of the most interesting was in this past LKML thread - http://lkml.org/lkml/2004/8/20/287 If I could replace the sysfs_attr_show() with my own, I believe that might work (the attribute is passed into the function, so the name should be available). It's odd that it's so easy to compile sysfs attributes into the kernel, but nobody seems to know how to generate them dynamically. Thoughts? Suggestions? Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCN2LeaI0dwg4A47wRAhWEAKC+CcoLmoyvS6RXy7n7gtTnKjPXsACgtCbE zofgMMEmc5mAzrQKdKwpIMQ= =xNOU -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Well, (a) the next rev of the patch will hopefully provide more access to the second thermal probe than just detecting its existence (it still doesn't do the sysfs or whatever magic to make the actual value accessible), and (b) the probe I *know* about is on the CPU, and runs over 40C easily as well (it's sitting at 49C right now). Remember we're talking about a laptop here, there's not a lot of room for a big heat sink in there.. ;) I've been trying to work out how to do this through dynamic sysfs attributes, but I have not found a way to create arbitrary attributes like this. It's not hard to define them at kernel compile time, but selecting the right number of sensors to compile in seems arbitrary. My Inspiron 9200 has 4 sensors, and who knows how many next year's model will have. It just doesn't seem like the Linux Kernel way of doing things to arbitrarily limit it like this. I've looked into several ways of creating sysfs attributes, but haven't found anything that works right/well. One of the most interesting was in this past LKML thread - http://lkml.org/lkml/2004/8/20/287 If I could replace the sysfs_attr_show() with my own, I believe that might work (the attribute is passed into the function, so the name should be available). It's odd that it's so easy to compile sysfs attributes into the kernel, but nobody seems to know how to generate them dynamically. Thoughts? Suggestions? Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCN2LeaI0dwg4A47wRAhWEAKC+CcoLmoyvS6RXy7n7gtTnKjPXsACgtCbE zofgMMEmc5mAzrQKdKwpIMQ= =xNOU -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
| Hi,
|
| here are some changes that freshen I8K driver (Dell Inspiron/Latitude
| platform driver). The patches have been tested on Inspiron 8100.
| Please consider for inclusion.
|
| Thanks!
These patches look pretty good. A few comments (with a patch--tested on
my Inspiron 9200):
- - The "return i8k_smm() < 0 ? : regs.eax;" construction is nice and
tidy, but it isn't passing on the return value of the called function,
and is returning TRUE or 1 on failure. This makes it difficult to check
the return value for valid data. Old behavior returned negative, so
I'll return -1.
- - The I8K_VERSION string should probably be changed to something more
unique. The version maintained outside the kernel tree by Massimo Dal
Zotto (http://www.debian.org/~dz/i8k/) is up to 1.25, so 1.14 isn't very
distinguishing. Maybe just use the date? Not sure here...
- - Also, some newer Dell laptops require a different function to get the
Dell signature, so the i8k_get_dell_signature test should check both
(borrowing some code from the out-of-kernel version).
- - Some newer Dell laptops report DMI_SYS_VENDOR as "Dell Inc." rather
than "Dell Computer"
- - Some of the Dell motherboards provide more than 1 temperature sensor.
~ How about a generic i8k_get_temp function, and i8k_get_cpu_temp just
calls that with sensor 0.
- - Also, I've added detection of the number of temperature sensors and
fans at init time. This way, we aren't hardcoded to 1 sensor and 2
fans. I couldn't figure out how to set up the sysfs entries
dynamically, but that probably should happen too.
- - Some boards don't need the I8K_FAN_MULT to get the right fan RPM (I
don't think my fans are rotating at over 90,000 RPM)! I guess we'll
need to address this sometime, but I have not done so.
Patch follows:
Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]>
- --- 2.6.11-a/drivers/char/i8k.c 2005-03-12 18:47:55.0 -0700
+++ 2.6.11-b/drivers/char/i8k.c 2005-03-12 20:29:01.0 -0700
@@ -28,7 +28,7 @@
~ #include
- -#define I8K_VERSION "1.14 21/02/2005"
+#define I8K_VERSION"2005-03-12"
~ #define I8K_SMM_FN_STATUS 0x0025
~ #define I8K_SMM_POWER_STATUS 0x0069
@@ -36,7 +36,8 @@
~ #define I8K_SMM_GET_FAN 0x00a3
~ #define I8K_SMM_GET_SPEED 0x02a3
~ #define I8K_SMM_GET_TEMP 0x10a3
- -#define I8K_SMM_GET_DELL_SIG 0xffa3
+#define I8K_SMM_GET_DELL_SIG1 0xfea3
+#define I8K_SMM_GET_DELL_SIG2 0xffa3
~ #define I8K_SMM_BIOS_VERSION 0x00a6
~ #define I8K_FAN_MULT 30
@@ -55,6 +56,8 @@
~ #define I8K_TEMPERATURE_BUG 1
~ static char bios_version[4];
+static int num_temps = 0;
+static int num_fans = 0;
~ MODULE_AUTHOR("Massimo Dal Zotto ([EMAIL PROTECTED])");
~ MODULE_DESCRIPTION("Driver for accessing SMM BIOS on Dell laptops");
@@ -201,10 +204,10 @@
~ */
~ static int i8k_get_fan_status(int fan)
~ {
- - struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, .ebx = (fan & 0xff)};
~ regs.ebx = fan & 0xff;
- - return i8k_smm() < 0 ? : regs.eax & 0xff;
+ return i8k_smm() < 0 ? -1 : regs.eax & 0xff;
~ }
~ /*
@@ -215,7 +218,7 @@
~ struct smm_regs regs = { .eax = I8K_SMM_GET_SPEED, };
~ regs.ebx = fan & 0xff;
- - return i8k_smm() < 0 ? : (regs.eax & 0x) * I8K_FAN_MULT;
+ return i8k_smm() < 0 ? -1 : (regs.eax & 0x) * I8K_FAN_MULT;
~ }
~ /*
@@ -228,15 +231,15 @@
~ speed = (speed < 0) ? 0 : ((speed > I8K_FAN_MAX) ? I8K_FAN_MAX : speed);
~ regs.ebx = (fan & 0xff) | (speed << 8);
- - return i8k_smm() < 0 ? : i8k_get_fan_status(fan);
+ return i8k_smm() < 0 ? -1 : i8k_get_fan_status(fan);
~ }
~ /*
~ * Read the cpu temperature.
~ */
- -static int i8k_get_cpu_temp(void)
+static int i8k_get_temp(int sensor)
~ {
- - struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, .ebx = sensor };
~ int rc;
~ int temp;
@@ -268,9 +271,14 @@
~ return temp;
~ }
- -static int i8k_get_dell_signature(void)
+static int i8k_get_cpu_temp(void)
+{
+ return i8k_get_temp(0);
+}
+
+static int i8k_get_dell_sig_aux(int fn)
~ {
- - struct smm_regs regs = { .eax = I8K_SMM_GET_DELL_SIG, };
+ struct smm_regs regs = { .eax = fn, };
~ int rc;
~ if ((rc = i8k_smm()) < 0)
@@ -279,6 +287,17 @@
~ return regs.eax == 1145651527 && regs.edx == 1145392204 ? 0 : -1;
~ }
+static int i8k_get_dell_signature(void)
+{
+ int rc;
+
+ if (((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG1)) < 0) &&
+ ((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG2)) < 0)) {
+ return rc;
+ }
+ return 0;
+}
+
~ static int i8k_ioctl(struct inode *ip, struct file *
Re: [PATCH 0/5] I8K driver facelift
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
| Hi,
|
| here are some changes that freshen I8K driver (Dell Inspiron/Latitude
| platform driver). The patches have been tested on Inspiron 8100.
snip
| Please consider for inclusion.
|
| Thanks!
These patches look pretty good. A few comments (with a patch--tested on
my Inspiron 9200):
- - The return i8k_smm(regs) 0 ? : regs.eax; construction is nice and
tidy, but it isn't passing on the return value of the called function,
and is returning TRUE or 1 on failure. This makes it difficult to check
the return value for valid data. Old behavior returned negative, so
I'll return -1.
- - The I8K_VERSION string should probably be changed to something more
unique. The version maintained outside the kernel tree by Massimo Dal
Zotto (http://www.debian.org/~dz/i8k/) is up to 1.25, so 1.14 isn't very
distinguishing. Maybe just use the date? Not sure here...
- - Also, some newer Dell laptops require a different function to get the
Dell signature, so the i8k_get_dell_signature test should check both
(borrowing some code from the out-of-kernel version).
- - Some newer Dell laptops report DMI_SYS_VENDOR as Dell Inc. rather
than Dell Computer
- - Some of the Dell motherboards provide more than 1 temperature sensor.
~ How about a generic i8k_get_temp function, and i8k_get_cpu_temp just
calls that with sensor 0.
- - Also, I've added detection of the number of temperature sensors and
fans at init time. This way, we aren't hardcoded to 1 sensor and 2
fans. I couldn't figure out how to set up the sysfs entries
dynamically, but that probably should happen too.
- - Some boards don't need the I8K_FAN_MULT to get the right fan RPM (I
don't think my fans are rotating at over 90,000 RPM)! I guess we'll
need to address this sometime, but I have not done so.
Patch follows:
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
- --- 2.6.11-a/drivers/char/i8k.c 2005-03-12 18:47:55.0 -0700
+++ 2.6.11-b/drivers/char/i8k.c 2005-03-12 20:29:01.0 -0700
@@ -28,7 +28,7 @@
~ #include linux/i8k.h
- -#define I8K_VERSION 1.14 21/02/2005
+#define I8K_VERSION2005-03-12
~ #define I8K_SMM_FN_STATUS 0x0025
~ #define I8K_SMM_POWER_STATUS 0x0069
@@ -36,7 +36,8 @@
~ #define I8K_SMM_GET_FAN 0x00a3
~ #define I8K_SMM_GET_SPEED 0x02a3
~ #define I8K_SMM_GET_TEMP 0x10a3
- -#define I8K_SMM_GET_DELL_SIG 0xffa3
+#define I8K_SMM_GET_DELL_SIG1 0xfea3
+#define I8K_SMM_GET_DELL_SIG2 0xffa3
~ #define I8K_SMM_BIOS_VERSION 0x00a6
~ #define I8K_FAN_MULT 30
@@ -55,6 +56,8 @@
~ #define I8K_TEMPERATURE_BUG 1
~ static char bios_version[4];
+static int num_temps = 0;
+static int num_fans = 0;
~ MODULE_AUTHOR(Massimo Dal Zotto ([EMAIL PROTECTED]));
~ MODULE_DESCRIPTION(Driver for accessing SMM BIOS on Dell laptops);
@@ -201,10 +204,10 @@
~ */
~ static int i8k_get_fan_status(int fan)
~ {
- - struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_FAN, .ebx = (fan 0xff)};
~ regs.ebx = fan 0xff;
- - return i8k_smm(regs) 0 ? : regs.eax 0xff;
+ return i8k_smm(regs) 0 ? -1 : regs.eax 0xff;
~ }
~ /*
@@ -215,7 +218,7 @@
~ struct smm_regs regs = { .eax = I8K_SMM_GET_SPEED, };
~ regs.ebx = fan 0xff;
- - return i8k_smm(regs) 0 ? : (regs.eax 0x) * I8K_FAN_MULT;
+ return i8k_smm(regs) 0 ? -1 : (regs.eax 0x) * I8K_FAN_MULT;
~ }
~ /*
@@ -228,15 +231,15 @@
~ speed = (speed 0) ? 0 : ((speed I8K_FAN_MAX) ? I8K_FAN_MAX : speed);
~ regs.ebx = (fan 0xff) | (speed 8);
- - return i8k_smm(regs) 0 ? : i8k_get_fan_status(fan);
+ return i8k_smm(regs) 0 ? -1 : i8k_get_fan_status(fan);
~ }
~ /*
~ * Read the cpu temperature.
~ */
- -static int i8k_get_cpu_temp(void)
+static int i8k_get_temp(int sensor)
~ {
- - struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, };
+ struct smm_regs regs = { .eax = I8K_SMM_GET_TEMP, .ebx = sensor };
~ int rc;
~ int temp;
@@ -268,9 +271,14 @@
~ return temp;
~ }
- -static int i8k_get_dell_signature(void)
+static int i8k_get_cpu_temp(void)
+{
+ return i8k_get_temp(0);
+}
+
+static int i8k_get_dell_sig_aux(int fn)
~ {
- - struct smm_regs regs = { .eax = I8K_SMM_GET_DELL_SIG, };
+ struct smm_regs regs = { .eax = fn, };
~ int rc;
~ if ((rc = i8k_smm(regs)) 0)
@@ -279,6 +287,17 @@
~ return regs.eax == 1145651527 regs.edx == 1145392204 ? 0 : -1;
~ }
+static int i8k_get_dell_signature(void)
+{
+ int rc;
+
+ if (((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG1)) 0)
+ ((rc=i8k_get_dell_sig_aux(I8K_SMM_GET_DELL_SIG2)) 0)) {
+ return rc;
+ }
+ return 0;
+}
+
~ static int i8k_ioctl(struct inode *ip, struct file *fp, unsigned int cmd,
~unsigned long arg)
~ {
@@ -506,6 +525,13 @@
~ },
~ },
~ {
+ .ident = Dell Inspiron
Re: [uml-devel] [patch] Make User Mode Linux compile in 2.6.11-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Landley wrote: | As of yesterday afternoon, the UML build still breaks in sys_call_table.c, | here's the patch I submitted earlier (which got me past the break when I | tried it). Last week, this produced what seemed like a working UML. | | Now there's a second break in mm/memory.c: the move to four level page | tables conflicts with a stub in our headers. Not quite sure how to fix that. | Jeff? | | (Yeah, I know Andrew's tree works. But wouldn't it be nice if the kernel.org | tree to worked too, before 2.6.11 release.) This patch for sys_call_table.c was merged into the main tree in this changeset: http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED] The patch fixes both the sys_call_table and the pud_alloc breakage, and as of 2.6.11-rc3-bk2, the main tree compiles again for UML. Andrew's tree, however, (at least 2.6.11-rc3-mm1) requires the patch I sent out yesterday in the message titled "Fix compilation of UML after the stack-randomization patches." Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCBQlRaI0dwg4A47wRAjJ8AJ9CKD/aXaz1TS9QfOO11vcsv+57BACg1CdJ GR0ukCKAabFtJs5rVsPItGg= =h/on -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [patch] Make User Mode Linux compile in 2.6.11-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Landley wrote: | As of yesterday afternoon, the UML build still breaks in sys_call_table.c, | here's the patch I submitted earlier (which got me past the break when I | tried it). Last week, this produced what seemed like a working UML. | | Now there's a second break in mm/memory.c: the move to four level page | tables conflicts with a stub in our headers. Not quite sure how to fix that. | Jeff? | | (Yeah, I know Andrew's tree works. But wouldn't it be nice if the kernel.org | tree to worked too, before 2.6.11 release.) This patch for sys_call_table.c was merged into the main tree in this changeset: http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED] The patch fixes both the sys_call_table and the pud_alloc breakage, and as of 2.6.11-rc3-bk2, the main tree compiles again for UML. Andrew's tree, however, (at least 2.6.11-rc3-mm1) requires the patch I sent out yesterday in the message titled Fix compilation of UML after the stack-randomization patches. Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCBQlRaI0dwg4A47wRAjJ8AJ9CKD/aXaz1TS9QfOO11vcsv+57BACg1CdJ GR0ukCKAabFtJs5rVsPItGg= =h/on -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fix compilation of UML after the stack-randomization patches
The stack randomization patches that went into 2.6.11-rc3-mm1 broke
compilation of ARCH=um. This patch fixes compiling by adding
arch_align_stack back in.
Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]>
Acked-By: Jeff Dike <[EMAIL PROTECTED]>
Frank
--
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
diff -Naur linux-2.6.11-rc3-mm1_bak/arch/um/kernel/process_kern.c
linux-2.6.11-rc3-mm1/arch/um/kernel/process_kern.c
--- linux-2.6.11-rc3-mm1_bak/arch/um/kernel/process_kern.c 2005-02-04
12:09:03.0 -0700
+++ linux-2.6.11-rc3-mm1/arch/um/kernel/process_kern.c 2005-02-04
12:16:59.0 -0700
@@ -21,6 +21,7 @@
#include "linux/spinlock.h"
#include "linux/proc_fs.h"
#include "linux/ptrace.h"
+#include "linux/random.h"
#include "asm/unistd.h"
#include "asm/mman.h"
#include "asm/segment.h"
@@ -479,6 +480,14 @@
return 2;
}
+unsigned long arch_align_stack(unsigned long sp)
+{
+ if (randomize_va_space)
+ sp -= get_random_int() % 8192;
+ return sp & ~0xf;
+}
+
+
/*
* Overrides for Emacs so that we follow Linus's tabbing style.
* Emacs will notice this stuff at the end of the file and automatically
Fix compilation of UML after the stack-randomization patches
The stack randomization patches that went into 2.6.11-rc3-mm1 broke
compilation of ARCH=um. This patch fixes compiling by adding
arch_align_stack back in.
Signed-off-by: Frank Sorenson [EMAIL PROTECTED]
Acked-By: Jeff Dike [EMAIL PROTECTED]
Frank
--
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
[EMAIL PROTECTED]
diff -Naur linux-2.6.11-rc3-mm1_bak/arch/um/kernel/process_kern.c
linux-2.6.11-rc3-mm1/arch/um/kernel/process_kern.c
--- linux-2.6.11-rc3-mm1_bak/arch/um/kernel/process_kern.c 2005-02-04
12:09:03.0 -0700
+++ linux-2.6.11-rc3-mm1/arch/um/kernel/process_kern.c 2005-02-04
12:16:59.0 -0700
@@ -21,6 +21,7 @@
#include linux/spinlock.h
#include linux/proc_fs.h
#include linux/ptrace.h
+#include linux/random.h
#include asm/unistd.h
#include asm/mman.h
#include asm/segment.h
@@ -479,6 +480,14 @@
return 2;
}
+unsigned long arch_align_stack(unsigned long sp)
+{
+ if (randomize_va_space)
+ sp -= get_random_int() % 8192;
+ return sp ~0xf;
+}
+
+
/*
* Overrides for Emacs so that we follow Linus's tabbing style.
* Emacs will notice this stuff at the end of the file and automatically
