[PATCH] add default mode CONFIG_EDD_OFF=n, override with edd={on,off}
Andrew, please add to -mm and forward during the the 2.6.27 merge window.
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
>From 5c8fa0705c7f55ec5ae1b7da874029fe2000c595 Mon Sep 17 00:00:00 2001
From: Tim Gardner <[EMAIL PROTECTED]>
Date: Fri, 22 Feb 2008 06:59:39 -0700
Subject: [PATCH] add default mode CONFIG_EDD_OFF=n, override with edd={on,off}
UBUNTU: Implemented default EDD control
OriginalAuthor: Tim Gardner <[EMAIL PROTECTED]>
Add a kernel parameter option to 'edd' to enable/disable BIOS Enhanced Disk
Drive Services.
CONFIG_EDD_OFF disables EDD while still compiling EDD into the kernel. Default
behavior can be forced using 'edd=on' or 'edd=off' as a kernel parameter.
Signed-off-by: Tim Gardner <[EMAIL PROTECTED]>
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |3 +--
arch/x86/boot/edd.c | 10 +-
drivers/firmware/Kconfig|9 +
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9a5b665..3e6f0f5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -625,8 +625,7 @@ and is between 256 and 4096 characters. It is defined in
the file
eata= [HW,SCSI]
edd=[EDD]
- Format: {"of[f]" | "sk[ipmbr]"}
- See comment in arch/i386/boot/edd.S
+ Format: {"off" | "on" | "sk[ipmbr]"}
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
diff --git a/arch/x86/boot/edd.c b/arch/x86/boot/edd.c
index 8721dc4..4191805 100644
--- a/arch/x86/boot/edd.c
+++ b/arch/x86/boot/edd.c
@@ -128,17 +128,25 @@ void query_edd(void)
{
char eddarg[8];
int do_mbr = 1;
+#ifdef CONFIG_EDD_OFF
+ int do_edd = 0;
+#else
int do_edd = 1;
+#endif
int be_quiet;
int devno;
struct edd_info ei, *edp;
u32 *mbrptr;
if (cmdline_find_option("edd", eddarg, sizeof eddarg) > 0) {
- if (!strcmp(eddarg, "skipmbr") || !strcmp(eddarg, "skip"))
+ if (!strcmp(eddarg, "skipmbr") || !strcmp(eddarg, "skip")) {
+ do_edd = 1;
do_mbr = 0;
+ }
else if (!strcmp(eddarg, "off"))
do_edd = 0;
+ else if (!strcmp(eddarg, "on"))
+ do_edd = 1;
}
be_quiet = cmdline_find_option_bool("quiet");
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 05f02a3..c28e33f 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -17,6 +17,15 @@ config EDD
obscure configurations. Most disk controller BIOS vendors do
not yet implement this feature.
+config EDD_OFF
+ bool "Sets default behavior for EDD detection to off"
+ depends on EDD
+ default n
+ help
+ Say Y if you want EDD disabled by default, even though it is compiled
into the
+ kernel. Say N if you want EDD enabled by default. EDD can be
dynamically set
+ using the kernel parameter 'edd={on|skipmbr|off}'.
+
config EFI_VARS
tristate "EFI Variable Support via sysfs"
depends on EFI
--
1.5.4.1
--
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] add default mode CONFIG_EDD_OFF=n, override with edd={on,off}
Andrew, please add to -mm and forward during the the 2.6.27 merge window.
Thanks,
Matt
--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com www.dell.com/linux
From 5c8fa0705c7f55ec5ae1b7da874029fe2000c595 Mon Sep 17 00:00:00 2001
From: Tim Gardner [EMAIL PROTECTED]
Date: Fri, 22 Feb 2008 06:59:39 -0700
Subject: [PATCH] add default mode CONFIG_EDD_OFF=n, override with edd={on,off}
UBUNTU: Implemented default EDD control
OriginalAuthor: Tim Gardner [EMAIL PROTECTED]
Add a kernel parameter option to 'edd' to enable/disable BIOS Enhanced Disk
Drive Services.
CONFIG_EDD_OFF disables EDD while still compiling EDD into the kernel. Default
behavior can be forced using 'edd=on' or 'edd=off' as a kernel parameter.
Signed-off-by: Tim Gardner [EMAIL PROTECTED]
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |3 +--
arch/x86/boot/edd.c | 10 +-
drivers/firmware/Kconfig|9 +
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9a5b665..3e6f0f5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -625,8 +625,7 @@ and is between 256 and 4096 characters. It is defined in
the file
eata= [HW,SCSI]
edd=[EDD]
- Format: {of[f] | sk[ipmbr]}
- See comment in arch/i386/boot/edd.S
+ Format: {off | on | sk[ipmbr]}
eisa_irq_edge= [PARISC,HW]
See header of drivers/parisc/eisa.c.
diff --git a/arch/x86/boot/edd.c b/arch/x86/boot/edd.c
index 8721dc4..4191805 100644
--- a/arch/x86/boot/edd.c
+++ b/arch/x86/boot/edd.c
@@ -128,17 +128,25 @@ void query_edd(void)
{
char eddarg[8];
int do_mbr = 1;
+#ifdef CONFIG_EDD_OFF
+ int do_edd = 0;
+#else
int do_edd = 1;
+#endif
int be_quiet;
int devno;
struct edd_info ei, *edp;
u32 *mbrptr;
if (cmdline_find_option(edd, eddarg, sizeof eddarg) 0) {
- if (!strcmp(eddarg, skipmbr) || !strcmp(eddarg, skip))
+ if (!strcmp(eddarg, skipmbr) || !strcmp(eddarg, skip)) {
+ do_edd = 1;
do_mbr = 0;
+ }
else if (!strcmp(eddarg, off))
do_edd = 0;
+ else if (!strcmp(eddarg, on))
+ do_edd = 1;
}
be_quiet = cmdline_find_option_bool(quiet);
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 05f02a3..c28e33f 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -17,6 +17,15 @@ config EDD
obscure configurations. Most disk controller BIOS vendors do
not yet implement this feature.
+config EDD_OFF
+ bool Sets default behavior for EDD detection to off
+ depends on EDD
+ default n
+ help
+ Say Y if you want EDD disabled by default, even though it is compiled
into the
+ kernel. Say N if you want EDD enabled by default. EDD can be
dynamically set
+ using the kernel parameter 'edd={on|skipmbr|off}'.
+
config EFI_VARS
tristate EFI Variable Support via sysfs
depends on EFI
--
1.5.4.1
--
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: [Openipmi-developer] [PATCH 3/4] IPMI: convert locked counters to atomics
On Thu, Feb 14, 2008 at 12:30:51PM -0600, Corey Minyard wrote: > From: Konstantin Baydarov <[EMAIL PROTECTED]> > > Atomics are a lot more efficient and neat than using a lock. per_cpu variables are a lot more efficient and neat than using locks for simple statistics. no cache line bouncing to increment the counter. Are these read so often that atomics are really better? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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: [Openipmi-developer] [PATCH 3/4] IPMI: convert locked counters to atomics
On Thu, Feb 14, 2008 at 12:30:51PM -0600, Corey Minyard wrote: From: Konstantin Baydarov [EMAIL PROTECTED] Atomics are a lot more efficient and neat than using a lock. per_cpu variables are a lot more efficient and neat than using locks for simple statistics. no cache line bouncing to increment the counter. Are these read so often that atomics are really better? Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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] PCI: remove initial bios sort of PCI devices on x86
On Wed, Feb 13, 2008 at 03:40:29PM -0800, Greg KH wrote: > We currently keep 2 lists of PCI devices in the system, one in the > driver core, and one all on its own. This second list is sorted at boot > time, in "BIOS" order, to try to remain compatible with older kernels > (2.2 and earlier days). There was also a "nosort" option to turn this > sorting off, to remain compatible with even older kernel versions, but > that just ends up being what we have been doing from 2.5 days... > > Unfortunately, the second list of devices is not really ever used to > determine the probing order of PCI devices or drivers[1]. That is done > using the driver core list instead. This change happened back in the > early 2.5 days. > > Relying on BIOS ording for the binding of drivers to specific device > names is problematic for many reasons, and userspace tools like udev > exist to properly name devices in a persistant manner if that is needed, > no reliance on the BIOS is needed. > > Matt Domsch and others at Dell noticed this back in 2006, and added a > boot option to sort the PCI device lists (both of them) in a > breadth-first manner to help remain compatible with the 2.4 order, if > needed for any reason. This option is not going away, as some systems > rely on them. > > This patch removes the sorting of the internal PCI device list in "BIOS" > mode, as it's not needed at all anymore, and hasn't for many years. > I've also removed the PCI flags for this from some other arches that for > some reason defined them, but never used them. > > This should not change the ordering of any drivers or device probing. Good plan. I'll be glad when the vestigal internal PCI device list is gone too. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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] PCI: remove initial bios sort of PCI devices on x86
On Wed, Feb 13, 2008 at 03:40:29PM -0800, Greg KH wrote: We currently keep 2 lists of PCI devices in the system, one in the driver core, and one all on its own. This second list is sorted at boot time, in BIOS order, to try to remain compatible with older kernels (2.2 and earlier days). There was also a nosort option to turn this sorting off, to remain compatible with even older kernel versions, but that just ends up being what we have been doing from 2.5 days... Unfortunately, the second list of devices is not really ever used to determine the probing order of PCI devices or drivers[1]. That is done using the driver core list instead. This change happened back in the early 2.5 days. Relying on BIOS ording for the binding of drivers to specific device names is problematic for many reasons, and userspace tools like udev exist to properly name devices in a persistant manner if that is needed, no reliance on the BIOS is needed. Matt Domsch and others at Dell noticed this back in 2006, and added a boot option to sort the PCI device lists (both of them) in a breadth-first manner to help remain compatible with the 2.4 order, if needed for any reason. This option is not going away, as some systems rely on them. This patch removes the sorting of the internal PCI device list in BIOS mode, as it's not needed at all anymore, and hasn't for many years. I've also removed the PCI flags for this from some other arches that for some reason defined them, but never used them. This should not change the ordering of any drivers or device probing. Good plan. I'll be glad when the vestigal internal PCI device list is gone too. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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: DMI: add-type-41
On Fri, Jan 25, 2008 at 09:19:11PM +0100, Wim Van Sebroeck wrote: > Hi All, > > Would appreciate feedback on this patch. > > Thanks in advance, > Wim. > > commit 4956e4e5e77b5a8f87bcfe6127ef17a406edf94b > Author: Wim Van Sebroeck <[EMAIL PROTECTED]> > Date: Mon Dec 31 17:21:33 2007 + > > [PATCH] SMBIOS/DMI - add type 41 = Onboard Devices Extended Information Is there something in the kernel that will consume this data, or is it being exported in /sys/class/dmi/id somehow? There will be one table entry per device (Dell PowerEdge x9xx servers with recent BIOS do so). FWIW, my biosdevname app consumes this data, using dmidecode from userspace. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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: DMI: add-type-41
On Fri, Jan 25, 2008 at 09:19:11PM +0100, Wim Van Sebroeck wrote: Hi All, Would appreciate feedback on this patch. Thanks in advance, Wim. commit 4956e4e5e77b5a8f87bcfe6127ef17a406edf94b Author: Wim Van Sebroeck [EMAIL PROTECTED] Date: Mon Dec 31 17:21:33 2007 + [PATCH] SMBIOS/DMI - add type 41 = Onboard Devices Extended Information Is there something in the kernel that will consume this data, or is it being exported in /sys/class/dmi/id somehow? There will be one table entry per device (Dell PowerEdge x9xx servers with recent BIOS do so). FWIW, my biosdevname app consumes this data, using dmidecode from userspace. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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: [Openipmi-developer] modprobing ipmi_si on Dell Power Edge 2600 make the terminal hang kernel ver. >= 2.6.20
On Tue, Jan 22, 2008 at 06:50:31AM -0600, Matt Domsch wrote: > On Mon, Jan 21, 2008 at 09:40:59AM +0800, william cheng wrote: > > Dear all, > > > > We got some problem on modprobing the ipmi_si module on Dell > > Power Edge 2600. > > I've asked someone to look into this. and I've filed this as http://bugzilla.kernel.org/show_bug.cgi?id=9793 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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: modprobing ipmi_si on Dell Power Edge 2600 make the terminal hang kernel ver. >= 2.6.20
On Mon, Jan 21, 2008 at 09:40:59AM +0800, william cheng wrote: > Dear all, > > We got some problem on modprobing the ipmi_si module on Dell > Power Edge 2600. I've asked someone to look into this. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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: modprobing ipmi_si on Dell Power Edge 2600 make the terminal hang kernel ver. = 2.6.20
On Mon, Jan 21, 2008 at 09:40:59AM +0800, william cheng wrote: Dear all, We got some problem on modprobing the ipmi_si module on Dell Power Edge 2600. I've asked someone to look into this. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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: Querying the bios from booted linux kernel?
On Fri, Jan 04, 2008 at 07:13:53PM -0500, Gene Heskett wrote: > Greetings; > > Is there a utility that can query the motherboard bios and get a list of the > drives it can see? > > Likewise, for the bios extension contained on a pny sata card with a Silicon > Image chipset on it? > > I'm trying to cobble up a way for linux to boot from the drive on this sata > card, so that the F8 install is completely separated from the FC6 install on > a pata drive connected to the mainboard. parted and fdisk both write into the MBR signature space, so your disks should have unique MBR values in them. Then, F8 anaconda / kickstart can be told on which disk to write its bits. http://linux.dell.com/installermagic.shtml describes this. I've given up trusting any BIOS to get EDD 3.0 device paths right, there are just too many broken implementations out there, and seemingly no real desire on the part of the component vendors to fix it. MBR signatures work pretty well - Dell uses this method for every one of our factory installed Linux systems we ship, so I _know_ it works. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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: Querying the bios from booted linux kernel?
On Fri, Jan 04, 2008 at 07:13:53PM -0500, Gene Heskett wrote: Greetings; Is there a utility that can query the motherboard bios and get a list of the drives it can see? Likewise, for the bios extension contained on a pny sata card with a Silicon Image chipset on it? I'm trying to cobble up a way for linux to boot from the drive on this sata card, so that the F8 install is completely separated from the FC6 install on a pata drive connected to the mainboard. parted and fdisk both write into the MBR signature space, so your disks should have unique MBR values in them. Then, F8 anaconda / kickstart can be told on which disk to write its bits. http://linux.dell.com/installermagic.shtml describes this. I've given up trusting any BIOS to get EDD 3.0 device paths right, there are just too many broken implementations out there, and seemingly no real desire on the part of the component vendors to fix it. MBR signatures work pretty well - Dell uses this method for every one of our factory installed Linux systems we ship, so I _know_ it works. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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/3] ide: use MODULE_VERSION()
On Wed, Jan 02, 2008 at 11:45:17PM +0100, Bartlomiej Zolnierkiewicz wrote: > Unfortunately 'srcversion' is set only if MODULE_VERSION() is used... :( or CONFIG_MODULE_SRCVERSION_ALL=y. I see Fedora doesn't use that :-( but Ubuntu, openSUSE do. /me files a change request... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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/3] ide: use MODULE_VERSION()
On Wed, Jan 02, 2008 at 11:45:17PM +0100, Bartlomiej Zolnierkiewicz wrote: Unfortunately 'srcversion' is set only if MODULE_VERSION() is used... :( or CONFIG_MODULE_SRCVERSION_ALL=y. I see Fedora doesn't use that :-( but Ubuntu, openSUSE do. /me files a change request... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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: Get physical MAC address
On Mon, Dec 31, 2007 at 12:39:11PM +0700, Theewara Vorakosit wrote: > Hello, > > I get MAC address from ioctl. However, ifconfig can change this MAC > address. Can I get a real physical MAC address of the NIC? yes. It's ETHTOOL_GPERMADDR to the ethtool ioctl. case ETHTOOL_GPERMADDR: rc = ethtool_get_perm_addr(dev, useraddr); break; When the driver is first loaded, before ifconfig can change the MAC address, the existing (permanent) MAC address is stored away, able to be retrieved via this ioctl. Jon Wetzel, a Dell intern of a few summers ago, wrote the code and was able to have it included. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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/3] ide: use MODULE_VERSION()
On Tue, Jan 01, 2008 at 09:32:36PM -0500, Jon Masters wrote: > On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote: > > > On the second thought: maybe we will be better off with limiting > > MODULE_VERSION() to the device drivers and the IDE core module for now, > > and just removing all these private version numbers from host drivers > > (with one or two exceptions they are not printed or exported currently, > > moreover exceptions are the cases like stale version numbers from 199x)? > > Things like checkpatch could help advise people to bump the version > number, but it's a bit iffy. Matt D. actually uses the special source > version modinfo for DKMS - which is different - but it makes me wonder > whether dynamically generating a version based on source SHA1 wouldn't > be a better idea in most cases than an outdated hard-coded one. We've got that already, it's called 'srcversion', and it's a CRC32 IIRC after some limited parsing to let it ignore whitspace changes and comment changes only. $ modinfo dell_rbu | grep version version:3.2 srcversion: 1D4815D7D6FBEE6612F3C18 DKMS uses the srcversion if present recognize an exact match. srcversions can't be tested for anything <> though, only =. DKMS also uses the version field as supplied by MODULE_VERSION() to try to determine older-vs-newer modules. On occasion we've had to release updated "fixed" kernel modules, in which case we bump the value in MODULE_VERSION() slightly (typically append .1 or something similar) so the "fixed" module version compares higher. Such version fields aren't generally used with stock kernel.org kernels (where users can be expected to upgrade to a later stock kernel), but for users of a distro kernel where we need to fix a module without forcing the user to upgrade the whole kernel. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- 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/3] ide: use MODULE_VERSION()
On Tue, Jan 01, 2008 at 09:32:36PM -0500, Jon Masters wrote: On Tue, 2008-01-01 at 19:33 +0100, Bartlomiej Zolnierkiewicz wrote: On the second thought: maybe we will be better off with limiting MODULE_VERSION() to the device drivers and the IDE core module for now, and just removing all these private version numbers from host drivers (with one or two exceptions they are not printed or exported currently, moreover exceptions are the cases like stale version numbers from 199x)? Things like checkpatch could help advise people to bump the version number, but it's a bit iffy. Matt D. actually uses the special source version modinfo for DKMS - which is different - but it makes me wonder whether dynamically generating a version based on source SHA1 wouldn't be a better idea in most cases than an outdated hard-coded one. We've got that already, it's called 'srcversion', and it's a CRC32 IIRC after some limited parsing to let it ignore whitspace changes and comment changes only. $ modinfo dell_rbu | grep version version:3.2 srcversion: 1D4815D7D6FBEE6612F3C18 DKMS uses the srcversion if present recognize an exact match. srcversions can't be tested for anything though, only =. DKMS also uses the version field as supplied by MODULE_VERSION() to try to determine older-vs-newer modules. On occasion we've had to release updated fixed kernel modules, in which case we bump the value in MODULE_VERSION() slightly (typically append .1 or something similar) so the fixed module version compares higher. Such version fields aren't generally used with stock kernel.org kernels (where users can be expected to upgrade to a later stock kernel), but for users of a distro kernel where we need to fix a module without forcing the user to upgrade the whole kernel. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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: Get physical MAC address
On Mon, Dec 31, 2007 at 12:39:11PM +0700, Theewara Vorakosit wrote: Hello, I get MAC address from ioctl. However, ifconfig can change this MAC address. Can I get a real physical MAC address of the NIC? yes. It's ETHTOOL_GPERMADDR to the ethtool ioctl. case ETHTOOL_GPERMADDR: rc = ethtool_get_perm_addr(dev, useraddr); break; When the driver is first loaded, before ifconfig can change the MAC address, the existing (permanent) MAC address is stored away, able to be retrieved via this ioctl. Jon Wetzel, a Dell intern of a few summers ago, wrote the code and was able to have it included. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux -- 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 38/54] efivars: remove new_var and del_var files from sysfs
On Fri, Nov 02, 2007 at 04:59:16PM -0700, Greg Kroah-Hartman wrote: > WTF? Passing binary structures into a sysfs file, expecting it to be in > the correct format/endianness? That's just wrong on so many levels. > > So, these files are deleted. If you want to add them back, please do so > in configfs, or in debugfs. Or use text strings, which is what sysfs is > only for. I have tested gregkh's patches tree, which includes this patch, the patch to put these back as binary blob interfaces, as well as other cleanups, on an Itanium2 system. The efibootmgr userspace application continues to work as it did before this patch series, which I claim is success. For the patches that touch drivers/firmware/efivars.c I can say: Tested-by: Matt Domsch <[EMAIL PROTECTED]> Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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 38/54] efivars: remove new_var and del_var files from sysfs
On Fri, Nov 02, 2007 at 04:59:16PM -0700, Greg Kroah-Hartman wrote: WTF? Passing binary structures into a sysfs file, expecting it to be in the correct format/endianness? That's just wrong on so many levels. So, these files are deleted. If you want to add them back, please do so in configfs, or in debugfs. Or use text strings, which is what sysfs is only for. I have tested gregkh's patches tree, which includes this patch, the patch to put these back as binary blob interfaces, as well as other cleanups, on an Itanium2 system. The efibootmgr userspace application continues to work as it did before this patch series, which I claim is success. For the patches that touch drivers/firmware/efivars.c I can say: Tested-by: Matt Domsch [EMAIL PROTECTED] Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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][RFC] Physical PCI slot objects
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote: > On Tue, Nov 13, 2007 at 11:33:53AM -0700, Matthew Wilcox wrote: > > On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote: > > > I'm still not sold on this idea at all. I'm really betting that there > > > is a lot of incorrect acpi slot information floating around in machines > > > and odd things will show up in these slot entries. > > > > Is that the end of the world? Instead of having no information, we'll > > end up with odd information. If people complain, we can always > > blacklist (indeed, won't the ACPI rolling blacklist catch the majority > > of these machines?) > > I don't think the rolling blacklist will catch this, as the rest of the > ACPI code is "correct". > > And yes, incorrect information exported by the kernel is not good at > all, especially if a user expects it to work properly :) > > > > I say this because for a long time there was no "standard" acpi entries > > > for hotplug slots and different companies did different things. Hence > > > the "odd" IBM acpi hotplug implementation as one example. If this is > > > going to go anywhere, you need to get IBM to agree that it works > > > properly with all their machines... > > > > Not in terms of slot names. There were various things that ACPI didn't > > specify, like attention and latches, but the description of _SUN hasn't > > changed. > > Ok, again, I want to see the IBM people sign off on this, after testing > on all of their machines, before I'll consider this, as I know the IBM > acpi tables are "odd". > > Also, how about Dell machines? I know they are probably not expecting > this information to show up and who knows if the numbering of their > slots match up with their physical diagrams (I say this based on all of > the eth0/eth1 "issues" with Dell machines over the years...) The only reported _SUN problems on Dell systems were on the PE6800 and PE6850 systems, which we've fixed with an updated BIOS several months ago. IIRC the values weren't always unique which kind of defeated the purpose. The eth0/eth1 "issues" are completely separate, with no relation to ACPI. That's purely a PCI tree depth-first discovery vs. breadth-first discovery (where it indeed seems everyone except Linux 2.6 uses and expects breadth-first). We looked at extending ACPI to export device naming preference, but instead extended SMBIOS tables because we could get that change in far easier. The other bit that looks at slot numbers is the old PCI IRQ Routing Table, which still exists on Dell systems. > > We should, IMO, be improving the way we tell users which device has > > a problem. 'tulip7', 'eth4', 'pci :04:1e.3' ... all the user wants > > to know is which damn card it is so they can replace it. And slot name > > tells them that. > > Not if the slot information is incorrect :) > > That's my main concern. Again, I've only seen this be incorrect on those two models of Dell servers with outdated BIOS versions. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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][RFC] Physical PCI slot objects
On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote: On Tue, Nov 13, 2007 at 11:33:53AM -0700, Matthew Wilcox wrote: On Tue, Nov 13, 2007 at 09:01:29AM -0800, Greg KH wrote: I'm still not sold on this idea at all. I'm really betting that there is a lot of incorrect acpi slot information floating around in machines and odd things will show up in these slot entries. Is that the end of the world? Instead of having no information, we'll end up with odd information. If people complain, we can always blacklist (indeed, won't the ACPI rolling blacklist catch the majority of these machines?) I don't think the rolling blacklist will catch this, as the rest of the ACPI code is correct. And yes, incorrect information exported by the kernel is not good at all, especially if a user expects it to work properly :) I say this because for a long time there was no standard acpi entries for hotplug slots and different companies did different things. Hence the odd IBM acpi hotplug implementation as one example. If this is going to go anywhere, you need to get IBM to agree that it works properly with all their machines... Not in terms of slot names. There were various things that ACPI didn't specify, like attention and latches, but the description of _SUN hasn't changed. Ok, again, I want to see the IBM people sign off on this, after testing on all of their machines, before I'll consider this, as I know the IBM acpi tables are odd. Also, how about Dell machines? I know they are probably not expecting this information to show up and who knows if the numbering of their slots match up with their physical diagrams (I say this based on all of the eth0/eth1 issues with Dell machines over the years...) The only reported _SUN problems on Dell systems were on the PE6800 and PE6850 systems, which we've fixed with an updated BIOS several months ago. IIRC the values weren't always unique which kind of defeated the purpose. The eth0/eth1 issues are completely separate, with no relation to ACPI. That's purely a PCI tree depth-first discovery vs. breadth-first discovery (where it indeed seems everyone except Linux 2.6 uses and expects breadth-first). We looked at extending ACPI to export device naming preference, but instead extended SMBIOS tables because we could get that change in far easier. The other bit that looks at slot numbers is the old PCI IRQ Routing Table, which still exists on Dell systems. We should, IMO, be improving the way we tell users which device has a problem. 'tulip7', 'eth4', 'pci :04:1e.3' ... all the user wants to know is which damn card it is so they can replace it. And slot name tells them that. Not if the slot information is incorrect :) That's my main concern. Again, I've only seen this be incorrect on those two models of Dell servers with outdated BIOS versions. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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: PCI card initialisation at boot
On Sun, Nov 11, 2007 at 04:46:44PM +, Alan Cox wrote: > Linux by default uses the BIOS resource assignments. It doesn't know > where those came from other than "the BIOS". Slightly tangential, but I'm starting to hear requests to have the OS re-assign resources when it might make better sense. For example, if you have a graphics card with a 1GB memory allocation, the BIOS may assign it into address ranges below 4GB because it doesn't know if the OS will be 32-bit or 64-bit capable. But, it would be beneficial to have it located above 4GB, and to fill in the (new) hole below 4GB with RAM. Linux right now doesn't have a way to do this. It will assign resources for cards that the BIOS left unassigned, but won't intentionally move resources. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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: PCI card initialisation at boot
On Sun, Nov 11, 2007 at 04:46:44PM +, Alan Cox wrote: Linux by default uses the BIOS resource assignments. It doesn't know where those came from other than the BIOS. Slightly tangential, but I'm starting to hear requests to have the OS re-assign resources when it might make better sense. For example, if you have a graphics card with a 1GB memory allocation, the BIOS may assign it into address ranges below 4GB because it doesn't know if the OS will be 32-bit or 64-bit capable. But, it would be beneficial to have it located above 4GB, and to fill in the (new) hole below 4GB with RAM. Linux right now doesn't have a way to do this. It will assign resources for cards that the BIOS left unassigned, but won't intentionally move resources. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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] Dell laptop backlight driver
On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote: > Matt Domsch wrote: > >On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: > >>Hello, > >>this driver implements backlight control on Dell laptops > >>which use SMI for changing brightness levels. > >> > >>The driver is INCOMPLETE since it is unable to probe some required > >>parameters > >>in order to perform backlight control. Such parameters are found in a Dell > >>proprietary DMI table which should be parsed. For now external tools may > >>be > >>used to find these parameters by hand. So if you intend to try this out, > >>FIRST write your laptop model parameters correctly inside the source code > >>as explained in Documentation/dell-laptop.txt. > >> > >>Parts of this driver may also be used to provide additional > >>functionalities > >>similarly to the drivers/misc/*-laptop.c drivers. > > > >Why is this better done in the kernel rather than in userspace with > >libsmbios as you've noted? > > > > I had to do a kernelspace driver for controlling the backlight. This > was part of a college project assignment. In order for it to be valid > for an operating system course, it had to be in kernelspace (not > Unix programming) :). > > As i mentioned that can be done in userspace and it IS sensible to do > so. I know that the code which was already written for Dell implied > a userspace approach, but i simply had no choice. > > I also don't expect this driver to become mainstream, but since i have > written it, other people might want to have a look at it. OK, that's fair. > Finally i really don't think there's any sensible way of implementing > Linux LCD Backlight Abstraction relying on a userspace application. > That would mean the kernel calling userspace code to change the > brightness, then this latter code would again call the kernel to trigger > a SMI and so on. That's just not a good design. I think a userspace > solution implies choosing NOT to implement the LCD Abstraction. Causing > Dell laptops to be treated differently from other machines (as they are > not compliant with Linux's own interface). I've had this discussion on lkml before. Short story is, until Dell laptops implement the ACPI methods that the backlight API expects, the only sane way to do it is to let libsmbios handle it. Moving the fairly large and complex libsmbios into the kernel isn't a good idea (imho). -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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] Dell laptop backlight driver
On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: > Hello, > this driver implements backlight control on Dell laptops > which use SMI for changing brightness levels. > > The driver is INCOMPLETE since it is unable to probe some required > parameters > in order to perform backlight control. Such parameters are found in a Dell > proprietary DMI table which should be parsed. For now external tools may be > used to find these parameters by hand. So if you intend to try this out, > FIRST write your laptop model parameters correctly inside the source code > as explained in Documentation/dell-laptop.txt. > > Parts of this driver may also be used to provide additional functionalities > similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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] Dell laptop backlight driver
On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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] Dell laptop backlight driver
On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote: Matt Domsch wrote: On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote: Hello, this driver implements backlight control on Dell laptops which use SMI for changing brightness levels. The driver is INCOMPLETE since it is unable to probe some required parameters in order to perform backlight control. Such parameters are found in a Dell proprietary DMI table which should be parsed. For now external tools may be used to find these parameters by hand. So if you intend to try this out, FIRST write your laptop model parameters correctly inside the source code as explained in Documentation/dell-laptop.txt. Parts of this driver may also be used to provide additional functionalities similarly to the drivers/misc/*-laptop.c drivers. Why is this better done in the kernel rather than in userspace with libsmbios as you've noted? I had to do a kernelspace driver for controlling the backlight. This was part of a college project assignment. In order for it to be valid for an operating system course, it had to be in kernelspace (not Unix programming) :). As i mentioned that can be done in userspace and it IS sensible to do so. I know that the code which was already written for Dell implied a userspace approach, but i simply had no choice. I also don't expect this driver to become mainstream, but since i have written it, other people might want to have a look at it. OK, that's fair. Finally i really don't think there's any sensible way of implementing Linux LCD Backlight Abstraction relying on a userspace application. That would mean the kernel calling userspace code to change the brightness, then this latter code would again call the kernel to trigger a SMI and so on. That's just not a good design. I think a userspace solution implies choosing NOT to implement the LCD Abstraction. Causing Dell laptops to be treated differently from other machines (as they are not compliant with Linux's own interface). I've had this discussion on lkml before. Short story is, until Dell laptops implement the ACPI methods that the backlight API expects, the only sane way to do it is to let libsmbios handle it. Moving the fairly large and complex libsmbios into the kernel isn't a good idea (imho). -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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] pci: use pci=bfsort for HP DL385 G2, DL585 G2
On Thu, Sep 27, 2007 at 11:18:44AM +0200, Michal Schmidt wrote: > Hello, > > HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI > devices in the expected order. > > (John, can you please confirm and ACK this?) As a shameless plug, biosdevname is a userspace app I wrote to help solve this so we don't need to patch the kernel for future systems. It's not integrated into any distributions properly yet, but is included in openSUSE 10.3 and Fedora 8 for people who want to download and install it there. It acts as a udev helper. For the time being, patching the kernel is necessary. I really hope biosdevname eliminates that need in future distributions. http://linux.dell.com/biosdevname/ Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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] pci: use pci=bfsort for HP DL385 G2, DL585 G2
On Thu, Sep 27, 2007 at 11:18:44AM +0200, Michal Schmidt wrote: Hello, HP ProLiant systems DL385 G2 and DL585 G2 need pci=bfsort to enumerate PCI devices in the expected order. (John, can you please confirm and ACK this?) As a shameless plug, biosdevname is a userspace app I wrote to help solve this so we don't need to patch the kernel for future systems. It's not integrated into any distributions properly yet, but is included in openSUSE 10.3 and Fedora 8 for people who want to download and install it there. It acts as a udev helper. For the time being, patching the kernel is necessary. I really hope biosdevname eliminates that need in future distributions. http://linux.dell.com/biosdevname/ Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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] ppp_mppe: Don't put InterimKey on the stack
On Fri, Sep 21, 2007 at 04:08:09PM +0200, Michal Schmidt wrote: > Hello, > > The interrupt stack can be in the __START_KERNEL_map region in which > virt_to_page will not work. This caused ppp_mppe to crash on CentOS 5 on > x86_64 > (http://bugs.centos.org/view.php?id=2076). > > The fix is to avoid copying the interim key. We can simply use it in its > original place, which is kmalloc'd. Needs a Signed-off-by: line, but otherwise, looks good, and even saves some stack space. Thanks for tracking this down. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux - 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] ppp_mppe: Don't put InterimKey on the stack
On Fri, Sep 21, 2007 at 04:08:09PM +0200, Michal Schmidt wrote: Hello, The interrupt stack can be in the __START_KERNEL_map region in which virt_to_page will not work. This caused ppp_mppe to crash on CentOS 5 on x86_64 (http://bugs.centos.org/view.php?id=2076). The fix is to avoid copying the interim key. We can simply use it in its original place, which is kmalloc'd. Needs a Signed-off-by: line, but otherwise, looks good, and even saves some stack space. Thanks for tracking this down. -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux - 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/
l-k-digest downtime + bounces
lists.us.dell.com hosts digest forms of lkml: linux-kernel-digest and linux-kernel-daily-digest. In the process of moving lists.us.dell.com new hardware and a new OS, some messages sent to lkml this evening may have bounced or been dropped by the digester. This would only affect those people subscribed to one of the digest forms of the list. I apologize for the inconvenience. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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/
l-k-digest downtime + bounces
lists.us.dell.com hosts digest forms of lkml: linux-kernel-digest and linux-kernel-daily-digest. In the process of moving lists.us.dell.com new hardware and a new OS, some messages sent to lkml this evening may have bounced or been dropped by the digester. This would only affect those people subscribed to one of the digest forms of the list. I apologize for the inconvenience. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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/1] Work around Dell E520 BIOS reboot bug.
On Wed, May 23, 2007 at 01:12:44PM -0600, Tim Gardner wrote: > From: Tim Gardner <[EMAIL PROTECTED]> > Subject: [PATCH] Work around Dell E520 BIOS reboot bug. > > Force Dell E520 to use the BIOS to shutdown/reboot. > > Signed-off-by: Tim Gardner <[EMAIL PROTECTED]> Acked-by: Matt Domsch <[EMAIL PROTECTED]> Thanks Tim for submitting this. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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/1] Work around Dell E520 BIOS reboot bug.
On Wed, May 23, 2007 at 01:12:44PM -0600, Tim Gardner wrote: From: Tim Gardner [EMAIL PROTECTED] Subject: [PATCH] Work around Dell E520 BIOS reboot bug. Force Dell E520 to use the BIOS to shutdown/reboot. Signed-off-by: Tim Gardner [EMAIL PROTECTED] Acked-by: Matt Domsch [EMAIL PROTECTED] Thanks Tim for submitting this. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.6.21-rc3] pci: set pci=bfsort for PowerEdge R900
This patch automatically enables pci=bfsort for the Dell PowerEdge
R900. This is necessary to ensure the onboard NICs enumerate in the
proper order, similar to the other systems already on the list.
I'd appreciate this being applied before 2.6.21-final if possible.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index 1bb0693..9484366 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -193,6 +193,14 @@ static struct dmi_system_id __devinitdat
},
{
.callback = set_bf_sort,
+ .ident = "Dell PowerEdge R900",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R900"),
+ },
+ },
+ {
+ .callback = set_bf_sort,
.ident = "HP ProLiant BL20p G3",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
-
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 2.6.21-rc3] pci: set pci=bfsort for PowerEdge R900
This patch automatically enables pci=bfsort for the Dell PowerEdge
R900. This is necessary to ensure the onboard NICs enumerate in the
proper order, similar to the other systems already on the list.
I'd appreciate this being applied before 2.6.21-final if possible.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
diff --git a/arch/i386/pci/common.c b/arch/i386/pci/common.c
index 1bb0693..9484366 100644
--- a/arch/i386/pci/common.c
+++ b/arch/i386/pci/common.c
@@ -193,6 +193,14 @@ static struct dmi_system_id __devinitdat
},
{
.callback = set_bf_sort,
+ .ident = Dell PowerEdge R900,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell),
+ DMI_MATCH(DMI_PRODUCT_NAME, PowerEdge R900),
+ },
+ },
+ {
+ .callback = set_bf_sort,
.ident = HP ProLiant BL20p G3,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, HP),
-
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: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 08:30:25AM -0800, Randy Dunlap wrote: > On Tue, 30 Jan 2007 08:16:21 +0100 Jes Sorensen wrote: > > > James Bottomley wrote: > > > On Tue, 2007-01-30 at 01:06 +0100, Jes Sorensen wrote: > > >> The last couple of years there's been roughly 13 seats sold to sponsors, > > >> which is somewhere in the order or 15%. Even if we assume that say 50% > > >> of those seats have been given to relevant participants, thats still a > > >> lot of waste. > > > > > > The sad fact is that putting on a summit costs money. If the attendees > > > themselves don't pay then it has to come from somewhere. The current > > > funding mechanism is open for discussion, like the agenda ... what did > > > you have in mind? > > > > I don't have an issue with the fact there are sponsors, however I think > > KS is important enough and sponsors are aware of this, that selling > > seats to sponsors shouldn't be necessary. As one who regularly fills a sponsor slot (though I have also gotten an invitation on merit in the past), I don't believe the sponsor slot people detract from the sessions. Most of the time we keep quiet, occasionally offering our insights or challenges. Jonathan's writeups are fantastic, but it doesn't really compare with being there and participating in discussions, either hallway or main room. Besides consuming oxygen, what's the real concern here? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit
On Tue, Jan 30, 2007 at 08:30:25AM -0800, Randy Dunlap wrote: On Tue, 30 Jan 2007 08:16:21 +0100 Jes Sorensen wrote: James Bottomley wrote: On Tue, 2007-01-30 at 01:06 +0100, Jes Sorensen wrote: The last couple of years there's been roughly 13 seats sold to sponsors, which is somewhere in the order or 15%. Even if we assume that say 50% of those seats have been given to relevant participants, thats still a lot of waste. The sad fact is that putting on a summit costs money. If the attendees themselves don't pay then it has to come from somewhere. The current funding mechanism is open for discussion, like the agenda ... what did you have in mind? I don't have an issue with the fact there are sponsors, however I think KS is important enough and sponsors are aware of this, that selling seats to sponsors shouldn't be necessary. As one who regularly fills a sponsor slot (though I have also gotten an invitation on merit in the past), I don't believe the sponsor slot people detract from the sessions. Most of the time we keep quiet, occasionally offering our insights or challenges. Jonathan's writeups are fantastic, but it doesn't really compare with being there and participating in discussions, either hallway or main room. Besides consuming oxygen, what's the real concern here? Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 race in efi variable delete code
Fix race when deleting an EFI variable and issuing another EFI command on the
same variable. The removal of the variable from the efivars_list should be
done in efivar_delete and not delayed until the kobject release.
Furthermore, remove the item from the list at module unload time, and
use list_for_each_entry_safe() rather than list_for_each_safe() for readability.
Tested on ia64.
Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]>
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.6/drivers/firmware/efivars.c.orig Thu Jan 25 14:35:05 2007
+++ linux-2.6/drivers/firmware/efivars.cThu Jan 25 15:00:45 2007
@@ -122,8 +122,6 @@ struct efivar_entry {
struct kobject kobj;
};
-#define get_efivar_entry(n) list_entry(n, struct efivar_entry, list)
-
struct efivar_attribute {
struct attribute attr;
ssize_t (*show) (struct efivar_entry *entry, char *buf);
@@ -386,9 +384,6 @@ static struct sysfs_ops efivar_attr_ops
static void efivar_release(struct kobject *kobj)
{
struct efivar_entry *var = container_of(kobj, struct efivar_entry,
kobj);
- spin_lock(_lock);
- list_del(>list);
- spin_unlock(_lock);
kfree(var);
}
@@ -430,9 +425,8 @@ static ssize_t
efivar_create(struct subsystem *sub, const char *buf, size_t count)
{
struct efi_variable *new_var = (struct efi_variable *)buf;
- struct efivar_entry *search_efivar = NULL;
+ struct efivar_entry *search_efivar, *n;
unsigned long strsize1, strsize2;
- struct list_head *pos, *n;
efi_status_t status = EFI_NOT_FOUND;
int found = 0;
@@ -444,8 +438,7 @@ efivar_create(struct subsystem *sub, con
/*
* Does this variable already exist?
*/
- list_for_each_safe(pos, n, _list) {
- search_efivar = get_efivar_entry(pos);
+ list_for_each_entry_safe(search_efivar, n, _list, list) {
strsize1 = utf8_strsize(search_efivar->var.VariableName, 1024);
strsize2 = utf8_strsize(new_var->VariableName, 1024);
if (strsize1 == strsize2 &&
@@ -490,9 +483,8 @@ static ssize_t
efivar_delete(struct subsystem *sub, const char *buf, size_t count)
{
struct efi_variable *del_var = (struct efi_variable *)buf;
- struct efivar_entry *search_efivar = NULL;
+ struct efivar_entry *search_efivar, *n;
unsigned long strsize1, strsize2;
- struct list_head *pos, *n;
efi_status_t status = EFI_NOT_FOUND;
int found = 0;
@@ -504,8 +496,7 @@ efivar_delete(struct subsystem *sub, con
/*
* Does this variable already exist?
*/
- list_for_each_safe(pos, n, _list) {
- search_efivar = get_efivar_entry(pos);
+ list_for_each_entry_safe(search_efivar, n, _list, list) {
strsize1 = utf8_strsize(search_efivar->var.VariableName, 1024);
strsize2 = utf8_strsize(del_var->VariableName, 1024);
if (strsize1 == strsize2 &&
@@ -537,9 +528,9 @@ efivar_delete(struct subsystem *sub, con
spin_unlock(_lock);
return -EIO;
}
+ list_del(_efivar->list);
/* We need to release this lock before unregistering. */
spin_unlock(_lock);
-
efivar_unregister(search_efivar);
/* It's dead Jim */
@@ -768,10 +759,14 @@ out_free:
static void __exit
efivars_exit(void)
{
- struct list_head *pos, *n;
+ struct efivar_entry *entry, *n;
- list_for_each_safe(pos, n, _list)
- efivar_unregister(get_efivar_entry(pos));
+ list_for_each_entry_safe(entry, n, _list, list) {
+ spin_lock(_lock);
+ list_del(>list);
+ spin_unlock(_lock);
+ efivar_unregister(entry);
+ }
subsystem_unregister(_subsys);
firmware_unregister(_subsys);
-
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] Fix race in efi variable delete code.
On Mon, Jan 22, 2007 at 10:22:09AM -0500, Prarit Bhargava wrote: > Fix race when deleting an EFI variable and issuing another EFI command on the > same variable. The removal of the variable from the efivars_list should be > done in efivar_delete and not delayed until the kprobes release. > > Signed-off-by: Prarit Bhargava <[EMAIL PROTECTED]> But then we'll leave it dangling on the list at module unload time. Let me rework this and send you something to try. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] Fix race in efi variable delete code.
On Mon, Jan 22, 2007 at 10:22:09AM -0500, Prarit Bhargava wrote: Fix race when deleting an EFI variable and issuing another EFI command on the same variable. The removal of the variable from the efivars_list should be done in efivar_delete and not delayed until the kprobes release. Signed-off-by: Prarit Bhargava [EMAIL PROTECTED] But then we'll leave it dangling on the list at module unload time. Let me rework this and send you something to try. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 race in efi variable delete code
Fix race when deleting an EFI variable and issuing another EFI command on the
same variable. The removal of the variable from the efivars_list should be
done in efivar_delete and not delayed until the kobject release.
Furthermore, remove the item from the list at module unload time, and
use list_for_each_entry_safe() rather than list_for_each_safe() for readability.
Tested on ia64.
Signed-off-by: Prarit Bhargava [EMAIL PROTECTED]
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.6/drivers/firmware/efivars.c.orig Thu Jan 25 14:35:05 2007
+++ linux-2.6/drivers/firmware/efivars.cThu Jan 25 15:00:45 2007
@@ -122,8 +122,6 @@ struct efivar_entry {
struct kobject kobj;
};
-#define get_efivar_entry(n) list_entry(n, struct efivar_entry, list)
-
struct efivar_attribute {
struct attribute attr;
ssize_t (*show) (struct efivar_entry *entry, char *buf);
@@ -386,9 +384,6 @@ static struct sysfs_ops efivar_attr_ops
static void efivar_release(struct kobject *kobj)
{
struct efivar_entry *var = container_of(kobj, struct efivar_entry,
kobj);
- spin_lock(efivars_lock);
- list_del(var-list);
- spin_unlock(efivars_lock);
kfree(var);
}
@@ -430,9 +425,8 @@ static ssize_t
efivar_create(struct subsystem *sub, const char *buf, size_t count)
{
struct efi_variable *new_var = (struct efi_variable *)buf;
- struct efivar_entry *search_efivar = NULL;
+ struct efivar_entry *search_efivar, *n;
unsigned long strsize1, strsize2;
- struct list_head *pos, *n;
efi_status_t status = EFI_NOT_FOUND;
int found = 0;
@@ -444,8 +438,7 @@ efivar_create(struct subsystem *sub, con
/*
* Does this variable already exist?
*/
- list_for_each_safe(pos, n, efivar_list) {
- search_efivar = get_efivar_entry(pos);
+ list_for_each_entry_safe(search_efivar, n, efivar_list, list) {
strsize1 = utf8_strsize(search_efivar-var.VariableName, 1024);
strsize2 = utf8_strsize(new_var-VariableName, 1024);
if (strsize1 == strsize2
@@ -490,9 +483,8 @@ static ssize_t
efivar_delete(struct subsystem *sub, const char *buf, size_t count)
{
struct efi_variable *del_var = (struct efi_variable *)buf;
- struct efivar_entry *search_efivar = NULL;
+ struct efivar_entry *search_efivar, *n;
unsigned long strsize1, strsize2;
- struct list_head *pos, *n;
efi_status_t status = EFI_NOT_FOUND;
int found = 0;
@@ -504,8 +496,7 @@ efivar_delete(struct subsystem *sub, con
/*
* Does this variable already exist?
*/
- list_for_each_safe(pos, n, efivar_list) {
- search_efivar = get_efivar_entry(pos);
+ list_for_each_entry_safe(search_efivar, n, efivar_list, list) {
strsize1 = utf8_strsize(search_efivar-var.VariableName, 1024);
strsize2 = utf8_strsize(del_var-VariableName, 1024);
if (strsize1 == strsize2
@@ -537,9 +528,9 @@ efivar_delete(struct subsystem *sub, con
spin_unlock(efivars_lock);
return -EIO;
}
+ list_del(search_efivar-list);
/* We need to release this lock before unregistering. */
spin_unlock(efivars_lock);
-
efivar_unregister(search_efivar);
/* It's dead Jim */
@@ -768,10 +759,14 @@ out_free:
static void __exit
efivars_exit(void)
{
- struct list_head *pos, *n;
+ struct efivar_entry *entry, *n;
- list_for_each_safe(pos, n, efivar_list)
- efivar_unregister(get_efivar_entry(pos));
+ list_for_each_entry_safe(entry, n, efivar_list, list) {
+ spin_lock(efivars_lock);
+ list_del(entry-list);
+ spin_unlock(efivars_lock);
+ efivar_unregister(entry);
+ }
subsystem_unregister(vars_subsys);
firmware_unregister(efi_subsys);
-
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] docbook: add edd firmware interfaces
On Tue, Jan 09, 2007 at 09:41:09PM -0800, Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Cleanup kernel-doc notation in drivers/firmware/edd.c. > > Add edd.c to DocBook/kernel-api.tmpl. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Acked-by: Matt Domsch <[EMAIL PROTECTED]> Thanks Randy! -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com pgpRIN9Fud6Ci.pgp Description: PGP signature
Re: [PATCH] docbook: add edd firmware interfaces
On Tue, Jan 09, 2007 at 09:41:09PM -0800, Randy Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Cleanup kernel-doc notation in drivers/firmware/edd.c. Add edd.c to DocBook/kernel-api.tmpl. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Acked-by: Matt Domsch [EMAIL PROTECTED] Thanks Randy! -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com pgpRIN9Fud6Ci.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
On Thu, Dec 21, 2006 at 01:27:55PM -0500, [EMAIL PROTECTED] wrote: > On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said: > > It's also complicated because some switches are supposed to rfkill both > > an 802.11 module _and_ a bluetooth module at the same time, or I guess > > some laptops may even have one rfkill switch for each wireless device. > > On my Dell D820, it's bios-selectable if the switch is enabled, or if > it controls just the 802.11 card, or 802.11 and bluetooth, or just bluetooth, > or 802.11 and mobile broadband, or ... > > This way lies madness. :) > > (Oddest part - said bios config screen offers the choices for bluetooth > and mobile broadband even though the hardware config doesn't include it. ;) In this case changing the UI based on presence (and thus the printed docs etc.) winds up being difficult. Think of it as an embedded advertisement - you too could have bluetooth and mobile broadband... :-) -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Network drivers that don't suspend on interface down
On Thu, Dec 21, 2006 at 01:27:55PM -0500, [EMAIL PROTECTED] wrote: On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said: It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. On my Dell D820, it's bios-selectable if the switch is enabled, or if it controls just the 802.11 card, or 802.11 and bluetooth, or just bluetooth, or 802.11 and mobile broadband, or ... This way lies madness. :) (Oddest part - said bios config screen offers the choices for bluetooth and mobile broadband even though the hardware config doesn't include it. ;) In this case changing the UI based on presence (and thus the printed docs etc.) winds up being difficult. Think of it as an embedded advertisement - you too could have bluetooth and mobile broadband... :-) -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: [2.6 patch] make arch/i386/pci/common.c:pci_bf_sort static
On Thu, Nov 16, 2006 at 01:16:23PM +0100, Adrian Bunk wrote: > This patch makes the needlessly global pci_bf_sort static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Matt Domsch <[EMAIL PROTECTED]> -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: [2.6 patch] make arch/i386/pci/common.c:pci_bf_sort static
On Thu, Nov 16, 2006 at 01:16:23PM +0100, Adrian Bunk wrote: This patch makes the needlessly global pci_bf_sort static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Matt Domsch [EMAIL PROTECTED] -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.6.13-rc6-mm2] ppp_mppe: author email change
Frank Cusack, primary author of the ppp_mppe kernel module, is no
longer at Google. This updates his email address in the module, as
agreed to by Frank privately.
ppp_mppe.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
diff -urNp --exclude-from=/home/mdomsch/excludes --minimal
linux-2.6.13-rc6-mm2.orig/drivers/net/ppp_mppe.c
linux-2.6.13-rc6-mm2/drivers/net/ppp_mppe.c
--- linux-2.6.13-rc6-mm2.orig/drivers/net/ppp_mppe.cMon Aug 29 22:08:58 2005
+++ linux-2.6.13-rc6-mm2/drivers/net/ppp_mppe.c Mon Aug 29 22:10:23 2005
@@ -2,7 +2,7 @@
* ppp_mppe.c - interface MPPE to the PPP code.
* This version is for use with Linux kernel 2.6.14+
*
- * By Frank Cusack <[EMAIL PROTECTED]>.
+ * By Frank Cusack <[EMAIL PROTECTED]>.
* Copyright (c) 2002,2003,2004 Google, Inc.
* All rights reserved.
*
@@ -59,7 +59,7 @@
#include "ppp_mppe.h"
-MODULE_AUTHOR("Frank Cusack <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Frank Cusack <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Point-to-Point Protocol Microsoft Point-to-Point
Encryption support");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_ALIAS("ppp-compress-" __stringify(CI_MPPE));
-
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: ppp_mppe+pptp for 2.6.14?
On Mon, Aug 29, 2005 at 06:12:20PM +0100, Daniel Drake wrote: > Hi, > > If there are no known issues it would be nice to push this for inclusion in > 2.6.14. The relevant patches from -mm are named > ppp_mppe-add-ppp-mppe-encryption-module.patch and > ppp_mppe-add-ppp-mppe-encryption-module-update.patch > > Judging by the feedback I get from Gentoo users, there is high demand for > this :) This patch has been working fine for me for several weeks now. I've asked James Cameron, pptp project lead, to try a test to force the server side to issue a CCP DOWN, to make sure the client-side kernel ppp_generic module does the right thing and drops packets. I don't have a testbed that allows such, but he does. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: ppp_mppe+pptp for 2.6.14?
On Mon, Aug 29, 2005 at 06:12:20PM +0100, Daniel Drake wrote: Hi, If there are no known issues it would be nice to push this for inclusion in 2.6.14. The relevant patches from -mm are named ppp_mppe-add-ppp-mppe-encryption-module.patch and ppp_mppe-add-ppp-mppe-encryption-module-update.patch Judging by the feedback I get from Gentoo users, there is high demand for this :) This patch has been working fine for me for several weeks now. I've asked James Cameron, pptp project lead, to try a test to force the server side to issue a CCP DOWN, to make sure the client-side kernel ppp_generic module does the right thing and drops packets. I don't have a testbed that allows such, but he does. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.6.13-rc6-mm2] ppp_mppe: author email change
Frank Cusack, primary author of the ppp_mppe kernel module, is no longer at Google. This updates his email address in the module, as agreed to by Frank privately. ppp_mppe.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Signed-off-by: Matt Domsch [EMAIL PROTECTED] -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com diff -urNp --exclude-from=/home/mdomsch/excludes --minimal linux-2.6.13-rc6-mm2.orig/drivers/net/ppp_mppe.c linux-2.6.13-rc6-mm2/drivers/net/ppp_mppe.c --- linux-2.6.13-rc6-mm2.orig/drivers/net/ppp_mppe.cMon Aug 29 22:08:58 2005 +++ linux-2.6.13-rc6-mm2/drivers/net/ppp_mppe.c Mon Aug 29 22:10:23 2005 @@ -2,7 +2,7 @@ * ppp_mppe.c - interface MPPE to the PPP code. * This version is for use with Linux kernel 2.6.14+ * - * By Frank Cusack [EMAIL PROTECTED]. + * By Frank Cusack [EMAIL PROTECTED]. * Copyright (c) 2002,2003,2004 Google, Inc. * All rights reserved. * @@ -59,7 +59,7 @@ #include ppp_mppe.h -MODULE_AUTHOR(Frank Cusack [EMAIL PROTECTED]); +MODULE_AUTHOR(Frank Cusack [EMAIL PROTECTED]); MODULE_DESCRIPTION(Point-to-Point Protocol Microsoft Point-to-Point Encryption support); MODULE_LICENSE(Dual BSD/GPL); MODULE_ALIAS(ppp-compress- __stringify(CI_MPPE)); - 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: Ext3 Errors on Dell RAID
On Tue, Aug 23, 2005 at 09:05:27AM -0400, Jess Balint wrote: > Problem: > I get massive ext3 errors once every few days. See "errors on console" > section below. Almost all commands return I/O error. I have to power > cycle the machine to get it running again. Upon reboot, there are > usually 3 orphan inodes deleted and everything is fine. See "messages > on reboot" below. > > Configuration: > System: Dell PowerEdge 6300/500, 4 CPU SMP w/2GB memory > Discs: 3 SCSI discs in a controller-managed striped configuration > Controller: Dell PERC-2 > kernel messages in "kernel boot messages" below This looks very familiar, and given the firmware versions you mention, is probably a known issue. The controller firmware goes to do a cache flush, but that doesn't complete in a sane amount of time, and eventually the SCSI midlayer starts aborting commands and taking the file system offline. I don't believe a firmware update was released for your add-in PERC2 quad-channel card. Firmware 6091 was released for the PERC3/Di ROMBs which addresses this exact case, though other failures have been reported on [EMAIL PROTECTED] (subscribe and read archives at http://lists.us.dell.com) even with newer firmware. The workarounds include: 1) disable the read and write cache using afacli. 2) mount file systems using 'noatime'. 3) backup your data, replace the controller with something newer (disks on the onboard aic7xxx controller combined with Linux Software RAID works quite well), recreate your RAID array on the new controller, and restore your data from backups. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Ext3 Errors on Dell RAID
On Tue, Aug 23, 2005 at 09:05:27AM -0400, Jess Balint wrote: Problem: I get massive ext3 errors once every few days. See errors on console section below. Almost all commands return I/O error. I have to power cycle the machine to get it running again. Upon reboot, there are usually 3 orphan inodes deleted and everything is fine. See messages on reboot below. Configuration: System: Dell PowerEdge 6300/500, 4 CPU SMP w/2GB memory Discs: 3 SCSI discs in a controller-managed striped configuration Controller: Dell PERC-2 kernel messages in kernel boot messages below This looks very familiar, and given the firmware versions you mention, is probably a known issue. The controller firmware goes to do a cache flush, but that doesn't complete in a sane amount of time, and eventually the SCSI midlayer starts aborting commands and taking the file system offline. I don't believe a firmware update was released for your add-in PERC2 quad-channel card. Firmware 6091 was released for the PERC3/Di ROMBs which addresses this exact case, though other failures have been reported on [EMAIL PROTECTED] (subscribe and read archives at http://lists.us.dell.com) even with newer firmware. The workarounds include: 1) disable the read and write cache using afacli. 2) mount file systems using 'noatime'. 3) backup your data, replace the controller with something newer (disks on the onboard aic7xxx controller combined with Linux Software RAID works quite well), recreate your RAID array on the new controller, and restore your data from backups. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
sm to do this in userspace, and it's extensible (edit and load a new config file at runtime) in a similar fashion. So it's not impossible, but it seems like it's adding a whole lot of code to the kernel, just to properly find and export the tokens. I heard some fair suggestions: 1) check DMI_SYS_VENDOR and DMI_PRODUCT_NAME at init time to limit the driver to work on Dell systems (or those systems which are OEMd from Dell). 2) Require the userspace tool to be root to use the interface. I had mentioned this to Doug already, gregkh did as well, and Doug agreed to make that change. 3) export appropriate functionality via hwmon. No problem conceptually there. Some unfair suggestions: 1) this is a SMI hook for userspace. Sure it is, but root in userspace can generate all the SMIs it wants completely independent of the kernel to do evil things. To do things right requires a little kernel help as noted above. The root application requires a good bit of trust, but we trust root an awful lot already. This isn't a new capability we're giving root through the kernel module, it's a safer capability. 2) if it's exported via sysfs, then userspace tools become easier. Yes, this is true, when the information in the kernel is best represented and easy to export via sysfs. In this case though, the kernel need not know about the whole token list and which ones work on any given platform, what their value mappings are, and what their input validation routines must be. That's complexity best left to a trusted root userspace app. I really see this kernel module as a pass-through mechanism to talk with hardware in its native language (even if you disagree with the language). This is conceptually similar to how SCSI Generic (either /dev/sg or ioctl(SG_IO)) works (userspace passes in preformated SCSI CDBs and gets back the resultant CDBs and extended sense data). The sg driver doesn't look at the data being passed down to any great extent. It doesn't validate that the command will make sense to the end device. It *has* validated that the device it's talking to is a SCSI device (fair suggestion #1 above) before doing so. But there isn't a sysfs file for every possible command you can send to each device. Userspace tools that care about any given command implement such. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.6.13-rc6] add Dell Systems Management Base Driver (dcdbas) with sysfs support
to properly find and export the tokens. I heard some fair suggestions: 1) check DMI_SYS_VENDOR and DMI_PRODUCT_NAME at init time to limit the driver to work on Dell systems (or those systems which are OEMd from Dell). 2) Require the userspace tool to be root to use the interface. I had mentioned this to Doug already, gregkh did as well, and Doug agreed to make that change. 3) export appropriate functionality via hwmon. No problem conceptually there. Some unfair suggestions: 1) this is a SMI hook for userspace. Sure it is, but root in userspace can generate all the SMIs it wants completely independent of the kernel to do evil things. To do things right requires a little kernel help as noted above. The root application requires a good bit of trust, but we trust root an awful lot already. This isn't a new capability we're giving root through the kernel module, it's a safer capability. 2) if it's exported via sysfs, then userspace tools become easier. Yes, this is true, when the information in the kernel is best represented and easy to export via sysfs. In this case though, the kernel need not know about the whole token list and which ones work on any given platform, what their value mappings are, and what their input validation routines must be. That's complexity best left to a trusted root userspace app. I really see this kernel module as a pass-through mechanism to talk with hardware in its native language (even if you disagree with the language). This is conceptually similar to how SCSI Generic (either /dev/sg or ioctl(SG_IO)) works (userspace passes in preformated SCSI CDBs and gets back the resultant CDBs and extended sense data). The sg driver doesn't look at the data being passed down to any great extent. It doesn't validate that the command will make sense to the end device. It *has* validated that the device it's talking to is a SCSI device (fair suggestion #1 above) before doing so. But there isn't a sysfs file for every possible command you can send to each device. Userspace tools that care about any given command implement such. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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/
[RFT][PATCH 2.6.13-rc] EDD: edd=skipmbr necessity fix
This is a request for testers, specifically people whose i386 or x86_64 systems won't boot properly if CONFIG_EDD=[ym] without the use of edd=skipmbr. If you're currently using edd=skipmbr, I'd really appreciate knowing about it, and your results of booting with this patch. This patch uses an int13 Get Disk Type call before using a Read Sectors call to read the MBR. If Get Disk Type fails, this is a good indication that the BIOS doesn't believe there's a disk there, without actually trying to do I/O to the disk. arch/i386/boot/edd.S | 15 ++- include/linux/edd.h |2 ++ 2 files changed, 16 insertions, 1 deletion Signed-off-by: Matt Domsch <[EMAIL PROTECTED]> Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com diff --git a/arch/i386/boot/edd.S b/arch/i386/boot/edd.S --- a/arch/i386/boot/edd.S +++ b/arch/i386/boot/edd.S @@ -55,6 +55,19 @@ done_cl: # Read the first sector of each BIOS disk device and store the 4-byte signature edd_mbr_sig_start: movb$0x80, %dl # from device 80 +edd_get_disk_type: + movw$GET_DISK_TYPE, %ax + pushw %cx # this clobbers cx and dx + pushw %dx # + stc # work around buggy BIOSes + int $0x13 + sti # work around buggy BIOSes + popw%dx + popw%cx + jc edd_mbr_sig_done + cmpb$GET_DISK_TYPE_DISK, %ah# is this a disk? + jne edd_mbr_sig_done + movw$EDD_MBR_SIG_BUF, %bx # store buffer ptr in bx edd_mbr_sig_read: movl$0x, %eax @@ -82,7 +95,7 @@ edd_mbr_sig_read: incb%dl # increment to next device addw$4, %bx # increment sig buffer ptr cmpb$EDD_MBR_SIG_MAX, (EDD_MBR_SIG_NR_BUF) # Out of space? - jb edd_mbr_sig_read# keep looping + jb edd_get_disk_type # keep looping edd_mbr_sig_done: # Do the BIOS Enhanced Disk Drive calls diff --git a/include/linux/edd.h b/include/linux/edd.h --- a/include/linux/edd.h +++ b/include/linux/edd.h @@ -39,6 +39,8 @@ #define CHECKEXTENSIONSPRESENT 0x41 #define GETDEVICEPARAMETERS 0x48 #define LEGACYGETDEVICEPARAMETERS 0x08 +#define GET_DISK_TYPE 0x1500 +#define GET_DISK_TYPE_DISK 0x03 #define EDDMAGIC1 0x55AA #define EDDMAGIC2 0xAA55 - 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/
[RFT][PATCH 2.6.13-rc] EDD: edd=skipmbr necessity fix
This is a request for testers, specifically people whose i386 or x86_64 systems won't boot properly if CONFIG_EDD=[ym] without the use of edd=skipmbr. If you're currently using edd=skipmbr, I'd really appreciate knowing about it, and your results of booting with this patch. This patch uses an int13 Get Disk Type call before using a Read Sectors call to read the MBR. If Get Disk Type fails, this is a good indication that the BIOS doesn't believe there's a disk there, without actually trying to do I/O to the disk. arch/i386/boot/edd.S | 15 ++- include/linux/edd.h |2 ++ 2 files changed, 16 insertions, 1 deletion Signed-off-by: Matt Domsch [EMAIL PROTECTED] Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com diff --git a/arch/i386/boot/edd.S b/arch/i386/boot/edd.S --- a/arch/i386/boot/edd.S +++ b/arch/i386/boot/edd.S @@ -55,6 +55,19 @@ done_cl: # Read the first sector of each BIOS disk device and store the 4-byte signature edd_mbr_sig_start: movb$0x80, %dl # from device 80 +edd_get_disk_type: + movw$GET_DISK_TYPE, %ax + pushw %cx # this clobbers cx and dx + pushw %dx # + stc # work around buggy BIOSes + int $0x13 + sti # work around buggy BIOSes + popw%dx + popw%cx + jc edd_mbr_sig_done + cmpb$GET_DISK_TYPE_DISK, %ah# is this a disk? + jne edd_mbr_sig_done + movw$EDD_MBR_SIG_BUF, %bx # store buffer ptr in bx edd_mbr_sig_read: movl$0x, %eax @@ -82,7 +95,7 @@ edd_mbr_sig_read: incb%dl # increment to next device addw$4, %bx # increment sig buffer ptr cmpb$EDD_MBR_SIG_MAX, (EDD_MBR_SIG_NR_BUF) # Out of space? - jb edd_mbr_sig_read# keep looping + jb edd_get_disk_type # keep looping edd_mbr_sig_done: # Do the BIOS Enhanced Disk Drive calls diff --git a/include/linux/edd.h b/include/linux/edd.h --- a/include/linux/edd.h +++ b/include/linux/edd.h @@ -39,6 +39,8 @@ #define CHECKEXTENSIONSPRESENT 0x41 #define GETDEVICEPARAMETERS 0x48 #define LEGACYGETDEVICEPARAMETERS 0x08 +#define GET_DISK_TYPE 0x1500 +#define GET_DISK_TYPE_DISK 0x03 #define EDDMAGIC1 0x55AA #define EDDMAGIC2 0xAA55 - 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: Could you please check mail configuration?
On Fri, Aug 05, 2005 at 12:31:10AM +0900, Tetsuo Handa wrote: > Hello, Matt. > > > I had a note from you that this was a configuration error on your > > server's part, not on the list. So I stopped worrying about it... > Oh, really? I'm sorry. > > What is funny is that ... > > The mail from Matt had a X-OUTRCPT-TO header > with 2 mail addresses (my address and this ml's address), > but the mail from Jesper didn't have the X-OUTRCPT-TO header, > although both mails are sent as a reply to my mail. > > The X-OUTRCPT-TO: header in a Linux-kernel-daily-digest Digest > contains 80 mail addresses including my address. > > I can find X-OUTRCPT-TO header only in mails from > Matt and Linux-kernel-daily-digest Digest. > > You say this is a configuration error on my server's part. > I thought this X-OUTRCPT-TO header is added at linux.us.dell.com > and delivered to 80 recipients, resulting 80 recipients can see > other 79 addresses. It is indeed a mistake on Dell's part, and it'll be fixed momentarily. lists.us.dell.com relays to an intermediate server before being sent to you, and the intermediate relay was adding that field incorrectly. Thanks for bringing it to my attention. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Could you please check mail configuration?
On Thu, Aug 04, 2005 at 10:46:35PM +0900, Tetsuo Handa wrote: > Message to the moderators of this ML. > > Please don't forward this mail to this ML. > I intendedly mailed using a non-subscriber's address > so that this mail only seen to the moderators. > > - > > Hello, > > I found X-OUTRCPT-TO: header since > Linux-kernel-daily-digest Digest, Vol 8, Issue 21 > (at Date: Thu, 21 Jul 2005 06:00:01 -0500). > The X-OUTRCPT-TO: header exposes recipient's mail addresses. > And recently I'm getting spam mails to the exposed address. > I want you to hide X-OUTRCPT-TO header if you can. > > I sent to the person managing the list > ([EMAIL PROTECTED]) > on Mon, 1 Aug 2005 20:11:31 +0900, but no reply. > So I sent to you this time. I run the daily-digest list. I had a note from you that this was a configuration error on your server's part, not on the list. So I stopped worrying about it... -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Could you please check mail configuration?
On Thu, Aug 04, 2005 at 10:46:35PM +0900, Tetsuo Handa wrote: Message to the moderators of this ML. Please don't forward this mail to this ML. I intendedly mailed using a non-subscriber's address so that this mail only seen to the moderators. - Hello, I found X-OUTRCPT-TO: header since Linux-kernel-daily-digest Digest, Vol 8, Issue 21 (at Date: Thu, 21 Jul 2005 06:00:01 -0500). The X-OUTRCPT-TO: header exposes recipient's mail addresses. And recently I'm getting spam mails to the exposed address. I want you to hide X-OUTRCPT-TO header if you can. I sent to the person managing the list ([EMAIL PROTECTED]) on Mon, 1 Aug 2005 20:11:31 +0900, but no reply. So I sent to you this time. I run the daily-digest list. I had a note from you that this was a configuration error on your server's part, not on the list. So I stopped worrying about it... -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: Could you please check mail configuration?
On Fri, Aug 05, 2005 at 12:31:10AM +0900, Tetsuo Handa wrote: Hello, Matt. I had a note from you that this was a configuration error on your server's part, not on the list. So I stopped worrying about it... Oh, really? I'm sorry. What is funny is that ... The mail from Matt had a X-OUTRCPT-TO header with 2 mail addresses (my address and this ml's address), but the mail from Jesper didn't have the X-OUTRCPT-TO header, although both mails are sent as a reply to my mail. The X-OUTRCPT-TO: header in a Linux-kernel-daily-digest Digest contains 80 mail addresses including my address. I can find X-OUTRCPT-TO header only in mails from Matt and Linux-kernel-daily-digest Digest. You say this is a configuration error on my server's part. I thought this X-OUTRCPT-TO header is added at linux.us.dell.com and delivered to 80 recipients, resulting 80 recipients can see other 79 addresses. It is indeed a mistake on Dell's part, and it'll be fixed momentarily. lists.us.dell.com relays to an intermediate server before being sent to you, and the intermediate relay was adding that field incorrectly. Thanks for bringing it to my attention. -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 22/82] remove linux/version.h from drivers/message/fus ion
On Wed, Jul 20, 2005 at 12:54:09PM -0500, Nathan Lynch wrote:
> Matt Domsch wrote:
> > On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
> > > On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > > > In general, this construct:
> > > >
> > > > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > > > -{
> > > > > > - return sdev->online;
> > > > > > -}
> > > > > > -#endif
> > > >
> > > > is better tested as:
> > > >
> > > > #ifndef scsi_device_inline
> > > > static int inline scsi_device_online(struct scsi_device *sdev)
> > > > {
> > > > return sdev->online;
> > > > }
> > > > #endif
> > > >
> > > > when you can. It cleanly eliminates the version test, and tests for
> > > > exactly what you're looking for - is this function defined.
> > > >
> > >
> > > What you illustrated above is not going to work.
> > > If your doing #ifndef around a function, such as scsi_device_online, it's
> > > not going to compile
> > > when scsi_device_online is already implemented in the kernel tree.
> > > The routine scsi_device_online is a function, not a define. For a define
> > > this would work.
> >
> > Sure it does, function names are defined symbols.
> >
>
> $ cat foo.c
> static int foo(void) { return 0; }
> #ifndef foo
> static int foo(void) { return 0; }
> #endif
>
> $ gcc -c foo.c
> foo.c:3: error: redefinition of 'foo'
> foo.c:1: error: previous definition of 'foo' was here
>
> I believe #ifdef/#ifndef can test only preprocessor symbols.
I was mistaken. Christoph explained to me that it worked on 2.4 due to
the way module symbol versions worked, but isn't that way on 2.6
anymore. My apologies.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 22/82] remove linux/version.h from drivers/message/fus ion
On Wed, Jul 20, 2005 at 12:54:09PM -0500, Nathan Lynch wrote:
Matt Domsch wrote:
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online is a function, not a define. For a define
this would work.
Sure it does, function names are defined symbols.
$ cat foo.c
static int foo(void) { return 0; }
#ifndef foo
static int foo(void) { return 0; }
#endif
$ gcc -c foo.c
foo.c:3: error: redefinition of 'foo'
foo.c:1: error: previous definition of 'foo' was here
I believe #ifdef/#ifndef can test only preprocessor symbols.
I was mistaken. Christoph explained to me that it worked on 2.4 due to
the way module symbol versions worked, but isn't that way on 2.6
anymore. My apologies.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 22/82] remove linux/version.h from drivers/message/fus ion
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
> On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
> > In general, this construct:
> >
> > > > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > > > -static int inline scsi_device_online(struct scsi_device *sdev)
> > > > -{
> > > > - return sdev->online;
> > > > -}
> > > > -#endif
> >
> > is better tested as:
> >
> > #ifndef scsi_device_inline
> > static int inline scsi_device_online(struct scsi_device *sdev)
> > {
> > return sdev->online;
> > }
> > #endif
> >
> > when you can. It cleanly eliminates the version test, and tests for
> > exactly what you're looking for - is this function defined.
> >
>
> What you illustrated above is not going to work.
> If your doing #ifndef around a function, such as scsi_device_online, it's
> not going to compile
> when scsi_device_online is already implemented in the kernel tree.
> The routine scsi_device_online is a function, not a define. For a define
> this would work.
Sure it does, function names are defined symbols.
I'm doing exactly this in my backport of the openipmi drivers to RHEL4
and SLES9.
> I'm trying your example around msleep, msleep_interruptible, and
> msecs_to_jiffies, and
> my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
> three routines were not implemented and
> your suggestion works. I won't be able to to a linux version check as this
> change occurred between service packs
> of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
>
> Example:
>
> #ifdef msleep
#ifndef you mean.
> static void inline msleep(unsigned long msecs)
> {
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(msecs) + 1);
> }
> #endif
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 22/82] remove linux/version.h from drivers/message/fus ion
On Tue, Jul 19, 2005 at 06:07:41PM -0600, Moore, Eric Dean wrote:
On Tuesday, July 12, 2005 8:17 PM, Matt Domsch wrote:
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
What you illustrated above is not going to work.
If your doing #ifndef around a function, such as scsi_device_online, it's
not going to compile
when scsi_device_online is already implemented in the kernel tree.
The routine scsi_device_online is a function, not a define. For a define
this would work.
Sure it does, function names are defined symbols.
I'm doing exactly this in my backport of the openipmi drivers to RHEL4
and SLES9.
I'm trying your example around msleep, msleep_interruptible, and
msecs_to_jiffies, and
my code simply won't compile in SLES9 SP2(-191). In SLES9 SP1(-139), these
three routines were not implemented and
your suggestion works. I won't be able to to a linux version check as this
change occurred between service packs
of the 2.6.5 kernel suse tree. Anybody on the linux forums have any ideas?
Example:
#ifdef msleep
#ifndef you mean.
static void inline msleep(unsigned long msecs)
{
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(msecs) + 1);
}
#endif
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 22/82] remove linux/version.h from drivers/message/fus ion
Eric, I have to have a similar compat file for the IPMI drivers
backported onto RHEL3, RHEL4, and SLES9. They aren't in mainline of
course, but each OS has a slightly different copy for its needs, so my
DKMS packages carry it.
In general, this construct:
> > -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,6))
> > -static int inline scsi_device_online(struct scsi_device *sdev)
> > -{
> > - return sdev->online;
> > -}
> > -#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev->online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 22/82] remove linux/version.h from drivers/message/fus ion
Eric, I have to have a similar compat file for the IPMI drivers
backported onto RHEL3, RHEL4, and SLES9. They aren't in mainline of
course, but each OS has a slightly different copy for its needs, so my
DKMS packages carry it.
In general, this construct:
-#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,6))
-static int inline scsi_device_online(struct scsi_device *sdev)
-{
- return sdev-online;
-}
-#endif
is better tested as:
#ifndef scsi_device_inline
static int inline scsi_device_online(struct scsi_device *sdev)
{
return sdev-online;
}
#endif
when you can. It cleanly eliminates the version test, and tests for
exactly what you're looking for - is this function defined.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 2.6.13-rc1] driver core: subclasses
On Fri, Jul 08, 2005 at 07:40:00PM -0700, Greg KH wrote: > On Fri, Jul 08, 2005 at 05:54:48PM -0500, Matt Domsch wrote: > > The below patch is a first pass at implementing subclasses, for review > > and comment. > > Oops, when you mentioned this on irc, I thought you were referring to > class_devices not classes. I don't want classes to be able to be > nested, only class devices. > > I don't see a need for nested classes, as I thought the input thread had > resolved itself so that it didn't need it (but I stopped paying > attention, sorry, so I might be wrong here...) The tailing part of the thread is here: http://marc.theaimsgroup.com/?l=linux-kernel=111873628324649=2 http://marc.theaimsgroup.com/?l=linux-hotplug-devel=111877313202313=2 where Hannes and Dmitry seemed to indicate (to my reading) that they were looking for subclasses. Perhaps it's not necessary. > Why can't you just use class_device's that can have children? That way > the /sys/block stuff could be converted to also use this. I will investigate. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.6.13-rc1] driver core: subclasses
On Fri, Jul 08, 2005 at 07:40:00PM -0700, Greg KH wrote: On Fri, Jul 08, 2005 at 05:54:48PM -0500, Matt Domsch wrote: The below patch is a first pass at implementing subclasses, for review and comment. Oops, when you mentioned this on irc, I thought you were referring to class_devices not classes. I don't want classes to be able to be nested, only class devices. I don't see a need for nested classes, as I thought the input thread had resolved itself so that it didn't need it (but I stopped paying attention, sorry, so I might be wrong here...) The tailing part of the thread is here: http://marc.theaimsgroup.com/?l=linux-kernelm=111873628324649w=2 http://marc.theaimsgroup.com/?l=linux-hotplug-develm=111877313202313w=2 where Hannes and Dmitry seemed to indicate (to my reading) that they were looking for subclasses. Perhaps it's not necessary. Why can't you just use class_device's that can have children? That way the /sys/block stuff could be converted to also use this. I will investigate. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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/
[RFC][PATCH 2.6.13-rc1] driver core: subclasses
Greg,
The below patch is a first pass at implementing subclasses, for review
and comment.
As a test, I modified drivers/input/input.c to allocate a new class,
and register it as a subclass.
Before:
/sys/class/input/
/sys/class/input_device/
After:
/sys/class/input/input_device/
In this pass I'm not exporting the subclass_register/unregister
functions, but am expecting callers to use the new
class_subclass_create() call, and older callers to continue using
class_create() which is now static inline.
Callers to class_create() are expected to call class_destroy() on the
subclasses before the parent class.
Feedback appreciated.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.6/drivers/base/class.c 2005-07-06 14:19:37.0 -0400
+++ linux-2.6/drivers/base/class.c 2005-07-08 18:41:19.0 -0400
@@ -133,6 +133,26 @@ static void remove_class_attrs(struct cl
}
}
+static int class_subclass_register(struct class *subclass)
+{
+ struct class *parent;
+
+ if (!subclass)
+ return -ENODEV;
+
+ parent = class_get(subclass->parent);
+ if (!parent)
+ return -EINVAL;
+
+ subclass->subsys.kset.kobj.parent = >subsys.kset.kobj;
+
+ down(>sem);
+ list_add_tail(>subclasses, >subclass_node);
+ up(>sem);
+
+ return 0;
+}
+
int class_register(struct class * cls)
{
int error;
@@ -141,6 +161,8 @@ int class_register(struct class * cls)
INIT_LIST_HEAD(>children);
INIT_LIST_HEAD(>interfaces);
+ INIT_LIST_HEAD(>subclasses);
+ INIT_LIST_HEAD(>subclass_node);
init_MUTEX(>sem);
error = kobject_set_name(>subsys.kset.kobj, "%s", cls->name);
if (error)
@@ -148,6 +170,7 @@ int class_register(struct class * cls)
subsys_set_kset(cls, class_subsys);
+ class_subclass_register(cls);
error = subsystem_register(>subsys);
if (!error) {
error = add_class_attrs(class_get(cls));
@@ -156,10 +179,25 @@ int class_register(struct class * cls)
return error;
}
+static void class_subclass_unregister(struct class *subclass)
+{
+ struct class *parent = subclass->parent;
+
+ if (!parent)
+ return;
+
+ down(>sem);
+ list_del_init(>subclass_node);
+ subclass->parent = NULL;
+ up(>sem);
+ class_put(parent);
+}
+
void class_unregister(struct class * cls)
{
pr_debug("device class '%s': unregistering\n", cls->name);
remove_class_attrs(cls);
+ class_subclass_unregister(cls);
subsystem_unregister(>subsys);
}
@@ -184,7 +222,7 @@ static void class_device_create_release(
* Note, the pointer created here is to be destroyed when finished by
* making a call to class_destroy().
*/
-struct class *class_create(struct module *owner, char *name)
+struct class *class_subclass_create(struct module *owner, char *name, struct
class *parent)
{
struct class *cls;
int retval;
@@ -200,6 +238,7 @@ struct class *class_create(struct module
cls->owner = owner;
cls->class_release = class_create_release;
cls->release = class_device_create_release;
+ cls->parent = parent;
retval = class_register(cls);
if (retval)
@@ -738,8 +777,8 @@ EXPORT_SYMBOL_GPL(class_register);
EXPORT_SYMBOL_GPL(class_unregister);
EXPORT_SYMBOL_GPL(class_get);
EXPORT_SYMBOL_GPL(class_put);
-EXPORT_SYMBOL_GPL(class_create);
+EXPORT_SYMBOL_GPL(class_subclass_create);
EXPORT_SYMBOL_GPL(class_destroy);
EXPORT_SYMBOL_GPL(class_device_register);
--- linux-2.6/include/linux/device.h2005-07-06 14:21:20.0 -0400
+++ linux-2.6-input/include/linux/device.h 2005-07-08 18:39:16.0
-0400
@@ -155,11 +155,14 @@ struct device * driver_find_device(struc
struct class {
const char * name;
struct module * owner;
+ struct class* parent; /* for subclasses */
struct subsystemsubsys;
- struct list_headchildren;
+ struct list_headchildren; /* for class_devices */
struct list_headinterfaces;
- struct semaphoresem;/* locks both the children and
interfaces lists */
+ struct list_headsubclasses;
+ struct list_headsubclass_node; /* parent->sem held when
accessing */
+ struct semaphoresem;/* locks children, subclasses,
interfaces lists */
struct class_attribute * class_attrs;
struct class_device_attribute * class_dev_attrs;
@@ -258,7 +261,11 @@ struct class_interface {
extern int class_interface_register(struct class_interface *);
[RFC][PATCH 2.6.13-rc1] driver core: subclasses
Greg,
The below patch is a first pass at implementing subclasses, for review
and comment.
As a test, I modified drivers/input/input.c to allocate a new class,
and register it as a subclass.
Before:
/sys/class/input/
/sys/class/input_device/
After:
/sys/class/input/input_device/
In this pass I'm not exporting the subclass_register/unregister
functions, but am expecting callers to use the new
class_subclass_create() call, and older callers to continue using
class_create() which is now static inline.
Callers to class_create() are expected to call class_destroy() on the
subclasses before the parent class.
Feedback appreciated.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.6/drivers/base/class.c 2005-07-06 14:19:37.0 -0400
+++ linux-2.6/drivers/base/class.c 2005-07-08 18:41:19.0 -0400
@@ -133,6 +133,26 @@ static void remove_class_attrs(struct cl
}
}
+static int class_subclass_register(struct class *subclass)
+{
+ struct class *parent;
+
+ if (!subclass)
+ return -ENODEV;
+
+ parent = class_get(subclass-parent);
+ if (!parent)
+ return -EINVAL;
+
+ subclass-subsys.kset.kobj.parent = parent-subsys.kset.kobj;
+
+ down(parent-sem);
+ list_add_tail(parent-subclasses, subclass-subclass_node);
+ up(parent-sem);
+
+ return 0;
+}
+
int class_register(struct class * cls)
{
int error;
@@ -141,6 +161,8 @@ int class_register(struct class * cls)
INIT_LIST_HEAD(cls-children);
INIT_LIST_HEAD(cls-interfaces);
+ INIT_LIST_HEAD(cls-subclasses);
+ INIT_LIST_HEAD(cls-subclass_node);
init_MUTEX(cls-sem);
error = kobject_set_name(cls-subsys.kset.kobj, %s, cls-name);
if (error)
@@ -148,6 +170,7 @@ int class_register(struct class * cls)
subsys_set_kset(cls, class_subsys);
+ class_subclass_register(cls);
error = subsystem_register(cls-subsys);
if (!error) {
error = add_class_attrs(class_get(cls));
@@ -156,10 +179,25 @@ int class_register(struct class * cls)
return error;
}
+static void class_subclass_unregister(struct class *subclass)
+{
+ struct class *parent = subclass-parent;
+
+ if (!parent)
+ return;
+
+ down(parent-sem);
+ list_del_init(subclass-subclass_node);
+ subclass-parent = NULL;
+ up(parent-sem);
+ class_put(parent);
+}
+
void class_unregister(struct class * cls)
{
pr_debug(device class '%s': unregistering\n, cls-name);
remove_class_attrs(cls);
+ class_subclass_unregister(cls);
subsystem_unregister(cls-subsys);
}
@@ -184,7 +222,7 @@ static void class_device_create_release(
* Note, the pointer created here is to be destroyed when finished by
* making a call to class_destroy().
*/
-struct class *class_create(struct module *owner, char *name)
+struct class *class_subclass_create(struct module *owner, char *name, struct
class *parent)
{
struct class *cls;
int retval;
@@ -200,6 +238,7 @@ struct class *class_create(struct module
cls-owner = owner;
cls-class_release = class_create_release;
cls-release = class_device_create_release;
+ cls-parent = parent;
retval = class_register(cls);
if (retval)
@@ -738,8 +777,8 @@ EXPORT_SYMBOL_GPL(class_register);
EXPORT_SYMBOL_GPL(class_unregister);
EXPORT_SYMBOL_GPL(class_get);
EXPORT_SYMBOL_GPL(class_put);
-EXPORT_SYMBOL_GPL(class_create);
+EXPORT_SYMBOL_GPL(class_subclass_create);
EXPORT_SYMBOL_GPL(class_destroy);
EXPORT_SYMBOL_GPL(class_device_register);
--- linux-2.6/include/linux/device.h2005-07-06 14:21:20.0 -0400
+++ linux-2.6-input/include/linux/device.h 2005-07-08 18:39:16.0
-0400
@@ -155,11 +155,14 @@ struct device * driver_find_device(struc
struct class {
const char * name;
struct module * owner;
+ struct class* parent; /* for subclasses */
struct subsystemsubsys;
- struct list_headchildren;
+ struct list_headchildren; /* for class_devices */
struct list_headinterfaces;
- struct semaphoresem;/* locks both the children and
interfaces lists */
+ struct list_headsubclasses;
+ struct list_headsubclass_node; /* parent-sem held when
accessing */
+ struct semaphoresem;/* locks children, subclasses,
interfaces lists */
struct class_attribute * class_attrs;
struct class_device_attribute * class_dev_attrs;
@@ -258,7 +261,11 @@ struct class_interface {
extern int class_interface_register(struct class_interface *);
extern void class_interface_unregister(struct
Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 08:26:45PM +0100, Andi Kleen wrote:
> On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote:
> > For review and comment.
> >
> > On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever
> > there are any pages mapped above 4GB), pci_alloc_consistent() falls
> > back to using ZONE_DMA for all allocations, even if the device's
> > dma_mask could have supported using memory from other zones. Problems
> > can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
> > all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
> >
> > Patch below makes pci_alloc_consistent() for the nommu case (EM64T
> > processors) match the 2.6 implementation of dma_alloc_coherent(), with
> > the exception that this continues to use GFP_ATOMIC.
>
> You fixed the wrong code. The pci-nommu code is only used
> when IOMMU is disabled in the Kconfig. But most kernels have
> it enabled. You would need to change it in pci-gart.c too.
OK, then how's this for review? Compiles clean, can't test it myself
for a few days.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= arch/x86_64/kernel/pci-gart.c 1.12 vs edited =
--- 1.12/arch/x86_64/kernel/pci-gart.c 2004-06-03 05:29:36 -05:00
+++ edited/arch/x86_64/kernel/pci-gart.c2005-03-19 15:56:34 -06:00
@@ -154,27 +154,37 @@ void *pci_alloc_consistent(struct pci_de
int gfp = GFP_ATOMIC;
int i;
unsigned long iommu_page;
+ dma_addr_t dma_mask;
- if (hwdev == NULL || hwdev->dma_mask < 0x || no_iommu)
+ if (hwdev == NULL || hwdev->dma_mask < 0x)
gfp |= GFP_DMA;
+ dma_mask = hwdev ? hwdev->dma_mask : 0xULL;
+ if (dma_mask == 0)
+ dma_mask = 0xULL;
+
/*
-* First try to allocate continuous and use directly if already
-* in lowmem.
+* First try to allocate continuous and use directly if
+* our device supports it
*/
size = round_up(size, PAGE_SIZE);
+ again:
memory = (void *)__get_free_pages(gfp, get_order(size));
if (memory == NULL) {
return NULL;
} else {
- int high = 0, mmu;
- if (((unsigned long)virt_to_bus(memory) + size) > 0xUL)
- high = 1;
- mmu = high;
+ int high = (((unsigned long)virt_to_bus(memory) + size) &
~dma_mask) != 0;
+ int mmu = high;
if (force_mmu && !(gfp & GFP_DMA))
mmu = 1;
if (no_iommu) {
- if (high) goto error;
+ if (high && (gfp & GFP_DMA))
+ goto error;
+ if (high) {
+ free_pages((unsigned long)memory,
get_order(size));
+ gfp |= GFP_DMA;
+ goto again;
+ }
mmu = 0;
}
memset(memory, 0, size);
-
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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 07:09:45AM +0100, Arjan van de Ven wrote: > On Fri, 2005-03-18 at 15:23 -0600, Matt Domsch wrote: > > For review and comment. > > > > On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever > > there are any pages mapped above 4GB), pci_alloc_consistent() falls > > back to using ZONE_DMA for all allocations, even if the device's > > dma_mask could have supported using memory from other zones. Problems > > can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume > > all of ZONE_DMA, leaving none left for pci_alloc_consistent() use. > > scsi_malloc no longer uses ZONE_DMA nowadays In 2.4.x it does. scsi_resize_dma_pool() has: __get_free_pages(GFP_ATOMIC | GFP_DMA, 0); scsi_init_minimal_dma_pool() has similar. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 07:09:45AM +0100, Arjan van de Ven wrote: On Fri, 2005-03-18 at 15:23 -0600, Matt Domsch wrote: For review and comment. On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever there are any pages mapped above 4GB), pci_alloc_consistent() falls back to using ZONE_DMA for all allocations, even if the device's dma_mask could have supported using memory from other zones. Problems can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume all of ZONE_DMA, leaving none left for pci_alloc_consistent() use. scsi_malloc no longer uses ZONE_DMA nowadays In 2.4.x it does. scsi_resize_dma_pool() has: __get_free_pages(GFP_ATOMIC | GFP_DMA, 0); scsi_init_minimal_dma_pool() has similar. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
On Sat, Mar 19, 2005 at 08:26:45PM +0100, Andi Kleen wrote:
On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote:
For review and comment.
On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones. Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.
You fixed the wrong code. The pci-nommu code is only used
when IOMMU is disabled in the Kconfig. But most kernels have
it enabled. You would need to change it in pci-gart.c too.
OK, then how's this for review? Compiles clean, can't test it myself
for a few days.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= arch/x86_64/kernel/pci-gart.c 1.12 vs edited =
--- 1.12/arch/x86_64/kernel/pci-gart.c 2004-06-03 05:29:36 -05:00
+++ edited/arch/x86_64/kernel/pci-gart.c2005-03-19 15:56:34 -06:00
@@ -154,27 +154,37 @@ void *pci_alloc_consistent(struct pci_de
int gfp = GFP_ATOMIC;
int i;
unsigned long iommu_page;
+ dma_addr_t dma_mask;
- if (hwdev == NULL || hwdev-dma_mask 0x || no_iommu)
+ if (hwdev == NULL || hwdev-dma_mask 0x)
gfp |= GFP_DMA;
+ dma_mask = hwdev ? hwdev-dma_mask : 0xULL;
+ if (dma_mask == 0)
+ dma_mask = 0xULL;
+
/*
-* First try to allocate continuous and use directly if already
-* in lowmem.
+* First try to allocate continuous and use directly if
+* our device supports it
*/
size = round_up(size, PAGE_SIZE);
+ again:
memory = (void *)__get_free_pages(gfp, get_order(size));
if (memory == NULL) {
return NULL;
} else {
- int high = 0, mmu;
- if (((unsigned long)virt_to_bus(memory) + size) 0xUL)
- high = 1;
- mmu = high;
+ int high = (((unsigned long)virt_to_bus(memory) + size)
~dma_mask) != 0;
+ int mmu = high;
if (force_mmu !(gfp GFP_DMA))
mmu = 1;
if (no_iommu) {
- if (high) goto error;
+ if (high (gfp GFP_DMA))
+ goto error;
+ if (high) {
+ free_pages((unsigned long)memory,
get_order(size));
+ gfp |= GFP_DMA;
+ goto again;
+ }
mmu = 0;
}
memset(memory, 0, size);
-
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 2.4.30-pre3] x86_64: move init_tss declaration after tss_struct definition
Compiling 2.4.30-pre3 for x86_64 with FC4-test1 gcc-4.0.0-0.32 fails
because include/asm-x86_64/processor.h declares init_tss[NR_CPUS] as a
sized array before struct tss_struct has been defined. Simple fix
moves this declaration to after the definition of tss_struct.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= include/asm-x86_64/processor.h 1.9 vs edited =
--- 1.9/include/asm-x86_64/processor.h 2004-03-21 18:35:56 -06:00
+++ edited/include/asm-x86_64/processor.h 2005-03-18 14:56:30 -06:00
@@ -68,7 +68,6 @@
#define X86_VENDOR_UNKNOWN 0xff
extern struct cpuinfo_x86 boot_cpu_data;
-extern struct tss_struct init_tss[NR_CPUS];
#ifdef CONFIG_SMP
extern struct cpuinfo_x86 cpu_data[];
@@ -298,6 +297,8 @@
u16 io_map_base;
u32 io_bitmap[IO_BITMAP_SIZE];
} __attribute__((packed)) cacheline_aligned;
+
+extern struct tss_struct init_tss[NR_CPUS];
struct thread_struct {
unsigned long rsp0;
-
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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
For review and comment.
On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones. Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 13:01:44 2005
+++ linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 06:56:55 2005
@@ -13,18 +13,28 @@ void *pci_alloc_consistent(struct pci_de
dma_addr_t *dma_handle)
{
void *ret;
+ u64 mask;
+ int order = get_order(size);
int gfp = GFP_ATOMIC;
-
- if (hwdev == NULL ||
- end_pfn > (hwdev->dma_mask>>PAGE_SHIFT) || /* XXX */
- (u32)hwdev->dma_mask < 0x)
- gfp |= GFP_DMA;
- ret = (void *)__get_free_pages(gfp, get_order(size));
- if (ret != NULL) {
- memset(ret, 0, size);
+ if (hwdev)
+ mask = hwdev->dma_mask;
+ else
+ mask = 0xULL;
+
+ for (;;) {
+ ret = (void *)__get_free_pages(gfp, order);
+ if (ret == NULL)
+ return NULL;
*dma_handle = virt_to_bus(ret);
+ if ((*dma_handle & ~mask) == 0)
+ break;
+ free_pages((unsigned long)ret, order);
+ if (gfp & GFP_DMA)
+ return NULL;
+ gfp |= GFP_DMA;
}
+ memset(ret, 0, size);
return ret;
}
-
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 2.4.30-pre3] linux/fs.h: remove root_device_name declaration
include/linux/fs.h has: extern char root_device_name[]; but it's been declared static in init/do_mounts.c since March 2002. gcc-4.0.0-0.32 from FC4-test1 errors out due to the static/non-static mismatch. Time to kill it from include/linux/fs.h. Signed-off-by: Matt Domsch <[EMAIL PROTECTED]> -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com = include/linux/fs.h 1.100 vs edited = --- 1.100/include/linux/fs.h2005-02-07 12:30:59 -06:00 +++ edited/include/linux/fs.h 2005-03-18 15:00:48 -06:00 @@ -1559,7 +1559,6 @@ unsigned long generate_cluster(kdev_t, int b[], int); unsigned long generate_cluster_swab32(kdev_t, int b[], int); extern kdev_t ROOT_DEV; -extern char root_device_name[]; extern void show_buffers(void); - 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 2.4.30-pre3] linux/fs.h: remove root_device_name declaration
include/linux/fs.h has: extern char root_device_name[]; but it's been declared static in init/do_mounts.c since March 2002. gcc-4.0.0-0.32 from FC4-test1 errors out due to the static/non-static mismatch. Time to kill it from include/linux/fs.h. Signed-off-by: Matt Domsch [EMAIL PROTECTED] -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com = include/linux/fs.h 1.100 vs edited = --- 1.100/include/linux/fs.h2005-02-07 12:30:59 -06:00 +++ edited/include/linux/fs.h 2005-03-18 15:00:48 -06:00 @@ -1559,7 +1559,6 @@ unsigned long generate_cluster(kdev_t, int b[], int); unsigned long generate_cluster_swab32(kdev_t, int b[], int); extern kdev_t ROOT_DEV; -extern char root_device_name[]; extern void show_buffers(void); - 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 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation
For review and comment.
On x86_64 systems with no IOMMU and with 4GB RAM (in fact, whenever
there are any pages mapped above 4GB), pci_alloc_consistent() falls
back to using ZONE_DMA for all allocations, even if the device's
dma_mask could have supported using memory from other zones. Problems
can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
Patch below makes pci_alloc_consistent() for the nommu case (EM64T
processors) match the 2.6 implementation of dma_alloc_coherent(), with
the exception that this continues to use GFP_ATOMIC.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
--- linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 13:01:44 2005
+++ linux-2.4/arch/x86_64/kernel/pci-nommu.cFri Feb 25 06:56:55 2005
@@ -13,18 +13,28 @@ void *pci_alloc_consistent(struct pci_de
dma_addr_t *dma_handle)
{
void *ret;
+ u64 mask;
+ int order = get_order(size);
int gfp = GFP_ATOMIC;
-
- if (hwdev == NULL ||
- end_pfn (hwdev-dma_maskPAGE_SHIFT) || /* XXX */
- (u32)hwdev-dma_mask 0x)
- gfp |= GFP_DMA;
- ret = (void *)__get_free_pages(gfp, get_order(size));
- if (ret != NULL) {
- memset(ret, 0, size);
+ if (hwdev)
+ mask = hwdev-dma_mask;
+ else
+ mask = 0xULL;
+
+ for (;;) {
+ ret = (void *)__get_free_pages(gfp, order);
+ if (ret == NULL)
+ return NULL;
*dma_handle = virt_to_bus(ret);
+ if ((*dma_handle ~mask) == 0)
+ break;
+ free_pages((unsigned long)ret, order);
+ if (gfp GFP_DMA)
+ return NULL;
+ gfp |= GFP_DMA;
}
+ memset(ret, 0, size);
return ret;
}
-
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 2.4.30-pre3] x86_64: move init_tss declaration after tss_struct definition
Compiling 2.4.30-pre3 for x86_64 with FC4-test1 gcc-4.0.0-0.32 fails
because include/asm-x86_64/processor.h declares init_tss[NR_CPUS] as a
sized array before struct tss_struct has been defined. Simple fix
moves this declaration to after the definition of tss_struct.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= include/asm-x86_64/processor.h 1.9 vs edited =
--- 1.9/include/asm-x86_64/processor.h 2004-03-21 18:35:56 -06:00
+++ edited/include/asm-x86_64/processor.h 2005-03-18 14:56:30 -06:00
@@ -68,7 +68,6 @@
#define X86_VENDOR_UNKNOWN 0xff
extern struct cpuinfo_x86 boot_cpu_data;
-extern struct tss_struct init_tss[NR_CPUS];
#ifdef CONFIG_SMP
extern struct cpuinfo_x86 cpu_data[];
@@ -298,6 +297,8 @@
u16 io_map_base;
u32 io_bitmap[IO_BITMAP_SIZE];
} __attribute__((packed)) cacheline_aligned;
+
+extern struct tss_struct init_tss[NR_CPUS];
struct thread_struct {
unsigned long rsp0;
-
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: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas: Announcing new module for LSI Logic's SAS based MegaRAID controllers
attach a frame to each of the commands in cmd_list.
> + * By making cmd->index as the context instead of the , we can
> + * always use 32bit context regardless of the architecture
> + */
> + for( i = 0, cmd = instance->cmd_list; i < max_cmd; i++, cmd++ ) {
> +
> + cmd->frame = pci_pool_alloc( instance->frame_dma_pool,
> + GFP_KERNEL, >frame_phys_addr );
> +
> + cmd->sense = pci_pool_alloc( instance->sense_dma_pool,
> + GFP_KERNEL, >sense_phys_addr );
> +
> + if (!cmd->frame || !cmd->sense) {
> + printk(KERN_ERR "megasas: pci_pool_alloc failed
> \n");
> + megasas_teardown_frame_pool( instance );
> + return -ENOMEM;
> + }
If the second pci_pool_create() fails, you leak the first pool.
> +megasas_register_aen( struct megasas_instance* instance, uint32_t seq_num,
> + uint32_t* mbox_word;
s/uint32_t/u32/ everywhere. Likewise for the other sizes.
> +megasas_reset_handler( struct scsi_cmnd* scmd )
This reset command doesn't do anything except wait and hope. Any
chance there's a way to do a write to a bit in your adapter PCI
config space to force an adapter reset? Or some other manner? This
is a long-standing issue with the other LSI RAID cards too - you can't
effectively abort an issued command, and you can't reset the adapter
from the driver. Many of the megaraid issues seen by customers over
time is from adapter firmwares going catatonic. Having a real method
to reset the adapter would benefit users.
> +/**
> + * megasas_build_dcdb
> + */
What is a dcdb?
> +/**
> + * megasas_mgmt_open
> + */
> +static int
> +megasas_mgmt_open( struct inode* inode, struct file* filep )
Could you consider moving the management device code into a separate
file? This is getting long already...
> +/**
> + * megasas_mgmt_ioctl
> + */
> +static int
> +megasas_mgmt_ioctl( struct inode* inode, struct file* filep,
> + unsigned int cmd, unsigned long arg )
> +{
> + int i;
> + int j;
> + int rc;
> + uint8_t fw_status;
> + struct iocpacketuioc;
This is ~200 bytes. Seems large to put on the (4KB) stack.
> + case MR_LINUX_GET_ADAPTER_MAP:
> + /*
> + * README: encrypting logic for adapter map
> + * The adpater field size allows up to 16-bit adapter
> number,
> + * which translates into 65536 possible adapters, which
> + * obviously is too much. So we reserve the lower 4-bits to
> + * put the coding nibble (0xF) and add 1 to the adapter
> + * number. Applications shall have (12-bits - 1) to provide
> + * the adapter number. This still translates in 4095
> possible
> + * adapters, which should be sufficient :-)
> + */
While confusing, I appreciate the large comment about it.
> +/**
> + * megasas_mgmt_fw_smp
What is SMP in this instance?
> +/* vim: set ts=8 sw=8 tw=78 ai si: */
unnecessary. megaraid is about the only driver in the tree with
such a line (one USB serial dongle has it too, but that's it).
> diff -Naur linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h
> linux-2.6.11/drivers/scsi/megaraid/megaraid_sas.h
> --- linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h1969-12-31
> 19:00:00.0 -0500
> +++ linux-2.6.11/drivers/scsi/megaraid/megaraid_sas.h 2005-03-05
> 21:41:25.503377336 -0500
> +struct megasas_ctrl_prop {
> +
> + uint16_tseq_num;
Covered above, but again, use u16 rather than uint16_t. Likewise
their equivalents.
There's virtually no information exposed via sysfs. That would be a
welcome addition. A RAID device transport, exposing data common to
logical drives (RAID level, stripe size, health, cache mode, ...).
Very good start though.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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: [ANNOUNCE][PATCH 2.6.11 2/3] megaraid_sas: Announcing new module for LSI Logic's SAS based MegaRAID controllers
, uint32_t seq_num,
+ uint32_t* mbox_word;
s/uint32_t/u32/ everywhere. Likewise for the other sizes.
+megasas_reset_handler( struct scsi_cmnd* scmd )
This reset command doesn't do anything except wait and hope. Any
chance there's a way to do a write to a bit in your adapter PCI
config space to force an adapter reset? Or some other manner? This
is a long-standing issue with the other LSI RAID cards too - you can't
effectively abort an issued command, and you can't reset the adapter
from the driver. Many of the megaraid issues seen by customers over
time is from adapter firmwares going catatonic. Having a real method
to reset the adapter would benefit users.
+/**
+ * megasas_build_dcdb
+ */
What is a dcdb?
+/**
+ * megasas_mgmt_open
+ */
+static int
+megasas_mgmt_open( struct inode* inode, struct file* filep )
Could you consider moving the management device code into a separate
file? This is getting long already...
+/**
+ * megasas_mgmt_ioctl
+ */
+static int
+megasas_mgmt_ioctl( struct inode* inode, struct file* filep,
+ unsigned int cmd, unsigned long arg )
+{
+ int i;
+ int j;
+ int rc;
+ uint8_t fw_status;
+ struct iocpacketuioc;
This is ~200 bytes. Seems large to put on the (4KB) stack.
+ case MR_LINUX_GET_ADAPTER_MAP:
+ /*
+ * README: encrypting logic for adapter map
+ * The adpater field size allows up to 16-bit adapter
number,
+ * which translates into 65536 possible adapters, which
+ * obviously is too much. So we reserve the lower 4-bits to
+ * put the coding nibble (0xF) and add 1 to the adapter
+ * number. Applications shall have (12-bits - 1) to provide
+ * the adapter number. This still translates in 4095
possible
+ * adapters, which should be sufficient :-)
+ */
While confusing, I appreciate the large comment about it.
+/**
+ * megasas_mgmt_fw_smp
What is SMP in this instance?
+/* vim: set ts=8 sw=8 tw=78 ai si: */
unnecessary. megaraid is about the only driver in the tree with
such a line (one USB serial dongle has it too, but that's it).
diff -Naur linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h
linux-2.6.11/drivers/scsi/megaraid/megaraid_sas.h
--- linux-2.6.11-orig/drivers/scsi/megaraid/megaraid_sas.h1969-12-31
19:00:00.0 -0500
+++ linux-2.6.11/drivers/scsi/megaraid/megaraid_sas.h 2005-03-05
21:41:25.503377336 -0500
+struct megasas_ctrl_prop {
+
+ uint16_tseq_num;
Covered above, but again, use u16 rather than uint16_t. Likewise
their equivalents.
There's virtually no information exposed via sysfs. That would be a
welcome addition. A RAID device transport, exposing data common to
logical drives (RAID level, stripe size, health, cache mode, ...).
Very good start though.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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] EFI missing failure handling
On Sat, Mar 05, 2005 at 09:17:34PM +0100, Panagiotis Issaris wrote: > Hi, > > On Sat, Mar 05, 2005 at 07:06:29PM +0200 or thereabouts, Alexey Dobriyan > wrote: > > On Saturday 05 March 2005 17:38, Panagiotis Issaris wrote: > > > > > The EFI driver allocates memory and writes into it without checking the > > > success of the allocation: > > > > > > 668 efi_char16_t *variable_name = kmalloc(1024, GFP_KERNEL); > > > ... > > > 696 memset(variable_name, 0, 1024); > > > > > --- linux-2.6.11-orig/drivers/firmware/efivars.c > > > +++ linux-2.6.11-pi/drivers/firmware/efivars.c > > > @@ -670,6 +670,9 @@ efivars_init(void) > > > > > + if (!variable_name) > > > + return -ENOMEM; > > > + > > > if (!efi_enabled) > > > return -ENODEV; > > > > I'd better move kmalloc() and checking for success down right before > > memset(). Otherwise you leak if efi_enabled == 0. > > Oh, and efivars_init() wants to return "error", not unconditionally 0. > > > > Alexey > > Thanks! How about the updated patch? Looks good to me. Good catch, and thanks for the patch! Please forward to Andrew Morton ([EMAIL PROTECTED]) directly, following the format described here: http://linux.yyz.us/patch-format.html Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] EFI missing failure handling
On Sat, Mar 05, 2005 at 09:17:34PM +0100, Panagiotis Issaris wrote: Hi, On Sat, Mar 05, 2005 at 07:06:29PM +0200 or thereabouts, Alexey Dobriyan wrote: On Saturday 05 March 2005 17:38, Panagiotis Issaris wrote: The EFI driver allocates memory and writes into it without checking the success of the allocation: 668 efi_char16_t *variable_name = kmalloc(1024, GFP_KERNEL); ... 696 memset(variable_name, 0, 1024); --- linux-2.6.11-orig/drivers/firmware/efivars.c +++ linux-2.6.11-pi/drivers/firmware/efivars.c @@ -670,6 +670,9 @@ efivars_init(void) + if (!variable_name) + return -ENOMEM; + if (!efi_enabled) return -ENODEV; I'd better move kmalloc() and checking for success down right before memset(). Otherwise you leak if efi_enabled == 0. Oh, and efivars_init() wants to return error, not unconditionally 0. Alexey Thanks! How about the updated patch? Looks good to me. Good catch, and thanks for the patch! Please forward to Andrew Morton ([EMAIL PROTECTED]) directly, following the format described here: http://linux.yyz.us/patch-format.html Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: EDD failures since edd=off patch
On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
> Hi Matt,
>
> it seems the edd=off patch has caused some problems with
> some machines I have access to. They simply don't boot
> anymore unless I specify edd=foo. foo can be {off,skip,bar}
> so it seems the hang on boot is related to the parser
> not finding the parameter it is looking for.
> I looked through the code some days ago and it seemed to
> me that the register used to iterate through the command
> line buffer only got its lower 16 bit reset before calling
> into the BIOS. I don't have the code handy right now,
> but I can look later if the hints I gave are insufficient.
Yes, please. I'm reading the code, and %ecx gets set to
(COMMAND_LINE_SIZE-7) which is 256-7=249. So the upper 24 bits of
%ecx are going to always be zero, and if "edd=" isn't seen, then %ecx
will be zero when dropping into edd_mbr_sig_start. The only other
register touched is %esi, but it's pushed at the beginning, and pop'd
on all exit cases, so that should be unchanged.
ZF is the only other bit I can picture. On the "no edd= option" path,
ZF=0 on exit. With "edd=of" or "edd=sk", ZF=1. But with "edd=bar",
ZF=0, which you say works too. So that's not it...
CF is taken care of around the int13 calls already, so that's not
it...
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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: EDD failures since edd=off patch
On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through the code some days ago and it seemed to
me that the register used to iterate through the command
line buffer only got its lower 16 bit reset before calling
into the BIOS. I don't have the code handy right now,
but I can look later if the hints I gave are insufficient.
Yes, please. I'm reading the code, and %ecx gets set to
(COMMAND_LINE_SIZE-7) which is 256-7=249. So the upper 24 bits of
%ecx are going to always be zero, and if edd= isn't seen, then %ecx
will be zero when dropping into edd_mbr_sig_start. The only other
register touched is %esi, but it's pushed at the beginning, and pop'd
on all exit cases, so that should be unchanged.
ZF is the only other bit I can picture. On the no edd= option path,
ZF=0 on exit. With edd=of or edd=sk, ZF=1. But with edd=bar,
ZF=0, which you say works too. So that's not it...
CF is taken care of around the int13 calls already, so that's not
it...
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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 2.6.11-rc3] cpufreq-core: reduce warning messages
cpufreq core is printing out messages at KERN_WARNING level that the
core recovers from without intervention, and that the system
administrator can do nothing about. Patch below reduces the severity
of these messages to debug.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= cpufreq.c 1.94 vs edited =
--- 1.94/drivers/cpufreq/cpufreq.c 2005-01-20 23:02:15 -06:00
+++ edited/cpufreq.c2005-02-03 11:16:16 -06:00
@@ -258,7 +258,7 @@ void cpufreq_notify_transition(struct cp
(likely(cpufreq_cpu_data[freqs->cpu]->cur)) &&
(unlikely(freqs->old !=
cpufreq_cpu_data[freqs->cpu]->cur)))
{
- printk(KERN_WARNING "Warning: CPU frequency is
%u, "
+ dprintk("CPU frequency is %u, "
"cpufreq assumed %u kHz.\n", freqs->old,
cpufreq_cpu_data[freqs->cpu]->cur);
freqs->old = cpufreq_cpu_data[freqs->cpu]->cur;
}
@@ -814,7 +814,7 @@ static void cpufreq_out_of_sync(unsigned
{
struct cpufreq_freqs freqs;
- printk(KERN_WARNING "Warning: CPU frequency out of sync: cpufreq and
timing "
+ dprintk("CPU frequency out of sync: cpufreq and timing "
"core thinks of %u, is %u kHz.\n", old_freq, new_freq);
freqs.cpu = cpu;
@@ -919,7 +919,7 @@ static int cpufreq_resume(struct sys_dev
if (unlikely(cur_freq != cpu_policy->cur)) {
struct cpufreq_freqs freqs;
- printk(KERN_WARNING "Warning: CPU frequency is %u, "
+ dprintk("CPU frequency is %u, "
"cpufreq assumed %u kHz.\n", cur_freq,
cpu_policy->cur);
freqs.cpu = 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 2.6.11-rc3] cpufreq-core: reduce warning messages
cpufreq core is printing out messages at KERN_WARNING level that the
core recovers from without intervention, and that the system
administrator can do nothing about. Patch below reduces the severity
of these messages to debug.
Signed-off-by: Matt Domsch [EMAIL PROTECTED]
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= cpufreq.c 1.94 vs edited =
--- 1.94/drivers/cpufreq/cpufreq.c 2005-01-20 23:02:15 -06:00
+++ edited/cpufreq.c2005-02-03 11:16:16 -06:00
@@ -258,7 +258,7 @@ void cpufreq_notify_transition(struct cp
(likely(cpufreq_cpu_data[freqs-cpu]-cur))
(unlikely(freqs-old !=
cpufreq_cpu_data[freqs-cpu]-cur)))
{
- printk(KERN_WARNING Warning: CPU frequency is
%u,
+ dprintk(CPU frequency is %u,
cpufreq assumed %u kHz.\n, freqs-old,
cpufreq_cpu_data[freqs-cpu]-cur);
freqs-old = cpufreq_cpu_data[freqs-cpu]-cur;
}
@@ -814,7 +814,7 @@ static void cpufreq_out_of_sync(unsigned
{
struct cpufreq_freqs freqs;
- printk(KERN_WARNING Warning: CPU frequency out of sync: cpufreq and
timing
+ dprintk(CPU frequency out of sync: cpufreq and timing
core thinks of %u, is %u kHz.\n, old_freq, new_freq);
freqs.cpu = cpu;
@@ -919,7 +919,7 @@ static int cpufreq_resume(struct sys_dev
if (unlikely(cur_freq != cpu_policy-cur)) {
struct cpufreq_freqs freqs;
- printk(KERN_WARNING Warning: CPU frequency is %u,
+ dprintk(CPU frequency is %u,
cpufreq assumed %u kHz.\n, cur_freq,
cpu_policy-cur);
freqs.cpu = 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] Prevent NMI oopser
On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: > >As a hack, one could #define inline /*nothing*/ in megaraid2.h to > >avoid this, but it would be nice if the functions could all get > >reordered such that inlining works properly, and the need for function > >declarations in megaraid2.h would disappear completely. > > > Could you fix it by additional patch? Or you going to prepare a new one? Here's the hack patch (will apply after yours). Signed-off-by: Matt Domsch <[EMAIL PROTECTED]> -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com = drivers/scsi/megaraid2.h 1.6 vs edited = --- 1.6/drivers/scsi/megaraid2.h2005-02-02 13:48:22 -06:00 +++ edited/drivers/scsi/megaraid2.h 2005-02-02 13:55:42 -06:00 @@ -5,6 +5,18 @@ #include +/* This is an ugly hack, but gets around the fact that earlier + * versions of gcc ignores the inline specification when + * the function definition comes after function use (thereby + * not inlining the code), and newer gcc fails to compile the + * code. This should be removed once the functions are properly + * ordered in megaraid2.c, and the function declarations removed + * in megaraid2.h. + */ +#undef inline +#define inline /*nothing*/ + + #define MEGARAID_VERSION \ "v2.10.8.2 (Release Date: Mon Jul 26 12:15:51 EDT 2004)\n" - 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] Prevent NMI oopser
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: > Marcelo Tosatti wrote: > >On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: > >>You should unlock io_request_lock before msleep, like in latest versions > >>of megaraid2 drivers. > > > >Andrey, > > > >Can you please update your patch to unlock io_request_lock before sleeping > >and locking after coming back? > > > >What the driver is doing is indeed wrong. > > Marcelo, > > This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible > version that I've seen), taken from latest RHEL3 kernel update. I > believe it should prevent NMI in abort/reset handler. > > Thank you, > Vasily Averin, SWSoft Linux Kernel Team Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] Prevent NMI oopser
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote: Marcelo Tosatti wrote: On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote: You should unlock io_request_lock before msleep, like in latest versions of megaraid2 drivers. Andrey, Can you please update your patch to unlock io_request_lock before sleeping and locking after coming back? What the driver is doing is indeed wrong. Marcelo, This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible version that I've seen), taken from latest RHEL3 kernel update. I believe it should prevent NMI in abort/reset handler. Thank you, Vasily Averin, SWSoft Linux Kernel Team Thanks Vasily, I was just looking at this again yesterday. You'll also find that because the driver doesn't define its inline functions prior to their use, newest compilers refuse to compile this version of the driver. Earlier compilers just ignore it and don't inline anything. As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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] Prevent NMI oopser
On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote: As a hack, one could #define inline /*nothing*/ in megaraid2.h to avoid this, but it would be nice if the functions could all get reordered such that inlining works properly, and the need for function declarations in megaraid2.h would disappear completely. Could you fix it by additional patch? Or you going to prepare a new one? Here's the hack patch (will apply after yours). Signed-off-by: Matt Domsch [EMAIL PROTECTED] -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com = drivers/scsi/megaraid2.h 1.6 vs edited = --- 1.6/drivers/scsi/megaraid2.h2005-02-02 13:48:22 -06:00 +++ edited/drivers/scsi/megaraid2.h 2005-02-02 13:55:42 -06:00 @@ -5,6 +5,18 @@ #include linux/spinlock.h +/* This is an ugly hack, but gets around the fact that earlier + * versions of gcc ignores the inline specification when + * the function definition comes after function use (thereby + * not inlining the code), and newer gcc fails to compile the + * code. This should be removed once the functions are properly + * ordered in megaraid2.c, and the function declarations removed + * in megaraid2.h. + */ +#undef inline +#define inline /*nothing*/ + + #define MEGARAID_VERSION \ v2.10.8.2 (Release Date: Mon Jul 26 12:15:51 EDT 2004)\n - 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: [Announce] megaraid_mbox 2.20.4.3 patch
On Tue, Jan 25, 2005 at 07:52:42PM -0500, Ju, Seokmann wrote: > Hello, > > Here is a patch for megaraid_mbox 2.20.4.3 and megaraid_mm 2.20.2.5. > The patch includes following changes/fixes > - sysfs support for drive addition/removal > - Tape drive timeout issue > - Made some code static > > I am attaching and inlining the patch. This patch is mangled. Long lines are wrapped, and appears to be in ISO-8859-1, such that spaces (ascii 0x20) appear as hex 0xa0. This makes it difficult to review, and impossible to apply. +// definitions for the device attributes for exporting logical drive number +// for a scsi address (Host, Channel, Id, Lun) + +CLASS_DEVICE_ATTR(megaraid_mbox_app_hndl, S_IRUSR, megaraid_sysfs_show_app_hndl, + NULL); How is this being used by your apps please? Otherwise the patch looks sane. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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: [Announce] megaraid_mbox 2.20.4.3 patch
On Tue, Jan 25, 2005 at 07:52:42PM -0500, Ju, Seokmann wrote: Hello, Here is a patch for megaraid_mbox 2.20.4.3 and megaraid_mm 2.20.2.5. The patch includes following changes/fixes - sysfs support for drive addition/removal - Tape drive timeout issue - Made some code static I am attaching and inlining the patch. This patch is mangled. Long lines are wrapped, and appears to be in ISO-8859-1, such that spaces (ascii 0x20) appear as hex 0xa0. This makes it difficult to review, and impossible to apply. +// definitions for the device attributes for exporting logical drive number +// for a scsi address (Host, Channel, Id, Lun) + +CLASS_DEVICE_ATTR(megaraid_mbox_app_hndl, S_IRUSR, megaraid_sysfs_show_app_hndl, + NULL); How is this being used by your apps please? Otherwise the patch looks sane. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - 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/
[RFC][PATCH 2.6.11-rc2] vmlinux: put built-in module parameter info in vmlinux
Module parameter descriptions are added to loadable modules, but is
omitted from objects built into the kernel itself. It would be nice
if you could get the list of parameters usable on the kernel command
line by looking at vmlinux.
$ modinfo vmlinux | grep parm:
parm: thermal.tzp:Thermal zone polling frequency, in 1/10 seconds.
parm: drm.drm_debug:Enable debug output
parm: drm.drm_cards_limit:Maximum number of graphics cards
parm: i8042.debug:Turn i8042 debugging mode on and off
parm: i8042.noacpi:Do not use ACPI to detect controller settings
parm: i8042.dumbkbd:Disable the AUX Loopback command while probing
for the AUX port
parm: i8042.dumbkbd:Pretend that controller can only read data from
keyboard
parm: i8042.direct:Put keyboard port into non-translated mode.
parm: i8042.reset:Reset controller during init and cleanup.
parm: i8042.unlock:Ignore keyboard lock.
parm: i8042.nomux:Do not check whether an active multiplexing
conrtoller is present.
parm: i8042.noaux:Do not probe or use AUX (mouse) port.
parm: 8250.probe_rsa:Probe I/O ports for RSA
parm: 8250.share_irqs:Share IRQs with other non-8250/16x50 devices
(unsafe)
parm: rd.rd_blocksize:Blocksize of each RAM disk in bytes.
parm: rd.rd_size:Size of each RAM disk in kbytes.
parm: usbcore.use_both_schemes:try the other device initialization
scheme if the first one fails
parm: usbcore.old_scheme_first:start with the old device
initialization scheme
parm: usbcore.blinkenlights:true to cycle leds on hubs
parm: usbcore.usbfs_snoop:true to log all usbfs traffic
parm: mousedev.tap_time:Tap time for touchpads in absolute mode
(msecs)
parm: mousedev.yres:Vertical screen resolution
parm: mousedev.xres:Horizontal screen resolution
parm: atkbd.extra:Enable extra LEDs and keys on IBM RapidAcces, EzKey
and similar keyboards
parm: atkbd.scroll:Enable scroll-wheel on MS Office and similar
keyboards
parm: atkbd.softraw:Use software generated rawmode
parm: atkbd.softrepeat:Use software keyboard repeat
parm: atkbd.reset:Reset keyboard during initialization
parm: atkbd.set:Select keyboard code set (2 = default, 3 = PS/2
native)
parm: psmouse.resetafter:Reset device after so many bad packets (0 =
never).
parm: psmouse.smartscroll:Logitech Smartscroll autorepeat, 1 =
enabled (default), 0 = disabled.
parm: psmouse.rate:Report rate, in reports per second.
parm: psmouse.resolution:Resolution, in dpi.
parm: psmouse.proto:Highest protocol extension to probe (bare, imps,
exps). Useful for KVM switches.
Patch below implements such. It also emits modulename.version fields
should they exist, but omits license, author, and description fields,
as I'm not sure how interesting those fields are when built-in.
Feedback requested prior to submission for inclusion.
Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
= include/linux/module.h 1.92 vs edited =
--- 1.92/include/linux/module.h 2005-01-10 13:28:15 -06:00
+++ edited/include/linux/module.h 2005-01-31 17:59:23 -06:00
@@ -76,14 +79,27 @@
extern struct subsystem module_subsys;
+/* You can override this manually, but generally this should match the
+ module name. */
#ifdef MODULE
+#define MODULE_PARAM_PREFIX /* empty */
+#else
+#define MODULE_PARAM_PREFIX __stringify(KBUILD_MODNAME) "."
+#endif
+
#define ___module_cat(a,b) __mod_ ## a ## b
#define __module_cat(a,b) ___module_cat(a,b)
#define __MODULE_INFO(tag, name, info) \
static const char __module_cat(name,__LINE__)[]
\
__attribute_used__ \
- __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
+ __attribute__((section(".modinfo"),unused)) = MODULE_PARAM_PREFIX
__stringify(tag) "=" info
+
+#define ___MODULE_INFO(tag, name, info)
\
+static const char __module_cat(name,__LINE__)[]
\
+ __attribute_used__ \
+ __attribute__((section(".modinfo"),unused)) = __stringify(tag) "="
MODULE_PARAM_PREFIX info
+#ifdef MODULE
#define MODULE_GENERIC_TABLE(gtype,name) \
extern const struct gtype##_id __mod_##gtype##_table \
__attribute__ ((unused, alias(__stringify(name
@@ -94,7 +110,6 @@
#else /* !MODULE */
#define MODULE_GENERIC_TABLE(gtype,name)
-#define __MODULE_INF
