try_module_get code understanding
Dear List,
I agree that this issue certainly doesn't require to be in this list (rightful
place being kernewbies) but I tried that and got no response - so trying my luck
here.
I was going through try_module_get function in include/linux/module.h file
(2.6.22 stock kernel) - which is like:
-
static inline int try_module_get(struct module *module){
int ret = 1; <--- error case when !module
if (module) {
unsigned int cpu = get_cpu();
if (likely(module_is_live(module)))
local_inc(>ref[cpu].count);
else
ret = 0; <--- error case
put_cpu();
}
return ret; <
}
What I understand about the code flow is:
-- module live would return the flag stating that this module can be reference
and is NOT being removed currently.
1. In case the module pointer passed is invalid (NULL) this function would
return 1 (error case)
2. In case the module pointer is OK, and module is currently not being removed,
reference count would be incremented and 1 returned (non error case)
3. In case the module pointer is OK, and module reference count can NOT be
increased, 0 would be returned (error case).
As you can observe from above points, 0 and 1 are returned for error cases. I am
a little confused and wondering if there is something which I am missing in this
code??.
Can anyone help me out with this? Any help would be highly appreciated.
Regards
Shreyansh
-
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: jbd : config_jbd_debug cannot create /proc entry
On Wed, 26 Sep 2007 14:35:39 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Sep 2007 16:36:08 +0200
> Jan Kara <[EMAIL PROTECTED]> wrote:
>
> > > On Tue, 25 Sep 2007 07:49:38 -0500
> > > "Jose R. Santos" <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Tue, 25 Sep 2007 13:50:46 +0200
> > > > Jan Kara <[EMAIL PROTECTED]> wrote:
> > > > > > Jan Kara wrote:
> > > > > > >>
> > > > > > >-#define create_jbd_proc_entry() do {} while (0)
> > > > > > >-#define remove_jbd_proc_entry() do {} while (0)
> > > > > > >+static ctl_table fs_table[] = {
> > > > > > >+ {
> > > > > > >+.ctl_name = -1, /* Don't want it */
> > > > > >
> > > > > >
> > > > > >
> > > > > > shouldn't this be CTL_UNNUMBERED ?
> > > > > Oh, it should be. I didn't notice we have this :) Thanks for
> > > > > notifying
> > > > > me. Attached is a fixed version.
> > > >
> > > > This was fixed in JBD2 by moving the jbd-debug file to debugfs:
> > > > http://lkml.org/lkml/2007/7/11/334
> > > >
> > > > Since this code is already in the kernel, we should keep it consistent.
> > > >
> > >
> > > OK. Here's a quick patch to fix this. Adapted from the JBD2 patch.
> > > Let me know what you think.
> > Looks fine - exactly what I've just done here :).
>
> hm. I found rather a lot of issues. If this patch is derived from the
> JBD2 patch then perhaps the JBD2 patch needs some looking at.
Some of the changes do apply to the JBD2 patch. I'll send a cleanup patch.
>
> > > Signed-off-by: Jose R. Santos <[EMAIL PROTECTED]>
> > You can add Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
>
> I suspect you might be getting your signed-off-bys and acked-bys mixed up.
> (If not this patch, then the previous one). Please see
> Documentation/SubmittingPatches section 13 for the difference.
>
> Jose, please review and if possible runtime test these proposed changes?
Agree with all the changes and they worked as expected on my system.
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> - use `#ifdef foo' instead of `#if defined(foo)'
>
> - CONFIG_JBD_DEBUG depends on CONFIG_DEBUG_FS so we don't need to duplicate
> that logic in the .c file ifdefs
>
> - Make journal_enable_debug __read_mostly just for the heck of it
>
> - Make jbd_debugfs_dir and jbd_debug static
>
> - debugfs_remove(NULL) is legal: remove unneeded tests
>
> - jbd_create_debugfs_entry is a better name than create_jbd_debugfs_entry
>
> - ditto remove_jbd_debugfs_entry
>
> - C functions are preferred over macros
>
> Cc: "Jose R. Santos" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Cc: Jan Kara <[EMAIL PROTECTED]>
> Cc: Jose R. Santos <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Acked-by: Jose R. Santos <[EMAIL PROTECTED]>
-JRS
-
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: sata_sil24 broken since 2.6.23-rc4-mm1
Tejun Heo wrote: > Torsten Kaiser wrote: >> Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the >> following change looked the most suspicions to me: >> http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=blobdiff;f=drivers/ata/sata_sil24.c;h=3dcb223117be9739ee04d70b6bfc776a4b839a3f;hp=e0cd31aa8002350add53ba6ff07493e503275244;hb=020bc1bd8d369a77bd9379cd9763ac0057651753;hpb=8d4bdf8087e682df98bdb856f6ad451bf6d597e7 >> >> That after rc4-mm1 the sata_sil24.c did not change anymore also >> matches the occurrence of the error. >> >> To confirm my theorie I exchanged the sata_sil24.c from rc8-mm1 with >> the version from rc3-mm1. >> I was able to boot the resulting kernel successfully 5 times, without >> the error happening again. > > Thanks a lot for chasing down the problem. The changed code is address > initialization path and it's weird that it causes intermittent failures, > not a consistent one. > > Anyways, does the attached patch fix the problem? If not, can you add printk of iomap[SIL24_PORT_BAR], offset, initialized cmd_addr and scr_addr in the loop and see whether anything is different between when the driver works and fails. Thanks. -- tejun - 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: sata_sil24 broken since 2.6.23-rc4-mm1
Torsten Kaiser wrote: > Comparing the driver/ata directory from rc3-mm1 and rc4-mm1 the > following change looked the most suspicions to me: > http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=blobdiff;f=drivers/ata/sata_sil24.c;h=3dcb223117be9739ee04d70b6bfc776a4b839a3f;hp=e0cd31aa8002350add53ba6ff07493e503275244;hb=020bc1bd8d369a77bd9379cd9763ac0057651753;hpb=8d4bdf8087e682df98bdb856f6ad451bf6d597e7 > > That after rc4-mm1 the sata_sil24.c did not change anymore also > matches the occurrence of the error. > > To confirm my theorie I exchanged the sata_sil24.c from rc8-mm1 with > the version from rc3-mm1. > I was able to boot the resulting kernel successfully 5 times, without > the error happening again. Thanks a lot for chasing down the problem. The changed code is address initialization path and it's weird that it causes intermittent failures, not a consistent one. Anyways, does the attached patch fix the problem? -- tejun diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c index 3831920..dc3ddcb 100644 --- a/drivers/ata/sata_sil24.c +++ b/drivers/ata/sata_sil24.c @@ -1117,6 +1117,7 @@ static int sil24_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) host->ports[i]->ioaddr.cmd_addr = port; host->ports[i]->ioaddr.scr_addr = port + PORT_SCONTROL; + ata_std_ports(>ioaddr); ata_port_pbar_desc(ap, SIL24_HOST_BAR, -1, "host"); ata_port_pbar_desc(ap, SIL24_PORT_BAR, offset, "port");
Re: [PATCH] Add iSCSI iBFT support.
On Wed, 26 Sep 2007 20:52:43 -0400 Konrad Rzeszutek wrote: > > > +config ISCSI_IBFT > > > + tristate "iSCSI Boot Firmware Table Attributes" > > > + depends on X86 > > > > why only on X86? > > PowerPC exports this data via the OpenFirmware so it already shows in > the /sysfs entries. I was thinking to combine those sysfs entries under this > code, but that is something in the future. > > In regards to all other platforms, I figured I would only make it supported > under platforms that have been tested. Is there anything that stops this from > working for example of IA64? Well no. The hardware that supports the iBFT is > either in the BIOS or in NICs - so the SGI or HP boxes _should_ work, however > I am not comfortable to make it supported unless I've tested it. That's not how Linux development works. You (we) have a huge test lab around the world. You practice "release early, release often" and get testing/feedback on it. Maybe even patches. :) > > Need blank line here... except why is this function in the header > > Fixed blank line. > > file? and why is it inline? > > Q: "Why is this function in the header file" > If the find_ibft() was to be implemented in firmware/iscsi_ibft.c code the > firmware-driver couldn't be compiled as a module (or rather it could, but > when the vmlinuz was to be linked it would complain about missing symbol - > find_ibft). I was thinking to let the user give the choice whether they want > to load this firmware driver or have it built-in the kernel. > > Q:"Why is it inline" > Uhh. It does not need to. I will remove the 'inline' part. But we strongly prefer not to have non-inline C code in header files, [and the function does not need to be inline] so find_ibft() needs a home in some source file/code that won't be built as a loadable module, right? And preferably not duplicated (i386 & x86_64 versions; but we should see a merged x86/ arch soon, so it sounds). Would ia64 have its own version of find_ibft() or use this same code? I think that for now you can put find_ibft() in both setup.c files and the merged x86/ arch tree can eliminate one of them. On looking back at the patch, why aren't the ibft_phys and find_ibft() parts of both setup.c patches surrounded by #ifdef CONFIG_ISCSI_IBFT & #endif ? --- ~Randy Phaedrus says that Quality is about caring. - 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.23-rc7-mm1 AHCI ATA errors -- won't boot
Berck E. Nash wrote: > Bernd Schmidt wrote: >> One of these appears in my system as well (ASUS P5W-DH Deluxe >> mainboard). Here's the hdparm output: > > Yup, same mainboard here. > >> Since about 2.6.17 or 2.6.18, it has been causing long delays while >> booting: >> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> ata2.00: qc timeout (cmd 0xec) >> ata2.00: failed to IDENTIFY (I/O error, err_mask=0x5) >> ata2: port is slow to respond, please be patient (Status 0x80) >> ata2: COMRESET failed (errno=-16) >> ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 >> ata2.00: 640 sectors, multi 1: LBA >> ata2.00: configured for UDMA/133 > > And yup, same problem with the painful boot delays since 2.6.18. Tejun > indicated that a fix would get merged with 2.6.23, but that didn't > happen. Here's hoping something makes it into .24! Yeah, it is the sil4726 virtual device which is really crappy as an ATA device. About the fix, I thought PMP support would fix it but the controller on P5W-DH doesn't support PMP. It can only talk to the virtual device or the device attached to the first port depending on how the PMP chip is configured. It seems we'll have to blacklist the mainboard and skip or use modified reset sequence on the affected port, so that's why the fix was delayed. I'm currently on the road but I'll look into it when I get back (next week). Thanks. -- tejun - 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.23-rc7 - _random_ IRQ23 : nobody cared
Paul Rolland wrote: > Hi David, > > On Mon, 24 Sep 2007 23:56:59 +0930 > David Newall <[EMAIL PROTECTED]> wrote: > >> Paul Rolland "(???) wrote: >>> Hell, IRQ 23 is shared between libata and my modem !!! >>> >> Tried using the modem? > > When no problem is reported, both the libata part and the modem are OK. > When the problem is reported, at that time, only libata is handling IRQ23 > (the modem is a WinModem, and the driver is an out-kernel module), this > is still kernel boot time, and the disabling of the IRQ makes my machine > unable to complete the boot process (too many disk timeout). > > It could be good to be able to delay the disabling of an IRQ something long > enough to allow all the modules to be loaded... Can you change driver load order such that the driver for the modem is loaded first? -- tejun - 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] QoS params patch
On Thu, 27 Sep 2007 11:24:40 +0900 Paul Mundt wrote:
> > +/* static helper functions */
> > +static s32 max_compare(s32 v1, s32 v2)
> > +{
> > + if (v1 < v2)
> > + return v2;
> > + else
> > + return v1;
> > +}
> > +
> > +static s32 min_compare(s32 v1, s32 v2)
> > +{
> > + if (v1 < v2)
> > + return v1;
> > + else
> > + return v2;
> > +}
> > +
> min()/max() instead?
Other code wants function pointers to the min & max functions.
That's why they are here AFAICT.
> > +/* assumes qos_lock is held */
> > +static void update_target(int i)
> > +{
> 'target' might be a more meaningful variable name.
Anything but 'i'.
---
~Randy
Phaedrus says that Quality is about caring.
-
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] Add iSCSI iBFT support.
Ram Dorai wrote:
Fixed.
> > +static int
> > +ibft_mmap_binary(struct kobject *kobj, struct bin_attribute
*attr,
> > +struct vm_area_struct *vma)
>
Do we not put a space between binary and '('. Is that against the coding
guidelines?
Right, we do not put a space there.
It's read_binary(ko, attr, vma);
so function names have no space following them, but
if, for, switch, and while do have space following them.
--
~Randy
Phaedrus says that Quality is about caring.
-
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/
TCP Spike
Hi, We have observed 40ms latency spikes in TCP connections in "burst" type of traffic. This affects regular TCP sockets. We observed this issue in kernels of 2.4.21 and kernel 2.6.5. Aparently, this seems to be fixed in 2.6.19. Can someone throw some light on this? Is this a congestion control/avoidance issue? What congestion control algorithm is used before 2.6.8? Thanks Rajib == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
> <-- snip -->
>
> Look, when chroot was being designed, I think they intended that even root
> should be unable to get out. They went so far as to say that dot-dot
> wouldn't let you out; and it doesn't.
>
> <-- snip -->
>
> You were clearly saying that whom you call "they" were the people who
> designed chroot. And it was you who was claiming in this statement that
> "they" said it.
>
> The OpenBSD manpage you quoted in this thread states chroot() was added
> in 4.2BSD, and 4.2BSD was released in 1983.
>
> You should therefore either bring a source where the people who designed
> chroot() in 1983 or earlier are stating what you claim they said or
> admit that you were talking utter bullshit.
chroot() is present in v7, thank you very much. /usr/sys/sys/sys4.c has
chdir()
{
chdirec(_cdir);
}
chroot()
{
if (suser())
chdirec(_rdir);
}
and back then it didn't stop lookups by .. at all - u_rdir is only used
in the beginning of namei() (when pathname starts with /), plus the obvious
refcounting in exit()/newproc(). So give me a break - back when it had
been introduced, it didn't do anything jail-like _at_ _all_.
That check appears only in BSD:
@@ -1,4 +1,4 @@
-/* vfs_lookup.c4.4 03/06/81*/
+/* vfs_lookup.c4.5 81/03/09*/
#include "../h/param.h"
#include "../h/systm.h"
@@ -107,6 +107,9 @@
u.u_segflg = 1;
eo = 0;
bp = NULL;
+ if (dp == u.u_rdir && u.u_dent.d_name[0] == '.' &&
+ u.u_dent.d_name[1] == '.' && u.u_dent.d_name[2] == 0)
+ goto cloop;
eloop:
with spectaculary lousy commit message ("lint and a minor fixed") by
wnj. Feel free to ask Bill Joy WTF he had intended. At a guess,
more consistent behaviour in chrooted environment (i.e. pathname
resolution looking as if the subtree had been everything).
To talk about root-safety of _anything_ at that point is bloody ridiculous.
-
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] QoS params patch
On Wed, Sep 26, 2007 at 10:53:03PM -0400, [EMAIL PROTECTED] wrote: > On Wed, 26 Sep 2007 17:40:20 PDT, Mark Gross said: > > --- linux-2.6.23-rc8/kernel/Makefile2007-09-26 13:54:54.0 > > -0700 > > +++ linux-2.6.23-rc8-qos/kernel/Makefile2007-09-26 14:06:38.0 - > 0700 > > @@ -9,7 +9,7 @@ > > rcupdate.o extable.o params.o posix-timers.o \ > > kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \ > > hrtimer.o rwsem.o latency.o nsproxy.o srcu.o die_notifier.o \ > > - utsname.o > > + utsname.o qos_params.o > > So I don't get a choice in the matter if I will be dragging this thing > around in my kernel, even if I have no intention of using the functionality? > You don't get that option with latency.c either at the moment, and it's arguable whether it's even worth it. The more curious thing is that while this qos params seems to be an evolution of Arjan's latency.c (and the drivers that are using it are updated in the rest of the patch set), latency.c itself is still compiled in. Is this an oversight, or was it intentional? One set of latency hinting APIs only, please :-) - 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] QoS params patch
On Wed, 26 Sep 2007 17:40:20 PDT, Mark Gross said:
(others here are probably better at spotting leaks and races than I am,
so I'm skipping those and picking other nits. ;)
> --- linux-2.6.23-rc8/kernel/Makefile 2007-09-26 13:54:54.0 -0700
> +++ linux-2.6.23-rc8-qos/kernel/Makefile 2007-09-26 14:06:38.0 -
0700
> @@ -9,7 +9,7 @@
> rcupdate.o extable.o params.o posix-timers.o \
> kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
> hrtimer.o rwsem.o latency.o nsproxy.o srcu.o die_notifier.o \
> - utsname.o
> + utsname.o qos_params.o
So I don't get a choice in the matter if I will be dragging this thing
around in my kernel, even if I have no intention of using the functionality?
> + * This QoS design is best effort based. Dependents register their QoS
> needs.
> + * Watchers register to keep track of the current QoS needs of the system.
> + *
> + * There are 3 basic classes of QoS parameter: latency, timeout, throughput
> + * each have defined units:
> + * latency: usec
> + * timeout: usec <-- currently not used.
> + * throughput: kbs (kilo byte / sec)
It's unclear whether these are registering a differing QoS request for each
process/container/whatever that asks for one, or if they're global across the
system. Also, even though it's "best effort", it would be good to document
what the failure mode is if we get conflicting requests, or an overcommit
situation - do new requests get refused, or allowed and ignored, or allowed
and only sometimes fulfilled. For instance, assume a gigabit ethernet,
and 3 processes ask for 400 mbits/sec each - who wins, who gets part of what
they asked for, and who loses and gets starved?
> + * User mode requirements on a QOS parameter register themselves to the
> + * subsystem by opening the device node /dev/... and writing there request to
> + * the node. As long as the process holds a file handle open to the node the
/dev? What /dev entry do you use for a network interface? Should this
be a configfs creature instead, or maybe something else?
> +/* static helper functions */
> +static s32 max_compare(s32 v1, s32 v2)
Blech. Is it time for the yearly stamp-out-reinvention-of-max() already?
The use of pointer functions is interesting, but I have to wonder if there's
not a better way...
> +#define PID_NAME_LEN sizeof("process_1234567890")
> +static char name[PID_NAME_LEN];
And then you just pass a pointer to this and kstrdup() it. Why not kmalloc()
the space initially and just 'dep->name = name;' and be done with it?
General nit - why qos_power_*, when none of the supported QoS parameters
seem to be power-related?
pgpe8ho0wgIaP.pgp
Description: PGP signature
Re: [PATCH 1/5] The config option itself
Serge E. Hallyn [EMAIL PROTECTED] wrote: | Quoting Serge E. Hallyn ([EMAIL PROTECTED]): | > Quoting Pavel Emelyanov ([EMAIL PROTECTED]): | > > The option is called NAMESPACES. It can be selectable only | > > if EMBEDDED is chosen (this was Eric's requisition). When | > > the EMBEDDED is off namespaces will be on automatically. | > > | > > One more option (NAMESPACES_EXPERIMENTAL) was added by | > > Serge's request to move there all the namespaces that are | > > not finished yet. Currently only the user and the network | > > namespaces are such. | > > | > > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> | > > | > > --- | > > | > > diff --git a/init/Kconfig b/init/Kconfig | > > index 684ccfb..05a71d7 100644 | > > --- a/init/Kconfig | > > +++ b/init/Kconfig | > > @@ -369,6 +360,23 @@ config RELAY | > > | > > If unsure, say N. | > > | > > +config NAMESPACES | > > + bool "The namespaces support" if EMBEDDED | > > + default !EMBEDDED | > > + help | > > + Provides the way to make tasks work with different objects using | > > + the same id. For example same IPC id may refer to different objects | > > + or same user id or pid may refer to different tasks when used in | > > + different namespaces. | > > + | > > +config NAMESPACES_EXPERIMENTAL | > > + bool "Add the experimantal namespaces support" if EMBEDDED | > | > Hi Pavel, | > | > Overall this patchset looks good. | > | > However the NAMESPACES_EXPERIMENTAL option should not have the | > 'if EMBEDDED', right? This is about EXPERIMENTAL, not about | > EMBEDDED, unlike the plain NAMESPACES option. | > | > -serge | | Actually that doesn't seem to work either. Even though | SECURITY_NAMESPACES=y, the config system seems to infer that | since NAMESPACES is not user-selectable, NAMESPACES_EXPERIMENTAL | shouldn't be either. So we end up with NAMESPACES_EXPERIMENTAL | being on and not un-selectable if !EMBEDDED. Yes. Given that NAMESPACES depends on EMBEDDED, NAMESPACES_EXPERIMENTAL can simply depend on NAMESPACES and EXPERIMENTAL with a default of N. BTW, does the position of 'config NAMESPACES' in init/Kconfig file matter ? If it is dependent on EMBEDDED, should it not come later in the file, after 'config EMBEDDED' ? | | > > + depends on NAMESPACES && EXPERIMENTAL | > > + default !EMBEDDED | > > + help | > > + Also include the support for the namespaces that are not fnished | > > + or well developed yet | > > + | > > config BLK_DEV_INITRD | > > bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support" | > > depends on BROKEN || !FRV | ___ | Containers mailing list | [EMAIL PROTECTED] | https://lists.linux-foundation.org/mailman/listinfo/containers - 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] QoS params patch
On Wed, Sep 26, 2007 at 03:40:26PM -0700, Mark Gross wrote:
> + struct list_head list;
> + union {
> + s32 value;
> + s32 usec;
> + s32 kbps;
> + };
> + char *name;
Your } is in a strange place. It looks like it wants to join its friends
closer to the left margin ;-)
> +};
> +
> +#define QOS_RESERVED 0
> +#define QOS_CPU_DMA_LATENCY 1
> +#define QOS_NETWORK_LATENCY 2
> +#define QOS_NETWORK_THROUGHPUT 3
> +
> +#define QOS_NUM_CLASSES 4
> +#define QOS_DEFAULT_VALUE -1
an enum would be better for this, especially as people are likely to add
new types, having to update QOS_NUM_CLASSES each time sucks.
> +/* static helper functions */
> +static s32 max_compare(s32 v1, s32 v2)
> +{
> + if (v1 < v2)
> + return v2;
> + else
> + return v1;
> +}
> +
> +static s32 min_compare(s32 v1, s32 v2)
> +{
> + if (v1 < v2)
> + return v1;
> + else
> + return v2;
> +}
> +
min()/max() instead?
> +/* assumes qos_lock is held */
> +static void update_target(int i)
> +{
'target' might be a more meaningful variable name.
> + qos->qos_power_miscdev.fops = _power_fops;
> +
> + ret = misc_register(& qos->qos_power_miscdev);
> + if (ret < 0 )
> + printk(KERN_ERR "qos_power: misc_register returns %d.\n", ret);
> +
> + return ret;
> +}
> +
Just return misc_register(...); ?
> + if( i < QOS_NUM_CLASSES) {
> + qos = _array[i];
> + qos->name = kstrdup(name, GFP_KERNEL);
> + if(!qos->name)
> + goto cleanup;
> +
> + qos->default_value = default_value;
> + qos->target_value = default_value;
> + qos->comparitor = comparitor;
> + srcu_init_notifier_head(>notifiers);
> + INIT_LIST_HEAD(>requirements.list);
> + if (register_new_qos_misc(qos) < 0 )
> + goto cleanup;
> + }
> + return;
> +cleanup:
> + kfree(qos->name);
> +}
This leaks. You'll have to scan down from i and clean up the kstrdup()
per qos_array element. Presently this will only free the first one to fail
registration.
> +
> +int qos_add_requirement(int i, char *name, s32 value)
> +{
> + struct requirement_list * dep;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_lock, flags);
> + dep = kzalloc(sizeof(struct requirement_list), GFP_KERNEL);
kmalloc() under a spinlock. GFP_KERNEL implies __GFP_WAIT, which can
sleep. Slab debugging would have caught this, too.
> + if (dep) {
> + if (value == QOS_DEFAULT_VALUE)
> + dep->value = qos_array[i].default_value;
> + else
> + dep->value = value;
> + dep->name = kstrdup(name, GFP_KERNEL);
And here also, still under the spinlock. You can probably rework the
locking just to protect the list, if you really need it at all, it
doesn't seem to matter anywhere else here.
> + if(!dep->name)
> + goto cleanup;
> +
> + list_add(>list, _array[i].requirements.list);
> + update_target(i);
> + spin_unlock_irqrestore(_lock, flags);
> +
> + return 0;
> + }
> + spin_unlock_irqrestore(_lock, flags);
> +
> +cleanup:
> + if(dep)
> + kfree(dep);
no if() needed.
> + return -ENOMEM;
> +}
> +EXPORT_SYMBOL_GPL(qos_add_requirement);
You also didn't spin_unlock_irqrestore() in the error path, so this bails
out with the lock held and IRQs disabled.
-
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:disable resource decode in PCI BAR detection
On Thu, Sep 27, 2007 at 10:40:33AM +1000, Benjamin Herrenschmidt wrote: > > > How is this a change in behavior as far as this device is concerned? If > > we are doing BAR sizing and moving the base address around, it's going > > to cause problems if you try to access the device during this time > > whether we disable decode or not. > > True. The window is smaller tho if the upper bridge decode hasn't been > disabled. I suppose I'll have to find a way to "pin" those devices and > generate the BAR info from the firmware data. The upper bridge decode only gets disabled while we size the upper bridge's BARs. Then we reenable it. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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] Add iSCSI iBFT support.
On Wed, Sep 26, 2007 at 08:08:45PM -0400, Konrad Rzeszutek wrote: > On Wednesday 26 September 2007 17:10:57 Greg KH wrote: > > On Wed, Sep 26, 2007 at 02:46:52PM -0400, Konrad Rzeszutek wrote: > > > This patch adds a /sysfs/firmware/ibft/table binary blob which exports > > > the iSCSI Boot Firmware Table (iBFT) structure. > > > > Please don't do that. Binary files are for things that are > > "pass-through" only, not anything that the kernel knows the structure > > of, or cares about (like PCI config space, or firmware blobs for > > devices.) > > > > Just export the individual fields of this table as individual files > > please. > > My goal was to do that in the next version of this patch. My first step was > to get the fundamental work reviewed (and hopefully accepted) and then build > on top of that. > > The exploiter of this binary file (/sys/firmware/ibft/table) is the > iscsi-initiator-utils package and it has a library that parses the binary > blob data. The thought was to get this first working (ie, > iscsi-initiator-utils finds /sys/firmware/ibft/table, parses it and work) and > then work to have the iscsi-initiator-support individual sysfs entries. > > Or do you think I should skip the fundamental step and work on the next > version of this patch that exports the data as individual data and post that > one instead? Just do the individual files, do not export binary structures through sysfs as that is not allowed. The individual files should be much easier to export than the binary blog anyway :) thanks, greg k-h - 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] writeback: remove unnecessary wait in throttle_vm_writeout()
We don't want to introduce pointless delays in throttle_vm_writeout()
when the writeback limits are not yet exceeded, do we?
Cc: Nick Piggin <[EMAIL PROTECTED]>
Cc: OGAWA Hirofumi <[EMAIL PROTECTED]>
Cc: Kumar Gala <[EMAIL PROTECTED]>
Cc: Pete Zaitcev <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/page-writeback.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
--- linux-2.6.23-rc8-mm1.orig/mm/page-writeback.c
+++ linux-2.6.23-rc8-mm1/mm/page-writeback.c
@@ -507,16 +507,6 @@ void throttle_vm_writeout(gfp_t gfp_mask
long background_thresh;
long dirty_thresh;
- if ((gfp_mask & (__GFP_FS|__GFP_IO)) != (__GFP_FS|__GFP_IO)) {
- /*
-* The caller might hold locks which can prevent IO completion
-* or progress in the filesystem. So we cannot just sit here
-* waiting for IO to complete.
-*/
- congestion_wait(WRITE, HZ/10);
- return;
- }
-
for ( ; ; ) {
get_dirty_limits(_thresh, _thresh, NULL, NULL);
@@ -530,6 +520,14 @@ void throttle_vm_writeout(gfp_t gfp_mask
global_page_state(NR_WRITEBACK) <= dirty_thresh)
break;
congestion_wait(WRITE, HZ/10);
+
+ /*
+* The caller might hold locks which can prevent IO completion
+* or progress in the filesystem. So we cannot just sit here
+* waiting for IO to complete.
+*/
+ if ((gfp_mask & (__GFP_FS|__GFP_IO)) != (__GFP_FS|__GFP_IO))
+ break;
}
}
-
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/
sched-devel feedback
Hi, Ingo , Mike and Peter! Just passing around to say that 2.6.23-rc8-sched-dev is the best scheduler ever to me. It's great for 3D games. http://www.openarena.ws/?files is really great with this scheduler. I played a whole match without no slowdown, smooth playing all the time. I had never played it before like this, it made a huge difference to me. Even older CFS releases and -ck did not made it so smooth. It was really smooth _all_ the time. The scheduler team did a really good work on this! Thank you so much for this great work, -- []s, André Goddard - 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] Add iSCSI iBFT support.
> > +config ISCSI_IBFT > > + tristate "iSCSI Boot Firmware Table Attributes" > > + depends on X86 > > why only on X86? PowerPC exports this data via the OpenFirmware so it already shows in the /sysfs entries. I was thinking to combine those sysfs entries under this code, but that is something in the future. In regards to all other platforms, I figured I would only make it supported under platforms that have been tested. Is there anything that stops this from working for example of IA64? Well no. The hardware that supports the iBFT is either in the BIOS or in NICs - so the SGI or HP boxes _should_ work, however I am not comfortable to make it supported unless I've tested it. > > + * drivers/firmware/iscsi_ibft.c > > Don't repeat the file name. OK. > > + * This code exposes the the iSCSI Boot Format Table to userland via > > sysfs. > > ~~~ > yes. Yup. > > + > > no blank line here. Fixed. > > +static ssize_t > > +ibft_read_binary(struct kobject *kobj, struct bin_attribute *attr, char > > *buf, + loff_t off, size_t count) > > Put 'static ssize_t' on same line as function name, then put parameters > on following lines as needed. Fixed. > > +static int > > +ibft_mmap_binary(struct kobject *kobj, struct bin_attribute *attr, > > +struct vm_area_struct *vma) > > ditto. Fixed. > > + /* Need PAGE_ALING for mmap functionality. */ > > PAGE_ALIGN Fixed. > > + printk(KERN_INFO "BIOS iBFT unloaded.\n"); > > Drop the unload message. ibft_init() is also quite noisy. Fixed. > > Need blank line here... except why is this function in the header Fixed blank line. > file? and why is it inline? Q: "Why is this function in the header file" If the find_ibft() was to be implemented in firmware/iscsi_ibft.c code the firmware-driver couldn't be compiled as a module (or rather it could, but when the vmlinuz was to be linked it would complain about missing symbol - find_ibft). I was thinking to let the user give the choice whether they want to load this firmware driver or have it built-in the kernel. Q:"Why is it inline" Uhh. It does not need to. I will remove the 'inline' part. > > > + unsigned long pos; > > add blank line here between data / code. Fixed. Randy, Thank you for taking time to do such thoroughly review. - 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] QoS params patch
On Wed, Sep 26, 2007 at 04:41:59PM -0700, Randy Dunlap wrote:
> On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross wrote:
>
> > The following is the qos_param patch that implements a genralization of
> > latency.c.
> >
>
> Just some general comments (as on irc):
>
> - use 'diffstat -p1 -w70' to summarize each patch
> - use checkpatch.pl to check for coding style and other buglets
done
> - has no API docs :(
not done yet.
>
>
>
>
> > +/* assumes qos_lock is held */
> > +static void update_target(int i)
>
> I'd prefer a better arg name than 'i'.
I do too, but i in this case is an Index.
> > +{
>
> ---
> ~Randy
> Phaedrus says that Quality is about caring.
updated patch:
Signed-off-by: mark gross <[EMAIL PROTECTED]>
Makefile |2
linux/qos_params.h | 35 +
qos_params.c | 354 +
3 files changed, 390 insertions(+), 1 deletion(-)
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/include/linux/qos_params.h
linux-2.6.23-rc8-qos/include/linux/qos_params.h
--- linux-2.6.23-rc8/include/linux/qos_params.h 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.23-rc8-qos/include/linux/qos_params.h 2007-09-26
14:05:20.0 -0700
@@ -0,0 +1,35 @@
+/* interface for the qos_power infrastructure of the linux kernel.
+ *
+ * Mark Gross
+ */
+#include
+#include
+#include
+
+struct requirement_list {
+ struct list_head list;
+ union {
+ s32 value;
+ s32 usec;
+ s32 kbps;
+ };
+ char *name;
+};
+
+#define QOS_RESERVED 0
+#define QOS_CPU_DMA_LATENCY 1
+#define QOS_NETWORK_LATENCY 2
+#define QOS_NETWORK_THROUGHPUT 3
+
+#define QOS_NUM_CLASSES 4
+#define QOS_DEFAULT_VALUE -1
+
+int qos_add_requirement(int qos, char *name, s32 value);
+int qos_update_requirement(int qos, char *name, s32 new_value);
+void qos_remove_requirement(int qos, char *name);
+
+int qos_requirement(int qos);
+
+int qos_add_notifier(int qos, struct notifier_block *notifier);
+int qos_remove_notifier(int qos, struct notifier_block *notifier);
+
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/kernel/Makefile linux-2.6.23-rc8-qos/kernel/Makefile
--- linux-2.6.23-rc8/kernel/Makefile2007-09-26 13:54:54.0 -0700
+++ linux-2.6.23-rc8-qos/kernel/Makefile2007-09-26 14:06:38.0
-0700
@@ -9,7 +9,7 @@
rcupdate.o extable.o params.o posix-timers.o \
kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
hrtimer.o rwsem.o latency.o nsproxy.o srcu.o die_notifier.o \
- utsname.o
+ utsname.o qos_params.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-y += time/
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/kernel/qos_params.c linux-2.6.23-rc8-qos/kernel/qos_params.c
--- linux-2.6.23-rc8/kernel/qos_params.c1969-12-31 16:00:00.0
-0800
+++ linux-2.6.23-rc8-qos/kernel/qos_params.c2007-09-26 17:09:44.0
-0700
@@ -0,0 +1,354 @@
+/*
+ * This module exposes the interface to kernel space for specifying
+ * QoS dependencies. It provides infrastructure for registration of:
+ *
+ * Dependents on a QoS value : register requirements
+ * Watchers of QoS value : get notified when target QoS value changes
+ *
+ * This QoS design is best effort based. Dependents register their QoS needs.
+ * Watchers register to keep track of the current QoS needs of the system.
+ *
+ * There are 3 basic classes of QoS parameter: latency, timeout, throughput
+ * each have defined units:
+ * latency: usec
+ * timeout: usec <-- currently not used.
+ * throughput: kbs (kilo byte / sec)
+ *
+ * There are lists of qos_objects each one wrapping requirements, notifiers
+ *
+ * User mode requirements on a QOS parameter register themselves to the
+ * subsystem by opening the device node /dev/... and writing there request to
+ * the node. As long as the process holds a file handle open to the node the
+ * client continues to be accounted for. Upon file release the usermode
+ * requirement is removed and a new qos target is computed. This way when the
+ * requirement that the application has is cleaned up when closes the file
+ * pointer or exits the qos_object will get an opportunity to clean up.
+ *
+ * mark gross [EMAIL PROTECTED]
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * locking rule: all changes to target_value or requirements or notifiers lists
+ * or qos_object list and qos_objects need to happen with qos_lock held, taken
+ * with _irqsave. One lock to rule them all
+ */
+
+struct qos_object {
+ struct requirement_list requirements;
+ struct srcu_notifier_head notifiers;
+ struct miscdevice qos_power_miscdev;
+ char *name;
+ s32 default_value;
+ s32 target_value;
+ s32 (*comparitor)(s32, s32);
+};
Re: [PATCH]PCI:disable resource decode in PCI BAR detection
> How is this a change in behavior as far as this device is concerned? If > we are doing BAR sizing and moving the base address around, it's going > to cause problems if you try to access the device during this time > whether we disable decode or not. True. The window is smaller tho if the upper bridge decode hasn't been disabled. I suppose I'll have to find a way to "pin" those devices and generate the BAR info from the firmware data. Ben. - 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] Add iSCSI iBFT support.
On Wednesday 26 September 2007 17:10:57 Greg KH wrote: > On Wed, Sep 26, 2007 at 02:46:52PM -0400, Konrad Rzeszutek wrote: > > This patch adds a /sysfs/firmware/ibft/table binary blob which exports > > the iSCSI Boot Firmware Table (iBFT) structure. > > Please don't do that. Binary files are for things that are > "pass-through" only, not anything that the kernel knows the structure > of, or cares about (like PCI config space, or firmware blobs for > devices.) > > Just export the individual fields of this table as individual files > please. My goal was to do that in the next version of this patch. My first step was to get the fundamental work reviewed (and hopefully accepted) and then build on top of that. The exploiter of this binary file (/sys/firmware/ibft/table) is the iscsi-initiator-utils package and it has a library that parses the binary blob data. The thought was to get this first working (ie, iscsi-initiator-utils finds /sys/firmware/ibft/table, parses it and work) and then work to have the iscsi-initiator-support individual sysfs entries. Or do you think I should skip the fundamental step and work on the next version of this patch that exports the data as individual data and post that one instead? > > thanks, > > greg k-h - 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: NMI error and Intel S5000PSL Motherboards
Hello, > We have about 100 servers based on Intel S5000PSL-SATA motherboards. > They have been running for anywhere between 1 and 10 months. For the > past few months, after updating them all to the 2.6.20.15 kernel > (because of a bug in the 2.6.18 kernel), we are seeing some strange NMI > errors. For example: > > Aug 29 09:02:10 master kernel: Uhhuh. NMI received for unknown reason 30. > Aug 29 09:02:10 master kernel: Do you have a strange power saving mode > enabled? > Aug 29 09:02:10 master kernel: Dazed and confused, but trying to continue I'm also working with Andrew and Samson. It seems that the cause of the problem is CONFIG_PCIEAER, which was introduced after 2.6.18 and defaults to y. With CONFIG_PCIEAER=n, scanpci works fine with no errors. This is the workaround that they'll likely use for now. With CONFIG_PCIEAER=y, scanpci always triggers the NMI error. The option aerdriver.forceload=1 has no effect. The related dmesg output at boot is: Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:02.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:03.0:pcie01 failed with error 1 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:04.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:05.0:pcie01 failed with error 2 Evaluate _OSC Set fails. Status = 0x0005 Evaluate _OSC Set fails. Status = 0x0005 aer_init: AER service init fails - Run ACPI _OSC fails aer: probe of :00:06.0:pcie01 failed with error 2 aer_init: AER service init fails - No ACPI _OSC support aer: probe of :00:07.0:pcie01 failed with error 1 Full dmesg, lspci, and ACPI DSDT are available here: http://jim.sh/~jim/tmp/nmi/ -jim - 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] Add iSCSI iBFT support.
> > i.e., what is this binary blob (?) > > I don't see a binary blob in this patch (as stated in the first > sentence). I'd say that this patch adds methods for exporting > (or exposing) the ibft thru sysfs. I used the wrong choice of words. The correct one is, as you say, to add methods for exporting the iBFT through sysfs. > > Is there some good reason that the iSCSI connection information > shouldn't be exposed in real sysfs attribute files instead of just > in a binary file? My end goal is to export the iBFT data via individual sysfs attribute files. I was thinking to do that in the next version of this code and build on top of this patch. This way the existing exploiter (iscsi-initiator-utils) can use the parsing code it already has to extract the data from the binary blob. Then in the next version of the iscsi-initiator-utils (and for the kernel) I can post a patch for supporting (and exporting in the kernel) individual sysfs attribute files. - 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: NMI error and Intel S5000PSL Motherboards
On Wed, 26 Sep 2007 19:48:14 -0400 Jim Paris wrote: > Hello, > > > We have about 100 servers based on Intel S5000PSL-SATA motherboards. > > They have been running for anywhere between 1 and 10 months. For the > > past few months, after updating them all to the 2.6.20.15 kernel > > (because of a bug in the 2.6.18 kernel), we are seeing some strange NMI > > errors. For example: > > > > Aug 29 09:02:10 master kernel: Uhhuh. NMI received for unknown reason 30. > > Aug 29 09:02:10 master kernel: Do you have a strange power saving mode > > enabled? > > Aug 29 09:02:10 master kernel: Dazed and confused, but trying to continue > > I'm also working with Andrew and Samson. It seems that the cause of > the problem is CONFIG_PCIEAER, which was introduced after 2.6.18 and > defaults to y. > > With CONFIG_PCIEAER=n, scanpci works fine with no errors. This is the > workaround that they'll likely use for now. Glad that you found it. > With CONFIG_PCIEAER=y, scanpci always triggers the NMI error. The > option aerdriver.forceload=1 has no effect. The 'forceload' option only forces the driver to load even when the ACPI hardware initialization routine fails. It would be nice to be able to disable PCIEAER at boot time though. Shouldn't be difficult. > The related dmesg output at boot is: > > Evaluate _OSC Set fails. Status = 0x0005 > Evaluate _OSC Set fails. Status = 0x0005 > aer_init: AER service init fails - Run ACPI _OSC fails > aer: probe of :00:02.0:pcie01 failed with error 2 > aer_init: AER service init fails - No ACPI _OSC support > aer: probe of :00:03.0:pcie01 failed with error 1 > Evaluate _OSC Set fails. Status = 0x0005 > Evaluate _OSC Set fails. Status = 0x0005 > aer_init: AER service init fails - Run ACPI _OSC fails > aer: probe of :00:04.0:pcie01 failed with error 2 > Evaluate _OSC Set fails. Status = 0x0005 > Evaluate _OSC Set fails. Status = 0x0005 > aer_init: AER service init fails - Run ACPI _OSC fails > aer: probe of :00:05.0:pcie01 failed with error 2 > Evaluate _OSC Set fails. Status = 0x0005 > Evaluate _OSC Set fails. Status = 0x0005 > aer_init: AER service init fails - Run ACPI _OSC fails > aer: probe of :00:06.0:pcie01 failed with error 2 > aer_init: AER service init fails - No ACPI _OSC support > aer: probe of :00:07.0:pcie01 failed with error 1 > > Full dmesg, lspci, and ACPI DSDT are available here: > http://jim.sh/~jim/tmp/nmi/ > > -jim --- ~Randy Phaedrus says that Quality is about caring. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 09:05:33AM +0930, David Newall wrote: > Adrian Bunk wrote: >> You are claiming "They went so far as to say that dot-dot wouldn't let you >> out"? >> > > I phrased it in a somewhat conversational way. The promise, which I've now > quoted from multiple sources, is expressed variously, including: >> The dot-dot entry in the root directory is interpreted to mean the root >> directory itself. Thus, dot-dot cannot be used to access files outside the >> subtree rooted at the root directory. You claimed: <-- snip --> Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. <-- snip --> You were clearly saying that whom you call "they" were the people who designed chroot. And it was you who was claiming in this statement that "they" said it. The OpenBSD manpage you quoted in this thread states chroot() was added in 4.2BSD, and 4.2BSD was released in 1983. You should therefore either bring a source where the people who designed chroot() in 1983 or earlier are stating what you claim they said or admit that you were talking utter bullshit. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/3] A kernel tracing interface - (updated)
Mathieu Desnoyers wrote: * David J. Wilder ([EMAIL PROTECTED]) wrote: These patches provide a kernel tracing interface called "trace". (update) Moved the sample code to the new samples\ subdir The motivation for "trace" is to: - Provide a simple set of tracing primitives that will utilize the high- performance and low-overhead of relayfs for passing traces data from kernel to user space. - Provide a common user interface for managing kernel traces. - Allow for binary as well as ascii trace data. - Incorporate features from the systemtap runtime that are useful to others. Patches are against 2.6.23-rc6-mm1 Summary of patches: [patch 1/3] Trace code and documentation [patch 2/3] Relay Reset Consumed [patch 3/3] Trace sample Note: Patches 1/3 and 2/3 must be applied together. Note: The following patches must be applied with 3/3. [patch 3/5] Add samples subdir http://lkml.org/lkml/2007/9/25/157 I guess you mean: [patch 3/5] Add samples subdir (updated) http://lkml.org/lkml/2007/9/25/366 (please try it with this new version, it should work as is..) yes it works fine with the new version of your patch, I will update my note for the next round of submissions. Mathieu [patch 4/5] Linux Kernel Markers - Samples http://lkml.org/lkml/2007/9/25/166 Signed-off-by: David Wilder <[EMAIL PROTECTED]> - 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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
Heh, well of course I vigoursly checked System.map. On my x86 and amd64 systems it removes them all. What a stupid question :-p Nope. I expect(ed) you to do that, i.e., make sure that the patch does that the description says that it does. - 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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
Jonathan Campbell wrote: Sorry about that. That's why I always send as attachments. Do you have similar problems when using Mozilla Thunderbird? tbird works when following the instructions at http://mbligh.org/linuxdocs/Email/Clients/Thunderbird or (simpler) use an External Editor plugin. And have you checked System.map to verify the DMI functions aren't there? Nope. I expect(ed) you to do that, i.e., make sure that the patch does that the description says that it does. On Wed, 26 Sep 2007 11:42:16 -0700 Jonathan Campbell wrote: Here is the DMI patch again, written against linux-2.6.23-rc8, with some of the #ifdef CONFIG_DMI's removed and moved to include/linux/dmi.h. Putting them there in the way I've done ensures that you don't have to put #ifdef CONFIG_DMI around each dmi_check_machine() and that you don't have to apply little patches to so many device drivers. Damaged as the patch is, I was able to apply it by using 'patch -l' (ignore whitespace) + some fuzz. Not something that Linus or Andrew would or should do. I built and booted the kernel, it's running fine (x86_32 notebook). -- ~Randy Phaedrus says that Quality is about caring. - 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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
Sorry about that. That's the reason I send them as attachments. Any suggestions for someone like myself using Mozilla Thunderbird? Damaged as the patch is, I was able to apply it by using 'patch -l' (ignore whitespace) + some fuzz. Not something that Linus or Andrew would or should do. I built and booted the kernel, it's running fine (x86_32 notebook). - 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] QoS params patch
On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross wrote:
> The following is the qos_param patch that implements a genralization of
> latency.c.
>
Just some general comments (as on irc):
- use 'diffstat -p1 -w70' to summarize each patch
- use checkpatch.pl to check for coding style and other buglets
- has no API docs :(
> +/* assumes qos_lock is held */
> +static void update_target(int i)
I'd prefer a better arg name than 'i'.
> +{
---
~Randy
Phaedrus says that Quality is about caring.
-
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: sys_chroot+sys_fchdir Fix
Adrian Bunk wrote: You are claiming "They went so far as to say that dot-dot wouldn't let you out"? I phrased it in a somewhat conversational way. The promise, which I've now quoted from multiple sources, is expressed variously, including: The dot-dot entry in the root directory is interpreted to mean the root directory itself. Thus, dot-dot cannot be used to access files outside the subtree rooted at the root directory. - 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: [REGRESSION from 2.6.23-rc8]
On 09/26/2007 06:35 PM, Thomas Gleixner wrote: > > It's even worse than I thought on the first check: > > "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot > CPU apic timer from being used. But the secondary CPU is still > unconditionally setting up the APIC timer and uses the non calibrated > variable calibration_result, which is of course 0, to setup the APIC > timer. Wreckage guaranteed. > Well, that would explain a lot of the things I've been seeing... - 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.23-rc8: Known regressions from 2.6.22
On 09/26/2007 07:27 PM, Rafael J. Wysocki wrote: > > Subject: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD > Geode LX800 > Submitter:Joerg Pommnitz <[EMAIL PROTECTED]> > References: http://lkml.org/lkml/2007/9/26/91 > http://bugzilla.kernel.org/show_bug.cgi?id=9086 > Caused-By:H. Peter Anvin <[EMAIL PROTECTED]> > commit 4fd06960f120e02e9abc802a09f9511c400042a5 > Use the new x86 setup code for i386 > Handled-By: H. Peter Anvin <[EMAIL PROTECTED]> > Patch:http://lkml.org/lkml/2007/9/26/374 > Patch was just merged. - 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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
On Wed, 26 Sep 2007 11:42:16 -0700 Jonathan Campbell wrote: > Here is the DMI patch again, written against linux-2.6.23-rc8, > with some of the #ifdef CONFIG_DMI's removed and moved > to include/linux/dmi.h. Putting them there in the way I've done > ensures that you don't have to put #ifdef CONFIG_DMI > around each dmi_check_machine() and that you don't > have to apply little patches to so many device drivers. Damaged as the patch is, I was able to apply it by using 'patch -l' (ignore whitespace) + some fuzz. Not something that Linus or Andrew would or should do. I built and booted the kernel, it's running fine (x86_32 notebook). > diff -u -r linux-2.6.23-rc8-old/init/Kconfig linux-2.6.23-rc8/init/Kconfig > --- linux-2.6.23-rc8-old/init/Kconfig2007-09-21 22:38:23.0 + > +++ linux-2.6.23-rc8/init/Kconfig2007-09-26 00:03:05.0 + > @@ -542,6 +542,18 @@ >on EMBEDDED systems. /proc/vmstat will only show page counts >if VM event counters are disabled. > > +config DMI > +default y > +bool "Enable DMI support" if EMBEDDED > +depends on X86 > +help > + This enables support for processing the Desktop Management > + Interface structures present in most modern BIOSes. If you are > + building a kernel for an older Pentium, 486, or 386 system and > + memory is tight, you can disable this to help reduce the size > + of your kernel by about 6K. > + If unsure, say Y. > + This is in the General setup menu. How about putting it into the EMBEDDED menu instead? [Configure standard kernel features (for small systems)] > config SLUB_DEBUG > default y > bool "Enable SLUB debugging support" if EMBEDDED There are still several build warnings that need attention: drivers/acpi/sleep/main.c:223: warning: 'acpisleep_dmi_table' defined but not used drivers/pnp/pnpbios/core.c:509: warning: 'pnpbios_dmi_table' defined but not used arch/i386/pci/irq.c:1035: warning: 'pciirq_dmi_table' defined but not used arch/i386/pci/common.c:148: warning: 'pciprobe_dmi_table' defined but not used +#endif // CONFIG_DMI Use /* ... */ style comments instead of // comments. --- ~Randy Phaedrus says that Quality is about caring. - 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: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents)
On Thu, 2007-09-27 at 01:30 +0200, Rafael J. Wysocki wrote: > > > Tested for a couple of times with each kernel, the results seem to be > > > reproducible 100% of the time. > > > > Thanks for going through this debug marathon. > > No big deal. I'm glad that you've found what's up. > > Well, we still have the "CPU hotplug during suspend w/ the hrt patch" problem > to debug ... ;-) Yeah. Knowing the actual line of code where it breaks might be helpful. tglx - 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] just rename call_rcu_bh instead of making it a macro
On Wed, Sep 26, 2007 at 02:17:47PM -0400, Steven Rostedt wrote:
> Seems that I found a box that has a config that passes call_rcu_bh as a
> function pointer (see net/sctp/sm_make_chunk.c), so declaring the
> call_rcu_bh has a macro function isn't good enough.
>
> This patch makes it just another name of call_rcu for rcupreempt.
Looks good!
Acked-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
>
> Index: linux-2.6.23-rc8-rt1/include/linux/rcupreempt.h
> ===
> --- linux-2.6.23-rc8-rt1.orig/include/linux/rcupreempt.h
> +++ linux-2.6.23-rc8-rt1/include/linux/rcupreempt.h
> @@ -42,9 +42,14 @@
> #include
> #include
>
> -#define rcu_qsctr_inc(cpu)
> -#define rcu_bh_qsctr_inc(cpu)
> -#define call_rcu_bh(head, rcu) call_rcu(head, rcu)
> +#define rcu_qsctr_inc(cpu) do { } while (0)
> +#define rcu_bh_qsctr_inc(cpu)do { } while (0)
> +/*
> + * Someone might want to pass call_rcu_bh as a function pointer.
> + * So this needs to just be a rename and not a macro function.
> + * (no parentheses)
> + */
> +#define call_rcu_bh call_rcu
>
> extern void __rcu_read_lock(void);
> extern void __rcu_read_unlock(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/
Re: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents)
Thomas, On Wednesday, 26 September 2007 23:34, Thomas Gleixner wrote: > Rafael, > > On Wed, 2007-09-26 at 23:00 +0200, Rafael J. Wysocki wrote: > > > > > First, with the "x86-64: Disable local APIC timer use on AMD systems > > > > > with C1E" > > > > > patch and my collection of suspend patches applied, the box doesn't > > > > > boot > > > > > (the suspend patches don't even thouch the boot code, so they should > > > > > be > > > > > irrelevant here). However, it boots if patch-2.6.23-rc7-hrt1.patch > > > > > (adjusted > > > > > for 2.6.23-rc8) is applied in addition. Is this expected? > > > > > > > > No. That's odd. It is nothing else than adding "noapictimer" to the > > > > kernel command line. > > > > > > Seems to be reproducible, though. I'll investigate further. > > > > So far, the results are the following: > > > > 1) current Linus' tree doesn't boot with any command line (regression) > > > > [ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0 > > > >x86-64: Disable local APIC timer use on AMD systems with C1E > > > >It's not necessary for 2.6.23 and actually kills the box that it's > > supposed to fix. ] > > > > 2) 2.6.23-rc8 w/ the "x86-64: Disable local APIC timer use on AMD systems > > with C1E" > >patch applied behaves like the current -git > > > > 3) 2.6.23-rc8 w/o this patch doesn't boot with either "noapictimer" _or_ > > OK, this explains 2) and 3). I just looked into the code and the logic > vs. noapictimer on SMP is completely broken. > > On i386 the noapictimer option not only disables the local APIC timer, > it also registers the CPUs for broadcasting via IPI on SMP systems. > > The x8664 code uses the broadcast only when the local apic timer is > active, i.e. "noapictimer" is not on the command line. This defeats the > whole purpose of "noapictimer". It should be there to make boxen work, > where the local APIC timer actually has a hardware problem, e.g. the > nx6325. > > The current implementation of x86_64 only fixes the ACPI c-states > related problem where the APIC timer stops in C3(2), nothing else. > > On nx6325 and other AMD X2 equipped systems which have the C1E enabled > we run into the following: > > PIT keeps jiffies (and the system) running, but the local APIC timer > interrupts can get out of sync due to this C1E effect. > > I don't think this is a critical problem, but it is wrong nevertheless. > > I think it's safe to revert the C1E patch and postpone the fix to the > clock events conversion. > > > "apicmaintimer" > > on your box is not going to work. See the C1E patch. "apicmaintimer" > switches off PIT and then waits for ever for the local APIC timer > interrupts. > > > 4) 2.6.22 behaves like 2.6.23-rc8 > > No surprise > > > 5) 2.6.23-rc8 with (adjusted) patch-2.6.23-rc7-hrt1.patch boots only with > >"noapictimer" > > > > 6) 2.6.23-rc8 with (adjusted) patch-2.6.23-rc7-hrt1.patch and with the > >"x86-64: Disable local APIC timer use on AMD systems with C1E" patch > > boots > >without any extra command line options > > That's consistent behaviour. > > > Tested for a couple of times with each kernel, the results seem to be > > reproducible 100% of the time. > > Thanks for going through this debug marathon. No big deal. I'm glad that you've found what's up. Well, we still have the "CPU hotplug during suspend w/ the hrt patch" problem to debug ... ;-) Greetings, Rafael - 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/
2.6.23-rc8: Known regressions from 2.6.22
Hi, This message lists some known regressions from 2.6.22 for which there are no fixes in the mainline that I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.22, please let me know either and I'll add them to the list. Subject:zd1211 device is no longer configured Submitter: Oliver Neukum <[EMAIL PROTECTED]> References: http://marc.info/?l=linux-usb-devel=118854967709322=2 http://bugzilla.kernel.org/show_bug.cgi?id=8972 Caused-By: Daniel Drake <[EMAIL PROTECTED]> commit 74553aedd46b3a2cae986f909cf2a3f99369decc Subject:Oops while modprobing phy fixed module Submitter: Gabriel C <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/7/14/63 http://bugzilla.kernel.org/show_bug.cgi?id=9060 Handled-By: Satyam Sharma <[EMAIL PROTECTED]> Vitaly Bordug <[EMAIL PROTECTED]> Tejun Heo <[EMAIL PROTECTED]> Patch: http://lkml.org/lkml/2007/7/18/506 Subject:ACPI problems: 2.6.22-git17 working, 2.6.23-rc1* is not Submitter: Danny ter Haar <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/7/27/298 http://lkml.org/lkml/2007/7/29/371 http://bugzilla.kernel.org/show_bug.cgi?id=9061 Handled-By: Len Brown <[EMAIL PROTECTED]> Subject:empty suspend stopped working around 2.6.23-rc4 Submitter: Pavel Machek <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/11/326 http://bugzilla.kernel.org/show_bug.cgi?id=9075 Subject:umount triggers a warning in jfs and takes almost a minute Submitter: Oliver Neukum <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/4/73 http://bugzilla.kernel.org/show_bug.cgi?id=9076 Subject:build #301 failed for 2.6.23-rc6-g0d4cbb5 in linux/drivers/net/wireless/libertas/ Submitter: Toralf Förster <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/11/150 http://bugzilla.kernel.org/show_bug.cgi?id=9077 Subject:NETDEV WATCHDOG: eth0: transmit timed out Submitter: Karl Meyer <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/8/13/737 http://bugzilla.kernel.org/show_bug.cgi?id=9079 Handled-By: Francois Romieu <[EMAIL PROTECTED]> Subject:Weird network problems with 2.6.23-rc2 Submitter: Shish <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/8/11/40 http://bugzilla.kernel.org/show_bug.cgi?id=9080 Subject:powersaving degradation, (time spend in C0 goes up after a while) Submitter: Christian Leber <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/2/142 http://bugzilla.kernel.org/show_bug.cgi?id=9081 Subject:Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800 Submitter: Joerg Pommnitz <[EMAIL PROTECTED]> References: http://lkml.org/lkml/2007/9/26/91 http://bugzilla.kernel.org/show_bug.cgi?id=9086 Caused-By: H. Peter Anvin <[EMAIL PROTECTED]> commit 4fd06960f120e02e9abc802a09f9511c400042a5 Use the new x86 setup code for i386 Handled-By: H. Peter Anvin <[EMAIL PROTECTED]> Patch: http://lkml.org/lkml/2007/9/26/374 For details, please follow the links given in references. As you can see, there is a Bugzilla entry for each of the listed regressions. I'm the owner of some of these entries, so if you want me to reassign them to someone else, please let me know. There also is a Bugzilla entry used for tracking the regressions from 2.6.22, unresolved as well as resolved, at: http://bugzilla.kernel.org/show_bug.cgi?id=9056 Please let me know if there are any Bugzilla entries that I should add to the list in there. Greetings, Rafael - 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: Fix boot-time hang on G31/G33 PC
Jesse Barnes wrote: On Wednesday, September 26, 2007 2:56 pm Greg KH wrote: On Wed, Sep 26, 2007 at 02:55:55PM -0700, Jesse Barnes wrote: On Wednesday, September 26, 2007 2:18 pm Greg KH wrote: Due to the issues surrounding this patch, I'm dropping it from my repo. What issues? Is it causing problems for people? I thought this was the patch that Ivan objected to. Yeah, Ivan objected to this, but incorrectly I think. Ivan, your concern is about disabling things like interrupt controllers and power management chips during probe right? You're right that doing that could cause problems if we get and interrupt or PMU event at just the wrong time, but that could just as easily happen if decode was still enabled but the BAR had a bogus address programmed (as it would during probing). Ultimately, I don't care much one way or another as long as we can get the desktop platforms fixed somehow. I think disabling decode is the most correct way of doing this, but I'm open to other solutions (this is the only patch I've seen though that's been tested to solve the problem). I agree, I've yet to see a single report of an actual problem that disabling the decode causes, nor even a theoretical problem which couldn't already happen due to the possibility of the device being accessed during BAR sizing, which just shouldn't be allowed since it can't work with or without this patch. Until and unless we have something better that fixes the real and serious boot-time problems that we need this patch to fix, I would say it should stay in. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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]PCI:disable resource decode in PCI BAR detection
Benjamin Herrenschmidt wrote: On Mon, 2007-09-17 at 14:22 +0400, Ivan Kokshaysky wrote: On Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote: Agreed. I have a similar problem on ppc where it's common to have things like the main PIC on a PCI device. Note that another problem is (or at least was, i haven't checked recently) the P2P bridge scanning code that, in a similar way, can block the path to all devices below it. I -do- have a case for example with Apple Xserve G4's where the main Apple IO ASIC, which is a PCI device containing the PIC, the power management controller, and various low level system control IOs is behind a pair of P2P bridges. I think the P2P probing code is pretty safe now - there are read-only accesses to the bridge config, unless you request to reassign the bus numbers. Though it won't be safe anymore with the patch in question. In which case I will need to NAK the patch... Note that those Xserve G4's still have the subtle issue that they -also- reassign bus numbers :-) But that's going away the day I finally enable domains support for ppc32 (it's been off for now due to problems with X) How is this a change in behavior as far as this device is concerned? If we are doing BAR sizing and moving the base address around, it's going to cause problems if you try to access the device during this time whether we disable decode or not. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: why network devices don't do reference counting?
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Wed, 26 Sep 2007 15:33:30 -0700 > ipv6 is not a network driver, it is a protocol. You might be able to > remove it if you zap all the routes and applications, ... It is purposefully set to have a permanent elevated reference count because it is not designed to be unloaded safely. It has been unloadable forever. - 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] usb_serial: Stop passing NULL to functions that expect data
On Wed, 26 Sep 2007 15:52:48 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 26 Sep 2007 23:08:40 +0100 > Alan Cox <[EMAIL PROTECTED]> wrote: > > > Earlier patches have removed the checking for old v new differences from > > the USB drivers so we can now pass in a valid blank old termios so that > > we don't to fill the drivers with magic hacks for console support > > Are all the prerequisites for these patches in mainline, or are there > dependencies on -mm stuff here? Sorry pre-req for the USB serial ones is the tty patch I sent you last chunk that added tty_encode_baud_rate I'd prefer them to sit in -mm a bit. I'm pretty sure most of them are 100% solid but I also want to see if we get any app breakages caused by correcting our behaviour Alan - 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] usb_serial: Stop passing NULL to functions that expect data
On Wed, 26 Sep 2007 23:08:40 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > Earlier patches have removed the checking for old v new differences from > the USB drivers so we can now pass in a valid blank old termios so that > we don't to fill the drivers with magic hacks for console support Are all the prerequisites for these patches in mainline, or are there dependencies on -mm stuff here? - 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] QoS power example / hack
The following patch is a bit of a hack to illustrate how the qos
parameter infrastructure can communication information to the e1000
driver to use to set interrupt consolidation policy as a function of
acceptable network latency.
Its just an example.
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos-nolatency.c/drivers/net/e1000/e1000_main.c
linux-2.6.23-rc8-qos-apps/drivers/net/e1000/e1000_main.c
--- linux-2.6.23-rc8-qos-nolatency.c/drivers/net/e1000/e1000_main.c
2007-09-26 13:54:33.0 -0700
+++ linux-2.6.23-rc8-qos-apps/drivers/net/e1000/e1000_main.c2007-09-26
15:00:17.0 -0700
@@ -27,6 +27,7 @@
***/
#include "e1000.h"
+#include
#include
char e1000_driver_name[] = "e1000";
@@ -2764,6 +2765,7 @@
{
unsigned int retval = itr_setting;
struct e1000_hw *hw = >hw;
+ int requested_latency = qos_requirement(QOS_NETWORK_LATENCY);
if (unlikely(hw->mac_type < e1000_82540))
goto update_itr_done;
@@ -2803,6 +2805,13 @@
break;
}
+ if (requested_latency < 50)
+ retval = lowest_latency;
+ else if (requested_latency < 250)
+ retval = low_latency;
+ else
+ ; //don't change the current algorithm
+
update_itr_done:
return retval;
}
-
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] QoS power Management enabling patch set
The following patch replaces latency.c with qos_params.c and fixes up
users of latency to use qos_params
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos/drivers/acpi/processor_idle.c
linux-2.6.23-rc8-qos-nolatency.c/drivers/acpi/processor_idle.c
--- linux-2.6.23-rc8-qos/drivers/acpi/processor_idle.c 2007-09-26
13:54:28.0 -0700
+++ linux-2.6.23-rc8-qos-nolatency.c/drivers/acpi/processor_idle.c
2007-09-26 14:09:27.0 -0700
@@ -38,7 +38,7 @@
#include
#include
#include/* need_resched() */
-#include
+#include
#include
/*
@@ -605,7 +605,7 @@
if (cx->promotion.state &&
((cx->promotion.state - pr->power.states) <= max_cstate)) {
if (sleep_ticks > cx->promotion.threshold.ticks &&
- cx->promotion.state->latency <= system_latency_constraint()) {
+ cx->promotion.state->latency <=
qos_requirement(QOS_CPU_DMA_LATENCY)) {
cx->promotion.count++;
cx->demotion.count = 0;
if (cx->promotion.count >=
@@ -649,7 +649,7 @@
* or if the latency of the current state is unacceptable
*/
if ((pr->power.state - pr->power.states) > max_cstate ||
- pr->power.state->latency > system_latency_constraint()) {
+ pr->power.state->latency >
qos_requirement(QOS_CPU_DMA_LATENCY)) {
if (cx->demotion.state)
next_state = cx->demotion.state;
}
@@ -1173,7 +1173,7 @@
"maximum allowed latency: %d usec\n",
pr->power.state ? pr->power.state - pr->power.states : 0,
max_cstate, (unsigned)pr->power.bm_activity,
- system_latency_constraint());
+ qos_requirement(QOS_CPU_DMA_LATENCY));
seq_puts(seq, "states:\n");
@@ -1280,7 +1280,7 @@
max_cstate);
first_run++;
#ifdef CONFIG_SMP
- register_latency_notifier(_processor_latency_notifier);
+ qos_add_notifier(QOS_CPU_DMA_LATENCY,
_processor_latency_notifier);
#endif
}
@@ -1354,7 +1354,7 @@
*/
cpu_idle_wait();
#ifdef CONFIG_SMP
- unregister_latency_notifier(_processor_latency_notifier);
+ qos_remove_notifier(QOS_CPU_DMA_LATENCY,
_processor_latency_notifier);
#endif
}
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos/drivers/net/wireless/ipw2100.c
linux-2.6.23-rc8-qos-nolatency.c/drivers/net/wireless/ipw2100.c
--- linux-2.6.23-rc8-qos/drivers/net/wireless/ipw2100.c 2007-09-26
13:54:34.0 -0700
+++ linux-2.6.23-rc8-qos-nolatency.c/drivers/net/wireless/ipw2100.c
2007-09-26 14:09:27.0 -0700
@@ -162,7 +162,7 @@
#include
#include
#include
-#include
+#include
#include "ipw2100.h"
@@ -1701,7 +1701,7 @@
/* the ipw2100 hardware really doesn't want power management delays
* longer than 175usec
*/
- modify_acceptable_latency("ipw2100", 175);
+ qos_update_requirement(QOS_CPU_DMA_LATENCY, "ipw2100", 175);
/* If the interrupt is enabled, turn it off... */
spin_lock_irqsave(>low_lock, flags);
@@ -1856,7 +1856,7 @@
ipw2100_disable_interrupts(priv);
spin_unlock_irqrestore(>low_lock, flags);
- modify_acceptable_latency("ipw2100", INFINITE_LATENCY);
+ qos_update_requirement(QOS_CPU_DMA_LATENCY, "ipw2100",
QOS_DEFAULT_VALUE);
#ifdef ACPI_CSTATE_LIMIT_DEFINED
if (priv->config & CFG_C3_DISABLED) {
@@ -6544,7 +6544,7 @@
if (ret)
goto out;
- set_acceptable_latency("ipw2100", INFINITE_LATENCY);
+ qos_add_requirement(QOS_CPU_DMA_LATENCY, "ipw2100", QOS_DEFAULT_VALUE);
#ifdef CONFIG_IPW2100_DEBUG
ipw2100_debug_level = debug;
ret = driver_create_file(_pci_driver.driver,
@@ -6566,7 +6566,7 @@
_attr_debug_level);
#endif
pci_unregister_driver(_pci_driver);
- remove_acceptable_latency("ipw2100");
+ qos_remove_requirement(QOS_CPU_DMA_LATENCY, "ipw2100");
}
module_init(ipw2100_init);
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos/include/linux/latency.h
linux-2.6.23-rc8-qos-nolatency.c/include/linux/latency.h
--- linux-2.6.23-rc8-qos/include/linux/latency.h2007-07-08
16:32:17.0 -0700
+++ linux-2.6.23-rc8-qos-nolatency.c/include/linux/latency.h1969-12-31
16:00:00.0 -0800
@@ -1,25 +0,0 @@
-/*
- * latency.h: Explicit system-wide latency-expectation infrastructure
- *
- * (C) Copyright 2006 Intel Corporation
- * Author: Arjan van de Ven <[EMAIL PROTECTED]>
- *
- */
-
-#ifndef _INCLUDE_GUARD_LATENCY_H_
-#define _INCLUDE_GUARD_LATENCY_H_
-
-#include
-
-void set_acceptable_latency(char *identifier, int usecs);
-void
Re: [RFC] QoS params patch
The following is the qos_param patch that implements a genralization of
latency.c.
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/include/linux/qos_params.h
linux-2.6.23-rc8-qos/include/linux/qos_params.h
--- linux-2.6.23-rc8/include/linux/qos_params.h 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.23-rc8-qos/include/linux/qos_params.h 2007-09-26
14:05:20.0 -0700
@@ -0,0 +1,35 @@
+/* interface for the qos_power infrastructure of the linux kernel.
+ *
+ * Mark Gross
+ */
+#include
+#include
+#include
+
+struct requirement_list {
+ struct list_head list;
+ union {
+ s32 value;
+ s32 usec;
+ s32 kbps;
+ };
+ char *name;
+};
+
+#define QOS_RESERVED 0
+#define QOS_CPU_DMA_LATENCY 1
+#define QOS_NETWORK_LATENCY 2
+#define QOS_NETWORK_THROUGHPUT 3
+
+#define QOS_NUM_CLASSES 4
+#define QOS_DEFAULT_VALUE -1
+
+int qos_add_requirement(int qos, char *name, s32 value);
+int qos_update_requirement(int qos, char *name, s32 new_value);
+void qos_remove_requirement(int qos, char *name);
+
+int qos_requirement(int qos);
+
+int qos_add_notifier(int qos, struct notifier_block *notifier);
+int qos_remove_notifier(int qos, struct notifier_block *notifier);
+
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/kernel/Makefile linux-2.6.23-rc8-qos/kernel/Makefile
--- linux-2.6.23-rc8/kernel/Makefile2007-09-26 13:54:54.0 -0700
+++ linux-2.6.23-rc8-qos/kernel/Makefile2007-09-26 14:06:38.0
-0700
@@ -9,7 +9,7 @@
rcupdate.o extable.o params.o posix-timers.o \
kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o mutex.o \
hrtimer.o rwsem.o latency.o nsproxy.o srcu.o die_notifier.o \
- utsname.o
+ utsname.o qos_params.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
obj-y += time/
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/kernel/qos_params.c linux-2.6.23-rc8-qos/kernel/qos_params.c
--- linux-2.6.23-rc8/kernel/qos_params.c1969-12-31 16:00:00.0
-0800
+++ linux-2.6.23-rc8-qos/kernel/qos_params.c2007-09-26 15:21:51.0
-0700
@@ -0,0 +1,354 @@
+/*
+ * This module exposes the interface to kernel space for specifying
+ * QoS dependencies. It provides infrastructure for registration of:
+ *
+ * Dependents on a QoS value : register requirements
+ * Watchers of QoS value : get notified when target QoS value changes
+ *
+ * This QoS design is best effort based. Dependents register their QoS needs.
+ * Watchers register to keep track of the current QoS needs of the system.
+ *
+ * There are 3 basic classes of QoS parameter: latency, timeout, throughput
+ * each have defined units:
+ * latency: usec
+ * timeout: usec <-- currently not used.
+ * throughput: kbs (kilo byte / sec)
+ *
+ * There are lists of qos_objects each one wrapping requirements, notifiers
+ *
+ * User mode requirements on a QOS parameter register themselves to the
+ * subsystem by opening the device node /dev/... and writing there request to
+ * the node. As long as the process holds a file handle open to the node the
+ * client continues to be accounted for. Upon file release the usermode
+ * requirement is removed and a new qos target is computed. This way when the
+ * requirement that the application has is cleaned up when closes the file
+ * pointer or exits the qos_object will get an opportunity to clean up.
+ *
+ * mark gross [EMAIL PROTECTED]
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * locking rule: all changes to target_value or requirements or notifiers
lists or
+ * qos_object list and qos_objects need to happen with qos_lock held, taken
+ * with _irqsave. One lock to rule them all
+ */
+
+struct qos_object {
+ struct requirement_list requirements;
+ struct srcu_notifier_head notifiers;
+ struct miscdevice qos_power_miscdev;
+ char * name;
+ s32 default_value;
+ s32 target_value;
+ s32 (* comparitor)(s32,s32);
+};
+static struct qos_object qos_array[QOS_NUM_CLASSES];
+static DEFINE_SPINLOCK(qos_lock);
+
+static ssize_t qos_power_write(struct file *filp, const char __user *buf,
+ size_t count, loff_t *f_pos);
+static int qos_power_open(struct inode *inode, struct file *filp);
+static int qos_power_release(struct inode *inode, struct file *filp);
+
+static const struct file_operations qos_power_fops = {
+ .write = qos_power_write,
+ .open = qos_power_open,
+ .release = qos_power_release,
+};
+
+/* static helper functions */
+static s32 max_compare(s32 v1, s32 v2)
+{
+ if (v1 < v2)
+ return v2;
+ else
+ return v1;
+}
+
+static s32 min_compare(s32 v1, s32 v2)
+{
+ if (v1 < v2)
+ return v1;
+ else
[RFC] QoS power Management enabling patch set
The following patches implement a more generalized infrastructure (than latency.c) for connecting drivers and subsystem's that could implement power performance optimizations with the data needed to implement such policies. These patches are following up on the discussions and presentations at the power management summit last summer. The idea is that from an abstract point of view how much to throttle hardware can be expressed as a function of QoS types of parameters; Latency, throughput, and idle time outs. The qos_parameter patch is intended to put into place the registration and notification infrastructure for enabling QoS based policy choices by drivers, where constraints on throttling are communicated through the qos_params module. Note: it implements a user mode registration protocol where user mode QoS dependents open a misc device node and write there constraints. As long as the file is held open the QoS constraint is included, when the file closes this constraint is removed and a new constraint is computed. I would like some feed back on the idea, implementation and possible applications of this concept we could work on. The current patch set is 2 patches. 1) qos_param : implements the infrastructure and user mode interface 2) no latency : removes latency.c from the kernel tree replacing it with qos_param use. I have a 3rd patch that's a hack application of this qos interface for communicating latency constraints to e1000.c for tweaking the interrupt processing of the e1000 based on acceptable latency gathered from the infrastructure. I'm not proud of this last one but it helps express the idea. Also there is some more documentation and commentary (and an older patch set) on http://www.lesswatts.org/projects/power-qos/ thanks, --mgross - 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 3/3] NCR53C8XX: Remove deprecated IRQ flags (SA_*)
Hi Matthew, A patch to stop using deprecated IRQ flags in ncr53c8xx documentaion. The new IRQF_* macros are used instead. Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> --- diff --git a/Documentation/scsi/ChangeLog.ncr53c8xx b/Documentation/scsi/ChangeLog.ncr53c8xx index 7d03e9d..a9f721a 100644 --- a/Documentation/scsi/ChangeLog.ncr53c8xx +++ b/Documentation/scsi/ChangeLog.ncr53c8xx @@ -195,9 +195,9 @@ Sun Feb 14:00 1999 Gerard Roudier ([EMAIL PROTECTED]) Pointed out by Leonard Zubkoff. - Allow to tune request_irq() flags from the boot command line using ncr53c8xx=irqm:??, as follows: - a) If bit 0x10 is set in irqm, SA_SHIRQ flag is not used. - b) If bit 0x20 is set in irqm, SA_INTERRUPT flag is not used. - By default the driver uses both SA_SHIRQ and SA_INTERRUPT. + a) If bit 0x10 is set in irqm, IRQF_SHARED flag is not used. + b) If bit 0x20 is set in irqm, IRQF_DISABLED flag is not used. + By default the driver uses both IRQF_SHARED and IRQF_DISABLED. Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by a 53C8XX adapter and a network board. - Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index 39d409a..a65cea9 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt @@ -785,8 +785,8 @@ port address 0x1400. irqm:0 always open drain irqm:1 same as initial settings (assumed BIOS settings) irqm:2 always totem pole -irqm:0x10 driver will not use SA_SHIRQ flag when requesting irq -irqm:0x20 driver will not use SA_INTERRUPT flag when requesting irq +irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq +irqm:0x20 driver will not use IRQF_DISABLED flag when requesting irq (Bits 0x10 and 0x20 can be combined with hardware irq mode option) @@ -1236,15 +1236,15 @@ when the SCSI DATA IN phase is reentered after a phase mismatch. When an IRQ is shared by devices that are handled by different drivers, it may happen that one driver complains about the request of the IRQ having failed. Inder Linux-2.0, this may be due to one driver having requested the -IRQ using the SA_INTERRUPT flag but some other having requested the same IRQ +IRQ using the IRQF_DISABLED flag but some other having requested the same IRQ without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by -one driver not having requested the IRQ with the SA_SHIRQ flag. +one driver not having requested the IRQ with the IRQF_SHARED flag. By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the -SA_INTERRUPT and the SA_SHIRQ flag under Linux-2.0 and with only the SA_SHIRQ +IRQF_DISABLED and the IRQF_SHARED flag under Linux-2.0 and with only the IRQF_SHARED flag under Linux-2.2. -Under Linux-2.0, you can disable use of SA_INTERRUPT flag from the boot +Under Linux-2.0, you can disable use of IRQF_DISABLED flag from the boot command line by using the following option: ncr53c8xx=irqm:0x20 (for the generic ncr53c8xx driver) @@ -1252,7 +1252,7 @@ command line by using the following option: If this does not fix the problem, then you may want to check how all other drivers are requesting the IRQ and report the problem. Note that if at least -a single driver does not request the IRQ with the SA_SHIRQ flag (share IRQ), +a single driver does not request the IRQ with the IRQF_SHARED flag (share IRQ), then the request of the IRQ obviously will not succeed for all the drivers. 15. SCSI problem troubleshooting -- Ahmed S. Darwish HomePage: http://darwish.07.googlepages.com Blog: http://darwish-07.blogspot.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: kswapd high CPU usage with no swap
>> When this is sorted out, should I keep the previous patch [1] applied >> as well? > > That doesn't hurt. OK, I've used just the latter patch (because I somehow believe the first one lowers the probability of bad behavior), so let's see if kswapd consumes CPU again. I don't have any test patter to trigger that CPU usage, though... Cheers and thanks for your time, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
[PATCH 2/3] MIPS: Remove deprecated IRQ flags (SA_*)
Hi Ralf,
A patch to stop using deprecated IRQ flags. The new IRQF_* macros are used
instead.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/arch/mips/pci/ops-pmcmsp.c b/arch/mips/pci/ops-pmcmsp.c
index 09fa007..a86a189 100644
--- a/arch/mips/pci/ops-pmcmsp.c
+++ b/arch/mips/pci/ops-pmcmsp.c
@@ -404,7 +404,7 @@ int msp_pcibios_config_access(unsigned char access_type,
if (pciirqflag == 0) {
request_irq(MSP_INT_PCI,/* Hardcoded internal MSP7120 wiring */
bpci_interrupt,
- SA_SHIRQ | SA_INTERRUPT,
+ IRQF_SHARED | IRQF_DISABLED,
"PMC MSP PCI Host",
preg);
pciirqflag = ~0;
diff --git a/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
b/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
index 6fa8572..ab96a2d 100644
--- a/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
+++ b/arch/mips/pmc-sierra/msp71xx/msp_hwbutton.c
@@ -163,7 +163,7 @@ static int msp_hwbutton_register(struct hwbutton_interrupt
*hirq)
CIC_EXT_SET_ACTIVE_HI(cic_ext, hirq->eirq);
*CIC_EXT_CFG_REG = cic_ext;
- return request_irq(hirq->irq, hwbutton_handler, SA_INTERRUPT,
+ return request_irq(hirq->irq, hwbutton_handler, IRQF_DISABLED,
hirq->name, (void *)hirq);
}
--
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.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: xpad_probe: undefined reference to `led_classdev_register'
On Wed, 26 Sep 2007 18:33:22 -0400 Dmitry Torokhov wrote: > Hi, > > On Wednesday 26 September 2007, Randy Dunlap wrote: > > On Wed, 26 Sep 2007 23:25:33 +0200 [EMAIL PROTECTED] wrote: > > > > > Hi. > > > > > > Current linus' git tree: > > > > > > x86_64-unknown-linux-gnu-ld: BFD 2.15 assertion fail > > > /home/thomas/source/crosstool-0.43/build/x86_64-unknown-linux-gnu/gcc-3.4.5-glibc-2.3.6/binutils-2.15/bfd/linker.c:619 > > > drivers/built-in.o(.text+0x20749d): In function `xpad_probe': > > > : undefined reference to `led_classdev_register' > > > drivers/built-in.o(.text+0x20756c): In function `xpad_disconnect': > > > : undefined reference to `led_classdev_unregister' > > > make: *** [.tmp_vmlinux1] Fehler 1 > > > > > > any ideas? > > > > Please send .config file. > > > > Ix xpad driver built-in (yes, it is) and led driver is modular? > > We can fix that... > > > > I have the patch below in mytree. I guess I need to forward it to Linus > insterad of waiting for 2.6.24 as too many people hit this. > > -- > Dmitry > > Input: xpad - fix dependancy on LEDS class > > The driver can not be built-in when LEDS class is a module. > > Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]> Yes, looks good. Thanks. > --- > drivers/input/joystick/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: work/drivers/input/joystick/Kconfig > === > --- work.orig/drivers/input/joystick/Kconfig > +++ work/drivers/input/joystick/Kconfig > @@ -277,7 +277,7 @@ config JOYSTICK_XPAD_FF > > config JOYSTICK_XPAD_LEDS > bool "LED Support for Xbox360 controller 'BigX' LED" > - depends on LEDS_CLASS && JOYSTICK_XPAD > + depends on JOYSTICK_XPAD && (LEDS_CLASS=y || LEDS_CLASS=JOYSTICK_XPAD) > ---help--- > This option enables support for the LED which surrounds the Big X on > XBox 360 controller. > - --- ~Randy Phaedrus says that Quality is about caring. - 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: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents)
On Wed, 2007-09-26 at 15:22 -0700, Linus Torvalds wrote: > > On Wed, 26 Sep 2007, Thomas Gleixner wrote: > > > > > > 1) current Linus' tree doesn't boot with any command line (regression) > > > > > > [ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0 > > Reverted. > > > OK, this explains 2) and 3). I just looked into the code and the logic > > vs. noapictimer on SMP is completely broken. > > ..and thanks for the explanation. > > Thanks for finding it so quickly guys. Sounds like this will be fixed > properly in 2.6.24 with the x86 merge (which hopefully brings in the hrt > patch too) It's even worse than I thought on the first check: "noapictimer" on the command line of an SMP box prevents _ONLY_ the boot CPU apic timer from being used. But the secondary CPU is still unconditionally setting up the APIC timer and uses the non calibrated variable calibration_result, which is of course 0, to setup the APIC timer. Wreckage guaranteed. tglx - 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 1/3] Completely remove deprecated IRQ flags (SA_*)
Hi all,
Only very little files use the deprecated SA_* IRQ flags in latest pull. This
minimal patch series removes such macros from the tree and transfrom old code
to the new IRQF_* flags.
Andrew, I've grepped the whole tree to make sure that no more files than the
patched ones use such deprecated macros. I hope this series won't introduce
build errors.
Patches can be applied cleanly on v2.6.23-rc8.
==>
Get rid of the deprecated SA_* IRQ flags.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5523f19..00bdebb 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -55,28 +55,6 @@
#define IRQF_NOBALANCING 0x0800
#define IRQF_IRQPOLL 0x1000
-/*
- * Migration helpers. Scheduled for removal in 9/2007
- * Do not use for new code !
- */
-static inline
-unsigned long __deprecated deprecated_irq_flag(unsigned long flag)
-{
- return flag;
-}
-
-#define SA_INTERRUPT deprecated_irq_flag(IRQF_DISABLED)
-#define SA_SAMPLE_RANDOM deprecated_irq_flag(IRQF_SAMPLE_RANDOM)
-#define SA_SHIRQ deprecated_irq_flag(IRQF_SHARED)
-#define SA_PROBEIRQdeprecated_irq_flag(IRQF_PROBE_SHARED)
-#define SA_PERCPU deprecated_irq_flag(IRQF_PERCPU)
-
-#define SA_TRIGGER_LOW deprecated_irq_flag(IRQF_TRIGGER_LOW)
-#define SA_TRIGGER_HIGHdeprecated_irq_flag(IRQF_TRIGGER_HIGH)
-#define SA_TRIGGER_FALLING deprecated_irq_flag(IRQF_TRIGGER_FALLING)
-#define SA_TRIGGER_RISING deprecated_irq_flag(IRQF_TRIGGER_RISING)
-#define SA_TRIGGER_MASKdeprecated_irq_flag(IRQF_TRIGGER_MASK)
-
typedef irqreturn_t (*irq_handler_t)(int, void *);
struct irqaction {
Regards,
--
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.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: why network devices don't do reference counting? (Re: [PATCH] Module use count must be updated as bridges are created/destroyed)
On Thu, 27 Sep 2007 00:18:55 +0200 (CEST) Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Sep 26 2007 14:06, Stephen Hemminger wrote: > >> > > >> > No, network devices don't do reference counting. > >> > >> Could you explain why, please? > >> > >> After `udevd` on boot loads lots of unused crap, i surrendered, and use > >> $(rmmod `lsmod | just first column`). Networing bravely wipes away. OK, > >> there are lots of configs: udev, hotplug, modprobe, that somebody might > >> like to fix. But it came to the end with me. I just don't care. So, > >> please answer :) > > > >For hotplug and other reasons, the network developers decided that being > >able to remove a network module at any time was a good thing. It works. > > Except that for ipv6.ko, it's all opposite. After modprobe, > it already got a refcount like 8 and you're wondering how > to get rid of that. ipv6 is not a network driver, it is a protocol. You might be able to remove it if you zap all the routes and applications, ... -- Stephen Hemminger <[EMAIL PROTECTED]> - 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: xpad_probe: undefined reference to `led_classdev_register'
Hi, On Wednesday 26 September 2007, Randy Dunlap wrote: > On Wed, 26 Sep 2007 23:25:33 +0200 [EMAIL PROTECTED] wrote: > > > Hi. > > > > Current linus' git tree: > > > > x86_64-unknown-linux-gnu-ld: BFD 2.15 assertion fail > > /home/thomas/source/crosstool-0.43/build/x86_64-unknown-linux-gnu/gcc-3.4.5-glibc-2.3.6/binutils-2.15/bfd/linker.c:619 > > drivers/built-in.o(.text+0x20749d): In function `xpad_probe': > > : undefined reference to `led_classdev_register' > > drivers/built-in.o(.text+0x20756c): In function `xpad_disconnect': > > : undefined reference to `led_classdev_unregister' > > make: *** [.tmp_vmlinux1] Fehler 1 > > > > any ideas? > > Please send .config file. > > Ix xpad driver built-in (yes, it is) and led driver is modular? > We can fix that... > I have the patch below in mytree. I guess I need to forward it to Linus insterad of waiting for 2.6.24 as too many people hit this. -- Dmitry Input: xpad - fix dependancy on LEDS class The driver can not be built-in when LEDS class is a module. Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]> --- drivers/input/joystick/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: work/drivers/input/joystick/Kconfig === --- work.orig/drivers/input/joystick/Kconfig +++ work/drivers/input/joystick/Kconfig @@ -277,7 +277,7 @@ config JOYSTICK_XPAD_FF config JOYSTICK_XPAD_LEDS bool "LED Support for Xbox360 controller 'BigX' LED" - depends on LEDS_CLASS && JOYSTICK_XPAD + depends on JOYSTICK_XPAD && (LEDS_CLASS=y || LEDS_CLASS=JOYSTICK_XPAD) ---help--- This option enables support for the LED which surrounds the Big X on XBox 360 controller. - 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] mm ecryptfs warning spew on 64bit
Its a size_t to use %Zd
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/fs/ecryptfs/crypto.c
linux-2.6.23rc8-mm1/fs/ecryptfs/crypto.c
--- linux.vanilla-2.6.23rc8-mm1/fs/ecryptfs/crypto.c2007-09-26
16:46:54.0 +0100
+++ linux-2.6.23rc8-mm1/fs/ecryptfs/crypto.c2007-09-26 17:31:47.0
+0100
@@ -1439,7 +1439,7 @@
* crypt_stat->num_header_extents_at_front)
< ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE)) {
rc = -EINVAL;
- printk(KERN_WARNING "Invalid number of header extents: [%d]\n",
+ printk(KERN_WARNING "Invalid number of header extents: [%Zd]\n",
crypt_stat->num_header_extents_at_front);
}
return rc;
-
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/
[GIT PULL] Workaround for broken Geode E820 BIOS
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (1):
[x86 setup] Handle case of improperly terminated E820 chain
arch/i386/boot/memory.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
[Log messages and full diffs follow]
commit 2efa33f81ef56e7700c09a3d8a881c96692149e5
Author: H. Peter Anvin <[EMAIL PROTECTED]>
Date: Wed Sep 26 14:11:43 2007 -0700
[x86 setup] Handle case of improperly terminated E820 chain
At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain. We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.
Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.
Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Jordan Crouse <[EMAIL PROTECTED]>
Cc: Joerg Pommnitz <[EMAIL PROTECTED]>
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..bccaa1c 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@ -20,6 +20,7 @@
static int detect_memory_e820(void)
{
+ int count = 0;
u32 next = 0;
u32 size, id;
u8 err;
@@ -33,14 +34,24 @@ static int detect_memory_e820(void)
"=m" (*desc)
: "D" (desc), "a" (0xe820));
- if (err || id != SMAP)
+ /* Some BIOSes stop returning SMAP in the middle of
+ the search loop. We don't know exactly how the BIOS
+ screwed up the map at that point, we might have a
+ partial map, the full map, or complete garbage, so
+ just return failure. */
+ if (id != SMAP) {
+ count = 0;
break;
+ }
- boot_params.e820_entries++;
+ if (err)
+ break;
+
+ count++;
desc++;
- } while (next && boot_params.e820_entries < E820MAX);
+ } while (next && count < E820MAX);
- return boot_params.e820_entries;
+ return boot_params.e820_entries = count;
}
static int detect_memory_e801(void)
@@ -89,11 +100,16 @@ static int detect_memory_88(void)
int detect_memory(void)
{
+ int err = -1;
+
if (detect_memory_e820() > 0)
- return 0;
+ err = 0;
if (!detect_memory_e801())
- return 0;
+ err = 0;
+
+ if (!detect_memory_88())
+ err = 0;
- return detect_memory_88();
+ return err;
}
-
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: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents)
On Wed, 26 Sep 2007, Thomas Gleixner wrote: > > > > 1) current Linus' tree doesn't boot with any command line (regression) > > > > [ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0 Reverted. > OK, this explains 2) and 3). I just looked into the code and the logic > vs. noapictimer on SMP is completely broken. ..and thanks for the explanation. Thanks for finding it so quickly guys. Sounds like this will be fixed properly in 2.6.24 with the x86 merge (which hopefully brings in the hrt patch too) Linus - 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: Fix boot-time hang on G31/G33 PC
On Wednesday, September 26, 2007 2:56 pm Greg KH wrote: > On Wed, Sep 26, 2007 at 02:55:55PM -0700, Jesse Barnes wrote: > > On Wednesday, September 26, 2007 2:18 pm Greg KH wrote: > > > Due to the issues surrounding this patch, I'm dropping it from my > > > repo. > > > > What issues? Is it causing problems for people? > > I thought this was the patch that Ivan objected to. Yeah, Ivan objected to this, but incorrectly I think. Ivan, your concern is about disabling things like interrupt controllers and power management chips during probe right? You're right that doing that could cause problems if we get and interrupt or PMU event at just the wrong time, but that could just as easily happen if decode was still enabled but the BAR had a bogus address programmed (as it would during probing). Ultimately, I don't care much one way or another as long as we can get the desktop platforms fixed somehow. I think disabling decode is the most correct way of doing this, but I'm open to other solutions (this is the only patch I've seen though that's been tested to solve the problem). Jesse - 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: why network devices don't do reference counting? (Re: [PATCH] Module use count must be updated as bridges are created/destroyed)
On Sep 26 2007 14:06, Stephen Hemminger wrote: >> > >> > No, network devices don't do reference counting. >> >> Could you explain why, please? >> >> After `udevd` on boot loads lots of unused crap, i surrendered, and use >> $(rmmod `lsmod | just first column`). Networing bravely wipes away. OK, >> there are lots of configs: udev, hotplug, modprobe, that somebody might >> like to fix. But it came to the end with me. I just don't care. So, >> please answer :) > >For hotplug and other reasons, the network developers decided that being >able to remove a network module at any time was a good thing. It works. Except that for ipv6.ko, it's all opposite. After modprobe, it already got a refcount like 8 and you're wondering how to get rid of that. - 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: [Bluez-devel] Warnings and Oops on 2.6.23-rc6 while activily using rfcomm links (mm/slab.c)
Hi Pierre-Yves, > Putting the bluetooth system under load (opening and closing several > rfcomm links off several USB adapters, and transmitting data over > them), > I got the Oops below. The computer hung completely, as you can see. > Just > before, I also got those warnings. I got another one that also seems to involve device_move() in some way. No idea on how I really got there. One time after resume it was there and I was simply using my UMTS mobile phone for Internet connection. Regards Marcel general protection fault: [#2] Modules linked in: battery ac thermal fan button ipw2200 ieee80211 ieee80211_cry pt tg3 btusb ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic s lhc option usbserial ohci_hcd bnep bridge llc rfcomm l2cap bluetooth binfmt_misc nfsd exportfs lockd sunrpc uinput parport_pc ppdev parport i915 drm ipv6 acpi_c pufreq cpufreq_stats cpufreq_powersave cpufreq_performance cpufreq_ondemand freq _table cpufreq_conservative sbs container bay dock fuse snd_intel8x0 snd_ac97_co dec ac97_bus pcmcia snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_oss snd_seq_midi s nd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device sdhci firmware_cl ass evdev sg mmc_core yenta_socket rsrc_nonstatic pcmcia_core snd ehci_hcd uhci_ hcd 8250_pci 8250 serial_core thinkpad_acpi hwmon video output soundcore snd_pag e_alloc backlight nvram usbcore processor unix CPU:0 EIP:0060:[]Tainted: G D VLI EFLAGS: 00010282 (2.6.23-rc7 #41) EIP is at dput+0xf/0xf4 eax: fffe ebx: fffe ecx: edx: f70f6d04 esi: fffe edi: f76e14b0 ebp: d16b5de0 esp: d16b5dd8 ds: 007b es: 007b fs: gs: 0033 ss: 0068 Process wvdial (pid: 5229, ti=d16b5000 task=c46a6cb0 task.ti=d16b5000) Stack: f1d8b0a8 fffe d16b5e18 c019539c fffe f77c8ac8 f1d8b0a8 fffe f1d8b0a8 f72f9dc0 f72f9f40 d16b5e48 c01d8fea c5d8bec0 c0359476 f72f9f40 fff4 c5d8bec0 c5d8bec0 Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9d/0xa5 [] show_registers+0x1b5/0x287 [] die+0xf1/0x225 [] do_general_protection+0x1b8/0x1c0 [] error_code+0x6a/0x70 [] sysfs_move_dir+0x1a0/0x1b2 [] kobject_move+0xab/0xf6 [] device_move+0x52/0xed [] rfcomm_tty_open+0x1b9/0x1c4 [rfcomm] [] tty_open+0x170/0x2b1 [] chrdev_open+0xf1/0x137 [] __dentry_open+0xb8/0x169 [] nameidata_to_filp+0x27/0x37 [] do_filp_open+0x33/0x3b [] do_sys_open+0x45/0xc4 [] sys_open+0x1c/0x1e [] sysenter_past_esp+0x6b/0xa1 === Code: 49 43 83 f9 ff 75 e5 89 75 e8 8d 55 e8 89 f8 e8 f0 fd ff ff 83 c4 0c 5b 5e 5f 5d c3 55 89 e5 56 53 89 c3 85 c0 0f 84 e1 00 00 00 <83> 38 01 75 05 e8 17 a0 15 00 ba 40 8b 39 c0 89 d8 e8 cd 6a 06 EIP: [] dput+0xf/0xf4 SS:ESP 0068:d16b5dd8 - 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 3/3] UML - Correctly handle skb allocation failures
On Wed, 26 Sep 2007 17:46:13 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:
> Handle memory allocation failures when reading packets.
>
> We have to read something from the host, even if we can't allocate any
> memory. If we don't, the host side of the device may fill up and stop
> delivering interrupts because no new packets can be queued.
>
> A single sk_buff is allocated whenever an MTU is seen which is larger
> than any seen earlier. This is used to read packets if there is a
> memory allocation failure.
>
> The large MTU check is done from eth_configure, which is called when a
> interface is added to the system, and from uml_net_change_mtu, which
> is called when an existing interface has its MTU changed.
>
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> ---
> arch/um/drivers/net_kern.c | 60
> +
> 1 file changed, 60 insertions(+)
>
> Index: linux-2.6.20/arch/um/drivers/net_kern.c
> ===
> --- linux-2.6.20.orig/arch/um/drivers/net_kern.c 2007-09-26
> 16:48:21.0 -0400
> +++ linux-2.6.20/arch/um/drivers/net_kern.c 2007-09-26 16:56:16.0
> -0400
> @@ -34,6 +34,48 @@ static inline void set_ether_mac(struct
> static DEFINE_SPINLOCK(opened_lock);
> static LIST_HEAD(opened);
>
> +/*
> + * The throwaway skb is used when we can't allocate an skb. The
> + * packet is read into throwaway in order to get the data off the
> + * connection to the host.
> + * It is reallocated whenever an MTU is seen which is larger than
> + * anything seen before. update_throwaway_skb is called from
> + * eth_configure for new interfaces and from uml_net_change_mtu for
> + * MTU changes on existing interfaces.
> + */
> +static DEFINE_SPINLOCK(throwaway_lock);
> +static struct sk_buff *throwaway;
> +static int throwaway_max;
> +
> +static int update_throwaway_skb(int max)
> +{
> + struct sk_buff *new;
> + int err = 0;
> +
> + spin_lock(_lock);
> +
> + if (max <= throwaway_max)
> + goto out;
> +
> + err = -ENOMEM;
> + new = dev_alloc_skb(max);
> + if (new == NULL)
> + goto out;
> +
> + skb_put(new, max);
> +
> + kfree_skb(throwaway);
> + throwaway = new;
> + throwaway_max = max;
> + err = 0;
> +out:
> + spin_unlock(_lock);
> +
> + return err;
> +}
> +
> +int npackets = 0;
Unneeded initialisation?
Maybe not a good name for a global symbol ;)
I worry that the memory at "throwaway" can get thrown away...
> static int uml_net_rx(struct net_device *dev)
> {
> struct uml_net_private *lp = dev->priv;
> @@ -42,7 +84,14 @@ static int uml_net_rx(struct net_device
>
> /* If we can't allocate memory, try again next round. */
> skb = dev_alloc_skb(lp->max_packet);
> + if ((++npackets % 100) == 0){
> + kfree_skb(skb);
> + skb = NULL;
> + }
> +
> if (skb == NULL) {
> + throwaway->dev = dev;
> + (*lp->read)(lp->fd, throwaway, lp);
... while other code is still using it. Are you sure we don't need
throwaway_lock here?
> lp->stats.rx_dropped++;
> return 0;
> }
> @@ -240,6 +289,13 @@ static int uml_net_set_mac(struct net_de
>
> static int uml_net_change_mtu(struct net_device *dev, int new_mtu)
> {
> + struct uml_net_private *lp = dev->priv;
> + int err;
> +
> + err = update_throwaway_skb(lp->max_packet);
> + if (err)
> + return err;
> +
> dev->mtu = new_mtu;
>
> return 0;
> @@ -447,6 +503,10 @@ static void eth_configure(int n, void *i
> dev->watchdog_timeo = (HZ >> 1);
> dev->irq = UM_ETH_IRQ;
>
> + err = update_throwaway_skb(lp->max_packet);
> + if (err)
> + goto out_undo_user_init;
> +
> rtnl_lock();
> err = register_netdevice(dev);
> rtnl_unlock();
-
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] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7
On Wed, 26 Sep 2007 11:42:16 -0700 Jonathan Campbell wrote: > Here is the DMI patch again, written against linux-2.6.23-rc8, > with some of the #ifdef CONFIG_DMI's removed and moved > to include/linux/dmi.h. Putting them there in the way I've done > ensures that you don't have to put #ifdef CONFIG_DMI > around each dmi_check_machine() and that you don't > have to apply little patches to so many device drivers. This patch is horribly whitespace-damaged and does not apply to 2.6.23-rc8 as is: Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] 1 out of 1 hunk ignored -- saving rejects to file arch/i386/Kconfig.rej 1 out of 2 hunks FAILED -- saving rejects to file arch/i386/kernel/acpi/boot.c.rej 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/Kconfig.rej 1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/blacklist.c.rej patch: malformed patch at line 233: */ Please send it to yourself and make sure that you can apply it before sending it to the mailing list. --- ~Randy Phaedrus says that Quality is about caring. - 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] usb serial: Kill another case we pass NULL and shouldn't
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/drivers/usb/serial/console.c
linux-2.6.23rc8-mm1/drivers/usb/serial/console.c
--- linux.vanilla-2.6.23rc8-mm1/drivers/usb/serial/console.c2007-09-26
16:41:47.0 +0100
+++ linux-2.6.23rc8-mm1/drivers/usb/serial/console.c2007-09-18
16:30:08.0 +0100
@@ -164,6 +164,7 @@
}
if (serial->type->set_termios) {
+ struct ktermios dummy;
/* build up a fake tty structure so that the open call has
something
* to look at to get the cflag value */
tty = kzalloc(sizeof(*tty), GFP_KERNEL);
@@ -177,12 +178,13 @@
kfree (tty);
return -ENOMEM;
}
+ memset(, 0, sizeof(struct ktermios));
termios->c_cflag = cflag;
tty->termios = termios;
port->tty = tty;
/* set up the initial termios settings */
- serial->type->set_termios(port, NULL);
+ serial->type->set_termios(port, );
port->tty = NULL;
kfree (termios);
kfree (tty);
-
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] usb_serial: Stop passing NULL to functions that expect data
Earlier patches have removed the checking for old v new differences from
the USB drivers so we can now pass in a valid blank old termios so that
we don't to fill the drivers with magic hacks for console support
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/drivers/serial/serial_core.c
linux-2.6.23rc8-mm1/drivers/serial/serial_core.c
--- linux.vanilla-2.6.23rc8-mm1/drivers/serial/serial_core.c2007-09-26
16:46:54.0 +0100
+++ linux-2.6.23rc8-mm1/drivers/serial/serial_core.c2007-09-18
16:28:20.0 +0100
@@ -1885,6 +1885,7 @@
int baud, int parity, int bits, int flow)
{
struct ktermios termios;
+ static struct ktermios dummy;
int i;
/*
@@ -1930,7 +1931,7 @@
*/
port->mctrl |= TIOCM_DTR;
- port->ops->set_termios(port, , NULL);
+ port->ops->set_termios(port, , );
co->cflag = termios.c_cflag;
return 0;
-
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: Fix boot-time hang on G31/G33 PC
On Wed, Sep 26, 2007 at 02:55:55PM -0700, Jesse Barnes wrote: > On Wednesday, September 26, 2007 2:18 pm Greg KH wrote: > > Due to the issues surrounding this patch, I'm dropping it from my > > repo. > > What issues? Is it causing problems for people? I thought this was the patch that Ivan objected to. thanks, greg k-h - 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: commit 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 kills r8169 send performance
Timo Jantunen <[EMAIL PROTECTED]> : [...] > Thanks for the quick reply and fix. Unfortunately the fix didn't help in my > case. Apply and try each patch of the attached tarball on top of 2.6.23-git until the behavior changes (assuming it does). Patch #000n applies on top of patch #000(n - 1). Good night. -- Ueimor r8169-timo-20070926.tgz Description: GNU Zip compressed data
Re: PCI: Fix boot-time hang on G31/G33 PC
On Wednesday, September 26, 2007 2:18 pm Greg KH wrote: > Due to the issues surrounding this patch, I'm dropping it from my > repo. What issues? Is it causing problems for people? Jesse - 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: xpad_probe: undefined reference to `led_classdev_register'
On Wed, 26 Sep 2007 23:25:33 +0200 [EMAIL PROTECTED] wrote: > Hi. > > Current linus' git tree: > > x86_64-unknown-linux-gnu-ld: BFD 2.15 assertion fail > /home/thomas/source/crosstool-0.43/build/x86_64-unknown-linux-gnu/gcc-3.4.5-glibc-2.3.6/binutils-2.15/bfd/linker.c:619 > drivers/built-in.o(.text+0x20749d): In function `xpad_probe': > : undefined reference to `led_classdev_register' > drivers/built-in.o(.text+0x20756c): In function `xpad_disconnect': > : undefined reference to `led_classdev_unregister' > make: *** [.tmp_vmlinux1] Fehler 1 > > any ideas? Please send .config file. Ix xpad driver built-in (yes, it is) and led driver is modular? We can fix that... --- ~Randy Phaedrus says that Quality is about caring. - 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] pata_atiixp: Audit notes on locking
Signed-off-by: Alan Cox <[EMAIL PROTECTED]> diff -u --new-file --exclude-from /usr/src/exclude --recursive linux.vanilla-2.6.23rc8-mm1/drivers/ata/pata_atiixp.c linux-2.6.23rc8-mm1/drivers/ata/pata_atiixp.c --- linux.vanilla-2.6.23rc8-mm1/drivers/ata/pata_atiixp.c 2007-09-26 16:46:48.0 +0100 +++ linux-2.6.23rc8-mm1/drivers/ata/pata_atiixp.c 2007-09-25 23:59:17.0 +0100 @@ -173,6 +173,9 @@ * * When DMA begins we need to ensure that the UDMA control * register for the channel is correctly set. + * + * Note: The host lock held by the libata layer protects + * us from two channels both trying to set DMA bits at once */ static void atiixp_bmdma_start(struct ata_queued_cmd *qc) @@ -199,6 +202,9 @@ * * DMA has completed. Clear the UDMA flag as the next operations will * be PIO ones not UDMA data transfer. + * + * Note: The host lock held by the libata layer protects + * us from two channels both trying to set DMA bits at once */ static void atiixp_bmdma_stop(struct ata_queued_cmd *qc) - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 06:49:28AM +0930, David Newall wrote: >... > Look, when chroot was being designed, I think they intended that even root > should be unable to get out. They went so far as to say that dot-dot > wouldn't let you out; and it doesn't. >... You are claiming "They went so far as to say that dot-dot wouldn't let you out"? Who are the "they" people you are referring to? And where did "they" explicitely state what you claim they did say? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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] page->mapping clarification [1/3] base functions
On Wed, 26 Sep 2007 20:31:02 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote: > Would that waste a little memory? I think not with SLUB, > but perhaps with SLOB, which packs a little tighter. > maybe just depends on the amount of used anon_vma and page_mapping_info etc... I don't think a system which uses SLOB consumes such structs so much as that memory-for-alignment is considered as "waste" of memory. Anyway, I decided to go ahead with current container-info-per-page implementation. If the size of page struct is problem at mainline inclusion discussion, I'll be back. Thanks, -Kame - 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: State of the Linux PCI Subsystem for 2.6.23-rc8
Greg KH wrote: > On Wed, Sep 26, 2007 at 11:40:58PM +0200, Brice Goglin wrote: > >> Greg KH wrote: >> >>> Here's a summary of the current state of the Linux PCI subsystem, as of >>> 2.6.23-rc8. >>> >>> If the information in here is incorrect, or anyone knows of any >>> outstanding issues not listed here, please let me know. >>> >>> List of outstanding regressions from 2.6.22: >>> - none known. >>> >>> List of outstanding regressions from older kernel versions: >>> - none known. >>> >>> >> What about http://marc.info/?l=linux-pci=11907248538=2 ? >> > > That's not a regression, right? Tt's probably never worked for that > kind of box :) > Ok, fair enough, I can't be sure it ever worked :) > I think the pci bus patches that are pending from Jeff Garzik should fix > up these issues. They are in one of his trees, and in the -mm release, > if you are able to test those. > Ok, I'll see what I can do. Jeff, could you point me to some good candidate patches for fixing this? Brice - 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 3/3] UML - Correctly handle skb allocation failures
Handle memory allocation failures when reading packets.
We have to read something from the host, even if we can't allocate any
memory. If we don't, the host side of the device may fill up and stop
delivering interrupts because no new packets can be queued.
A single sk_buff is allocated whenever an MTU is seen which is larger
than any seen earlier. This is used to read packets if there is a
memory allocation failure.
The large MTU check is done from eth_configure, which is called when a
interface is added to the system, and from uml_net_change_mtu, which
is called when an existing interface has its MTU changed.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
arch/um/drivers/net_kern.c | 60 +
1 file changed, 60 insertions(+)
Index: linux-2.6.20/arch/um/drivers/net_kern.c
===
--- linux-2.6.20.orig/arch/um/drivers/net_kern.c2007-09-26
16:48:21.0 -0400
+++ linux-2.6.20/arch/um/drivers/net_kern.c 2007-09-26 16:56:16.0
-0400
@@ -34,6 +34,48 @@ static inline void set_ether_mac(struct
static DEFINE_SPINLOCK(opened_lock);
static LIST_HEAD(opened);
+/*
+ * The throwaway skb is used when we can't allocate an skb. The
+ * packet is read into throwaway in order to get the data off the
+ * connection to the host.
+ * It is reallocated whenever an MTU is seen which is larger than
+ * anything seen before. update_throwaway_skb is called from
+ * eth_configure for new interfaces and from uml_net_change_mtu for
+ * MTU changes on existing interfaces.
+ */
+static DEFINE_SPINLOCK(throwaway_lock);
+static struct sk_buff *throwaway;
+static int throwaway_max;
+
+static int update_throwaway_skb(int max)
+{
+ struct sk_buff *new;
+ int err = 0;
+
+ spin_lock(_lock);
+
+ if (max <= throwaway_max)
+ goto out;
+
+ err = -ENOMEM;
+ new = dev_alloc_skb(max);
+ if (new == NULL)
+ goto out;
+
+ skb_put(new, max);
+
+ kfree_skb(throwaway);
+ throwaway = new;
+ throwaway_max = max;
+ err = 0;
+out:
+ spin_unlock(_lock);
+
+ return err;
+}
+
+int npackets = 0;
+
static int uml_net_rx(struct net_device *dev)
{
struct uml_net_private *lp = dev->priv;
@@ -42,7 +84,14 @@ static int uml_net_rx(struct net_device
/* If we can't allocate memory, try again next round. */
skb = dev_alloc_skb(lp->max_packet);
+ if ((++npackets % 100) == 0){
+ kfree_skb(skb);
+ skb = NULL;
+ }
+
if (skb == NULL) {
+ throwaway->dev = dev;
+ (*lp->read)(lp->fd, throwaway, lp);
lp->stats.rx_dropped++;
return 0;
}
@@ -240,6 +289,13 @@ static int uml_net_set_mac(struct net_de
static int uml_net_change_mtu(struct net_device *dev, int new_mtu)
{
+ struct uml_net_private *lp = dev->priv;
+ int err;
+
+ err = update_throwaway_skb(lp->max_packet);
+ if (err)
+ return err;
+
dev->mtu = new_mtu;
return 0;
@@ -447,6 +503,10 @@ static void eth_configure(int n, void *i
dev->watchdog_timeo = (HZ >> 1);
dev->irq = UM_ETH_IRQ;
+ err = update_throwaway_skb(lp->max_packet);
+ if (err)
+ goto out_undo_user_init;
+
rtnl_lock();
err = register_netdevice(dev);
rtnl_unlock();
-
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/3] UML - Network driver MTU cleanups
A bunch of MTU-related cleanups in the network code.
First, there is the addition of the notion of a maximally-sized
packet, which is the MTU plus headers. This is used to size the skb
that will receive a packet. This allows ether_adjust_skb to go away,
as it was used to resize the skb after it was allocated.
Since the skb passed into the low-level read routine is no longer
resized, and possibly reallocated, there, they (and the write
routines) don't need to get an sk_buff **. They just need the sk_buff
* now. The callers of ether_adjust_skb still need to do the skb_put,
so that's now inlined.
The MAX_PACKET definitions in most of the drivers are gone.
The set_mtu methods were all the same and did nothing, so they can be
removed.
The ethertap driver had a typo which doubled the size of the packet
rather than adding two bytes to it. It also wasn't defining its
setup_size, causing a zero-byte kmalloc and crash when the invalid
pointer returned from kmalloc was dereferenced.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
arch/um/drivers/daemon_kern.c| 15 +++
arch/um/drivers/daemon_user.c| 11 +---
arch/um/drivers/mcast_kern.c | 13 +++--
arch/um/drivers/mcast_user.c | 11 +---
arch/um/drivers/net_kern.c | 42 +--
arch/um/drivers/pcap_kern.c | 13 ++---
arch/um/drivers/pcap_user.c |9 ++
arch/um/drivers/slip_kern.c | 10 ++-
arch/um/drivers/slip_user.c |9 +-
arch/um/drivers/slirp_kern.c | 14 --
arch/um/drivers/slirp_user.c |9 +-
arch/um/drivers/vde_kern.c | 19 +-
arch/um/drivers/vde_user.c | 11 +---
arch/um/include/net_kern.h | 13 -
arch/um/include/net_user.h |4 +-
arch/um/os-Linux/drivers/ethertap_kern.c | 30 +++---
arch/um/os-Linux/drivers/ethertap_user.c |9 +-
arch/um/os-Linux/drivers/tuntap_kern.c | 15 +++
arch/um/os-Linux/drivers/tuntap_user.c | 11 +---
19 files changed, 80 insertions(+), 188 deletions(-)
Index: linux-2.6.20/arch/um/drivers/daemon_user.c
===
--- linux-2.6.20.orig/arch/um/drivers/daemon_user.c 2007-09-26
17:14:22.0 -0400
+++ linux-2.6.20/arch/um/drivers/daemon_user.c 2007-09-26 17:19:31.0
-0400
@@ -19,8 +19,6 @@
#include "um_malloc.h"
#include "user.h"
-#define MAX_PACKET (ETH_MAX_PACKET + ETH_HEADER_OTHER)
-
enum request_type { REQ_NEW_CONTROL };
#define SWITCH_MAGIC 0xfeedface
@@ -184,18 +182,13 @@ int daemon_user_write(int fd, void *buf,
return net_sendto(fd, buf, len, data_addr, sizeof(*data_addr));
}
-static int daemon_set_mtu(int mtu, void *data)
-{
- return mtu;
-}
-
const struct net_user_info daemon_user_info = {
.init = daemon_user_init,
.open = daemon_open,
.close = NULL,
.remove = daemon_remove,
- .set_mtu= daemon_set_mtu,
.add_address= NULL,
.delete_address = NULL,
- .max_packet = MAX_PACKET - ETH_HEADER_OTHER
+ .mtu= ETH_MAX_PACKET,
+ .max_packet = ETH_MAX_PACKET + ETH_HEADER_OTHER,
};
Index: linux-2.6.20/arch/um/drivers/mcast_user.c
===
--- linux-2.6.20.orig/arch/um/drivers/mcast_user.c 2007-09-26
17:14:22.0 -0400
+++ linux-2.6.20/arch/um/drivers/mcast_user.c 2007-09-26 17:19:31.0
-0400
@@ -20,8 +20,6 @@
#include "um_malloc.h"
#include "user.h"
-#define MAX_PACKET (ETH_MAX_PACKET + ETH_HEADER_OTHER)
-
static struct sockaddr_in *new_addr(char *addr, unsigned short port)
{
struct sockaddr_in *sin;
@@ -154,18 +152,13 @@ int mcast_user_write(int fd, void *buf,
return net_sendto(fd, buf, len, data_addr, sizeof(*data_addr));
}
-static int mcast_set_mtu(int mtu, void *data)
-{
- return mtu;
-}
-
const struct net_user_info mcast_user_info = {
.init = mcast_user_init,
.open = mcast_open,
.close = mcast_close,
.remove = mcast_remove,
- .set_mtu= mcast_set_mtu,
.add_address= NULL,
.delete_address = NULL,
- .max_packet = MAX_PACKET - ETH_HEADER_OTHER
+ .mtu= ETH_MAX_PACKET,
+ .max_packet = ETH_MAX_PACKET + ETH_HEADER_OTHER,
};
Index: linux-2.6.20/arch/um/drivers/pcap_user.c
===
--- linux-2.6.20.orig/arch/um/drivers/pcap_user.c 2007-09-26
17:14:22.0 -0400
+++ linux-2.6.20/arch/um/drivers/pcap_user.c2007-09-26 17:19:31.0
-0400
@@ -13,8 +13,6 @@
#include "um_malloc.h"
#include "user.h"
Re: State of the Linux PCI Subsystem for 2.6.23-rc8
On Wed, Sep 26, 2007 at 11:40:58PM +0200, Brice Goglin wrote: > Greg KH wrote: > > Here's a summary of the current state of the Linux PCI subsystem, as of > > 2.6.23-rc8. > > > > If the information in here is incorrect, or anyone knows of any > > outstanding issues not listed here, please let me know. > > > > List of outstanding regressions from 2.6.22: > > - none known. > > > > List of outstanding regressions from older kernel versions: > > - none known. > > > > What about http://marc.info/?l=linux-pci=11907248538=2 ? That's not a regression, right? Tt's probably never worked for that kind of box :) I think the pci bus patches that are pending from Jeff Garzik should fix up these issues. They are in one of his trees, and in the -mm release, if you are able to test those. thanks, greg k-h - 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] bw-qcam: use data_reverse instead of manually poking the control register
On 9/26/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> On 9/26/07, Brett Warden <[EMAIL PROTECTED]> wrote:
> > On 9/26/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> >
> > > Just as an aside, if you've tested this and it works, then there's no
> > > point to keep the write_lpcontrol even as a comment. Kill those four
> > > lines, and if someone's interested in what happened they'll just look
> > > at the file history.
> >
> > Point taken, thanks for the feedback.
> >
> > ---
> >
> > diff --git a/drivers/media/video/bw-qcam.c b/drivers/media/video/bw-qcam.c
> > index 7d47cbe..0ba92e3 100644
> > --- a/drivers/media/video/bw-qcam.c
> > +++ b/drivers/media/video/bw-qcam.c
> > @@ -107,6 +107,11 @@ static inline void write_lpcontrol(struct
> > qcam_device *q, int d)
> > parport_write_control(q->pport, d);
> > }
> >
> > +static inline void reverse_port(struct qcam_device *q)
> > +{
> > + parport_data_reverse(q->pport);
> > +}
> > +
> > static int qc_waithand(struct qcam_device *q, int val);
> > static int qc_command(struct qcam_device *q, int command);
> > static int qc_readparam(struct qcam_device *q);
> > @@ -369,7 +374,7 @@ static void qc_reset(struct qcam_device *q)
> > break;
> >
> > case QC_ANY:
> > - write_lpcontrol(q, 0x20);
> > + reverse_port(q);
> > write_lpdata(q, 0x75);
> >
> > if (read_lpdata(q) != 0x75) {
> > @@ -512,10 +517,12 @@ static inline int qc_readbytes(struct
> > qcam_device *q, char buffer[])
> > switch (q->port_mode & QC_MODE_MASK)
> > {
> > case QC_BIDIR: /* Bi-directional Port */
> > - write_lpcontrol(q, 0x26);
> > + reverse_port(q);
> > + write_lpcontrol(q, 0x6);
> > lo = (qc_waithand2(q, 1) >> 1);
> > hi = (read_lpstatus(q) >> 3) & 0x1f;
> > - write_lpcontrol(q, 0x2e);
> > + reverse_port(q);
> > + write_lpcontrol(q, 0xe);
> > lo2 = (qc_waithand2(q, 0) >> 1);
> > hi2 = (read_lpstatus(q) >> 3) & 0x1f;
> > switch (q->bpp)
> > @@ -613,10 +620,13 @@ static long qc_capture(struct qcam_device * q,
> > char __user *buf, unsigned long l
> >
> > if ((q->port_mode & QC_MODE_MASK) == QC_BIDIR)
> > {
> > - write_lpcontrol(q, 0x2e); /* turn port around */
> > - write_lpcontrol(q, 0x26);
> > + reverse_port(q);/* turn port around
> > */
> > + write_lpcontrol(q, 0xe);
> > + reverse_port(q);
> > + write_lpcontrol(q, 0x6);
> > (void) qc_waithand(q, 1);
> > - write_lpcontrol(q, 0x2e);
> > + reverse_port(q);
> > + write_lpcontrol(q, 0xe);
> > (void) qc_waithand(q, 0);
> > }
>
> Better, and do you have time for two (possibly stupid) questions? In
> each of the last cases it looks like the transformation is from a
> write_lpcontrol -> reverse_port and a write_lpcontrol (old address -
> 0x20). Except the first one, which merely has the reverse_port. One
> would think that there should be a write_lpcontrol(q, 0x0); after that
> one.
>
> Also, is the reverse port sticky, or does it only apply to the next
> write? If it's only the next, then maybe a different name would be
> better. If it's sticky, then I think the code is wrong...
In response to Randy's and your questions, here's what I understand:
The error message comes from parport_pc_write_control in
include/linux/parport_pc.h, which is called by bw-qcam's
write_lpcontrol():
static __inline__ void parport_pc_write_control (struct parport *p,
unsigned char d)
{
const unsigned char wm = (PARPORT_CONTROL_STROBE |
PARPORT_CONTROL_AUTOFD |
PARPORT_CONTROL_INIT |
PARPORT_CONTROL_SELECT);
/* Take this out when drivers have adapted to newer interface. */
if (d & 0x20) {
printk (KERN_DEBUG "%s (%s): use data_reverse for this!\n",
p->name, p->cad->name);
parport_pc_data_reverse (p);
}
__parport_pc_frob_control (p, wm, d & wm);
}
The mask wm works out to 0x0f, so first it calls
parport_pc_data_reverse(), then masks off the high nibble with the
reverse flag and makes the regular call.
Looking at that more carefully, I'm not sure whether I need to add the
write_lpcontrol(q, 0) after the first call. Other than that, I believe
I'm following the same procedure.
As for whether data_reverse is sticky, I don't know... I'll see what I
can find out.
--
Brett Warden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH 13/25] Unionfs: add un/likely conditionals on dir ops
Erez Zadok wrote: > @@ -194,7 +194,7 @@ int check_empty(struct dentry *dentry, struct > unionfs_dir_state **namelist) > > BUG_ON(!S_ISDIR(dentry->d_inode->i_mode)); > > - if ((err = unionfs_partial_lookup(dentry))) > + if (unlikely((err = unionfs_partial_lookup(dentry > goto out; > > bstart = dbstart(dentry); Is it bad to leave this assignment within the unlikely()? - 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: State of the Linux PCI Subsystem for 2.6.23-rc8
Greg KH wrote: > Here's a summary of the current state of the Linux PCI subsystem, as of > 2.6.23-rc8. > > If the information in here is incorrect, or anyone knows of any > outstanding issues not listed here, please let me know. > > List of outstanding regressions from 2.6.22: > - none known. > > List of outstanding regressions from older kernel versions: > - none known. > What about http://marc.info/?l=linux-pci=11907248538=2 ? Brice - 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: jbd : config_jbd_debug cannot create /proc entry
On Tue, 25 Sep 2007 16:36:08 +0200
Jan Kara <[EMAIL PROTECTED]> wrote:
> > On Tue, 25 Sep 2007 07:49:38 -0500
> > "Jose R. Santos" <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 25 Sep 2007 13:50:46 +0200
> > > Jan Kara <[EMAIL PROTECTED]> wrote:
> > > > > Jan Kara wrote:
> > > > > >>
> > > > > >-#define create_jbd_proc_entry() do {} while (0)
> > > > > >-#define remove_jbd_proc_entry() do {} while (0)
> > > > > >+static ctl_table fs_table[] = {
> > > > > >+{
> > > > > >+.ctl_name = -1, /* Don't want it */
> > > > >
> > > > >
> > > > >
> > > > > shouldn't this be CTL_UNNUMBERED ?
> > > > Oh, it should be. I didn't notice we have this :) Thanks for notifying
> > > > me. Attached is a fixed version.
> > >
> > > This was fixed in JBD2 by moving the jbd-debug file to debugfs:
> > > http://lkml.org/lkml/2007/7/11/334
> > >
> > > Since this code is already in the kernel, we should keep it consistent.
> > >
> >
> > OK. Here's a quick patch to fix this. Adapted from the JBD2 patch.
> > Let me know what you think.
> Looks fine - exactly what I've just done here :).
hm. I found rather a lot of issues. If this patch is derived from the
JBD2 patch then perhaps the JBD2 patch needs some looking at.
> > Signed-off-by: Jose R. Santos <[EMAIL PROTECTED]>
> You can add Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
I suspect you might be getting your signed-off-bys and acked-bys mixed up.
(If not this patch, then the previous one). Please see
Documentation/SubmittingPatches section 13 for the difference.
Jose, please review and if possible runtime test these proposed changes?
From: Andrew Morton <[EMAIL PROTECTED]>
- use `#ifdef foo' instead of `#if defined(foo)'
- CONFIG_JBD_DEBUG depends on CONFIG_DEBUG_FS so we don't need to duplicate
that logic in the .c file ifdefs
- Make journal_enable_debug __read_mostly just for the heck of it
- Make jbd_debugfs_dir and jbd_debug static
- debugfs_remove(NULL) is legal: remove unneeded tests
- jbd_create_debugfs_entry is a better name than create_jbd_debugfs_entry
- ditto remove_jbd_debugfs_entry
- C functions are preferred over macros
Cc: "Jose R. Santos" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: Jan Kara <[EMAIL PROTECTED]>
Cc: Jose R. Santos <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
diff -puN fs/jbd/journal.c~jbd-config_jbd_debug-cannot-create-proc-entry-fix
fs/jbd/journal.c
--- a/fs/jbd/journal.c~jbd-config_jbd_debug-cannot-create-proc-entry-fix
+++ a/fs/jbd/journal.c
@@ -1853,16 +1853,15 @@ void journal_put_journal_head(struct jou
/*
* debugfs tunables
*/
-#if defined(CONFIG_JBD_DEBUG)
-u8 journal_enable_debug;
-EXPORT_SYMBOL(journal_enable_debug);
-#endif
+#ifdef CONFIG_JBD_DEBUG
-#if defined(CONFIG_JBD_DEBUG) && defined(CONFIG_DEBUG_FS)
+u8 journal_enable_debug __read_mostly;
+EXPORT_SYMBOL(journal_enable_debug);
-struct dentry *jbd_debugfs_dir, *jbd_debug;
+static struct dentry *jbd_debugfs_dir;
+static struct dentry *jbd_debug;
-static void __init create_jbd_debugfs_entry(void)
+static void __init jbd_create_debugfs_entry(void)
{
jbd_debugfs_dir = debugfs_create_dir("jbd", NULL);
if (jbd_debugfs_dir)
@@ -1871,18 +1870,21 @@ static void __init create_jbd_debugfs_en
_enable_debug);
}
-static void __exit remove_jbd_debugfs_entry(void)
+static void __exit jbd_remove_debugfs_entry(void)
{
- if (jbd_debug)
- debugfs_remove(jbd_debug);
- if (jbd_debugfs_dir)
- debugfs_remove(jbd_debugfs_dir);
+ debugfs_remove(jbd_debug);
+ debugfs_remove(jbd_debugfs_dir);
}
#else
-#define create_jbd_debugfs_entry() do {} while (0)
-#define remove_jbd_debugfs_entry() do {} while (0)
+static inline void jbd_create_debugfs_entry(void)
+{
+}
+
+static inline void jbd_remove_debugfs_entry(void)
+{
+}
#endif
@@ -1940,7 +1942,7 @@ static int __init journal_init(void)
ret = journal_init_caches();
if (ret != 0)
journal_destroy_caches();
- create_jbd_debugfs_entry();
+ jbd_create_debugfs_entry();
return ret;
}
@@ -1951,7 +1953,7 @@ static void __exit journal_exit(void)
if (n)
printk(KERN_EMERG "JBD: leaked %d journal_heads!\n", n);
#endif
- remove_jbd_debugfs_entry();
+ jbd_remove_debugfs_entry();
journal_destroy_caches();
}
_
-
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 11/25] Unionfs: add un/likely conditionals on debug ops
Erez Zadok wrote:
> Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
> ---
> fs/unionfs/debug.c | 108 +++
> 1 files changed, 57 insertions(+), 51 deletions(-)
>
> diff --git a/fs/unionfs/debug.c b/fs/unionfs/debug.c
> index 9546a41..09b52ce 100644
> --- a/fs/unionfs/debug.c
> +++ b/fs/unionfs/debug.c
> @@ -56,19 +56,19 @@ void __unionfs_check_inode(const struct inode *inode,
> sb = inode->i_sb;
> istart = ibstart(inode);
> iend = ibend(inode);
> - if (istart > iend) {
> + if (unlikely(istart > iend)) {
> PRINT_CALLER(fname, fxn, line);
> printk(" Ci0: inode=%p istart/end=%d:%d\n",
> inode, istart, iend);
> }
> - if ((istart == -1 && iend != -1) ||
> - (istart != -1 && iend == -1)) {
> + if (unlikely((istart == -1 && iend != -1) ||
> + (istart != -1 && iend == -1))) {
you could also do
if (unlikely((istart == -1 || iend == -1) && istart != iend)) {
[...]
> @@ -138,8 +139,8 @@ void __unionfs_check_dentry(const struct dentry *dentry,
> dend = dbend(dentry);
> BUG_ON(dstart > dend);
>
> - if ((dstart == -1 && dend != -1) ||
> - (dstart != -1 && dend == -1)) {
> + if (unlikely((dstart == -1 && dend != -1) ||
> + (dstart != -1 && dend == -1))) {
[...]
the same here
> @@ -223,30 +224,30 @@ void __unionfs_check_dentry(const struct dentry *dentry,
> istart = ibstart(inode);
> iend = ibend(inode);
> BUG_ON(istart > iend);
> - if ((istart == -1 && iend != -1) ||
> - (istart != -1 && iend == -1)) {
> + if (unlikely((istart == -1 && iend != -1) ||
> + (istart != -1 && iend == -1))) {
and here
[...]
> @@ -350,30 +354,30 @@ void __unionfs_check_file(const struct file *file,
> fend = fbend(file);
> BUG_ON(fstart > fend);
>
> - if ((fstart == -1 && fend != -1) ||
> - (fstart != -1 && fend == -1)) {
> + if (unlikely((fstart == -1 && fend != -1) ||
> + (fstart != -1 && fend == -1))) {
and here
[...]
-
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: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents)
Rafael, On Wed, 2007-09-26 at 23:00 +0200, Rafael J. Wysocki wrote: > > > > First, with the "x86-64: Disable local APIC timer use on AMD systems > > > > with C1E" > > > > patch and my collection of suspend patches applied, the box doesn't boot > > > > (the suspend patches don't even thouch the boot code, so they should be > > > > irrelevant here). However, it boots if patch-2.6.23-rc7-hrt1.patch > > > > (adjusted > > > > for 2.6.23-rc8) is applied in addition. Is this expected? > > > > > > No. That's odd. It is nothing else than adding "noapictimer" to the > > > kernel command line. > > > > Seems to be reproducible, though. I'll investigate further. > > So far, the results are the following: > > 1) current Linus' tree doesn't boot with any command line (regression) > > [ Linus, please revert commit e66485d747505e9d960b864fc6c37f8b2afafaf0 > >x86-64: Disable local APIC timer use on AMD systems with C1E > >It's not necessary for 2.6.23 and actually kills the box that it's > supposed to fix. ] > > 2) 2.6.23-rc8 w/ the "x86-64: Disable local APIC timer use on AMD systems > with C1E" >patch applied behaves like the current -git > > 3) 2.6.23-rc8 w/o this patch doesn't boot with either "noapictimer" _or_ OK, this explains 2) and 3). I just looked into the code and the logic vs. noapictimer on SMP is completely broken. On i386 the noapictimer option not only disables the local APIC timer, it also registers the CPUs for broadcasting via IPI on SMP systems. The x8664 code uses the broadcast only when the local apic timer is active, i.e. "noapictimer" is not on the command line. This defeats the whole purpose of "noapictimer". It should be there to make boxen work, where the local APIC timer actually has a hardware problem, e.g. the nx6325. The current implementation of x86_64 only fixes the ACPI c-states related problem where the APIC timer stops in C3(2), nothing else. On nx6325 and other AMD X2 equipped systems which have the C1E enabled we run into the following: PIT keeps jiffies (and the system) running, but the local APIC timer interrupts can get out of sync due to this C1E effect. I don't think this is a critical problem, but it is wrong nevertheless. I think it's safe to revert the C1E patch and postpone the fix to the clock events conversion. > "apicmaintimer" on your box is not going to work. See the C1E patch. "apicmaintimer" switches off PIT and then waits for ever for the local APIC timer interrupts. > 4) 2.6.22 behaves like 2.6.23-rc8 No surprise > 5) 2.6.23-rc8 with (adjusted) patch-2.6.23-rc7-hrt1.patch boots only with >"noapictimer" > > 6) 2.6.23-rc8 with (adjusted) patch-2.6.23-rc7-hrt1.patch and with the >"x86-64: Disable local APIC timer use on AMD systems with C1E" patch boots >without any extra command line options That's consistent behaviour. > Tested for a couple of times with each kernel, the results seem to be > reproducible 100% of the time. Thanks for going through this debug marathon. tglx - 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: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
On 26/09/07 14:20 -0700, H. Peter Anvin wrote:
> Testing this patch now:
>
> >From 2efa33f81ef56e7700c09a3d8a881c96692149e5 Mon Sep 17 00:00:00 2001
> From: H. Peter Anvin <[EMAIL PROTECTED]>
> Date: Wed, 26 Sep 2007 14:11:43 -0700
> Subject: [PATCH] [x86 setup] Handle case of improperly terminated E820 chain
>
> At least one system (a Geode system with a Digital Logic BIOS) has
> been found which suddenly stops reporting the SMAP signature when
> reading the E820 memory chain. We can't know what, exactly, broke in
> the BIOS, so if we detect this situation, declare the E820 data
> unusable and fall back to E801.
>
> Also, revert to original behavior of always probing all memory
> methods; that way all the memory information is available to the
> kernel.
>
> Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
> Cc: Jordan Crouse <[EMAIL PROTECTED]>
> Cc: Joerg Pommnitz <[EMAIL PROTECTED]>
> ---
> arch/i386/boot/memory.c | 30 +++---
> 1 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
> index 1a2e62d..bccaa1c 100644
> --- a/arch/i386/boot/memory.c
> +++ b/arch/i386/boot/memory.c
> @@ -20,6 +20,7 @@
>
> static int detect_memory_e820(void)
> {
> + int count = 0;
> u32 next = 0;
> u32 size, id;
> u8 err;
> @@ -33,14 +34,24 @@ static int detect_memory_e820(void)
> "=m" (*desc)
> : "D" (desc), "a" (0xe820));
>
> - if (err || id != SMAP)
> + /* Some BIOSes stop returning SMAP in the middle of
> +the search loop. We don't know exactly how the BIOS
> +screwed up the map at that point, we might have a
> +partial map, the full map, or complete garbage, so
> +just return failure. */
> + if (id != SMAP) {
> + count = 0;
> break;
> + }
>
> - boot_params.e820_entries++;
> + if (err)
> + break;
> +
> + count++;
> desc++;
> - } while (next && boot_params.e820_entries < E820MAX);
> + } while (next && count < E820MAX);
>
> - return boot_params.e820_entries;
> + return boot_params.e820_entries = count;
> }
>
> static int detect_memory_e801(void)
> @@ -89,11 +100,16 @@ static int detect_memory_88(void)
>
> int detect_memory(void)
> {
> + int err = -1;
> +
> if (detect_memory_e820() > 0)
> - return 0;
> + err = 0;
>
> if (!detect_memory_e801())
> - return 0;
> + err = 0;
> +
> + if (!detect_memory_88())
> + err = 0;
>
> - return detect_memory_88();
> + return err;
> }
> --
> 1.5.3.1
>
Works here with the buggy BIOS.
Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
Thanks.
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
-
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] Add iSCSI iBFT support.
On Wed, 26 Sep 2007 14:46:52 -0400 Konrad Rzeszutek wrote:
> 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.
>
> 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 <[EMAIL PROTECTED]>
> Signed-off-by: Peter Jones <[EMAIL PROTECTED]>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 05f02a3..2d9f01a 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -93,4 +93,14 @@ config DMIID
> information from userspace through /sys/class/dmi/id/ or if you want
> DMI-based module auto-loading.
>
> +config ISCSI_IBFT
> + tristate "iSCSI Boot Firmware Table Attributes"
> + depends on X86
why only on X86?
> + default n
> + help
> + This option enables support for detection of an iSCSI
> + Boot Firmware Table (iBFT). If you wish to detect iSCSI boot
> + parameters dynamically during system boot, say Y.
> + Otherwise, say N.
> +
> endmenu
> diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c
> new file mode 100644
> index 000..b3767fe
> --- /dev/null
> +++ b/drivers/firmware/iscsi_ibft.c
> @@ -0,0 +1,201 @@
> +/*
> + * drivers/firmware/iscsi_ibft.c
Don't repeat the file name.
> + * Copyright 2007 Red Hat, Inc.
> + * by Peter Jones <[EMAIL PROTECTED]>
> + * Copyright 2007 IBM
> + * by Konrad Rzeszutek <[EMAIL PROTECTED]>
> + *
> + * This code exposes the the iSCSI Boot Format Table to userland via sysfs.
~~~
yes.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
no blank line here.
> +#include
> +
> +#define ISCSI_IBFT_VERSION "0.2"
> +#define ISCSI_IBFT_DATE "2007-Aug-29"
> +
> +MODULE_AUTHOR
> +("Peter Jones <[EMAIL PROTECTED]> and Konrad Rzeszutek <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("sysfs interface to BIOS iBFT information");
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION(ISCSI_IBFT_VERSION);
> +
> +
> +static ssize_t
> +ibft_read_binary(struct kobject *kobj, struct bin_attribute *attr, char *buf,
> + loff_t off, size_t count)
Put 'static ssize_t' on same line as function name, then put parameters
on following lines as needed.
> +{
> +
> + struct ibft_device *ibft = container_of(kobj, struct ibft_device, kobj);
> + ssize_t len = ibft->hdr->length;
> +
> + if (off > len)
> + return 0;
> +
> + if (off + count > len)
> + count = len - off;
> +
> + memcpy(buf, ibft->hdr + off, count);
> +
> + return count;
> +}
> +static int
> +ibft_mmap_binary(struct kobject *kobj, struct bin_attribute *attr,
> + struct vm_area_struct *vma)
ditto.
> +{
...
> +}
> +static struct bin_attribute ibft_attribute_binary = {
> + .attr = {
> + .name = "binary",
> + .mode = S_IRUSR,
> + .owner = THIS_MODULE,
> + },
> + .read = ibft_read_binary,
> + .write = NULL,
> + .mmap = ibft_mmap_binary
> +};
> +static struct kobj_type ktype_ibft = {
> + .release = ibft_release,
> +};
> +
> +static decl_subsys(ibft, _ibft, NULL);
> +
> +static int ibft_device_register(struct ibft_device *idev)
> +{
> + int error = 0;
> + int len = 0;
> + struct ibft_header *hdr;
> +
> + if (!idev)
> + return 1;
> +
> + /* Copy over the data */
> + hdr = (struct ibft_header *)phys_to_virt((unsigned long)ibft_phys);
> + len = hdr->length;
> +
> + /* Need PAGE_ALING for mmap functionality. */
PAGE_ALIGN
> + idev->hdr = kzalloc(PAGE_ALIGN(len), GFP_KERNEL);
> + if (!idev->hdr)
> + return -ENOMEM;
> +
> + memcpy(idev->hdr, hdr, len);
> +
> + /* This is firmware/ibft */
> + kobject_set_name(>kobj, "table");
> + kobj_set_kset_s(idev, ibft_subsys);
> + error = kobject_register(>kobj);
> +
> + if (!error) {
> + ibft_attribute_binary.size = idev->hdr->length;
> + error =
> + sysfs_create_bin_file(>kobj, _attribute_binary);
> + }
> +
> + /* The de-allocation part is done by module_exit() */
> + return error;
> +}
> +
> +static struct ibft_device *ibft_idev;
...
> +static void __exit ibft_exit(void)
> +{
> + if (ibft_idev)
> + kobject_unregister(_idev->kobj);
> +
> + firmware_unregister(_subsys);
> + printk(KERN_INFO "BIOS iBFT unloaded.\n");
Drop the unload message. ibft_init() is also
Re: v2.6.23-rc4-rt1 / new project URL
-- On Wed, 26 Sep 2007, Peter Zijlstra wrote: > On Mon, 2007-09-10 at 14:35 +0200, Peter Zijlstra wrote: > > > A bunch of patches are postponed for -rt2 (they are neither ignored > > > nor forgotten): > > > > > > - simple_irq change (Kevin Hilman): needs more thought > > > - RCU updates (Paul McKenney): needs proper integration > > > - latency tracer changes (Daniel Walker): needs review > > > - PICK_OP changes (Daniel Walker): needs review > > > > This one seems to have slipped through the cracks: > > http://lkml.org/lkml/2007/8/16/135 > > Seems to be missed again :-/ > Will work on that tonight. -- Steve - 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] Add iSCSI iBFT support.
On Wed, 26 Sep 2007 14:46:52 -0400 Konrad Rzeszutek wrote: > 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? i.e., what is this binary blob (?) I don't see a binary blob in this patch (as stated in the first sentence). I'd say that this patch adds methods for exporting (or exposing) the ibft thru sysfs. Is there some good reason that the iSCSI connection information shouldn't be exposed in real sysfs attribute files instead of just in a binary file? > 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. > > 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 --- ~Randy Phaedrus says that Quality is about caring. - 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/
xpad_probe: undefined reference to `led_classdev_register'
Hi. Current linus' git tree: x86_64-unknown-linux-gnu-ld: BFD 2.15 assertion fail /home/thomas/source/crosstool-0.43/build/x86_64-unknown-linux-gnu/gcc-3.4.5-glibc-2.3.6/binutils-2.15/bfd/linker.c:619 drivers/built-in.o(.text+0x20749d): In function `xpad_probe': : undefined reference to `led_classdev_register' drivers/built-in.o(.text+0x20756c): In function `xpad_disconnect': : undefined reference to `led_classdev_unregister' make: *** [.tmp_vmlinux1] Fehler 1 any ideas? mfg thomas - 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: Fix boot-time hang on G31/G33 PC
Due to the issues surrounding this patch, I'm dropping it from my repo.
thanks,
greg k-h
On Sat, Aug 25, 2007 at 07:55:56PM -0600, Matthew Wilcox wrote:
>
>
> This patch, loosely based on a patch from Robert Hancock, which was in
> turn based on a patch from Jesse Barnes, fixes a boot-time hang on my
> shiny new PC. The 'conflict' mentioned in the patch in my case happens
> to be between mmconfig and the graphics card, but it could easily be
> between any pair of devices if they are left enabled by the BIOS and
> mappen in the wrong place.
>
> Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
> Acked-by: Robert Hancock <[EMAIL PROTECTED]>
> Acked-by: Jesse Barnes <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
> ---
> drivers/pci/probe.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -180,11 +180,26 @@ static inline int is_64bit_memory(u32 ma
> return 0;
> }
>
> +/*
> + * Sizing PCI BARs requires us to disable decoding, otherwise we may run
> + * into conflicts with other devices while trying to size the BAR. Normally
> + * this isn't a problem, but it happens on some machines normally, and can
> + * happen on others during PCI device hotplug. Don't disable BARs for host
> + * bridges, though. Some of them do silly things like disable accesses to
> + * RAM from the CPU
> + */
> static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int
> rom)
> {
> unsigned int pos, reg, next;
> u32 l, sz;
> struct resource *res;
> + u16 orig_cmd;
> +
> + if ((dev->class >> 8) != PCI_CLASS_BRIDGE_HOST) {
> + pci_read_config_word(dev, PCI_COMMAND, _cmd);
> + pci_write_config_word(dev, PCI_COMMAND,
> + orig_cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO));
> + }
>
> for(pos=0; pos u64 l64;
> @@ -283,6 +298,9 @@ static void pci_read_bases(struct pci_de
> }
> }
> }
> +
> + if ((dev->class >> 8) != PCI_CLASS_BRIDGE_HOST)
> + pci_write_config_word(dev, PCI_COMMAND, orig_cmd);
> }
>
> void pci_read_bridge_bases(struct pci_bus *child)
-
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: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
Jordan Crouse wrote:
>
> Hmm - the old code seems to fail to e801 when CF was set too:
>
> int $0x15 # make the call
> jc bail820 # fall to e801 if it fails
>
> cmpl$SMAP, %eax # check the return is `SMAP'
> jne bail820 # fall to e801 if it fails
>
> Thats not to say that the old code was correct, mind you. Failing on a
> bad ID and returning without error on a set CF seems to be good to me.
>
Testing this patch now:
>From 2efa33f81ef56e7700c09a3d8a881c96692149e5 Mon Sep 17 00:00:00 2001
From: H. Peter Anvin <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 14:11:43 -0700
Subject: [PATCH] [x86 setup] Handle case of improperly terminated E820 chain
At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain. We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.
Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.
Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Jordan Crouse <[EMAIL PROTECTED]>
Cc: Joerg Pommnitz <[EMAIL PROTECTED]>
---
arch/i386/boot/memory.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..bccaa1c 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@ -20,6 +20,7 @@
static int detect_memory_e820(void)
{
+ int count = 0;
u32 next = 0;
u32 size, id;
u8 err;
@@ -33,14 +34,24 @@ static int detect_memory_e820(void)
"=m" (*desc)
: "D" (desc), "a" (0xe820));
- if (err || id != SMAP)
+ /* Some BIOSes stop returning SMAP in the middle of
+ the search loop. We don't know exactly how the BIOS
+ screwed up the map at that point, we might have a
+ partial map, the full map, or complete garbage, so
+ just return failure. */
+ if (id != SMAP) {
+ count = 0;
break;
+ }
- boot_params.e820_entries++;
+ if (err)
+ break;
+
+ count++;
desc++;
- } while (next && boot_params.e820_entries < E820MAX);
+ } while (next && count < E820MAX);
- return boot_params.e820_entries;
+ return boot_params.e820_entries = count;
}
static int detect_memory_e801(void)
@@ -89,11 +100,16 @@ static int detect_memory_88(void)
int detect_memory(void)
{
+ int err = -1;
+
if (detect_memory_e820() > 0)
- return 0;
+ err = 0;
if (!detect_memory_e801())
- return 0;
+ err = 0;
+
+ if (!detect_memory_88())
+ err = 0;
- return detect_memory_88();
+ return err;
}
--
1.5.3.1
Re: v2.6.23-rc4-rt1 / new project URL
Steve, On Mon, 2007-09-10 at 14:35 +0200, Peter Zijlstra wrote: > On Fri, 2007-08-31 at 22:59 +0200, Thomas Gleixner wrote: > > We're pleased to announce the release of the v2.6.23-rc4-rt1 kernel, > > which can be downloaded from a new place: > > > >http://www.kernel.org/pub/linux/kernel/projects/rt/ > > > > The move to kernel.org is experimental for now, we'll keep it if it > > works out fine. > > > > Changes since 2.6.23-rc2-rt2: > > > > - update to -rc4 > > - update to 2.6.23-rc4-hrt1 > > > > - UP compile fixes back merged (Kevin Hilman / Steven Rostedt) > > - various latency tracer fixes (Steven Rostedt) > > - softirq migration fixes (Steven Rostedt) > > - ARM futex cmpxchg in atomic support (Khem Raj) > > - ARM raw lock fix (Kevin Hilman) > > - loadavgrt fix (Luis Claudio R. Goncalves) > > - mellanox driver fix (Michael S. Tsirkin) > > > > A bunch of patches are postponed for -rt2 (they are neither ignored > > nor forgotten): > > > > - simple_irq change (Kevin Hilman): needs more thought > > - RCU updates (Paul McKenney): needs proper integration > > - latency tracer changes (Daniel Walker): needs review > > - PICK_OP changes (Daniel Walker): needs review > > This one seems to have slipped through the cracks: > http://lkml.org/lkml/2007/8/16/135 Seems to be missed again :-/ - 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: sys_chroot+sys_fchdir Fix
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to attempt to chroot(2), as root can generally escape a
chroot(2).
For sure, "a root user can get out of a chroot a million different
ways." Young Alan said as much at the beginning of this conversation,
and I have always agreed. I don't hope to secure Linux within chroot,
simply to fix chroot so that it does what it says it does.
Look, when chroot was being designed, I think they intended that even
root should be unable to get out. They went so far as to say that
dot-dot wouldn't let you out; and it doesn't. It's not dot-dot that's
the problem. Even fchdir is no problem, because you choose which file
descriptors to leave open. Fchdir is actually one of the answers.
("What if we need a way to escape?")
The problem is leaving cwd unchanged. Once you've set cwd within the
new root, dot-dot is promised to keep you within that root; and so it
does. But by leaving cwd unchanged, if you do a subsequent chroot, that
promise is suddenly broken. I think this is a bug. I think that
behavior was not intended. Not all agree with me, but obviously a lot
do, otherwise OpenBSD and others wouldn't have addressed this exact
issue. Here's what they do:
"If the program is already running with an altered root directory,
the process's current directory is changed to the same new root
directory. This prevents the current directory from being further
up the directory tree than the altered root directory."
-- OpenBSD man 2 chroot
This was no more than an attempt to fix a long-standing bug.
As stated, opinion is divided as to whether this is a bug. I think it
is, and many people agree, for example some of the BSDs and probably
others; some people don't. Young Alan, for example, ummm, strongly (is
a good word) disagrees. I don't see that it calls for nastiness or
emotion, and although opinion on this august list is divided, apparently
the nays are in the majority. We should leave it at that.
-
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/
reviewed (Re: [patch 1/7] Extended crashkernel command line)
Wed, Sep 26, 2007 at 11:05:33PM +0200, Bernhard Walle:
> * Oleg Verych <[EMAIL PROTECTED]> [2007-09-26 20:18]:
> > >
> > > --- a/kernel/kexec.c
> > > +++ b/kernel/kexec.c
> > > @@ -1172,33 +1172,50 @@ static int __init parse_crashkernel_mem(
> > > do {
> > > unsigned long long start = 0, end = ULLONG_MAX;
> > > unsigned long long size = -1;
> >
> > no need in assigning values here, unless you plan to use them in case
> > of `return -EINVAL', but i can not see that,
>
> What about this (and yes, I tested with some wrong strings with Qemu):
Reviewed-by: Oleg Verych <[EMAIL PROTECTED]>
Thanks :D
>
>
> This patch improves error handling in parse_crashkernel_mem() by comparing
> the return pointer of memparse() with the input pointer and also replaces
> all printk(KERN_WARNING msg) with pr_warning(msg).
>
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
_
-
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] Add iSCSI iBFT support.
On Wed, Sep 26, 2007 at 02:46:52PM -0400, Konrad Rzeszutek wrote: > This patch adds a /sysfs/firmware/ibft/table binary blob which exports > the iSCSI Boot Firmware Table (iBFT) structure. Please don't do that. Binary files are for things that are "pass-through" only, not anything that the kernel knows the structure of, or cares about (like PCI config space, or firmware blobs for devices.) Just export the individual fields of this table as individual files please. thanks, greg k-h - 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 4/4] dmapool: Improve memory usage for devices which can't cross boundaries
From: Matthew Wilcox <[EMAIL PROTECTED]> Date: Wed, 26 Sep 2007 15:01:19 -0400 > The previous implementation simply refused to allocate more than a > boundary's worth of data from an entire page. Some users didn't know > this, so specified things like SMP_CACHE_BYTES, not realising the > horrible waste of memory that this was. It's fairly easy to correct > this problem, just by ensuring we don't cross a boundary within a page. > This even helps drivers like EHCI (which can't cross a 4k boundary) > on machines with larger page sizes. > > Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> This one looks good to me: Acked-by: David S. Miller <[EMAIL PROTECTED]> - 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: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
On 26/09/07 14:04 -0700, H. Peter Anvin wrote:
> Jordan Crouse wrote:
> > On 26/09/07 12:14 -0700, H. Peter Anvin wrote:
> >> Please try the following debug patch to let us know what is going on.
> >>
> >>-hpa
> >
> >> diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
> >> index 1a2e62d..a0ccf29 100644
> >> --- a/arch/i386/boot/memory.c
> >> +++ b/arch/i386/boot/memory.c
> >> @@ -33,6 +33,12 @@ static int detect_memory_e820(void)
> >> "=m" (*desc)
> >>: "D" (desc), "a" (0xe820));
> >>
> >> + printf("e820: err %d id 0x%08x next %u %08x:%08x %u\n",
> >> + err, id, next,
> >> + (unsigned int)desc->addr,
> >> + (unsigned int)desc->size,
> >> + desc->type);
> >> +
> >>if (err || id != SMAP)
> >>break;
> >
> > Okay, we have clarity. Here is the output
> >
> > e820: err 0 id 0x534d4150 next 15476 :0009fc00 1
> > e820: err 0 id 0x534d4150 next 15496 0009fc00:0400 2
> > e820: err 0 id 0x534d4150 next 15516 000e:0002 2
> > e820: err 0 id 0x0e7b next 11536 0010:0e6b 1
> >
> > In the last entry, id is obviously wrong (it should be 'SMAP' or
> > 0x534d4150). This is the BIOS bug.
> >
> > Here's the reason why this bothers us now. In the old assembly code,
> > if the returned ID wasn't equal to 'SMAP', we jumped straight to the e801
> > code. In the new code in memory.c, if id != SMAP, we break out of the
> > int15 loop, and return boot_params.e820_entries, which in our case is
> > 3. detect_memory() considers this to be successful, and no attempt to
> > parse e801 is made.
> >
> > So thats where the problem is - in the old code with the buggy BIOS, we
> > punted to reading the e801 information, and that was enough to keep us
> > going. In the new code, we allow a partial table to be used, and we
> > blow up.
> >
> > Attached is a patch to fix this - it returns -1 on error, and only sets
> > boot_params.e820_entries to be non-zero if we have something useful
> > in it. This punts the detection to the e801 code, which then is
> > then successful.
> >
> > This fixes the problem with the DB800, and so it probably should
> > with the other Geode platforms affected by this.
> >
> > Many thanks to hpa for the guiding hand.
> >
>
> This patch is obviously wrong. There are a lot of e820 BIOSen out there
> that terminate with CF=1, and that is a legitimate termination condition
> for e820. Now, as far as what to do when id != SMAP, it probably is
> still the right thing to do; since the BOS vendor couldn't get something
> that elementary correct, we shouldn't trust the data.
>
> I'll write up a corrected patch.
Hmm - the old code seems to fail to e801 when CF was set too:
int $0x15 # make the call
jc bail820 # fall to e801 if it fails
cmpl$SMAP, %eax # check the return is `SMAP'
jne bail820 # fall to e801 if it fails
Thats not to say that the old code was correct, mind you. Failing on a
bad ID and returning without error on a set CF seems to be good to me.
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
-
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 3/4] Change dmapool free block management
From: Matthew Wilcox <[EMAIL PROTECTED]> Date: Wed, 26 Sep 2007 15:01:18 -0400 > Also add documentation for how dma pools work, move the header above the > includes, add my copyright, add the original author's copyright, add a > GPL v2 licence to the file and fix the includes. > > Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> Correct or not, you need to describe how you are changing the free block management, why that transformation is valid and worthwhile, etc. I can see that you're getting rid of a bitmap and replacing it with the dma_page->in_use et al. stuff, but you need to describe that in detail. - 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: Man page for revised timerfd API
Hi Davide, > On Wed, 26 Sep 2007, Michael Kerrisk wrote: > > > .TH TIMERFD_CREATE 2 2007-09-26 Linux "Linux Programmer's Manual" > > .SH NAME > > timerfd_create, timerfd_settime, timer_gettime \- > > timers that notify via file descriptors > > .SH SYNOPSIS > > .\" FIXME . This header file may well change > > .\" FIXME . Probably _GNU_SOURCE will be required > > .\" FIXME . May require: Link with \fI\-lrt\f > > .nf > > .B #include > > .sp > > .BI "int timerfd_create(int " clockid ); > > .sp > > .BI "int timerfd_settime(int " fd ", int " flags , > > .BI "const struct itimerspec *" new_value , > > .BI "struct itimerspec *" curr_value ); > > .sp > > .BI "int timerfd_gettime(int " fd ", struct itimerspec *" curr_value ); > > .fi > > .SH DESCRIPTION > > These system calls create and operate on a timer > > that delivers timer expiration notifications via a file descriptor. > > They provide an alternative to the use of > > .BR setitimer (2) > > or > > .BR timer_create (3), > > with the advantage that the file descriptor may be monitored by > > .BR poll (2) > > and > > .BR select (2). > > epoll, no? Yes, I suppose I should add it too -- I was trying to keep the text short was all. [...] And thanks for checking the other parts. > BTW: We need to re-look over the signalfd man page, since Linus, in an > unexpected move, merged the simplification patch :) Yep, I'll have the page to you in a few days. Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'. - 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] dmapool: Validate parameters to dma_pool_create
From: Matthew Wilcox <[EMAIL PROTECTED]> Date: Wed, 26 Sep 2007 15:01:17 -0400 > Check that 'align' is a power of two, like the API specifies. > Align 'size' to 'align' correctly -- the current code has an off-by-one. > The ALIGN macro in kernel.h doesn't. > > Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> - 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/
