Re: [PATCH] m68k: Atari SCSI driver update_timeout removal
On Sun, Jun 03, 2007 at 12:55:04PM +0200, Geert Uytterhoeven wrote:
> From: Michael Schmitz <[EMAIL PROTECTED]>
>
> Atari SCSI driver fixes: remove update_timeout kludge
Looks good. James, can you send this on for 2.6.22 so the accidentally
added cludge doesn't end up in any release version?
> Signed-off-by: Michael Schmitz <[EMAIL PROTECTED]>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> Cc: Christoph Hellwig <[EMAIL PROTECTED]>
> ---
> This removes the timeout kludge in commit
> fb810d121bceb945c5e576356bccba11cbfad7e3 that was NAK'ed by Christoph.
>
> drivers/scsi/atari_NCR5380.c | 44
> +--
> 1 file changed, 2 insertions(+), 42 deletions(-)
>
> --- a/drivers/scsi/atari_NCR5380.c
> +++ b/drivers/scsi/atari_NCR5380.c
> @@ -894,45 +894,6 @@ static int NCR5380_init(struct Scsi_Host
> }
>
> /*
> - * our own old-style timeout update
> - */
> -/*
> - * The strategy is to cause the timer code to call scsi_times_out()
> - * when the soonest timeout is pending.
> - * The arguments are used when we are queueing a new command, because
> - * we do not want to subtract the time used from this time, but when we
> - * set the timer, we want to take this value into account.
> - */
> -
> -int atari_scsi_update_timeout(Scsi_Cmnd * SCset, int timeout)
> -{
> - int rtn;
> -
> - /*
> - * We are using the new error handling code to actually
> register/deregister
> - * timers for timeout.
> - */
> -
> - if (!timer_pending(&SCset->eh_timeout))
> - rtn = 0;
> - else
> - rtn = SCset->eh_timeout.expires - jiffies;
> -
> - if (timeout == 0) {
> - del_timer(&SCset->eh_timeout);
> - SCset->eh_timeout.data = (unsigned long)NULL;
> - SCset->eh_timeout.expires = 0;
> - } else {
> - if (SCset->eh_timeout.data != (unsigned long)NULL)
> - del_timer(&SCset->eh_timeout);
> - SCset->eh_timeout.data = (unsigned long)SCset;
> - SCset->eh_timeout.expires = jiffies + timeout;
> - add_timer(&SCset->eh_timeout);
> - }
> - return rtn;
> -}
> -
> -/*
> * Function : int NCR5380_queue_command (Scsi_Cmnd *cmd,
> * void (*done)(Scsi_Cmnd *))
> *
> @@ -956,7 +917,6 @@ static int NCR5380_queue_command(Scsi_Cm
> Scsi_Cmnd *tmp;
> int oldto;
> unsigned long flags;
> - // extern int update_timeout(Scsi_Cmnd * SCset, int timeout);
>
> #if (NDEBUG & NDEBUG_NO_WRITE)
> switch (cmd->cmnd[0]) {
> @@ -1029,9 +989,9 @@ static int NCR5380_queue_command(Scsi_Cm
>* alter queues and touch the lock.
>*/
> if (!IS_A_TT()) {
> - oldto = atari_scsi_update_timeout(cmd, 0);
> + /* perhaps stop command timer here */
> falcon_get_lock();
> - atari_scsi_update_timeout(cmd, oldto);
> + /* perhaps restart command timer here */
> }
> if (!(hostdata->issue_queue) || (cmd->cmnd[0] == REQUEST_SENSE)) {
> LIST(cmd, hostdata->issue_queue);
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] h8300 zImage support update.
- Add missing files
- Add Makefile target
- Change image base
- Style fix
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile
index b2d896a..53b5c1e 100644
--- a/arch/h8300/Makefile
+++ b/arch/h8300/Makefile
@@ -61,10 +61,11 @@ archmrproper:
archclean:
$(Q)$(MAKE) $(clean)=$(boot)
-vmlinux.srec vmlinux.bin: vmlinux
+vmlinux.srec vmlinux.bin zImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
define archhelp
- echo 'vmlinux.bin - Create raw binary'
- echo 'vmlinux.srec - Create srec binary'
+ @echo 'vmlinux.bin - Create raw binary'
+ @echo 'vmlinux.srec - Create srec binary'
+ @echo 'zImage - Compressed kernel image'
endef
diff --git a/arch/h8300/boot/compressed/Makefile
b/arch/h8300/boot/compressed/Makefile
index 71aac82..d6189e0 100644
--- a/arch/h8300/boot/compressed/Makefile
+++ b/arch/h8300/boot/compressed/Makefile
@@ -15,10 +15,10 @@ OBJECTS = $(obj)/head.o $(obj)/misc.o
# in order to suppress error message.
#
CONFIG_MEMORY_START ?= 0x0040
-CONFIG_BOOT_LINK_OFFSET ?= 0x0040
+CONFIG_BOOT_LINK_OFFSET ?= 0x0014
IMAGE_OFFSET := $(shell printf "0x%08x"
$$[$(CONFIG_MEMORY_START)+$(CONFIG_BOOT_LINK_OFFSET)])
-LDFLAGS_vmlinux := -T $(obj)/vmlinux.lds
+LDFLAGS_vmlinux := -Ttext $(IMAGE_OFFSET) -estartup $(obj)/vmlinux.lds
$(obj)/vmlinux: $(OBJECTS) $(obj)/piggy.o FORCE
$(call if_changed,ld)
diff --git a/arch/h8300/boot/compressed/head.S
b/arch/h8300/boot/compressed/head.S
index b8e90d1..985a81a 100644
--- a/arch/h8300/boot/compressed/head.S
+++ b/arch/h8300/boot/compressed/head.S
@@ -4,7 +4,7 @@
* Copyright (C) 2006 Yoshinori Sato
*/
-.h8300h
+ .h8300h
#include
#define SRAM_START 0xff4000
diff --git a/arch/h8300/boot/compressed/vmlinux.lds
b/arch/h8300/boot/compressed/vmlinux.lds
new file mode 100644
index 000..65e2a0d
--- /dev/null
+++ b/arch/h8300/boot/compressed/vmlinux.lds
@@ -0,0 +1,32 @@
+SECTIONS
+{
+.text :
+{
+__stext = . ;
+ __text = .;
+ *(.text.startup)
+ *(.text)
+__etext = . ;
+}
+
+ .rodata :
+ {
+ *(.rodata)
+ }
+.data :
+
+{
+__sdata = . ;
+___data_start = . ;
+*(.data.*)
+ }
+.bss :
+{
+. = ALIGN(0x4) ;
+__sbss = . ;
+*(.bss*)
+. = ALIGN(0x4) ;
+__ebss = . ;
+__end = . ;
+}
+}
diff --git a/arch/h8300/boot/compressed/vmlinux.scr
b/arch/h8300/boot/compressed/vmlinux.scr
new file mode 100644
index 000..d9bcc74
--- /dev/null
+++ b/arch/h8300/boot/compressed/vmlinux.scr
@@ -0,0 +1,9 @@
+SECTIONS
+{
+ .data : {
+ _input_len = .;
+ LONG(_input_data_end - _input_data) _input_data = .;
+ *(.data)
+ _input_data_end = .;
+ }
+}
--
Yoshinori Sato
<[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: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Jens Axboe wrote: > On Sat, Jun 02 2007, Tejun Heo wrote: >> Hello, >> >> Jens Axboe wrote: Would that be very different from issuing barrier and not waiting for its completion? For ATA and SCSI, we'll have to flush write back cache anyway, so I don't see how we can get performance advantage by implementing separate WRITE_ORDERED. I think zero-length barrier (haven't looked at the code yet, still recovering from jet lag :-) can serve as genuine barrier without the extra write tho. >>> As always, it depends :-) >>> >>> If you are doing pure flush barriers, then there's no difference. Unless >>> you only guarantee ordering wrt previously submitted requests, in which >>> case you can eliminate the post flush. >>> >>> If you are doing ordered tags, then just setting the ordered bit is >>> enough. That is different from the barrier in that we don't need a flush >>> of FUA bit set. >> Hmmm... I'm feeling dense. Zero-length barrier also requires only one >> flush to separate requests before and after it (haven't looked at the >> code yet, will soon). Can you enlighten me? > > Yeah, that's what the zero-length barrier implementation I posted does. > Not sure if you have a question beyond that, if so fire away :-) I thought you were talking about adding BIO_RW_ORDERED instead of exposing zero length BIO_RW_BARRIER. Sorry about the confusion. :-) -- 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/
nfsroot and locking
Hi, I have a quick question about nfsroot in linux: Is there any way to use nfsv3 in the nfsroot (nolock is OK there), and then mount other directories with locking enabled ? The default nfs options when using nfsroot are to use nfsv2 without locking. After booting, one can mount other filesystems which will default to nfsv3 with locking. By passing extra options in the nfsroot parameter, one can boot with nfs3 if desired. For example v3,tcp,rsize=131072,wsize=131072,intr set the same options in nfsroot than would otherwise be the after-boot default, except that locking stays disabled (I understand lockd can not be started as portmap is not running during boot). However after starting the nfsroot with nfsv3, I am unable to mount any other shares with locking. Passing the 'lock' option to mount will add 'lock' in /etc/mtab, but /proc/mounts will still show the share with 'nolock' and rpcinfo shows that lockd was not started. Is there a reason for this, or an easy workaround ? for reference, I'm currently running debian etch with a 2.6.20.12 kernel. Also I'd appreciate to be copied on replies as I'm not on the list. Thanks, -- Michel "Walken" Lespinasse "Bill Gates is a monocle and a Persian cat away from being the villain in a James Bond movie." -- Dennis Miller - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: libata & no PCI: dma_[un]map_single undefined
On Sun, Jun 03, 2007 at 05:40:10PM -0700, David Miller wrote: > From: Meelis Roos <[EMAIL PROTECTED]> > Date: Sun, 3 Jun 2007 23:23:33 +0300 (EEST) > > > I accidentally enabled libata config options on my Sun Ultra 1 (sparc64, > > UP, no PCI, only SBUS): > > > > MODPOST 440 modules > > ERROR: "dma_unmap_sg" [drivers/ata/libata.ko] undefined! > > ERROR: "dma_map_sg" [drivers/ata/libata.ko] undefined! > > ERROR: "dma_unmap_single" [drivers/ata/libata.ko] undefined! > > ERROR: "dma_mapping_error" [drivers/ata/libata.ko] undefined! > > ERROR: "dma_map_single" [drivers/ata/libata.ko] undefined! > > > > CONFIG_PCI=n > > CONFIG_ATA=m > > > > This seems to be a valid configuration since libata can drive non-PCI > > devices too? > > It really makes no sense to allow this on Sparc, there are no > non-PCI Sparc ATA controllers. > > Therefore I'll fix it like this: The right fix is the depend on the new HAS_DMA (or whatever it's called) symbol. The proper long-term fix is to move calln to the dam mapping functions from the core libata files into the drivers responsibility with a default implementation for the typical cases. > > commit 6274b5c63131c3110405db5d19e71af26cbbd375 > Author: David S. Miller <[EMAIL PROTECTED]> > Date: Sun Jun 3 17:39:56 2007 -0700 > > [ATA]: Don't allow to enable this for SPARC64 without PCI. > > Based upon a report from Meelis Roos. > > Signed-off-by: David S. Miller <[EMAIL PROTECTED]> > > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig > index b4a8d60..7d893a6 100644 > --- a/drivers/ata/Kconfig > +++ b/drivers/ata/Kconfig > @@ -8,6 +8,7 @@ menuconfig ATA > depends on BLOCK > depends on !(M32R || M68K) || BROKEN > depends on !SUN4 || BROKEN > + depends on !(SPARC64 && !PCI) > select SCSI > ---help--- > If you want to use a ATA hard disk, ATA tape drive, ATA CD-ROM or > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ---end quoted text--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 1/2] PM: Introduce hibernation and suspend notifiers
On Monday, 4 June 2007 00:59, Pavel Machek wrote: > On Mon 2007-06-04 00:38:53, Rafael J. Wysocki wrote: > > On Sunday, 3 June 2007 18:41, Pavel Machek wrote: > > > Hi! > > > > > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > Make it possible to register hibernation and suspend notifiers, so that > > > > subsystems can perform hibernation-related or suspend-related > > > > operations that > > > > should not be carried out by device drivers' .suspend() and .resume() > > > > routines. > > > > > > One more question: what will we call in suspend-to-both case? I do not > > > think we can call SUSPEND_PREPARE with frozen tasks, so just one call > > > to HIBERNATION_PREPARE? > > > > Yes, right now it should work this way. > > (Should it be mentioned in docuementation?) Eventually, yes. Still, for now, the STR code in user.c is outdated and needs fixing. I'll take care of it later this week. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Documentation/CodingStyle: Add rules for goto labels
On Sun, Jun 03, 2007 at 11:59:26PM -0700, Jeremy Fitzhardinge wrote: >WANG Cong wrote: >> I just wonder, if a goto label is nested in a while/for/if/switch block, >> aligning it in >> the first column maybe a bit ugly. (I know mostly it is not in any >> while/for/if/switch block.) >> > >In general goto labels are not scoped, so there's no point in pretending >they are. It might make sense to indent a label deeper if you've >actually declared it local (__label__). > >J OK. Thank you. I will take your advice. A new version of this patch will come soon. ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A kexec approach to hibernation
Hi, On Monday, 4 June 2007 07:22, Nigel Cunningham wrote: > Hi. > > I can see that the idea of writing a kernel image from using another > kernel sounds nice and clean initially, but the more we get into the > details (yes, I am listening, even though I said nothing before now), > the more it's sounding like the cure is worse than the disease. > > To get rid of process freezing, we're talking about: > * making hibernation depend on depriving the user of 32 or 64M of > otherwise perfectly usable memory (thereby making hibernation on > machines with less memory impossible) > * requiring them to set up kexec or kdump (I don't understand the > difference, sorry) or some new variation > * adding interfaces to tell kexec/dump/whatever what pages need to be > saved and reloaded > * adding convolutions in which at resume time we boot one kernel, switch > to another kernel to do the loading and then switch back again to the > resumed kernel (assuming I understand what you're suggesting). > > It all sounds terribly complicated and confusing to me, and that's > before I even begin to think about how this second kernel could possibly > write the image to an encrypted device or LVM or such like that the > first kernel knows about and might use now. > > Can't we just get the freezer right and be done with it? My feelings about this are pretty much the same. :-) At least, there still is room for improvements within the current approach, so first I'd like to improve it as much as reasonably possible and then to think of alternatives, if need be. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
* Andrew Morton <[EMAIL PROTECTED]> wrote: > I must say that it's not really clear to me why this fdmap thing was > created. Exactly what problem is it solving, and what properties is > it designed to have? > > Could not a (prehaps suitably modified) IDR tree have adequately > provided those properties? > > I'm sure it's good stuff, but the patches were presented as if we all > know what they're for. But I don't. Maybe I was asleep at the time. i think this sums it up: http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2490.html and some more, with a benchmark as well: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13685.html ( blame Google for picking up two different lkml archives for the two searches i did :-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sendfile removal
On Mon, Jun 04 2007, Fengguang Wu wrote: > Hi Jens, > > This is another try, still not in a comfortable state though. > //Busy waiting is possible for interleaved reads. A few random comments... Adding an internal flag is fine, but please put it at the upper end of the spectrum. So, use (1 << 31) for that flag. And please work on the #splice branch of the block repo, not -mm. There are quite a few things pending for inclusion in there, and I'm sure your patch as-is wont apply. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc3][ACPI?] Resume from s2r doesn't work.
On Sunday, 3 June 2007 23:20, Olaf Dietsche wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> > Second, you can use PM_TRACE (Documentation/power/s2ram.txt) to find the
> > place where it really fails.
>
> First I augmented my minimal config kernel with some TRACE_RESUME()s:
>
> --- a/kernel/power/main.c 2007-05-27 23:48:05.0 +0200
> +++ b/kernel/power/main.c 2007-06-03 22:28:46.0 +0200
> @@ -223,6 +223,7 @@
> pr_debug("PM: Finishing wakeup.\n");
> suspend_finish(state);
> Unlock:
> + TRACE_RESUME(error);
> mutex_unlock(&pm_mutex);
> return error;
> }
> @@ -303,6 +304,7 @@
> error = enter_state(state);
> else
> error = -EINVAL;
> + TRACE_RESUME(error);
> return error ? error : n;
> }
>
> With this test script:
>
> #! /bin/sh
>
> sync
> echo 1 >/sys/power/pm_trace
> echo mem >/sys/power/state
> shutdown -rn now
>
> I got alternating
> hash matches drivers/base/power/resume.c:58
> and
> hash matches kernel/power/main.c:307
>
> > First, you can check if the patch
> >
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/20-ACPI-preserve-the-ebx-value-in-acpi_copy_wakeup_routine.patch
>
> Then I applied this patch, but it doesn't change anything.
>
> But either way the script never reaches "shutdown -rn now". So, it
> seems, that my laptop does a full resume every other reboot, but it
> never returns to userspace.
I'm still suspecting that the problem is related to your graphics adapter.
What graphics adapter do you have in the box?
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
* Ingo Molnar <[EMAIL PROTECTED]> wrote: > i think this sums it up: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2490.html i mean this mail started it: http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13070.html > and some more, with a benchmark as well: > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13685.html Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A kexec approach to hibernation
Hi again. On Mon, 2007-06-04 at 10:05 +0200, Rafael J. Wysocki wrote: > On Monday, 4 June 2007 07:22, Nigel Cunningham wrote: > > Hi. > > > > I can see that the idea of writing a kernel image from using another > > kernel sounds nice and clean initially, but the more we get into the > > details (yes, I am listening, even though I said nothing before now), > > the more it's sounding like the cure is worse than the disease. > > > > To get rid of process freezing, we're talking about: > > * making hibernation depend on depriving the user of 32 or 64M of > > otherwise perfectly usable memory (thereby making hibernation on > > machines with less memory impossible) > > * requiring them to set up kexec or kdump (I don't understand the > > difference, sorry) or some new variation > > * adding interfaces to tell kexec/dump/whatever what pages need to be > > saved and reloaded > > * adding convolutions in which at resume time we boot one kernel, switch > > to another kernel to do the loading and then switch back again to the > > resumed kernel (assuming I understand what you're suggesting). > > > > It all sounds terribly complicated and confusing to me, and that's > > before I even begin to think about how this second kernel could possibly > > write the image to an encrypted device or LVM or such like that the > > first kernel knows about and might use now. > > > > Can't we just get the freezer right and be done with it? > > My feelings about this are pretty much the same. :-) > > At least, there still is room for improvements within the current approach, > so first I'd like to improve it as much as reasonably possible and then to > think of alternatives, if need be. Agreed. I'm not for a moment denying that the current freezer could be better, but biffing it out the window just doesn't seem to be the appropriate solution at the moment. Regards, Nigel signature.asc Description: This is a digitally signed message part
Re: [-mm patch] drivers/i2c/chips/ds1682.c: make code static
Hi Adrian,
On Sun, 3 Jun 2007 22:54:17 +0200, Adrian Bunk wrote:
> This patch makes some needlessly global code static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> drivers/i2c/chips/ds1682.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> --- linux-2.6.22-rc3-mm1/drivers/i2c/chips/ds1682.c.old 2007-06-03
> 22:18:53.0 +0200
> +++ linux-2.6.22-rc3-mm1/drivers/i2c/chips/ds1682.c 2007-06-03
> 22:21:07.0 +0200
> @@ -121,12 +121,12 @@
> /*
> * Simple register attributes
> */
> -SENSOR_DEVICE_ATTR_2(elapsed_time, S_IRUGO | S_IWUSR, ds1682_show,
> ds1682_store,
> - 4, DS1682_REG_ELAPSED);
> -SENSOR_DEVICE_ATTR_2(alarm_time, S_IRUGO | S_IWUSR, ds1682_show,
> ds1682_store,
> - 4, DS1682_REG_ALARM);
> -SENSOR_DEVICE_ATTR_2(event_count, S_IRUGO | S_IWUSR, ds1682_show,
> ds1682_store,
> - 2, DS1682_REG_EVT_CNTR);
> +static SENSOR_DEVICE_ATTR_2(elapsed_time, S_IRUGO | S_IWUSR, ds1682_show,
> + ds1682_store, 4, DS1682_REG_ELAPSED);
> +static SENSOR_DEVICE_ATTR_2(alarm_time, S_IRUGO | S_IWUSR, ds1682_show,
> + ds1682_store, 4, DS1682_REG_ALARM);
> +static SENSOR_DEVICE_ATTR_2(event_count, S_IRUGO | S_IWUSR, ds1682_show,
> + ds1682_store, 2, DS1682_REG_EVT_CNTR);
>
> static const struct attribute_group ds1682_group = {
> .attrs = (struct attribute *[]) {
Good catch. I've folded this fix into i2c-ds1628-new-driver.patch,
thanks for reporting.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] Documentation/CodingStyle: Add rules for goto labels (-v2)
Lindent gets wrong when it meets goto labels. This should be fixed manually. And kernel's CodingStyle doesn't specify the indentation for goto labels explicitly. This patch adds specifications on those things about goto labels in CodingStyle. And it is against -rc3 source tree. Thanks to Al Viro, Randy Dunlap, Jeff Garzik and Jeremy Fitzhardinge for their comments! Regards! Signed-off-by: WANG Cong <[EMAIL PROTECTED]> --- CodingStyle |7 +++ 1 file changed, 7 insertions(+) --- linux-2.6.22-rc3/Documentation/CodingStyle.orig 2007-06-04 15:53:58.0 +0800 +++ linux-2.6.22-rc3/Documentation/CodingStyle 2007-06-04 16:04:31.0 +0800 @@ -66,6 +66,13 @@ something to hide: Don't put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions. +Do care when you use Lindent to indent your code, since it may use spaces +instead of tabs before a goto label and it may also align the label in a +wrong position. Generally speaking, a goto label should be always aligned in +the first column. However, it might make sense to indent a label deeper if +you've actually declared it local (__label__). Please fix it manually if you +find Lindent is wrong. + Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
On Mon, 4 Jun 2007 10:09:41 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > i think this sums it up: > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2490.html > > i mean this mail started it: > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13070.html > > > and some more, with a benchmark as well: > > > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13685.html > Yeah, I remember all that but I don't think it provides a suitable description of what all this code is there for - what problem it is solving and how it solves it. If we just want some pseudo-private fd space for glibc to use then I'd have thought that the existing code could be tweaked to do that: top-down allocation, start at some high offset, etc. But apparently there's more to it than 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 1/2] ufd v1 - unsequential O(1) fdmap core
* Andrew Morton <[EMAIL PROTECTED]> wrote: > If we just want some pseudo-private fd space for glibc to use then I'd > have thought that the existing code could be tweaked to do that: > top-down allocation, start at some high offset, etc. But apparently > there's more to it than this. top-down has the problem of rlimits: 'where is top' is a variable notion. start-at-high-offset using the existing scheme has a 'bitmap size' problem: even at 2^28 the bitmap size would be 32+ MB. per process (!). The bitmap could be allocated on demand, but that slows down the current code, uglifies it, and it would still end up somewhere looking a bit like Davide's clean new code. so, instead of trying to mesh this thing into the old fd data structures which are very much centered around and tailored to the continuous-allocation usage model, Davide cleanly separated it out into a separate data structure that fits this independently-allocated usage model well and leaves the original data structure alone. I'm strongly in favor of such clean data structure separations. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: stallion driver dmesg notice
Ingo Korb wrote:
> > > Should I test it with an EC8/64-PCI? The /32 (ab)uses an IDE controller
> > > chip as PCI interface, the /64 uses a PLX PCI9050.
> >
> > I don't undestand this. IDE grabs the device? This is possible and if yes,
> > I'll fix the IDE driver.
>
> Yes, IDE (specifically: generic IDE PCI support, generic.ko - not
> compiled into my kernel) can grab the device. It's using an IDE
> controller chip that reports itself as such, so that's not completely
> unreasonable.
Good, thanks for the info.
> > Could you please try the patch below?
>
> Oopsed:
>
> === Cut ===
> Unloading Stallion Multiport Serial Driver: version 5.6.0
> Stallion Multiport Serial Driver: version 5.6.0
> stallion :00:0b.0: please, report this to LKML: 100b/d001/ff
> STALLION: EC8/32-PCI found, board=0 io=d200 irq=17 nrpanels=1 nrports=8
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0074
Okay, tty alloc after pci init, attached patch should fix it. Could you
retest?
> > stallion, don't fail with less than max panels
>
> I could try with more than one panel if neccecary - I think I have four 8-
> Port-Panels, one 8-Port-XP-Panel (different UART) and one 16-Port-Panel
> stored somewhere.
Doesn't matter, needs fix anyway.
--
stallion, alloc tty before pci devices init
this causes oops, because pci prboe function calls tty_register_device for
each device found.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit f6d5d1877b0f7ac82f5e1fec2ead0429eeb069c8
tree 31beaaee84ef718acc5401b3cb07a7f2e340f0fe
parent a6c3fb453e98ba32291a4fc5a7d843fb27359182
author Jiri Slaby <[EMAIL PROTECTED]> Mon, 04 Jun 2007 10:39:41 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 04 Jun 2007 10:39:41 +0200
drivers/char/stallion.c | 73 ++-
1 files changed, 34 insertions(+), 39 deletions(-)
diff --git a/drivers/char/stallion.c b/drivers/char/stallion.c
index 9820f49..45bf2a2 100644
--- a/drivers/char/stallion.c
+++ b/drivers/char/stallion.c
@@ -4714,6 +4714,29 @@ static int __init stallion_module_init(void)
spin_lock_init(&stallion_lock);
spin_lock_init(&brd_lock);
+ stl_serial = alloc_tty_driver(STL_MAXBRDS * STL_MAXPORTS);
+ if (!stl_serial) {
+ retval = -ENOMEM;
+ goto err;
+ }
+
+ stl_serial->owner = THIS_MODULE;
+ stl_serial->driver_name = stl_drvname;
+ stl_serial->name = "ttyE";
+ stl_serial->major = STL_SERIALMAJOR;
+ stl_serial->minor_start = 0;
+ stl_serial->type = TTY_DRIVER_TYPE_SERIAL;
+ stl_serial->subtype = SERIAL_TYPE_NORMAL;
+ stl_serial->init_termios = stl_deftermios;
+ stl_serial->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ tty_set_operations(stl_serial, &stl_ops);
+
+ retval = tty_register_driver(stl_serial);
+ if (retval) {
+ printk("STALLION: failed to register serial driver\n");
+ goto err_frtty;
+ }
+
/*
* Find any dynamically supported boards. That is via module load
* line options.
@@ -4743,13 +4766,9 @@ static int __init stallion_module_init(void)
/* this has to be _after_ isa finding because of locking */
retval = pci_register_driver(&stl_pcidriver);
- if (retval && stl_nrbrds == 0)
- goto err;
-
- stl_serial = alloc_tty_driver(STL_MAXBRDS * STL_MAXPORTS);
- if (!stl_serial) {
- retval = -ENOMEM;
- goto err_pcidr;
+ if (retval && stl_nrbrds == 0) {
+ printk(KERN_ERR "STALLION: can't register pci driver\n");
+ goto err_unrtty;
}
/*
@@ -4760,43 +4779,18 @@ static int __init stallion_module_init(void)
printk("STALLION: failed to register serial board device\n");
stallion_class = class_create(THIS_MODULE, "staliomem");
- if (IS_ERR(stallion_class)) {
- retval = PTR_ERR(stallion_class);
- goto err_reg;
- }
+ if (IS_ERR(stallion_class))
+ printk("STALLION: failed to create class\n");
for (i = 0; i < 4; i++)
class_device_create(stallion_class, NULL,
MKDEV(STL_SIOMEMMAJOR, i), NULL,
"staliomem%d", i);
- stl_serial->owner = THIS_MODULE;
- stl_serial->driver_name = stl_drvname;
- stl_serial->name = "ttyE";
- stl_serial->major = STL_SERIALMAJOR;
- stl_serial->minor_start = 0;
- stl_serial->type = TTY_DRIVER_TYPE_SERIAL;
- stl_serial->subtype = SERIAL_TYPE_NORMAL;
- stl_serial->init_termios = stl_deftermios;
- stl_serial->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
- tty_set_operations(stl_serial, &stl_ops);
-
- retval = tty_register_driver(stl_serial);
- if (retval) {
- printk("STALLION: failed to register serial driver\n");
-
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
On Mon, 4 Jun 2007 10:42:27 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > If we just want some pseudo-private fd space for glibc to use then I'd > > have thought that the existing code could be tweaked to do that: > > top-down allocation, start at some high offset, etc. But apparently > > there's more to it than this. > > top-down has the problem of rlimits: 'where is top' is a variable > notion. Well, sort-of. rlimits affect the number of open files, not the actual fd indices. But whatever. > start-at-high-offset using the existing scheme has a 'bitmap size' > problem: even at 2^28 the bitmap size would be 32+ MB. per process (!). > The bitmap could be allocated on demand, but that slows down the current > code, uglifies it, and it would still end up somewhere looking a bit > like Davide's clean new code. OK, so the existing code doesn't support a holey bitmap. > so, instead of trying to mesh this thing into the old fd data structures > which are very much centered around and tailored to the > continuous-allocation usage model, Davide cleanly separated it out into > a separate data structure that fits this independently-allocated usage > model well and leaves the original data structure alone. I'm strongly in > favor of such clean data structure separations. a) Were IDR trees evaluated and if so, why were they rejected? b) it's a bit disappointing that this new allocator is only usable for one specific application. We have a *lot* of places in the kernel which want allocators of this type. Many of them are open-coded and crappy. Some use IDR trees. If we're going to go and add a complete new allocator, it would be good to position it as a library thing if poss. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 06/18] fs/logfs/compr.c
On Sun, 3 June 2007 23:58:43 +0200, Arnd Bergmann wrote: > On Sunday 03 June 2007, Jörn Engel wrote: > > +#define COMPR_LEVEL 3 > > + > > +static DEFINE_MUTEX(compr_mutex); > > +static struct z_stream_s stream; > > Is there a particular reason to choose '3' as the only compression > level? Should this perhaps be a per-superblock option instead? There is no particular reason. '3' should be a reasonable value for most people. If actual users want to change this value, I can make it a mount option as well. Right now I'm just lazy and doubt the merits. > Also, I thought I saw discussion about making the mutex and > stream per-superblock, but don't remember if the idea was discarded. > If it was, you might want to add it to the won't-happen list. It was more or less discarded. As long as the sweet spot for LogFS is small systems, saving memory is more important than multithreaded performance. Will add it to the list. Jörn -- Joern's library part 2: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 09/18] fs/logfs/gc.c
On Mon, 4 June 2007 00:07:36 +0200, Arnd Bergmann wrote:
> On Sunday 03 June 2007, Jörn Engel wrote:
> > +static long decay(long t0, long t, long theta)
> > +{
> > + long shift, fac;
> > +
> > + if (t >= 32*theta)
> > + return 0;
> > +
> > + shift = t/theta;
> > + fac = theta - (t%theta)/2;
> > + return (t0 >> shift) * fac / theta;
> > +}
>
> I think it's confusion to work with 'long' arguments
> here. If you actually allow larger than 32 bit arguments,
> that means that the gc logic behaves differently on
> 32 and 64 bit CPUs, which I don't think is what you
> intended.
Different behaviour would be fine. This function will be used to pick
good candidates for garbage collection. If one segment will get chosen
over another depending on BITS_PER_LONG, either one would have been a
good candidate anyway.
Hmm. Maybe I should s/32/BITS_PER_LONG/ in the function.
> Also, can any of the arguments be negative? How about
> making them all explicit u32 and u64 variables?
That would make sense, yes.
Jörn
--
I've never met a human being who would want to read 17,000 pages of
documentation, and if there was, I'd kill him to get him out of the
gene pool.
-- Joseph Costello
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sundance: PHY address form 0, only for device ID 0x0200 (IP100A)
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
Search PHY address form 0, only for device ID 0x0200 (IP100A). Other device are
from PHY address 1.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
5724a72722dfc9cafbb8f273cb82dbf577bd9ad0
diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
index e1f912d..914ab29 100644
--- a/drivers/net/sundance.c
+++ b/drivers/net/sundance.c
@@ -562,7 +562,9 @@ #endif
* It seems some phys doesn't deal well with address 0 being accessed
* first, so leave address zero to the end of the loop (32 & 31).
*/
- for (phy = 1; phy <= 32 && phy_idx < MII_CNT; phy++) {
+ if(sundance_pci_tbl[np->chip_id].device == 0x0200) phy = 0;
+ else phy = 1;
+ for (; phy <= 32 && phy_idx < MII_CNT; phy++) {
int phyx = phy & 0x1f;
int mii_status = mdio_read(dev, phyx, MII_BMSR);
if (mii_status != 0x && mii_status != 0x) {
--
1.3.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LogFS take four
On Mon, 4 June 2007 00:18:21 +0200, Arnd Bergmann wrote:
> On Sunday 03 June 2007, Jörn Engel wrote:
>
> > Unchanged:
> > o error handling
> >
> ...
> > Won't happen (unless I get convinced to do otherwise):
> > o Change LOGFS_BUG() and LOGFS_BUG_ON() to inline functions
> > These are macros for very much the same reasons BUG() and BUG_ON() are.
>
> I wonder how many of your LOGFS_BUG{,_ON} still remain after the
> error handling is in place to deal with broken file system contents.
> Ideally, I'd say the current LOGFS_BUG() should be replaced with
> a function that prints about the kind of error it has hit (rate-limited),
> potentially calls logfs_crash_dump(), and remounts the medium read-only,
> but _not_ call BUG().
That sounds fairly useful, actually. Do a WARN_ON(), call
logfs_crash_dump(), remount read-only and finished. Rate-limiting might
be unnecessary as the read-only thing already limits the rate to 1.
I like the idea.
Jörn
--
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/18] fs/logfs/segment.c
On Mon, 4 June 2007 00:21:41 +0200, Arnd Bergmann wrote: > On Sunday 03 June 2007, Jörn Engel wrote: > > +static DEFINE_MUTEX(compr_mutex); > > + > > It seems you define a static compre_mutex in both segment.c and in compr.c, > and always lock them both at the same time. Is that a correct observation? > Is it intentional, or an oversight on your side? Lame coding on my side. Seems to have gone lost in my notes, but this mutex should get removed and the protected memory made per-superblock. Unlike the zlib workspace it does not consume 300k, so there is no excuse for it here. Jörn -- Joern's library part 9: http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 05/18] fs/logfs/logfs.h
On Sun, 3 June 2007 23:50:55 +0200, Arnd Bergmann wrote:
> On Sunday 03 June 2007, Jörn Engel wrote:
> > +/**
> > + * struct logfs_device_ops - device access operations
> > + *
> > + * @read: read from the device
> > + * @write: write to the device
> > + * @erase: erase part of the device
> > + */
> > +struct logfs_device_ops {
> > + int (*read)(struct super_block *sb, loff_t ofs, size_t len, void
> > *buf);
> > + int (*write)(struct super_block *sb, loff_t ofs, size_t len, void
> > *buf);
> > + int (*erase)(struct super_block *sb, loff_t ofs, size_t len);
> > +};
>
> I wonder if there is a way to document the prototypes of these function
> pointers with kerneldoc, other than having a typedef for each.
>
> What brought me to this point is that I first assumed they would return
> the number of bytes transferred, like read/write file operations, where
> your functions return zero on success.
I can just add a comment about the return code in the struct
documentation. For the foreseeable future there will be exactly two
instances of this structure. It's not as if every driver would
implement this.
Jörn
--
A defeated army first battles and then seeks victory.
-- Sun Tzu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 04/18] include/linux/logfs.h
On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
> On Sunday 03 June 2007, Jörn Engel wrote:
> > +struct logfs_je_spillout {
> > + __be64 so_segment[0];
> > +}__packed;
>
> All the on-disk data structures you define in this file have naturally
> aligned members, so the __packed attribute is not needed.
Amen. It is purely paranoia and I don't even know who is out to get me.
> However, I think it causes gcc to generate larger and slower code
> on some architectures, because now it has to assume that the data
> structure itself has no more than byte alignment.
>
> I'd simply remove all instances of __packed therefore. In order
> to verify that you got it right in all cases, build with
> '-Wpadded -Wpacked'.
Fine with me. Will do.
Jörn
--
Ninety percent of everything is crap.
-- Sturgeon's Law
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] ide: ide-generic, add another device exception
ide-generic, add another device exception
This device is char device and is grabbed by generic ide driver:
00:0b.0 Class : National Semiconductor Corporation 87410 IDE (rev ff)
(prog-if ff)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Disallow generic driver to grab it by adding next condition. Also
consolidate exceptions to one bigger 'switch (dev->vendor)'.
Cc: Ingo Korb <[EMAIL PROTECTED]>
Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 879404085754892c27ff2d1c73d310582b872a98
tree abb7f3b7522c4076da230125afa9d34cbf48ff91
parent f6d5d1877b0f7ac82f5e1fec2ead0429eeb069c8
author Jiri Slaby <[EMAIL PROTECTED]> Mon, 04 Jun 2007 11:19:39 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 04 Jun 2007 11:19:39 +0200
drivers/ide/pci/generic.c | 37 +++--
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c
index f2c5a14..0d51a11 100644
--- a/drivers/ide/pci/generic.c
+++ b/drivers/ide/pci/generic.c
@@ -198,32 +198,41 @@ static ide_pci_device_t generic_chipsets[] __devinitdata
= {
static int __devinit generic_init_one(struct pci_dev *dev, const struct
pci_device_id *id)
{
ide_pci_device_t *d = &generic_chipsets[id->driver_data];
- u16 command;
int ret = -ENODEV;
/* Don't use the generic entry unless instructed to do so */
if (id->driver_data == 0 && ide_generic_all == 0)
goto out;
- if (dev->vendor == PCI_VENDOR_ID_UMC &&
- dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
- (!(PCI_FUNC(dev->devfn) & 1)))
- goto out; /* UM8886A/BF pair */
-
- if (dev->vendor == PCI_VENDOR_ID_OPTI &&
- dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
- (!(PCI_FUNC(dev->devfn) & 1)))
- goto out;
-
- if (dev->vendor == PCI_VENDOR_ID_JMICRON) {
- if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
PCI_FUNC(dev->devfn) != 1)
+ switch (dev->vendor) {
+ case PCI_VENDOR_ID_UMC:
+ if (dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
+ !(PCI_FUNC(dev->devfn) & 1))
+ goto out; /* UM8886A/BF pair */
+ break;
+ case PCI_VENDOR_ID_OPTI:
+ if (dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
+ !(PCI_FUNC(dev->devfn) & 1))
+ goto out;
+ break;
+ case PCI_VENDOR_ID_JMICRON:
+ if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
+ PCI_FUNC(dev->devfn) != 1)
+ goto out;
+ break;
+ case PCI_VENDOR_ID_NS:
+ if (dev->device == PCI_DEVICE_ID_NS_87410 &&
+ (dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
goto out;
+ break;
}
if (dev->vendor != PCI_VENDOR_ID_JMICRON) {
+ u16 command;
pci_read_config_word(dev, PCI_COMMAND, &command);
if (!(command & PCI_COMMAND_IO)) {
- printk(KERN_INFO "Skipping disabled %s IDE
controller.\n", d->name);
+ printk(KERN_INFO "Skipping disabled %s IDE "
+ "controller.\n", d->name);
goto 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/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote: > Yes, SuSE enables polling mode by default, but that is just > distro specific "value add" that should eventually be fixed. I will do that for openSUSE FACTORY. -- Stefan Seyfried QA / R&D Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc1-mm1 [cannot change thermal trip points]
On Tue, May 22, 2007 at 11:06:36AM +0200, Pavel Machek wrote: > We need to ignore trip point updates from BIOS, and we need to poll > thermals when use overrides trip points. That's expected. Plus I've > yet to see platform actually updating the trip points. Thinkpad 600, whenever a trip point is crossed, all trip points are updated. I think they implemented hysteresis that way. ISTR that hp nx5000 did something similar, but i might be wrong on this one. -- Stefan Seyfried QA / R&D Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: hisax isdn card (Sedlbauer Speed Fax+) does not get an interrupt
Hi Robert, On Thu, 31 May 2007, Robert Hancock wrote: > Thomas Voegtle wrote: > > > > == [...] > > <03>2007 May 30 14:21:40 cbs kern: irq 11: nobody cared (try booting with > > the \"irqpoll\" option) > > <04>2007 May 30 14:21:40 cbs kern: [] __report_bad_irq+0x2b/0x69 > > <04>2007 May 30 14:21:40 cbs kern: [] note_interrupt+0x166/0x193 > > <04>2007 May 30 14:21:40 cbs kern: [] usb_hcd_irq+0x23/0x4f > > <04>2007 May 30 14:21:40 cbs kern: [] handle_IRQ_event+0x21/0x4a > > <04>2007 May 30 14:21:40 cbs kern: [] __do_IRQ+0x68/0x8f > > <04>2007 May 30 14:21:40 cbs kern: [] do_IRQ+0x5c/0x77 > > <04>2007 May 30 14:21:40 cbs kern: === > > <04>2007 May 30 14:21:40 cbs kern: [] common_interrupt+0x1a/0x20 > > <04>2007 May 30 14:21:40 cbs kern: [] __do_softirq+0x2c/0x7d > > <04>2007 May 30 14:21:40 cbs kern: [] do_softirq+0x38/0x3f > > <04>2007 May 30 14:21:40 cbs kern: === > > <04>2007 May 30 14:21:40 cbs kern: [] do_IRQ+0x6e/0x77 > > <04>2007 May 30 14:21:40 cbs kern: [] common_interrupt+0x1a/0x20 > > <04>2007 May 30 14:21:40 cbs kern: [] W6692B_interrupt+0x23c/0x559 > > [hisax] > > <04>2007 May 30 14:21:40 cbs kern: [] delay_pmtmr+0xb/0x13 > > <04>2007 May 30 14:21:40 cbs kern: [] __delay+0x9/0xa > > <04>2007 May 30 14:21:40 cbs kern: [] setup_sedlbauer+0x1ee/0x534 > > [hisax] > > <04>2007 May 30 14:21:40 cbs kern: [] printk+0x12/0x16 > > <04>2007 May 30 14:21:40 cbs kern: [] checkcard+0x201/0x566 > > [hisax] > > <04>2007 May 30 14:21:40 cbs kern: [] checkcard+0x288/0x566 > > [hisax] > > <04>2007 May 30 14:21:40 cbs kern: [] HiSax_init+0x4dc/0x57a > > [hisax] > > <04>2007 May 30 14:21:40 cbs kern: [] new_inode+0x14/0x76 > > <04>2007 May 30 14:21:40 cbs kern: [] sysfs_add_file+0x1f/0x52 > > <04>2007 May 30 14:21:40 cbs kern: [] > > debug_mutex_add_waiter+0x14/0x24 > > <04>2007 May 30 14:21:40 cbs kern: [] sysfs_new_dirent+0x17/0x56 > > <04>2007 May 30 14:21:40 cbs kern: [] > > sys_init_module+0x1364/0x1439 > > <04>2007 May 30 14:21:40 cbs kern: [] > > vma_prio_tree_insert+0x17/0x2a > > <04>2007 May 30 14:21:40 cbs kern: [] vma_link+0x85/0x8b > > <04>2007 May 30 14:21:40 cbs kern: [] do_mmap_pgoff+0x4e7/0x634 > > <04>2007 May 30 14:21:40 cbs kern: [] sys_mmap2+0x61/0x90 > > <04>2007 May 30 14:21:40 cbs kern: [] syscall_call+0x7/0xb > > <03>2007 May 30 14:21:40 cbs kern: handlers: > > <03>2007 May 30 14:21:40 cbs kern: [] (usb_hcd_irq+0x0/0x4f) > > <00>2007 May 30 14:21:40 cbs kern: Disabling IRQ #11 [...] > > Likely a driver problem - the device is using IRQ 11, but the driver never > actually registered a handler for that interrupt (it's not in the list of > handlers, only USB is). Maybe retrieving the interrupt before > pci_enable_device? (I haven't looked at the code in question.) Thx for your answer. Unfortunately, it didn't help us yet in finding a fix for the problem. The first IRQs are received after the call to pci_enable_device, but before the IRQ handler itself is registered (register_irq). The IRQs seem to be triggered by the write operations to the card registers (byteout()/outb() calls around lines 676ff in sedlbauer.c); the IRQ handler is registered much later, though. The dump above suggests that the kernel relays the interrupts to the USB handler (on the same IRQ) instead - which obviously is wrong. In short: * pci_enable_device * writing to card registers -> triggering interrupts (handler not yet installed -> error) * register interrupt -> fails, as it already was disabled due to the errors Again: thx for your comments. Do you have any further ideas/advice on how to get the driver running? Thomas -- Thomas Vögtleemail: [EMAIL PROTECTED] - http://www.voegtle-clan.de/thomas --
[PATCH] update checkpatch.pl to version 0.03
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
- catch use of volatile
- allow deprecated functions to be listed in feature-removal-schedule.txt
- warn about #ifdef's in c files
- check that spinlock_t and struct mutex use is commented
- report on architecture specific defines being used
- report memory barriers without an associated comment
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
Full changelog:
Andy Whitcroft (19):
catch use of volatile
convert other quoted string checks to common routine
alloc deprecated functions to be listed in feature-removal-schedule.txt
split out the line length and indent for each line
improve switch block handling
handle GNU diff context lines with no leading space
warn about #ifdef's in c files
tidy up tests for signed-off-by using raw mode
check that spinlock_t and struct mutex use is commented
syntax checks for open brace placement may drop off the bottom of hunk
report memory barriers without an associated comment
when a sign off is present but ugly do not report it missing
do not mistake bitfield definitions for indented labels
report on architecture specific defines being used
major update to the operator checks
prevent switch/if/while etc matching foo_switch
generify assignement in condition error message
introduce an operator context marker
Version: 0.03
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
old mode 100644
new mode 100755
index e216d49..9590bbb
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -8,7 +8,7 @@ use strict;
my $P = $0;
-my $V = '0.01';
+my $V = '0.03';
use Getopt::Long qw(:config no_auto_abbrev);
@@ -38,7 +38,8 @@ if ($tree && !top_of_kernel_tree()) {
exit(2);
}
-my @deprecated = ();
+my @dep_includes = ();
+my @dep_functions = ();
my $removal = 'Documentation/feature-removal-schedule.txt';
if ($tree && -f $removal) {
open(REMOVE, "<$removal") || die "$P: $removal: open failed - $!\n";
@@ -46,9 +47,14 @@ if ($tree && -f $removal) {
if (/^Files:\s+(.*\S)/) {
for my $file (split(/[, ]+/, $1)) {
if ($file =~ [EMAIL PROTECTED]/(.*)@) {
- push(@deprecated, $1);
+ push(@dep_includes, $1);
}
}
+
+ } elsif (/^Funcs:\s+(.*\S)/) {
+ for my $func (split(/[, ]+/, $1)) {
+ push(@dep_functions, $func);
+ }
}
}
}
@@ -99,6 +105,97 @@ sub expand_tabs {
return $res;
}
+sub line_stats {
+ my ($line) = @_;
+
+ # Drop the diff line leader and expand tabs
+ $line =~ s/^.//;
+ $line = expand_tabs($line);
+
+ # Pick the indent from the front of the line.
+ my ($white) = ($line =~ /^(\s*)/);
+
+ return (length($line), length($white));
+}
+
+sub ctx_block_get {
+ my ($linenr, $remain, $outer) = @_;
+ my $line;
+ my $start = $linenr - 1;
+ my $end = $linenr - 1 + $remain;
+ my $blk = '';
+ my @o;
+ my @c;
+ my @res = ();
+
+ for ($line = $start; $line < $end; $line++) {
+ $blk .= $lines[$line];
+
+ @o = ($blk =~ /\{/g);
+ @c = ($blk =~ /\}/g);
+
+ if (!$outer || (scalar(@o) - scalar(@c)) == 1) {
+ push(@res, $lines[$line]);
+ }
+
+ last if (scalar(@o) == scalar(@c));
+ }
+
+ return @res;
+}
+sub ctx_block_outer {
+ my ($linenr, $remain) = @_;
+
+ return ctx_block_get($linenr, $remain, 1);
+}
+sub ctx_block {
+ my ($linenr, $remain) = @_;
+
+ return ctx_block_get($linenr, $remain, 0);
+}
+
+sub ctx_locate_comment {
+ my ($first_line, $end_line) = @_;
+
+ # Catch a comment on the end of the line itself.
+ my ($current_comment) = ($lines[$end_line - 1] =~ [EMAIL
PROTECTED](/\*.*\*/)\s*$@);
+ return $current_comment if (defined $current_comment);
+
+ # Look through the context and try and figure out if there is a
+ # comment.
+ my $in_comment = 0;
+ $current_comment = '';
+ for (my $linenr = $first_line; $linenr < $end_line; $linenr++) {
+ my $line = $lines[$linenr - 1];
+ ##warn " $line\n";
+ if ($linenr == $first_line and $line =~ [EMAIL PROTECTED]@) {
+ $in_comment = 1;
+ }
+ if ($line =~ m@/\*@) {
+ $in_comment = 1;
+ }
+ if (!$in_comment && $current_comment ne '') {
+
Re: patch-2.6.21.3-rt9 misnamed?
On Friday 01 June 2007 18:11:11 Matt Mackall wrote:
> On Thu, May 31, 2007 at 10:01:09PM +0200, Ingo Molnar wrote:
> > * K.R. Foley <[EMAIL PROTECTED]> wrote:
> > > Ingo Molnar wrote:
> > > > * K.R. Foley <[EMAIL PROTECTED]> wrote:
> > > >> Ingo,
> > > >>
> > > >> I believe that patch-2.6.21.3-rt9 is misnamed. It applies cleanly to
> > > >> 2.6.21 but seems to contain stuff that is already in 2.6.21.3.
> > > >
> > > > yes - it includes all of 2.6.21.3.
> > > >
> > > > Ingo
> > >
> > > So actually it is not really misnamed, it's just done a bit
> > > differently than previous versions. Sorry.
> >
> > yeah. Maybe we should make the 2.6.21.3 -rt patches relative to 2.6.21.3
> > - but that would be one extra patching step for people who already have
> > a 2.6.21 tree. But ... maybe that makes the most sense after all.
>
> Including 2.6.21.3 in your patch will break ketchup.
ketchup already breaks with the current rt9 patch.
lapdog{rt}$ ketchup -n 2.6-rt
None -> 2.6.21.3-rt9
Unpacking linux-2.6.21.tar.bz2
Applying patch-2.6.21.3.bz2
Applying patch-2.6.21.3-rt9
lapdog{rt}$ head `which ketchup`
#!/usr/bin/python
#
# ketchup 0.9.8
# http://selenic.com/ketchup/wiki
As noted before rt9 is based one 2.6.21 so after ketchup brings the directory
to 2.6.21.3 then applying rt9 fails.
I would appreciate it if you base the rtX patch on the kernel you list as a
prefix of that patch. It helps us that use ketchup and it just makes sense.
-Joachim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/18] fs/logfs/logfs.h
>On Sunday 03 June 2007, Jörn Engel wrote:
>> +/**
>> + * struct logfs_device_ops - device access operations
>> + *
>> + * @read: read from the device
>> + * @write: write to the device
>> + * @erase: erase part of the device
>> + */
>> +struct logfs_device_ops {
>> + int (*read)(struct super_block *sb, loff_t ofs, size_t len, void
>> *buf);
>> + int (*write)(struct super_block *sb, loff_t ofs, size_t len, void
>> *buf);
>> + int (*erase)(struct super_block *sb, loff_t ofs, size_t len);
>> +};
>
>I wonder if there is a way to document the prototypes of these function
>pointers with kerneldoc, other than having a typedef for each.
>
>What brought me to this point is that I first assumed they would return
>the number of bytes transferred, like read/write file operations, where
>your functions return zero on success.
read/write functions returning bytes written would return ssize_t,
just as vfs_read and vfs_write do.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [BUG] Oops with KVM-27
Luca Tettamanti wrote:
Hello,
my kernel just exploded :)
The host is running 2.6-git-current, with KVM modules from KVM-27
package. kernel is 32bit, SMP, with PREEMPT enabled, no HIGHMEM (but I'm
using CONFIG_VMSPLIT_3G_OPT=y). The CPU is a Core2 (hence I'm using
kvm-intel).
Guest was a Fedora7 setup DVD, which died somewhere during the
installation (anaconda was already active at that point). Bad news is
that I cannot reproduce the bug :|
Fortunately the trace clearly shows the problem (out of mmu working
memory on guest context switch). The attached patch should fix it. Let
me know if it works for you.
--
error compiling committee.c: too many arguments to function
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 0632d0b..0fdd5a6 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -543,6 +543,8 @@ void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
const u8 *old, const u8 *new, int bytes);
int kvm_mmu_unprotect_page_virt(struct kvm_vcpu *vcpu, gva_t gva);
void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu);
+int kvm_mmu_load(struct kvm_vcpu *vcpu);
+void kvm_mmu_unload(struct kvm_vcpu *vcpu);
int kvm_hypercall(struct kvm_vcpu *vcpu, struct kvm_run *run);
@@ -554,6 +556,14 @@ static inline int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva,
return vcpu->mmu.page_fault(vcpu, gva, error_code);
}
+static inline int kvm_mmu_reload(struct kvm_vcpu *vcpu)
+{
+ if (likely(vcpu->mmu.root_hpa != INVALID_PAGE))
+ return 0;
+
+ return kvm_mmu_load(vcpu);
+}
+
static inline int is_long_mode(struct kvm_vcpu *vcpu)
{
#ifdef CONFIG_X86_64
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
diff --git a/drivers/kvm/mmu.c b/drivers/kvm/mmu.c
index 283df03..5915d7a 100644
--- a/drivers/kvm/mmu.c
+++ b/drivers/kvm/mmu.c
@@ -949,9 +949,7 @@ static int nonpaging_init_context(struct kvm_vcpu *vcpu)
context->free = nonpaging_free;
context->root_level = 0;
context->shadow_root_level = PT32E_ROOT_LEVEL;
- mmu_alloc_roots(vcpu);
- ASSERT(VALID_PAGE(context->root_hpa));
- kvm_arch_ops->set_cr3(vcpu, context->root_hpa);
+ context->root_hpa = INVALID_PAGE;
return 0;
}
@@ -965,11 +963,6 @@ static void paging_new_cr3(struct kvm_vcpu *vcpu)
{
pgprintk("%s: cr3 %lx\n", __FUNCTION__, vcpu->cr3);
mmu_free_roots(vcpu);
- if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
- kvm_mmu_free_some_pages(vcpu);
- mmu_alloc_roots(vcpu);
- kvm_mmu_flush_tlb(vcpu);
- kvm_arch_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
}
static void inject_page_fault(struct kvm_vcpu *vcpu,
@@ -1003,10 +996,7 @@ static int paging64_init_context_common(struct kvm_vcpu *vcpu, int level)
context->free = paging_free;
context->root_level = level;
context->shadow_root_level = level;
- mmu_alloc_roots(vcpu);
- ASSERT(VALID_PAGE(context->root_hpa));
- kvm_arch_ops->set_cr3(vcpu, context->root_hpa |
- (vcpu->cr3 & (CR3_PCD_MASK | CR3_WPT_MASK)));
+ context->root_hpa = INVALID_PAGE;
return 0;
}
@@ -1025,10 +1015,7 @@ static int paging32_init_context(struct kvm_vcpu *vcpu)
context->free = paging_free;
context->root_level = PT32_ROOT_LEVEL;
context->shadow_root_level = PT32E_ROOT_LEVEL;
- mmu_alloc_roots(vcpu);
- ASSERT(VALID_PAGE(context->root_hpa));
- kvm_arch_ops->set_cr3(vcpu, context->root_hpa |
- (vcpu->cr3 & (CR3_PCD_MASK | CR3_WPT_MASK)));
+ context->root_hpa = INVALID_PAGE;
return 0;
}
@@ -1042,7 +1029,6 @@ static int init_kvm_mmu(struct kvm_vcpu *vcpu)
ASSERT(vcpu);
ASSERT(!VALID_PAGE(vcpu->mmu.root_hpa));
- mmu_topup_memory_caches(vcpu);
if (!is_paging(vcpu))
return nonpaging_init_context(vcpu);
else if (is_long_mode(vcpu))
@@ -1064,16 +1050,31 @@ static void destroy_kvm_mmu(struct kvm_vcpu *vcpu)
int kvm_mmu_reset_context(struct kvm_vcpu *vcpu)
{
+ destroy_kvm_mmu(vcpu);
+ return init_kvm_mmu(vcpu);
+}
+
+int kvm_mmu_load(struct kvm_vcpu *vcpu)
+{
int r;
- destroy_kvm_mmu(vcpu);
- r = init_kvm_mmu(vcpu);
- if (r < 0)
- goto out;
+ spin_lock(&vcpu->kvm->lock);
r = mmu_topup_memory_caches(vcpu);
+ if (r)
+ goto out;
+ mmu_alloc_roots(vcpu);
+ kvm_arch_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
+ kvm_mmu_flush_tlb(vcpu);
out:
+ spin_unlock(&vcpu->kvm->lock);
return r;
}
+EXPORT_SYMBOL_GPL(kvm_mmu_load);
+
+void kvm_mmu_unload(struct kvm_vcpu *vcpu)
+{
+ mmu_free_roots(vcpu);
+}
static void mmu_pte_write_zap_pte(struct kvm_vcpu *vcpu,
struct kvm_mmu_page *page,
diff --git a/drivers/kvm/paging_tmpl.h b/drivers/kvm/paging_tmpl.h
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index b621403..ed33f59 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1482,6 +1482,10 @@ static int svm_vcpu_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
int r;
again:
+ r = kvm_mmu_reload(vcpu);
+ if (unlikely(r))
+ return r;
+
if (!vcpu->mmio_read_completed)
do_interrupt_requests(vcpu, kvm_run);
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 09e3609..a499989 100644
--- a/drivers/kvm/vmx
Re: RTC_DRV_CMOS can break userspace interface
On Fri, Jun 01, 2007 at 13:54:23 +0100, Matthew Garrett wrote: > On Fri, Jun 01, 2007 at 09:46:06AM +0200, Tino Keitel wrote: > > Yes, you are right. I think this issue should be covered by Kconfig. > > > > However: > > > > $ cat wakealarm > > cat: wakealarm: Input/output error > > > > It worked with /proc/acpi/alarm before. > > Can you do > > for i in /sys/bus/pnp/devices/*; do if [ "$(cat $i/id)" = PNP0b00 ]; > then cat $i/resources; echo options; cat $i/options; fi; done Here it is: state = active io 0x70-0x77 options Regards, Tino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Q] Bio traversal trouble?
Hi Jens, list.
The new Mitsumi legacy CD-ROM driver seems largely done. Both audio and data
work (and the driver's clean) but data does still have a problem that I think
needs some input from a block person. I don't have any idea...
Audio is fine, and data basically as well. It's performing at maximum drive
speed (and gets the correct data):
[EMAIL PROTECTED]:~# dd if=/dev/mitsumi of=/dev/null bs=2k count=8k
8192+0 records in
8192+0 records out
16777216 bytes (17 MB) copied, 111.379 seconds, 151 kB/s
Unfortunately, I can make the box oops by just doing enough of those dd runs in
a row (this one with bs=2k count=128, oopsed the seventh time or something):
===
BUG: unable to handle kernel paging request at virtual address 8c1d2071
printing eip:
c10a6d6f
*pde =
Oops: 0002 [#1]
Modules linked in: mitsumi nfsd exportfs lockd sunrpc nls_cp437 msdos fat
nls_base
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.21.3 #1)
EIP is at ioread8_rep+0x20/0x31
eax: 0001 ebx: 00010300 ecx: 0800 edx: 0300
esi: c3145b30 edi: 8c1d2071 ebp: 8c1d2071 esp: c3145aec
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process dd (pid: 1770, ti=c3145000 task=c3114110 task.ti=c3145000)
Stack: c3a7ad48 c486504d c4865ab7 0006 50020034 c1015f7b 0292
00520300 0100 0007e000 c3340300 c10a0531
c12adf60 0001 dead4ead
Call Trace:
[] __mitsumi_get_frame+0xc/0x16 [mitsumi]
[] mitsumi_get_frame+0x120/0x134 [mitsumi]
[] lock_timer_base+0x15/0x2f
[] cfq_set_request+0x0/0x144
[] _spin_unlock_irq+0x20/0x23
[] mempool_free+0x5f/0x64
[] mitsumi_read+0x62/0x94 [mitsumi]
[] mitsumi_request+0x49/0xb5 [mitsumi]
[] blk_start_queueing+0x14/0x1c
[] elv_insert+0xa3/0x13f
[] _spin_lock_irq+0x2f/0x3a
[] __make_request+0x29f/0x2d3
[] generic_make_request+0x136/0x146
[] kmem_cache_alloc+0x93/0x9e
[] mempool_alloc+0x32/0xcd
[] mempool_alloc+0x32/0xcd
[] submit_bio+0xa4/0xaa
[] bio_alloc_bioset+0xb2/0x112
[] submit_bh+0xc2/0xdb
[] block_read_full_page+0x245/0x252
[] blkdev_get_block+0x0/0x36
[] _write_unlock_irq+0x20/0x23
[] add_to_page_cache+0x71/0x78
[] read_pages+0x7c/0xc1
[] _read_unlock_irq+0x20/0x23
[] _read_unlock_irq+0x20/0x23
[] trace_hardirqs_on+0x11b/0x13e
[] __do_page_cache_readahead+0xed/0x107
[] blockable_page_cache_readahead+0x4d/0x9d
[] make_ahead_window+0x84/0xa5
[] page_cache_readahead+0x13c/0x15b
[] file_read_actor+0x7f/0x102
[] do_generic_mapping_read+0x110/0x3fa
[] generic_file_aio_read+0x187/0x1b0
[] file_read_actor+0x0/0x102
[] do_sync_read+0xbf/0xfc
[] autoremove_wake_function+0x0/0x33
[] dnotify_parent+0x1b/0x66
[] vfs_write+0xc9/0xff
[] __lock_release+0x2d/0x3f
[] vfs_read+0x87/0xfd
[] sys_read+0x41/0x67
[] syscall_call+0x7/0xb
===
Code: 00 00 89 c8 ef c3 0f c9 89 0a c3 57 3d ff ff 03 00 53 89 d7 89 c3 89 ca 77
15 66 31 c0 3d 00 00 01 00 74 04 0f 0b eb fe 0f b7 d3 6c eb 0a 4a 78 07 8a
03 88 07 47 eb f6 5b 5f c3 57 3d ff ff
EIP: [] ioread8_rep+0x20/0x31 SS:ESP 0068:c3145aec
===
This is obviously not good.
Since the last time this driver was posted it changed considerably and as one of
the chances it's now requesting just one hardware sector ("frame") at a time
from the drive as requesting multiple didn't actually work -- I seemed to have
fouled up earlier tests somehow.
The driver could let the block layer handle just doing one frame at a time by
completing only one frame (4 sectors) each time but this is not a good idea.
Things are somewhat timing sensitive since if you're too late the next sector
has passed below you (and if you're too early you're overrunning the drive)
causing throughput to plummet.
I'd also simply like to understand it, so this is doing a manual bio traversal,
requesting frames from the hardware as it goes along. The driver's main request
function is:
static void mitsumi_request(struct request_queue *q)
{
struct request *req;
while ((req = elv_next_request(q))) {
struct bio *bio;
int sectors = 0;
if (!blk_fs_request(req)) {
end_request(req, 0);
continue;
}
if (rq_data_dir(req) != READ) {
printk(KERN_WARNING
"mitsumi: non-read request to CD\n");
end_request(req, 0);
continue;
}
spin_unlock_irq(q->queue_lock);
rq_for_each_bio(bio, req) {
unsigned int bytes;
bytes = mitsumi_read(req->rq_disk->private_data, bio);
sectors += bytes >> 9;
if (bytes != bio->bi_size)
break;
}
spin_lock_irq(q->queue_lock);
Re: [PATCH] fix race in AF_UNIX
> A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> send()+close() on the peer, causing recv() to return zero, even though
> the sent data should be received.
>
> This happens if the send() and the close() is performed between
> skb_dequeue() and checking sk->sk_shutdown in unix_stream_recvmsg():
>
> process A skb_dequeue() returns NULL, there's no data in the socket queue
> process B new data is inserted onto the queue by unix_stream_sendmsg()
> process B sk->sk_shutdown is set to SHUTDOWN_MASK by unix_release_sock()
> process A sk->sk_shutdown is checked, unix_release_sock() returns zero
This is only part of the story. It turns out, there are other races
involving the garbage collector, that can throw away perfectly good
packets with AF_UNIX sockets in them.
The problems arise when a socket goes from installed to in-flight or
vica versa during garbage collection. Since gc is done with a
spinlock held, this only shows up on SMP.
The following patch fixes it for me, but it's possibly the wrong
approach.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc2/net/unix/garbage.c
===
--- linux-2.6.22-rc2.orig/net/unix/garbage.c2007-06-03 23:58:11.0
+0200
+++ linux-2.6.22-rc2/net/unix/garbage.c 2007-06-04 11:39:42.0 +0200
@@ -90,6 +90,7 @@
static struct sock *gc_current = GC_HEAD; /* stack of objects to mark */
atomic_t unix_tot_inflight = ATOMIC_INIT(0);
+DECLARE_RWSEM(unix_gc_sem);
static struct sock *unix_get_socket(struct file *filp)
@@ -169,7 +170,7 @@ static void maybe_unmark_and_push(struct
void unix_gc(void)
{
- static DEFINE_MUTEX(unix_gc_sem);
+ static DEFINE_MUTEX(unix_gc_local_lock);
int i;
struct sock *s;
struct sk_buff_head hitlist;
@@ -179,9 +180,22 @@ void unix_gc(void)
* Avoid a recursive GC.
*/
- if (!mutex_trylock(&unix_gc_sem))
+ if (!mutex_trylock(&unix_gc_local_lock))
return;
+
+ /*
+* unix_gc_sem protects against sockets going from in-flight to
+* installed
+*
+* Can't sleep on this, because skb_recv_datagram could be
+* waiting for a packet that is to be sent by the thread which
+* invoked the gc
+*/
+ if (!down_write_trylock(&unix_gc_sem)) {
+ mutex_unlock(&unix_gc_local_lock);
+ return;
+ }
spin_lock(&unix_table_lock);
forall_unix_sockets(i, s)
@@ -207,8 +221,6 @@ void unix_gc(void)
forall_unix_sockets(i, s)
{
- int open_count = 0;
-
/*
* If all instances of the descriptor are not
* in flight we are in use.
@@ -218,10 +230,20 @@ void unix_gc(void)
* In this case (see unix_create1()) we set artificial
* negative inflight counter to close race window.
* It is trick of course and dirty one.
+*
+* Get the inflight counter first, then the open
+* counter. This avoids problems if racing with
+* sendmsg
+*
+* If just created socket is not yet attached to
+* a file descriptor, assume open_count of 1
*/
+ int inflight_count = atomic_read(&unix_sk(s)->inflight);
+ int open_count = 1;
+
if (s->sk_socket && s->sk_socket->file)
open_count = file_count(s->sk_socket->file);
- if (open_count > atomic_read(&unix_sk(s)->inflight))
+ if (open_count > inflight_count)
maybe_unmark_and_push(s);
}
@@ -302,11 +324,12 @@ void unix_gc(void)
u->gc_tree = GC_ORPHAN;
}
spin_unlock(&unix_table_lock);
+ up_write(&unix_gc_sem);
/*
* Here we are. Hitlist is filled. Die.
*/
__skb_queue_purge(&hitlist);
- mutex_unlock(&unix_gc_sem);
+ mutex_unlock(&unix_gc_local_lock);
}
Index: linux-2.6.22-rc2/include/net/af_unix.h
===
--- linux-2.6.22-rc2.orig/include/net/af_unix.h 2007-04-26 05:08:32.0
+0200
+++ linux-2.6.22-rc2/include/net/af_unix.h 2007-06-04 09:13:56.0
+0200
@@ -14,6 +14,7 @@ extern void unix_gc(void);
extern struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
extern spinlock_t unix_table_lock;
+extern struct rw_semaphore unix_gc_sem;
extern atomic_t unix_tot_inflight;
Index: linux-2.6.22-rc2/net/unix/af_unix.c
===
--- linux-2.6.22-rc2.orig/net/unix/af_unix.c2007-06-03 23:58:11.0
+0200
+++ linux-2.6.22-rc2/net/unix/af_unix.c 2007-06-04 11:04:15.0 +0200
@@
Re: libata & no PCI: dma_[un]map_single undefined
[ Your email has `m68k' in the body, so I read it :-]
On Sun, 3 Jun 2007, David Miller wrote:
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index b4a8d60..7d893a6 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -8,6 +8,7 @@ menuconfig ATA
> depends on BLOCK
> depends on !(M32R || M68K) || BROKEN
> depends on !SUN4 || BROKEN
> + depends on !(SPARC64 && !PCI)
> select SCSI
Isn't `!SPARC64 || PCI' more readable?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix race in AF_UNIX
(resend, sorry, fscked up the address list)
> A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> send()+close() on the peer, causing recv() to return zero, even though
> the sent data should be received.
>
> This happens if the send() and the close() is performed between
> skb_dequeue() and checking sk->sk_shutdown in unix_stream_recvmsg():
>
> process A skb_dequeue() returns NULL, there's no data in the socket queue
> process B new data is inserted onto the queue by unix_stream_sendmsg()
> process B sk->sk_shutdown is set to SHUTDOWN_MASK by unix_release_sock()
> process A sk->sk_shutdown is checked, unix_release_sock() returns zero
This is only part of the story. It turns out, there are other races
involving the garbage collector, that can throw away perfectly good
packets with AF_UNIX sockets in them.
The problems arise when a socket goes from installed to in-flight or
vica versa during garbage collection. Since gc is done with a
spinlock held, this only shows up on SMP.
The following patch fixes it for me, but it's possibly the wrong
approach.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux-2.6.22-rc2/net/unix/garbage.c
===
--- linux-2.6.22-rc2.orig/net/unix/garbage.c2007-06-03 23:58:11.0
+0200
+++ linux-2.6.22-rc2/net/unix/garbage.c 2007-06-04 11:39:42.0 +0200
@@ -90,6 +90,7 @@
static struct sock *gc_current = GC_HEAD; /* stack of objects to mark */
atomic_t unix_tot_inflight = ATOMIC_INIT(0);
+DECLARE_RWSEM(unix_gc_sem);
static struct sock *unix_get_socket(struct file *filp)
@@ -169,7 +170,7 @@ static void maybe_unmark_and_push(struct
void unix_gc(void)
{
- static DEFINE_MUTEX(unix_gc_sem);
+ static DEFINE_MUTEX(unix_gc_local_lock);
int i;
struct sock *s;
struct sk_buff_head hitlist;
@@ -179,9 +180,22 @@ void unix_gc(void)
* Avoid a recursive GC.
*/
- if (!mutex_trylock(&unix_gc_sem))
+ if (!mutex_trylock(&unix_gc_local_lock))
return;
+
+ /*
+* unix_gc_sem protects against sockets going from in-flight to
+* installed
+*
+* Can't sleep on this, because skb_recv_datagram could be
+* waiting for a packet that is to be sent by the thread which
+* invoked the gc
+*/
+ if (!down_write_trylock(&unix_gc_sem)) {
+ mutex_unlock(&unix_gc_local_lock);
+ return;
+ }
spin_lock(&unix_table_lock);
forall_unix_sockets(i, s)
@@ -207,8 +221,6 @@ void unix_gc(void)
forall_unix_sockets(i, s)
{
- int open_count = 0;
-
/*
* If all instances of the descriptor are not
* in flight we are in use.
@@ -218,10 +230,20 @@ void unix_gc(void)
* In this case (see unix_create1()) we set artificial
* negative inflight counter to close race window.
* It is trick of course and dirty one.
+*
+* Get the inflight counter first, then the open
+* counter. This avoids problems if racing with
+* sendmsg
+*
+* If just created socket is not yet attached to
+* a file descriptor, assume open_count of 1
*/
+ int inflight_count = atomic_read(&unix_sk(s)->inflight);
+ int open_count = 1;
+
if (s->sk_socket && s->sk_socket->file)
open_count = file_count(s->sk_socket->file);
- if (open_count > atomic_read(&unix_sk(s)->inflight))
+ if (open_count > inflight_count)
maybe_unmark_and_push(s);
}
@@ -302,11 +324,12 @@ void unix_gc(void)
u->gc_tree = GC_ORPHAN;
}
spin_unlock(&unix_table_lock);
+ up_write(&unix_gc_sem);
/*
* Here we are. Hitlist is filled. Die.
*/
__skb_queue_purge(&hitlist);
- mutex_unlock(&unix_gc_sem);
+ mutex_unlock(&unix_gc_local_lock);
}
Index: linux-2.6.22-rc2/include/net/af_unix.h
===
--- linux-2.6.22-rc2.orig/include/net/af_unix.h 2007-04-26 05:08:32.0
+0200
+++ linux-2.6.22-rc2/include/net/af_unix.h 2007-06-04 09:13:56.0
+0200
@@ -14,6 +14,7 @@ extern void unix_gc(void);
extern struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
extern spinlock_t unix_table_lock;
+extern struct rw_semaphore unix_gc_sem;
extern atomic_t unix_tot_inflight;
Index: linux-2.6.22-rc2/net/unix/af_unix.c
===
--- linux-2.6.22-rc2.orig/net/unix/af_unix.c2007-06-03 23:58:11.0
+0200
+++ linux-2.6.22-rc2/net/unix/af_u
[PATCH] update feature-removal-schedule.txt to include deprecated functions
Now that deprecated functions are detected out of Documentation/feature-removal-schedule.txt update this to include kernel_thread. Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]> --- This was missed from the update to checkpatch.pl version 0.03 patch, and probabally should be folded into there. --- diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index e88baca..bc366cb 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -87,6 +87,7 @@ Who: Mauro Carvalho Chehab <[EMAIL PROTECTED]> What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c +Funcs: kernel_thread Why: kernel_thread is a low-level implementation detail. Drivers should use the API instead which shields them from implementation details and provides a higherlevel interface that - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patch-2.6.21.3-rt9 misnamed?
* Joachim Deguara <[EMAIL PROTECTED]> wrote: > > Including 2.6.21.3 in your patch will break ketchup. > > ketchup already breaks with the current rt9 patch. we'll release -rt10 probably later today, which will fix this. (it will be named 2.6.21.3-rt10 and will be against 2.6.21.3) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/2] m68k 53c700 SCSI
On Sun, Jun 03, 2007 at 01:21:36PM +0200, Geert Uytterhoeven wrote:
> Hi James,
>
> Here are the updates for m68k 53c700 SCSI drivers:
> [1] m68k: BVME6000 and MVME16x SCSI driver rename
> [2] m68k: switch to 53c700 driver
As I mentioned in the description for the 53c7xx removal patch I
think it's cleaner to just remove the old and re-add the new drivers
when there is nothing left of the content at all and they are renamed
aswell.
Also the amiga7xx driver should probably be split into two, as the
a4000t internal code shares nothing with the zorro bus cards.
So I'd suggest you repost a patch series onto of the current scsi-misc
tree consisting of:
1/n changes to the 53c700 driver for m68k support
2/n new BVME6000 driver
3/n new MVME16x driver
4/n new a4000t driver
5/n new zorror 53x700 driver
That beeing said the actual code looks very nice. I've attached a small
patch cleaning up some minor codingstyle deficiencies and switching to
the new shost_priv accessor that's in the scsi-misc tree.
Index: linux-2.6/drivers/scsi/amiga7xx.c
===
--- linux-2.6.orig/drivers/scsi/amiga7xx.c 2007-06-04 10:48:03.0
+0200
+++ linux-2.6/drivers/scsi/amiga7xx.c 2007-06-04 10:52:44.0 +0200
@@ -101,7 +101,6 @@ static int __devinit amiga7xx_init_one(s
}
hostdata = kmalloc(sizeof(struct NCR_700_Host_Parameters), GFP_KERNEL);
-
if (hostdata == NULL) {
printk(KERN_ERR "amiga7xx: Failed to allocate host data\n");
goto out_release;
@@ -124,9 +123,11 @@ static int __devinit amiga7xx_init_one(s
amiga7xx_scsi_driver_template.name = zdd->name;
/* and register the chip */
- if ((host = NCR_700_detect(&amiga7xx_scsi_driver_template, hostdata,
&z->dev))
- == NULL) {
- printk(KERN_ERR "amiga7xx-scsi: No host detected; board
configuration problem?\n");
+ host = NCR_700_detect(&amiga7xx_scsi_driver_template,
+ hostdata, &z->dev);
+ if (!host) {
+ printk(KERN_ERR "amiga7xx-scsi: No host detected; "
+ "board configuration problem?\n");
goto out_free;
}
@@ -134,7 +135,8 @@ static int __devinit amiga7xx_init_one(s
host->base = ioaddr;
host->irq = IRQ_AMIGA_PORTS;
- if (request_irq(host->irq, NCR_700_intr, IRQF_SHARED, "amiga7xx-scsi",
host)) {
+ if (request_irq(host->irq, NCR_700_intr, IRQF_SHARED,
+ "amiga7xx-scsi", host)) {
printk(KERN_ERR "amiga7xx-scsi: request_irq failed\n");
goto out_put_host;
}
@@ -158,8 +160,7 @@ static int __devinit amiga7xx_init_one(s
static __devexit void amiga7xx_remove_one(struct zorro_dev *z)
{
struct Scsi_Host *host = dev_to_shost(&z->dev);
- struct NCR_700_Host_Parameters *hostdata =
- (struct NCR_700_Host_Parameters *)host->hostdata[0];
+ struct NCR_700_Host_Parameters *hostdata = shost_priv(host);
scsi_remove_host(host);
@@ -188,7 +189,8 @@ static int __devinit a4000t_probe(struct
if (!(MACH_IS_AMIGA && AMIGAHW_PRESENT(A4000_SCSI)))
goto out;
- if (!request_mem_region(A4000T_SCSI_ADDR, 0x1000, "A4000T builtin
SCSI"))
+ if (!request_mem_region(A4000T_SCSI_ADDR, 0x1000,
+ "A4000T builtin SCSI"))
goto out;
hostdata = kmalloc(sizeof(struct NCR_700_Host_Parameters), GFP_KERNEL);
@@ -206,9 +208,10 @@ static int __devinit a4000t_probe(struct
hostdata->dcntl_extra = EA_710;
/* and register the chip */
- if ((host = NCR_700_detect(&amiga7xx_scsi_driver_template, hostdata,
dev))
- == NULL) {
- printk(KERN_ERR "a4000t-scsi: No host detected; board
configuration problem?\n");
+ host = NCR_700_detect(&amiga7xx_scsi_driver_template, hostdata, dev);
+ if (!host) {
+ printk(KERN_ERR "a4000t-scsi: No host detected; "
+ "board configuration problem?\n");
goto out_free;
}
@@ -238,8 +241,7 @@ static int __devinit a4000t_probe(struct
static __devexit int a4000t_device_remove(struct device *dev)
{
struct Scsi_Host *host = dev_to_shost(dev);
- struct NCR_700_Host_Parameters *hostdata =
- (struct NCR_700_Host_Parameters *)host->hostdata[0];
+ struct NCR_700_Host_Parameters *hostdata = shost_priv(host);
scsi_remove_host(host);
@@ -262,11 +264,12 @@ static int __init amiga7xx_scsi_init(voi
{
int err;
- if ((err = driver_register(&a4000t_scsi_driver)))
+ err = driver_register(&a4000t_scsi_driver);
+ if (err)
return err;
- a4000t_scsi_device = platform_device_register_simple("a4000t-scsi", -1,
NULL, 0);
-
+ a4000t_scsi_device = platform_device_register_simple("a4000t
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
On Mon, 4 Jun 2007 01:34:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 4 Jun 2007 10:09:41 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > * Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > i think this sums it up: > > > > > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0705.3/2490.html > > > > i mean this mail started it: > > > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13070.html > > > > > and some more, with a benchmark as well: > > > > > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-05/msg13685.html > > > > Yeah, I remember all that but I don't think it provides a suitable > description of what all this code is there for - what problem it is > solving and how it solves it. > > If we just want some pseudo-private fd space for glibc to use then I'd have > thought that the existing code could be tweaked to do that: top-down > allocation, start at some high offset, etc. But apparently there's more > to it than this. Goals : 1) libc wants 'private fds' 2) Latencies of get_unused_fd() for huge processes (more than 100.000 file handles) Point 1) can use a top-down allocation, or use a 'last unused' index. Point 2) Instead of introducing a *complex* layer, couldnt we improve existing one ? If the main problem we want to solve is the potentially slow bitmap search, we could logically divide the open_fds bitmap into pages (4096*8 = 32768 bits per page on i386/x86_64 arches) We would have to add a new field in 'struct fdtable', pointer to an array of u32 counters, that would count the number of 'one' bits in each PAGE. This array is tiny : 128 bytes only for 1.000.000 file handles get_unused_fd() could then use this array to select an appropriate page (a page known to have at least one zero bit), then do a find_next_zero_bit() restricted to at most PAGE_SIZE bytes. Max latency would be similar to vm one when clearing a page. If applications use Point 1) hint (asking kernel one fd, not the POSIX low fd), typical latency will be null. Old applications (still asking for POSIX "give me the lowest fd crap") would benefit from this, without recompilation or glibc change. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
WARNING: at mm/slab.c:777 __find_general_cachep() in 2.6.22-rc3
While testing 2.6.22-rc3 I sometime get the following message in syslog: WARNING: at mm/slab.c:777 __find_general_cachep() [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] === The system works fine, as far as I can tell, but I thought you might be interested. The hardware is a Lenovo laptop 3000 series, model N100, the processor is a Centrino Duo. .config attached. Regards, Biker config.gz Description: GNU Zip compressed data
Re: alpha modpost warnings
> > Something for COMMON symbols was fixed for powerpc recently, the warning > is gone there. For PowerPC the symbol was declared .common in the .S file. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A kexec approach to hibernation
Hi! > >> But kernel threads also rely on userspace, due to e.g. fuse and usermode > >> helpers. > > > Yes, I know that and I think these issues are solvable within the current > > approach. > > It seems like it would be very hard to get writing of an image to a > fuse filesystem working under the current scheme. > > Trying to image a system while it is running seems fundamentally broken. > As another example, I believe currently although devices are "quiesced" > or stopped while the atomic snapshot is made, they are all then started > again afterward while the image is written to disk. As a result, the > network drivers will continue acking TCP packets that are received after > the snapshot, but these packets will be lost. > > You might claim then that the solution is to simply keep the network > driver quiesced or stopped. But then it is impossible to write the > image over the network. The way to get around this problem is to write > the image over the network using a fresh network stack. The "fresh network stack" will RST any connections that were going, which is ugly, too. > >> Grub, its configuration, and the kernel used to resume the system had > >> better be on a "safe" filesystem already (i.e. a separate, unmounted > >> before hibernation /boot). > > > Currently, you don't need to do that. > > Some people get away with it, but fundamentally it is broken to do so. > (The fact that the current software suspend implementations tell the > filesystems to sync to disk increases its chances of working.) You are > accessing a filesystem that is in an unknown state. Consider that the > user might make a change to grub.conf, but the kernel caches the write. > If the filesystem containing grub.conf is left mounted, the write might > never reach disk before the system is hibernated. As a result, when > grub attempts to read it, it doesn't get the expected data. sync is perfectly safe way of telling the fs to store data on disk. > >> That is why I think the kexec solution is the elegant solution. > > > Frankly, I think it's tricky. ;-) > > To me, it seems a lot easier to get right than the current approaches. Well, you are certainly welcome to create the patch. "suspend3" name is still free, AFAICT. If _I_ were willing to add some runtime overhead to make hibernation simpler, I'd just use some virtualization to do that... with added advantage of "hibernate here, resume on different hw". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stallion driver dmesg notice
Jiri Slaby <[EMAIL PROTECTED]> writes: > Okay, tty alloc after pci init, attached patch should fix it. Could you > retest? Loads find and seems to work with basic tests (and no character loss, yay!). I'll try 8-link bonded ppp when I've set up a second box. -ik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] powernow-k8: depend on acpi-processor for SMP systems
On Thu 2007-05-17 06:24:22, Ed Sweetman wrote: > Pavel Machek wrote: > >Hi! > > > > > >>powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but > >>on SMP it requires the acpi-processor driver. Kconfig should be updated > >>accordingly to avoid the issues that users are running into. > >> > >>http://bugzilla.kernel.org/show_bug.cgi?id=8075 > >>https://bugs.gentoo.org/show_bug.cgi?id=178585 > >> > >>Signed-off-by: Daniel Drake <[EMAIL PROTECTED]> > >> > >>Index: linux/arch/i386/kernel/cpu/cpufreq/Kconfig > >>=== > >>--- linux.orig/arch/i386/kernel/cpu/cpufreq/Kconfig > >>+++ linux/arch/i386/kernel/cpu/cpufreq/Kconfig > >>@@ -81,6 +81,7 @@ config X86_POWERNOW_K7_ACPI > >> config X86_POWERNOW_K8 > >>tristate "AMD Opteron/Athlon64 PowerNow!" > >>select CPU_FREQ_TABLE > >>+ select ACPI_PROCESSOR if SMP > >>depends on EXPERIMENTAL > >>help > >> This adds the CPUFreq driver for mobile AMD Opteron/Athlon64 > >> processors. > >> > > > >It is still possible to run SMP kernel on UP machine -- so this sounds > >wrong. > > It's possible to run a kernel with drivers for hardware you dont have. > But not having the dependencies correct for those drivers for that > hardware you dont have just because it's possible you can run a kernel > with those drivers without that hardware isn't correct. Got it? Breaking working configs is not fine, got it? We are having the thing called "stable release" here. Feel free to fix code to decide during runtime. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote: > On Tuesday 15 May 2007 11:14, Pavel Machek wrote: > > Why is this configurable? > > The maximum length of a pathname is an arbitrary limit: we don't want to > allocate arbitrary amounts of of kernel memory for pathnames so we introduce > this limit and set it to a reasonable value. In the unlikely case that > someone uses insanely long pathnames, this limit can be increased. vfs does not have configurable pathname limit, and I do not see what is so special about AA to require this kind of uglyness. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gmail is a bit too popular..
On Tue, 2007-05-08 at 08:43 +0200, Adrian Bunk wrote: > BTW (not related to gmail): > Are there any news regarding the buggy 451 handling in zmailer I'm > reporting again and again that regularly results in every single > linux-kernel message sent to me being delayed by up to 13 hours? Er, you're giving it a 451 response to _every_ message? Why? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: WARNING: at mm/slab.c:777 __find_general_cachep() in 2.6.22-rc3
On 6/4/07, Biker <[EMAIL PROTECTED]> wrote: WARNING: at mm/slab.c:777 __find_general_cachep() [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Please, enable CONFIG_DEBUG_BUGVERBOSE, or decipher addresses into function calls yourself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: lid switch hangs notebook
Hi. The problem reported below has not been solved, I tried with the last stable kernel 2.6.21.3. But it seems not to be an ACPI issue, I removed ACPI support from the kernel, and still have the problem. What else could be? On 4/13/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote: On Thursday 15 March 2007 13:06, Andrew Morton wrote: > > On Mon, 12 Mar 2007 15:53:18 +0100 "Antonio Mignolli" <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm running a slackware 10.2 on a HP/Compaq nx5000. > > > > With kernels <= 2.6.17.3 I didn't have problems. > > Starting from 2.6.19 if I close the notebook's video, > > or if I press the lid switch, > > after a couple of time, or after a few seconds, the o.s. hangs > > completely. The only thing to do is a brute power off > > by pressing for 5 seconds the power button > > (If I press for few it should do a clean shutdown -h). > > I've tried 2.6.19, 2.6.19.1, 2.6.19.2, 2.6.20, 2.6.20.1, 2.6.20.2, > > and all of them seem to give problems. > > > > I don't have KERNEL_DEBUG set, so I haven't any debug informations, > > I will be happy to activate it and provide more info if someone suggests > > me which debug parameters I should set. > > There's nothing in /var/log/messages and /var/log/syslog, > > except for the message "LID switch" added by me > > with a logger command in /etc/acpi/acpi_handler.sh. > > I've put it after noticing the problem, in order to be sure the event was > > detected, and it was. > > I guess this is an ACPI think, although not necessarily. > > Len & co: do you think we should ask Antonio to raise a report > against ACPI at bugzilla.kernel.org? I don't see a response to this on the linux-acpi list. Did the problem get resolved? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend
Hi! > > > The theoretical answer is that it behaves the way we want. The kernel > > > thread does selective resumes in response to device requests. If such > > > a request comes in while the system is asleep it will awaken the > > > system; so it's only logical that a request coming in while the system > > > is in the process of going to sleep should abort the suspend. > > > > I'd say that it shows ppc being broken. User wanted to suspend the > > system, and now unrelated task did lsusb... and system will not sleep. > > > > AFAICT it is DoS issue -- if one of your users keeps doing lsusb, root > > will not be able to suspend the system. > > This is a matter of one's philosophy. In suspend-to-RAM, should tasks > be frozen or should I/O queues be frozen? > > With the USB subsystem I have followed the approach taken by the PM > core, which is that tasks are frozen. But one can -- and Linus has on > at least one occasion -- make a good case that tasks should be left > running while only I/O is frozen. This would require the subsystem to > distinguish between a selective device suspend and a system-wide > suspend-to-RAM, so that selective resume could be enabled on demand in > one case but not the other. > > It's quite doable in principle -- it's just not the technique I used. I guess we need to do that. Random user should not be able to prevent machine from sleeping. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.21.1] resume doesn't run suspended kernel?
Hi! > > > They are already. > > > > ...but will that place still be safe when we use other version of > > kernel? > > They'll be in the image too, won't they? Failing that, the information > could be stored in the image header. > > > Anyway, pagedirs are on the safe place, right? That means that we > > swsusp should no longer clash with page allocation debugging... > > You mean DEBUG_PAGEALLOC? That can be overcome easily - I have code in > current Suspend2 that works with DEBUG_PAGEALLOC. I handle the page > fault, mapping the page and setting a flag in the fault handler to tell > the atomic copy code to unmap the page again once it has been copied. I meant debug_pagealloc, but no, I do not think we want to make page fault handler more complex. Switching to 1:1 mapping tables should be enough. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.21.1] resume doesn't run suspended kernel?
Hi.
On Mon, 2007-06-04 at 13:02 +0200, Pavel Machek wrote:
> Hi!
>
> > > > They are already.
> > >
> > > ...but will that place still be safe when we use other version of
> > > kernel?
> >
> > They'll be in the image too, won't they? Failing that, the information
> > could be stored in the image header.
> >
> > > Anyway, pagedirs are on the safe place, right? That means that we
> > > swsusp should no longer clash with page allocation debugging...
> >
> > You mean DEBUG_PAGEALLOC? That can be overcome easily - I have code in
> > current Suspend2 that works with DEBUG_PAGEALLOC. I handle the page
> > fault, mapping the page and setting a flag in the fault handler to tell
> > the atomic copy code to unmap the page again once it has been copied.
>
> I meant debug_pagealloc, but no, I do not think we want to make page
> fault handler more complex. Switching to 1:1 mapping tables should be
> enough.
> Pavel
@@ -311,6 +315,20 @@ fastcall void __kprobes do_page_fault(struct pt_regs *regs,
si_code = SEGV_MAPERR;
+ /* During a Suspend2 atomic copy, with DEBUG_SLAB, we will
+* get page faults where slab has been unmapped. Map them
+* temporarily and set the variable that tells Suspend2 to
+* unmap afterwards.
+*/
+
+ if (unlikely(suspend2_running && !suspend2_faulted)) {
+ struct page *page = NULL;
+ suspend2_faulted = 1;
+ page = virt_to_page(address);
+ kernel_map_pages(page, 1, 1);
+ return;
+ }
+
/*
* We fault-in kernel-space virtual memory on-demand. The
* 'reference' page table is init_mm.pgd.
Regards,
Nigel
signature.asc
Description: This is a digitally signed message part
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Mon 2007-06-04 11:02:01, Stefan Seyfried wrote: > On Thu, May 17, 2007 at 06:35:48PM -0400, Len Brown wrote: > > > Yes, SuSE enables polling mode by default, but that is just > > distro specific "value add" that should eventually be fixed. > > I will do that for openSUSE FACTORY. Well, I still believe right solution is to enable polling mode as soon as trip points are written (and ignoring bios updates from then on). That gets trip point writing into functional state. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook
On Fri 2007-06-01 11:00:50, [EMAIL PROTECTED] wrote: > On Fri, 1 Jun 2007, [EMAIL PROTECTED] wrote: > > >On Thu, 24 May 2007 14:47:27 -, Pavel Machek said: > >>Yes, if there's significantly more remote bad guys than local bad > >>guys, and if remote bad guys can't just get some local user first, AA > >>still has some value. > > > >Experience over on the Windows side of the fence indicates that "remote bad > >guys get some local user first" is a *MAJOR* part of the current real-world > >threat model - the vast majority of successful attacks on end-user boxes > >these > >days start off with either "Get user to (click on link|open attachment)" or > >"Subvert the path to a website (either by hacking the real site or > >hijacking > >the DNS) and deliver a drive-by fruiting when the user visits the page". > > and if your local non-root user can create a hard link to /etc/shadow and > access it they own your box anyway (they can just set the root password to > anything they want). I think you need to look how unix security works: [EMAIL PROTECTED]:/tmp$ ln /etc/shadow . [EMAIL PROTECTED]:/tmp$ cat shadow cat: shadow: Permission denied [EMAIL PROTECTED]:/tmp$ Yes, regular users are permitted to hardlink shadow, no, it is not a security hole, yes, it is a problem for AA. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]
On Thu 2007-05-31 22:46:11, Len Brown wrote: > On Monday 21 May 2007 08:11, Pavel Machek wrote: > > On Thu 2007-05-17 18:42:43, Len Brown wrote: > > > > Something similar happened to me on XE3, yes. > > > > > > > > (Actual values were different; BIOS specified critical temperature at > > > > cca 95C, but hw killed the power at cca 83C. Setting critical trip > > > > point at 80C made the problem go away.) > > > > > > Great, please file a bug and include the acpidump from the XE3 > > > and we'll fix it, rather than supporting a bogus (manual) workaround for > > > it. > > > > It is few years since I do not have that XE3 machine. > > > > > Of course if your system is running at 80*C and the hardware shuts > > > off at 83*C, you may have a broken fan, or one clogged with dust... > > > > It _did_ have broken fan. It also had broken trip points. > > Thanks for clarifying this, Pavel. > If you come upon an XE3 where Linux-2.6.22 doesn't work as well > as Windows, please let me know. "work as well as windows" is not good enough goal as far as I'm concerned. Please don't break working setups. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove apparently useless, commented apm_get_battery_status().
Remove the "#if 0"ed definition of apm_get_battery_status().
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/apm.c b/arch/i386/kernel/apm.c
index 4112afe..5c6da2b 100644
--- a/arch/i386/kernel/apm.c
+++ b/arch/i386/kernel/apm.c
@@ -1006,35 +1006,6 @@ static int apm_get_power_status(u_short *status, u_short
*bat, u_short *life)
return APM_SUCCESS;
}
-#if 0
-static int apm_get_battery_status(u_short which, u_short *status,
- u_short *bat, u_short *life, u_short *nbat)
-{
- u32 eax;
- u32 ebx;
- u32 ecx;
- u32 edx;
- u32 esi;
-
- if (apm_info.connection_version < 0x0102) {
- /* pretend we only have one battery. */
- if (which != 1)
- return APM_BAD_DEVICE;
- *nbat = 1;
- return apm_get_power_status(status, bat, life);
- }
-
- if (apm_bios_call(APM_FUNC_GET_STATUS, (0x8000 | (which)), 0, &eax,
- &ebx, &ecx, &edx, &esi))
- return (eax >> 8) & 0xff;
- *status = ebx;
- *bat = ecx;
- *life = edx;
- *nbat = esi;
- return APM_SUCCESS;
-}
-#endif
-
/**
* apm_engage_power_management - enable PM on a device
* @device: identity of device
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] sendfile removal
On Mon, Jun 04, 2007 at 10:05:35AM +0200, Jens Axboe wrote: > On Mon, Jun 04 2007, Fengguang Wu wrote: > > Hi Jens, > > > > This is another try, still not in a comfortable state though. > > //Busy waiting is possible for interleaved reads. > > A few random comments... > > Adding an internal flag is fine, but please put it at the upper end of > the spectrum. So, use (1 << 31) for that flag. OK. > And please work on the #splice branch of the block repo, not -mm. There > are quite a few things pending for inclusion in there, and I'm sure your > patch as-is wont apply. I'm afraid this patch cannot be moved over to your branch trivially. The core of the algorithm reuses f_ra.prev_index to record the state. It is OK for the on-demand readahead in the -mm tree. But the current readahead code in 2.6.22-rc3 is sensible to the change. And it also does not reliably tell if readahead I/O has been submitted. We can either try other ways of doing non-blocking I/O, or just wait until the merge of on-demand readahead? The current patch should work perfect with single splice reader. In the case of multiple readers on the same fd, we might simply err on the side of I/O waiting, since busy EAGAIN looping is not acceptable. Fengguang Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc[23]: blinking capslock led, stuck keys?
Hi! I started getting blinking capslock leds in 2.6.22-somewhere. Every 5 seconds or so, capslock led toggles on thinkpad x60. Ouch. I also get some stuck keys I was not getting before. I hope my userland did not go crazy... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Monday 04 June 2007 12:55, Pavel Machek wrote: > On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote: > > On Tuesday 15 May 2007 11:14, Pavel Machek wrote: > > > Why is this configurable? > > > > The maximum length of a pathname is an arbitrary limit: we don't want to > > allocate arbitrary amounts of of kernel memory for pathnames so we > > introduce this limit and set it to a reasonable value. In the unlikely > > case that someone uses insanely long pathnames, this limit can be > > increased. > > vfs does not have configurable pathname limit, and I do not see what > is so special about AA to require this kind of uglyness. You very well know that the vfs has a limit of PATH_MAX characters (4096) for pathnames. This means that at most that many characters can be passed at once. I've really got enough of your perpetual unfounded rants. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[bug] very high non-preempt latency in context_struct_compute_av()
a simple ssh login triggers a ~130 msecs non-preemptible latency even with CONFIG_PREEMPT enabled, on a fast Core2Duo CPU (!). the latency is caused by a _very_ long loop in the SELinux code: sshd-4828 0.N.. 465894us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 465895us : cond_compute_av (context_struct_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node (cond_compute_av) sshd-4828 0.N.. 465895us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av (context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node (cond_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 465896us : cond_compute_av (context_struct_compute_av) sshd-4828 0.N.. 465896us : avtab_search_node (cond_compute_av) it is triggered like this: sshd-4828 0..s. 462986us : tasklet_action (__do_softirq) sshd-4828 0..s. 462986us : rcu_process_callbacks (tasklet_action) sshd-4828 0..s. 462986us : __rcu_process_callbacks (rcu_process_callbacks) sshd-4828 0..s. 462987us : __rcu_process_callbacks (rcu_process_callbacks) sshd-4828 0D.s. 462987us : _local_bh_enable (__do_softirq) sshd-4828 0DN.. 462987us : idle_cpu (irq_exit) sshd-4828 0.N.. 462988us : avtab_search_node (context_struct_compute_av) sshd-4828 0.N.. 462989us : cond_compute_av (context_struct_compute_av) and it ends like this after 130 msecs: sshd-4828 0.N.. 594068us : ebitmap_contains (constraint_expr_eval) sshd-4828 0.N.. 594068us : ebitmap_get_bit (constraint_expr_eval) sshd-4828 0.N.. 594068us : constraint_expr_eval (context_struct_compute_av) sshd-4828 0.N.. 594068us : ebitmap_contains (constraint_expr_eval) sshd-4828 0.N.. 594068us : ebitmap_get_bit (constraint_expr_eval) sshd-4828 0.N.. 594070us : sprintf (sel_write_user) sshd-4828 0.N.. 594070us : vsnprintf (sprintf) sshd-4828 0.N.. 594072us : number (vsnprintf) sshd-4828 0.N.. 594072us : security_sid_to_context (sel_write_user) sshd-4828 0.N.. 594073us : _read_lock (security_sid_to_context) sshd-4828 0.N.. 594073us : sidtab_search (security_sid_to_context) sshd-4828 0.N.. 594073us : context_struct_to_string (security_sid_to_context) sshd-4828 0.N.. 594074us : mls_compute_context_len (context_struct_to_string) sshd-4828 0.N.. 594075us : ebitmap_cmp (mls_compute_context_len) sshd-4828 0.N.. 594075us : __kmalloc (context_struct_to_string) sshd-4828 0.N.. 594076us : sprintf (context_struct_to_string) sshd-4828 0.N.. 594077us : vsnprintf (sprintf) i've got the full trace saved away (200 MB ...) and can upload it, but it's just repetitions of the above lines. The distribution is Fedora 7, v2.6.21 (but also happens in recent -git) and a simple 'ssh localhost' login is enough to trigger this. It triggers every time and this is causing audio skipping in certain apps. It is even visible in glxgears smoothness: a small 'bump' is visible in the otherwise smooth rotation of glxgears. Enabling CONFIG_PREEMPT does not fix this issue as the function runs under spinlocks. (enabling CONFIG_PREEMPT_RT in -rt fixes the issue - but that still leaves us with the huge 130 msecs cost of that function.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Mon 2007-06-04 13:25:30, Andreas Gruenbacher wrote: > On Monday 04 June 2007 12:55, Pavel Machek wrote: > > On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote: > > > On Tuesday 15 May 2007 11:14, Pavel Machek wrote: > > > > Why is this configurable? > > > > > > The maximum length of a pathname is an arbitrary limit: we don't want to > > > allocate arbitrary amounts of of kernel memory for pathnames so we > > > introduce this limit and set it to a reasonable value. In the unlikely > > > case that someone uses insanely long pathnames, this limit can be > > > increased. > > > > vfs does not have configurable pathname limit, and I do not see what > > is so special about AA to require this kind of uglyness. > > You very well know that the vfs has a limit of PATH_MAX characters (4096) for > pathnames. This means that at most that many characters can be passed at > once. Sorry then. Why not reuse the PATH_MAX when it exists already? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
On Monday 04 June 2007 13:35, Pavel Machek wrote:
> On Mon 2007-06-04 13:25:30, Andreas Gruenbacher wrote:
> > On Monday 04 June 2007 12:55, Pavel Machek wrote:
> > > On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
> > > > On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
> > > > > Why is this configurable?
> > > >
> > > > The maximum length of a pathname is an arbitrary limit: we don't want
> > > > to allocate arbitrary amounts of of kernel memory for pathnames so we
> > > > introduce this limit and set it to a reasonable value. In the
> > > > unlikely case that someone uses insanely long pathnames, this limit
> > > > can be increased.
> > >
> > > vfs does not have configurable pathname limit, and I do not see what
> > > is so special about AA to require this kind of uglyness.
> >
> > You very well know that the vfs has a limit of PATH_MAX characters (4096)
> > for pathnames. This means that at most that many characters can be passed
> > at once.
What users can do is something like this:
chdir("some/long/path");
chdir("some/even/longer/path");
...
and the total length of the path can then exceed PATH_MAX characters. We can
only accept pathnames up to some upper limit, and we need to somehow define
what that limit is supposed to be. We could use PATH_MAX or some other
arbitrary number. In most situations PATH_MAX will be fine, but that's not
always guaranteed to be the case. So what's wrong about making this
configurable for special situations that we might run into? Module parameters
are *really* dead cheap.
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix roundup_pow_of_two(1)
On Thu, May 17, 2007 at 11:56:56PM +0200, Rolf Eike Beer wrote: > Fix roundup_pow_of_two(1) > > 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It does > in case the argument is a variable but in case it's a constant it behaves > wrong and returns 0. Probably nobody ever did it so this was never noticed. I'm not getting the problem. 2^0 = 1 > Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]> > > --- > commit 01ceeffac83011f0b5021013cc4abd1c4f291df5 > tree 7da59df51617d7cebd55e4361019181645a17e10 > parent ab35916f807eb4f2019a208e96cb0bddbb91dfc3 > author Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 17 May 2007 23:43:54 +0200 > committer Rolf Eike Beer <[EMAIL PROTECTED]> Thu, 17 May 2007 23:43:54 +0200 > > include/linux/log2.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/linux/log2.h b/include/linux/log2.h > index 57e641e..1b8a2c1 100644 > --- a/include/linux/log2.h > +++ b/include/linux/log2.h > @@ -159,7 +159,7 @@ unsigned long __roundup_pow_of_two(unsigned long n) > #define roundup_pow_of_two(n)\ > (\ > __builtin_constant_p(n) ? ( \ > - (n == 1) ? 0 : \ > + (n == 1) ? 1 : \ > (1UL << (ilog2((n) - 1) + 1)) \ > ) : \ > __roundup_pow_of_two(n) \ 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/
apic related BUG: soft lockup detected on CPU#0!
FYI, 2.6.21.1, tainted with ATI fglrx driver (so maybe take it with a grain of salt): When I attempted to kill -9 an unresponsive looping X server (desktop processes were gone at that time) the system locked up and reported the following: BUG: soft lockup detected on CPU#0! [] show_trace_log_lvl+0x19/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x14/0x20 [] softlockup_tick+0xa2/0xc0 [] run_local_timers+0x12/0x20 [] update_process_times+0x5d/0x90 [] tick_sched_timer+0x4f/0xb0 [] hrtimer_interrupt+0x177/0x1e0 [] local_apic_timer_interrupt+0x57/0x60 [] smp_apic_timer_interrupt+0x23/0x40 [] apic_timer_interrupt+0x28/0x30 === -- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/22] 2.6.22-rc3 perfmon2 : common core functions
Andi, On Thu, May 31, 2007 at 05:01:38PM +0200, Andi Kleen wrote: > > + * pmu_desc: subdir containing the PMU register mapping information > > + > > + * reset_stats(W): echo 0 > reset_stats resets the statistics collected > > by perfmon2. > > + stats are available per-cpu in > > /sys/devices/system/cpu/cpu*/perfmon > > + > > + * smpl_buffer_mem_cur(RO): reports the amount of memory currently > > dedicated to sampling > > + buffers by the kernel. > > + > > + * smpl_buffer_mem_max(RW): maximum amount of memory usable for sampling > > buffers. > > + -1 means all that is available. > > -1 seems dangerous. > > > + > > + * sys_group(RW): which users group is allowed to create a system-wide > > contexts. > > + -1 means any group > > Wouldn't this better be a capability bit? Then it could be just set > in the normal pam configuration files. > > > + > > + * sys_sessions_count(RO): number of loaded system-wide contexts > > + > > + * task_group(RW): which users group is allowed to create per-thread > > contexts. > > + -1 means any group > I spent quite some time looking at the kernel code for capabilities and also how to control them from userland. I agree with you that it would be nicer to use capabilities to control which users can create system-wide or per-thread perfmon sessions. We could simply create two new capabilities: CAP_PERFMON_SYS and CAP_PERFMON_THREAD. Then, I can envision a setup where a sysadmin would grant the capabilities to users when they login via PAM. There are two problems with this at the moment: - the 32bit for capabilities have been exhausted (kernel_cap_t is u32). We would need to increase to u64. That would impact __user_cap_data_struct which is used by the captset()/capget() syscalls. - I have not been able to find how one could grant/deny capabilities via PAM and especially for login. Libcap does not seem to be used. There was a pam_cap at some point, it seems abandonned by now. I am not a linux security expert, so there may be newer ways of setting capabilities for processes. Any comments? -- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc[23]: blinking capslock led, stuck keys?
06/04/2007 01:24 PM, Pavel Machek wrote/a écrit: Hi! I started getting blinking capslock leds in 2.6.22-somewhere. Every 5 seconds or so, capslock led toggles on thinkpad x60. Ouch. Could it be related to commit f038f9a361a764ed013447174b7170073f89cbe9 aka "Add keyboard blink driver" ? Probably you don't want it in hard in the kernel ;-) See you, 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: gmail is a bit too popular..
On Mon, Jun 04, 2007 at 11:55:32AM +0100, David Woodhouse wrote: > On Tue, 2007-05-08 at 08:43 +0200, Adrian Bunk wrote: > > BTW (not related to gmail): > > Are there any news regarding the buggy 451 handling in zmailer I'm > > reporting again and again that regularly results in every single > > linux-kernel message sent to me being delayed by up to 13 hours? > > Er, you're giving it a 451 response to _every_ message? Why? His secondary MX server: 220 mailrelay1.lrz-muenchen.de (IntraStore TurboSendmail) ESMTP Service ready yields at times "451-responses". (It suffers from occasional resource starvations and only way to get out of it is to temporarily give those replies.) Indeed there was queue timer bug at VGER in case remote replied with TEMPFAILs sufficiently many times, the whole destination queue to it got kicked back way too much. > -- > dwmw2 /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] 1/2: MMCONFIG: validate against ACPI motherboard resources
On Tue, May 29, 2007 at 10:03:32PM -0600, Robert Hancock wrote: > -Validate that the area is reserved even if we read it from the > chipset directly and not from the MCFG table. This catches the case > where the BIOS didn't set the location properly in the chipset and > has mapped it over other things it shouldn't have. Just for the record, I still fundamentally disagree with that part. You're not catching what you think you're catching, since the chipset tells you what it is going to decode as mmconfig, no matter what is connected to it. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix roundup_pow_of_two(1)
Adrian Bunk wrote: > On Thu, May 17, 2007 at 11:56:56PM +0200, Rolf Eike Beer wrote: > > Fix roundup_pow_of_two(1) > > > > 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It > > does in case the argument is a variable but in case it's a constant it > > behaves wrong and returns 0. Probably nobody ever did it so this was > > never noticed. > > I'm not getting the problem. > 2^0 = 1 Yes. But it returned 0 (not 1 << 0). Eike signature.asc Description: This is a digitally signed message part.
Re: RTC_DRV_CMOS can break userspace interface
On Mon, Jun 04, 2007 at 11:35:18AM +0200, Tino Keitel wrote: (By the way, it helps if you Cc: me - it's easy to lose track of things in the LKML noise) > Here it is: > > state = active > io 0x70-0x77 > options Yes, there's no IRQ listed. Can you try current git? -- Matthew Garrett | [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/
[PATCH -mm] Fix /proc/slab_allocators re seq_list_next() conversion
Wrong pointer was used as kmem_cache pointer.
[Here /proc/slab_allocators appears as empty file, but it's just me, probably]
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
mm/slab.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4401,7 +4401,7 @@ static void show_symbol(struct seq_file *m, unsigned long
address)
static int leaks_show(struct seq_file *m, void *p)
{
- struct kmem_cache *cachep = p;
+ struct kmem_cache *cachep = list_entry(p, struct kmem_cache, next);
struct slab *slabp;
struct kmem_list3 *l3;
const char *name;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix /proc/slab_allocators re seq_list_next() conversion
Alexey Dobriyan wrote:
> Wrong pointer was used as kmem_cache pointer.
>
> [Here /proc/slab_allocators appears as empty file, but it's just me, probably]
>
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Acked-by: Pavel Emelianov <[EMAIL PROTECTED]>
> ---
>
> mm/slab.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -4401,7 +4401,7 @@ static void show_symbol(struct seq_file *m, unsigned
> long address)
>
> static int leaks_show(struct seq_file *m, void *p)
> {
> - struct kmem_cache *cachep = p;
> + struct kmem_cache *cachep = list_entry(p, struct kmem_cache, next);
> struct slab *slabp;
> struct kmem_list3 *l3;
> const char *name;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.22-rc[23]: blinking capslock led, stuck keys?
On Mon, 4 Jun 2007, Indan Zupancic wrote: > > I also get some stuck keys I was not getting before. I hope my > > userland did not go crazy... > I get that too, and wasn't sure about it either. It happens irregularly, > so it's hard to debug, but often enough to be annoying. What kind of keyboards are they? I guess the x60 case is serio/ps2, what keyboard do you experience this with, Indan? -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A kexec approach to hibernation
On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote: > sync is perfectly safe way of telling the fs to store data on disk. On disk, yes. On the filesystem, no. It's valid for the data to be left in the journal, for instance. -- Matthew Garrett | [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 2/2] ehea: Receive SKB Aggregation
Stephen Hemminger wrote on 31.05.2007 18:37:03:
>
> >
> >
> > +static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff
*skb,
> > + struct iphdr **iph, struct tcphdr **tcph)
> > +{
> > + int ip_len;
> > +
> > + /* non tcp/udp packets */
> > + if (!cqe->header_length)
> > + return -1;
> > +
> > + /* non tcp packet */
> > + *iph = (struct iphdr *)(skb->data);
>
> Why the indirection, copying of headers..
This interacts with the header split function in the hardware.
>
> > + if ((*iph)->protocol != IPPROTO_TCP)
> > + return -1;
> > +
> > + ip_len = (u8)((*iph)->ihl);
> > + ip_len <<= 2;
> > + *tcph = (struct tcphdr *)(((u64)*iph) + ip_len);
> > +
> > + return 0;
> > +}
> > +
> >
>
> This code seems to be duplicating a lot (but not all) of the TCP/IP
> input path validation checks. This is a security problem if nothing
else...
>
We should only do aggregation in the driver if this really is a TCP header,
otherwise things will get worse.
You're right, we should at least check that tcph is within the received
frame.
> Also, how do you prevent DoS attacks from hostile TCP senders that send
> huge number of back to back frames?
Actually a huge number of back to back frames is what we would want to
receive
at 10 gbit ;-)
How is it possible to figure out if this is what you want or just DoS?
It doesn't change anything compared to a non LRO driver, we process a
certain
maximum amount of frames before waiting for the next interrupt,
the packet filters/DoS should still see all traffic (which is above the
driver).
Any suggestions how to handle this better/different?
>
> --
> Stephen Hemminger
Gruss / Regards
Christoph Raisch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ehea: Receive SKB Aggregation
Christoph Hellwig wrote on 31.05.2007 15:41:18: > I'm still very unhappy with having all this in various drivers. There's > a lot of code that can be turned into generic library functions, and even > more code that could be made generic with some amount of refactoring. Yes, we'd also prefer to use a generic function, but we first would want to get some "real world" experience how our driver behaves with LRO to be even able to define requirements for such a generic function. A lot of this is tied into pathlengths, caching, and why does that help compared to a different TCP receive side processing? In a perfect world we shouldn't see a diffference if this is enabled or not, but measurements indicate something completely different at 10gbit. Gruss / Regards Christoph Raisch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc3 hibernate(?) disables SMART on ide
> 3) There should be no bad effect from enabling smart, except if the BIOS >insists on not booting because of a bad RAID disk. (That's why I like >to disable it in the BIOS) With a couple of exceptions unfortunately. Belongs in udev and smartd so its controllable and flexible (and also swappable). Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
On Mon, 4 Jun 2007, Eric Dumazet wrote: > Goals : > 1) libc wants 'private fds' > 2) Latencies of get_unused_fd() for huge processes (more than 100.000 file > handles) > > Point 1) can use a top-down allocation, or use a 'last unused' index. > > > Point 2) Instead of introducing a *complex* layer, couldnt we improve > existing one ? Complex layer?! It's an array with free slots chained by a double linked list. > If the main problem we want to solve is the potentially slow bitmap > search, > we could logically divide the open_fds bitmap into pages (4096*8 = 32768 > bits per page on i386/x86_64 arches) > > We would have to add a new field in 'struct fdtable', pointer to an > array of u32 counters, that would count the number of 'one' bits in each > PAGE. This array is tiny : 128 bytes only for 1.000.000 file handles > > get_unused_fd() could then use this array to select an appropriate page > (a page known to have at least one zero bit), then do a > find_next_zero_bit() restricted to at most PAGE_SIZE bytes. Max latency > would be similar to vm one when clearing a page. If applications use > Point 1) hint (asking kernel one fd, not the POSIX low fd), typical > latency will be null. And look at what you're describing here, talking about simplicity. You'd still need two bitmaps, so you'd still need the out-of-fdmap.c/h code. You're trying to fit an horse-shoe to a deer :) The most appropriate structure for this, is an array (O(1) lookup) with free elements chained by a dbl linked list (O(1) alloc and free). Plus, the extra pointer can nicely fit other per-allocated-fd flags w/out adding extra custom flags bitmaps to the fdtable. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ide: ide-generic, add another device exception
Hello.
Jiri Slaby wrote:
diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c
index f2c5a14..0d51a11 100644
--- a/drivers/ide/pci/generic.c
+++ b/drivers/ide/pci/generic.c
@@ -198,32 +198,41 @@ static ide_pci_device_t generic_chipsets[] __devinitdata
= {
static int __devinit generic_init_one(struct pci_dev *dev, const struct
pci_device_id *id)
{
ide_pci_device_t *d = &generic_chipsets[id->driver_data];
- u16 command;
int ret = -ENODEV;
/* Don't use the generic entry unless instructed to do so */
if (id->driver_data == 0 && ide_generic_all == 0)
goto out;
- if (dev->vendor == PCI_VENDOR_ID_UMC &&
- dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
- (!(PCI_FUNC(dev->devfn) & 1)))
- goto out; /* UM8886A/BF pair */
-
- if (dev->vendor == PCI_VENDOR_ID_OPTI &&
- dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
- (!(PCI_FUNC(dev->devfn) & 1)))
- goto out;
-
- if (dev->vendor == PCI_VENDOR_ID_JMICRON) {
- if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
PCI_FUNC(dev->devfn) != 1)
+ switch (dev->vendor) {
+ case PCI_VENDOR_ID_UMC:
+ if (dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
+ !(PCI_FUNC(dev->devfn) & 1))
+ goto out; /* UM8886A/BF pair */
+ break;
+ case PCI_VENDOR_ID_OPTI:
+ if (dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
+ !(PCI_FUNC(dev->devfn) & 1))
+ goto out;
+ break;
+ case PCI_VENDOR_ID_JMICRON:
+ if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
+ PCI_FUNC(dev->devfn) != 1)
+ goto out;
+ break;
+ case PCI_VENDOR_ID_NS:
+ if (dev->device == PCI_DEVICE_ID_NS_87410 &&
+ (dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
goto out;
+ break;
}
Could you intend the if() conditions carried to another line the way they
were intended before?
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix roundup_pow_of_two(1)
On Mon, 4 Jun 2007, Adrian Bunk wrote: > > 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It > > does > > in case the argument is a variable but in case it's a constant it behaves > > wrong and returns 0. Probably nobody ever did it so this was never noticed. > I'm not getting the problem. > 2^0 = 1 Adrian, that's of course true, but unrelated to the patch in question :) You simply want roundup_pow_of_two(1) to be 1, and not 0. That's what the patch does, and that's correct. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc[23]: blinking capslock led, stuck keys?
On Mon, 4 Jun 2007, Pavel Machek wrote: > I started getting blinking capslock leds in 2.6.22-somewhere. Every 5 > seconds or so, capslock led toggles on thinkpad x60. Ouch. I also get > some stuck keys I was not getting before. I hope my userland did not go > crazy... Hi Pavel, what does grep BLINK .config show? -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc[23]: blinking capslock led, stuck keys?
On Mon, June 4, 2007 13:24, Pavel Machek wrote: > I also get some stuck keys I was not getting before. I hope my > userland did not go crazy... I get that too, and wasn't sure about it either. It happens irregularly, so it's hard to debug, but often enough to be annoying. My mouse pointer tends to warp too in the same irregular way, no idea if that's related (it seemed to happen in an earlier kernel version than the sticky key thing, but not sure, as I don't have this mouse that long.) Greetings, Indan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: gmail is a bit too popular..
On Mon, Jun 04, 2007 at 11:55:32AM +0100, David Woodhouse wrote: > On Tue, 2007-05-08 at 08:43 +0200, Adrian Bunk wrote: > > BTW (not related to gmail): > > Are there any news regarding the buggy 451 handling in zmailer I'm > > reporting again and again that regularly results in every single > > linux-kernel message sent to me being delayed by up to 13 hours? > > Er, you're giving it a 451 response to _every_ message? Why? Not me, a MTA 4 hops away on the way to me. And not on _every_ message, it is more like "randomly one out of 100 messages gets an 451 4.3.2 system not accepting network messages". That's a perfectly legal behaviour considering that RFC 3463 gives "immanent shutdown, excessive load, or system maintenance" (which are for the sending MTA equal to "random") as example causes for this response. The problem is really that Zmailer on vger under some circumstances never retries to send these emails for days, on one occasion the emails bounced after 5 days without any retry. > dwmw2 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 1/1] ide: ide-generic, add another device exception
Sergei Shtylyov napsal(a):
> Hello.
>
> Jiri Slaby wrote:
>
>> diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c
>> index f2c5a14..0d51a11 100644
>> --- a/drivers/ide/pci/generic.c
>> +++ b/drivers/ide/pci/generic.c
>> @@ -198,32 +198,41 @@ static ide_pci_device_t generic_chipsets[]
>> __devinitdata = {
>> static int __devinit generic_init_one(struct pci_dev *dev, const
>> struct pci_device_id *id)
>> {
>> ide_pci_device_t *d = &generic_chipsets[id->driver_data];
>> -u16 command;
>> int ret = -ENODEV;
>>
>> /* Don't use the generic entry unless instructed to do so */
>> if (id->driver_data == 0 && ide_generic_all == 0)
>> goto out;
>>
>> -if (dev->vendor == PCI_VENDOR_ID_UMC &&
>> -dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
>> -(!(PCI_FUNC(dev->devfn) & 1)))
>> -goto out; /* UM8886A/BF pair */
>> -
>> -if (dev->vendor == PCI_VENDOR_ID_OPTI &&
>> -dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
>> -(!(PCI_FUNC(dev->devfn) & 1)))
>> -goto out;
>> -
>> -if (dev->vendor == PCI_VENDOR_ID_JMICRON) {
>> -if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
>> PCI_FUNC(dev->devfn) != 1)
>> +switch (dev->vendor) {
>> +case PCI_VENDOR_ID_UMC:
>> +if (dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
>> +!(PCI_FUNC(dev->devfn) & 1))
>> +goto out; /* UM8886A/BF pair */
>> +break;
>> +case PCI_VENDOR_ID_OPTI:
>> +if (dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
>> +!(PCI_FUNC(dev->devfn) & 1))
>> +goto out;
>> +break;
>> +case PCI_VENDOR_ID_JMICRON:
>> +if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
>> +PCI_FUNC(dev->devfn) != 1)
>> +goto out;
>> +break;
>> +case PCI_VENDOR_ID_NS:
>> +if (dev->device == PCI_DEVICE_ID_NS_87410 &&
>> +(dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
>> goto out;
>> +break;
>> }
>
> Could you intend the if() conditions carried to another line the way
> they were intended before?
I could, if you tell me the reason.
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.21.1] SATA freeze
Fred Moyer wrote: Sounds like SMART is likely disabled on that drive. You can try doing "smartctl -s on /dev/sda" and see if that will turn it on. Sorry - that last post of mine was brain dead. Here's the one with (hopefully) useful data. app2 ~ # smartctl -d ata -a /dev/sda smartctl version 5.36 [x86_64-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen (...) -- -- -- -- -- -- -- 84 51 00 b5 c9 73 e0 Error: ICRC, ABRT at LBA = 0x0073c9b5 = 7588277 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- 25 00 20 96 c9 73 e0 00 01:25:42.886 READ DMA EXT b0 d0 01 00 4f c2 00 02 01:25:42.868 SMART READ DATA 35 00 08 ae b6 42 e0 00 01:25:42.456 WRITE DMA EXT b0 da 00 00 4f c2 00 00 01:25:42.430 SMART RETURN STATUS 35 00 08 60 81 04 e0 00 01:25:42.376 WRITE DMA EXT I was getting very similar SMART results, and kernel errors, when used PATA drive and SATA_VIA (no freezes or hangs though): SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 0 res 51/04:00:0b:ff:bf/00:00:00:00:00/00 Emask 0x1 (device error) ata3.00: configured for UDMA/100 ata3: EH complete SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 0 cdb 0x0 data 512 in res 51/04:01:00:4f:c2/00:00:00:00:00/00 Emask 0x1 (device error) ata3.00: configured for UDMA/100 ata3: EH complete The problem was that I started smartd with wrong parameters: DEVICESCAN -a -o on -S on -s (S/../.././10|L/../../6/11) It was solved when I added "-d sat" to smartd parameters: DEVICESCAN -d sat -a -o on -S on -s (S/../.././10|L/../../6/11) From that time on, smartctl -a /dev/sda gives "normal" output, and no more strange kernel errors. Hopefully, it'll get fixed in smartmontools soon (or is fixed already, but not yet mainline). -- Tomasz Chmielewski http://wpkg.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] ufd v1 - unsequential O(1) fdmap core
On Mon, 4 Jun 2007, Andrew Morton wrote: > a) Were IDR trees evaluated and if so, why were they rejected? > > b) it's a bit disappointing that this new allocator is only usable for >one specific application. We have a *lot* of places in the kernel which >want allocators of this type. Many of them are open-coded and crappy. >Some use IDR trees. > >If we're going to go and add a complete new allocator, it would be >good to position it as a library thing if poss. Thank you for pointing me to that, Andrew. I didn't know about it (IDR trees). It does not fit AFAICS. Locking should be handled extarnally (the files struct), must be RCU friendly (proper barriers) since it's used in lockless code, and must have flags associated to an allocation. And I'm leaving out the O(1) part, that for something like this, is just silly not to have it. This is really an array. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.22-rc[23]: blinking capslock led, stuck keys?
On Mon 2007-06-04 14:35:23, Jiri Kosina wrote: > On Mon, 4 Jun 2007, Pavel Machek wrote: > > > I started getting blinking capslock leds in 2.6.22-somewhere. Every 5 > > seconds or so, capslock led toggles on thinkpad x60. Ouch. I also get > > some stuck keys I was not getting before. I hope my userland did not go > > crazy... > > Hi Pavel, > > what does > > grep BLINK .config > show. CONFIG_BLINK=y OOps. WTF is that? config BLINK tristate "Keyboard blink driver" help Driver that when loaded will blink the keyboard LEDs continuously. This is useful for debugging and for kernels that cannot necessarily output something to the screen like kexec kernels to give the user a visual indication that the kernel is doing something. ..does it need "default n"? Why does it make keys stuck sometimes? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A kexec approach to hibernation
On Mon 2007-06-04 13:20:54, Matthew Garrett wrote: > On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote: > > > sync is perfectly safe way of telling the fs to store data on disk. > > On disk, yes. On the filesystem, no. It's valid for the data to be left > in the journal, for instance. Yep... then grub needs to grok the journal. It does for ext3, IIRC. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [AppArmor 38/45] AppArmor: Module and LSM hooks
Hi!
> > > You very well know that the vfs has a limit of PATH_MAX characters (4096)
> > > for pathnames. This means that at most that many characters can be passed
> > > at once.
>
> What users can do is something like this:
>
> chdir("some/long/path");
> chdir("some/even/longer/path");
> ...
>
> and the total length of the path can then exceed PATH_MAX characters. We can
> only accept pathnames up to some upper limit, and we need to somehow define
> what that limit is supposed to be. We could use PATH_MAX or some other
> arbitrary number. In most situations PATH_MAX will be fine, but that's not
> always guaranteed to be the case. So what's wrong about making this
> configurable for special situations that we might run into? Module parameters
> are *really* dead cheap.
Parameters are cheap, but this one is ugly.
How will kernel work with very long paths? I'd suspect some problems,
if path is 1MB long and I attempt to print it in /proc
somewhere. Perhaps vfs should be modified not to allow such crazy
paths? But placing limit in aa is ugly.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc[23]: blinking capslock led, stuck keys?
On Mon, 4 Jun 2007, Pavel Machek wrote: > CONFIG_BLINK=y > OOps. WTF is that? > > config BLINK > tristate "Keyboard blink driver" > help > Driver that when loaded will blink the keyboard LEDs > continuously. > This is useful for debugging and for kernels that cannot > necessarily > output something to the screen like kexec kernels to give > the user > a visual indication that the kernel is doing something. > ..does it need "default n"? Why does it make keys stuck sometimes? Are you sure that it's this dummy blink driver that makes the kernel stuck? I can't see how it could be causing any hogs - see commit f038f9. Anyway, added Andi to CC. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ide: ide-generic, add another device exception
Hello.
Jiri Slaby wrote:
diff --git a/drivers/ide/pci/generic.c b/drivers/ide/pci/generic.c
index f2c5a14..0d51a11 100644
--- a/drivers/ide/pci/generic.c
+++ b/drivers/ide/pci/generic.c
@@ -198,32 +198,41 @@ static ide_pci_device_t generic_chipsets[]
__devinitdata = {
static int __devinit generic_init_one(struct pci_dev *dev, const
struct pci_device_id *id)
{
ide_pci_device_t *d = &generic_chipsets[id->driver_data];
-u16 command;
int ret = -ENODEV;
/* Don't use the generic entry unless instructed to do so */
if (id->driver_data == 0 && ide_generic_all == 0)
goto out;
-if (dev->vendor == PCI_VENDOR_ID_UMC &&
-dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
-(!(PCI_FUNC(dev->devfn) & 1)))
-goto out; /* UM8886A/BF pair */
-
-if (dev->vendor == PCI_VENDOR_ID_OPTI &&
-dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
-(!(PCI_FUNC(dev->devfn) & 1)))
-goto out;
-
-if (dev->vendor == PCI_VENDOR_ID_JMICRON) {
-if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
PCI_FUNC(dev->devfn) != 1)
+switch (dev->vendor) {
+case PCI_VENDOR_ID_UMC:
+if (dev->device == PCI_DEVICE_ID_UMC_UM8886A &&
+!(PCI_FUNC(dev->devfn) & 1))
+goto out; /* UM8886A/BF pair */
+break;
+case PCI_VENDOR_ID_OPTI:
+if (dev->device == PCI_DEVICE_ID_OPTI_82C558 &&
+!(PCI_FUNC(dev->devfn) & 1))
+goto out;
+break;
+case PCI_VENDOR_ID_JMICRON:
+if (dev->device != PCI_DEVICE_ID_JMICRON_JMB368 &&
+PCI_FUNC(dev->devfn) != 1)
+goto out;
+break;
+case PCI_VENDOR_ID_NS:
+if (dev->device == PCI_DEVICE_ID_NS_87410 &&
+(dev->class >> 8) != PCI_CLASS_STORAGE_IDE)
goto out;
+break;
}
Could you intend the if() conditions carried to another line the way
they were intended before?
I could, if you tell me the reason.
Sorry -- I thought it was a part of kernel style, but it appeared to be my
aesthetical preference only. :-)
regards,
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ide: ide-generic, add another device exception
Sergei Shtylyov napsal(a): > Hello. Hi. >Sorry -- I thought it was a part of kernel style, but it appeared to > be my aesthetical preference only. :-) Ok, anyway thanks for reviewing, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A kexec approach to hibernation
On Mon, Jun 04, 2007 at 03:10:00PM +0200, Pavel Machek wrote: > On Mon 2007-06-04 13:20:54, Matthew Garrett wrote: > > On Mon, Jun 04, 2007 at 12:46:21PM +0200, Pavel Machek wrote: > > > > > sync is perfectly safe way of telling the fs to store data on disk. > > > > On disk, yes. On the filesystem, no. It's valid for the data to be left > > in the journal, for instance. > > Yep... then grub needs to grok the journal. It does for ext3, IIRC. No, it only supports ext2 (and reading ext3 as if it's ext2). Right now, the assumption that syncing during suspend will cause data to hit something grub can read isn't a safe one. -- Matthew Garrett | [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] Fix roundup_pow_of_two(1)
On Mon, Jun 04, 2007 at 02:13:11PM +0200, Rolf Eike Beer wrote: > Adrian Bunk wrote: > > On Thu, May 17, 2007 at 11:56:56PM +0200, Rolf Eike Beer wrote: > > > Fix roundup_pow_of_two(1) > > > > > > 1 is a power of two, therefore roundup_pow_of_two(1) should return 1. It > > > does in case the argument is a variable but in case it's a constant it > > > behaves wrong and returns 0. Probably nobody ever did it so this was > > > never noticed. > > > > I'm not getting the problem. > > 2^0 = 1 > > Yes. But it returned 0 (not 1 << 0). Sorry, I had a thinko and you are right. > Eike 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/
[PATCH 0/8] RSS controller based on process containers (v3.1)
Adds RSS accounting and control within a container.
Changes from v3
- comments across the code
- git-bisect safe split
- lost places to move the page between active/inactive lists
Ported above Paul's containers V10 with fixes from Balbir.
RSS container includes the per-container RSS accounting
and reclamation, and out-of-memory killer.
Each mapped page has an owning container and is linked into its
LRU lists just like in the global LRU ones. The owner of the page
is the container that touched the page first. As long as the page
stays mapped it holds the container, is accounted into its usage
and lives in its LRU list. When page is unmapped for the last time
it releases the container. The RSS usage is exactly the number of
pages in its booth LRU lists, i.e. the nu,ber of pages used by this
container. When this usage exceeds the limit set some pages are
reclaimed from the owning container. In case no reclamation possible
the OOM killer starts thinning out the container.
Thus the container behaves like a standalone machine - when it runs
out of resources, it tries to reclaim some pages, and if it doesn't
succeed, kills some task.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
The testing scenario may look like this:
1. Prepare the containers
# mkdir -p /containers/rss
# mount -t container none /containers/rss -o rss
2. Make the new group and move bash into it
# mkdir /containers/rss/0
# echo $$ > /containers/rss/0/tasks
Since now we're in the 0 container.
We can alter the RSS limit
# echo -n 6000 > /containers/rss/0/rss_limit
We can check the usage
# cat /containers/rss/0/rss_usage
25
And do other stuff. To check the reclamation to work we need a
simple program that touches many pages of memory, like this:
#include
#include
#include
#include
#ifndef PGSIZE
#define PGSIZE 4096
#endif
int main(int argc, char **argv)
{
unsigned long pages;
int i;
char *mem;
if (argc < 2) {
printf("Usage: %s \n", argv[0]);
return 1;
}
pages = strtol(argv[1], &mem, 10);
if (*mem != '\0') {
printf("Bad number %s\n", argv[1]);
return 1;
}
mem = mmap(NULL, pages * PGSIZE, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, 0, 0);
if (mem == MAP_FAILED) {
perror("map");
return 2;
}
for (i = 0; i < pages; i++)
mem[i * PGSIZE] = 0;
printf("OK\n");
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] Resource counters
Introduce generic structures and routines for resource accounting.
Each resource accounting container is supposed to aggregate it,
container_subsystem_state and its resource-specific members within.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
---
diff -upr linux-2.6.22-rc2-mm1.orig/include/linux/res_counter.h
linux-2.6.22-rc2-mm1-2/include/linux/res_counter.h
--- linux-2.6.22-rc2-mm1.orig/include/linux/res_counter.h 2007-06-01
16:46:32.0 +0400
+++ linux-2.6.22-rc2-mm1-2/include/linux/res_counter.h 2007-06-01
16:35:15.0 +0400
@@ -0,0 +1,102 @@
+#ifndef __RES_COUNTER_H__
+#define __RES_COUNTER_H__
+
+/*
+ * resource counters
+ * contain common data types and routines for resource accounting
+ *
+ * Copyright 2007 OpenVZ SWsoft Inc
+ *
+ * Author: Pavel Emelianov <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+
+/*
+ * the core object. the container that wishes to account for some
+ * resource may include this counter into its structures and use
+ * the helpers described beyond
+ */
+
+struct res_counter {
+ /*
+* the current resource consumption level
+*/
+ unsigned long usage;
+ /*
+* the limit that usage cannot exceed
+*/
+ unsigned long limit;
+ /*
+* the number of insuccessful attempts to consume the resource
+*/
+ unsigned long failcnt;
+ /*
+* the lock to protect all of the above.
+* the routines below consider this to be IRQ-safe
+*/
+ spinlock_t lock;
+};
+
+/*
+ * helpers to interact with userspace
+ * res_counter_read/_write - put/get the specified fields from the
+ * res_counter struct to/from the user
+ *
+ * @cnt: the counter in question
+ * @member: the field to work with (see RES_xxx below)
+ * @buf: the buffer to opeate on,...
+ * @nbytes: its size...
+ * @pos: and the offset.
+ */
+
+ssize_t res_counter_read(struct res_counter *cnt, int member,
+ const char __user *buf, size_t nbytes, loff_t *pos);
+ssize_t res_counter_write(struct res_counter *cnt, int member,
+ const char __user *buf, size_t nbytes, loff_t *pos);
+
+/*
+ * the field descriptors. one for each member of res_counter
+ */
+
+enum {
+ RES_USAGE,
+ RES_LIMIT,
+ RES_FAILCNT,
+};
+
+/*
+ * helpers for accounting
+ */
+
+void res_counter_init(struct res_counter *cnt);
+
+/*
+ * charge - try to consume more resource.
+ *
+ * @cnt: the counter
+ * @val: the amount of the resource. each controller defines its own
+ * units, e.g. numbers, bytes, Kbytes, etc
+ *
+ * returns 0 on success and <0 if the cnt->usage will exceed the cnt->limit
+ * _locked call expects the cnt->lock to be taken
+ */
+
+int res_counter_charge_locked(struct res_counter *cnt, unsigned long val);
+int res_counter_charge(struct res_counter *cnt, unsigned long val);
+
+/*
+ * uncharge - tell that some portion of the resource is released
+ *
+ * @cnt: the counter
+ * @val: the amount of the resource
+ *
+ * these calls check for usage underflow and show a warning on the console
+ * _locked call expects the cnt->lock to be taken
+ */
+
+void res_counter_uncharge_locked(struct res_counter *cnt, unsigned long val);
+void res_counter_uncharge(struct res_counter *cnt, unsigned long val);
+
+#endif
diff -upr linux-2.6.22-rc2-mm1.orig/init/Kconfig
linux-2.6.22-rc2-mm1-2/init/Kconfig
--- linux-2.6.22-rc2-mm1.orig/init/Kconfig 2007-06-01 16:35:12.0
+0400
+++ linux-2.6.22-rc2-mm1-2/init/Kconfig 2007-06-01 16:35:13.0 +0400
@@ -328,6 +328,10 @@ config CPUSETS
Say N if unsure.
+config RESOURCE_COUNTERS
+ bool
+ select CONTAINERS
+
config SYSFS_DEPRECATED
bool "Create deprecated sysfs files"
default y
diff -upr linux-2.6.22-rc2-mm1.orig/kernel/Makefile
linux-2.6.22-rc2-mm1-2/kernel/Makefile
--- linux-2.6.22-rc2-mm1.orig/kernel/Makefile 2007-06-01 16:35:12.0
+0400
+++ linux-2.6.22-rc2-mm1-2/kernel/Makefile 2007-06-01 16:35:13.0
+0400
@@ -56,6 +56,7 @@ obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
obj-$(CONFIG_UTS_NS) += utsname.o
obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
+obj-$(CONFIG_RESOURCE_COUNTERS) += res_counter.o
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is
diff -upr linux-2.6.22-rc2-mm1.orig/kernel/res_counter.c
linux-2.6.22-rc2-mm1-2/kernel/res_counter.c
--- linux-2.6.22-rc2-mm1.orig/kernel/res_counter.c 2007-06-01
16:46:32.0 +0400
+++ linux-2.6.22-rc2-mm1-2/kernel/res_counter.c 2007-06-01 16:35:15.0
+0400
@@ -0,0 +1,121 @@
+/*
+ * resource containers
+ *
+ * Copyright 2007 OpenVZ SWsoft Inc
+ *
+ * Author: Pavel Emelianov <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void res_counter_init(struct res_counter *cnt)
+{
+ spin_lock_init(&cnt->lock);
+ cnt->lim
Re: libata & no PCI: dma_[un]map_single undefined
> > CONFIG_PCI=n > > CONFIG_ATA=m > > > > This seems to be a valid configuration since libata can drive non-PCI > > devices too? Yep. > It really makes no sense to allow this on Sparc, there are no > non-PCI Sparc ATA controllers. There are PCMCIA controllers and PCI/PCMCIA/Cardbus adapters for the Sparc platform I thought ? > diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig > index b4a8d60..7d893a6 100644 > --- a/drivers/ata/Kconfig > +++ b/drivers/ata/Kconfig > @@ -8,6 +8,7 @@ menuconfig ATA > depends on BLOCK > depends on !(M32R || M68K) || BROKEN > depends on !SUN4 || BROKEN > + depends on !(SPARC64 && !PCI) NAK - this is the wrong approach. PCI=n ATA=m should compile. Sparc is not the only problem case. The DMA handling bits of libata are fairly nicely split out but they are stuck in the same file and unconditionally compiled in. I'll have a poke at this when I get a bit of time if Jeff doesn't. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
