Re: [PATCH] documentation fixes
On Dienstag, 31. Juli 2007, Cal Peake wrote: > > Whom should I CC for other documentation updates? Is the maintainer > > the correct person, or are such small fixes "send and forget"? > > For spelling and grammar fixes, sending to [EMAIL PROTECTED] is prolly > the best bet with a CC to l-k. > > Also, please see Documentation/SubmittingPatches, particularly section 12 > about signing off your work. Ok, thank you! Regards, Phil - 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/5] x86_64 EFI support -v3: EFI framebuffer driver
On Tue, 2007-07-31 at 11:13 +0800, Huang, Ying wrote: > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + I don't see any problems with this driver, just a few minor nits. Do you really need all the #include's? I presume this driver only supports bpp 16 and above? Tony - 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: eurotechwdt will cause reboot
Hi Dave, > config eurotechwdt to yes will cause system silent reboot. Is it right > behaviour or a bug? I think this might be a bug. I'll look at the code and will ask you to do some tests for me (if that is ok for you). Greetings, Wim. - 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]: sound: ioremap/iounmap function balancing audit
On Wed, 01 Aug 2007 00:52:26 -0400 Andrew Morton <[EMAIL PROTECTED] foundation.org> wrote: >The patch is terribly wordwrapped. > >I suspect a lot of the code which you're fixing is about to be >removed. >But I suppose we should fix it before removing it anwyay. Still, >please >split this patch into at least one for sound/oss and one for >sound/soc and >sound/pci, thanks. Will do, though wordwrapping issues will still be there. The part of the function I was patching in i810_probe is nested so deep birds have taken up residence. --- Scott Thompson / [EMAIL PROTECTED] --- -- Rock bottom prices! Click to save on brand name copiers today http://tagline.hushmail.com/fc/Ioyw6h4efL27NZWTgRQ5KLEGpGlRXMwVmKYR73wM4wS274Lb73uEK4/ - 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: [ck] Re: Linus 2.6.23-rc1
Roman Zippel wrote: When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. When Ingo wrote something that went head-on with what Con wrote, it was his prerogative to do so. There's no speaking here of rights to do or not to do since as matter of evidence, in the open source world, that which is superior (i.e. code, function, not person) has the right to exist and the inferior to die away. Did Ingo have the obligation to improve Con's work? Definitely not. Did Con have a right to get Ingo's improvements or suggestions? Definitely not. There are no such rights in this open source development framework (TM). What Ingo did, I think, was what he wanted and he has the right to do that. I believe that Ingo does not have an obligation to be responsible for what Con felt. You feel what you feel because you choose to feel that way. Let us remember that "Happiness is a choice, not a state." And let's just look at the attitudes on how both Ingo and Con reacted to the issues regarding their respective schedulers. I won't list them here now since they're all there in the archives. Since attitude also plays a big part in getting your code in mainline, I think we would know the reason why one got chosen for the other. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, UP Campus Diliman 1101 Quezon City, Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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 -mm] Introduce strtol_check_range()
On Tue, Jul 31, 2007 at 10:04:10PM +0530, Satyam Sharma wrote:
> Callers (especially "store" functions for sysfs or configfs attributes)
> that want to convert an input string to a number may often also want to
> check for simple input sanity or allowable range. strtol10_check_range()
> of netconsole does this, so extract it out into lib/vsprintf.c, make it
> generic w.r.t. base, and export it to the rest of the kernel and modules.
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -335,9 +307,11 @@ static ssize_t store_enabled(struct netconsole_target
> *nt,
> int err;
> long enabled;
>
> - enabled = strtol10_check_range(buf, 0, 1);
> - if (enabled < 0)
> + enabled = strtol_check_range(buf, 0, 1, 10);
> + if (enabled < 0) {
> + printk(KERN_ERR "netconsole: invalid input\n");
> return enabled;
> + }
Please, copy strtonum() from BSD instead. Nobody needs another
home-grown converter.
-
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: [ck] Re: SD still better than CFS for 3d ?
On Tue, Jul 31, 2007 at 01:07:30PM +1000, Matthew Hawkins wrote: >... > I took the time to track down what caused a breakage - in an "illegal > binary driver" (not against the law here, though defamation certainly > is...) no less. And contacted the vendor (separately). Other people > on desktop machines with an ATI card using the fglrx driver may have > been interested to know that they can't do the benchmarking some > people here on lkml and -mm are asking for with a current 2.6.23 git > kernel, hence my post. >... But there's not much value in benchmarking if an important part of the performance critical code is in some undebuggable driver... > Matt 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 52] include/asm-m32r/thread_info.h: kmalloc + memset conversion to kzalloc
From: Mariusz Kozlowski <[EMAIL PROTECTED]> Date: Tue, 31 Jul 2007 21:18:33 +0200 > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> > > include/asm-m32r/thread_info.h |5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > Acked-by: Hirokazu Takata <[EMAIL PROTECTED]> Thank you. - 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/
SAA7160/2
Hi All, After a bit of talks with NXP, they stated that if shown enough of a user base (future business forecast) for the SAA7160 / SAA7162 PCIe chipset, they would take into consideration, an investment into support, such that the chips can be better supported. ie, i need to provide them information that there is some significant numbers in the user base. Additionally, vendors such as Azurewave are ready to help us as well, in whatever way they can. Any ideas, how we can show user support in terms of a future business case ? Comments appreciated. Thanks, Manu - 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 FINAL] Merge the Sonics Silicon Backplane subsystem
On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote:
> The Sonics Silicon Backplane is a mini-bus used on
> various Broadcom chips and embedded devices.
A few probs with mips allmodconfig:
drivers/ssb/driver_mipscore.c:121: warning: "struct ssb_serial_ports" declared
inside parameter list
drivers/ssb/driver_mipscore.c:121: warning: its scope is only this definition
or declaration, which is probably not what you want
drivers/ssb/driver_mipscore.c: In function `ssb_mips_serial_init':
drivers/ssb/driver_mipscore.c:166: warning: passing arg 1 of
`ssb_extif_serial_init' from incompatible pointer type
drivers/ssb/driver_mipscore.c:166: warning: passing arg 2 of
`ssb_extif_serial_init' from incompatible pointer type
drivers/ssb/driver_mipscore.c: At top level:
drivers/ssb/driver_mipscore.c:188: warning: 'ssb_cpu_clock' defined but not used
drivers/ssb/driver_pcicore.c: In function `ssb_fixup_pcibridge':
drivers/ssb/driver_pcicore.c:98: error: implicit declaration of function
`pcibios_enable_device'
drivers/ssb/driver_pcicore.c: At top level:
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
the latter is due to .end in
static struct resource ssb_pcicore_mem_resource = {
.name = "SSB PCIcore external memory",
.start = SSB_PCI_DMA,
.end= SSB_PCI_DMA + SSB_PCI_DMA_SZ - 1,
.flags = IORESOURCE_MEM,
};
It could be more Kconfig select borkage, of course..
-
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]: sound: ioremap/iounmap function balancing audit
On Wed, 01 Aug 2007 00:05:59 -0400 "Scott Thompson" <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
You might want to consider losing that stuff when sending patches - it just
makes things harder.
> This patch, along with previously submitted dmasound_awacs.c patch,
> completes an audit of the 'sound' tree for ioremap/iounmap
> balancing and return code checking on ioremap calls. ioremap()
> must be balanced by an iounmap() (else this causes a memory leak).
>
> i810_audio.c had a 'fixme' issue regarding ioremap fail that was
> addressed as well.
>
> Signed-off-by: Scott Thompson hushmail.com>
> - ---
>
> diff --git a/sound/oss/i810_audio.c b/sound/oss/i810_audio.c
> index f5e31f1..407958c 100644
> - --- a/sound/oss/i810_audio.c
> +++ b/sound/oss/i810_audio.c
> @@ -3362,7 +3362,7 @@ static int __devinit i810_probe(struct
> pci_dev *pci_dev, const struct pci_device
>
> if (card->use_mmio) {
> if (request_mem_region(card->ac97base_mmio_phys, 512, "ich_audio
> MMBAR")) {
> - - if ((card->ac97base_mmio =
> ioremap(card->ac97base_mmio_phys,
> 512))) { /[EMAIL PROTECTED] can ioremap fail? don't know (jsaw) */
> + if ((card->ac97base_mmio =
> ioremap(card->ac97base_mmio_phys,
> 512))) {
> if (request_mem_region(card->iobase_mmio_phys,
> 256, "ich_audio
> MBBAR")) {
> if ((card->iobase_mmio =
> ioremap(card->iobase_mmio_phys,
> 256))) {
> printk(KERN_INFO "i810: %s mmio
> at 0x%04lx and 0x%04lx\n",
The patch is terribly wordwrapped.
I suspect a lot of the code which you're fixing is about to be removed.
But I suppose we should fix it before removing it anwyay. Still, please
split this patch into at least one for sound/oss and one for sound/soc and
sound/pci, thanks.
-
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: VT_PROCESS, VT_LOCKSWITCH capabilities
On Wed, 01 Aug 2007 00:22:38 +0200 Frank Benkstein <[EMAIL PROTECTED]> wrote: > I wonder why there are different permissions needed for VT_PROCESS > (access to the current virtual console) and VT_LOCKSWITCH > (CAP_SYS_TTY_CONFIG). > > The first one lets the calling process decide if console switching is > allowed, the second one simply disables it. If a program wants to > forbid console switching the only technical difference I can see is that > switching is automatically reenabled when the program exits when using > VT_PROCESS. When using VT_LOCKSWITCH it must be manually reenabled. > When the program uses the first method and disables terminal signals and > SysRQ is disabled, too, I see no practical difference between the two. It'd take some kernel archaeology to work out how things got the way they are. Perhaps the issue with VT_LOCKSWITCH is that its effects will persist after the user has logged out? So user A is effectively altering user B's console, hence suitable capabilities are needed? Is the current code actually causing any observable problem? - 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] [POWERPC] Typo fixes interrrupt -> interrupt
On Wed, 01 Aug 2007 05:16:27 +0200 Gabriel C <[EMAIL PROTECTED]> wrote: > > arch/powerpc/platforms/iseries/it_lp_naca.h | 87 > +++-- NAK this part as it just makes a lot of the lines more than 80 characters for no real gain on a platform that is moving on ... -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpaJGOos3L2C.pgp Description: PGP signature
Re: 2.6.23-rc1: no setup signature found...
On Mon, Jul 30, 2007 at 01:46:33PM -0700, H. Peter Anvin wrote: > Borislav Petkov wrote: >> Hi, >> i decided to do some cheating :) and skipped the breakpoint where it used >> to >> stop (0x40200). (by the way, hitting 'c' wouldn't continue at all and keep >> executing the same instruction over and over again). This time it seems it >> behaves as expected: > > Uhm, it looks to me that you ran qemu with the -kernel option again (I can > tell because the dump exhibits a few bugs that are characteristic of the > qemu loader.) This makes qemu itself load the kernel and not rely on the > boot loader that's on your bootloader. > > I was expecting you to run "qemu -S -s -hda /dev/hda -snapshot", which you > previously said when run (without the -S -s) options reproduced the > problem. ups, sorry for that, i thought falsely here that you want to debug the kernel part of the setup code ... > > After taking the dump, please do: > > delete > c > > ... to verify the problem is reproduced. In this case, we never land on a jump instruction: GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu". (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0xfff0 in ?? () (gdb) set arch i8086 The target architecture is assumed to be i8086 (gdb) disp/i ($cs << 4)+$eip 1: x/i ($cs << 4) + $eip 0x0: ljmp $0xf000,$0xe05b (gdb) br *0x10200 Breakpoint 1 at 0x10200 (gdb) br *0x20200 Breakpoint 2 at 0x20200 (gdb) br *0x30200 Breakpoint 3 at 0x30200 (gdb) br *0x40200 Breakpoint 4 at 0x40200 (gdb) br *0x50200 Breakpoint 5 at 0x50200 (gdb) br *0x60200 Breakpoint 6 at 0x60200 (gdb) br *0x70200 Breakpoint 7 at 0x70200 (gdb) br *0x80200 Breakpoint 8 at 0x80200 (gdb) br *0x90200 Breakpoint 9 at 0x90200 (gdb) c Continuing. Breakpoint 4, 0x00040200 in ?? () 1: x/i ($cs << 4) + $eip 0x40300: lea(%si),%dx (gdb) c Continuing. if i do delete here, it loads the second stage of grub and continues to load the kernel. Is there another way to land at the jmp instruction instead of poking blindly, maybe disassemble something parts of the initial code. \me reading grub-docs... -- Regards/Gruß, Boris. - 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/2][RFC] v8 Simplified Mandatory Access Control Kernel
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/smack_lsm.c
linux-2.6.22/security/smack/smack_lsm.c
--- linux-2.6.22-base/security/smack/smack_lsm.c1969-12-31
16:00:00.0
-0800
+++ linux-2.6.22/security/smack/smack_lsm.c 2007-07-24 15:02:16.0
-0700
@@ -0,0 +1,1989 @@
+/*
+ * Simplified MAC Kernel (smack) security module
+ *
+ * This file contains the smack hook function implementations.
+ *
+ * Author:
+ * Casey Schaufler <[EMAIL PROTECTED]>
+ *
+ * Copyright (C) 2007 Casey Schaufler <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2,
+ * as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smack.h"
+
+/*
+ * I hope these are the hokeyist lines of code in the module. Casey.
+ */
+#define DEVPTS_SUPER_MAGIC 0x1cd1
+#define SOCKFS_MAGIC 0x534F434B
+#define PIPEFS_MAGIC 0x50495045
+#define TMPFS_MAGIC0x01021994
+
+/*
+ * These are maintained in smackfs
+ */
+extern smack_t smack_net_ambient;
+extern int smack_net_nltype;
+extern int smack_cipso_direct;
+extern struct smk_cipso_entry *smack_cipso;
+
+
+/*
+ * Fetch the smack label from a file.
+ */
+static int smk_fetch(struct inode *ip, struct dentry *dp, smack_t *isp)
+{
+ int rc;
+ smack_t smack;
+
+ if (ip->i_op->getxattr == NULL)
+ return -EOPNOTSUPP;
+
+ rc = ip->i_op->getxattr(dp, XATTR_NAME_SMACK, , sizeof(smack_t));
+ if (rc > 0)
+ *isp = smk_from_buffer(, rc);
+
+ return rc;
+}
+
+static smack_t *free_smack_t(smack_t *sp)
+{
+ kfree(sp);
+return NULL;
+}
+
+struct inode_smack *new_inode_smack(smack_t smack)
+{
+ struct inode_smack *isp;
+
+isp = kzalloc(sizeof(struct inode_smack), GFP_KERNEL);
+if (isp == NULL)
+return NULL;
+
+ isp->smk_inode = smack;
+ isp->smk_flags = 0;
+ mutex_init(>smk_lock);
+
+ return isp;
+}
+
+/*
+ * LSM hooks.
+ * We he, that is fun!
+ */
+static int smack_ptrace(struct task_struct *ptp, struct task_struct *ctp)
+{
+ smack_t *psp = smk_of_task(ptp);
+ smack_t *csp = smk_of_task(ctp);
+ int rc;
+
+ rc = cap_ptrace(ptp, ctp);
+ if (rc != 0)
+ return rc;
+
+ rc = smk_access(psp, csp, MAY_READWRITE);
+ if (rc != 0 && __capable(ptp, CAP_MAC_OVERRIDE))
+ return 0;
+
+ return rc;
+}
+
+static int smack_syslog(int type)
+{
+ int rc;
+ smack_t *sp = smk_of_task(current);
+
+ rc = cap_syslog(type);
+ if (rc == 0)
+if (*sp != SMK_FLOOR)
+ rc = -EACCES;
+
+ return rc;
+}
+
+static int smack_task_alloc_security(struct task_struct *tsk)
+{
+ struct task_smack *tsp;
+ struct task_smack *ctsp = current->security;
+
+ tsp = kzalloc(sizeof(struct task_smack), GFP_KERNEL);
+ if (tsp == NULL)
+ return -ENOMEM;
+
+ *tsp = *ctsp;
+ tsk->security = tsp;
+
+ return 0;
+}
+
+static void smack_task_free_security(struct task_struct *task)
+{
+ kfree(task->security);
+ task->security = NULL;
+}
+
+static int smack_task_setpgid(struct task_struct *p, pid_t pgid)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
+
+static int smack_task_setnice(struct task_struct *p, int nice)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
+
+static int smack_task_setioprio(struct task_struct *p, int ioprio)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
+
+static int smack_task_getioprio(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_READ);
+ return rc;
+}
+
+static int smack_task_setscheduler(struct task_struct *p, int policy,
+ struct sched_param *lp)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
+
+static int smack_task_getscheduler(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_READ);
+ return rc;
+}
+
+static int smack_task_movememory(struct task_struct *p)
+{
+ int rc;
+
+ rc = smk_curacc(smk_of_task(p), MAY_WRITE);
+ return rc;
+}
+
+static int smack_task_kill(struct task_struct *p, struct siginfo *info,
+ int sig, u32 secid)
+{
+ smack_t *tsp = smk_of_task(p);
+ int rc;
+
+ /*
+* Sending a signal requires that the sender
+* can write the receiver.
+*/
+ rc = smk_curacc(tsp, MAY_WRITE);
+
+ return rc;
+}
+
+/*
+ * Superblock Hooks.
[PATCH 1/2][RFC] v8 Simplified Mandatory Access Control Kernel
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/Kconfig linux-2.6.22/security/Kconfig
--- linux-2.6.22-base/security/Kconfig 2007-07-08 16:32:17.0 -0700
+++ linux-2.6.22/security/Kconfig 2007-07-10 01:08:05.0 -0700
@@ -94,6 +94,7 @@ config SECURITY_ROOTPLUG
If you are unsure how to answer this question, answer N.
source security/selinux/Kconfig
+source security/smack/Kconfig
endmenu
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/Makefile linux-2.6.22/security/Makefile
--- linux-2.6.22-base/security/Makefile 2007-07-08 16:32:17.0 -0700
+++ linux-2.6.22/security/Makefile 2007-07-10 01:08:05.0 -0700
@@ -4,6 +4,7 @@
obj-$(CONFIG_KEYS) += keys/
subdir-$(CONFIG_SECURITY_SELINUX) += selinux
+subdir-$(CONFIG_SECURITY_SMACK)+= smack
# if we don't select a security model, use the default capabilities
ifneq ($(CONFIG_SECURITY),y)
@@ -14,5 +15,6 @@ endif
obj-$(CONFIG_SECURITY) += security.o dummy.o inode.o
# Must precede capability.o in order to stack properly.
obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o
+obj-$(CONFIG_SECURITY_SMACK) += commoncap.o smack/built-in.o
obj-$(CONFIG_SECURITY_CAPABILITIES)+= commoncap.o capability.o
obj-$(CONFIG_SECURITY_ROOTPLUG)+= commoncap.o root_plug.o
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/Kconfig linux-2.6.22/security/smack/Kconfig
--- linux-2.6.22-base/security/smack/Kconfig1969-12-31 16:00:00.0
-0800
+++ linux-2.6.22/security/smack/Kconfig 2007-07-10 01:08:05.0 -0700
@@ -0,0 +1,10 @@
+config SECURITY_SMACK
+ bool "Simplified Mandatory Access Control Kernel Support"
+ depends on NETLABEL && SECURITY_NETWORK
+ default n
+ help
+ This selects the Simplified Mandatory Access Control Kernel.
+ SMACK is useful for sensitivity, integrity, and a variety
+ of other madatory security schemes.
+ If you are unsure how to answer this question, answer N.
+
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/Makefile linux-2.6.22/security/smack/Makefile
--- linux-2.6.22-base/security/smack/Makefile 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.22/security/smack/Makefile2007-07-10 01:08:05.0
-0700
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
+
diff -uprN -X linux-2.6.22-base/Documentation/dontdiff
linux-2.6.22-base/security/smack/smack_access.c
linux-2.6.22/security/smack/smack_access.c
--- linux-2.6.22-base/security/smack/smack_access.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.22/security/smack/smack_access.c 2007-07-24 15:36:18.0
-0700
@@ -0,0 +1,113 @@
+/*
+ * Copyright (C) 2007 Casey Schaufler <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2.
+ *
+ * Author:
+ * Casey Schaufler <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include "smack.h"
+
+extern struct smk_list_entry *smack_list;
+
+static int smk_get_access(smack_t sub, smack_t obj)
+{
+ struct smk_list_entry *sp = smack_list;
+
+ for (; sp != NULL; sp = sp->smk_next)
+ if (sp->smk_rule.smk_subject == sub &&
+ sp->smk_rule.smk_object == obj)
+ return sp->smk_rule.smk_access;
+ /*
+* No access is explicitly defined for this pair.
+*/
+ return MAY_NOT;
+}
+
+int smk_access(smack_t *sub_label, smack_t *obj_label, int request)
+{
+ smack_t sub = *sub_label;
+ smack_t obj = *obj_label;
+ /*
+* Hardcoded comparisons.
+*
+* A star subject can't access any object.
+*/
+ if (sub == SMK_STAR)
+ return -EACCES;
+ /*
+* A star object can be accessed by any subject.
+*/
+ if (obj == SMK_STAR)
+ return 0;
+ /*
+* An object can be accessed in any way by a subject
+* with the same label.
+*/
+ if (sub == obj)
+ return 0;
+ /*
+* A hat subject can read any object.
+* A floor object can be read by any subject.
+*/
+ if (sub == SMK_HAT && ((request & MAY_ANYREAD) == request))
+ return 0;
+
+ if (obj == SMK_FLOOR && ((request & MAY_ANYREAD) == request))
+ return 0;
+ /*
+* Beyond here an explicit relationship is required.
+* If the requested access is contained in the available
+* access (e.g. read is included in readwrite) it's
+* good.
+*
+
[PATCH 0/2][RFC] v8 Simplified Mandatory Access Control Kernel
Smack is the Simplified Mandatory Access Control Kernel. Smack implements mandatory access control (MAC) using labels attached to tasks and data containers, including files, SVIPC, and other tasks. Smack is a kernel based scheme that requires an absolute minimum of application support and a very small amount of configuration data. Subscribers to the LSM list have seen most of this description before. Smack is implemented as a clean LSM. It requires no external code changes and the patch modifies only the Kconfig and Makefile in the security directory. Smack uses extended attributes and provides a set of general mount options, borrowing technics used elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides a pseudo-filesystem smackfs that is used for manipulation of task and system Smack attributes. The patch is split into two parts because of its size. The first (1/2) includes smackfs, the rule checking functions, a header file, Makefile and Kconfig. It also includes the changes to the security Makefile and Kconfig. The second (2/2) contains the lsm hooks. Both are required. The patch, patches for ls and sshd, a README, a startup script, and x86 binaries for ls and sshd is also available on http:/www.schaufler-ca.com The patch applies to 2.6.22. It has received minimal testing with 2.6.23-rc1 as well. Development has been done using Fedora Core 5 in a virtual machine environment. Smack provides mandatory access controls based on the label attached to a task and the label attached to the object it is attempting to access. Smack labels are deliberately short (1-7 characters) text strings. Single character labels using special characters are reserved for system use. The only operation applied to Smack labels is equality comparison. No wildcards or expressions, regular or otherwise, are used. A file always gets the Smack label of the task that created it. Smack defines and uses these labels: "*" - pronounced "star" "_" - pronounced "floor" "^" - pronounced "hat" "?" - pronounced "huh" The access rules enforced by Smack are, in order: 1. Any access requested by a task labeled "*" is denied. 2. A read or execute access requested by a task labeled "^" is permitted. 3. A read or execute access requested on an object labeled "_" is permitted. 4. Any access requested on an object labeled "*" is permitted. 5. Any access requested by a task on an object with the same label is permitted. 6. Any access requested that is explicitly defined in the loaded rule set is permitted. 7. Any other access is denied. Rules may be explicitly defined by writing subject,object,access triples to /smack/load. Smack rule sets can be easily defined that describe Bell sensitivity, Biba integrity, and a variety of interesting configurations. Smack rule sets can be modified on the fly to accomodate changes in the operating environment or even the time of day. Some practical use cases: Hierarchical levels. The less common of the two usual uses for MLS systems is to define hierarchical levels, often unclassified, confidential, secret, and so on. To set up smack to support this, these rules could be defined: CUnclass rx SC rx SUnclass rx TS S rx TS C rx TS Unclass rx A TS process can read S, C, and Unclass data, but cannot write it. An S process can read C and Unclass. Note that specifying that TS can read S and S can read C does not imply TS can read C, it has to be explicitly stated. Non-hierarchical categories. This is the more common of the usual uses for an MLS system. Since the default rule is that a subject cannot access an object with a different label no access rules are required to implement compartmentalization. A case that the Bell & LaPadula policy does not allow is demonstrated with this Smack access rule: A case that Bell does not allow that Smack does: ESPNABC r ABC ESPN r On my portable video device I have two applications, one that shows ABC programming and the other ESPN programming. ESPN wants to show me sport stories that show up as news, and ABC will only provide minimal information about a sports story if ESPN is covering it. Each side can look at the other's info, neither can change the other. Neither can see what FOX is up to, which is just as well all things considered. Another case that I especially like: SatData Guard w Guard Publish w A program running with the Guard label opens a UDP socket and accepts messages sent by a program running with a SatData label. The Guard program inspects the message to ensure it is wholesome and if it is sends it to a program running with the Publish label. This program then puts the information passed in an appropriate place. Note that the Guard program cannot write to a Publish file system object because file system semanitic require read as well as write. The four cases (categories, levels, mutual read,
[PATCH] libata Kconfig: Allow libata to be selected from within the SCSI submenu
Move libata Kconfig sourcing from the drivers Kconfig into the SCSI Kconfig. This allows the user to quickly select additional disk/tape/cdrom support from within the same menu. Signed-off-by: Al Boldi <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> --- --- a/drivers/Kconfig 2007-05-02 17:25:30.0 +0300 +++ b/drivers/Kconfig 2007-08-01 06:33:13.0 +0300 @@ -22,8 +22,6 @@ source "drivers/ide/Kconfig" source "drivers/scsi/Kconfig" -source "drivers/ata/Kconfig" - source "drivers/cdrom/Kconfig" source "drivers/md/Kconfig" --- a/drivers/scsi/Kconfig 2007-07-09 06:38:37.0 +0300 +++ b/drivers/scsi/Kconfig 2007-08-01 06:46:42.0 +0300 @@ -7,6 +7,8 @@ config RAID_ATTRS ---help--- Provides RAID +source "drivers/ata/Kconfig" + config SCSI tristate "SCSI device support" depends on BLOCK - 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: WARN_ON() which sometimes sucks
Linus Torvalds writes: > Umm. The WARN_ON() might actually get a "long long" value for all we know. > Ie it's perfectly possible that the WARN_ON might look like > > /* Must not have high bits on */ > WARN_ON(offset & 0x); > > which on a 32-bit pcc would apparently do the wrong thing entirely as it > stands now. No? Actually, because of the typeof in the powerpc WARN_ON, I think it would fail to build since we'd be passing a long long value to an inline asm, or at least I hope it would fail to build. :) But your criticism is correct with regard to the powerpc BUG_ON, and you're correct that a long wouldn't be sufficient if someone passes in a long long. Oh well. I guess we just wear the extra two instructions. Paul. - 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: [ck] Re: Linus 2.6.23-rc1
Hi, On Sat, 28 Jul 2007, Linus Torvalds wrote: > We've had people go with a splash before. Quite frankly, the current > scheduler situation looks very much like the CML2 situation. Anybody > remember that? The developer there also got rejected, the improvement was > made differently (and much more in line with existing practices and > maintainership), and life went on. Eric Raymond, however, left with a > splash. Since I was directly involved I'd like to point out a key difference. http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and initially I didn't plan on writing a new config system. At the beginning there was only the converter, which I did to address the issue that Eric created a complete new and different config database, so the converter was meant to create a more acceptable transition path. What happened next is that I haven't got a single response from Eric, so I continued hacking on it until was complete. The key difference is now that Eric refused the offered help, while Con was refused the help he needed to get his work integrated. When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had already pretty much lost. I have no doubt that Ingo can quickly transform an idea into working code and I would've been very surprised if he wouldn't be able to turn it into something technically superior. When Ingo figured out how to implement fair scheduling in a better way, he didn't use this idea to help Con to improve his work. He decided instead to work against Con and started his own rewrite, this is of course his right to do, but then he should also accept the responsibility that Con felt his years of work ripped apart and in vain and we have now lost a developer who tried to address things from a different perspective. bye, Roman - 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: [Fwd: [PlanetCCRMA] atl1 driver; sleeping function]
On Tue, 2007-07-31 at 10:51 +0200, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo, I'm forwading this report from a Planet CCRMA user, this is
> > happening to him with 2.6.21.6-rt21...
>
> thanks!
Thanks for the patch!
Looks like it fixed the problem Matt was having...
-- Fernando
Forwarded Message
From: Matt Barbe
To: Fernando Lopez-Lezcano
Cc: [EMAIL PROTECTED]
Subject: Re: [PlanetCCRMA] atl1 driver; sleeping function
Date: Tue, 31 Jul 2007 22:50:28 -0400
The newly patched atl1 driver seems to be working fine. I tried it
also in rt21.3 (that's the latest src.rpm in
http://ccrma.stanford.edu/planetccrma/mirror/all/linux/SRPMS/), and it
also worked fine -- I need kernel-rt-devel because I do use apps that
need nvidia drivers, and those are working fine in rt21.3 as well. I
can keep you up to date if anything negative happens.
Thanks again,
Matt
>
> > BUG: sleeping function called from invalid context IRQ-219(2243) at
> > kernel/rtmutex.c:613
> > in_atomic():0 [], irqs_disabled():1
> > [] dump_trace+0x64/0x105
> > [] show_trace_log_lvl+0x18/0x2c
> > [] show_trace+0xf/0x11
> > [] dump_stack+0x12/0x14
> > [] __rt_spin_lock+0x21/0x3d
> > [] atl1_xmit_frame+0x66f/0x6c6 [atl1]
> > [] dev_hard_start_xmit+0x1c6/0x225
> > [] __qdisc_run+0xb7/0x1cf
>
> could you try the patch below, does it fix the problem? The atl1 driver
> uses raw irq flags in combination with a spinlock that is a sleeping
> lock on -rt. (this is valid code on upstream, fortunately the -rt fix is
> also a cleanup and a small code reduction enhancement on upstream, so
> there's no problem pushing such fixes upstream.)
>
> Ingo
>
> --->
> Subject: [patch] drivers/net/atl1/atl1_main.c: use spin_trylock_irqsave()
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> use the simpler spin_trylock_irqsave() API to get the adapter lock.
>
> [ this is also a fix for -rt where adapter->lock is a sleeping lock. ]
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> drivers/net/atl1/atl1_main.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> Index: linux-rt-rebase.q/drivers/net/atl1/atl1_main.c
> ===
> --- linux-rt-rebase.q.orig/drivers/net/atl1/atl1_main.c
> +++ linux-rt-rebase.q/drivers/net/atl1/atl1_main.c
> @@ -1704,10 +1704,8 @@ static int atl1_xmit_frame(struct sk_buf
> }
> }
>
> - local_irq_save(flags);
> - if (!spin_trylock(>lock)) {
> + if (!spin_trylock_irqsave(>lock, flags)) {
> /* Can't get lock - tell upper layer to requeue */
> - local_irq_restore(flags);
> dev_printk(KERN_DEBUG, >pdev->dev, "tx locked\n");
> return NETDEV_TX_LOCKED;
> }
-
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] - Remove current defines and uses of pr_err, add pr_emerg, pr_alert, pr_crit, pr_err, pr_warn, pr_notice to include/linux/kernel.h
Remove current #define and uses of pr_err
Add pr_emerg, pr_alert, pr_crit, pr_err, pr_warn, pr_notice
to include/linux/kernel.h
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index 48a7e2f..3ee323a 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,7 @@
#include
#define DRIVER_NAME"menelaus"
-
-#define pr_err(fmt, arg...)printk(KERN_ERR DRIVER_NAME ": ", ## arg);
+#define PFX DRIVER_NAME ": "
#define MENELAUS_I2C_ADDRESS 0x72
@@ -156,7 +155,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val = i2c_smbus_write_byte_data(the_menelaus->client, reg, value);
if (val < 0) {
- pr_err("write error");
+ printk(KERN_ERR PFX "write error\n");
return val;
}
@@ -168,7 +167,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus->client, reg);
if (val < 0)
- pr_err("read error");
+ printk(KERN_ERR PFX "read error\n");
return val;
}
@@ -1178,7 +1177,7 @@ static int menelaus_probe(struct i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev < 0) {
- pr_err("device not found");
+ printk(KERN_ERR PFX "device not found\n");
err = -ENODEV;
goto fail1;
}
@@ -1259,7 +1258,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(_i2c_driver);
if (res < 0) {
- pr_err("driver registration failed\n");
+ printk(KERN_ERR PFX "driver registration failed\n");
return res;
}
diff --git a/drivers/net/spider_net.c b/drivers/net/spider_net.c
index 590b12c..db589d8 100644
--- a/drivers/net/spider_net.c
+++ b/drivers/net/spider_net.c
@@ -1238,14 +1238,15 @@ spider_net_decode_one_descr(struct spider_net_card
*card)
if (hwdescr->dmac_cmd_status & SPIDER_NET_DESCR_BAD_STATUS) {
dev_err(>netdev->dev, "bad status, cmd_status=x%08x\n",
hwdescr->dmac_cmd_status);
- pr_err("buf_addr=x%08x\n", hw_buf_addr);
- pr_err("buf_size=x%08x\n", hwdescr->buf_size);
- pr_err("next_descr_addr=x%08x\n", hwdescr->next_descr_addr);
- pr_err("result_size=x%08x\n", hwdescr->result_size);
- pr_err("valid_size=x%08x\n", hwdescr->valid_size);
- pr_err("data_status=x%08x\n", hwdescr->data_status);
- pr_err("data_error=x%08x\n", hwdescr->data_error);
- pr_err("which=%ld\n", descr - card->rx_chain.ring);
+ printk(KERN_ERR "buf_addr=x%08x\n", hw_buf_addr);
+ printk(KERN_ERR "buf_size=x%08x\n", hwdescr->buf_size);
+ printk(KERN_ERR "next_descr_addr=x%08x\n",
+ hwdescr->next_descr_addr);
+ printk(KERN_ERR "result_size=x%08x\n", hwdescr->result_size);
+ printk(KERN_ERR "valid_size=x%08x\n", hwdescr->valid_size);
+ printk(KERN_ERR "data_status=x%08x\n", hwdescr->data_status);
+ printk(KERN_ERR "data_error=x%08x\n", hwdescr->data_error);
+ printk(KERN_ERR "which=%ld\n", descr - card->rx_chain.ring);
card->spider_stats.rx_desc_error++;
goto bad_desc;
diff --git a/drivers/net/spider_net.h b/drivers/net/spider_net.h
index dbbdb8c..c67b11d 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -493,7 +493,4 @@ struct spider_net_card {
struct spider_net_descr darray[0];
};
-#define pr_err(fmt,arg...) \
- printk(KERN_ERR fmt ,##arg)
-
#endif
diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
index 51807b4..80276d1 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -27,8 +27,7 @@
#include
#define MODULE_NAME"omapfb-lcd_h3"
-
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME ": " fmt, ## args)
+#define PFX MODULE_NAME ": "
static int h3_panel_init(struct lcd_panel *panel, struct omapfb_device *fbdev)
{
@@ -48,7 +47,7 @@ static int h3_panel_enable(struct lcd_panel *panel)
if (!r)
r = tps65010_set_gpio_out_value(GPIO2, HIGH);
if (r)
- pr_err("Unable to turn on LCD panel\n");
+ printk(KERN_ERR PFX "Unable to turn on LCD panel\n");
return r;
}
@@ -62,7 +61,7 @@ static void h3_panel_disable(struct lcd_panel *panel)
if (!r)
tps65010_set_gpio_out_value(GPIO2, LOW);
if (r)
- pr_err("Unable to turn off LCD panel\n");
+ printk(KERN_ERR PFX "Unable to turn off LCD panel\n");
}
static unsigned long h3_panel_get_caps(struct lcd_panel *panel)
diff --git
Re: WARN_ON() which sometimes sucks
On Wed, 1 Aug 2007, Paul Mackerras wrote: > > It will mean more code on architectures which have a > conditional-trap-on-nonzero instruction, such as powerpc, since the > compiler will generate instructions to evaluate !!x. But I don't see > any reason why ret_warn_on couldn't be a long. Umm. The WARN_ON() might actually get a "long long" value for all we know. Ie it's perfectly possible that the WARN_ON might look like /* Must not have high bits on */ WARN_ON(offset & 0x); which on a 32-bit pcc would apparently do the wrong thing entirely as it stands now. No? I think I'll commit the !!(x) version, and you guys can try to figure out what the right thing is long-term. For all I know, the proper solution is to just revert the whole mess, and *not* make WARN_ON() return a value at all, since that seems to be the fundamental mistake here. 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/
[PATCH]: sound: ioremap/iounmap function balancing audit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch, along with previously submitted dmasound_awacs.c patch,
completes an audit of the 'sound' tree for ioremap/iounmap
balancing and return code checking on ioremap calls. ioremap()
must be balanced by an iounmap() (else this causes a memory leak).
i810_audio.c had a 'fixme' issue regarding ioremap fail that was
addressed as well.
Signed-off-by: Scott Thompson hushmail.com>
- ---
diff --git a/sound/oss/i810_audio.c b/sound/oss/i810_audio.c
index f5e31f1..407958c 100644
- --- a/sound/oss/i810_audio.c
+++ b/sound/oss/i810_audio.c
@@ -3362,7 +3362,7 @@ static int __devinit i810_probe(struct
pci_dev *pci_dev, const struct pci_device
if (card->use_mmio) {
if (request_mem_region(card->ac97base_mmio_phys, 512, "ich_audio
MMBAR")) {
- - if ((card->ac97base_mmio =
ioremap(card->ac97base_mmio_phys,
512))) { /[EMAIL PROTECTED] can ioremap fail? don't know (jsaw) */
+ if ((card->ac97base_mmio =
ioremap(card->ac97base_mmio_phys,
512))) {
if (request_mem_region(card->iobase_mmio_phys,
256, "ich_audio
MBBAR")) {
if ((card->iobase_mmio =
ioremap(card->iobase_mmio_phys,
256))) {
printk(KERN_INFO "i810: %s mmio
at 0x%04lx and 0x%04lx\n",
@@ -3383,6 +3383,10 @@ static int __devinit i810_probe(struct
pci_dev *pci_dev, const struct pci_device
card->use_mmio = 0;
}
}
+ else {
+ card->use_mmio;
+ release_mem_region(card->ac97base_mmio_phys,
512);
+ }
}
else {
card->use_mmio = 0;
diff --git a/sound/oss/msnd_pinnacle.c b/sound/oss/msnd_pinnacle.c
index f1f49eb..117f79d 100644
- --- a/sound/oss/msnd_pinnacle.c
+++ b/sound/oss/msnd_pinnacle.c
@@ -1912,6 +1912,9 @@ static int __init msnd_init(void)
static void __exit msdn_cleanup(void)
{
+ if (dev.base)
+ iounmap(dev.base);
+
unload_multisound();
msnd_fifo_free();
msnd_fifo_free();
diff --git a/sound/pci/mixart/mixart.c b/sound/pci/mixart/mixart.c
index ac007ce..871b09f 100644
- --- a/sound/pci/mixart/mixart.c
+++ b/sound/pci/mixart/mixart.c
@@ -1319,6 +1319,13 @@ static int __devinit snd_mixart_probe(struct
pci_dev *pci,
pci_resource_len(pci, i));
}
+ if (!mgr->mem[0].virt || !mgr->mem[1].virt){
+ printk(KERN_ERR "unable to remap resource 0x%lx and/or 0x%lx\n",
+ mgr->mem[0].phys, mgr->mem[1].phys);
+ snd_mixart_free(mgr);
+ return -EBUSY;
+ }
+
if (request_irq(pci->irq, snd_mixart_interrupt, IRQF_SHARED,
CARD_NAME, mgr)) {
snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
diff --git a/sound/pci/rme32.c b/sound/pci/rme32.c
index 618653e..d62d32a 100644
- --- a/sound/pci/rme32.c
+++ b/sound/pci/rme32.c
@@ -1373,6 +1373,7 @@ static int __devinit snd_rme32_create(struct
rme32 * rme32)
if (request_irq(pci->irq, snd_rme32_interrupt, IRQF_SHARED,
"RME32", rme32)) {
snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
+ iounmap(rme32->iobase);
return -EBUSY;
}
rme32->irq = pci->irq;
@@ -1382,6 +1383,7 @@ static int __devinit snd_rme32_create(struct
rme32 * rme32)
/* set up ALSA pcm device for S/PDIF */
if ((err = snd_pcm_new(rme32->card, "Digi32 IEC958", 0, 1, 1,
>spdif_pcm)) < 0) {
+ iounmap(rme32->iobase);
return err;
}
rme32->spdif_pcm->private_data = rme32;
@@ -1414,6 +1416,7 @@ static int __devinit snd_rme32_create(struct
rme32 * rme32)
if ((err = snd_pcm_new(rme32->card, "Digi32 ADAT", 1,
1, 1, >adat_pcm)) < 0)
{
+ iounmap(rme32->iobase);
return err;
}
rme32->adat_pcm->private_data = rme32;
@@ -1459,6 +1462,7 @@ static int __devinit snd_rme32_create(struct
rme32 * rme32)
/* init switch interface */
if ((err = snd_rme32_create_switches(rme32->card, rme32)) < 0) {
+ iounmap(rme32->iobase);
return err;
}
diff --git a/sound/pci/rme96.c b/sound/pci/rme96.c
index e3304b7..25af36c 100644
- --- a/sound/pci/rme96.c
+++ b/sound/pci/rme96.c
@@ -1590,6 +1590,7 @@ snd_rme96_create(struct rme96 *rme96)
if (request_irq(pci->irq, snd_rme96_interrupt, IRQF_SHARED,
"RME96", rme96)) {
snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
+
Re: [Patch 09/16] Remove unnecessary kmalloc casts in the pci subsystem.
Greg KH writes: > On Tue, Jul 31, 2007 at 06:20:29PM +0200, Andreas Schwab wrote: > > Greg KH <[EMAIL PROTECTED]> writes: > > > > > On Tue, Jul 31, 2007 at 10:46:19PM +0800, WANG Cong wrote: > > >> However, I think using resource_size_t is a bit better than unsigned > > >> long, > > >> so that we don't need to check the defination of it. > > >> > > >> - res->start = (unsigned long)kmalloc(*size, GFP_KERNEL); > > >> + res->start = (resource_size_t)kmalloc(*size, GFP_KERNEL); > > >> > > >> Is this change OK? > > > > > > Yes, that is the proper cast to have here. > > > > It will generate a warning when resoure_size_t is 64bit on a 32bit arch. > > How? And if so, what should the proper cast be? You'll get a "cast from pointer to different-sized integer" type of warning. The proper cast is unsigned long, just like the code is without this patch. :) Paul. - 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 34] fs/autofs4/inode.c: kmalloc + memset conversion to kzalloc
On Tue, 2007-07-31 at 20:05 +0200, Mariusz Kozlowski wrote:
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
ACK.
>
> fs/autofs4/inode.c | 10467 -> 10435 (-32 bytes)
> fs/autofs4/inode.o | 98576 -> 98552 (-24 bytes)
>
> fs/autofs4/inode.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> --- linux-2.6.23-rc1-mm1-a/fs/autofs4/inode.c 2007-07-26 13:07:46.0
> +0200
> +++ linux-2.6.23-rc1-mm1-b/fs/autofs4/inode.c 2007-07-29 23:56:08.0
> +0200
> @@ -312,13 +312,11 @@ int autofs4_fill_super(struct super_bloc
> struct autofs_sb_info *sbi;
> struct autofs_info *ino;
>
> - sbi = kmalloc(sizeof(*sbi), GFP_KERNEL);
> + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
> if (!sbi)
> goto fail_unlock;
> DPRINTK("starting up, sbi = %p",sbi);
>
> - memset(sbi, 0, sizeof(*sbi));
> -
> s->s_fs_info = sbi;
> sbi->magic = AUTOFS_SBI_MAGIC;
> sbi->pipefd = -1;
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
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: WARN_ON() which sometimes sucks
Al Viro writes: > Actually, the real problem is different - WTF do we need that typeof > anyway? > int ret_warn_on = !!(condition); > [same as now] > will work just fine... It will mean more code on architectures which have a conditional-trap-on-nonzero instruction, such as powerpc, since the compiler will generate instructions to evaluate !!x. But I don't see any reason why ret_warn_on couldn't be a long. Paul. - 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] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure
On Tue, 2007-07-31 at 20:26 -0400, Gregory Haskins wrote:
> The following workqueue related patch is a port of the original VFCIPI PI
> patch I submitted earlier. There is still more work to be done to add the
> "schedule_on_cpu()" type behavior, and even more if we want to use this as
> part of KVM. But for now, this patch can stand alone so I thought I would
> get it out there.
>
> --
>
> Mainline workqueues treat all requests the same. This patch prioritizes
> requests in the queue based on the callers current rt_priority. It also
> adds a priority-inheritance feature to avoid inversion.
>
> Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
> ---
>
> include/linux/workqueue.h |2
> kernel/workqueue.c| 198
> +
> 2 files changed, 149 insertions(+), 51 deletions(-)
Here's a simpler version .. uses the plist data structure instead of the
100 queues, which makes for a cleaner patch ..
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
---
include/linux/workqueue.h |7 ---
kernel/power/poweroff.c |1 +
kernel/sched.c|4
kernel/workqueue.c| 40 +---
4 files changed, 30 insertions(+), 22 deletions(-)
Index: linux-2.6.22/include/linux/workqueue.h
===
--- linux-2.6.22.orig/include/linux/workqueue.h
+++ linux-2.6.22/include/linux/workqueue.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
struct workqueue_struct;
@@ -26,7 +27,7 @@ struct work_struct {
#define WORK_STRUCT_PENDING 0 /* T if work item pending execution */
#define WORK_STRUCT_FLAG_MASK (3UL)
#define WORK_STRUCT_WQ_DATA_MASK (~WORK_STRUCT_FLAG_MASK)
- struct list_head entry;
+ struct plist_node entry;
work_func_t func;
};
@@ -43,7 +44,7 @@ struct execute_work {
#define __WORK_INITIALIZER(n, f) { \
.data = WORK_DATA_INIT(), \
- .entry = { &(n).entry, &(n).entry }, \
+ .entry = PLIST_NODE_INIT(n.entry, MAX_PRIO), \
.func = (f),\
}
@@ -79,7 +80,7 @@ struct execute_work {
#define INIT_WORK(_work, _func)
\
do {\
(_work)->data = (atomic_long_t) WORK_DATA_INIT(); \
- INIT_LIST_HEAD(&(_work)->entry);\
+ plist_node_init(&(_work)->entry, -1); \
PREPARE_WORK((_work), (_func)); \
} while (0)
Index: linux-2.6.22/kernel/power/poweroff.c
===
--- linux-2.6.22.orig/kernel/power/poweroff.c
+++ linux-2.6.22/kernel/power/poweroff.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
Index: linux-2.6.22/kernel/sched.c
===
--- linux-2.6.22.orig/kernel/sched.c
+++ linux-2.6.22/kernel/sched.c
@@ -4379,8 +4379,6 @@ long __sched sleep_on_timeout(wait_queue
}
EXPORT_SYMBOL(sleep_on_timeout);
-#ifdef CONFIG_RT_MUTEXES
-
/*
* rt_mutex_setprio - set the current priority of a task
* @p: task
@@ -4457,8 +4455,6 @@ out_unlock:
task_rq_unlock(rq, );
}
-#endif
-
void set_user_nice(struct task_struct *p, long nice)
{
int old_prio, delta, on_rq;
Index: linux-2.6.22/kernel/workqueue.c
===
--- linux-2.6.22.orig/kernel/workqueue.c
+++ linux-2.6.22/kernel/workqueue.c
@@ -44,7 +44,7 @@ struct cpu_workqueue_struct {
spinlock_t lock;
- struct list_head worklist;
+ struct plist_head worklist;
wait_queue_head_t more_work;
struct work_struct *current_work;
@@ -127,16 +127,19 @@ struct cpu_workqueue_struct *get_wq_data
static void insert_work(struct cpu_workqueue_struct *cwq,
struct work_struct *work, int tail)
{
+ int prio = current->normal_prio;
+
set_wq_data(work, cwq);
/*
* Ensure that we get the right work->data if we see the
* result of list_add() below, see try_to_grab_pending().
*/
smp_wmb();
- if (tail)
- list_add_tail(>entry, >worklist);
- else
- list_add(>entry, >worklist);
+ plist_node_init(>entry, prio);
+ plist_add(>entry, >worklist);
+
+ if (prio < cwq->thread->prio)
+ rt_mutex_setprio(cwq->thread, prio);
wake_up(>more_work);
}
@@ -168,7 +171,7 @@ int fastcall queue_work(struct workqueue
int ret = 0, cpu = raw_smp_processor_id();
if
Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?
Satyam Sharma wrote: > On 7/27/07, Alan Cox <[EMAIL PROTECTED]> wrote: >>> Maybe I should resurrect it & send it out... > > Hmm, something that hooks in not only at do_IRQ time (as the present > in-mainline stackoverflow check thing)? No, what I had did only that, so it was still a matter of probabilities... -Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 7/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> The Coverity checker spotted that we have already oops'ed if "fe" was NULL.
>
> Since "fe" being NULL seems impossible at this point this patch removes
> the NULL check.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old
> 2007-07-29 21:41:56.0 +0200
> +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c
> 2007-07-29 21:42:16.0 +0200
> @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino
> struct dvb_frontend_private *fepriv = fe->frontend_priv;
> int err = -EOPNOTSUPP;
>
> dprintk ("%s\n", __FUNCTION__);
>
> - if (!fe || fepriv->exit)
> + if (fepriv->exit)
> return -ENODEV;
>
> if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
> (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
> cmd == FE_DISEQC_RECV_SLAVE_REPLY))
>
> -
Acked-by: Manu Abraham <[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: IRQ Delivery Problem for MCP65
[cc'ing linux-pci and quoting whole body.] Any ideas? Craig Block wrote: > --- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > >>> --- Craig Block <[EMAIL PROTECTED]> wrote: > >>> I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X >>> motherboard with an MCP65 (nForce 520) chipset. When the kernel probes the >>> AHCI controllers, it hangs for a minute or so on each one and returns the >>> following; >>> >>> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) >> I googled for some more info about similar issues and found very similar >> problem being discussed on Gentoo forum: >> >> The important part is here: >> >> "when I disabled Message Signaled Interrupts (MSI and MSI-X) under "Bus >> Options" in the kernel, the problem magically went away (disabling MSI)" >> >> which indicates IRQ routing problems (as suspected from dmesg output and also >> stated by Tejun). Have you already tried disabling MSI IRQs with "pci=nomsi" >> (not "nomsi") or even completely disabling CONFIG_PCI_MSI support? > > Thanks a ton, building the kernel with PCI_MSI not set did the trick. > Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate > the problem. I had to build the kernel without MSI support. There's a few > interesting differences in the dmesg output with "PCI_MSI=y" and PCI_MSI not > set; > > With PCI_MSI not set; > > ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x bmdma 0x irq 5 > ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x bmdma 0x irq 5 > ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x bmdma 0x irq 5 > ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x bmdma 0x irq 5 > > With PCI_MSI=y; > > ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x bmdma 0x irq 219 > ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x bmdma 0x irq 219 > ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x bmdma 0x irq 219 > ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x bmdma 0x irq 219 > > Also, there's a spurous interrupt message that appears with PCI_MSI=y; > > spurious 8259A interrupt: IRQ7. > > I attached the two dmesg instances for reference. -- tejun 6896k available (1556k kernel code, 24352k reserved, 545k data, 168k init, 1179392k highmem) virtual kernel memory layout: fixmap : 0xfffaf000 - 0xf000 ( 320 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc031 - 0xc033a000 ( 168 kB) .data : 0xc0285011 - 0xc030d70c ( 545 kB) .text : 0xc010 - 0xc0285011 (1556 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4824.67 BogoMIPS (lpj=2412339) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff ebd3fbff 2001 011d CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 078bfbff ebd3fbff 0410 2001 011d Compat vDSO mapped to e000. CPU: AMD Athlon(tm) 64 Processor 3800+ stepping 01 Checking 'hlt' instruction... OK. ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 NET: Registered protocol family 16 PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized libata version 2.21 loaded. PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - :00:08.0 PCI: Using IRQ router default [10de/0441] at :00:01.0 PCI->APIC IRQ transform: :00:01.1[A] -> IRQ 10 PCI->APIC IRQ transform: :00:02.0[A] -> IRQ 11 PCI->APIC IRQ transform: :00:02.1[B] -> IRQ 10 PCI->APIC IRQ transform: :00:07.0[B] -> IRQ 11 PCI->APIC IRQ transform: :00:0a.0[A] -> IRQ 5 PCI->APIC IRQ transform: :01:08.0[A] -> IRQ 11 PCI->APIC IRQ transform: :04:00.0[A] -> IRQ 11 PCI: Bridge: :00:08.0 IO window: d000-dfff MEM window: dbf0-dbff Time: tsc clocksource has been installed. PREFETCH window: 8800-880f PCI: Bridge: :00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:0d.0 IO window: e000-efff MEM window: dc00-dfff PREFETCH window: c000-cfff PCI: Bridge: :00:0e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Setting latency timer of device :00:08.0 to 64 PCI: Setting latency timer of device :00:0b.0 to 64 PCI: Setting latency timer of device :00:0c.0 to 64 PCI: Setting latency timer of device :00:0d.0 to 64 PCI: Setting latency
CFS review
Hi, On Sat, 14 Jul 2007, Mike Galbraith wrote: > > On Fri, 13 Jul 2007, Mike Galbraith wrote: > > > > > > The new scheduler does _a_lot_ of heavy 64 bit calculations without any > > > > attempt to scale that down a little... > > > > > > See prio_to_weight[], prio_to_wmult[] and sysctl_sched_stat_granularity. > > > Perhaps more can be done, but "without any attempt..." isn't accurate. > > > > Calculating these values at runtime would have been completely insane, the > > alternative would be a crummy approximation, so using a lookup table is > > actually a good thing. That's not the problem. > > I meant see usage. I more meant serious attempts. At this point I'm not that much interested in a few localized optimizations, what I'm interested in is how can this optimized at the design level (e.g. how can arch information be used to simplify things). So I spent quite a bit of time looking through cfs and experimenting with some ideas. I want to put the main focus on the performance aspect, but there are a few other issues as well. But first something else (especially for Ingo): I tried to be very careful with any claims made in this mail, but this of course doesn't exclude the possibility of errors, in which case I'd appreciate any corrections. Any explanations done in this mail don't imply that anyone needs any such explanations, they're done to keep things in context, so that interested readers have a chance to follow even if they don't have the complete background information. Any suggestions made don't imply that they have to be implemented like this, there are more an incentive for further discussion and I'm always interested in better solutions. A first indication that something may not be quite right is the increase in code size: 2.6.22: textdata bss dec hex filename 10150 243344 1351834ce kernel/sched.o recent git: textdata bss dec hex filename 14724 2282020 16972424c kernel/sched.o That's i386 without stats/debug. A lot of the new code is in regularly executed regions and it's often not exactly trivial code as cfs added lots of heavy 64bit calculations. With the increased text comes increased runtime memory usage, e.g. task_struct increased so that only 5 of them instead 6 fit now into 8KB. Since sched-design-CFS.txt doesn't really go into any serious detail, so the EEVDF paper was more helpful and after playing with the ideas a little I noticed that the whole idea of fair scheduling can be explained somewhat simpler and I'm a little surprised not finding it mentioned anywhere. So a different view on this is that the runtime of a task is simply normalized and the virtual time (or fair_clock) is the weighted average of these normalized runtimes. The advantage of normalization is that it makes things comparable, once the normalized time values are equal each task got its fair share. It's more obvious in the EEVDF paper, cfs makes it a bit more complicated, as it uses the virtual time to calculate the eligible runtime, but it doesn't maintain a per process virtual time (fair_key is not quite the same). Here we get to the first problem, cfs is not overly accurate at maintaining a precise balance. First there a lot of rounding errors due to constant conversion between normalized and non-normalized values and the higher the update frequency the bigger the error. The effect of this can be seen by running: while (1) sched_yield(); and watching the sched_debug output and watch the underrun counter go crazy. cfs thus needs the limiting to keep this misbehaviour under control. The problem here is that it's not that difficult to hit one of the many limits, which may change the behaviour and makes cfs hard to predict how it will behave under different situations. The next issue is scheduler granularity, here I don't quite understand why the actual running time has no influence at all, which makes it difficult to predict how much cpu time a process will get at a time (even the comments only refer to the vmstat output). What is basically used instead is the normalized time since it was enqueued and practically it's a bit more complicated, as fair_key is not entirely a normalized time value. If the wait_runtime value is positive, higher prioritized tasks are given even more priority than they already get from their larger wait_runtime value. The problem here is that this triggers underruns and lower priority tasks get even less time. Another issue is the sleep bonus given to sleeping tasks. A problem here is that this can be exploited, if a job is spread over a few threads, they can get more time relativ to other tasks, e.g. in this example there are three tasks that run only for about 1ms every 3ms, but they get far more time than should have gotten fairly: 4544 roman 20 0 1796 520 432 S 32.1 0.4 0:21.08 lt 4545 roman 20 0 1796 344 256 R 32.1 0.3 0:21.07 lt
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > The Sonics Silicon Backplane is a mini-bus used on > various Broadcom chips and embedded devices. Sigh. s390: drivers/ssb/main.c: In function 'ssb_ssb_read16': drivers/ssb/main.c:489: error: implicit declaration of function 'readw' drivers/ssb/main.c: In function 'ssb_ssb_read32': drivers/ssb/main.c:497: error: implicit declaration of function 'readl' drivers/ssb/main.c: In function 'ssb_ssb_write16': drivers/ssb/main.c:505: error: implicit declaration of function 'writew' drivers/ssb/main.c: In function 'ssb_ssb_write32': drivers/ssb/main.c:513: error: implicit declaration of function 'writel' we shouldn't be compiling SSB on s390, because: config SSB tristate "Sonics Silicon Backplane support" depends on EXPERIMENTAL && HAS_IOMEM and akpm2:/usr/src/25> grep IOMEM .config CONFIG_NO_IOMEM=y akpm2:/usr/src/25> but akpm2:/usr/src/25> grep SSB .config CONFIG_DCSSBLK=m CONFIG_SSB=m CONFIG_SSB_SILENT=y well, how did that come about? It _has_ to be `select'. It's _always_ `select'. yup, it's `select': Selected by: B44 && NETDEVICES && NET_ETHERNET || BCM43XX_MAC80211 && NETDEVICES && !S390 && MAC80211 && WLAN_80211 && EXPERIMENTAL Look. Kconfig's `select' Just. Does. Not. Work. If you find yourself contemplating using it, please, don sackcloth, take a cold shower and several analgesics, then have another go, OK? ho hum. - 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] ACPI: delete CONFIG_ACPI_PROCFS_SLEEP (again)
From: Len Brown <[EMAIL PROTECTED]> CONFIG_ACPI_PROCFS_SLEEP is a NO-OP -- delete it (again). Apparently 296699de6bdc717189a331ab6bbe90e05c94db06 creating CONFIG_SUSPEND and CONFIG_PM_SLEEP was based on an out-dated version of drivers/acpi/Kconfig, as it erroneously restored this recently deleted config option. Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 934d639..f1372de 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -68,14 +68,6 @@ config ACPI_PROCFS Say N to delete /proc/acpi/ files that have moved to /sys/ -config ACPI_PROCFS_SLEEP - bool "/proc/acpi/sleep (deprecated)" - depends on PM_SLEEP && ACPI_PROCFS - default n - ---help--- - Create /proc/acpi/sleep - Deprecated by /sys/power/state - config ACPI_AC tristate "AC Adapter" depends on X86 - 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 RT] Move RECURSION_LIMIT define up for more global use (take 2)
OK, I sent this out once before but it must have slipped under the radar.
http://lkml.org/lkml/2007/6/28/325
My config fails miserably with lockdep:
kernel/lockdep.c: In function 'find_usage_forwards':
kernel/lockdep.c:814: error: 'RECURSION_LIMIT' undeclared (first use in
this function)
kernel/lockdep.c:814: error: (Each undeclared identifier is reported only
once
kernel/lockdep.c:814: error: for each function it appears in.)
kernel/lockdep.c:815: warning: implicit declaration of function
'print_infinite_recursion_bug'
kernel/lockdep.c: In function 'find_usage_backwards':
kernel/lockdep.c:856: error: 'RECURSION_LIMIT' undeclared (first use in
this function)
make[1]: *** [kernel/lockdep.o] Error 1
But this patch fixes it nicely.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6.22.1-rt9/kernel/lockdep.c
===
--- linux-2.6.22.1-rt9.orig/kernel/lockdep.c2007-07-31 23:14:12.0
-0400
+++ linux-2.6.22.1-rt9/kernel/lockdep.c 2007-07-31 23:25:04.0 -0400
@@ -683,6 +683,21 @@ static void print_kernel_version(void)
init_utsname()->version);
}
+#if defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_TRACE_IRQFLAGS)
+
+#define RECURSION_LIMIT 40
+
+static int noinline print_infinite_recursion_bug(void)
+{
+ if (!debug_locks_off_graph_unlock())
+ return 0;
+
+ WARN_ON(1);
+
+ return 0;
+}
+#endif /* CONFIG_PROVE_LOCKING || CONFIG_TRACE_IRQFLAGS */
+
#ifdef CONFIG_PROVE_LOCKING
/*
* When a circular dependency is detected, print the
@@ -736,18 +751,6 @@ static noinline int print_circular_bug_t
return 0;
}
-#define RECURSION_LIMIT 40
-
-static int noinline print_infinite_recursion_bug(void)
-{
- if (!debug_locks_off_graph_unlock())
- return 0;
-
- WARN_ON(1);
-
- return 0;
-}
-
/*
* Prove that the dependency graph starting at can not
* lead to . Print an error and return 0 if it does.
@@ -874,6 +877,7 @@ find_usage_backwards(struct lock_class *
return 1;
}
+#ifdef CONFIG_PROVE_LOCKING
static int
print_bad_irq_dependency(struct task_struct *curr,
struct held_lock *prev,
@@ -956,6 +960,7 @@ check_usage(struct task_struct *curr, st
return print_bad_irq_dependency(curr, prev, next,
bit_backwards, bit_forwards, irqclass);
}
+#endif /* CONFIG_PROVE_LOCKING */
#endif
-
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] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote: >> I don't think the interface you're suggesting is a good one. Do you? > > I think if it's applicable to SCSI at all it is fine. If it is not, then > I think we need to make do with the interface we are given. I do not think > we should hold up a feature for libata sysfs integration. Well, I guess we'll have to agree to disagree here and leave the decision to James and Jeff. >>> I can assert that I think ALPM is a good idea, >>> because I've never had a report of it causing problems. Windows has >>> been using this feature for a very long time - and you have to admit that >>> they have a pretty large market share. Nobody is complaining about ALPM >>> increasing device malfunction, so unless you have proof it seems insane >>> to nak due to this. >> Is ALPM enabled by default? How do they deal with the performance >> degradation? > > I believe so, but I'm obviously not privvy to their implementation details. It would be *really* great if we can find more about how they do it. How and when it's enabled and on which systems. Is it possible to find this out? -- 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: [patch 2/4] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote: > So at current rate of development and kernel release schedule, the best > possible scenario is still 6 months away - whereas this patchset is already > tested and ready for merging now. The best possible scenario is .24-rc1 merge window with or without waiting. With waiting, the best possible scenario is harder to achieve tho. > Out of tree patches don't work. Nobody tests them. A module parameter > will not work - we need to be able to expose the sysfs interface so that > users may chose to turn the feature off and on at will - mainly according > to their usage. For example, at boot time - you want ALPM off to maximize > performance. Lets say when you are plugged into the wall socket, you leave > it off, but then when you go on battery power you would want to enable it. You can turn on and off dynamically using a module parameter. Although it's not a pretty interface, it should work as an interim solution if we absolutely must merge ALPM now. >> Due to the generosity of the ATA committee, we have, by default, at >> least two ways to achieve link PS - HIPS and DIPS. I dunno why but >> someone thought we needed two. And then, ahci people thought automatic > > They thought we needed two because sometimes the device knows when it > will be idle faster than the host can. this is why ALPM can determine > idleness faster than any software algorithm on the host cpu can. You > can use ALPM without having HIPM. You can also use it without having > DIPM. I see. I get that one way is better than another in some way. I'm just not convinced whether the advantage is substantial enough to justify the complexity. >> HIPS would be nice, which I fully agree, and added ALPM. Unfortunately, >> they mandated ALPM to kick in the moment command engine becomes idle, so >> most current implementations suffer unnecessary performance hit when >> ALPM is active. > > "unnecessary" is subjective and at the moment, untrue. You > have to make performance/power tradeoffs with anything, whether it's > CPU or your AHCI controller. It's the current cost of getting out of these > sleep states even if you aren't using ALPM but just doing HIPM or DIPM > manually. Having short cool-down time would remove most of performance degradation and I'm pretty sure power consumption would stay about the same. > But, this is why it's so critical to allow the user to > control when ALPM is enabled dynamically - which this patchset does. > The medium power setting is provided for users who wish to not go to > SLUMBER and get the higher latency cost but still have some power savings. Note that PARTIAL also incurs noticeable performance degradation. > I understand you are being cautious based on your prior experience, but > again we still have no data to show that we are going to have a lot of > problems. Perhaps we should proceed optimistically and deal with problems > when they actually occur rather than block something on a bet. I would agree with you, merge it and see the fireworks in -mm if it didn't involve user visible API. We have an API decision to make here and it hasn't been sufficiently considered yet. >> The alternate way is to export flexible interface to userland and let >> userland decide and if we're gonna do that. SCSI sysfs just isn't the >> place. > > How about a patch? I'd love to have a flexible interface to userland, > it was my goal to provide this with the sysfs files. The requirement > is that the users be able to turn ALPM off and on dynamically, and to > be able to chose the power savings level you want - i.e. SLUMBER vs. > PARTIAL - perferrably not using those terms since users really shouldn't > need to know AHCI terminology just to chose a power management level. As I wrote before, which level of interface to export to userland is related with where to put the knowledge about working and broken combinations. Unfortunately, we don't have data to support one way or the other at the moment. All I'm saying is that we should be cautious before introducing user-land visible interface which lives in SCSI sysfs as it's unknown whether it would fit the reality or not. Sorry that I don't have an alternative patch now, but something which can relieve the situation is being worked on, so let's give it some time and see how things turn out. Things have to wait till the next -rc1 window anyway. 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/
[PATCH] [POWERPC] Typo fixes interrrupt -> interrupt
Hi,
This patch fixes some interrrupt -> interrupt typos and the comments in
it_lp_naca.h
Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/embedded6xx/holly.c|2 +-
arch/powerpc/platforms/embedded6xx/linkstation.c |2 +-
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |2 +-
arch/powerpc/platforms/iseries/it_lp_naca.h | 87 +++--
include/asm-ppc/commproc.h|2 +-
5 files changed, 49 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c
b/arch/powerpc/platforms/embedded6xx/holly.c
index 6292e36..fda16e8 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -147,7 +147,7 @@ static void __init holly_setup_arch(void)
}
/*
- * Interrupt setup and service. Interrrupts on the holly come
+ * Interrupt setup and service. Interrupts on the holly come
* from the four external INT pins, PCI interrupts are routed via
* PCI interrupt control registers, it generates internal IRQ23
*
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c
b/arch/powerpc/platforms/embedded6xx/linkstation.c
index bd5ca58..8c60e02 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -99,7 +99,7 @@ static void __init linkstation_setup_arch(void)
}
/*
- * Interrupt setup and service. Interrrupts on the linkstation come
+ * Interrupt setup and service. Interrupts on the linkstation come
* from the four PCI slots plus onboard 8241 devices: I2C, DUART.
*/
static void __init linkstation_init_IRQ(void)
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index 1e3cc69..25c29bc 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -91,7 +91,7 @@ static void __init mpc7448_hpc2_setup_arch(void)
}
/*
- * Interrupt setup and service. Interrrupts on the mpc7448_hpc2 come
+ * Interrupt setup and service. Interrupts on the mpc7448_hpc2 come
* from the four external INT pins, PCI interrupts are routed via
* PCI interrupt control registers, it generates internal IRQ23
*
diff --git a/arch/powerpc/platforms/iseries/it_lp_naca.h
b/arch/powerpc/platforms/iseries/it_lp_naca.h
index 9bbf589..46060bb 100644
--- a/arch/powerpc/platforms/iseries/it_lp_naca.h
+++ b/arch/powerpc/platforms/iseries/it_lp_naca.h
@@ -21,53 +21,56 @@
#include
/*
- * This control block contains the data that is shared between the
- * hypervisor (PLIC) and the OS.
+ * This control block contains the data that is shared between the
+ * hypervisor (PLIC) and the OS.
*/
-
struct ItLpNaca {
-// CACHE_LINE_1 0x - 0x007F Contains read-only data
- u32 xDesc; // Eye catcher x00-x03
- u16 xSize; // Size of this class x04-x05
- u16 xIntHdlrOffset; // Offset to IntHdlr array x06-x07
- u8 xMaxIntHdlrEntries; // Number of entries in array x08-x08
- u8 xPrimaryLpIndex;// LP Index of Primary x09-x09
- u8 xServiceLpIndex;// LP Ind of Service Focal Pointx0A-x0A
- u8 xLpIndex; // LP Index x0B-x0B
- u16 xMaxLpQueues; // Number of allocated queues x0C-x0D
- u16 xLpQueueOffset; // Offset to start of LP queues x0E-x0F
- u8 xPirEnvironMode;// Piranha or hardware x10-x10
- u8 xPirConsoleMode;// Piranha console indicatorx11-x11
- u8 xPirDasdMode; // Piranha dasd indicator x12-x12
- u8 xRsvd1_0[5];// Reserved for Piranha related x13-x17
- u8 flags; // flags, see below x18-x1F
- u8 xSpVpdFormat; // VPD areas are in CSP format ...
- u8 xIntProcRatio; // Ratio of int procs to procs ...
- u8 xRsvd1_2[5];// Reserved ...
- u16 xRsvd1_3; // Reserved x20-x21
- u16 xPlicVrmIndex; // VRM index of PLICx22-x23
- u16 xMinSupportedSlicVrmInd;// Min supported OS VRM index x24-x25
- u16 xMinCompatableSlicVrmInd;// Min compatible OS VRM index x26-x27
- u64 xLoadAreaAddr; // ER address of load area x28-x2F
- u32 xLoadAreaChunks;// Chunks for the load area x30-x33
- u32 xPaseSysCallCRMask; // Mask used to test CR before x34-x37
- // doing an ASR switch on PASE
- // system call.
- u64 xSlicSegmentTablePtr; // Pointer to Slic seg table. x38-x3f
- u8
eurotechwdt will cause reboot
Hi, config eurotechwdt to yes will cause system silent reboot. Is it right behaviour or a bug? Regards dave - 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: VT_PROCESS, VT_LOCKSWITCH capabilities
Frank Benkstein wrote:
> I wonder why there are different permissions needed for VT_PROCESS
> (access to the current virtual console) and VT_LOCKSWITCH
> (CAP_SYS_TTY_CONFIG).
To be more direct:
require CAP_SYS_TTY_CONFIG for VT_SETMODE as its essentially the same as
VT_LOCKSWITCH and said capability is already required there
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index c6f6f42..7034a68 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -662,7 +662,7 @@ int vt_ioctl(struct tty_struct *tty, struct file * file,
{
struct vt_mode tmp;
- if (!perm)
+ if (!perm || !capable(CAP_SYS_TTY_CONFIG))
return -EPERM;
if (copy_from_user(, up, sizeof(struct vt_mode)))
return -EFAULT;
--
GPG (Mail): 7093 7A43 CC40 463A 5564 599B 88F6 D625 BE63 866F
GPG (XMPP): 2243 DBBA F234 7C5A 6D71 3983 9F28 4D03 7110 6D51
signature.asc
Description: OpenPGP digital signature
Re: [ck] Re: Linus 2.6.23-rc1
Bill Huey (hui) wrote: On Tue, Jul 31, 2007 at 09:15:17AM +0800, Carlo Florendo wrote: And I think you are digressing from the main issue, which is the empirical comparison of SD vs. CFS and to determine which is best. The root of all the scheduler fuss was the emotional reaction of SD's author on why his scheduler began to be compared with CFS. Legitimate emotional reaction for being locked out of the development process. There's a very human aspect to this, yes, a negative human aspect that pervade Linux kernel development and is overly defensive and protective of new ideas. Yes, the reaction was legitimate but it could have been better. It would have benefited everyone if instead of posting rants, numbers and patches or suggested solutions were posted. Up until today, some posters that complain on how CFS fairs worse than SD simply post reports that say: "I use this system in this way and it does not fair well with cfs!" Look at this one for example: http://lkml.org/lkml/2007/7/31/199 It looks technical but it isn't. The author simply stated that he built his own lightweight Linux box that specializes in audio but there has not been any technical characteristic of the problem. We don't even know the audio libraries he's using but simply claimed that he wrote his own. The report, if I were the one to debug it, is completely useless since it does not even give some reproducability hints nor technical characteristics of the system. This is what some of the SD fan-boys do. Rant. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp - 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: "Add support for vector domain" breaks boot on x355
On 01.08.2007 [10:43:43 +0900], Kenji Kaneshige wrote: > 2007-07-31 (?$B2P) ?$B$N 15:13 -0700 ?$B$K Nishanth Aravamudan > ?$B$5$s$O=q$-$^$7$?: > > The following commit (4994be1b3fe9120c88022ff5c0c33f6312b17adb) broke > > Linus' Tree between 2.6.22-git15 and 2.6.22-git16 on a 2-node 8-way x455 > > (Madison procs). Thanks to Ryan Hodges for bisecting down to this > > commit. > > Thank you for reporting. > > I think this problem might be fixed by the commit > 6ffbc82351c62aeb9e817ddf93049353493d. Could you try that? Ah you might be right. Our testing harness is missing that the kernel came up further, at least. (2.6.23-rc1-git9 works fine, mostly, it looks like) Thanks! Nish -- Nishanth Aravamudan <[EMAIL PROTECTED]> IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] coredump: cleanup documentation for suid_dumpable
Hi Alan, Alan Cox wrote: > On Tue, 31 Jul 2007 15:03:40 +0800 > Eugene Teo <[EMAIL PROTECTED]> wrote: > >> This patch removes documentation that is related to suidsafe core dump >> mode. >> >> Signed-off-by: Eugene Teo <[EMAIL PROTECTED]> > > NAK - this feature is actively used and can be set by the sysctl > interface. The PRCTL fixup was just a bug being fixed. The sysctl > interface is still relevant. Thank you for correcting me. Appreciated. I am not aware that it is still being actively used. May I know who or which program is using this feature? Thanks, Eugene - 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] net/sched: mark "NET_CLS_RSVP6 depends on IPV6"
On 8/1/07, Gabriel C <[EMAIL PROTECTED]> wrote: > I thought the same but ... see > > http://marc.info/?l=linux-kernel=118440958516205=2 > http://marc.info/?l=linux-netdev=118442747709230=2 That sounds good. Thanks. -- Denis - 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 14/16] Remove needless kmalloc casts in the zd1211rw drivers.
Stefan Richter wrote: NAK: this patch adds a sparse warning zd_chip.c:116:15: warning: implicit cast to nocast type What does this warning mean? a16 is defined as zd_addr_t *. zd_addr_t is defined as typedef u16 __nocast zd_addr_t; The __nocast annotation forces us to use explicit casts for values of this type. This is really useful as we have functions which take an address and a value (e.g. register writes). It's very easy to get them in the wrong order and have a non-obvious bug. With this mechanism, sparse helps us avoid this. The case with pointers may be a little unintuitive, but it's a small price to pay for a bug that bit us hard once before... The number of other places we have to cast is very small due to use of the preprocessor. For example we have: #define ZD_ADDR(base, offset) \ ((zd_addr_t)(((base) & ADDR_BASE_MASK) | ((offset) & ADDR_OFFSET_MASK))) #define CTL_REG(offset) ZD_ADDR(CR_BASE, offset) /* byte addressing */ Then we have a few hundred registers defined in terms of CTL_REG. Also, why is there this cast right before that? zd_addr_t *a16 = (zd_addr_t *)NULL; For similar reasons. Daniel - 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] retrieve VBE EDID/DDC info independent of used video mode
Antonino A. Daplas wrote: > On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: >> Zwane Mwaikambo wrote: >>> Sorry if this has been hashed out before, but could you point me towards >>> the gentoo bugzilla entry? I'm trying to understand how your setup broke. >>> Which version VBE does your system have? >> Here's the bug: >> http://bugs.gentoo.org/show_bug.cgi?id=181067 >> > > Looking at the dmesg output of the working and failing kernel, it does > seem that there's no EDID block available in the failing kernel. > >> How can we identify the VBE version? You could use http://john.fremlin.de/programs/linux/read-edid/ and you get the EDID and VBE version Regards, Gabriel - 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] retrieve VBE EDID/DDC info independent of used video mode
Daniel Drake wrote: Zwane Mwaikambo wrote: Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Here's the bug: http://bugs.gentoo.org/show_bug.cgi?id=181067 How can we identify the VBE version? Thanks, Daniel Just put printf's in video-vesa.c -hpa - 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] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: > Zwane Mwaikambo wrote: > > Sorry if this has been hashed out before, but could you point me towards > > the gentoo bugzilla entry? I'm trying to understand how your setup broke. > > Which version VBE does your system have? > > Here's the bug: > http://bugs.gentoo.org/show_bug.cgi?id=181067 > Looking at the dmesg output of the working and failing kernel, it does seem that there's no EDID block available in the failing kernel. > How can we identify the VBE version? If vesafb works, then it is at least VBE 2.0. To confirm, you can use X + the 'vesa' driver and check /var/log/X*.log. Tony - 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] net/sched: mark "NET_CLS_RSVP6 depends on IPV6"
Denis Cheng wrote: > Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> > --- > net/sched/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/net/sched/Kconfig b/net/sched/Kconfig > index 8a74cac..5d3749c 100644 > --- a/net/sched/Kconfig > +++ b/net/sched/Kconfig > @@ -300,6 +300,7 @@ config NET_CLS_RSVP > config NET_CLS_RSVP6 > tristate "IPv6 Resource Reservation Protocol (RSVP6)" > select NET_CLS > + depends on IPV6 > ---help--- > The Resource Reservation Protocol (RSVP) permits end systems to > request a minimum and maximum data flow rate for a connection; this I thought the same but ... see http://marc.info/?l=linux-kernel=118440958516205=2 http://marc.info/?l=linux-netdev=118442747709230=2 Regards, Gabriel - 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: "Add support for vector domain" breaks boot on x355
2007-07-31 (火) の 15:13 -0700 に Nishanth Aravamudan さんは書きました: > The following commit (4994be1b3fe9120c88022ff5c0c33f6312b17adb) broke > Linus' Tree between 2.6.22-git15 and 2.6.22-git16 on a 2-node 8-way x455 > (Madison procs). Thanks to Ryan Hodges for bisecting down to this > commit. Thank you for reporting. I think this problem might be fixed by the commit 6ffbc82351c62aeb9e817ddf93049353493d. Could you try that? Thanks, Kenji Kaneshige - 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: [RESEND] [BUG] futex_unlock_pi() hurts my brain and may cause application deadlock
From: john stultz <[EMAIL PROTECTED]> Date: Tue, 31 Jul 2007 16:53:39 -0700 > I sent this fix for this back in the 2.6.21-rt9 era, and I thought to > picked it up, but I think it arrived amid some futex churn and > apparently has been dropped or was just lost. > > Some of our testers have been reporting futex deadlocks and this fix > resolves it, so I believe it to still be needed. This bug seems to exist in mainline too. Sparc users have been seeing something that smells like this bug, I will ask them to test this fix out. - 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] net/sched: mark "NET_CLS_RSVP6 depends on IPV6"
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]> --- net/sched/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/sched/Kconfig b/net/sched/Kconfig index 8a74cac..5d3749c 100644 --- a/net/sched/Kconfig +++ b/net/sched/Kconfig @@ -300,6 +300,7 @@ config NET_CLS_RSVP config NET_CLS_RSVP6 tristate "IPv6 Resource Reservation Protocol (RSVP6)" select NET_CLS + depends on IPV6 ---help--- The Resource Reservation Protocol (RSVP) permits end systems to request a minimum and maximum data flow rate for a connection; this -- 1.5.2.2 - 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 check do_direct_IO() return val
> Does a patch like this work? I don't have any test-cases, but it would be > good to have something like this tested and passed back with proper > explanations and sign-offs. Yes it work find after apply the patch, thanks. Joe - 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: [GIT PATCH] ACPI patches for 2.6.23-rc1
On 7/28/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: > Andreas Schwab wrote: > > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Len Brown wrote: > >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a > >> modulo of the size of section __mod_acpi_device_table=144. > > Are you cross-compiling? The definition of kernel_ulong_t won't work on > > x86. > Yes, sorry, should have mentioned that. Build system is x86. Still, > it didn't happen before the recent acpi merge. I also have the same error, which I didn't have in 2.6.22: FATAL: drivers/acpi/ac: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=48. Fix definition of struct acpi_device_id in mod_devicetable.h make[1]: *** [__modpost] Error 1 Build system is x86_64. I'm not cross-compiling, as the target machine (not the build machine) is also x86_64. - Yasha - 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: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
On Tue, 2007-07-31 at 13:04 +0200, Pavel Machek wrote: > Hi! > > > 3. Boot kernel compiled for normal usage, the reserved crash kernel > >memory region must be added to kernel command line as following: > > > >crashkernel=M@M > > > >Where, should be replaced by the real memory size and > > position. > > I used [EMAIL PROTECTED] . > > > > 4. Load kernel compiled for hibernating usage as a crashdump kernel > >with kexec, the same kernel as that of 3 can be used if > >CONFIG_RELOCATABLE=y is selected. The kernel command line option as > >following must be appended to kernel command line. > > > >kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn` > > > >For example, the shell command line can be as follow: > > > >kexec -p /boot/vmlinux --args-linux --append="root=/dev/hdb signal > >kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`" > > I think I followed the instructions closely. Now I'm trying to do > > kexec -p /data/l/linux/vmlinux --args-linux --append="init=/bin/bash > kexec_jump_buf_pfn=`cat /sys/kernel/kexec_jump_buf_pfn`" > > but it tells me: > > Invalid memory segment 0x10 - 0x7a0fff > > (and nothing in dmesg) > > If I try to load bzImage (corresponding to vmlinux I tried to use), I > get: > > [EMAIL PROTECTED]:~# kexec -p /data/l/linux/arch/i386/boot/bzImage > --append="init=/bin/bash kexec_jump_buf_pfn=`cat > /sys/kernel/kexec_jump_buf_pfn`" > Could not find a free area of memory of 9000 bytes... > locate_hole failed > [EMAIL PROTECTED]:~# > > What am I doing wrong? The kexec-tools version 1.101 does not work perfectly with relocatable kernel. This would have been solved if I worked against kexec-tools testing tree. I will work against testing tree in the next version. But, with some trick, it can work. When configure kernel, make sure the following option is set: CONFIG_PHYSICAL_START=0x400 # if crashkernel=[EMAIL PROTECTED] Best Regards, Huang Ying - 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: inotify and /proc/
On Mon, 30 Jul 2007 22:56:27 CDT, Joseph Pingenot said: > From Al Viro on Tuesday, 31 July, 2007: > >On Mon, Jul 30, 2007 at 10:40:59PM -0500, Joseph Pingenot wrote: > >> I'm trying to implement pwait. It blocks until a specified PID exits, > >> and then it exits. > >er... ptrace(2)? > > Should work for most common usage scenarios, although will suspect that it > won't for for processes owned by another user (at least, I hope > it wouldn't). > > What is dangerous about inotify on a proc file? And if it's dangerous, should the inotify system call fail when trying to set the watch? Bailout with a -EBADIDEA or something? pgp33gMwjEtFq.pgp Description: PGP signature
[PATCH] Fix section mismatch warnings in sound/pci/hda/
This patch fixes the following section mismatch warnings in sound/pci/hda/* ... WARNING: vmlinux.o(.text+0x2d6a77): Section mismatch: reference to .init.text:snd_hda_add_new_ctls (between 'alc_build_controls' and 'alc662_auto_set_output_and_unmute') WARNING: vmlinux.o(.text+0x2d6aa1): Section mismatch: reference to .init.text:snd_hda_create_spdif_in_ctls (between 'alc_build_controls' and 'alc662_auto_set_output_and_unmute') WARNING: vmlinux.o(.text+0x2d6abd): Section mismatch: reference to .init.text:snd_hda_create_spdif_out_ctls (between 'alc_build_controls' and 'alc662_auto_set_output_and_unmute') WARNING: vmlinux.o(.text+0x2d994a): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'alc880_parse_auto_config' and 'alc882_gpio_mute') WARNING: vmlinux.o(.text+0x2da2fe): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc268' and 'patch_alc662') WARNING: vmlinux.o(.text+0x2da31c): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_alc268' and 'patch_alc662') WARNING: vmlinux.o(.text+0x2da6e8): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc662' and 'alc_mux_enum_info') WARNING: vmlinux.o(.text+0x2da7b5): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_alc662' and 'alc_mux_enum_info') WARNING: vmlinux.o(.text+0x2dae6a): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc880' and 'patch_alc260') WARNING: vmlinux.o(.text+0x2db036): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc260' and 'patch_alc882') WARNING: vmlinux.o(.text+0x2db0cc): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_alc260' and 'patch_alc882') WARNING: vmlinux.o(.text+0x2db4b0): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc882' and 'patch_alc883') WARNING: vmlinux.o(.text+0x2db77a): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc883' and 'patch_alc262') WARNING: vmlinux.o(.text+0x2db8ea): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc262' and 'patch_alc861') WARNING: vmlinux.o(.text+0x2db9b7): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_alc262' and 'patch_alc861') WARNING: vmlinux.o(.text+0x2dbca6): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc861' and 'patch_alc861vd') WARNING: vmlinux.o(.text+0x2dbd3c): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_alc861' and 'patch_alc861vd') WARNING: vmlinux.o(.text+0x2dc0c6): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_alc861vd' and 'cmi9880_build_pcms') WARNING: vmlinux.o(.text+0x2dc195): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_alc861vd' and 'cmi9880_build_pcms') WARNING: vmlinux.o(.text+0x2dc77d): Section mismatch: reference to .init.text:snd_hda_add_new_ctls (between 'cmi9880_build_controls' and 'cmi_ch_mode_put') WARNING: vmlinux.o(.text+0x2dc796): Section mismatch: reference to .init.text:snd_hda_add_new_ctls (between 'cmi9880_build_controls' and 'cmi_ch_mode_put') WARNING: vmlinux.o(.text+0x2dc7c6): Section mismatch: reference to .init.text:snd_hda_create_spdif_in_ctls (between 'cmi9880_build_controls' and 'cmi_ch_mode_put') WARNING: vmlinux.o(.text+0x2dc7e6): Section mismatch: reference to .init.text:snd_hda_create_spdif_out_ctls (between 'cmi9880_build_controls' and 'cmi_ch_mode_put') WARNING: vmlinux.o(.text+0x2dc93e): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_cmi9880' and 'cmi_mux_enum_get') WARNING: vmlinux.o(.text+0x2dcab4): Section mismatch: reference to .init.text:snd_hda_parse_pin_def_config (between 'patch_cmi9880' and 'cmi_mux_enum_get') WARNING: vmlinux.o(.text+0x2dd301): Section mismatch: reference to .init.text:snd_hda_add_new_ctls (between 'ad198x_build_controls' and 'ad1988_laptop_unsol_event') WARNING: vmlinux.o(.text+0x2dd32b): Section mismatch: reference to .init.text:snd_hda_create_spdif_in_ctls (between 'ad198x_build_controls' and 'ad1988_laptop_unsol_event') WARNING: vmlinux.o(.text+0x2dd347): Section mismatch: reference to .init.text:snd_hda_create_spdif_out_ctls (between 'ad198x_build_controls' and 'ad1988_laptop_unsol_event') WARNING: vmlinux.o(.text+0x2ddbad): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_ad1984' and 'patch_ad1882') WARNING: vmlinux.o(.text+0x2ddcfb): Section mismatch: reference to .init.text:snd_hda_check_board_config (between 'patch_ad1882' and 'ad198x_free') WARNING: vmlinux.o(.text+0x2de7db): Section mismatch: reference to .init.text:snd_hda_check_board_config (between
Re: [PATCH 1/7] Simple Performance Counters: Core Piece
Christoph Lameter <[EMAIL PROTECTED]> writes: > Simple performance counters are a way to measure the performance on > code paths in the Linux kernel. Code must be instrumented with calls > that signal the start and the stop of a measurement. [...] For what it's worth, this kind of measurement widget could be usefully recast as a pure client of the lttng/systemtap markers that Mathieu is still working on. Instead of the custom pc_start/pc_stop functions, you would have generic markers to identify the start/end spots, and a bit of callback code to compute/export the statistics to procfs. - FChE - 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] direct IO submission and completion scalability issues
On Tue, Jul 31, 2007 at 05:55:13PM -0700, Suresh B wrote: > On Wed, Aug 01, 2007 at 02:41:18AM +0200, Nick Piggin wrote: > > On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote: > > > task by taking away some of its cpu time. With CFS micro accounting, > > > perhaps > > > we can track irq, softirq time and avoid penalizing the running task's cpu > > > time. > > > > But you "penalize" the running task in the completion handler as well > > anyway. > > Yes. > > Ingo, in general with CFS micro accounting, we should be able to avoid > penalizing the running task by tracking irq/softirq time. Isn't it? > > > Doing this with a SCHED_FIFO task is sort of like doing interrupt > > threading which AFAIK has not been accepted (yet). > > I am not recommending SCHED_FIFO. I will take a look at softirq > infrastructure for this. I think that would be a fine way to go. > > > This workload is using direct IO and there is no batching at the block > > > layer > > > for direct IO. IO is submitted to the HW as it arrives. > > > > So you aren't putting concurrent requests into the queue? Sounds like > > userspace should be improved. > > Nick remember that there are hundreds of disks in this setup and at > an instance, there will be max 1 or 2 requests per disk. Well if there is 2 requests per disk, that's a good thing; you won't need to unplug. If there is only 1, then as well as the plugging cost, the hardeware loses some ability to pipeline things effectively. I'm not saying the kernel shouldn't be improved in the latter case, but if you're looking for performance, it is nice to ensure you have at least 2 requests. Presumably you're using some pretty well tuned db software though, so I guess this is not always possible. Do you have stats for these things (queue empty vs not empty events, unplugs, etc)? > > > It is applicable for both direct IO and buffered IO. But the > > > implementations > > > will differ. For example in buffered IO, we can setup in such a way that > > > the > > > block plug timeout function runs on the IO completion cpu. > > > > It would be nice to be doing that anyway. But unplug via request submission > > rather than timeout is fairly common in buffered loads too. > > Ok. Currently the patch handles both direct and buffered IO. While making > improvements to this patch I will make sure that both the paths take > advantage of this. Sounds good! - 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] retrieve VBE EDID/DDC info independent of used video mode
Zwane Mwaikambo wrote: Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Here's the bug: http://bugs.gentoo.org/show_bug.cgi?id=181067 How can we identify the VBE version? Thanks, Daniel - 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: [PATH 0/1] Kexec jump - v2 - the first step to kexec based hibernation
On Tue, 2007-07-31 at 04:52 -0600, Eric W. Biederman wrote:
> "Huang, Ying" <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2007-07-31 at 11:10 +0200, Pavel Machek wrote:
> >> > Index: kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c
> >> > ===
> >> > --- kexec-tools-1.101.orig/kexec/arch/i386/crashdump-x86.c 2007-07-08
> > 23:00:25.0 +0800
> >> > +++ kexec-tools-1.101/kexec/arch/i386/crashdump-x86.c 2007-07-14
> > 17:06:45.0 +0800
> >> > @@ -428,6 +428,29 @@
> >> > return 0;
> >> > }
> >> >
> >> > +/* Adds the kexec_backup= command line parameter to command line. */
> >> > +static int cmdline_add_backup(char *cmdline, unsigned long addr)
> >> > +{
> >> > +int cmdlen, len, align = 1024;
> >> > +char str[30], *ptr;
> >> > +
> >> > +/* Passing in kexec_backup=xxxK format. Saves space required
> >> > + * in cmdline. Ensure 1K alignment*/
> >> > +if (addr%align)
> >> > +return -1;
> >> > +addr = addr/align;
> >> > +ptr = str;
> >> > +strcpy(str, " kexec_backup=");
> >> > +ptr += strlen(str);
> >> > +ultoa(addr, ptr);
> >> > +strcat(str, "K");
> >> > +len = strlen(str);
> >> > +cmdlen = strlen(cmdline) + len;
> >> > +if (cmdlen > (COMMAND_LINE_SIZE - 1))
> >> > +die("Command line overflow\n");
> >> > +strcat(cmdline, str);
> >> > +return 0;
> >> > +}
> >>
> >> This part did not apply for me -- it seems crashdump related and I did
> >> not have that applied. Is it critical?
> >
> > This is needed for kexec_jump to work properly. Which version of
> > kexec-tools do you use? This patch is against 1.101. The kdump patch
> > must be applied before this patch is applied.
>
> Please work against the kexec-tools-testing tree, if you can.
> All of the outstanding patches should be there.
OK, I will work against the kexec-tools-testing tree in the next
version.
Best Regards,
Huang Ying
-
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 60] drivers/net/wireless/prism54/oid_mgt.c: kmalloc + memset conversion to kzalloc
On 7/31/07, Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Acked-by: Luis R. Rodriguez <[EMAIL PROTECTED]>
> drivers/net/wireless/prism54/oid_mgt.c | 25377 -> 25297 (-80 bytes)
> drivers/net/wireless/prism54/oid_mgt.o | 128460 -> 128284 (-176 bytes)
>
> drivers/net/wireless/prism54/oid_mgt.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> --- linux-2.6.23-rc1-mm1-a/drivers/net/wireless/prism54/oid_mgt.c
> 2007-07-26 13:07:43.0 +0200
> +++ linux-2.6.23-rc1-mm1-b/drivers/net/wireless/prism54/oid_mgt.c
> 2007-07-30 00:27:44.0 +0200
> @@ -244,13 +244,11 @@ mgt_init(islpci_private *priv)
> /* Alloc the cache */
> for (i = 0; i < OID_NUM_LAST; i++) {
> if (isl_oid[i].flags & OID_FLAG_CACHED) {
> - priv->mib[i] = kmalloc(isl_oid[i].size *
> + priv->mib[i] = kzalloc(isl_oid[i].size *
>(isl_oid[i].range + 1),
>GFP_KERNEL);
> if (!priv->mib[i])
> return -ENOMEM;
> - memset(priv->mib[i], 0,
> - isl_oid[i].size * (isl_oid[i].range + 1));
> } else
> priv->mib[i] = NULL;
> }
>
-
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 PATCH] hwmon updates against ~v2.6.23-rc1-git8
Hi Linus: Please pull from: git://lm-sensors.org/kernel/mhoffman/hwmon-2.6.git release You'll get a handful of cleanups and bugfixes (including a couple that fix regressions since 2.6.22). The Macbook gets some additional sensors, and there's also one brand new driver, which has spent some time in the latest -mm. This patch series was also posted to the lm-sensors list yesterday: http://lists.lm-sensors.org/pipermail/lm-sensors/2007-July/020730.html Thanks & regards, Documentation/hwmon/adm1031 |4 +- Documentation/hwmon/thmc50 | 74 +++ drivers/hwmon/Kconfig| 10 + drivers/hwmon/Makefile |1 + drivers/hwmon/abituguru3.c |5 +- drivers/hwmon/ams/ams-core.c |1 - drivers/hwmon/applesmc.c | 14 +- drivers/hwmon/dme1737.c |2 +- drivers/hwmon/fscher.c |4 +- drivers/hwmon/it87.c |2 +- drivers/hwmon/lm78.c |2 +- drivers/hwmon/lm90.c |2 +- drivers/hwmon/lm93.c |2 +- drivers/hwmon/pc87360.c |2 +- drivers/hwmon/sis5595.c |2 +- drivers/hwmon/smsc47m1.c |2 +- drivers/hwmon/thmc50.c | 440 ++ drivers/hwmon/via686a.c |2 +- drivers/hwmon/vt8231.c |4 +- drivers/hwmon/w83627hf.c |2 +- 20 files changed, 554 insertions(+), 23 deletions(-) create mode 100644 Documentation/hwmon/thmc50 create mode 100644 drivers/hwmon/thmc50.c Adrian Bunk (1): hwmon: make abituguru3_read_increment_offset() static Guillaume Chazarain (1): hwmon: Fix regression caused by typo in lm90.c Hans de Goede (3): hwmon: fix lm78 detection regression hwmon: fscher control update bugfix hwmon: fscher read control bugfix Hans-Jürgen Koch (1): hwmon: fix array overruns in lm93.c Jean Delvare (2): hwmon: Add missing __devexit tags in various drivers hwmon: (adm1031) Fix broken links in documentation Jesper Juhl (1): hwmon: clean up duplicate includes Juerg Haefliger (1): hwmon: fix dme1737 temp fault attribute Krzysztof Helt (1): hwmon: add support for THMC50 and ADM1022 Martin Szulecki (1): hwmon: (applesmc) add temperature sensors set for Macbook -- Mark M. Hoffman [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 check do_direct_IO() return val
> Okay. Here is the fix for the problem. It work fine, thanks. > Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]> Acked-by: Joe Jin <[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 14/16] Remove needless kmalloc casts in the zd1211rw drivers.
Daniel Drake wrote:
> [EMAIL PROTECTED] wrote:
>> Signed-off-by: Jack Stone <[EMAIL PROTECTED]>
>>
>> CC: Daniel Drake <[EMAIL PROTECTED]>
>
> NAK: this patch adds a sparse warning
> zd_chip.c:116:15: warning: implicit cast to nocast type
What does this warning mean? a16 is defined as zd_addr_t *.
>> --- a/drivers/net/wireless/zd1211rw/zd_chip.c
>> +++ b/drivers/net/wireless/zd1211rw/zd_chip.c
>> @@ -115,7 +115,7 @@ int zd_ioread32v_locked(struct zd_chip *
>>
>> /* Allocate a single memory block for values and addresses. */
>> count16 = 2*count;
>> -a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) +
>> sizeof(u16)),
>> +a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
>> GFP_KERNEL);
>> if (!a16) {
>> dev_dbg_f(zd_chip_dev(chip),
>>
Also, why is there this cast right before that?
zd_addr_t *a16 = (zd_addr_t *)NULL;
--
Stefan Richter
-=-=-=== =--- =
http://arcgraph.de/sr/
-
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 01/16] Remove unnecessary kmalloc casts from the cris arch.
[EMAIL PROTECTED] wrote:
> --- a/arch/cris/arch-v32/mm/intmem.c
> +++ b/arch/cris/arch-v32/mm/intmem.c
> @@ -28,7 +28,7 @@ static void crisv32_intmem_init(void)
> static int initiated = 0;
> if (!initiated) {
> struct intmem_allocation* alloc =
> - (struct intmem_allocation*)kmalloc(sizeof *alloc, GFP_KERNEL);
> + kmalloc(sizeof *alloc, GFP_KERNEL);
> INIT_LIST_HEAD(_allocations);
> intmem_virtual = ioremap(MEM_INTMEM_START, MEM_INTMEM_SIZE);
> initiated = 1;
>
Would be nice if you increased the indentation of the kmalloc line for
better readability, now that the expression is shorter.
In the rest of arch/cris/arch-v32/mm/intmem.c, one tab is typically used
for such continuation indentations. However, intmem.c is not a prime
example for good whitespace usage, so you could as well use two tabs.
Also note that there are two more kmallocs with unnecessary cast in the
same file, at least in 2.6.23-rc1. Would be nice if you cleaned up the
whole file at once.
There is also a shadowing of a local variable (tmp) by another local
variable of the same name. Maybe you could submit another cleanup patch
for that too while you are at it?
--
Stefan Richter
-=-=-=== =--- =
http://arcgraph.de/sr/
-
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: IRQ Delivery Problem for MCP65
--- Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > > --- Craig Block <[EMAIL PROTECTED]> wrote: > > I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X > > motherboard with an MCP65 (nForce 520) chipset. When the kernel probes the > > AHCI controllers, it hangs for a minute or so on each one and returns the > > following; > > > > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) > > I googled for some more info about similar issues and found very similar > problem being discussed on Gentoo forum: > > The important part is here: > > "when I disabled Message Signaled Interrupts (MSI and MSI-X) under "Bus > Options" in the kernel, the problem magically went away (disabling MSI)" > > which indicates IRQ routing problems (as suspected from dmesg output and also > stated by Tejun). Have you already tried disabling MSI IRQs with "pci=nomsi" > (not "nomsi") or even completely disabling CONFIG_PCI_MSI support? Thanks a ton, building the kernel with PCI_MSI not set did the trick. Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate the problem. I had to build the kernel without MSI support. There's a few interesting differences in the dmesg output with "PCI_MSI=y" and PCI_MSI not set; With PCI_MSI not set; ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x bmdma 0x irq 5 ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x bmdma 0x irq 5 ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x bmdma 0x irq 5 ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x bmdma 0x irq 5 With PCI_MSI=y; ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x bmdma 0x irq 219 ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x bmdma 0x irq 219 ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x bmdma 0x irq 219 ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x bmdma 0x irq 219 Also, there's a spurous interrupt message that appears with PCI_MSI=y; spurious 8259A interrupt: IRQ7. I attached the two dmesg instances for reference. - Craig Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting 6896k available (1556k kernel code, 24352k reserved, 545k data, 168k init, 1179392k highmem) virtual kernel memory layout: fixmap : 0xfffaf000 - 0xf000 ( 320 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc031 - 0xc033a000 ( 168 kB) .data : 0xc0285011 - 0xc030d70c ( 545 kB) .text : 0xc010 - 0xc0285011 (1556 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4824.67 BogoMIPS (lpj=2412339) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff ebd3fbff 2001 011d CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After all inits, caps: 078bfbff ebd3fbff 0410 2001 011d Compat vDSO mapped to e000. CPU: AMD Athlon(tm) 64 Processor 3800+ stepping 01 Checking 'hlt' instruction... OK. ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 NET: Registered protocol family 16 PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized libata version 2.21 loaded. PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Transparent bridge - :00:08.0 PCI: Using IRQ router default [10de/0441] at :00:01.0 PCI->APIC IRQ transform: :00:01.1[A] -> IRQ 10 PCI->APIC IRQ transform: :00:02.0[A] -> IRQ 11 PCI->APIC IRQ transform: :00:02.1[B] -> IRQ 10 PCI->APIC IRQ transform: :00:07.0[B] -> IRQ 11 PCI->APIC IRQ transform: :00:0a.0[A] -> IRQ 5 PCI->APIC IRQ transform: :01:08.0[A] -> IRQ 11 PCI->APIC IRQ transform: :04:00.0[A] -> IRQ 11 PCI: Bridge: :00:08.0 IO window: d000-dfff MEM window: dbf0-dbff Time: tsc clocksource has been installed. PREFETCH window: 8800-880f PCI: Bridge: :00:0b.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:0c.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:0d.0 IO window: e000-efff MEM window: dc00-dfff PREFETCH window: c000-cfff PCI: Bridge: :00:0e.0 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Setting latency timer of device :00:08.0 to 64 PCI: Setting latency timer of device :00:0b.0 to 64 PCI: Setting latency timer of device
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 19:58 -0400, Daniel Drake wrote: > Hi, > > H. Peter Anvin wrote: > >> So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are > >> further patches needed? > >> > > > > It should, yes. > > It didn't work, and the bug still exists in 2.6.23-rc1: the resolution > is wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. > > So far the only known working setups since 2.6.20.11 are: > 1. Zwane's patch reverted > 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works > for 2.6.23) > > Here is dmesg output from 2.6.23: > http://bugs.gentoo.org/attachment.cgi?id=126203=view > The dmesg ouput did show that intelfb was not able to acquire the EDID from the BIOS, even if CONFIG_FIRMWARE_EDID=y I presume. I don't think it's the VBE version, the chipset is an Intel 830 which should at least be a VBE 2.0. Is it the same for the working kernel? Do you have a link to the dmesg ouput of a working kernel, if possible with #define DEBUG in drivers/video/fbmon.c. The output of read-edid or /var/log/X?.log will also be helpful. Tony - 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: [OOPS] 2.6.23-rc1 Seems to be network related
On Wed, 1 Aug 2007 02:57:48 +0200 Bongani Hlope <[EMAIL PROTECTED]> wrote: > I'm not sure if the first email went through, resending without .config > attachment. It did come through, and I replied ;) The below post-2.6.23-rc1 patch should fix it. commit b8c1c5da1520977cb55a358f20fc09567d40cad9 Author: Andrew Morton <[EMAIL PROTECTED]> Date: Tue Jul 24 12:02:40 2007 -0700 slab: correctly handle __GFP_ZERO Use the correct local variable when calling into the page allocator. Local `flags' can have __GFP_ZERO set, which causes us to pass __GFP_ZERO into the page allocator, possibly from illegal contexts. The page allocator will later do prep_zero_page()->kmap_atomic(..., KM_USER0) from irq contexts and will then go BUG. Cc: Mike Galbraith <[EMAIL PROTECTED]> Acked-by: Christoph Lameter <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> diff --git a/mm/slab.c b/mm/slab.c index bde271c..a684778 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2776,7 +2776,7 @@ static int cache_grow(struct kmem_cache * 'nodeid'. */ if (!objp) - objp = kmem_getpages(cachep, flags, nodeid); + objp = kmem_getpages(cachep, local_flags, nodeid); if (!objp) goto failed; - 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] direct IO submission and completion scalability issues
On Wed, Aug 01, 2007 at 02:41:18AM +0200, Nick Piggin wrote: > On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote: > > Yes, softirq context is one way. But just didn't want to penalize the > > running > > task by taking away some of its cpu time. With CFS micro accounting, perhaps > > we can track irq, softirq time and avoid penalizing the running task's cpu > > time. > > But you "penalize" the running task in the completion handler as well > anyway. Yes. Ingo, in general with CFS micro accounting, we should be able to avoid penalizing the running task by tracking irq/softirq time. Isn't it? > Doing this with a SCHED_FIFO task is sort of like doing interrupt > threading which AFAIK has not been accepted (yet). I am not recommending SCHED_FIFO. I will take a look at softirq infrastructure for this. > > This workload is using direct IO and there is no batching at the block layer > > for direct IO. IO is submitted to the HW as it arrives. > > So you aren't putting concurrent requests into the queue? Sounds like > userspace should be improved. Nick remember that there are hundreds of disks in this setup and at an instance, there will be max 1 or 2 requests per disk. > > It is applicable for both direct IO and buffered IO. But the implementations > > will differ. For example in buffered IO, we can setup in such a way that the > > block plug timeout function runs on the IO completion cpu. > > It would be nice to be doing that anyway. But unplug via request submission > rather than timeout is fairly common in buffered loads too. Ok. Currently the patch handles both direct and buffered IO. While making improvements to this patch I will make sure that both the paths take advantage of this. thanks, suresh - 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/
[OOPS] 2.6.23-rc1 Seems to be network related
Hi I'm not sure if the first email went through, resending without .config attachment. I got this partial Oops on my work laptop (DELL D800), while using the linux 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and this is the first and only time it did not boot. It was around the time it should have been trying to connect to my linksys wireless router (which has been working fine everyday since the 2.6.23-rc1 kernel was released). I copied what was on screen by hand, so some info is missing. I don't know how to reproduce it. Call Trace: [] show_trace_log_lvl+0x1a/0x2f [] show_stack_log_lvl+0x9b/0xa3 [] show_registers+0x1c2/0x2db [] die+0x02/0x1de [] do_trap+0x89/0xa2 [] do_invalid_op+0x88/0x92 [] error_code+0x6a/0x70 [] kmap_atomic+0xe/0x10 [] get_page_from_freelist+0x24c/0x3... [] __alloc_pages+0x53/0x27d [] kmem_cache_alloc+0x32/0x68 [] dst_alloc+0x28/0x60 [] ip_route_input+0x9b9/0xbba [] arp_process+0x155/0x4e1 [] arp_rcv+0xe9/0xfd [] netif_receive_skb+0x16e/0x1eb [] process_backlog+0x71/0xda [] net_rx_action+0x56/0xee [] __do_softirq+0x38/0x7a [] do_soft_irq+0x41/0x91 [] irq_exit+0x2c/0x66 [] do_IRQ+0xb7/0xcd [] common_interrupt+0x23/0x28 [] handle_mm_fault+0x1fe/0x57e [] error_code+0x6a/0x70 === EIP: [] kmap_atomic_prot+0x27/0x8.. Linux bongani_nb 2.6.23-rc1 #4 PREEMPT Mon Jul 23 12:11:40 SAST 2007 i686 Intel(R) Pentium(R) M processor 1600MHz GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.9 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.39 pcmciautils014 PPP2.4.4 Linux C Library> libc.2.4 Dynamic linker (ldd) 2.4 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 106 wireless-tools 28 Modules Loaded tg3 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd soundcore video output thermal sbs processor fan container button battery ac pcmcia yenta_socket rsrc_nonstatic pcmcia_core intel_agp hidp nvram rfcomm l2cap ipw2100 ieee80211 ieee80211_crypt usbhid hci_usb bluetooth ohci1394 ieee1394 ehci_hcd uhci_hcd joydev evdev I'm sorry I can't provide more info, this is completely random and it's the first time it ever happened. - 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 05/16] Remove unnecessary kmalloc casts in the drivers subdirectory.
[EMAIL PROTECTED] wrote:
> --- a/drivers/char/tty_io.c
> +++ b/drivers/char/tty_io.c
> @@ -2034,7 +2034,7 @@ static int init_dev(struct tty_driver *d
> }
>
> if (!*tp_loc) {
> - tp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
> + tp = kmalloc(sizeof(struct ktermios),
> GFP_KERNEL);
> if (!tp)
> goto free_mem_out;
>
Looks like you can pull the "GFP_KERNEL);" into the same line as the
kmalloc. IMO a cleanup patch shouldn't leave inexplicable linebreaks
and other whitespace strangeness behind.
--
Stefan Richter
-=-=-=== =--- =
http://arcgraph.de/sr/
-
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: garmin_gps not working with etrex vista cx
On Tue, 31 Jul 2007 10:44:39 -0400 Neal Becker <[EMAIL PROTECTED]> wrote: > I can't seem to transfer routes to my garmin etrex vista cx. I get > (repeatably) truncated routes, and: > Jul 31 07:19:07 nbecker4 kernel: usb 2-2: reset full speed USB device using > ohci_hcd and address 3 > Jul 31 07:24:05 nbecker4 kernel: usb 2-2: reset full speed USB device using > ohci_hcd and address 3 > Jul 31 07:26:04 nbecker4 last message repeated 3 times > ... > > The problem must be the kernel driver, because I can d/l the same file using > windoze without problems. > > Jul 31 07:13:18 nbecker4 kernel: garmin_gps 2-2:1.0: Garmin GPS usb/tty > converter detected > Which kernel version are you using? Did any earlier kernel version work correctly? (Use verizon vznavigator instead - it's kewl ;)) - 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: Question: Scheduler 'Exit' or modularization of scheduler?
Paul Robinson, Solaris's SunOS SVR4.x has a modular schedular / dispatcher, however, I believe that the time share dispatcher is actually a frozen-base and is not replaceable. I do believe that some of its scheduling characteristics are modifyable. IT is my understanding that CFS is the new schedular, however it is separated from the RT (real-time) FIFO and RR schedular. Currently, I have a initial suggestion to lkma to see if their is any support of a interactive task class. It allows a root user to classify a set of tasks as interactive. If their is acceptance, I plan to propose a patch/ set of changes to support this new task class by the end of Aug. IFF, then maybe in the future... Paul Robinson, if you feel that you are up to the task of modularizing the schedular / dispatcher to do what you think should be done, I would suggest submitting a prototype to Ingo, et al and see what the response is.. Mitchell Erblich Paul Robinson wrote: > > There has been a considerable amount of talk and many news articles on > some websites because of the inclusion of the CFS scheduler either as a > replacement for the old scheduler or instead of using the SD scheduler, > some people apparently feel that one or the other of these is not right > in some contexts or in some environments. I'm not completely clear on > what is going on or exactly what the complaint is. But I personally > would like to try to toss in my 0.02 Euro in an attempt to offer some > light and less heat to the dilemma and offer a suggestion. > > If my ignorance of the subject is too obvious, please excuse me, I might > not have that much experience in the subject. I've only been > programming for 27 years and I hope to get better at it with more practice. > > So, there are two questions about which I am wondering. They may be > somewhat related but the methodology for each are different and the > method of implementation would be different. > > 1. Could it be possible to design the interface to the scheduler either > that there is an 'exit' (my mainframe history precedes me) in which one > can issue a monitor call such that the system changes to an alternate > scheduler, possibly as part of the boot process? Thus there might be a > default scheduler but it is possible to invoke an alternative one. > > 2. Could the scheduler be such that it be designed as a system loadable > module rather than as a monolithic part of the code, such that the > particular scheduler is a specific file and is simply installed at boot > time, and if someone wants a different scheduler, they can simply create > a new one, rename the existing one to something else, name theirs to > whatever the scheduler's name is, then shutdown and reboot the machine? > > I am thinking that the system scheduler is an integral part of a > time-shared operating system, it would be memory resident while the > machine is operating, thus it only has to be on disk during start up and > is not in use while the system is in normal operation and could be > replaced at any time (subject to the usual caveat that the system has to > be shutdown and rebooted to cause the scheduling mechanism to be changed > to the new one.). > > If such a capacity were available, or perhaps if such capacity can be > implemented at some point in the future, this would solve one of the > more critical issues, since people needing more finely tuned scheduling > facilities can use one different from the common one, or 'roll their > own' if they need something really special. > > I am also thinking this sort of a capacity would be extremely useful > either in virtualization issues, in running other operating systems (or > copies of Linux) as guest operating systems under Linux vis-a-vis Xen, > or in respect to real-time versions of Linux, such that if someone needs > to grant certain processes high priority, and the rest everything that's > left over, then they could do that simply by writing the scheduler to > the interface definition. > > Of course, I could be completely wrong on this point and this is not a > partitionable feature, that it's not possible to have the job scheduler > loaded from a secondary module at boot time. (This may be one of the > reasons why there have been problems with non-monolithic kernels being > unavailable for general use except in extremely limited cases.) > > Or I could be wrong in that this issue isn't that important and most of > the noise over the issue is a small and vocal minority complaining about > a marginal and unimportant issue. Of course, this sort of situation is > probably the case with 90% of all traffic on usenet, newsgroups and > mailing lists, so what else is new? > > Or, and this is the big one, that this feature already exists in the > Linux kernel and the
Re: [REGRESSION] tg3 dead after s2ram
On Tue, 31 Jul 2007 11:28:32 +0200 "Joachim Deguara" <[EMAIL PROTECTED]> wrote: > On my Acer Ferrari 1000 the tg3 ethernet no longer is available after a > suspend to ram with the latet 2.6.23-rc1-git9. Thanks. cc's added, body retained.. > The tg3 works fine with s2ram > in 2.6.22.1. The tell tail signs that is dead is this message from the > kernel log: > > [6.754133] tg3: eth0: No firmware running. > [6.816140] tg3: tg3_load_tso_firmware fails for eth0 to set CPU PC, is > should be 0001 > [7.285797] ACPI: EC: Handler for query 0x80 is not found! > [8.016223] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not > clear MAC_TX_MODE= > > and trying to bring the link up resuls in: > > # ifconfig eth0 up > SIOCSIFFLAGS: No such device > > Full kernel log follows. > > -Joachim > > [0.00] Linux version 2.6.23-rc1-git9 ([EMAIL PROTECTED]) (gcc version > 4.2.1 20070705 (prerelease) (SUSE Linux)) #13 SMP PREEMPT Tue Jul 31 11:15:02 > CEST 2007 > [0.00] Command line: > root=/dev/disk/by-id/scsi-SATA_Hitachi_HTS5416_SB2404SJHNT7YE-part6 > sysrq_always_enable resume=/dev/sda5 splash=silent showopts > [0.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: - 0009dc00 (usable) > [0.00] BIOS-e820: 0009dc00 - 000a (reserved) > [0.00] BIOS-e820: 000d - 0010 (reserved) > [0.00] BIOS-e820: 0010 - 7be8 (usable) > [0.00] BIOS-e820: 7be8 - 7be95000 (ACPI data) > [0.00] BIOS-e820: 7be95000 - 7bf0 (ACPI NVS) > [0.00] BIOS-e820: 7bf0 - 8000 (reserved) > [0.00] BIOS-e820: e000 - f000 (reserved) > [0.00] BIOS-e820: fec0 - fec1 (reserved) > [0.00] BIOS-e820: fee0 - fee01000 (reserved) > [0.00] BIOS-e820: fff8 - 0001 (reserved) > [0.00] Entering add_active_range(0, 0, 157) 0 entries of 3200 used > [0.00] Entering add_active_range(0, 256, 507520) 1 entries of 3200 > used > [0.00] end_pfn_map = 1048576 > [0.00] DMI present. > [0.00] ACPI: RSDP 000F81A0, 0014 (r0 PTLTD ) > [0.00] ACPI: RSDT 7BE8D65C, 003C (r1 ACRSYS ACRPRDCT 604 LTP > > 0) > [0.00] ACPI: FACP 7BE94B9A, 0074 (r1 ATIBowfin604 ATI > F4240) > [0.00] ACPI: DSDT 7BE8D698, 7502 (r1ATISB460 604 MSFT > 202) > [0.00] ACPI: FACS 7BE95FC0, 0040 > [0.00] ACPI: SSDT 7BE94C0E, 01C4 (r1 PTLTD POWERNOW 604 LTP > > 1) > [0.00] ACPI: APIC 7BE94DD2, 0054 (r1 PTLTD APIC604 LTP > > 0) > [0.00] ACPI: MCFG 7BE94E26, 003C (r1 PTLTDMCFG604 LTP > > 0) > [0.00] ACPI: BOOT 7BE94E62, 0028 (r1 PTLTD $SBFTBL$ 604 LTP > > 1) > [0.00] ACPI: SLIC 7BE94E8A, 0176 (r1 ACRSYS ACRPRDCT 604 acer > > 0) > [0.00] Scanning NUMA topology in Northbridge 24 > [0.00] CPU has 2 num_cores > [0.00] No NUMA configuration found > [0.00] Faking a node at -7be8 > [0.00] Entering add_active_range(0, 0, 157) 0 entries of 3200 used > [0.00] Entering add_active_range(0, 256, 507520) 1 entries of 3200 > used > [0.00] Bootmem setup node 0 -7be8 > [0.00] Zone PFN ranges: > [0.00] DMA 0 -> 4096 > [0.00] DMA324096 -> 1048576 > [0.00] Normal1048576 -> 1048576 > [0.00] Movable zone start PFN for each node > [0.00] early_node_map[2] active PFN ranges > [0.00] 0:0 -> 157 > [0.00] 0: 256 -> 507520 > [0.00] On node 0 totalpages: 507421 > [0.00] DMA zone: 56 pages used for memmap > [0.00] DMA zone: 1957 pages reserved > [0.00] DMA zone: 1984 pages, LIFO batch:0 > [0.00] DMA32 zone: 6882 pages used for memmap > [0.00] DMA32 zone: 496542 pages, LIFO batch:31 > [0.00] Normal zone: 0 pages used for memmap > [0.00] Movable zone: 0 pages used for memmap > [0.00] ATI board detected. Disabling timer routing over 8254. > [0.00] ACPI: PM-Timer IO Port: 0x8008 > [0.00] ACPI: Local APIC address 0xfee0 > [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > [0.00] Processor #0 (Bootup-CPU) > [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) > [0.00] Processor #1 > [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) > [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) > [
Re: Update: ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not:
Quoting Len Brown ([EMAIL PROTECTED]): > Also, please test with CONFIG_X86_ACPI_CPUFREQ=n > to remove the acpi-cpufreq driver (and thus this patch) > from your kernel. If it still fails, then we know > that this driver (and this patch) are not related > to the failure. It wasn't enabled in any of the kernels i ran: # grep X86_ACPI ../configs/config* ../configs/config-2.6.22-git14-c3-via5000-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.22-git17-c3-via5000-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-git5:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-git6:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-git9:# CONFIG_X86_ACPI_CPUFREQ is not set ../configs/config-2.6.23-rc1-mm1-c3-firewall:# CONFIG_X86_ACPI_CPUFREQ is not set > Hmmm, okay, the "big hammer" works. Please see > if any of these smaller hammers work: > > pnpacpi=off > acpi=noirq > notsc _none_ of these options will work. The machine locks up solid. And that's what i'm the most surprised about. The last time i withnessed a solid kernel lockup without any panic/notification is _years_ ago. I also tried a kernel without "CPU Frequency scaling", so it is not the scaling up/down in Mhz of the cpu. I've even just compiled/run a kernel with libata and even that one still locks up. New round of git bisects i guess (this time powercycle instead of reboot and wait few hours before ginving it "bisect good" ) Will report back. Danny -- - 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: inotify and /proc/
On Tue, 31 Jul 2007 20:31:49 +0200 Diego Calleja <[EMAIL PROTECTED]> wrote: > El Mon, 30 Jul 2007 22:25:21 -0500, Joseph Pingenot <[EMAIL PROTECTED]> > escribió: > > > More background, please? > > > > What's the way to check for a process exiting without spinning? > > > I don't know if it's useful for you, but CONFIG_CONNECTOR and > CONFIG_PROC_EVENTS > will report process creation/exit/fork/etc through a netlink interface. yup. See example code in Documentation/accounting/getdelays.c - 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] direct IO submission and completion scalability issues
On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote: > On Tue, Jul 31, 2007 at 06:19:17AM +0200, Nick Piggin wrote: > > On Mon, Jul 30, 2007 at 01:35:19PM -0700, Suresh B wrote: > > > So any suggestions for making this clean and acceptable to everyone? > > > > It is obviously a good idea to hand over the IO at the point which > > requires the least number of cachelines to be moved, and I think doing > > it in the block layer is right. Mostly you have to convince the block > > and driver maintainers I guess. > > Yes. Implementation is the challenging part I guess. > > > The scheduler really should be made interrupt-load aware anyway, so I > > don't have a problem with changing that; or scheduling kblockd at a > > higher priority, but I don't know if SCHED_FIFO is a good idea. Couldn't > > it be done in a softirq instead? > > Yes, softirq context is one way. But just didn't want to penalize the running > task by taking away some of its cpu time. With CFS micro accounting, perhaps > we can track irq, softirq time and avoid penalizing the running task's cpu > time. But you "penalize" the running task in the completion handler as well anyway. Doing this with a SCHED_FIFO task is sort of like doing interrupt threading which AFAIK has not been accepted (yet). > > Latency for IO migration could be the most difficult problem to solve > > really. You don't give much details of the workload, profiles, etc... I > > hope this is for a real world test? > > Improvement numbers quoted are from the OLTP database workload. We can look > into other workloads. > > > Can the locking be improved in simpler ways first? > > > > Just some random questions... > > > > It looks like the main source of cacheline bouncing you're eliminating > > is from the initial starting of IO from an empty queue (ie. unplug). > > From then on, the submission is driven by completion, right? > > > > Why is the queue allowed to go empty in the first place in an IO critical > > workload? > > This workload is using direct IO and there is no batching at the block layer > for direct IO. IO is submitted to the HW as it arrives. So you aren't putting concurrent requests into the queue? Sounds like userspace should be improved. > > Are you loading up each CPU with as many disks as it can possibly handle > > plus a few more? If so, is that realistic? (I honestly don't know). > > There is 3-4% iowait time in the system. So the cpu's are not 100% busy, > but there is quite a bit of direct IO going on. > > > You say that you'd like to do this for direct IO only, but if it is more > > efficient, why not for buffered IO as well? (or is it not more efficient > > for buffered IO? if not, why?) > > It is applicable for both direct IO and buffered IO. But the implementations > will differ. For example in buffered IO, we can setup in such a way that the > block plug timeout function runs on the IO completion cpu. It would be nice to be doing that anyway. But unplug via request submission rather than timeout is fairly common in buffered loads too. > > AFAIKS, you'd still have significant queue_lock contention from other > > CPUs inserting requests into the list? > > Correct. We have more potential to explore. Current implementation > is very elementary. > > > What IO scheduler are you using? I assume noop... > > yes. > > > as a crazy experiment, what happens if you create per-cpu request queues? > > or in other words, each kblockd thread catering multiple request queues > (perhaps one for each cpu or one for group of cpu's). > > softirq context and each kblockd thread handling multiple request queues will > lead to further improvements. - 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] RT: Add priority-queuing and priority-inheritance to workqueue infrastructure
The following workqueue related patch is a port of the original VFCIPI PI
patch I submitted earlier. There is still more work to be done to add the
"schedule_on_cpu()" type behavior, and even more if we want to use this as
part of KVM. But for now, this patch can stand alone so I thought I would
get it out there.
--
Mainline workqueues treat all requests the same. This patch prioritizes
requests in the queue based on the callers current rt_priority. It also
adds a priority-inheritance feature to avoid inversion.
Signed-off-by: Gregory Haskins <[EMAIL PROTECTED]>
---
include/linux/workqueue.h |2
kernel/workqueue.c| 198 +
2 files changed, 149 insertions(+), 51 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 925d898..ae740b6 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -28,6 +28,7 @@ struct work_struct {
#define WORK_STRUCT_WQ_DATA_MASK (~WORK_STRUCT_FLAG_MASK)
struct list_head entry;
work_func_t func;
+ int prio;
};
#define WORK_DATA_INIT() ATOMIC_LONG_INIT(0)
@@ -81,6 +82,7 @@ struct execute_work {
(_work)->data = (atomic_long_t) WORK_DATA_INIT(); \
INIT_LIST_HEAD(&(_work)->entry);\
PREPARE_WORK((_work), (_func)); \
+(_work)->prio = -1; \
} while (0)
#define INIT_DELAYED_WORK(_work, _func)\
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index e339c80..ecd5e01 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -14,6 +14,8 @@
* Theodore Ts'o <[EMAIL PROTECTED]>
*
* Made to use alloc_percpu by Christoph Lameter <[EMAIL PROTECTED]>.
+ *
+ * RT-queues and PI by Gregory Haskins <[EMAIL PROTECTED]>
*/
#include
@@ -36,6 +38,13 @@
#include
+/* Note: prio_array inspiration credit goes to the RT scheduler...*/
+struct prio_array {
+ DECLARE_BITMAP(bitmap, MAX_RT_PRIO+1); /* +1 bit for delimiter */
+ unsigned longcount;
+ struct list_head queue[MAX_RT_PRIO];
+};
+
/*
* The per-CPU workqueue (if single thread, we always use the first
* possible cpu).
@@ -45,6 +54,7 @@ struct cpu_workqueue_struct {
spinlock_t lock;
struct list_head worklist;
+ struct prio_array rt_worklist;
wait_queue_head_t more_work;
struct work_struct *current_work;
@@ -52,6 +62,7 @@ struct cpu_workqueue_struct {
struct task_struct *thread;
int run_depth; /* Detect run_workqueue() recursion depth */
+ int prio; /* -1 = normal priority, 0-99 = RT priority */
} cacheline_aligned;
/*
@@ -82,6 +93,94 @@ static cpumask_t cpu_singlethread_map __read_mostly;
*/
static cpumask_t cpu_populated_map __read_mostly;
+/*
+ *
+ * prio_array
+ *
+ */
+static void prio_array_init(struct prio_array *array)
+{
+ int i;
+
+ memset(array->bitmap, 0, sizeof(array->bitmap));
+ array->count = 0;
+
+ for (i=0; iqueue[i]);
+}
+
+static struct work_struct* prio_array_dequeue(struct prio_array *array)
+{
+ struct list_head *head;
+ struct work_struct *work;
+ int idx;
+
+ if (!array->count)
+ return NULL;
+
+ idx = sched_find_first_bit(array->bitmap);
+
+ head = array->queue + idx;
+
+ /* If we got here, there better be something in the list */
+ BUG_ON(!head);
+ BUG_ON(list_empty(head));
+
+ work = list_first_entry(head, struct work_struct, entry);
+ BUG_ON(!work);
+
+ list_del_init(>entry);
+ array->count--;
+
+ if (list_empty(head))
+ __clear_bit(idx, >bitmap);
+
+ return work;
+}
+
+static void prio_array_enqueue(struct prio_array *array,
+ struct work_struct *work,
+ int prio, int tail)
+{
+ struct list_head *head;
+
+ BUG_ON(prio < 0);
+ BUG_ON(prio > MAX_RT_PRIO);
+
+ head = array->queue + prio;
+
+ if (tail)
+ list_add_tail(>entry, head);
+ else
+ list_add(>entry, head);
+
+ __set_bit(prio, >bitmap);
+ array->count++;
+}
+
+#define CWQ_DEFAULT_PRIO 1
+
+/* Assumes lock is held */
+static void wq_task_setprio(struct cpu_workqueue_struct *cwq, int prio)
+{
+ struct sched_param param = { 0, };
+ pid_t pid = cwq->thread->pid;
+
+ if (prio < CWQ_DEFAULT_PRIO)
+ prio = CWQ_DEFAULT_PRIO;
+
+ if (cwq->prio != prio) {
+ if (prio != -1) {
+ param.sched_priority = prio;
+
Re: [rfc] balance-on-fork NUMA placement
On Tue, Jul 31, 2007 at 11:14:08AM +0200, Andi Kleen wrote: > On Tuesday 31 July 2007 07:41, Nick Piggin wrote: > > > I haven't given this idea testing yet, but I just wanted to get some > > opinions on it first. NUMA placement still isn't ideal (eg. tasks with > > a memory policy will not do any placement, and process migrations of > > course will leave the memory behind...), but it does give a bit more > > chance for the memory controllers and interconnects to get evenly > > loaded. > > I didn't think slab honored mempolicies by default? > At least you seem to need to set special process flags. > > > NUMA balance-on-fork code is in a good position to allocate all of a new > > process's memory on a chosen node. However, it really only starts > > allocating on the correct node after the process starts running. > > > > task and thread structures, stack, mm_struct, vmas, page tables etc. are > > all allocated on the parent's node. > > The page tables should be only allocated when the process runs; except > for the PGD. We certainly used to copy all page tables on fork. Not any more, but we must still copy anonymous page tables. - 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] balance-on-fork NUMA placement
On Tue, Jul 31, 2007 at 10:01:14AM +0200, Ingo Molnar wrote: > > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > > This patch uses memory policies to attempt to improve this. It > > requires that we ask the scheduler to suggest the child's new CPU > > earlier in the fork, but that is not a fundamental difference. > > no fundamental objections, but i think we could simply move sched_fork() > to the following place: > > > @@ -989,10 +990,13 @@ static struct task_struct *copy_process( > > if (retval) > > goto fork_out; > > > > + cpu = sched_fork_suggest_cpu(clone_flags); > > + mpol_arg = mpol_prefer_cpu_start(cpu); > > + > > retval = -ENOMEM; > > p = dup_task_struct(current); > > if (!p) > > - goto fork_out; > > + goto fork_mpol; > > > > rt_mutex_init_task(p); > > > _after_ the dup_task_struct(). Then change sched_fork() to return a CPU > number - hence we dont have a separate sched_fork_suggest_cpu() > initialization function, only one, obvious sched_fork() function. > Agreed? That puts task struct, kernel stack, thread info on the wrong node. - 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] retrieve VBE EDID/DDC info independent of used video mode
Hi Daniel, On Tue, 31 Jul 2007, Daniel Drake wrote: > Hi, > > H. Peter Anvin wrote: > > > So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are > > > further patches needed? > > > > > > > It should, yes. > > It didn't work, and the bug still exists in 2.6.23-rc1: the resolution is > wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. > > So far the only known working setups since 2.6.20.11 are: > 1. Zwane's patch reverted > 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works for > 2.6.23) > > Here is dmesg output from 2.6.23: > http://bugs.gentoo.org/attachment.cgi?id=126203=view > > Let me know how we can help diagnose this further. Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Thanks, Zwane - 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 RT] Fix RT balancing tasks pulling
On Tue, 2007-07-31 at 13:48 +0200, Sébastien Dugué wrote: > On Mon, 30 Jul 2007 14:50:34 -0700 Josh Triplett <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-07-24 at 15:42 +0200, Sébastien Dugué wrote: > > > this one-liner fixes a bug in balance_rt_tasks() which sometimes > > > manifests by > > > having a lower prio task being scheduled while a higher prio task is > > > sitting > > > waiting on another runqueue. > > > > > > This is pretty hard to reproduce on low cpu count machines, for > > > example, I > > > had to have sched_football run in a loop for ~38h before it failed on a > > > dual HT > > > Xeon box. > > > > Very impressive find, and this does seem to improve things in some > > cases. > > > > However, with 2.6.22.1-rt8, which includes this patch, I still managed > > to get some failures after a few hours on an 8-way (quad dual-core) box. > > Preliminary results so far: > > 420 Final ball position: 0 > > 2 Final ball position: 1 > > > > Darn, I thought it was it :( > > I had a ~60h run on my box with the very same kernel without a single > failure. I think you really need a box with more processors to reproduce these problems in a reasonable timeframe. Happy to test any patches you have to fix RT balancing; please let me know. > Do you have any other user RT load running when those failures pop up? Other than sched_football, I had sshd, bash, and GNU screen, theoretically all 100% idle (no input to read and no output to display). - Josh Triplett - 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] flush icache before set_pte take6. [3/4] add montecito brand name
On Tue, 31 Jul 2007 09:39:58 -0700 "Luck, Tony" <[EMAIL PROTECTED]> wrote: > + } else if (family == 0x20) > + memcpy(brand, "Montecito", 10); > > NAK. > > We don't really have names for the different cpu families. "Montecito" > is definitely not the right string to apply here (Montvale will also > have family == 0x20). The old McKinley/Madison strings are intended > to provide some information for old processors where PAL did not > support PAL_BRAND_INFO. All new cpus (from Montecito onward) will > support this PAL call, so there should be no need to add more code to > make names out of [family,model] tuples. > Ok, please ignore patch [3/4] and [4/4]. -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: /proc/$pid/pagemap troubles
On Tue, Jul 31, 2007 at 03:43:10PM -0700, Dave Hansen wrote:
> On Tue, 2007-07-31 at 16:37 -0500, Matt Mackall wrote:
> >
> > > So, a couple of questions. Don't we need to support
> > non-sizeof(unsigned
> > > long)-aligned reads?
> >
> > Why? We should obviously never return more data than we were asked for
> > (that's clearly a bug), but lots of things refuse to read or write
> > stuff that isn't well sized and aligned.
>
> For the 1-byte stuff at the beginning of the file, I think it makes
> perfect sense:
>
> char __big_endian;
> int big_endian;
> read(fd, &__big_endian, 1);
> big_endian = __big_endian;
True.
> > > Do we _really_ need that header in each and every file?
> >
> > Well there's either a header or there isn't.
>
> I just mean that perhaps we should be putting some of that stuff in a
> global file. I think there's some added simplicity both in the kernel
> and in the userspace programs if we just let "*ppos << PAGE_SHIFT ==
> vaddr".
Absolutely. It's the source of both of the long read bugs you
mentioned. But there are also advantages to having it attached.
> I was going to send you a patch, but since you're updating anyway, could
> you add some symbolic names like this:
>
> #define PAGEMAP_ENTRY_SIZE_BYTESsizeof(unsigned long)
> #define PAGEMAP_HEADER_SIZE_BYTES sizeof(unsigned long)
> #define PAGEMAP_MAX_VIRT_PFN(((~0UL) >> PAGE_SHIFT) + 1)
> #define PAGEMAP_BUFFER_SLOTS (PAGE_SIZE/PAGEMAP_ENTRY_SIZE_BYTES)
> #define PAGEMAP_UNPOPULATED_PAGE (-1UL)
I suppose.
> + evpfn = min((src + count) / sizeof(unsigned long),
> + ((~0UL) >> PAGE_SHIFT) + 1);
>
> Should that hunk of code be any different for 32-bit processes on a
> 64-bit kernel? Do we want to use TASK_SIZE_OF() or restrict these to
> actual virtual address space (which is only 48 bits on x86_64).
No. A page for a 32-bit task can line anywhere in the >32-bit physical
address space.
> It also seems that we need some replacement for the CONFIG_HIGHPTE
> #ifdefs. What is the basic reason for those? The copy_to_user() called
> by add_to_pagemap()->flush_pagemap() conflicts with the kmap_atomic()
> from pte_offset_map()?
My not-yet-working code uses get_user_pages and does away with all the
double-buffering and a bunch of the locking issues.
> As I think about it, do we really even need to walk the VMA list at all?
> We don't do anything differently if an address is inside a VMA. We just
> save time by not walking the pagetables for areas that we know are
> zeroed. But, we won't be able to walk down to the PTE level in most
> cases, anyway. So, it probably won't waste _that_ much time.
Perhaps not.
> +struct pagemapread {
> + struct mm_struct *mm;
> + unsigned long next;
> + unsigned long *buf;
> + pte_t *ptebuf;
> + unsigned long pos;
> + size_t count;
> + int index;
> + char __user *out;
> +};
>
> Just looking at the structure, it's _really_ hard to tell what fields go
> with other fields, and it took me a while to unravel it all. There's
> also some redundancy in it, which I find a bit confusing.
Most of those go away with the get_user_pages approach.
--
Mathematics is the supreme nostalgia of our time.
-
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 09] drivers/char/consolemap.c: kmalloc + memset conversion to kzalloc
On Tue, 31 Jul 2007 19:08:28 +0200 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> Acked-by: Alan Cox <[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 55] drivers/char/n_hdlc.c: kmalloc + memset conversion to kzalloc
On Tue, 31 Jul 2007 23:27:30 +0200 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> NAK > - struct n_hdlc *n_hdlc = kmalloc(sizeof(*n_hdlc), GFP_KERNEL); > - > + struct n_hdlc *n_hdlc; > + > + n_hdlc = kzalloc(sizeof(*n_hdlc), GFP_KERNEL); Change looks fine but please keep the original formatting style - 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] atl1: use spin_trylock_irqsave()
From: Ingo Molnar <[EMAIL PROTECTED]>
use the simpler spin_trylock_irqsave() API to get the adapter lock.
[ this is also a fix for -rt where adapter->lock is a sleeping lock. ]
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
drivers/net/atl1/atl1_main.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 56f6389..3c1984e 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1704,10 +1704,8 @@ static int atl1_xmit_frame(struct sk_buff *skb, struct
net_device *netdev)
}
}
- local_irq_save(flags);
- if (!spin_trylock(>lock)) {
+ if (!spin_trylock_irqsave(>lock, flags)) {
/* Can't get lock - tell upper layer to requeue */
- local_irq_restore(flags);
dev_printk(KERN_DEBUG, >pdev->dev, "tx locked\n");
return NETDEV_TX_LOCKED;
}
--
1.5.2.2
-
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: [RESEND] [BUG] futex_unlock_pi() hurts my brain and may cause application deadlock
-- On Tue, 31 Jul 2007, john stultz wrote: > On Wed, 2007-05-30 at 17:49 -0700, john stultz wrote: > > Hey Ingo, > I sent this fix for this back in the 2.6.21-rt9 era, and I thought to > picked it up, but I think it arrived amid some futex churn and > apparently has been dropped or was just lost. > > Some of our testers have been reporting futex deadlocks and this fix > resolves it, so I believe it to still be needed. Heh, I remember this bug. Wasn't there another patch that modified this. I almost definitly remember this getting into the patch queue, but it must have been dropped later. John, thanks for looking into this deeper! Acked-by: Steven Rostedt <[EMAIL PROTECTED]> > > thanks > -john > > Avoid futex_unlock_pi returning -EFAULT (which results in deadlock), by > clearing uval before jumping to retry_locked. > > Signed-off-by: John Stultz <[EMAIL PROTECTED]> > Index: 2.6-rt/kernel/futex.c > === > --- 2.6-rt.orig/kernel/futex.c2007-07-31 16:48:41.0 -0700 > +++ 2.6-rt/kernel/futex.c 2007-07-31 16:48:48.0 -0700 > @@ -1673,6 +1673,7 @@ pi_faulted: >attempt); > if (ret) > goto out; > + uval = 0; > goto retry_unlocked; > } > > > > > - 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] retrieve VBE EDID/DDC info independent of used video mode
Hi, H. Peter Anvin wrote: So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are further patches needed? It should, yes. It didn't work, and the bug still exists in 2.6.23-rc1: the resolution is wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. So far the only known working setups since 2.6.20.11 are: 1. Zwane's patch reverted 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works for 2.6.23) Here is dmesg output from 2.6.23: http://bugs.gentoo.org/attachment.cgi?id=126203=view Let me know how we can help diagnose this further. Thanks, Daniel - 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: Load interrupt code dynamically
> dealing with the concurrency in the kernel. Interrupt is one of them. Its extremely hard as you've probably noticed by now. > My first question is, what are other interrupts in the kernel that can > allow other interrupts > to be issued? Second question is, how does the kernel switch between The kernel IRQ handling is pretty flexible. A concious decision was made many years ago not to try and limit it to do a pageable kernel as RAM was far cheaper than the pain, and getting cheaper by the day. > different interrupts? Last, any suggestion on how to change my current > implementation to enable loading interrupt code dynamically? Realistically - the one case it is done right now is by the mainframe people, simply because the underlying hypervisor does it. You probably have much more chance that way using a microkernel (real one not MACH) underneath. Still a huge task. - 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/
[RESEND] [BUG] futex_unlock_pi() hurts my brain and may cause application deadlock
On Wed, 2007-05-30 at 17:49 -0700, john stultz wrote:
> All,
> So we've been seeing PI mutex deadlocks with a few of our applications
> using the -rt kernel. After narrowing things down, we were finding that
> the applications were indirectly calling futex_unlock_pi(), which on
> occasion would return -EFAULT, which is promptly ignored by glibc. This
> would cause the application to continue on as if it has unlocked the
> mutex, until it tried to reacquire it and deadlock.
>
> In looking into why the kernel was returning -EFAULT, I found the
> following:
>
> ...
> retry_locked:
> /*
>* To avoid races, try to do the TID -> 0 atomic transition
>* again. If it succeeds then we can return without waking
>* anyone else up:
>*/
> if (!(uval & FUTEX_OWNER_DIED)) {
> pagefault_disable();
> uval = futex_atomic_cmpxchg_inatomic(uaddr, current->pid, 0);
> pagefault_enable();
> }
>
> if (unlikely(uval == -EFAULT))
> goto pi_faulted;
> ...[snip]...
> pi_faulted:
> /*
>* We have to r/w *(int __user *)uaddr, but we can't modify it
>* non-atomically. Therefore, if get_user below is not
>* enough, we need to handle the fault ourselves, while
>* still holding the mmap_sem.
>*/
> if (attempt++) {
> ret = futex_handle_fault((unsigned long)uaddr, fshared,
>attempt);
> if (ret)
> goto out_unlock;
> goto retry_locked;
> }
>
>
> Should we fault through normal causes, on the second round we call
> futex_handle_fault, which faults in the address, and we then jump back
> to retry_locked. However, since uval is -EFAULT from the last cmpxchg,
> it w/ FUTEX_OWNER_DIED so we don't enter the first conditional to try
> to cmpxchg again. So since uval is still -EFAULT, we loop back to
> pi_faulted! This will loop until futex_handle_fault() bombs out because
> attempt is too big and we return -EFAULT.
>
> I *think* this is a possible quick fix here, but I'm no futex guru, so I
> wanted to run it by folks for review.
>
> Big thanks to Sripathi and Angela Lin for helping debug this, and Steven
> for suggesting a cleaner fix then what I first tried.
Hey Ingo,
I sent this fix for this back in the 2.6.21-rt9 era, and I thought to
picked it up, but I think it arrived amid some futex churn and
apparently has been dropped or was just lost.
Some of our testers have been reporting futex deadlocks and this fix
resolves it, so I believe it to still be needed.
thanks
-john
Avoid futex_unlock_pi returning -EFAULT (which results in deadlock), by
clearing uval before jumping to retry_locked.
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
Index: 2.6-rt/kernel/futex.c
===
--- 2.6-rt.orig/kernel/futex.c 2007-07-31 16:48:41.0 -0700
+++ 2.6-rt/kernel/futex.c 2007-07-31 16:48:48.0 -0700
@@ -1673,6 +1673,7 @@ pi_faulted:
attempt);
if (ret)
goto out;
+ uval = 0;
goto retry_unlocked;
}
-
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/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
> The hardware is called (E)IDE, the protocol is called ATA. > Or that's what I was told -- I think there's some historic > revisionism involved, too. ATA is the interface and standards for the ANSI standards based disk attachment. IDE "Integrated Drive Electronics" is a marketing name used to cover all sorts of ST412 compatible-ish early interfaces that moved the brains onto the disk. IDE doesn't really mean much but "brains on disk", ATA is a real standard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/net/cxgb3/xgmac.c: remove dead code
Adrian Bunk wrote:
This patch removes dead code ("tx_xcnt" can never be != 0 at this place)
spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/xgmac.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.22-rc6-mm1/drivers/net/cxgb3/xgmac.c.old 2007-07-24
13:55:33.0 +0200
+++ linux-2.6.22-rc6-mm1/drivers/net/cxgb3/xgmac.c 2007-07-24
13:57:06.0 +0200
@@ -510,38 +510,35 @@ int t3b2_mac_watchdog_task(struct cmac *
if (tx_mcnt == mac->tx_mcnt) {
tx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_TX_SPI4_SOP_EOP_CNT +
mac->offset)));
if (tx_xcnt == 0) {
t3_write_reg(adap, A_TP_PIO_ADDR,
A_TP_TX_DROP_CNT_CH0 + macidx(mac));
tx_tcnt = (G_TXDROPCNTCH0RCVD(t3_read_reg(adap,
A_TP_PIO_DATA)));
} else {
goto rxcheck;
}
} else {
mac->toggle_cnt = 0;
goto rxcheck;
}
- if (((tx_tcnt != mac->tx_tcnt) &&
-(tx_xcnt == 0) && (mac->tx_xcnt == 0)) ||
- ((mac->tx_mcnt == tx_mcnt) &&
-(tx_xcnt != 0) && (mac->tx_xcnt != 0))) {
+ if ((tx_tcnt != mac->tx_tcnt) && (mac->tx_xcnt == 0)) {
if (mac->toggle_cnt > 4) {
status = 2;
goto out;
} else {
status = 1;
goto out;
}
} else {
mac->toggle_cnt = 0;
goto rxcheck;
}
rxcheck:
if (rx_mcnt != mac->rx_mcnt)
rx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_RX_SPI4_SOP_EOP_CNT +
mac->offset)));
-
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 25] drivers/usb/misc/ftdi-elan.c: kmalloc + memset conversion to kzalloc
On Tue, 31 Jul 2007, Mariusz Kozlowski wrote:
> @@ -2777,12 +2777,14 @@ static int ftdi_elan_probe(struct usb_in
> size_t buffer_size;
> int i;
> int retval = -ENOMEM;
> -struct usb_ftdi *ftdi = kmalloc(sizeof(struct usb_ftdi), GFP_KERNEL);
> -if (ftdi == NULL) {
> +struct usb_ftdi *ftdi;
> +
> + ftdi = kzalloc(sizeof(struct usb_ftdi), GFP_KERNEL);
> + if (!ftdi) {
Whitespace damage soewhere?
-
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: CS5530 Alsa driver fails
> After "modprobe snd-cs5530" I have: > CS5530: XpressAudio at 0x220 > CS5530: MPU at 0x330 > CS5530: IRQ: 9 DMA8: 0 DMA16: 5 > sb: can't grab irq 9 > CS5530: Could not create SoundBlaster > CS5530_Audio: probe of :00:12.3 failed with error -16 Might be worth setting the IRQ to sharable. I've never seen a 5530 with the sound IRQ shared so I don't know if that works and is a valid configuration for the VSA firmware - 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: [OOPS] 2.6.23-rc1 Seems to be network related
On Wed, 1 Aug 2007 01:35:23 +0200 Bongani Hlope <[EMAIL PROTECTED]> wrote: > I got this partial Oops on my work laptop (DELL D800), while using the linux > 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and > this is the first and only time it did not boot. It was around the time it > should have been trying to connect to my linksys wireless router (which has > been working fine everyday since the 2.6.23-rc1 kernel was released). > > I copied what was on screen by hand, so some info is missing. I don't know > how > to reproduce it. > > Call Trace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_stack_log_lvl+0x9b/0xa3 > [] show_registers+0x1c2/0x2db > [] die+0x02/0x1de > [] do_trap+0x89/0xa2 > [] do_invalid_op+0x88/0x92 > [] error_code+0x6a/0x70 > [] kmap_atomic+0xe/0x10 > [] get_page_from_freelist+0x24c/0x3... > [] __alloc_pages+0x53/0x27d > [] kmem_cache_alloc+0x32/0x68 > [] dst_alloc+0x28/0x60 > [] ip_route_input+0x9b9/0xbba > [] arp_process+0x155/0x4e1 > [] arp_rcv+0xe9/0xfd > [] netif_receive_skb+0x16e/0x1eb > [] process_backlog+0x71/0xda > [] net_rx_action+0x56/0xee > [] __do_softirq+0x38/0x7a > [] do_soft_irq+0x41/0x91 > [] irq_exit+0x2c/0x66 > [] do_IRQ+0xb7/0xcd > [] common_interrupt+0x23/0x28 > [] handle_mm_fault+0x1fe/0x57e > [] error_code+0x6a/0x70 > === > EIP: [] kmap_atomic_prot+0x27/0x8.. Thanks. Commit b8c1c5da1520977cb55a358f20fc09567d40cad9 should have fixed this. - 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] clean Modules.symvers in external module dirs
At the moment, running `make clean` in an external module directory does a nice job of cleaning up with one exception: it leaves behind Modules.symvers. Attached patch adds this file to the clean list for external modules. Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]> --- err it'd help if i actually prefixed the external directory diff --git a/Makefile b/Makefile index dfe3d16..1db97d6 100644 --- a/Makefile +++ b/Makefile @@ -1253,8 +1253,10 @@ $(clean-dirs): $(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@) clean: rm-dirs := $(MODVERDIR) +clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers clean: $(clean-dirs) $(call cmd,rmdirs) + $(call cmd,rmfiles) @find $(KBUILD_EXTMOD) $(RCS_FIND_IGNORE) \ \( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \ -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \) \ signature.asc Description: This is a digitally signed message part.
Re: [rfc] balance-on-fork NUMA placement
On Tue, 31 Jul 2007, Andi Kleen wrote: > On Tuesday 31 July 2007 07:41, Nick Piggin wrote: > > > I haven't given this idea testing yet, but I just wanted to get some > > opinions on it first. NUMA placement still isn't ideal (eg. tasks with > > a memory policy will not do any placement, and process migrations of > > course will leave the memory behind...), but it does give a bit more > > chance for the memory controllers and interconnects to get evenly > > loaded. > > I didn't think slab honored mempolicies by default? > At least you seem to need to set special process flags. It does in the sense that slabs are allocated following policies. If you want to place individual objects then you need to use kmalloc_node(). - 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/
CS5530 Alsa driver fails
Hello, Linux: 2.6.23-rc1-git3 Hardware: CX5530 After "modprobe snd-cs5530" I have: CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 sb: can't grab irq 9 CS5530: Could not create SoundBlaster CS5530_Audio: probe of :00:12.3 failed with error -16 Thank You Rafał ~ $ cat /proc/interrupts CPU0 0: 26624XT-PIC-XTtimer 2: 0XT-PIC-XTcascade 4:428XT-PIC-XTserial 8: 0XT-PIC-XTrtc 9: 10793XT-PIC-XTohci_hcd:usb1 10: 1326XT-PIC-XTeth0 NMI: 0 ERR: 0 ~ $ lspci -v 00:00.0 Host bridge: Cyrix Corporation PCI Master Flags: bus master, medium devsel, latency 0 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Subsystem: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at f800 [size=256] Memory at 1001 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 1000 [disabled] [size=64K] Capabilities: [40] Power Management version 2 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] Flags: bus master, medium devsel, latency 0 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] Flags: medium devsel Memory at 40012000 (32-bit, non-prefetchable) [size=256] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] (prog-if 80 [Master]) Flags: medium devsel [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at 1000 [disabled] [size=128] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] Flags: medium devsel Memory at 40011000 (32-bit, non-prefetchable) [size=128] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] (prog-if 00 [VGA]) Flags: medium devsel Memory at 4001 (32-bit, non-prefetchable) [size=4K] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation ZFMicro Chipset USB Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at 000cc000 (32-bit, non-prefetchable) [size=4K] -- Kobiety klamia o wiele skuteczniej niz mezczyzni. Sprawdz, jak sie na nich poznac http://link.interia.pl/f1b16 - 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/
