From davidz at redhat.com Sat Sep 1 15:04:04 2007 From: davidz at redhat.com (David Zeuthen) Date: Sat, 01 Sep 2007 11:04:04 -0400 Subject: 2.6.23 and newer kernel and option ACPI_PROC_EVENT. In-Reply-To: <20070829211435.GB31876@redhat.com> References: <46D5256F.4080901@redhat.com> <20070829081745.GA15223@redhat.com> <46D53E7C.9030000@redhat.com> <20070829211435.GB31876@redhat.com> Message-ID: <1188659044.10186.20.camel@oneill.fubar.dk> (Moving from fedora-devel-list to fedora-kernel-list) On Wed, 2007-08-29 at 17:14 -0400, Dave Jones wrote: > On Wed, Aug 29, 2007 at 11:38:04AM +0200, Zdenek Prikryl wrote: > > > > > I think acpid will have to be ported to this new ABI. > > > > > Yes, acpid will have to be ported, but it takes some time. But > > meanwhile, I think it is useful to enable old code. > > Yes, I'll turn it back on for F8. I disabled it to find out > just how much stuff is depending on it. Seems just acpid :-) Also hal. We still need /proc/acpi/event as the ACPI battery and ac_adapter drivers in the kernel haven't been ported to use sysfs. Hence, without the /proc/acpi/event socket we don't get change notifications [1]. Actually I'm unsure what the sysfs interfaces will end up looking like and how change notification will work. Does anyone know? I know dwmw2 did some work here (for OLPC) defining a sysfs class but I've also seen other patches with different interfaces fly by. Richard added support in hal for at least one of these [2] so maybe it will just work out of the box. dwmw2? David [1] : Actually we do poll all battery and ac_adapter devices every 30 secs (because some hardware is broken) so the changes are propagated to policy agents like gnome-power-manager with a 0-30 sec delay. [2] : http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=356ccdfa3bbf64648c48da8b756eaccef13d0dd9;hp=a2baf6b11fed6d64bf4e01db6e9a0fe279d7ee43 From nicolas.mailhot at laposte.net Sun Sep 2 15:06:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Sep 2007 17:06:40 +0200 Subject: kernel spec changes for custom mm builds Message-ID: <1188745600.14930.3.camel@rousalka.dyndns.org> Hi, Are the following changes totally insane, or could they be considered for merging? (partially build-tested, got to the point the -mm build didn't like me, I need to tweak my config file) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: kernelspec-mm-customconfig.patch Type: text/x-patch Size: 4880 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sun Sep 2 19:12:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 02 Sep 2007 21:12:47 +0200 Subject: kernel spec changes for custom mm builds In-Reply-To: <1188745600.14930.3.camel@rousalka.dyndns.org> References: <1188745600.14930.3.camel@rousalka.dyndns.org> Message-ID: <1188760368.3784.0.camel@rousalka.dyndns.org> Built, installed and booted a kernel using the patch now. So there is at least one system on which it works;) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwmw2 at infradead.org Sat Sep 8 11:40:10 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 08 Sep 2007 12:40:10 +0100 Subject: 2.6.23 and newer kernel and option ACPI_PROC_EVENT. In-Reply-To: <1188659044.10186.20.camel@oneill.fubar.dk> References: <46D5256F.4080901@redhat.com> <20070829081745.GA15223@redhat.com> <46D53E7C.9030000@redhat.com> <20070829211435.GB31876@redhat.com> <1188659044.10186.20.camel@oneill.fubar.dk> Message-ID: <1189251610.3488.280.camel@pmac.infradead.org> On Sat, 2007-09-01 at 11:04 -0400, David Zeuthen wrote: > (Moving from fedora-devel-list to fedora-kernel-list) > > On Wed, 2007-08-29 at 17:14 -0400, Dave Jones wrote: > > On Wed, Aug 29, 2007 at 11:38:04AM +0200, Zdenek Prikryl wrote: > > > > > > > I think acpid will have to be ported to this new ABI. > > > > > > > Yes, acpid will have to be ported, but it takes some time. But > > > meanwhile, I think it is useful to enable old code. > > > > Yes, I'll turn it back on for F8. I disabled it to find out > > just how much stuff is depending on it. Seems just acpid :-) > > Also hal. We still need /proc/acpi/event as the ACPI battery and > ac_adapter drivers in the kernel haven't been ported to use sysfs. > Hence, without the /proc/acpi/event socket we don't get change > notifications [1]. > > Actually I'm unsure what the sysfs interfaces will end up looking like > and how change notification will work. Does anyone know? I know dwmw2 > did some work here (for OLPC) defining a sysfs class but I've also seen > other patches with different interfaces fly by. Richard added support in > hal for at least one of these [2] so maybe it will just work out of the > box. dwmw2? Sorry for delayed response -- I am currently unable to read the mailbox you sent this to. The sysfs battery class stuff (which also covers AC since they're really quite similar) is merged into 2.6.23. You get a uevent when stuff changes, although the precise details of _when_ you get that uevent are dependent on the back end, and you might find that some back ends don't do it yet at all. We could do with standardising that somehow, or at least having some way to let userspace _know_ that it needs polling. The ACPI back end isn't yet merged -- it's being developed by Alexey Starikovskiy, and can be found on the linux-acpi mailing list: http://www.mail-archive.com/linux-acpi at vger.kernel.org/msg08858.html http://www.mail-archive.com/linux-acpi at vger.kernel.org/msg08856.html http://www.mail-archive.com/linux-acpi at vger.kernel.org/msg08859.html http://www.mail-archive.com/linux-acpi at vger.kernel.org/msg08857.html http://www.mail-archive.com/linux-acpi at vger.kernel.org/msg08855.html -- dwmw2 From konradr at redhat.com Mon Sep 10 19:18:39 2007 From: konradr at redhat.com (Konrad Rzeszutek) Date: Mon, 10 Sep 2007 15:18:39 -0400 Subject: [PATCH] Add iSCSI iBFT patch to the kernel. Message-ID: <20070910191839.GA1958@mars.boston.redhat.com> The patch below has been tested on a bunch of HP, Dell, NEC, and IBM machines by me and works without trouble. I was humbly wondering if Fedora kernel community would be OK picking this patch it up so that it can be tested on some other platforms before I go forth on LKML with it? And obviously, any comments on the patch are much appreciated. The testing is to make sure that this patch does not panic the box when it scans the memory (find_ibft function). For those that don't know what iSCSI is, here is a nice description: http://en.wikipedia.org/wiki/ISCSI and here http://linux-iscsi.sourceforge.net/ The issue at hand is to support iSCSI boot automatically. Right now when Fedora Core is installed on a iSCSI target and booted up from a NIC that supports software iSCSI initiator (the NIC firmware "exports" a disk) all the connection information (IQN, IP, CHAP password, etc) are all hard-coded in the initrd. This is OK, except when the password changes (and programmed in the NIC) the initrd can't boot anymore (unless the system admin also logged in the machine and changed the settings and re-created the initrd before rebooting the box). The goal is to have the initrd able to extract the iSCSI information from the NIC and use them. The patch below is one step in making this goal. The other necessary parts for this are to have iscsi-initirator-utils support this (upstream has the patches for this), and anaconda (not yet there). Thank you for your time. ----- PATCH: ----- This patch adds a /sysfs/firmware/ibft/table binary blob which exports the iSCSI Boot Firmware Table (iBFT) structure. What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI tools to extract from the machine NICs the iSCSI connection information so that they can automagically mount the iSCSI share/target. Currently the iSCSI information is hard-coded in the initrd. To enable this please set CONFIG_ISCSI_IBFT to m. The full details of the structure are located at: ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf Signed-off-by: Konrad Rzeszutek Signed-off-by: Peter Jones diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c index d474cd6..11d700f 100644 --- a/arch/i386/kernel/setup.c +++ b/arch/i386/kernel/setup.c @@ -46,7 +46,7 @@ #include #include #include #include - +#include #include