Keyboard programming needs root

[Daniel Mantione]

Hello,

A while back a patch was merged to make that only root can program the
keyboard:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0b360adbdb54d5b98b78d57ba0916bc4b8871968

Is this patch discussable? I think this patch isn't proper because of the
following reasons:

* Users can play games in many ways. They can configure the terminal
  settings, (remove the automatic line feed, disable the echo etc). They can
  load console fonts. They can still put the keyboard in raw mode, etc.
* All of these games can be prevented by making mingetty (or whatever getty
  is used) or PAM can put the console into a known state after logout.
* All of these games are annoyances, system security is not compromised.
* I do not see a problem with for example a French user doing a "loadkeys
  fr" if that allows hims to use the computer easier.

Worst issue for me though, is that KDSBENT is needed to be able to catch
keys like shift+tab, alt+fx, escape without delay. My application suddenly
needs root permissions to work properly. The alternative, semi raw mode,
has the disadvantage that you need to implement your own keymaps (like X).
In short, this change breaks applications.

Daniël Mantione

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] cleanup congestion control options

[Adrian Bunk]

On Fri, Jul 13, 2007 at 11:54:42PM -0700, David Miller wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sat, 14 Jul 2007 06:09:54 +0200
> 
> > This patch contains the following cleanups:
> > - note in the prompt if an option depends on EXPERIMENTAL
> > - remove "default n"s that didn't have any effect
> > - remove "default m"s from options under TCP_CONG_ADVANCED:
> >   if you manually choose congestion control modules you should
> >   know which ones you want
> > 
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> I'm not so sure about any of this, sorry Adrian, I'm
> not applying this.

What exactly are you not sure of?
- noting the experimental status in the prompt is a common convention
  in the kernel
- "default n"s like here are nops serving no purpose

This leaves only the removal of the "default m"s which I thought would 
be non-controversial since people seeing these options should know best
what they need.

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: [linux-pm] Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

[david]

On Fri, 13 Jul 2007, Alan Stern wrote:


On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:


I missed this discussion. is this idea to suspend, write to disk, but
leave things in ram so that if you wakeup soon enough you have everything
for ram, but if you don't and the battery dies you can restore from disk?

if so I think it's a mistake to mix the two. it would be better to just
suspend to ram, and wake up once in a while to check the battery state and
when the battery gets low enough do the suspend to disk.

otherwise you end up mixing the requirements of the two types of suspend,
which is how things got so ugly in the first place.


Not necessarily.  If we don't put devices into low power states before creating
the image, that should work just fine (quiesce devices, create the image or
kexec the new kernel, reprobe devices, save the image, suspend to RAM,
resume from RAM, continue - or restore from the image if power failed in the
meantime).  Still, for this purpose, both kernels need to be able to handle the
same set of devices.


Why?

Suppose the kexec kernel can't handle some device.  The normal kernel
has already quiesced the device, so it will remain quiescent while the
kexec kernel runs and throughout the suspend.  When the regular kernel
regains control the device will be ready for use.  I don't see any
problem.


remember that during the hibernation the box may be powered off.

but there's still no reason for the hibernate kernel to know how to access 
the USB TV Tuner for example.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc6-mm1

[Robert Hancock]

Andrew Morton wrote:

+x86_64-dynticks-disable-hpet_id_legsup-hpets.patch

 pretend to fix it


I'm not sure what this patch does on x86_64, but it seems like it 
trashes all HPET support on i386?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

[david]

On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:


remember release early, release often (with something that functions)


fo rthe current stage where we are trying to make things work don't worry
about packaging everything tight with initrd and re-useing partitions or
kernel images. once everything is working reliably then it's time to look
at useing the same kernel for multiple functions, writing to a partition
that's i use for other things, etc


I don't agree.  You need to think of many limitations in advance, because
they need to be taken into consideration in the design.

Otherwise we'll end up with something that will need to be bandaided like the
freezer. :-)


on the other hand, worrying about all the possible ways to do things can
paralize you.

the big advantage of the kexec approach is that the new userspace that's
setup with the new kernel can do _anything_.


No, it can't.  For example, it can't access filesystems mounted by the
hibernated kernel, or they may get corrupted after the restore (if they are
journaling, it can't even read from them).


it's only ext3 that has this bug when mounting a fileystem read-only 
AFAIK.



Which reminds me of one more issue, which is that the image-saving kernel
won't be able to use these filesystems either, so its modules and user space
will have to be available from somewhere else (like a RAM disk or dedicated
partition).  So things get ugly.


another reason to go ahead and make a dedicated no-module kernel for the 
hibernate phase ;-)



Apart from this, the new kernel's user space cannot blindly modify swap space
that might be in use by the hibernated kernel.


with swap space you have two options

1. free it up (to a swap file if needed) and don't worry about it

2. try and ensure that nothing else on the system attempts to use the swap 
partition until you reboot.


#2 is failure prone, #1 would be more reliable.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] F00F bug fixup for i386 - use immediate values

[Alexey Dobriyan]

On Fri, Jul 13, 2007 at 09:26:43PM -0400, Mathieu Desnoyers wrote:
> Use the faster immediate values for F00F bug handling in do_page_fault.

> --- linux-2.6-lttng.orig/arch/i386/mm/fault.c
> +++ linux-2.6-lttng/arch/i386/mm/fault.c
> @@ -492,7 +493,7 @@
>   /*
>* Pentium F0 0F C7 C8 bug workaround.
>*/
> - if (boot_cpu_data.f00f_bug) {
> + immediate_if (&f00f_bug_fix) {

This code is not called during normal pagefaults and even during invalid
userspace accesses.

Out of curiosity, I inserted printk() at this place to see where I was
wrong. I got only two hits:

Checking if this processor honours the WP bit even in supervisor 
mode... do_page_fault:
Freeing unused kernel memory: 116k freed
do_page_fault:

Resume: nobody gives a fuck about performance of this particular if,
so conversion it totally pointless.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/12] drivers/isdn: replace pci_find_device with pci_get_device

[Surya]

Hi...
  Recently Keil has accepted few isdn related , pci_find_device
cleanup patches, which are currently in -mm tree and would probably be
in mainline kernel soon..

look the below url shows a mail from karsten keil..
http://marc.info/?l=linux-kernel&m=118029832418653&w=2
Just make sure patch only the files not listed in the above patch..
Also look at the kernel archives before you start patching , just to
make sure somebody has not done it already..


thanks
surya.








List:   linux-kernel
Subject:[PATCH 0/12] drivers/isdn: replace pci_find_device with
pci_get_device
From:   "=?utf-8?q?S=2E=C3=87a=C4=9Flar?= Onur" 
Date:   2007-07-13 22:44:12
Message-ID: 200707140144.14644.caglar () pardus ! org ! tr
[Download message RAW]

Hi;

Following patches replaces pci_find_device with pci_get_device (with some
whitespace cleanups) to avoid following warnings;

warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:478)

occured while compiling the kernel for ages.

Although ISDN subsystem marked as Maintained, last activity on ISDN
subsystem's git tree occured 21 Month ago :( so for this reason i'm adding
LKML also.

[1] http://git.kernel.org/?p=linux/kernel/git/kkeil/isdn-2.6.git;a=summary

Cheers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 4/8] Immediate Value - Add kconfig menus

[Alexey Dobriyan]

On Fri, Jul 13, 2007 at 09:24:43PM -0400, Mathieu Desnoyers wrote:
> Immediate values provide a way to use dynamic code patching to update 
> variables
> sitting within the instruction stream. It saves caches lines normally used by
> static read mostly variables.

>  kernel/Kconfig.immediate |   11 +++

NAK, if this immediate stuff is so super-cool¹ it should be default on.

¹ it isn't

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 5/7] ICH Force HPET: ICH5 quirk to force detect enable

[Robert Hancock]

Venki Pallipadi wrote:


force_enable hpet for ICH5.

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>

---
 arch/i386/kernel/hpet.c   |2 
 arch/i386/kernel/quirks.c |  101 +-
 include/asm-i386/hpet.h   |2 
 include/linux/pci_ids.h   |1 
 4 files changed, 103 insertions(+), 3 deletions(-)




According to some reports, and a quick test I did on my laptop, this 
same method appears to work on the ICH4 chipset, even though the HPET is 
not documented on that chipset. Does Intel have any info on HPET support 
on ICH4 and whether there's any reason we should not force enable it 
there as well?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

signalfd() semantics after execve()

[Michael Kerrisk]

Davide, 

I'm working on the signalfd(2) man page, and I've come
acorss some puzzling behaviour...  

What are the intended semantics of a signalfd file descriptor
after an execve()?

As far as I can work out, after an execve() the file descriptor
is still available, but reads from it always return 0, even if:

a) there were signals pending before the execve().
   However, sigpending() shows the signal as pending,
   and the signal can be accepted using sigwaitinfo().

b) we generate a signal after the execve().
 
Is this intended behavior (the "orphaned sighand" condition
mentioned in the draft man page you sent me?)?  Is it a bug?

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [EXT4 set 5][PATCH 1/1] expand inode i_extra_isize to support features in larger inode

[Peter Zijlstra]

On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
> > I fear the consequences of this change :(
> 
> I love it.  In the past I've lost time by working with patches which
> didn't quite realize that ext3 holds a transaction open during
> ->direct_IO.
> 
> > Oh well, please keep it alive, maybe beat on it a bit, resend it
> > later on?
> 
> I can test the patch to make sure that it catches mistakes I've made in
> the past. 

That would be much appreciated.

>  Peter, do you have any interest in seeing how far we can get
> at tracking lock_page()?  I'm not holding my breath, but any little bit
> would probably help.

Yeah I'm going to try that one next.. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: why does git perpetually complain about include/asm-blackfin/macros.h?

[Sam Ravnborg]

On Mon, Jul 02, 2007 at 10:37:28AM -0400, Jeff Garzik wrote:
> Alex Riesen wrote:
> >Do some of your branches miss the commit by which it was removed?
> 
> git-clone followed by git-checkout master recreates the problem.
> 
> But to answer your question directly, I rebase, so they absolutely do 
> not miss any commits.
> 
> 
> >It is somewhat unclear what "reappear" means, though: do you mean
> 
> Attempts to give you precise output to answer your question yielded a 
> data point, the kernel's "make distclean" causes this:
> 
> [EMAIL PROTECTED] linux-2.6]$ make distclean && git checkout master && 
> git diff HEAD
> D   include/asm-blackfin/macros.h
> Switched to branch "master"
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..000
> 
> [EMAIL PROTECTED] linux-2.6]$ git checkout -f
> 
> [EMAIL PROTECTED] linux-2.6]$ make distclean && git checkout master && 
> git diff HEAD
> D   include/asm-blackfin/macros.h
> Switched to branch "master"
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..000
> 
> [EMAIL PROTECTED] linux-2.6]$ git checkout -f
> 
> [EMAIL PROTECTED] linux-2.6]$ git checkout master && git diff 
> HEADSwitched to branch "master"
> 
> [EMAIL PROTECTED] linux-2.6]$ git checkout master && git diff HEAD
> Switched to branch "master"
> 
> [EMAIL PROTECTED] linux-2.6]$
> 
> 
> So, not a git problem but a kernel Makefile problem.  Sorry for the git 
> noise.

distclean on purpose delete zero size files.
And the kernel tree shall not contain such files - if it does it is a bug.

So I do not see a 'problem' with the kernel makefile but instead a problem
with the kernel tree wich is about to be fixed.

Agree?

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: [PATCH 5/7] ICH Force HPET: ICH5 quirk to force detect enable

[Thomas Gleixner]

On Sat, 2007-07-14 at 01:35 -0600, Robert Hancock wrote:
> According to some reports, and a quick test I did on my laptop, this 
> same method appears to work on the ICH4 chipset, even though the HPET is 
> not documented on that chipset. Does Intel have any info on HPET support 
> on ICH4 and whether there's any reason we should not force enable it 
> there as well?

There is a patch for ICH4 in my hrt queue:

http://www.tglx.de/projects/hrtimers/

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

[david]

On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:


Ok, now we need a data channel from the old kernel to the hibernate
kernel, to the restore kernel. and the messier the memory layout the
larger this data channel needs to be (hmm, what's the status on the memory
defrag patches being proposed?) if this list can be made small enough it
would work to just have the old kernel put the data in a known location in
ram, and let the other two parts find it (in ram for the hibernate kernel,
in the hibernate image for the wakeup kernel).


I think the hibernation kernel should mmap() the "old" kernel's (and it's
processes') memory available for saving, so that the image-saving process
can read its contents from the original locations.


but I'll bet that not all kernels keep the info in the same place (and 
probably not even in the same format). I'm suggesting that a standard be 
defined for the format of the data and the location of a pointer to it 
that will be maintained across kernel versions.



how do the existing hibernate processes store this?


There are two approaches.  In the first of them (used in the mainline) we just
create copies of all pages eligible for saving (hence we can't create images
larger than 50% of RAM) atomically and then we save the contents of these
copies (either directly from the kernel or through a user space process).  This
way we don't need to worry that they may be modified before we can save
them.

The other approach is the Nigel's one, in which all LRU pages are first saved
and then used as additional storage for copying the rest of memory contents.
This has a drawback that we are not 100% sure if the LRU won't be modified
after we've used them to store the copies of the other pages.


and since both current approaches use the same kernel for everything the 
issues I'm thinking of simply don't apply.



since people are complaining about the amount of ram that a kexec kernel
would take up I'm assuiming it's somethingmore complex then just a bitmap
of all possible pages.


No, it's just bitmaps, AFAICS, and the complaints are a bit overstated, IMO. ;-)


1 bit for each 4k means 1m bits for 4g of ram, or 128k of bitmaps, growing 
up to 1m of ram used for 32G of ram in the system. I guess this isn't bad 
as long as it doesn't need to be contiguous for the new kernel to access 
it.


ok, that makes it a pretty trivial thing to work with. I just need to 
learn how to find the bitmaps.



most of the conversation so far has been around the process of makeing the
snapshot and storing it. what are the processes and tools available to
restore images?


We have quite an efficient restoration code in the kernel right now.  It's
able to upload big images (something like total RAM minus the size of the
boot kernel, initrd and, optionally, the resume application), which is much
more than we're able to save. :-)

It can work with images uploaded via /dev/snapshot from the user space
(specific image format is required, but that can be changed easily).


Ok, so it sounds as if the restore is basicly a solved problem, great!

so now I want to do a but-ugly hibernate configuration.

while I haven't done it yet I am very confident that I can enable kexec 
and create a kernel and filesystem to boot into. I can then use perl to 
get the bitmaps out of kmem (once I learn how to find them), and then can 
read from kmem to a file to save the 4k chunks that I need to a file.


it'll be ugly and use lots of partitions, but it should end up being solid 
from what I am understanding.


where can I learn how to find the bitmaps and what format things need to 
be in to feed into /dev/snapshot?


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel.org needs gitweb help

[Junio C Hamano]

"H. Peter Anvin" <[EMAIL PROTECTED]> writes:

> A lot of people have asked me if there is anything they can do to help
> out kernel.org.  At this point, the number one thing anyone could do to
> help, and which would be reasonably self-contained a project, would be
> to help maintain our fork of gitweb:
>
> http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary
>
> We really need the caching version of gitweb, but it does have a number
> of problems, including the non-working tarball generator.

Are there an issues-list for the forked gitweb somewhere, or
would the first step of people who would want to help be to
build such a list?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] libata: add taskfile protocol ->proto_mask info member

[Jeff Garzik]

These patches add proto_mask alongside pio_mask, mwdma_mask, and
udma_mask.  This is a more uniform way to export which features host
controllers support (DMA? NCQ? ATAPI? ATAPI DMA?), rather than creating
a new ATA_FLAG_xxx for each.

This also opens the door to useful things like combining "if
protocol==foo || protocol==bar" tests into a single mask, or masking
between host and device to determine common protocols.

Suggestions for improvement welcome, this is just the first cut.  Stored
on libata-dev.git#pmask for now.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] libata: add ->proto_mask

[Jeff Garzik]

commit c7baac44f3a02b895873cce48c6e426ddbea06b9
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Sat Jul 14 03:27:11 2007 -0400

[libata] Introduce per-port taskfile protocol masks

One ATA_PMASK_$name bitmapped value exists for each ATA_PROT_$name
value.

->proto_mask member added to ata_port and ata_port_info for holding
this data.

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

 drivers/ata/libata-core.c |3 +++
 drivers/ata/libata-scsi.c |1 +
 include/linux/ata.h   |   20 
 include/linux/libata.h|7 +++
 4 files changed, 31 insertions(+)

c7baac44f3a02b895873cce48c6e426ddbea06b9
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 88e2dd0..5cffca8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6007,6 +6007,7 @@ void ata_dev_init(struct ata_device *dev)
dev->pio_mask = UINT_MAX;
dev->mwdma_mask = UINT_MAX;
dev->udma_mask = UINT_MAX;
+   dev->proto_mask = UINT_MAX;
 }
 
 /**
@@ -6211,6 +6212,8 @@ struct ata_host *ata_host_alloc_pinfo(struct device *dev,
ap->pio_mask = pi->pio_mask;
ap->mwdma_mask = pi->mwdma_mask;
ap->udma_mask = pi->udma_mask;
+   ap->proto_mask = pi->proto_mask;
+
ap->flags |= pi->flags;
ap->ops = pi->port_ops;
 
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index cfde22d..f6da0cb 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -3234,6 +3234,7 @@ struct ata_port *ata_sas_port_alloc(struct ata_host *host,
ap->pio_mask = port_info->pio_mask;
ap->mwdma_mask = port_info->mwdma_mask;
ap->udma_mask = port_info->udma_mask;
+   ap->proto_mask = port_info->proto_mask;
ap->flags |= port_info->flags;
ap->ops = port_info->port_ops;
ap->cbl = ATA_CBL_SATA;
diff --git a/include/linux/ata.h b/include/linux/ata.h
index b5a2016..c5c4780 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -283,6 +283,26 @@ enum ata_tf_protocols {
ATA_PROT_ATAPI_DMA, /* packet command with special DMA sauce */
 };
 
+#define DEF(x) \
+   ATA_PMASK_##x = (1 << ATA_PROT_##x)
+enum ata_tf_proto_masks {
+   DEF(NODATA),
+   DEF(PIO),
+   DEF(DMA),
+   DEF(NCQ),
+   DEF(ATAPI),
+   DEF(ATAPI_NODATA),
+   DEF(ATAPI_DMA),
+};
+#undef DEF
+
+enum ata_standard_proto_masks {
+   ATA_PMASK_SFF   = ATA_PMASK_NODATA | ATA_PMASK_PIO |
+ ATA_PMASK_ATAPI | ATA_PMASK_ATAPI_NODATA,
+   ATA_PMASK_SFF_DMA   = ATA_PMASK_SFF |
+ ATA_PMASK_DMA | ATA_PMASK_ATAPI_DMA,
+};
+
 enum ata_ioctls {
ATA_IOC_GET_IO32= 0x309,
ATA_IOC_SET_IO32= 0x324,
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 47cd2a1..2f9174c 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -457,6 +457,7 @@ struct ata_device {
unsigned intpio_mask;
unsigned intmwdma_mask;
unsigned intudma_mask;
+   unsigned intproto_mask;
 
/* for CHS addressing */
u16 cylinders;  /* Number of cylinders */
@@ -524,9 +525,12 @@ struct ata_port {
 
u8  ctl;/* cache of ATA control register */
u8  last_ctl;   /* Cache last written value */
+
unsigned intpio_mask;
unsigned intmwdma_mask;
unsigned intudma_mask;
+   unsigned intproto_mask;
+
unsigned intcbl;/* cable type; ATA_CBL_xxx */
unsigned inthw_sata_spd_limit;
unsigned intsata_spd_limit; /* SATA PHY speed limit */
@@ -638,9 +642,12 @@ struct ata_port_operations {
 struct ata_port_info {
struct scsi_host_template   *sht;
unsigned long   flags;
+
unsigned long   pio_mask;
unsigned long   mwdma_mask;
unsigned long   udma_mask;
+   unsigned long   proto_mask;
+
const struct ata_port_operations *port_ops;
irq_handler_t   irq_handler;
void*private_data;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] libata: use ->proto_mask in drivers

[Jeff Garzik]

Review definitely helps here...


commit b8485b72aa93a82bcb48835f04c8cf06cd0b1f37
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Sat Jul 14 03:54:56 2007 -0400

[libata] Fill in ->proto_mask setting for all drivers

Using observations on pio_mask/mwdma_mask/udma_mask settings, set
->proto_mask to either ATA_PMASK_SFF (no DMA) or ATA_PMASK_SFF_DMA.

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

 drivers/ata/ahci.c  |6 ++
 drivers/ata/ata_generic.c   |   13 +++--
 drivers/ata/ata_piix.c  |   13 +
 drivers/ata/pata_ali.c  |7 +++
 drivers/ata/pata_amd.c  |   10 ++
 drivers/ata/pata_artop.c|3 +++
 drivers/ata/pata_atiixp.c   |1 +
 drivers/ata/pata_cmd640.c   |1 +
 drivers/ata/pata_cmd64x.c   |6 ++
 drivers/ata/pata_cs5520.c   |1 +
 drivers/ata/pata_cs5530.c   |2 ++
 drivers/ata/pata_cs5535.c   |1 +
 drivers/ata/pata_cypress.c  |1 +
 drivers/ata/pata_efar.c |1 +
 drivers/ata/pata_hpt366.c   |1 +
 drivers/ata/pata_hpt37x.c   |6 ++
 drivers/ata/pata_hpt3x2n.c  |1 +
 drivers/ata/pata_hpt3x3.c   |3 +++
 drivers/ata/pata_icside.c   |4 
 drivers/ata/pata_isapnp.c   |1 +
 drivers/ata/pata_it8213.c   |1 +
 drivers/ata/pata_it821x.c   |2 ++
 drivers/ata/pata_ixp4xx_cf.c|1 +
 drivers/ata/pata_jmicron.c  |1 +
 drivers/ata/pata_legacy.c   |1 +
 drivers/ata/pata_marvell.c  |2 ++
 drivers/ata/pata_mpc52xx.c  |1 +
 drivers/ata/pata_mpiix.c|1 +
 drivers/ata/pata_netcell.c  |1 +
 drivers/ata/pata_ns87410.c  |1 +
 drivers/ata/pata_oldpiix.c  |1 +
 drivers/ata/pata_opti.c |1 +
 drivers/ata/pata_optidma.c  |2 ++
 drivers/ata/pata_pcmcia.c   |1 +
 drivers/ata/pata_pdc2027x.c |2 ++
 drivers/ata/pata_pdc202xx_old.c |3 +++
 drivers/ata/pata_platform.c |1 +
 drivers/ata/pata_qdi.c  |2 ++
 drivers/ata/pata_radisys.c  |1 +
 drivers/ata/pata_rz1000.c   |1 +
 drivers/ata/pata_sc1200.c   |1 +
 drivers/ata/pata_scc.c  |1 +
 drivers/ata/pata_serverworks.c  |4 
 drivers/ata/pata_sil680.c   |2 ++
 drivers/ata/pata_sis.c  |   10 +-
 drivers/ata/pata_sl82c105.c |2 ++
 drivers/ata/pata_triflex.c  |1 +
 drivers/ata/pata_via.c  |6 ++
 drivers/ata/pata_winbond.c  |1 +
 drivers/ata/pdc_adma.c  |1 +
 drivers/ata/sata_inic162x.c |1 +
 drivers/ata/sata_mv.c   |7 +++
 drivers/ata/sata_nv.c   |4 
 drivers/ata/sata_promise.c  |7 +++
 drivers/ata/sata_qstor.c|1 +
 drivers/ata/sata_sil.c  |4 
 drivers/ata/sata_sil24.c|3 +++
 drivers/ata/sata_sis.c  |1 +
 drivers/ata/sata_svw.c  |2 ++
 drivers/ata/sata_sx4.c  |1 +
 drivers/ata/sata_uli.c  |1 +
 drivers/ata/sata_via.c  |3 +++
 drivers/ata/sata_vsc.c  |1 +
 63 files changed, 167 insertions(+), 7 deletions(-)

b8485b72aa93a82bcb48835f04c8cf06cd0b1f37
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 11e4eb9..9043642 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -334,6 +334,7 @@ static const struct ata_port_info ahci_port_info[] = {
.flags  = AHCI_FLAG_COMMON,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
+   .proto_mask = ATA_PMASK_SFF_DMA,
.port_ops   = &ahci_ops,
},
/* board_ahci_pi */
@@ -341,6 +342,7 @@ static const struct ata_port_info ahci_port_info[] = {
.flags  = AHCI_FLAG_COMMON | AHCI_FLAG_HONOR_PI,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
+   .proto_mask = ATA_PMASK_SFF_DMA,
.port_ops   = &ahci_ops,
},
/* board_ahci_vt8251 */
@@ -349,6 +351,7 @@ static const struct ata_port_info ahci_port_info[] = {
  AHCI_FLAG_NO_NCQ,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
+   .proto_mask = ATA_PMASK_SFF_DMA,
.port_ops   = &ahci_vt8251_ops,
},
/* board_ahci_ign_iferr */
@@ -356,6 +359,7 @@ static const struct ata_port_info ahci_port_info[] = {
.flags  = AHCI_FLAG_COMMON | AHCI_FLAG_IGN_IRQ_IF_ERR,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
+   .proto_mask = ATA_PMASK_SFF_DMA,
.port_ops   = &ahci_ops,
},
/* board_ahci_sb600 */
@@ -365,6 +369,7 @@ static const struct ata_port_info ahci_port_info[] =

[PATCH 3/3] libata: replace ATA_FLAG_{NCQ,NO_ATAPI} using ->proto_mask

[Jeff Garzik]

commit a02791c8298bc0c2202a49c5e781ed2c68132dc8
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Sat Jul 14 04:10:11 2007 -0400

[libata] Use ->proto_mask to replace NCQ and NO_ATAPI flags

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

 drivers/ata/ahci.c   |2 +-
 drivers/ata/libata-core.c|2 +-
 drivers/ata/libata-scsi.c|2 +-
 drivers/ata/pata_ixp4xx_cf.c |4 ++--
 drivers/ata/sata_mv.c|   19 ++-
 drivers/ata/sata_nv.c|4 ++--
 drivers/ata/sata_sil24.c |8 
 drivers/ata/sata_sx4.c   |5 +++--
 include/linux/ata.h  |2 ++
 include/linux/libata.h   |2 --
 10 files changed, 26 insertions(+), 24 deletions(-)

a02791c8298bc0c2202a49c5e781ed2c68132dc8
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9043642..676aa6c 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1801,7 +1801,7 @@ static int ahci_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
/* prepare host */
if (!(pi.flags & AHCI_FLAG_NO_NCQ) && (hpriv->cap & HOST_CAP_NCQ))
-   pi.flags |= ATA_FLAG_NCQ;
+   pi.proto_mask |= ATA_PMASK_NCQ;
 
host = ata_host_alloc_pinfo(&pdev->dev, ppi, fls(hpriv->port_map));
if (!host)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5cffca8..5036e83 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1789,7 +1789,7 @@ static void ata_dev_config_ncq(struct ata_device *dev,
snprintf(desc, desc_sz, "NCQ (not used)");
return;
}
-   if (ap->flags & ATA_FLAG_NCQ) {
+   if (ap->proto_mask & ATA_PMASK_NCQ) {
hdepth = min(ap->scsi_host->can_queue, ATA_MAX_QUEUE - 1);
dev->flags |= ATA_DFLAG_NCQ;
}
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index f6da0cb..60ccf12 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2458,7 +2458,7 @@ static int ata_scsi_dev_enabled(struct ata_device *dev)
if (unlikely(!ata_dev_enabled(dev)))
return 0;
 
-   if (!atapi_enabled || (dev->ap->flags & ATA_FLAG_NO_ATAPI)) {
+   if (!atapi_enabled || (!(dev->ap->proto_mask & ATA_PMASK_ALL_ATAPI))) {
if (unlikely(dev->class == ATA_DEV_ATAPI)) {
ata_dev_printk(dev, KERN_WARNING,
   "WARNING: ATAPI is %s, device 
ignored.\n",
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 121e7af..cb81a43 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -201,8 +201,8 @@ static __devinit int ixp4xx_pata_probe(struct 
platform_device *pdev)
 
ap->ops = &ixp4xx_port_ops;
ap->pio_mask = 0x1f; /* PIO4 */
-   ap->proto_mask = ATA_PMASK_SFF;
-   ap->flags |= ATA_FLAG_MMIO | ATA_FLAG_NO_LEGACY | ATA_FLAG_NO_ATAPI;
+   ap->proto_mask = ATA_PMASK_NODATA | ATA_PMASK_PIO;
+   ap->flags |= ATA_FLAG_MMIO | ATA_FLAG_NO_LEGACY;
 
ixp4xx_setup_port(&ap->ioaddr, data);
 
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index f45867e..8cd4384 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -127,9 +127,10 @@ enum {
MV_FLAG_DUAL_HC = (1 << 30),  /* two SATA Host Controllers */
MV_FLAG_IRQ_COALESCE= (1 << 29),  /* IRQ coalescing capability */
MV_COMMON_FLAGS = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
- ATA_FLAG_MMIO | ATA_FLAG_NO_ATAPI |
- ATA_FLAG_PIO_POLLING,
+ ATA_FLAG_MMIO | ATA_FLAG_PIO_POLLING,
MV_6XXX_FLAGS   = MV_FLAG_IRQ_COALESCE,
+   MV_PMASK= ATA_PMASK_NODATA | ATA_PMASK_PIO |
+ ATA_PMASK_DMA,
 
CRQB_FLAG_READ  = (1 << 0),
CRQB_TAG_SHIFT  = 1,
@@ -574,28 +575,28 @@ static const struct ata_port_info mv_port_info[] = {
.flags  = MV_COMMON_FLAGS,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
-   .proto_mask = ATA_PMASK_SFF_DMA,
+   .proto_mask = MV_PMASK,
.port_ops   = &mv5_ops,
},
{  /* chip_508x */
.flags  = MV_COMMON_FLAGS | MV_FLAG_DUAL_HC,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
-   .proto_mask = ATA_PMASK_SFF_DMA,
+   .proto_mask = MV_PMASK,
.port_ops   = &mv5_ops,
},
{  /* chip_5080 */
.flags  = MV_COMMON_FLAGS | MV_FLAG_DUAL_HC,
.pio_mask   = 0x1f, /* pio0-4 */
.udma_mask  = ATA_UDMA6,
-   .proto_mask = ATA_PMASK_SFF_DMA,
+   .proto_mask = MV_P

Re: [PATCH 1/6][TAKE7] manpage for fallocate

[Michael Kerrisk]

[CC += [EMAIL PROTECTED]

Amit,

Thanks for this page.  I will endeavour to review it in 
the coming days.  In the meantime, the better address to CC
me on fot man pages stuff is [EMAIL PROTECTED]

Cheers,

Michael

> Following is the modified version of the manpage originally submitted by
> David Chinner. Please use `nroff -man fallocate.2 | less` to view.
> 
> This includes changes suggested by Heikki Orsila and Barry Naujok.
> 
> 
> .TH fallocate 2
> .SH NAME
> fallocate \- allocate or remove file space
> .SH SYNOPSIS
> .nf
> .B #include 
> .PP
> .BI "long fallocate(int " fd ", int " mode ", loff_t " offset ", loff_t "
> len);
> .SH DESCRIPTION
> The
> .B fallocate
> syscall allows a user to directly manipulate the allocated disk space
> for the file referred to by
> .I fd
> for the byte range starting at
> .I offset
> and continuing for
> .I len
> bytes.
> The
> .I mode
> parameter determines the operation to be performed on the given range.
> Currently there are two modes:
> .TP
> .B FALLOC_ALLOCATE
> allocates and initialises to zero the disk space within the given range.
> After a successful call, subsequent writes are guaranteed not to fail
> because
> of lack of disk space.  If the size of the file is less than
> .IR offset + len ,
> then the file is increased to this size; otherwise the file size is left
> unchanged.
> .B FALLOC_ALLOCATE
> closely resembles
> .BR posix_fallocate (3)
> and is intended as a method of optimally implementing this function.
> .B FALLOC_ALLOCATE
> may allocate a larger range than that was specified.
> .TP
> .B FALLOC_RESV_SPACE
> provides the same functionality as
> .B FALLOC_ALLOCATE
> except it does not ever change the file size. This allows allocation
> of zero blocks beyond the end of file and is useful for optimising
> append workloads.
> .SH RETURN VALUE
> .B fallocate
> returns zero on success, or an error number on failure.
> Note that
> .I errno
> is not set.
> .SH ERRORS
> .TP
> .B EBADF
> .I fd
> is not a valid file descriptor, or is not opened for writing.
> .TP
> .B EFBIG
> .IR offset + len
> exceeds the maximum file size.
> .TP
> .B EINVAL
> .I offset
> was less than 0, or
> .I len
> was less than or equal to 0.
> .TP
> .B ENODEV
> .I fd
> does not refer to a regular file or a directory.
> .TP
> .B ENOSPC
> There is not enough space left on the device containing the file
> referred to by
> .IR fd .
> .TP
> .B ESPIPE
> .I fd
> refers to a pipe of file descriptor.
> .TP
> .B ENOSYS
> The filesystem underlying the file descriptor does not support this
> operation.
> .TP
> .B EINTR
> A signal was caught during execution
> .TP
> .B EIO
> An I/O error occurred while reading from or writing to a file system.
> .TP
> .B EOPNOTSUPP
> The mode is not supported on the file descriptor.
> .SH AVAILABILITY
> The
> .B fallocate
> system call is available since 2.6.XX
> .SH SEE ALSO
> .BR syscall (2),
> .BR posix_fadvise (3),
> .BR ftruncate (3).

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add a movablecore= parameter for sizing ZONE_MOVABLE

[Nick Piggin]

On Fri, Jul 13, 2007 at 04:56:10PM +0100, Mel Gorman wrote:
> On (12/07/07 22:32), Mel Gorman didst pronounce:
> 
> > > Should we at least go for
> > > 
> > > add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated.patch
> > > create-the-zone_movable-zone.patch
> > > allow-huge-page-allocations-to-use-gfp_high_movable.patch
> > > handle-kernelcore=-generic.patch
> > > 
> > > in 2.6.23?
> > 
> > Well, yes please from me obviously :) . There is one additional patch
> > I would like to send on tomorrow and that is providing the movablecore=
> 
> This is the patch. It has been boot-tested on a number of machines and
> behaves as expected. Nick, with this in addition, do you have any
> objection to the ZONE_MOVABLE patches going through to 2.6.23?

What's the status of making it configurable? I didn't see something
in -mm for that yet?

But that's not as important as ensuring the concept and user visible
stuff is in good shape, which I no longer have any problems with. So
yeah I think it would be good to get this in and get people up and
running with it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Kexec jump: The first step to kexec base hibernation

[david]

by the way, a data point on kernel sizes

-rw-r--r-- 1 root root  864648 Jul 14 00:53 vmlinuz.2.6.22.1.hibernate
-rw-r--r-- 1 root root  659496 Jul 14 01:17 vmlinuz.2.6.22.1.hibernate.stripped
-rw-r--r-- 1 root root 3948168 Jul 14 01:10 vmlinuz.2.6.22.1.running

the running one matches the config I'm running on my home server, the 
hibernate is a pretty stripped down version, and the stripped is close to 
a minimum (including turning off printk and BUG()). All three are with all 
drivers built-in, no module support.


this is on a amd64 64 bit system

configs are available if anyone cares, the point is how much smaller a 
kernel could be if it doesn't need all the stuff that you put in your main 
kernel. In my case this includes not enabling the 3-ware card that holds 
my 12-disk raid array, instead the hibernate image would be stored on one 
of the scsi drives attached to the adaptec 78xx card.


I expect that on a normal desktop/laptop with more features (like sound) 
the savings could be even more significant


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] X86_64: hpet tsc calibration fix broken smi detection logic

[Thomas Gleixner]

The current SMI detection logic in read_hpet_tsc() makes sure,
that when a SMI happens between the read of the HPET counter and
the read of the TSC, this wrong value is used for TSC calibration.

This is not the intention of the function. The comparison must ensure,
that we do _NOT_ use such a value.

Fix the check to use calibration values where delta of the two TSC reads
is smaller than a reasonable threshold.

Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>

--- a/arch/x86_64/kernel/hpet.c
+++ b/arch/x86_64/kernel/hpet.c
@@ -190,7 +190,7 @@ int hpet_reenable(void)
  */
 
 #define TICK_COUNT 1
-#define TICK_MIN   5000
+#define SMI_THRESHOLD 5
 #define MAX_TRIES  5
 
 /*
@@ -205,7 +205,7 @@ static void __init read_hpet_tsc(int *hpet, int *tsc)
tsc1 = get_cycles_sync();
hpet1 = hpet_readl(HPET_COUNTER);
tsc2 = get_cycles_sync();
-   if (tsc2 - tsc1 > TICK_MIN)
+   if ((tsc2 - tsc1) < SMI_TRESHOLD)
break;
}
*hpet = hpet1;


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] generic_nvram: use inode lock not lock_kernel

[Alan Cox]

> Can we just use generic_file_llseek() in here?  afacit that simply requires
> that i_size have the correct value.  Does it?

Yes.

> Generic_file_llseek() uses file->f_mapping->host->i_mutex which is
> equivalent for this file, but we might as well be consistent.

Last time I used file->f_mapping->host-> for this in another driver Al
Viro asked me to use the f_path sequence instead. So I've always done
that since.

If it is correct to use the other then generic_file_llseek looks fine, if
not perhaps we need generic_device_llseek() ?

Al - there are many clones of these lseek methods - which should we be
using ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] libata: use ->proto_mask in drivers

[Alan Cox]

On Sat, 14 Jul 2007 04:17:28 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:

> 
> Review definitely helps here...

Without knowing what the precise semantics are that is hard. Every
SFF_DMA case may not be supporting DMA depending upon the configuration
so it should probably be set by ata_pci_init_one for all the normal SFF
devices.

Thus I would say
- Drop every user of ata_pci_init_one from the patch

in ata_pci_init_one set it to SFF
in ata_pci_init_bmdma set it to SFF + DMA on success

and while we are at it this would nicely fix your TODO in
ata_pci_init_bmdma by testing the class when copying the modes over.

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] isofs: mounting to regular file may succeed

[Kirill Kuvaldin]

On Sat, Jul 14, 2007 at 03:47:21AM +0400, Kirill Kuvaldin wrote:
> $ dd if=correct.iso of=bad.iso bs=4k count=8

Oops, sorry, the right command should be:

dd if=correct.iso of=bad.iso bs=4k seek=8
   
 

Kirill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc6-mm1

[Andrew Morton]

On Sat, 14 Jul 2007 01:22:10 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:

> Andrew Morton wrote:
> > +x86_64-dynticks-disable-hpet_id_legsup-hpets.patch
> > 
> >  pretend to fix it
> 
> I'm not sure what this patch does on x86_64, but it seems like it 
> trashes all HPET support on i386?
> 

It might do, if your i386 is old and has the HPET_ID_LEGSUP bit set.

The code path which that patch disables:

--- a/arch/i386/kernel/hpet.c~x86_64-dynticks-disable-hpet_id_legsup-hpets
+++ a/arch/i386/kernel/hpet.c
@@ -376,7 +376,7 @@ int __init hpet_enable(void)
 
clocksource_register(&clocksource_hpet);
 
-   if (id & HPET_ID_LEGSUP) {
+   if (0 && (id & HPET_ID_LEGSUP)) {
hpet_enable_int();
hpet_reserve_platform_timers(id);
/*
_

will, if executed (on x86_64, at least), instaoops the machine.  It might
take down i386 as well, dunno.

I'd forgotten about this problem, and it seems that Thomas & John have too.
It's a showstopper.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Kexec jump: The first step to kexec base hibernation

[Rafael J. Wysocki]

On Saturday, 14 July 2007 10:33, [EMAIL PROTECTED] wrote:
> by the way, a data point on kernel sizes
> 
> -rw-r--r-- 1 root root  864648 Jul 14 00:53 vmlinuz.2.6.22.1.hibernate
> -rw-r--r-- 1 root root  659496 Jul 14 01:17 
> vmlinuz.2.6.22.1.hibernate.stripped
> -rw-r--r-- 1 root root 3948168 Jul 14 01:10 vmlinuz.2.6.22.1.running
> 
> the running one matches the config I'm running on my home server, the 
> hibernate is a pretty stripped down version, and the stripped is close to 
> a minimum (including turning off printk and BUG()). All three are with all 
> drivers built-in, no module support.
> 
> this is on a amd64 64 bit system
> 
> configs are available if anyone cares, the point is how much smaller a 
> kernel could be if it doesn't need all the stuff that you put in your main 
> kernel. In my case this includes not enabling the 3-ware card that holds 
> my 12-disk raid array, instead the hibernate image would be stored on one 
> of the scsi drives attached to the adaptec 78xx card.
> 
> I expect that on a normal desktop/laptop with more features (like sound) 
> the savings could be even more significant

But the kernel needs some data to work too (a 'struct page' for each memory
page etc.).

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: kernel.org needs gitweb help

[J.H.]

There's a todo list in the back of my head, I will try and write it up
this weekend and get it posted.

- John 'Warthog9' Hawley

On Sat, 2007-07-14 at 01:12 -0700, Junio C Hamano wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> 
> > A lot of people have asked me if there is anything they can do to help
> > out kernel.org.  At this point, the number one thing anyone could do to
> > help, and which would be reasonably self-contained a project, would be
> > to help maintain our fork of gitweb:
> >
> > http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary
> >
> > We really need the caching version of gitweb, but it does have a number
> > of problems, including the non-working tarball generator.
> 
> Are there an issues-list for the forked gitweb somewhere, or
> would the first step of people who would want to help be to
> build such a list?
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.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 0/12] drivers/isdn: replace pci_find_device with pci_get_device

[S.Çağlar Onur]

Hi;

14 Tem 2007 Cts tarihinde, Surya şunları yazmıştı: 
>Recently Keil has accepted few isdn related , pci_find_device
> cleanup patches, which are currently in -mm tree and would probably be
> in mainline kernel soon..
>
> look the below url shows a mail from karsten keil..
> http://marc.info/?l=linux-kernel&m=118029832418653&w=2
> Just make sure patch only the files not listed in the above patch..
> Also look at the kernel archives before you start patching , just to
> make sure somebody has not done it already..

Ahh, i was checked the -mm and isdn tree before sending these but somehow i 
missed that one, thanks for the info and sorry for noise :)

Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


signature.asc
Description: This is a digitally signed message part.

Re: Patch Related with Fork Bombing Attack

[WANG Cong]

On Fri, Jul 13, 2007 at 06:09:02PM +0530, Anand Jahagirdar wrote:
>Hello All

{snip}

>Index: root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c
>===
>--- root.orig/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c 
>2007-06-26 20:40:06.0 +0530
>+++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c  
>2007-06-26 20:41:41.0 +0530

Please make your patch be in `patch -p1' form.

See: http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt to learn more.

Regards!

-- 

If loving computers is wrong, I don't want to be right.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hibernating To Swap Considered Harmful

[Rafael J. Wysocki]

On Saturday, 14 July 2007 02:45, Joseph Fannin wrote:
> On Fri, Jul 13, 2007 at 11:30:50AM +0200, Rafael J. Wysocki wrote:
> > On Friday, 13 July 2007 07:42, Joseph Fannin wrote:
> > > On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote:
> > > > On Thu, 12 Jul 2007, Rafael J. Wysocki wrote:
> > >
> > > > > Plus we need to figure out how to avoid corrupting filesystems and
> > > > > swap in use by the "old" kernel and its processes (hint: a separate
> > > > > "hibernation partition" is a no-go).
> > > >
> > > > I thought the existing hibernation wrote to the swap partition as it's
> > > > dedicated space?
> > > >
> > > > I didn't know that anyone was suggesting writing the hibernation image 
> > > > to
> > > > a filesystem that the kernel was activly accessing.
> > >
> > > I'm suggesting a dedicated, preallocated hibernation *file*, right
> > > now.  There's no way around it, if hibernation is to be reliable --
> > > otherwise hibernation can fail if the system has used enough of its
> > > swap space, so that there isn't enough room to write the hibernate
> > > image.
> > >
> > > Even if it's desirable to allow hibernation to fail if the system is
> > > too deep into swap, it's a moot point.
> >
> > If you're afraid of that, use a dedicated swap file.
> 
> I don't understand what you mean.  A dedicated swap file for what?

Sorry, I should have been more precise.

For hibernation (ie. a swap file that you activate right befor the
hibernation).

Also tuxonice (formerly known as suspend2) allows you to use regular files
hibernation.

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 0/2] Kexec jump: The first step to kexec base hibernation

[Rafael J. Wysocki]

On Saturday, 14 July 2007 07:48, Huang, Ying wrote:
> On Fri, 2007-07-13 at 10:43 -0600, Eric W. Biederman wrote:
> > > Why a assembly stub is necessary? Is it not sufficient that just
> > > continue to complete a normal boot (hot add the reset of memory) or load
> > > the hibernated kernel (hibernated image) and jump to it?
> > 
> > I was thinking the assembly stub would be the small piece that jumps
> > to loaded hibernated kernel.  Quite possibly we could just get away
> > with providing no memory and just an entry point to kexec but it
> > makes sense to me to plan on running a couple of instructions.
> 
> Oh, I got it. In my patch, there is such assembly stub in
> arch/i386/kernel/kexec_jump.S. I think it is needed to restore basic CPU
> state and accommodate some position independent restore code (such as
> memory restore code).
> 
> > Actually the way the kexec infrastructure it might be reasonable to
> > just use sys_kexec_load to load the entire hibernated image.  Except
> > for the fact that sys_kexec_load requires the source pages to be
> > in the processes memory image the code shouldn't have the 50% of
> > memory limitation already.
> > 
> > If we can get that going we don't even need to restrict the first
> > kernels memory.  So it might just require teaching sys_kexec_load
> > how to steal process pages.  Anyway something to think about.
> 
> As for memory backupping and restoring during hibernating and resuming,
> I think a possible picture can be as follow:
> 
> Memory:
> 
>   Total memory: 512M
>   Memory used by hibernating/resuming kernel: 0~16M
> 
> 
> Hibernating process:
> 
>   1. Normal kernel running
>   2. Hibernating is triggered, sys_kexec_load is used to load
>  hibernating kernel and initramfs into memory. Then
>  sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
>   3. In sys_reboot, kexec_jump is called to save device/CPU state,
>  then relocate_kernel is called. kexec_jump and relocate_kernel
>  reside in individual page in 16M~512M.

OK

What's going to happen to devices at this point?

>   4. In relocate_kernel, 0~16M is backupped firstly, then the
>  hibernating kernel and initramfs is copied to 0~16M, after that,
>  the hibernating kernel is booted.
>   5. In hibernating kernel, the memory of normal kernel (it is in
>  16M~512M) is saved into a hibernation image through /dev/mem
>  and ELF header.

I don't think it can be _that_ simple:
(a) what about processes' memory
(b) what about areas that shouldn't be saved?

> Resume process:
> 
>   1. Resuming kernel is booted as a normal kernel, but the memory is
>  restricted to 0~16M.
>   2. Checking whether there is a effective hibernation image. If
>  there isn't, the memory of 16M~512M is hot added, and the normal
>  boot up process continues; If there is, a resuming process is
>  triggered.
>   3. sys_kexec_load is used to restore the memory state of hibernated
>  kernel. The sys_kexec_load works in crashdump way, that is, the
>  hibernation image is copied to destination location in 16M~512M
>  in sys_kexec_load instead of relocate_kernel. There is no half
>  of memory size restriction.
>   4. sys_reboot is called to trigger jumping back, which will jump back
>  to kexec_jump of hibernated kernel.
>   5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
>  back from the backup area in 16M~512M. The memory state of
>  hibernated kernel is restored totally. The CPU and device state
>  can be restored after that.

Well, I don't know why this needs to be that complicated.  We already have
code in the mainline that's able to load a large hibernation image into memory
and jump to the kernel being restored.  And it has _no_ 50% of RAM limitation,
this is the _saving_ part of the current code that this limitation comes from.

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] broken lilo check on make install

[Gabriel C]

H. Peter Anvin wrote:
> Gabriel C wrote:
>   
>> I don't use and don't have lilo installed on this system. The attached
>> patch fixes the problem for me.
>>
>> 
>
> You also don't have a /sbin/installkernel, which is arguably a bug too.
>  However, the patch mostly makes sense, although I would suggest putting
> a "sync" in the else clause.
>   

Ok , I've changed the patch to use sync.

> With that caveat, Acked-by: H. Peter Anvin <[EMAIL PROTECTED]>
>
>   

Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>

 arch/i386/boot/install.sh |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/arch/i386/boot/install.sh b/arch/i386/boot/install.sh
index 5e44c73..cb55f67 100644
--- a/arch/i386/boot/install.sh
+++ b/arch/i386/boot/install.sh
@@ -51,4 +51,11 @@ fi
 cat $2 > $4/vmlinuz
 cp $3 $4/System.map
 
-if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi
+if [ -x /sbin/lilo ]; then
+   /sbin/lilo
+elif [ -x /etc/lilo/install ]; then
+   /etc/lilo/install
+else
+   sync
+   echo "Cannot find LILO."
+fi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: -mm merge plans for 2.6.23

[Jan Engelhardt]

On Jul 14 2007 01:09, Tilman Schmidt wrote:
>Am 13.07.2007 11:46 schrieb Jan Engelhardt:
>> On Jul 10 2007 01:31, Andrew Morton wrote:
>> 
>>> use-menuconfig-objects-isdn-config_isdn_i4l.patch
>>>
>>> tilman didn't like it - might drop
>> 
>> Or replace by his suggestion patch ( http://lkml.org/lkml/2007/5/31/222 )
>
>That posting was just a change proposal for the drivers/isdn/Kconfig
>part, not a complete replacement for the entire patch. If you'd care to
>reissue that patch with the modification I proposed, I'll gladly ack it.
>Alternatively I can also send a full replacement patch if you prefer.

Since I did not really see much of a difference between our two
approaches, I'd be grateful if you could send a full replacement in
the hopes that I see the global picture.


Thanks,
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/

Kernel 2.6.22 + ALSA + Intel HDA = hda_codec: Unknown model

[Justin Piszcz]

Hi all,

I use an A-BIT AW9D-MAX motherboard and while the audio works fine using 
the Intel HDA driver; however, I see this in dmesg:


[   29.188561] Advanced Linux Sound Architecture Driver Version 1.0.14 
(Thu May 31 09:03:25 2007 UTC).

[   29.188728] ACPI: PCI Interrupt :00:1b.0[A] -> GSI 16 (level, low) -> 
IRQ 17
[   29.188822] PCI: Setting latency timer of device :00:1b.0 to 64
[   29.240729] hda_codec: Unknown model for ALC882, trying auto-probe from 
BIOS...
  ^
[   29.280743] ALSA device list:
[   29.280781]   #0: HDA Intel at 0xfdff8000 irq 17

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High 
Definition Audio Controller (rev 01)


Two lspci (-vx) listings attached.

Can we get the PCI ID added to the kernel source so it does not say 
unknown model?


Thanks,

Justin.00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition 
Audio Controller (rev 01)
Subsystem: ABIT Computer Corp. Unknown device 107a
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition 
Audio Controller (rev 01)
Subsystem: ABIT Computer Corp. Unknown device 107a
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at fdff8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 
Enable-
Capabilities: [70] Express Unknown type IRQ 0
Capabilities: [100] Virtual Channel
Capabilities: [130] Unknown (5)
00: 86 80 d8 27 06 00 10 00 01 00 03 04 08 00 00 00
10: 04 80 ff fd 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 7a 10
30: 00 00 00 00 50 00 00 00 00 00 00 00 05 01 00 00

[PATCH] NET_CLS_RSVP6 should depend on IPV6

[Gabriel C]

Hello,

cls_rsvp6 only works with IPV6 enabled kernels and IMO it should depends
on IPV6.


Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>

---

net/sched/Kconfig |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/net/sched/Kconfig b/net/sched/Kconfig
index b466288..200976e 100644
--- a/net/sched/Kconfig
+++ b/net/sched/Kconfig
@@ -299,6 +299,7 @@ config NET_CLS_RSVP
 
 config NET_CLS_RSVP6
tristate "IPv6 Resource Reservation Protocol (RSVP6)"
+   depends on IPV6
select NET_CLS
---help---
  The Resource Reservation Protocol (RSVP) permits end systems to
@@ -306,7 +307,7 @@ config NET_CLS_RSVP6
  is important for real time data such as streaming sound or video.
 
  Say Y here if you want to be able to classify outgoing packets
based
- on their RSVP requests and you are using the IPv6.
+ on their RSVP requests and you are using the IPv6 protocol.
 
  To compile this code as a module, choose M here: the
  module will be called cls_rsvp6.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/8] Kprobes - do not use kprobes mutex in arch code

[Christoph Hellwig]

On Fri, Jul 13, 2007 at 09:21:34PM -0400, Mathieu Desnoyers wrote:
> Remove the kprobes mutex from kprobes.h, since it does not belong there. Also
> remove all use of this mutex in the architecture specific code, replacing it 
> by
> a proper mutex lock/unlock in the architecture agnostic code.

This is not very nice for avr32/sparc64 which have a noop arch_remove_kprobe
and now need to take a mutex to do nothing.  Maybe you can find a nice
way to avoid that?

Except for this issue making kprobes_mutex static to kprobes.c sounds like
a good improvement.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [realtime-preempt] [x86_64] HR_TIMER and/or DYNTICKS cause an early boot freeze

[Maarten Maathuis]

Were can -rt3 be found?

On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:

On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> I have determined that version 2.6.22.1-rt2 freeze after:
>
> NET: Register protocol family 2
>
> This is very early in the boot stage, and i cannot determine what
> exactly causes it.
>
> It happens if either high resolution timers or dynamic ticks are active.
>
> I have included the config file that does work (so dynticks and
> hr_timers are disabled).
>
> Please CC any replies, as i am not a member of this mailinglist.

Try -rt3, that solved this issue for me.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/8] Text Edit Lock

[Christoph Hellwig]

On Fri, Jul 13, 2007 at 09:21:33PM -0400, Mathieu Desnoyers wrote:
> Hi Andrew,
> 
> After refactoring of architecture independant code (mutex to protect text
> edition) vs architecture dependant code (marking/unmarking pages RW) and
> thorough testing, here is the new version of the text edit lock.

Do you have a tarball of your quilt series for markers and all the patches
leading to them?  Trying to hand apply half a dozend patch series is not
too nice :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [realtime-preempt] [x86_64] HR_TIMER and/or DYNTICKS cause an early boot freeze

[Peter Zijlstra]

On Sat, 2007-07-14 at 12:49 +0200, Maarten Maathuis wrote:
> Were can -rt3 be found?

http://lkml.org/lkml/2007/7/13/159

> On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> > > I have determined that version 2.6.22.1-rt2 freeze after:
> > >
> > > NET: Register protocol family 2
> > >
> > > This is very early in the boot stage, and i cannot determine what
> > > exactly causes it.
> > >
> > > It happens if either high resolution timers or dynamic ticks are active.
> > >
> > > I have included the config file that does work (so dynticks and
> > > hr_timers are disabled).
> > >
> > > Please CC any replies, as i am not a member of this mailinglist.
> >
> > Try -rt3, that solved this issue for me.
> >
> >

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Kexec jump: The first step to kexec base hibernation

[Huang, Ying]

On Sat, 2007-07-14 at 11:59 +0200, Rafael J. Wysocki wrote:
> > Hibernating process:
> > 
> >   1. Normal kernel running
> >   2. Hibernating is triggered, sys_kexec_load is used to load
> >  hibernating kernel and initramfs into memory. Then
> >  sys_reboot(LINUX_REBOOT_CMD_KSPAWN) is invoked.
> >   3. In sys_reboot, kexec_jump is called to save device/CPU state,
> >  then relocate_kernel is called. kexec_jump and relocate_kernel
> >  reside in individual page in 16M~512M.
> 
> OK
> What's going to happen to devices at this point?
> 

The devices should be quiesced and the state of devices should be saved
in kexec_jump, before relocate_kernel is called. This needs the
implementation of device hibernating as you mentioned before.

> >   4. In relocate_kernel, 0~16M is backupped firstly, then the
> >  hibernating kernel and initramfs is copied to 0~16M, after that,
> >  the hibernating kernel is booted.
> >   5. In hibernating kernel, the memory of normal kernel (it is in
> >  16M~512M) is saved into a hibernation image through /dev/mem
> >  and ELF header.
> 
> I don't think it can be _that_ simple:
> (a) what about processes' memory
> (b) what about areas that shouldn't be saved?

The mem_map (struct page[]) of every zone of hibernated kernel is
checked.  Necessary pages are saved, like memory snapshot of software
suspend, but in user space.

> > Resume process:
> > 
> >   1. Resuming kernel is booted as a normal kernel, but the memory is
> >  restricted to 0~16M.
> >   2. Checking whether there is a effective hibernation image. If
> >  there isn't, the memory of 16M~512M is hot added, and the normal
> >  boot up process continues; If there is, a resuming process is
> >  triggered.
> >   3. sys_kexec_load is used to restore the memory state of hibernated
> >  kernel. The sys_kexec_load works in crashdump way, that is, the
> >  hibernation image is copied to destination location in 16M~512M
> >  in sys_kexec_load instead of relocate_kernel. There is no half
> >  of memory size restriction.
> >   4. sys_reboot is called to trigger jumping back, which will jump back
> >  to kexec_jump of hibernated kernel.
> >   5. In kexec_jump of hibernated kernel, the memory of 0~16M is copied
> >  back from the backup area in 16M~512M. The memory state of
> >  hibernated kernel is restored totally. The CPU and device state
> >  can be restored after that.
> 
> Well, I don't know why this needs to be that complicated.  We already have
> code in the mainline that's able to load a large hibernation image into memory
> and jump to the kernel being restored.  And it has _no_ 50% of RAM limitation,
> this is the _saving_ part of the current code that this limitation comes from.

There is much similarity between sys_kexec_load and software resuming.
If resuming can be done by sys_kexec_load, then we need not two similar
functionality in kernel.

Best Regards,
Huang Ying
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] trival typo in usb R8A66597 HCD config

[M4rkusXXL]

--- linux-2.6/drivers/usb/host/Kconfig  2007-07-14 13:00:15.0 
+0200
+++ linux-2.6-patched/drivers/usb/host/Kconfig  2007-07-14 
13:09:10.0 +0200
@@ -237,7 +237,7 @@
  module will be called "sl811_cs".

 config USB_R8A66597_HCD
-   tristate "R8A66597 HCD suppoort"
+   tristate "R8A66597 HCD support"
depends on USB
help
  The R8A66597 is a USB 2.0 host and peripheral controller.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

BUG: soft lockup detected on CPU#0!

[CIJOML]

Hi all,

today I have expirienced soft lockup at 2.6.21 kernel. 2.6.22 is taking me 
same problem:

BUG: soft lockup detected on CPU#0!
 [] softlockup_tick+0x98/0xb5
 [] update_process_times+0x33/0x55
 [] tick_nohz_handler+0x54/0xb4
 [] smp_apic_timer_interrupt+0x62/0x72
 [] apic_timer_interrupt+0x28/0x30
 [] ioread32+0x21/0x22
 [] snd_intel8x0_interrupt+0x17/0x1e3 [snd_intel8x0]
 [] snd_intel8x0_interrupt+0x76/0x1d9 [snd_intel8x0m]
 [] handle_IRQ_event+0x1a/0x3f
 [] handle_level_irq+0x93/0xec
 [] do_IRQ+0x79/0x93
 [] smp_apic_timer_interrupt+0x67/0x72
 [] common_interrupt+0x23/0x28
 [] ieee80211_send_probereq+0x93/0x277 [wlan]
 [] scan_next+0x20b/0x47b [wlan]
 [] getnstimeofday+0x2b/0xac
 [] scan_next+0x0/0x47b [wlan]
 [] run_timer_softirq+0x102/0x176
 [] tick_program_event+0x2a/0x49
 [] __do_softirq+0x35/0x75
 [] do_softirq+0x22/0x26
 [] irq_exit+0x29/0x62
 [] smp_apic_timer_interrupt+0x67/0x72
 [] apic_timer_interrupt+0x28/0x30
 ===

Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ANNOUNCE] UidSEC 0.1

[Roberto De Ioris]

UidSEC LSM
This module extends the standard UN*X "resource protection" model adding
some features useful for untrusted multiuser systems 

Current features
  * Deny usage of dmesg to unprivileged users 
  * Hide processes of "other users" to unprivileged users (example: sam
can only see his processes during a 'top' or a 'ps aux') 
  * Deny access to /sys and /config to unprivileged users 
  * Protect usage of bind() syscall using UidBIND 
  * Assign a group that can use dmesg and see all system processes


Download url: http://projects.unbit.it/uidsec/

Patch against 2.6.22 will follow in the next few days

Thanks for testing it

-- 
Roberto De Ioris
http://unbit.it
JID: [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] CFS scheduler, -v19

[Markus]

> i'm pleased to announce release -v19 of the CFS scheduler patchset.
> 
> The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7, 
> v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the 
> usual place:
> 
> http://people.redhat.com/mingo/cfs-scheduler/
Well, I took a 2.6.21 (gentoo-patchset...) and applied your cfs-v19 
patch for the 2.6.21 kernels. Its a amd64 system and the "normal" 
(=only gentoo patches) kernel is working fine!

> As usual, any sort of feedback, bugreport, fix and suggestion is more 
> than welcome!

When I start the system, the mouse is jerking like under heavy load. 
(also its idle!)
Then some programs just quit. They just disappear, no message in any 
log. (It were about four apps I realized in a period of about two hours 
of testing.)

I'll try a git snapshot next, but is there a way I can get more output?

Greetz
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.1: Enabling IO-APIC = APIC error on CPU0: 40(40)

[Justin Piszcz]

I have an older MSI motherboard and when I enable the following option:


From lshw:

   description: Motherboard
   product: MS-6730

[*]   IO-APIC support on uniprocessors

I get the following errors in dmesg:

[  247.177372] APIC error on CPU0: 00(40)
[  247.556741] APIC error on CPU0: 40(40)
[  262.010412] APIC error on CPU0: 40(40)
[  262.765553] APIC error on CPU0: 40(40)
[  263.876481] APIC error on CPU0: 40(40)
[  264.191962] APIC error on CPU0: 40(40)
[  265.040566] APIC error on CPU0: 40(40)
[  267.959689] APIC error on CPU0: 40(40)
[  269.446029] APIC error on CPU0: 40(40)
[  269.853344] APIC error on CPU0: 40(40)
[  271.122825] APIC error on CPU0: 40(40)
[  271.287051] APIC error on CPU0: 40(40)
[  273.825237] APIC error on CPU0: 40(40)
[  274.373737] APIC error on CPU0: 40(40)
[  275.355775] APIC error on CPU0: 40(40)
[  275.982087] APIC error on CPU0: 40(40)
[  276.101181] APIC error on CPU0: 40(40)
[  276.173611] APIC error on CPU0: 40(40)
[  276.970970] APIC error on CPU0: 40(40)
[  277.561575] APIC error on CPU0: 40(40)
[  278.694486] APIC error on CPU0: 40(40)
[  279.353573] APIC error on CPU0: 40(40)
[  281.779398] APIC error on CPU0: 40(40)
[  283.625457] APIC error on CPU0: 40(40)
[  284.749322] APIC error on CPU0: 40(40)
[  284.983013] APIC error on CPU0: 40(40)
[  285.126394] APIC error on CPU0: 40(40)

I normally do not use this option (which also gets rid of the errors*1), 
but I am curious, why do these errors occur?  I remember them with the early

2.6.x series and they are still re-occurring in 2.6.22.1.

The weird part-- is when IO-APIC is disabled, I see this on boot:

IO-APIC DISABLED:

[   46.902712] XFS mounting filesystem md0
[   47.017322] spurious 8259A interrupt: IRQ7.
[   47.273009] Ending clean XFS mount for filesystem: md0

IO-APIC ENABLED:

[   46.851012] XFS mounting filesystem md0
[   47.103066] Ending clean XFS mount for filesystem: md0

* 1 Anytime I see a spurious interrupt on (usually older hardware) 
especially during file I/O this usually means corruption (from what I 
have seen) that is why I don't really want to trust anything on this host.


Anyone have any idea what's going on here?

Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

flooding: "new high speed USB device using ehci_hcd and address"

[Markus]

Hello!

I just build 2.6.22-git5 to test the cfs.

I looked in the log and found:
usb 1-5: new high speed USB device using ehci_hcd and address 2
usb 1-5: new high speed USB device using ehci_hcd and address 3
usb 1-5: new high speed USB device using ehci_hcd and address 4
usb 1-5: new high speed USB device using ehci_hcd and address 5
usb 1-5: new high speed USB device using ehci_hcd and address 6
usb 1-5: new high speed USB device using ehci_hcd and address 7
usb 1-5: new high speed USB device using ehci_hcd and address 8
usb 1-5: new high speed USB device using ehci_hcd and address 9

They do from address 2 up to 127 and then begin again. They are printed 
about three to four times a second.

# lsusb
Bus 002 Device 006: ID 046d:c222 Logitech, Inc.
Bus 002 Device 005: ID 046d:c221 Logitech, Inc.
Bus 002 Device 004: ID 046d:08b5 Logitech, Inc.
Bus 002 Device 003: ID 046d:c041 Logitech, Inc.
Bus 002 Device 002: ID 046d:c223 Logitech, Inc.
Bus 002 Device 001: ID :
Bus 001 Device 001: ID :

# lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller 
(rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 
Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller 
(rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller 
(rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 
GS] (rev a1)
05:06.0 Network controller: Intersil Corporation ISL3890 [Prism GT/Prism 
Duette]/ISL3886 [Prism Javelin/Prism Xbow] (rev 01)
05:07.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135 
Video Broadcast Decoder (rev f0)


   Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops while modprobing phy fixed module

[Gabriel C]

Gabriel C wrote:
> Hi,
>
> doing a modprobe fixed the driver segfaults and I get this Oops:
>
>
> Jul 14 13:43:30 lara [  157.952915] Fixed PHY: Registered new driver
[...]

God , tbird sucks ..

There the dmesg with the Oops :

http://194.231.229.228/kern.log

Should be better to read.

Regards,

Gabriel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add a movablecore= parameter for sizing ZONE_MOVABLE

[Mel Gorman]

On (14/07/07 10:28), Nick Piggin didst pronounce:
> On Fri, Jul 13, 2007 at 04:56:10PM +0100, Mel Gorman wrote:
> > On (12/07/07 22:32), Mel Gorman didst pronounce:
> > 
> > > > Should we at least go for
> > > > 
> > > > add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated.patch
> > > > create-the-zone_movable-zone.patch
> > > > allow-huge-page-allocations-to-use-gfp_high_movable.patch
> > > > handle-kernelcore=-generic.patch
> > > > 
> > > > in 2.6.23?
> > > 
> > > Well, yes please from me obviously :) . There is one additional patch
> > > I would like to send on tomorrow and that is providing the movablecore=
> > 
> > This is the patch. It has been boot-tested on a number of machines and
> > behaves as expected. Nick, with this in addition, do you have any
> > objection to the ZONE_MOVABLE patches going through to 2.6.23?
> 
> What's the status of making it configurable? I didn't see something
> in -mm for that yet?
> 

I have a patch that makes it configurable but Kamezawa-san posted a very
promising patch about making all zones configurable in a very clever way
which is more general than what I did. He posted it as an RFC[1] and there
was feedback from Andy Whitcroft on how it could be made better so it wouldn't
have been picked up for -mm but something is in the pipeline.

I've tested his patch for zone movable and it worked as advertised so I
intended to see post-merge window what else could be done with it clean-up
wise. I am curious to see if it can also make ZONE_NORMAL configurable on
machines that only have ZONE_DMA for example.

> But that's not as important as ensuring the concept and user visible
> stuff is in good shape, which I no longer have any problems with.

Excellent.

> So
> yeah I think it would be good to get this in and get people up and
> running with it.

Thanks Nick.

[1] http://marc.info/?l=linux-mm&m=118405871911268&w=2

-- 
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] eepro100 resume patch

[David Fries]

On Fri, Jul 13, 2007 at 09:11:28PM -0700, Kok, Auke wrote:
> [adding netdev]
> 
> David Fries wrote:
> >When I did a software suspend to disk then resumed the Intel network
> >card using eepro100 driver would be unable to transmit packets.  I
> >tracked this down and found a register write after the print message
> >"DP83840 specific setup" which wasn't being executed when the system
> >was restored.  This fix moves that write and another write which
> >forces the link speed and duplex.
> >
> >After doing this work and preparing the patch I checked out the
> >mailing list only to find a patch that removes the eepro100.  I then
> >updated Kconfig, though I wonder why it didn't have a similar message
> >in it long time ago.
> >
> >I too had tried the e100 driver some time ago and it didn't work,
> 
> That argument is pretty useless right now. Please *test* e100 and *report 
> issues*. I recently did some very intensive suspend/resume testing (and 
> fixes) on e100 and I have yet to hear of any problems with it since... that 
> was 2.6.18 or so even.
> 
> >eepro100 did and I've been using it so long that I've almost forgotten
> >about that.  I just gave the e100 driver a try and I've been running
> >for about an hour now without any problems and it does resume after a
> >suspend to disk operation.
> 
> I don't think I need to NAK this. I doubt that Jeff Garzik will apply this 
> in the first place. eepro100 is on it's way out, so let's focus on what 
> matters.
> 
> Auke

Sorry for not making the point of my e-mail clear.

It would be a good idea when a driver is being obsoleted to flag that
in the Kconfig and give alternatives when they exist.  It will
increase the chance that people will pick the supported driver.

My other point was that e100 didn't use to work with my hardware, I
now have about 12 hours of using the e100 driver without any issues
that I've seen.  Consider that a success report.
:00:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 
100] (rev 01)

Signed-off-by: David Fries <[EMAIL PROTECTED]>

Index: drivers/net/Kconfig
===
RCS file: 
/home/david/kernel/k/spacedout/patches/linux/drivers/net/Attic/Kconfig,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 Kconfig
--- drivers/net/Kconfig 13 Jul 2007 23:16:36 -  1.1.2.1
+++ drivers/net/Kconfig 13 Jul 2007 23:31:29 -
@@ -1467,6 +1467,11 @@
depends on NET_PCI && PCI
select MII
help
+ ** Warning ** eepro100 (this driver) has been requested to be
+ removed from the kernel source tree.  Please use e100 and report
+ any bugs as that is the driver that will be supported going
+ forward.
+
  If you have an Intel EtherExpress PRO/100 PCI network (Ethernet)
  card, say Y and read the Ethernet-HOWTO, available from
  .

-- 
David Fries <[EMAIL PROTECTED]>
http://fries.net/~david/ (PGP encryption key available)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] pure_initcall ID inconsistency

[Michael Buesch]

pure_initcall uses the same ID as core_initcall.
I guess that's a typo and it should use its own ID.

Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/init.h
===
--- linux-2.6.orig/include/linux/init.h 2007-05-26 19:56:35.0 +0200
+++ linux-2.6/include/linux/init.h  2007-07-14 15:59:07.0 +0200
@@ -114,7 +114,7 @@ void prepare_namespace(void);
  *
  * This only exists for built-in code, not for modules.
  */
-#define pure_initcall(fn)  __define_initcall("0",fn,1)
+#define pure_initcall(fn)  __define_initcall("0",fn,0)
 
 #define core_initcall(fn)  __define_initcall("1",fn,1)
 #define core_initcall_sync(fn) __define_initcall("1s",fn,1s)

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ext3_ordered_writepage panic on shiny new 2.6.22

[Dave]

Hi

Light load on my system and encoding a home video to the disk using 
mencoder and i get this...



BUG: unable to handle kernel NULL pointer dereference at virtual address 
0004

 printing eip:
c01a478e
*pde = 
Oops:  [#1]
PREEMPT SMP
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat vmnet(P) parport_pc 
parport vmblock(P) vmmon(P) nvidia(P) bridge iptable_filter appletalk 
psnap llc nfsd exportfs lockd sunrpc ftdi_sio usbserial uhci_hcd 
ehci_hcd ohci_hcd i2c_nforce2 ipt_MASQUERADE iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack ip_tables x_tables forcedeth usblp 
snd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device 
snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 
usb_storage it87 hwmon_vid i2c_isa i2c_dev i2c_core

CPU:1
EIP:0060:[]Tainted: P   VLI
EFLAGS: 00010246   (2.6.22 #2)
EIP is at walk_page_buffers+0x4e/0x90
eax: 0001   ebx:    ecx:    edx: 0001
esi:    edi:    ebp: c8607a7c   esp: cbaabdf8
ds: 007b   es: 007b   fs: 00d8  gs:   ss: 0068
Process pdflush (pid: 2566, ti=cbaaa000 task=d49cb030 task.ti=cbaaa000)
Stack:  d16343d8  c2092360 d16343d8 c8607a7c d16343d8 
c01a7861
   1000  c01a47d0 cbaabebc 0286 cbaabf6c c90ecd3c 
0009
   cbaabf6c  c014b438 c2092360 c014b88f  000e 
c014b430

Call Trace:
 [] ext3_ordered_writepage+0xe1/0x190
 [] bget_one+0x0/0x10
 [] __writepage+0x8/0x30
 [] write_cache_pages+0x1ff/0x320
 [] __writepage+0x0/0x30
 [] __writepage+0x0/0x30
 [] generic_writepages+0x20/0x30
 [] do_writepages+0x49/0x50
 [] __writeback_single_inode+0x94/0x3c0
 [] sync_sb_inodes+0x192/0x270
 [] writeback_inodes+0x95/0xd0
 [] background_writeout+0x89/0xb0
 [] pdflush+0x0/0x1d0
 [] pdflush+0xfe/0x1d0
 [] background_writeout+0x0/0xb0
 [] kthread+0x42/0x70
 [] kthread+0x0/0x70
 [] kernel_thread_helper+0x7/0x14
 ===
Code: 24 85 d2 74 10 8b 01 a8 01 75 0a 8b 44 24 24 c7 00 01 00 00 00 31 
f6 39 fd 89 f9 0f 95 c2 85 db 0f 94 c0 08 c2 74 2e 03 5c 24 08 <8b> 79 
04 3b 1c 24 89 da 0f 96 c0 2b 54 24 08 3b 54 24 20 0f 93

EIP: [] walk_page_buffers+0x4e/0x90 SS:ESP 0068:cbaabdf8

This is an AMD SMP system.

$ uname -a
Linux home 2.6.22 #2 SMP PREEMPT Fri Jul 13 17:56:35 GST 2007 i686 
unknown unknown GNU/Linux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ext3_ordered_writepage panic on shiny new 2.6.22

[Mitch]

Hi

Light load on my system and encoding a home video to the disk using 
mencoder and i get this...



BUG: unable to handle kernel NULL pointer dereference at virtual address 
0004

 printing eip:
c01a478e
*pde = 
Oops:  [#1]
PREEMPT SMP
Modules linked in: nls_iso8859_1 nls_cp437 vfat fat vmnet(P) parport_pc 
parport vmblock(P) vmmon(P) nvidia(P) bridge iptable_filter appletalk 
psnap llc nfsd exportfs lockd sunrpc ftdi_sio usbserial uhci_hcd 
ehci_hcd ohci_hcd i2c_nforce2 ipt_MASQUERADE iptable_nat nf_nat 
nf_conntrack_ipv4 nf_conntrack ip_tables x_tables forcedeth usblp 
snd_hda_intel snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device 
snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd 
usb_storage it87 hwmon_vid i2c_isa i2c_dev i2c_core

CPU:1
EIP:0060:[]Tainted: P   VLI
EFLAGS: 00010246   (2.6.22 #2)
EIP is at walk_page_buffers+0x4e/0x90
eax: 0001   ebx:    ecx:    edx: 0001
esi:    edi:    ebp: c8607a7c   esp: cbaabdf8
ds: 007b   es: 007b   fs: 00d8  gs:   ss: 0068
Process pdflush (pid: 2566, ti=cbaaa000 task=d49cb030 task.ti=cbaaa000)
Stack:  d16343d8  c2092360 d16343d8 c8607a7c d16343d8 
c01a7861
   1000  c01a47d0 cbaabebc 0286 cbaabf6c c90ecd3c 
0009
   cbaabf6c  c014b438 c2092360 c014b88f  000e 
c014b430

Call Trace:
 [] ext3_ordered_writepage+0xe1/0x190
 [] bget_one+0x0/0x10
 [] __writepage+0x8/0x30
 [] write_cache_pages+0x1ff/0x320
 [] __writepage+0x0/0x30
 [] __writepage+0x0/0x30
 [] generic_writepages+0x20/0x30
 [] do_writepages+0x49/0x50
 [] __writeback_single_inode+0x94/0x3c0
 [] sync_sb_inodes+0x192/0x270
 [] writeback_inodes+0x95/0xd0
 [] background_writeout+0x89/0xb0
 [] pdflush+0x0/0x1d0
 [] pdflush+0xfe/0x1d0
 [] background_writeout+0x0/0xb0
 [] kthread+0x42/0x70
 [] kthread+0x0/0x70
 [] kernel_thread_helper+0x7/0x14
 ===
Code: 24 85 d2 74 10 8b 01 a8 01 75 0a 8b 44 24 24 c7 00 01 00 00 00 31 
f6 39 fd 89 f9 0f 95 c2 85 db 0f 94 c0 08 c2 74 2e 03 5c 24 08 <8b> 79 
04 3b 1c 24 89 da 0f 96 c0 2b 54 24 08 3b 54 24 20 0f 93

EIP: [] walk_page_buffers+0x4e/0x90 SS:ESP 0068:cbaabdf8

This is an AMD SMP system.

$ uname -a
Linux home 2.6.22 #2 SMP PREEMPT Fri Jul 13 17:56:35 GST 2007 i686 
unknown unknown GNU/Linux


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel 2.6.22 + ALSA + Intel HDA = hda_codec: Unknown model

[Dan Aloni]

On Sat, Jul 14, 2007 at 06:18:40AM -0400, Justin Piszcz wrote:
> Hi all,
> 
> I use an A-BIT AW9D-MAX motherboard and while the audio works fine using 
> the Intel HDA driver; however, I see this in dmesg:
> 
> [   29.188561] Advanced Linux Sound Architecture Driver Version 1.0.14 
> (Thu May 31 09:03:25 2007 UTC).
> [   29.188728] ACPI: PCI Interrupt :00:1b.0[A] -> GSI 16 (level, low) 
> -> IRQ 17
> [   29.188822] PCI: Setting latency timer of device :00:1b.0 to 64
> [   29.240729] hda_codec: Unknown model for ALC882, trying auto-probe from 
> BIOS...
>   ^
> [   29.280743] ALSA device list:
> [   29.280781]   #0: HDA Intel at 0xfdff8000 irq 17
> 
> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High 
> Definition Audio Controller (rev 01)
> 
> Two lspci (-vx) listings attached.
> 
> Can we get the PCI ID added to the kernel source so it does not say 
> unknown model?

Actually, it is reported as unknown in a deeper probing level than
PCI. I once made a patch that among other thing identified that 
A-BIT board exactly. 

http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000441.html

It is possible to take this patch, drop the other bits and just
leave out the nice print that just tells it's A-BIT AW9D-MAX.

Though AFAIK, ALSA maintainers have plans to move most of the 
probing code to userspace somehow so I'm not sure if it is 
quite relevant.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: e100 PCI bridge problem

[Krzysztof Halasa]

William Montgomery <[EMAIL PROTECTED]> writes:

> In an earlier post to the list I described a hard lockup condition
> that occurs on linux kernels 2.4.22, 2.6.13, and 2.6.17 when using
> a 4 port 10/100 fast ethernet card.  The lockup is easily repeatable
> and occurs on 2 out of 3 computers.
>
> Further testing has revealed that the lockup can be prevented on all
> computers by making sure the card is installed on the primary PCI bus.
> If the card is installed in a slot on the secondary PCI bus (behind a
> PCI to PCI bridge) the lockup occurs.

Does the machine #3 have a PCI slot connected to a "secondary" bus?
Have you tried with any other machine with a secondary bus?

> Are there any PCI tuning registers that I can tweak to get around
> this problem?  Any changes I could make to the e100 driver to fix this?

Could be a hardware/BIOS problem on machines #1 and #2. Could be
a Linux bug as well, though similar configurations are known to work
fine. I don't think it has anything to do with IRQs.

Perhaps it doesn't like a bridge (on the card) behind a bridge
(on the motherboard). I would test with another multiport card
such as old DLink DFE-570TX (using a DEC 21150 bridge and four
21143 Ethernet chips).

I'd probably use some PCI analyzer or, at least, I'd check
the bus state with a multimeter.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] CFS scheduler, -v19

[Markus]

> I'll try a git snapshot next, but is there a way I can get more 
output?
Did it. The mouse is smooth, just when one app is being quit (dont know 
why...) the mouse will be jerking for a few seconds...

So, is there any way to get a more verbose output regarding the cfs?

   Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> >> Bodo Eggert wrote:

> >>> I toyed with setting up a diskless system in initramfs. In the process, I
> >>> came across some things:
> >>>
> >>> 1)  There is no way to have the kernel not mount a filesystem,
> >>> unless you use /init or rdinit=.
> >> And?  Just use rdinit=/sbin/init and no patch is needed.
> > 
> > rdinit is supposed to do a different job from /sbin/init, therefore it
> > will not do the security callbacks the original code would do.
> > 
> > And besides that, it feels like turning the wrong knob for that task.
> 
> No, it is exactly the right knob for the task.

Setting the name of the rdinit process to the name of the init process
in order to select the root device should not be the right knob.

> The fact that the security callbacks don't get invoked when using an
> initramfs *AT ALL* is the real problem.

It's one more problem.
-- 
Interchangeable parts aren't. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/8] Text Edit Lock

[Mathieu Desnoyers]

* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 13, 2007 at 09:21:33PM -0400, Mathieu Desnoyers wrote:
> > Hi Andrew,
> > 
> > After refactoring of architecture independant code (mutex to protect text
> > edition) vs architecture dependant code (marking/unmarking pages RW) and
> > thorough testing, here is the new version of the text edit lock.
> 
> Do you have a tarball of your quilt series for markers and all the patches
> leading to them?  Trying to hand apply half a dozend patch series is not
> too nice :)
> 

Sure,

Here is the tarball:

http://ltt.polymtl.ca/markers/markers-patches-for-2.6.22-rc6-mm1-07-14-2007.tar.gz

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 4/8] Immediate Value - Add kconfig menus

[Mathieu Desnoyers]

* Alexey Dobriyan ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 13, 2007 at 09:24:43PM -0400, Mathieu Desnoyers wrote:
> > Immediate values provide a way to use dynamic code patching to update 
> > variables
> > sitting within the instruction stream. It saves caches lines normally used 
> > by
> > static read mostly variables.
> 
> >  kernel/Kconfig.immediate |   11 +++
> 
> NAK, if this immediate stuff is so super-cool¹ it should be default on.
> 
> ¹ it isn't
> 

Hi Alexey,

On embedded systems, the tradeoff is not the same. The immediate values
trade a little bit of system memory (to keep the pointers to the
variable and instruction as well as the size of the variable, only used
when the variable is updated) in order to remove cache line hot paths.

Also, embedded systems with physically read-only memory clearly does not
want to enable this.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] NET_CLS_RSVP6 should depend on IPV6

[Patrick McHardy]

Gabriel C wrote:
> cls_rsvp6 only works with IPV6 enabled kernels and IMO it should depends
> on IPV6.


I can't see any functional dependency on IPv6, what exactly are you
refering to? People might want to use it on a bridge for example
without having IPv6 running locally.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

new 2.6.22-git5 warnings

[Randy Dunlap]

net/sunrpc/auth_gss/auth_gss.c:1002: warning: implicit declaration of function 
'lock_kernel'
net/sunrpc/auth_gss/auth_gss.c:1004: warning: implicit declaration of function 
'unlock_kernel'


allmodconfig or allyesconfig on x86_64.

---
~Randy
/me goes hiking.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.22 released

[Martin Orr]

On 11/07/07 23:16, Andi Kleen wrote:
> I just checked with today's gcc 4.2 (070711) freshly compiled and from a 
> quick inspection 
> the code looks correct again. So perhaps it has been already fixed? 

It has indeed been fixed.  I tracked the bug down to gcc svn revision 126418
 (20070706) and the fix to revision 126487 (20070709).

Best wishes,

-- 
Martin Orr





signature.asc
Description: OpenPGP digital signature

[BUG] AS io-scheduler.

[Ian Kumlien]

Hi, 

I had emerge --sync failing several times... 

So i checked dmesg and found some info, attached further down.
This is a old VIA C3 machine with one disk, it's been running most
kernels in the 2.6.x series with no problems until now.

PS. Don't forget to CC me
DS.

BUG: unable to handle kernel paging request at virtual address ea86ac54
 printing eip:
c022dfec
*pde = 
Oops:  [#1]
Modules linked in: eeprom i2c_viapro vt8231 i2c_isa skge
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010082   (2.6.22.1 #26)
EIP is at as_can_break_anticipation+0xc/0x190
eax: dfcdaba0   ebx: dfcdaba0   ecx: 0035ff95   edx: cb296844
esi: cb296844   edi: dfcdaba0   ebp:    esp: ceff6a70
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process rsync (pid: 1667, ti=ceff6000 task=d59cf5b0 task.ti=ceff6000)
Stack: cb296844 0001 cb296844 dfcdaba0  c022efc8 cb296844
 
   dfcffb9c c0227a76 dfcffb9c  c016e96e cb296844 
dfcffb9c 
    c022af64  dfcffb9c 0008  08ff6b30
c04d1ec0 
Call Trace:
 [] as_add_request+0xa8/0xc0
 [] elv_insert+0xa6/0x150
 [] bio_phys_segments+0xe/0x20
 [] __make_request+0x384/0x490
 [] ide_do_request+0x6ee/0x890
 [] generic_make_request+0x18b/0x1c0
 [] submit_bio+0xa6/0xb0
 [] mempool_alloc+0x28/0xa0
 [] __find_get_block+0xf6/0x130
 [] bio_alloc_bioset+0x8c/0xf0
 [] submit_bh+0xb7/0xe0
 [] ll_rw_block+0x78/0x90
 [] search_by_key+0xdd/0xd20
 [] ll_rw_block+0x81/0x90
 [] irq_exit+0x40/0x60
 [] do_IRQ+0x94/0xb0
 [] common_interrupt+0x23/0x30
 [] reiserfs_read_locked_inode+0x6a/0x490
 [] reiserfs_find_actor+0x0/0x20
 [] reiserfs_iget+0x4b/0x80
 [] reiserfs_init_locked_inode+0x0/0x10
 [] reiserfs_lookup+0xa4/0xf0
 [] do_lookup+0xa3/0x140
 [] __link_path_walk+0x615/0xa20
 [] __mark_inode_dirty+0x28/0x150
 [] mntput_no_expire+0x11/0x50
 [] link_path_walk+0x42/0xb0
 [] do_path_lookup+0x130/0x150
 [] __user_walk_fd+0x30/0x50
 [] vfs_lstat_fd+0x16/0x40
 [] sys_lstat64+0xf/0x30
 [] syscall_call+0x7/0xb
 ===
Code: c0 8b 44 cb 0c 8b 40 08 29 d0 f7 d0 c1 e8 1f 83 f0 01 eb 02 31 c0
5b c3 8d b4 26 00 00 00 00 55 57 56 53 83 ec 04 89 c3 89 14 24 <8b> 90
b4 00 00 00 85 d2 75 04 0f 0b eb fe 83 3c 24 00 74 0c 8b 
EIP: [] as_can_break_anticipation+0xc/0x190 SS:ESP
0068:ceff6a70
WARNING: at block/as-iosched.c:862 as_remove_queued_request()
 [] as_remove_queued_request+0x40/0xc0
 [] as_move_to_dispatch+0xa4/0x110
 [] __delay+0x6/0x10
 [] as_dispatch_request+0x2d3/0x310
 [] ide_dma_start+0x22/0x30
 [] ide_do_rw_disk+0x310/0x3f0
 [] elv_next_request+0x105/0x120
 [] ide_do_request+0x246/0x890
 [] schedule+0x45d/0x4c0
 [] as_work_handler+0x0/0x20
 [] blk_start_queueing+0x11/0x20
 [] as_work_handler+0xf/0x20
 [] run_workqueue+0x6b/0xe0
 [] worker_thread+0x0/0xc0
 [] worker_thread+0xb2/0xc0
 [] autoremove_wake_function+0x0/0x40
 [] kthread+0x38/0x60
 [] kthread+0x0/0x60
 [] kernel_thread_helper+0x7/0x10
 ===
WARNING: at block/as-iosched.c:966 as_move_to_dispatch()
 [] as_move_to_dispatch+0xd3/0x110
 [] as_dispatch_request+0x2d3/0x310
 [] ide_dma_start+0x22/0x30
 [] ide_do_rw_disk+0x310/0x3f0
 [] elv_next_request+0x105/0x120
 [] ide_do_request+0x246/0x890
 [] schedule+0x45d/0x4c0
 [] as_work_handler+0x0/0x20
 [] blk_start_queueing+0x11/0x20
 [] as_work_handler+0xf/0x20
 [] run_workqueue+0x6b/0xe0
 [] worker_thread+0x0/0xc0
 [] worker_thread+0xb2/0xc0
 [] autoremove_wake_function+0x0/0x40
 [] kthread+0x38/0x60
 [] kthread+0x0/0x60
 [] kernel_thread_helper+0x7/0x10
 ===

-- 
Ian Kumlien  -- http://pomac.netswarm.net


signature.asc
Description: This is a digitally signed message part

[PATCH -rt 0/5] making SLUB -rt friendly

[Peter Zijlstra]

Hi,

This is an attempt at converting SLUB to -rt. It seems to work reasonably
well. But I haven't really pushed it _very_ _very_ hard yet.

Enjoy


--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -rt 3/5] asm/local.h cmpxchg

[Peter Zijlstra]

From: Christoph Lameter <[EMAIL PROTECTED]>

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 include/asm-generic/local.h |   25 +++--
 include/asm-i386/local.h|   13 +
 include/asm-x86_64/local.h  |   16 
 3 files changed, 52 insertions(+), 2 deletions(-)

Index: linux-2.6.22-rc6-mm1/include/asm-generic/local.h
===
--- linux-2.6.22-rc6-mm1.orig/include/asm-generic/local.h   2007-07-12 
19:44:18.0 -0700
+++ linux-2.6.22-rc6-mm1/include/asm-generic/local.h2007-07-12 
19:44:57.0 -0700
@@ -46,13 +46,34 @@ typedef struct
 #define local_add_unless(l, a, u) atomic_long_add_unless((&(l)->a), (a), (u))
 #define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
 
-/* Non-atomic variants, ie. preemption disabled and won't be touched
- * in interrupt, etc.  Some archs can optimize this case well. */
+/*
+ * Establish a state necessary for __local_xx functions to work.
+ */
+#define __local_begin(flags)   local_irq_disable(flags)
+
+static inline void __local_end(unsigned long flags)
+{
+   local_irq_restore(flags);
+}
+
+/*
+ * Non-atomic variants, ie. within local_begin() / local_end() or
+ * preempt_disable / enable() and won't be touched in interrupt, etc.
+ * Some archs can optimize this case well.
+ */
 #define __local_inc(l) local_set((l), local_read(l) + 1)
 #define __local_dec(l) local_set((l), local_read(l) - 1)
 #define __local_add(i,l)   local_set((l), local_read(l) + (i))
 #define __local_sub(i,l)   local_set((l), local_read(l) - (i))
 
+#define __local_cmpxchg((v), (o), (n)) (*(v) = (n), (o))
+#define __local_xchg((v), (n)) 
\
+({ \
+   __typeof(v) x = *(v);   \
+   *(v) = (n); \
+   x;  \
+)}
+
 /* Use these for per-cpu local_t variables: on some archs they are
  * much more efficient than these naive implementations.  Note they take
  * a variable (eg. mystruct.foo), not an address.
Index: linux-2.6.22-rc6-mm1/include/asm-x86_64/local.h
===
--- linux-2.6.22-rc6-mm1.orig/include/asm-x86_64/local.h2007-07-12 
19:44:18.0 -0700
+++ linux-2.6.22-rc6-mm1/include/asm-x86_64/local.h 2007-07-12 
19:44:57.0 -0700
@@ -9,6 +9,7 @@ typedef struct
atomic_long_t a;
 } local_t;
 
+
 #define LOCAL_INIT(i)  { ATOMIC_LONG_INIT(i) }
 
 #define local_read(l)  atomic_long_read(&(l)->a)
@@ -181,11 +182,26 @@ static __inline__ long local_sub_return(
 
 /* On x86-64 these are better than the atomic variants on SMP kernels
because they dont use a lock prefix. */
+
+#define __local_begin(__flags) \
+{  \
+   (__flags) = 0;  \
+   preempt_disable();  \
+}
+
+static inline void __local_end(unsigned long flags) {
+   preempt_enable();
+}
+
 #define __local_inc(l) local_inc(l)
 #define __local_dec(l) local_dec(l)
 #define __local_add(i,l)   local_add((i),(l))
 #define __local_sub(i,l)   local_sub((i),(l))
 
+#define __local_cmpxchgcmpxchg_local
+#define __local_xchg   xchg
+
+
 /* Use these for per-cpu local_t variables: on some archs they are
  * much more efficient than these naive implementations.  Note they take
  * a variable, not an address.
Index: linux-2.6.22-rc6-mm1/include/asm-i386/local.h
===
--- linux-2.6.22-rc6-mm1.orig/include/asm-i386/local.h  2007-07-12 
19:53:00.0 -0700
+++ linux-2.6.22-rc6-mm1/include/asm-i386/local.h   2007-07-12 
19:55:22.0 -0700
@@ -194,12 +194,25 @@ static __inline__ long local_sub_return(
 })
 #define local_inc_not_zero(l) local_add_unless((l), 1, 0)
 
+#define __local_begin(__flags) \
+{  \
+   (__flags) = 0;  \
+   preempt_disable();  \
+}
+
+static inline void __local_end(unsigned long flags) {
+   preempt_enable();
+}
+
 /* On x86, these are no better than the atomic variants. */
 #define __local_inc(l) local_inc(l)
 #define __local_dec(l) local_dec(l)
 #define __local_add(i,l)   local_add((i),(l))
 #define __local_sub(i,l)   local_sub((i),(l))
 
+#define __local_cmpxchgcmpxchg_local
+#define __local_xchg   xchg
+
 /* Use these for per-cpu local_t variables: on some archs they are
  * much more efficient than these naive implementations.  Note they take
  * a variable, not an address.

--

-
To unsubs

[PATCH -rt 4/5] use migrate_disable for __local_begin

[Peter Zijlstra]

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 include/asm-i386/local.h   |7 ---
 include/asm-x86_64/local.h |7 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

Index: linux-2.6/include/asm-i386/local.h
===
--- linux-2.6.orig/include/asm-i386/local.h
+++ linux-2.6/include/asm-i386/local.h
@@ -197,11 +197,12 @@ static __inline__ long local_sub_return(
 #define __local_begin(__flags) \
 {  \
(__flags) = 0;  \
-   preempt_disable();  \
+   migrate_disable();  \
 }
 
-static inline void __local_end(unsigned long flags) {
-   preempt_enable();
+static inline void __local_end(unsigned long flags)
+{
+   migrate_enable();
 }
 
 /* On x86, these are no better than the atomic variants. */
Index: linux-2.6/include/asm-x86_64/local.h
===
--- linux-2.6.orig/include/asm-x86_64/local.h
+++ linux-2.6/include/asm-x86_64/local.h
@@ -186,11 +186,12 @@ static __inline__ long local_sub_return(
 #define __local_begin(__flags) \
 {  \
(__flags) = 0;  \
-   preempt_disable();  \
+   migrate_disable();  \
 }
 
-static inline void __local_end(unsigned long flags) {
-   preempt_enable();
+static inline void __local_end(unsigned long flags)
+{
+   migrate_enable();
 }
 
 #define __local_inc(l) local_inc(l)

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -rt 1/5] workqueue: queue_work_cpu

[Peter Zijlstra]

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 include/linux/workqueue.h |1 +
 kernel/workqueue.c|   13 +
 2 files changed, 14 insertions(+)

Index: linux-2.6/include/linux/workqueue.h
===
--- linux-2.6.orig/include/linux/workqueue.h
+++ linux-2.6/include/linux/workqueue.h
@@ -131,6 +131,7 @@ extern void set_workqueue_prio(struct wo
 extern void destroy_workqueue(struct workqueue_struct *wq);
 
 extern int FASTCALL(queue_work(struct workqueue_struct *wq, struct work_struct 
*work));
+extern int FASTCALL(queue_work_cpu(struct workqueue_struct *wq, struct 
work_struct *work, int cpu));
 extern int FASTCALL(queue_delayed_work(struct workqueue_struct *wq,
struct delayed_work *work, unsigned long delay));
 extern int queue_delayed_work_on(int cpu, struct workqueue_struct *wq,
Index: linux-2.6/kernel/workqueue.c
===
--- linux-2.6.orig/kernel/workqueue.c
+++ linux-2.6/kernel/workqueue.c
@@ -176,6 +176,19 @@ int fastcall queue_work(struct workqueue
 }
 EXPORT_SYMBOL_GPL(queue_work);
 
+int fastcall queue_work_cpu(struct workqueue_struct *wq, struct work_struct 
*work, int cpu)
+{
+   int ret = 0;
+
+   if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {
+   BUG_ON(!list_empty(&work->entry));
+   __queue_work(wq_per_cpu(wq, cpu), work);
+   ret = 1;
+   }
+   return ret;
+}
+EXPORT_SYMBOL_GPL(queue_work_cpu);
+
 void delayed_work_timer_fn(unsigned long __data)
 {
struct delayed_work *dwork = (struct delayed_work *)__data;

--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -rt 2/5] Thread Migration Preemption - v2

[Peter Zijlstra]

From: Mathieu Desnoyers <[EMAIL PROTECTED]>

This patch adds the ability to protect critical sections from migration to
another CPU without disabling preemption.

This will be useful to minimize the amount of preemption disabling for the -rt
patch. It will help leveraging improvements brought by the local_t types in
asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
variables protected by migrate_disable must be either atomic or protected from
concurrent updates done by other threads.

Typical use:

migrate_disable();
local_inc(&__get_cpu_var(&my_local_t_var));
migrate_enable();

Which will increment the variable atomically wrt the local CPU.

Changes:

Do a check_migrate() upon migrate_enable() to answer to the migration
thread waiting for us to exit the migration disabled critical section. Use a
NEED_MIGRATE thread flag for this.

Note: (or we could say FIXME)
Is we ever want to check migration pending in assembly code, we will have to
make sure we test the right thread flag bits on each architectures. Care should
also be taken to check that the thread flags used won't trigger false positives
in non selective asm thread flag checks.

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 include/asm-alpha/thread_info.h |3 +
 include/asm-arm/thread_info.h   |5 +
 include/asm-arm26/thread_info.h |5 +
 include/asm-avr32/thread_info.h |4 +
 include/asm-blackfin/thread_info.h  |4 +
 include/asm-cris/thread_info.h  |4 +
 include/asm-frv/thread_info.h   |4 +
 include/asm-h8300/thread_info.h |4 +
 include/asm-i386/thread_info.h  |6 +-
 include/asm-ia64/thread_info.h  |4 +
 include/asm-m32r/thread_info.h  |4 +
 include/asm-m68k/thread_info.h  |2 
 include/asm-m68knommu/thread_info.h |3 +
 include/asm-mips/thread_info.h  |4 +
 include/asm-parisc/thread_info.h|4 +
 include/asm-powerpc/thread_info.h   |4 +
 include/asm-s390/thread_info.h  |4 +
 include/asm-sh/thread_info.h|4 +
 include/asm-sh64/thread_info.h  |4 +
 include/asm-sparc/thread_info.h |4 +
 include/asm-sparc64/thread_info.h   |5 +
 include/asm-um/thread_info.h|4 +
 include/asm-v850/thread_info.h  |4 +
 include/asm-x86_64/thread_info.h|4 +
 include/asm-xtensa/thread_info.h|4 +
 include/linux/preempt.h |   44 +
 kernel/sched.c  |   91 +---
 lib/smp_processor_id.c  |6 +-
 28 files changed, 230 insertions(+), 12 deletions(-)

Index: linux-2.6/include/asm-i386/thread_info.h
===
--- linux-2.6.orig/include/asm-i386/thread_info.h
+++ linux-2.6/include/asm-i386/thread_info.h
@@ -31,8 +31,7 @@ struct thread_info {
unsigned long   status; /* thread-synchronous flags */
__u32   cpu;/* current CPU */
int preempt_count;  /* 0 => preemptable, <0 => BUG 
*/
-
-
+   int migrate_count;/* 0: can migrate, <0: BUG */
mm_segment_taddr_limit; /* thread address space:
   0-0xBFFF for user-thead
   0-0x for 
kernel-thread
@@ -74,6 +73,7 @@ struct thread_info {
.flags  = 0,\
.cpu= 0,\
.preempt_count  = 1,\
+   .migrate_count = 0, \
.addr_limit = KERNEL_DS,\
.restart_block = {  \
.fn = do_no_restart_syscall,\
@@ -134,6 +134,7 @@ static inline struct thread_info *curren
 #define TIF_SECCOMP8   /* secure computing */
 #define TIF_RESTORE_SIGMASK9   /* restore signal mask in do_signal() */
 #define TIF_NEED_RESCHED_DELAYED 10/* reschedule on return to userspace */
+#define TIF_NEED_MIGRATE   11  /* migration necessary */
 #define TIF_MEMDIE 16
 #define TIF_DEBUG  17  /* uses debug registers */
 #define TIF_IO_BITMAP  18  /* uses I/O bitmap */
@@ -151,6 +152,7 @@ static inline struct thread_info *curren
 #define _TIF_SYSCALL_AUDIT (1preempt_count)
+
+#define inc_migrate_count() add_migrate_count(1)
+#define dec_migrate_count() sub_migrate_count(1)
+
+#define migrate_count() (current_thread_info()->migrate_count)
 
 #ifdef CONFIG_PREEMPT
 
@@ -80,6 +89,36 @@ do { \
preempt_check_resched(); \
 } while (0)
 
+#define migrate_disable() \
+do { \
+   inc_migrate_count(); \
+   barrier(); \
+} while (0)
+
+#define migrate_enable_no_check() \
+do { \
+   barrier(); \
+   

[PATCH -rt 5/5] slub: -rt port

[Peter Zijlstra]

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 init/Kconfig |1 
 mm/slub.c|  260 ---
 2 files changed, 214 insertions(+), 47 deletions(-)

Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Lock order:
@@ -99,6 +100,8 @@
  * the fast path and disables lockless freelists.
  */
 
+#ifndef CONFIG_PREEMPT_RT
+
 #define FROZEN (1 << PG_active)
 
 #ifdef CONFIG_SLUB_DEBUG
@@ -137,6 +140,46 @@ static inline void ClearSlabDebug(struct
page->flags &= ~SLABDEBUG;
 }
 
+#else /* CONFIG_PREEMPT_RT */
+/*
+ * when the allocator is preemptible these operations might be concurrent with
+ * lock_page(), and hence need atomic ops.
+ */
+
+#define PG_frozen  PG_active
+#define PG_debug   PG_error
+
+static inline int SlabFrozen(struct page *page)
+{
+   return test_bit(PG_frozen, &page->flags);
+}
+
+static inline void SetSlabFrozen(struct page *page)
+{
+   set_bit(PG_frozen, &page->flags);
+}
+
+static inline void ClearSlabFrozen(struct page *page)
+{
+   clear_bit(PG_frozen, &page->flags);
+}
+
+static inline int SlabDebug(struct page *page)
+{
+   return test_bit(PG_debug, &page->flags);
+}
+
+static inline void SetSlabDebug(struct page *page)
+{
+   set_bit(PG_debug, &page->flags);
+}
+
+static inline void ClearSlabDebug(struct page *page)
+{
+   clear_bit(PG_debug, &page->flags);
+}
+#endif
+
 /*
  * Issues still to be resolved:
  *
@@ -1021,7 +1064,7 @@ static struct page *new_slab(struct kmem
BUG_ON(flags & ~(GFP_DMA | GFP_LEVEL_MASK));
 
if (flags & __GFP_WAIT)
-   local_irq_enable();
+   local_irq_enable_nort();
 
page = allocate_slab(s, flags & GFP_LEVEL_MASK, node);
if (!page)
@@ -1057,7 +1100,7 @@ static struct page *new_slab(struct kmem
page->inuse = 0;
 out:
if (flags & __GFP_WAIT)
-   local_irq_disable();
+   local_irq_disable_nort();
return page;
 }
 
@@ -1117,6 +1160,7 @@ static void discard_slab(struct kmem_cac
 /*
  * Per slab locking using the pagelock
  */
+#ifndef CONFIG_PREEMPT_RT
 static __always_inline void slab_lock(struct page *page)
 {
bit_spin_lock(PG_locked, &page->flags);
@@ -1134,6 +1178,22 @@ static __always_inline int slab_trylock(
rc = bit_spin_trylock(PG_locked, &page->flags);
return rc;
 }
+#else
+static __always_inline void slab_lock(struct page *page)
+{
+   lock_page(page);
+}
+
+static __always_inline void slab_unlock(struct page *page)
+{
+   unlock_page(page);
+}
+
+static __always_inline int slab_trylock(struct page *page)
+{
+   return !TestSetPageLocked(page);
+}
+#endif
 
 /*
  * Management of partially allocated slabs
@@ -1154,8 +1214,7 @@ static void add_partial(struct kmem_cach
spin_unlock(&n->list_lock);
 }
 
-static void remove_partial(struct kmem_cache *s,
-   struct page *page)
+static void remove_partial(struct kmem_cache *s, struct page *page)
 {
struct kmem_cache_node *n = get_node(s, page_to_nid(page));
 
@@ -1282,6 +1341,7 @@ static void unfreeze_slab(struct kmem_ca
 {
struct kmem_cache_node *n = get_node(s, page_to_nid(page));
 
+   BUG_ON(!SlabFrozen(page));
ClearSlabFrozen(page);
if (page->inuse) {
 
@@ -1310,29 +1370,52 @@ static void unfreeze_slab(struct kmem_ca
}
 }
 
+static void **get_lockless_object(struct page *page)
+{
+   void **object;
+
+again:
+   object = page->lockless_freelist;
+   if (object && __local_cmpxchg(&page->lockless_freelist,
+   object, object[page->offset]) != object)
+   goto again;
+
+   return object;
+}
+
 /*
  * Remove the cpu slab
  */
 static void deactivate_slab(struct kmem_cache *s, struct page *page, int cpu)
 {
/*
+* take away the slab page before merging the lockless free list into
+* the regular free list to ensure that no new entries are put on the
+* lockless list between the merge and removal.
+*/
+   BUG_ON(page != s->cpu_slab[cpu]);
+   s->cpu_slab[cpu] = NULL;
+   barrier();
+
+   /*
 * Merge cpu freelist into freelist. Typically we get here
 * because both freelists are empty. So this is unlikely
 * to occur.
 */
-   while (unlikely(page->lockless_freelist)) {
+   for (;;) {
void **object;
 
/* Retrieve object from cpu_freelist */
-   object = page->lockless_freelist;
-   page->lockless_freelist = page->lockless_freelist[page->offset];
+   object = get_lockless_object(page);
+   if (likely(!object))
+   break;
 
 

Re: [patch 3/8] Text Edit Lock - i386

[Christoph Hellwig]

On Fri, Jul 13, 2007 at 09:21:36PM -0400, Mathieu Desnoyers wrote:
> +#ifdef CONFIG_DEBUG_RODATA
> +static int rodata_marked;
> +#endif

Maybe I'm missing something, but the rodata section should always stay
r/o, only text needs locking/unlocking, no?

Given that all code in this patch only operates on .text this seems fine,
but the variables/config options are grossly misnamed then.  And actually
making rodata r/o doesn't seem like a pure debugging thing to me either.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/8] Immediate Value - Architecture Independent Code

[Christoph Hellwig]

On Fri, Jul 13, 2007 at 09:24:41PM -0400, Mathieu Desnoyers wrote:
> +#ifdef __KERNEL__

no need for this.  unless you add the header to header-y in the Kbuild
file it's not exported to userspace at all.

> +#ifdef CONFIG_IMMEDIATE
> +#include 
> +#else
> +#include 
> +#endif

Nack on this one. linux/*.h should never include asm-generic headers.

Either put the !CONFIG_IMMEDIATE code directly into this file or let
every arch have a one-liner immediate.h that includes the asm-generic
one.  The first method is probably a lot nicer.

> +/*
> + * modules_mutex nests inside immediate_mutex. immediate_mutex protects 
> builtin
> + * immediates and module immediates.
> + */
> +DEFINE_MUTEX(immediate_mutex);

Why is this non-static?

> +
> +/*
> + * Sets a range of immediates to a enabled state : set the enable bit.
> + */
> +static void _immediate_update_range(
> + const struct __immediate *begin, const struct __immediate *end)

static void _immediate_update_range(const struct __immediate *begin,
const struct __immediate *end)

same for a few more functions here.

> +#ifdef CONFIG_MODULES

...

> +#endif
> +
> +#ifdef CONFIG_MODULES

please put all this code into a single ifdef block.


note that the exported functions probably want some kerneldoc documentation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 5/8] Immediate Values - kprobe header fix

[Christoph Hellwig]

On Fri, Jul 13, 2007 at 09:24:44PM -0400, Mathieu Desnoyers wrote:
> Since the immediate values depend on the same int3 handler as kprobes 
> implements
> for i386, we have to get architecture specific defines available for the 
> kprobes
> trap handler (especially restore_interrupts()) wven when CONFIG_KPROBES is not
> selected.
> 
> That kind of ifdef around a whole header does not make sense in the first 
> place
> anyway.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> ---
>  include/linux/kprobes.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6-lttng/include/linux/kprobes.h
> ===
> --- linux-2.6-lttng.orig/include/linux/kprobes.h  2007-07-13 
> 18:47:57.0 -0400
> +++ linux-2.6-lttng/include/linux/kprobes.h   2007-07-13 18:48:45.0 
> -0400
> @@ -36,9 +36,9 @@
>  #include 
>  #include 
>  
> -#ifdef CONFIG_KPROBES
>  #include 

but this one isn't available on architectures that don't have kprobes,
so you can't include linux/kprobes.h in generic code without ifdef
protection anymore.

I'd say move the code to asm/kdebug.h if it's need by more than just
kprobes.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/3] Generic Trace Setup and Control (GTSC) code

[Christoph Hellwig]

On Fri, Jun 29, 2007 at 10:24:32PM -0500, Tom Zanussi wrote:
> The Generic Tracing and Control Interface (GTSC) code.

The code looks fine to me from a first look, but the the name is just dumb.
Given that all your internal identifiers are trace_* or TRACE_ go all
the way and make it CONFIG_TRACE and lib/trace.c aswell.

Long term we probably want more complex tracing based on lttng, but I'm
a big fan of starting out simple and doing incremental changes.

So my 1c for merging this in 2.6.23 with the exports ripped out until
we actually grow modular users (which will probably come with the blktrace
markers conversion later on)

> +static inline struct trace_info *trace_setup(const char *root,
> +  const char *name,
> +  u32 buf_size,
> +  u32 buf_nr,
> +  u32 flags)

static inline struct trace_info *trace_setup(const char *root,
const char *name, u32 buf_size, u32 buf_nr, u32 flags)

> + * Based on blktrace code, Copyright (C) 2006 Jens Axboe <[EMAIL PROTECTED]>
> + * Moved to utt.c by Tom Zanussi <[EMAIL PROTECTED]>, 2006

It's gstc.c now and should be trace.c, nevermind that filename doesn't
really belong here anyway :)

> +unsigned long long trace_timestamp(void)
> +{
> + return sched_clock();
> +}
> +EXPORT_SYMBOL_GPL(trace_timestamp);

Using sched_clock is quite dangerous.  And just adding a wrapper to get
it exported is not nice either :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 2/5] Thread Migration Preemption - v2

[Mathieu Desnoyers]

Oh, testers for this patch will be welcome.. it runs fine on my system,
but I have not tested the CPU hotplug corner cases.

Mathieu

* Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> From: Mathieu Desnoyers <[EMAIL PROTECTED]>
> 
> This patch adds the ability to protect critical sections from migration to
> another CPU without disabling preemption.
> 
> This will be useful to minimize the amount of preemption disabling for the -rt
> patch. It will help leveraging improvements brought by the local_t types in
> asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
> variables protected by migrate_disable must be either atomic or protected from
> concurrent updates done by other threads.
> 
> Typical use:
> 
> migrate_disable();
> local_inc(&__get_cpu_var(&my_local_t_var));
> migrate_enable();
> 
> Which will increment the variable atomically wrt the local CPU.
> 
> Changes:
> 
> Do a check_migrate() upon migrate_enable() to answer to the migration
> thread waiting for us to exit the migration disabled critical section. Use a
> NEED_MIGRATE thread flag for this.
> 
> Note: (or we could say FIXME)
> Is we ever want to check migration pending in assembly code, we will have to
> make sure we test the right thread flag bits on each architectures. Care 
> should
> also be taken to check that the thread flags used won't trigger false 
> positives
> in non selective asm thread flag checks.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
>  include/asm-alpha/thread_info.h |3 +
>  include/asm-arm/thread_info.h   |5 +
>  include/asm-arm26/thread_info.h |5 +
>  include/asm-avr32/thread_info.h |4 +
>  include/asm-blackfin/thread_info.h  |4 +
>  include/asm-cris/thread_info.h  |4 +
>  include/asm-frv/thread_info.h   |4 +
>  include/asm-h8300/thread_info.h |4 +
>  include/asm-i386/thread_info.h  |6 +-
>  include/asm-ia64/thread_info.h  |4 +
>  include/asm-m32r/thread_info.h  |4 +
>  include/asm-m68k/thread_info.h  |2 
>  include/asm-m68knommu/thread_info.h |3 +
>  include/asm-mips/thread_info.h  |4 +
>  include/asm-parisc/thread_info.h|4 +
>  include/asm-powerpc/thread_info.h   |4 +
>  include/asm-s390/thread_info.h  |4 +
>  include/asm-sh/thread_info.h|4 +
>  include/asm-sh64/thread_info.h  |4 +
>  include/asm-sparc/thread_info.h |4 +
>  include/asm-sparc64/thread_info.h   |5 +
>  include/asm-um/thread_info.h|4 +
>  include/asm-v850/thread_info.h  |4 +
>  include/asm-x86_64/thread_info.h|4 +
>  include/asm-xtensa/thread_info.h|4 +
>  include/linux/preempt.h |   44 +
>  kernel/sched.c  |   91 
> +---
>  lib/smp_processor_id.c  |6 +-
>  28 files changed, 230 insertions(+), 12 deletions(-)
> 
> Index: linux-2.6/include/asm-i386/thread_info.h
> ===
> --- linux-2.6.orig/include/asm-i386/thread_info.h
> +++ linux-2.6/include/asm-i386/thread_info.h
> @@ -31,8 +31,7 @@ struct thread_info {
>   unsigned long   status; /* thread-synchronous flags */
>   __u32   cpu;/* current CPU */
>   int preempt_count;  /* 0 => preemptable, <0 => BUG 
> */
> -
> -
> + int migrate_count;/* 0: can migrate, <0: BUG */
>   mm_segment_taddr_limit; /* thread address space:
>  0-0xBFFF for user-thead
>  0-0x for 
> kernel-thread
> @@ -74,6 +73,7 @@ struct thread_info {
>   .flags  = 0,\
>   .cpu= 0,\
>   .preempt_count  = 1,\
> + .migrate_count = 0, \
>   .addr_limit = KERNEL_DS,\
>   .restart_block = {  \
>   .fn = do_no_restart_syscall,\
> @@ -134,6 +134,7 @@ static inline struct thread_info *curren
>  #define TIF_SECCOMP  8   /* secure computing */
>  #define TIF_RESTORE_SIGMASK  9   /* restore signal mask in do_signal() */
>  #define TIF_NEED_RESCHED_DELAYED 10  /* reschedule on return to userspace */
> +#define TIF_NEED_MIGRATE 11  /* migration necessary */
>  #define TIF_MEMDIE   16
>  #define TIF_DEBUG17  /* uses debug registers */
>  #define TIF_IO_BITMAP18  /* uses I/O bitmap */
> @@ -151,6 +152,7 @@ static inline struct thread_info *curren
>  #define _TIF_SYSCALL_AUDIT   (1<  #define _TIF_SECCOMP (1<  #define _TIF_RESTORE_SIGMASK (1< +#define _TIF_NEED_MIGRATE(1<  #define _TIF_DEBUG   (1<  #define _TIF_IO_BITMAP   (1

Ethernet not functioning on Nvidia MCP51 in 2.6.21

[Ed W]

Hi, I am renting a root server which uses an nvidia motherboard and 
currently has a functioning 2.6.16 kernel.  Unfortunately taking the 
same .config file (make oldconfig) in 2.6.21.6 is apparently not 
spotting the ethernet controller correctly (for various reasons I need a 
newer kernel, eventually with some other patches also)


As near as I can find it should be the forcedeth driver being used 
here.  Comparing dmesg on the working kernel and the non-working kernel 
shows no obvious differences.  The working kernel uses no special 
command line options.  Can someone please help me to debug this further?


Symptoms are that dmesg suggests that the driver is being asked to load, 
but ifconfig does not show any eth0 device?


Relevant chunks of dmesg on the non working kernel are below, full dmesg 
and lspci and kernel .config are in the links at the end.  Grateful for 
any help debugging this?  How do I find out why the driver is finding my 
hardware, but no eth0 device is being created?


Ed W


...
loop: loaded (max 8 devices)
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
sk98lin: driver has been replaced by the skge driver and is scheduled 
for removal

Marvell 88E1101: Registered new driver
Marvell 88E: Registered new driver
Marvell 88E1145: Registered new driver
Davicom DM9161E: Registered new driver
Davicom DM9131: Registered new driver
Cicada Cis8204: Registered new driver
Cicada Cis8201: Registered new driver
LXT970: Registered new driver
LXT971: Registered new driver
QS6612: Registered new driver
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
ACPI: PCI Interrupt Link [LNKL] enabled at IRQ 23
ACPI: PCI Interrupt :00:14.0[A] -> Link [LNKL] -> GSI 23 (level, 
high) -> IRQ 16

PCI: Setting latency timer of device :00:14.0 to 64
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01734:10c6 bound to :00:14.0
...

00:14.0 Ethernet controller: nVidia Corporation MCP51 Ethernet Controller (rev 
a3)
   Subsystem: Fujitsu Siemens Computer GmbH Unknown device 10c6
   Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 16
   Memory at f2202000 (32-bit, non-prefetchable) [size=4K]
   I/O ports at 8c38 [size=8]


   Capabilities: [44] Power Management version 2


http://www.wildgooses.com/downloads/config
http://www.wildgooses.com/downloads/dmesg.txt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new 2.6.22-git5 warnings

[Trond Myklebust]

On Sat, 2007-07-14 at 08:37 -0700, Randy Dunlap wrote:
> 
> net/sunrpc/auth_gss/auth_gss.c:1002: warning: implicit declaration of 
> function 'lock_kernel'
> net/sunrpc/auth_gss/auth_gss.c:1004: warning: implicit declaration of 
> function 'unlock_kernel'
> 
> 
> allmodconfig or allyesconfig on x86_64.

Yup. Sorry about that. Bruce has proposed a cleanup which should also
fix this problem. See attachment

Cheers
  Trond
--- Begin Message ---
From: J. Bruce Fields <[EMAIL PROTECTED]>

Since every invocation of xdr encode or decode functions takes the BKL now,
there's a lot of redundant lock_kernel/unlock_kernel pairs that we can pull out
into a common function.

Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
---
 include/linux/sunrpc/xdr.h |   16 
 net/sunrpc/auth.c  |   12 ++--
 net/sunrpc/auth_gss/auth_gss.c |   20 +---
 3 files changed, 23 insertions(+), 25 deletions(-)

> It's fine to keep it as a separate patch, but you're going to have to do
> something about the name: do_xdrproc() breaks with the standard sunrpc
> namespace conventions. How about naming it rpc_call_xdrproc().

Sounds fine.  Here's take two, with the new name and an additional
comment.

--b.

diff --git a/include/linux/sunrpc/xdr.h b/include/linux/sunrpc/xdr.h
index 9e340fa..c6b53d1 100644
--- a/include/linux/sunrpc/xdr.h
+++ b/include/linux/sunrpc/xdr.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Buffer adjustment
@@ -36,6 +37,21 @@ struct xdr_netobj {
 typedef int(*kxdrproc_t)(void *rqstp, __be32 *data, void *obj);
 
 /*
+ * We're still requiring the BKL in the xdr code until it's been
+ * more carefully audited, at which point this wrapper will become
+ * unnecessary.
+ */
+static inline int rpc_call_xdrproc(kxdrproc_t xdrproc, void *rqstp, __be32 
*data, void *obj)
+{
+   int ret;
+
+   lock_kernel();
+   ret = xdrproc(rqstp, data, obj);
+   unlock_kernel();
+   return ret;
+}
+
+/*
  * Basic structure for transmission/reception of a client XDR message.
  * Features a header (for a linear buffer containing RPC headers
  * and the data payload for short messages), and then an array of
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index e04da66..cd31cbd 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c
@@ -359,17 +359,13 @@ rpcauth_wrap_req(struct rpc_task *task, kxdrproc_t 
encode, void *rqstp,
__be32 *data, void *obj)
 {
struct rpc_cred *cred = task->tk_msg.rpc_cred;
-   int ret;
 
dprintk("RPC: %5u using %s cred %p to wrap rpc data\n",
task->tk_pid, cred->cr_ops->cr_name, cred);
if (cred->cr_ops->crwrap_req)
return cred->cr_ops->crwrap_req(task, encode, rqstp, data, obj);
/* By default, we encode the arguments normally. */
-   lock_kernel();
-   ret = encode(rqstp, data, obj);
-   unlock_kernel();
-   return ret;
+   return rpc_call_xdrproc(encode, rqstp, data, obj);
 }
 
 int
@@ -377,7 +373,6 @@ rpcauth_unwrap_resp(struct rpc_task *task, kxdrproc_t 
decode, void *rqstp,
__be32 *data, void *obj)
 {
struct rpc_cred *cred = task->tk_msg.rpc_cred;
-   int ret;
 
dprintk("RPC: %5u using %s cred %p to unwrap rpc data\n",
task->tk_pid, cred->cr_ops->cr_name, cred);
@@ -385,10 +380,7 @@ rpcauth_unwrap_resp(struct rpc_task *task, kxdrproc_t 
decode, void *rqstp,
return cred->cr_ops->crunwrap_resp(task, decode, rqstp,
   data, obj);
/* By default, we decode the arguments normally. */
-   lock_kernel();
-   ret = decode(rqstp, data, obj);
-   unlock_kernel();
-   return ret;
+   return rpc_call_xdrproc(decode, rqstp, data, obj);
 }
 
 int
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index a001973..73fd24c 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -917,9 +917,7 @@ gss_wrap_req_integ(struct rpc_cred *cred, struct gss_cl_ctx 
*ctx,
offset = (u8 *)p - (u8 *)snd_buf->head[0].iov_base;
*p++ = htonl(rqstp->rq_seqno);
 
-   lock_kernel();
-   status = encode(rqstp, p, obj);
-   unlock_kernel();
+   status = rpc_call_xdrproc(encode, rqstp, p, obj);
if (status)
return status;
 
@@ -1013,9 +1011,7 @@ gss_wrap_req_priv(struct rpc_cred *cred, struct 
gss_cl_ctx *ctx,
offset = (u8 *)p - (u8 *)snd_buf->head[0].iov_base;
*p++ = htonl(rqstp->rq_seqno);
 
-   lock_kernel();
-   status = encode(rqstp, p, obj);
-   unlock_kernel();
+   status = rpc_call_xdrproc(encode, rqstp, p, obj);
if (status)
return status;
 
@@ -1074,16 +1070,12 @@ gss_wrap_req(struct rpc_task *task,
/* The spec seems a little ambiguous here, but I think that not
 * wrapping context destruction 

i2c: pca954x I2C mux driver

[[EMAIL PROTECTED]]

Hello,

First of all excuse me for my bad english, this is my first time in LKML.

I'm not a programmer, but i'm a Gygabyte 7DPXDW+ owner (thanks ebay...), then i 
tried to compile a 2.6.20 patched kernel with an adapted version of the Kumar 
Gala's code as i found in:

http://lkml.org/lkml/2006/3/30/379
http://lkml.org/lkml/2006/3/30/385
http://lkml.org/lkml/2006/4/25/211

Well, the modified patch end related fixes applies well and compile, i get the 
pca954x module to work with:

modprobe pca954xx force_pca9540=0,0x70

the dmesg command says:

i2c-5: Virtual I2C bus (Physical bus i2c-0, multiplexer 0x70 port 0)
i2c-6: Virtual I2C bus (Physical bus i2c-0, multiplexer 0x70 port 1)
pca954x 0-0070: Registered 2 virtual buses for I2C mux pca9540

and the i2cdetect says:

  Installed I2C busses:
    i2c-6       smbus           Virtual I2C (i2c-0, mux 70:01)
    i2c-5       smbus           Virtual I2C (i2c-0, mux 70:00)
    i2c-0       smbus           SMBus AMD768 adapter at 50e0
    i2c-4       i2c             NVIDIA I2C Device
    i2c-3       i2c             NVIDIA I2C Device
    i2c-2       i2c             NVIDIA I2C Device
    i2c-1       smbus           saa7133[0]

This means that's all ok:), the module works!

Now the problem, the motherboard has two LM90 multiplexed by the PCA9540, but 
the sensors command only shows one chip directly attached to the amd768 bus:

lm90-i2c-0-4c
Adapter: SMBus AMD768 adapter at 50e0

M/B Temp:    +37°C  (low  =    +0°C, high =   +70°C)
CPU Temp:  +47.5°C  (low  =  +0.0°C, high = +70.0°C)
M/B Crit:    +85°C  (hyst =   +75°C)
CPU Crit:    +80°C  (hyst =   +70°C)

I tried to force the probe of the lm90 module with:

modprobe lm90 force_lm90=5,0x4c

or

modprobe lm90 force_lm90=6,0x4c

but the sensors command only seen the i2c-0 address.

The strange thing is that sensors-detect recognize both the LM90 on the virtual 
buses (plus one on the real bus):

sensors-detect
# sensors-detect revision 1.413 (2006/01/19 20:28:00)

This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.

It is generally safe and recommended to accept the default answers to all
questions, unless you know what you're doing.

 We can start with probing for (PCI) I2C or SMBus adapters.
 You do not need any special privileges for this.
 Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-amd756' for device 00:07.3: AMD-768 System Management
Probe succesfully concluded.

We will now try to load each adapter module in turn.
Module `i2c-amd756' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

 To continue, we need module `i2c-dev' to be loaded.
 If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.

 We are now going to do the adapter probings. Some adapters may hang halfway
 through; we can't really help that. Also, some chips will be double detected;
 we choose the one with the highest confidence value in that case.
 If you found that the adapter hung after probing a certain address, you can
 specify that address to remain unprobed. That often
 includes address 0x69 (clock chip).

Next adapter: Virtual I2C (i2c-0, mux 70:01)
Do you want to scan it? (YES/no/selectively):
Client found at address 0x08
Client found at address 0x4c
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82/LM83'... Failed!
Probing for `National Semiconductor LM90'... Success!
    (confidence 8, driver `lm90')
Probing for `National Semiconductor LM89/LM99'... Failed!
Probing for `National Semiconductor LM86'... Failed!
Probing for `Analog Devices ADM1032'... Failed!
Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
Probing for `National Semiconductor LM63'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Probing for `Analog Devices ADT7461'... Failed!
Client found at address 0x50
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Probing for `DDC monitor'... Failed!
Probing for `Maxim MAX6900'... Failed!
Client found at address 0x51

Re: [PATCH -rt 3/5] asm/local.h cmpxchg

[Daniel Walker]

On Sat, 2007-07-14 at 19:57 +0200, Peter Zijlstra wrote:
> ===
> ---
> linux-2.6.22-rc6-mm1.orig/include/asm-generic/local.h   2007-07-12
> 19:44:18.0 -0700
> +++ linux-2.6.22-rc6-mm1/include/asm-generic/local.h2007-07-12
> 19:44:57.0 -0700
> @@ -46,13 +46,34 @@ typedef struct
>  #define local_add_unless(l, a, u) atomic_long_add_unless((&(l)->a),
> (a), (u))
>  #define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
>  
> -/* Non-atomic variants, ie. preemption disabled and won't be touched
> - * in interrupt, etc.  Some archs can optimize this case well. */
> +/*
> + * Establish a state necessary for __local_xx functions to work.
> + */
> +#define __local_begin(flags)   local_irq_disable(flags) 

Did you mean local_irq_save(flags)? local_irq_disable() doesn't take any
arguments.

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 1/5] workqueue: queue_work_cpu

[Oleg Nesterov]

On 07/14, Peter Zijlstra wrote:
>
> +int fastcall queue_work_cpu(struct workqueue_struct *wq, struct work_struct 
> *work, int cpu)
> +{
> + int ret = 0;
> +
> + if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {
> + BUG_ON(!list_empty(&work->entry));
> + __queue_work(wq_per_cpu(wq, cpu), work);
> + ret = 1;
> + }
> + return ret;
> +}

Minor nit, we already have queue_delayed_work_on(), perhaps it should be named
queue_work_on().

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 3/5] asm/local.h cmpxchg

[Mathieu Desnoyers]

* Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> 
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
>  include/asm-generic/local.h |   25 +++--
>  include/asm-i386/local.h|   13 +
>  include/asm-x86_64/local.h  |   16 
>  3 files changed, 52 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.22-rc6-mm1/include/asm-generic/local.h
> ===
> --- linux-2.6.22-rc6-mm1.orig/include/asm-generic/local.h 2007-07-12 
> 19:44:18.0 -0700
> +++ linux-2.6.22-rc6-mm1/include/asm-generic/local.h  2007-07-12 
> 19:44:57.0 -0700
> @@ -46,13 +46,34 @@ typedef struct
>  #define local_add_unless(l, a, u) atomic_long_add_unless((&(l)->a), (a), (u))
>  #define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
>  
> -/* Non-atomic variants, ie. preemption disabled and won't be touched
> - * in interrupt, etc.  Some archs can optimize this case well. */
> +/*
> + * Establish a state necessary for __local_xx functions to work.
> + */
> +#define __local_begin(flags) local_irq_disable(flags)
> +
> +static inline void __local_end(unsigned long flags)
> +{
> + local_irq_restore(flags);
> +}
> +

Wouldn't it be cheaper to use preempt_disable/enable instead of irq
disable/enable in asm-generic to protect the __local accesses since they
are not supposed to be touched by interrupt context ?

I also think that __local_begin/end() should be changed into
local_begin() and local_end(). It makes sense to use this around all
local_t variable accesses.

> +/*
> + * Non-atomic variants, ie. within local_begin() / local_end() or
> + * preempt_disable / enable() and won't be touched in interrupt, etc.
> + * Some archs can optimize this case well.
> + */
>  #define __local_inc(l)   local_set((l), local_read(l) + 1)
>  #define __local_dec(l)   local_set((l), local_read(l) - 1)
>  #define __local_add(i,l) local_set((l), local_read(l) + (i))
>  #define __local_sub(i,l) local_set((l), local_read(l) - (i))
>  
> +#define __local_cmpxchg((v), (o), (n)) (*(v) = (n), (o))

Shouldn't this look like a while loop instead ? Where is the
comparison ? It should use local_set and local_read...

The proper way to do this would be to take all architectures that only
define a atomic_cmpxchg and atomic_xchg and turn that into a cmpxchg and
xchg. Then, the same could be done for architectures which only have a
local_cmpxchg, but no cmpxchg_local.

Then, cmpxchg_local could be used to touch a variable in an atomic wrt
cpu fashion without wrapping the variable in a local_t.

All the local_*() functions should only touch local_t types.

If local_begin()/local_end() is defined as preempt disable/enable, then
it's ok to use this to protect __local_*() accesses. However, if you
turn this into a migrate_disable/enable(), then the protection against
other threads on the same CPU is not insured.

> +#define __local_xchg((v), (n))   
> \
> +({   \
> + __typeof(v) x = *(v);   \
> + *(v) = (n); \
> + x;  \
> +)}
> +
>  /* Use these for per-cpu local_t variables: on some archs they are
>   * much more efficient than these naive implementations.  Note they take
>   * a variable (eg. mystruct.foo), not an address.
> Index: linux-2.6.22-rc6-mm1/include/asm-x86_64/local.h
> ===
> --- linux-2.6.22-rc6-mm1.orig/include/asm-x86_64/local.h  2007-07-12 
> 19:44:18.0 -0700
> +++ linux-2.6.22-rc6-mm1/include/asm-x86_64/local.h   2007-07-12 
> 19:44:57.0 -0700
> @@ -9,6 +9,7 @@ typedef struct
>   atomic_long_t a;
>  } local_t;
>  
> +

Empty line ?

>  #define LOCAL_INIT(i){ ATOMIC_LONG_INIT(i) }
>  
>  #define local_read(l)atomic_long_read(&(l)->a)
> @@ -181,11 +182,26 @@ static __inline__ long local_sub_return(
>  
>  /* On x86-64 these are better than the atomic variants on SMP kernels
> because they dont use a lock prefix. */
> +
> +#define __local_begin(__flags)   \
> +{\
> + (__flags) = 0;  \

What are these flags doing ? And why are they not set back in
__local_end ? I'm a bit curious :)

> + preempt_disable();  \
> +}
> +
> +static inline void __local_end(unsigned long flags) {
> + preempt_enable();
> +}
> +

Same here : __local_begin/end() -> local_begin/end().

>  #define __local_inc(l)   local_inc(l)
>  #define __local_dec(l)   local_dec(l)
>  #define __local_add(i,l) local_add((i),(l))
>  #define __local_sub(i,l) local_sub((i),(l))
>  
> +#define __local_cmpxchg  

Re: [PATCH -rt 2/5] Thread Migration Preemption - v2

[Oleg Nesterov]

On 07/14, Peter Zijlstra wrote:
>
> From: Mathieu Desnoyers <[EMAIL PROTECTED]>
> 
> This patch adds the ability to protect critical sections from migration to
> another CPU without disabling preemption.
> 
> This will be useful to minimize the amount of preemption disabling for the -rt
> patch. It will help leveraging improvements brought by the local_t types in
> asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
> variables protected by migrate_disable must be either atomic or protected from
> concurrent updates done by other threads.
> 
> Typical use:
> 
> migrate_disable();
> local_inc(&__get_cpu_var(&my_local_t_var));
> migrate_enable();
> 
> Which will increment the variable atomically wrt the local CPU.

I still think this patch is buggy. Perhaps I am wrong. Please look at

http://marc.info/?l=linux-kernel&m=118417177818825

there was no any reply.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 4/5] use migrate_disable for __local_begin

[Mathieu Desnoyers]

* Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
>  include/asm-i386/local.h   |7 ---
>  include/asm-x86_64/local.h |7 ---
>  2 files changed, 8 insertions(+), 6 deletions(-)
> 
> Index: linux-2.6/include/asm-i386/local.h
> ===
> --- linux-2.6.orig/include/asm-i386/local.h
> +++ linux-2.6/include/asm-i386/local.h
> @@ -197,11 +197,12 @@ static __inline__ long local_sub_return(
>  #define __local_begin(__flags)   \
>  {\
>   (__flags) = 0;  \
> - preempt_disable();  \
> + migrate_disable();  \

B. That's wrong. Your non atomic __local*() updates only makes sense
when preempt_disable/enable() protects them from concurrent threads on
the same CPU, which is not the case of migrate_disable/enable(). This is
why I suggest that you use local_begin/end() mapped to
migrate_disable/enable() for normal local variables, and, if you really
want a __local_begin/end(), then it should be mapped to
preempt_disable/enable() and should state that it provides no protection
against interrupts.

Mathieu

>  }
>  
> -static inline void __local_end(unsigned long flags) {
> - preempt_enable();
> +static inline void __local_end(unsigned long flags)
> +{
> + migrate_enable();
>  }
>  
>  /* On x86, these are no better than the atomic variants. */
> Index: linux-2.6/include/asm-x86_64/local.h
> ===
> --- linux-2.6.orig/include/asm-x86_64/local.h
> +++ linux-2.6/include/asm-x86_64/local.h
> @@ -186,11 +186,12 @@ static __inline__ long local_sub_return(
>  #define __local_begin(__flags)   \
>  {\
>   (__flags) = 0;  \
> - preempt_disable();  \
> + migrate_disable();  \
>  }
>  
> -static inline void __local_end(unsigned long flags) {
> - preempt_enable();
> +static inline void __local_end(unsigned long flags)
> +{
> + migrate_enable();
>  }
>  
>  #define __local_inc(l)   local_inc(l)
> 
> --
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] CFS scheduler, -v19

[Ed Tomlinson]

Hi,

I run a java application at nice 15.  Its been a background application here 
for as long
as SD and CFS have been around.  If I have a compile running at nice 0, with 
v19 java 
gets so little cpu that the the wrapper that runs to monitor it is timing out 
waiting for 
it to start.  This is new in v19 - something in v19 is not meshing well with my 
mix 
of applications...

Kernel is gentoo 2.6.22-r1 + cfs v19

How can I help to debug this?
Ed Tomlinson

On Friday 06 July 2007 13:33, Ingo Molnar wrote:
> i'm pleased to announce release -v19 of the CFS scheduler patchset.
> 
> The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7, 
> v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the 
> usual place:
> 
>     http://people.redhat.com/mingo/cfs-scheduler/
>  
> The biggest user-visible change in -v19 is reworked sleeper fairness: 
> it's similar in behavior to -v18 but works more consistently across nice 
> levels. Fork-happy workloads (like kernel builds) should behave better 
> as well. There are also a handful of speedups: unsigned math, 32-bit 
> speedups, O(1) task pickup, debloating and other micro-optimizations.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 3/5] asm/local.h cmpxchg

[Peter Zijlstra]

On Sat, 2007-07-14 at 13:14 -0400, Mathieu Desnoyers wrote:
> * Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> > From: Christoph Lameter <[EMAIL PROTECTED]>
> > 
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > ---
> >  include/asm-generic/local.h |   25 +++--
> >  include/asm-i386/local.h|   13 +
> >  include/asm-x86_64/local.h  |   16 
> >  3 files changed, 52 insertions(+), 2 deletions(-)
> > 
> > Index: linux-2.6.22-rc6-mm1/include/asm-generic/local.h
> > ===
> > --- linux-2.6.22-rc6-mm1.orig/include/asm-generic/local.h   2007-07-12 
> > 19:44:18.0 -0700
> > +++ linux-2.6.22-rc6-mm1/include/asm-generic/local.h2007-07-12 
> > 19:44:57.0 -0700
> > @@ -46,13 +46,34 @@ typedef struct
> >  #define local_add_unless(l, a, u) atomic_long_add_unless((&(l)->a), (a), 
> > (u))
> >  #define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
> >  
> > -/* Non-atomic variants, ie. preemption disabled and won't be touched
> > - * in interrupt, etc.  Some archs can optimize this case well. */
> > +/*
> > + * Establish a state necessary for __local_xx functions to work.
> > + */
> > +#define __local_begin(flags)   local_irq_disable(flags)
> > +
> > +static inline void __local_end(unsigned long flags)
> > +{
> > +   local_irq_restore(flags);
> > +}
> > +
> 
> Wouldn't it be cheaper to use preempt_disable/enable instead of irq
> disable/enable in asm-generic to protect the __local accesses since they
> are not supposed to be touched by interrupt context ?
> 
> I also think that __local_begin/end() should be changed into
> local_begin() and local_end(). It makes sense to use this around all
> local_t variable accesses.
> 
> > +/*
> > + * Non-atomic variants, ie. within local_begin() / local_end() or
> > + * preempt_disable / enable() and won't be touched in interrupt, etc.
> > + * Some archs can optimize this case well.
> > + */
> >  #define __local_inc(l) local_set((l), local_read(l) + 1)
> >  #define __local_dec(l) local_set((l), local_read(l) - 1)
> >  #define __local_add(i,l)   local_set((l), local_read(l) + (i))
> >  #define __local_sub(i,l)   local_set((l), local_read(l) - (i))
> >  
> > +#define __local_cmpxchg((v), (o), (n)) (*(v) = (n), (o))
> 
> Shouldn't this look like a while loop instead ? Where is the
> comparison ? It should use local_set and local_read...

Yeah, needs more thought.

> The proper way to do this would be to take all architectures that only
> define a atomic_cmpxchg and atomic_xchg and turn that into a cmpxchg and
> xchg. Then, the same could be done for architectures which only have a
> local_cmpxchg, but no cmpxchg_local.
> 
> Then, cmpxchg_local could be used to touch a variable in an atomic wrt
> cpu fashion without wrapping the variable in a local_t.
> 
> All the local_*() functions should only touch local_t types.
> 
> If local_begin()/local_end() is defined as preempt disable/enable, then
> it's ok to use this to protect __local_*() accesses. However, if you
> turn this into a migrate_disable/enable(), then the protection against
> other threads on the same CPU is not insured.

Yeah, the generic stuff is rather broken. For -rt begin/end should map
to migrate_disable/enable, and the primitives could be done using
preempt_disable/enable.

something like so:

static inline void local_begin(flags)
{
migrate_disable();
}

static inline void local_end(flags)
{
migrate_enable();
}

#define __local_cmpxchg(__p, __o, __n)  \
({  typeof(__o) o;  \
preempt_disable();  \
o = *(__p); \
if (o == (__o)) \
*(__p) = __n;   \
preempt_enable();   \
o; })


Obviously that only works for -rt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 4/5] use migrate_disable for __local_begin

[Peter Zijlstra]

On Sat, 2007-07-14 at 13:16 -0400, Mathieu Desnoyers wrote:
> * Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > ---
> >  include/asm-i386/local.h   |7 ---
> >  include/asm-x86_64/local.h |7 ---
> >  2 files changed, 8 insertions(+), 6 deletions(-)
> > 
> > Index: linux-2.6/include/asm-i386/local.h
> > ===
> > --- linux-2.6.orig/include/asm-i386/local.h
> > +++ linux-2.6/include/asm-i386/local.h
> > @@ -197,11 +197,12 @@ static __inline__ long local_sub_return(
> >  #define __local_begin(__flags) \
> >  {  \
> > (__flags) = 0;  \
> > -   preempt_disable();  \
> > +   migrate_disable();  \
> 
> B. That's wrong. Your non atomic __local*() updates only makes sense
> when preempt_disable/enable() protects them from concurrent threads on
> the same CPU, which is not the case of migrate_disable/enable(). This is
> why I suggest that you use local_begin/end() mapped to
> migrate_disable/enable() for normal local variables, and, if you really
> want a __local_begin/end(), then it should be mapped to
> preempt_disable/enable() and should state that it provides no protection
> against interrupts.

Sure, but on -rt it does suffice, this part of the patch is rather WIP.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 2/5] Thread Migration Preemption - v2

[Peter Zijlstra]

On Sat, 2007-07-14 at 21:16 +0400, Oleg Nesterov wrote:
> On 07/14, Peter Zijlstra wrote:
> >
> > From: Mathieu Desnoyers <[EMAIL PROTECTED]>
> > 
> > This patch adds the ability to protect critical sections from migration to
> > another CPU without disabling preemption.
> > 
> > This will be useful to minimize the amount of preemption disabling for the 
> > -rt
> > patch. It will help leveraging improvements brought by the local_t types in
> > asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
> > variables protected by migrate_disable must be either atomic or protected 
> > from
> > concurrent updates done by other threads.
> > 
> > Typical use:
> > 
> > migrate_disable();
> > local_inc(&__get_cpu_var(&my_local_t_var));
> > migrate_enable();
> > 
> > Which will increment the variable atomically wrt the local CPU.
> 
> I still think this patch is buggy. Perhaps I am wrong. Please look at
> 
>   http://marc.info/?l=linux-kernel&m=118417177818825
> 
> there was no any reply.

Ah, yes. That would be quite nasty. I assumed the patch worked for the
non-hotplug case. But you suggest even regular wakeups could go wrong.
That would need fixing indeed.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 5/5] slub: -rt port

[Oleg Nesterov]

On 07/14, Peter Zijlstra wrote:
>
> +static void flush_all(struct kmem_cache *s)
> +{
> + int cpu;
> + struct workqueue_struct *wq = flush_slab_workqueue;
> +
> + mutex_lock(&flush_slab_mutex);
> + for_each_online_cpu(cpu) {
> + struct slab_work_struct *sw = &per_cpu(slab_works, cpu);
> +
> + INIT_WORK(&sw->work, flush_cpu_slab_wq);
> + sw->s = s;
> + queue_work_cpu(wq, &sw->work, cpu);
> + }
> + flush_workqueue(wq);
> + mutex_unlock(&flush_slab_mutex);
> +}

I suspect this is not cpu-hotplug safe. flush_slab_mutex doesn't protect
from cpu_down(). This means that slab_work_struct could be scheduled on
the already dead CPU. flush_workqueue(wq) will hang in that case.

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add nid sanity on alloc_pages_node

[Nish Aravamudan]

On 7/13/07, Joe Jin <[EMAIL PROTECTED]> wrote:

>
> Patch gone too ;) I deleted it.  I was hoping that you'd send me the final
> finished product (please).
>

Ha.., the patch against 2.6.22, at your patch have use htlb_alloc_mask, but I
cannot found it at 2.6.22 kernel tree, I think you must use difference kernel
tree :)


I believe this patch will be unnecessary if my "Fix hugetlb pool
allocation with empty nodes" patch gets pulled into -mm.
alloc_fresh_huge_page() now takes a mempolicy which is created by the
two callers, rather than reinventing interleaving itself. I believe
this will avoid the oops you saw. I am still waiting on some test
results (annoying -mm config changes) before I repost them (and they
depend on Christoph's fixes for memoryless nodes).

Thanks,
Nish


--- linux-2.6.22/mm/hugetlb.c.orig  2007-07-12 15:02:19.0 +0800
+++ linux-2.6.22/mm/hugetlb.c   2007-07-13 17:33:45.0 +0800
@@ -101,13 +101,20 @@ static void free_huge_page(struct page *

 static int alloc_fresh_huge_page(void)
 {
-   static int nid = 0;
+   static int prev_nid;
struct page *page;
-   page = alloc_pages_node(nid, GFP_HIGHUSER|__GFP_COMP|__GFP_NOWARN,
-   HUGETLB_PAGE_ORDER);
-   nid = next_node(nid, node_online_map);
+   static DEFINE_SPINLOCK(nid_lock);
+   int nid;
+
+   spin_lock(&nid_lock);
+   nid = next_node(prev_nid, node_online_map);
if (nid == MAX_NUMNODES)
nid = first_node(node_online_map);
+   prev_nid = nid;
+   spin_unlock(&nid_lock);
+
+   page = alloc_pages_node(nid, GFP_HIGHUSER|__GFP_COMP|__GFP_NOWARN,
+   HUGETLB_PAGE_ORDER);
if (page) {
set_compound_page_dtor(page, free_huge_page);
spin_lock(&hugetlb_lock);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 5/5] slub: -rt port

[Peter Zijlstra]

On Sat, 2007-07-14 at 21:39 +0400, Oleg Nesterov wrote:
> On 07/14, Peter Zijlstra wrote:
> >
> > +static void flush_all(struct kmem_cache *s)
> > +{
> > +   int cpu;
> > +   struct workqueue_struct *wq = flush_slab_workqueue;
> > +
> > +   mutex_lock(&flush_slab_mutex);
> > +   for_each_online_cpu(cpu) {
> > +   struct slab_work_struct *sw = &per_cpu(slab_works, cpu);
> > +
> > +   INIT_WORK(&sw->work, flush_cpu_slab_wq);
> > +   sw->s = s;
> > +   queue_work_cpu(wq, &sw->work, cpu);
> > +   }
> > +   flush_workqueue(wq);
> > +   mutex_unlock(&flush_slab_mutex);
> > +}
> 
> I suspect this is not cpu-hotplug safe. flush_slab_mutex doesn't protect
> from cpu_down(). This means that slab_work_struct could be scheduled on
> the already dead CPU. flush_workqueue(wq) will hang in that case.

Yeah, the function I copied this from: schedule_on_each_cpu() has a
comment to that effect.

Any ideas on how to solve 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: Further 2.6.23 merge plans...

[Michael S. Tsirkin]

> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Further 2.6.23 merge plans...
> 
>  > Any plans to do something with multiple EQ support in mthca?
> 
> I haven't done any work on it or seen anything from anyone else, so I
> expect this will have to wait for 2.6.24.

I'm surprised to hear this. How about this:
http://lists.openfabrics.org/pipermail/general/2007-May/035757.html

-- 
MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 1/5] workqueue: queue_work_cpu

[Peter Zijlstra]

On Sat, 2007-07-14 at 21:14 +0400, Oleg Nesterov wrote:
> On 07/14, Peter Zijlstra wrote:
> >
> > +int fastcall queue_work_cpu(struct workqueue_struct *wq, struct 
> > work_struct *work, int cpu)
> > +{
> > +   int ret = 0;
> > +
> > +   if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {
> > +   BUG_ON(!list_empty(&work->entry));
> > +   __queue_work(wq_per_cpu(wq, cpu), work);
> > +   ret = 1;
> > +   }
> > +   return ret;
> > +}
> 
> Minor nit, we already have queue_delayed_work_on(), perhaps it should be named
> queue_work_on().

Yes, that makes sense. Shall do.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add nid sanity on alloc_pages_node

[Andrew Morton]

On Sat, 14 Jul 2007 10:40:25 -0700 "Nish Aravamudan" <[EMAIL PROTECTED]> wrote:

> On 7/13/07, Joe Jin <[EMAIL PROTECTED]> wrote:
> > >
> > > Patch gone too ;) I deleted it.  I was hoping that you'd send me the final
> > > finished product (please).
> > >
> >
> > Ha.., the patch against 2.6.22, at your patch have use htlb_alloc_mask, but 
> > I
> > cannot found it at 2.6.22 kernel tree, I think you must use difference 
> > kernel
> > tree :)
> 
> I believe this patch will be unnecessary if my "Fix hugetlb pool
> allocation with empty nodes" patch gets pulled into -mm.
> alloc_fresh_huge_page() now takes a mempolicy which is created by the
> two callers, rather than reinventing interleaving itself. I believe
> this will avoid the oops you saw. I am still waiting on some test
> results (annoying -mm config changes) before I repost them (and they
> depend on Christoph's fixes for memoryless nodes).

Could be so, but the patch which I have queued is nice and simple and
can be backported into 2.6.22.x.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-rc6-mm1

[Thomas Gleixner]

On Sat, 2007-07-14 at 02:07 -0700, Andrew Morton wrote:
> + if (0 && (id & HPET_ID_LEGSUP)) {
>   hpet_enable_int();
>   hpet_reserve_platform_timers(id);
>   /*
> _
> 
> will, if executed (on x86_64, at least), instaoops the machine.  It might
> take down i386 as well, dunno.
> 
> I'd forgotten about this problem, and it seems that Thomas & John have too.
> It's a showstopper.

No, I have not. I found and solved the problem. Updates to the x8664
hrtimer queue are going out tomorrow.

tglx



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Thread Migration Preemption - v2

[Mathieu Desnoyers]

* Oleg Nesterov ([EMAIL PROTECTED]) wrote:
> On 07/11, Mathieu Desnoyers wrote:
> > 
> > This patch adds the ability to protect critical sections from migration to
> > another CPU without disabling preemption.
> > 
> > This will be useful to minimize the amount of preemption disabling for the 
> > -rt
> > patch. It will help leveraging improvements brought by the local_t types in
> > asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
> > variables protected by migrate_disable must be either atomic or protected 
> > from
> > concurrent updates done by other threads.
> > 
> > Typical use:
> > 
> > migrate_disable();
> > local_inc(&__get_cpu_var(&my_local_t_var));
> > migrate_enable();
> > 
> > Which will increment the variable atomically wrt the local CPU.
> 
> Well, I am not a maintainer, but I personally think this patch is too complex.
> 
> Mathieu, please use "diff -p", it is very difficult to read it. I am not sure
> I understand this patch correctly, I don't have a -git tree.
> 

man quilt... echo "QUILT_DIFF_OPTS="-p" > ~/.quiltrc. done. :) Thanks
for pointing this out, the next patches should include this.


> >  static int __migrate_task(struct task_struct *p, int src_cpu, int dest_cpu)
> >  {
> > @@ -4829,13 +4888,19 @@
> >  
> > double_rq_lock(rq_src, rq_dest);
> > /* Already moved. */
> > -   if (task_cpu(p) != src_cpu)
> > +   if (task_cpu(p) != src_cpu) {
> > +   ret = 1;
> > goto out;
> > +   }
> 
> This is a strange change. Why we return success when migration failed ?
> OK, I guess this is a special hack for the modified migration_thread()...
> 

Yes, I wanted to change __migrate_task so it returns true if, after it
has been called to migrate a task out of a source CPU, the task is
indeed now migrated out the this CPU.

It follows a comment already at the beginning of this function:

  * So we race with normal scheduler movements, but that's OK, as long
  * as the task is no longer on this CPU.

The comment at the beginning explains the new convention:

- * Returns non-zero if task was successfully migrated.
+ * Returns non-zero if task is on dest_cpu when this function ends.

Well.. my comment is not perfect. It should read:

- * Returns non-zero if task was successfully migrated.
+ * Returns non-zero if task is not on src_cpu when this function ends.

My assumption is that if migrate_task races with the scheduler movement
to move a task out of a CPU, it should return non-zero in every case
when the task has been migrated out of the src_cpu.


> > /* Affinity changed (again). */
> > if (!cpu_isset(dest_cpu, p->cpus_allowed))
> > goto out;
> >  
> > on_rq = p->se.on_rq;
> > +#ifdef CONFIG_PREEMPT
> > +   if (!on_rq && task_thread_info(p)->migrate_count)
> > +   goto out;
> > +#endif
> 
> This means that move_task_off_dead_cpu() will spin until the task will be 
> scheduled
> on the dead CPU. Given that we hold tasklist_lock and irqs are disabled, this 
> may
> never happen.
> 

Yes. My idea to fix this issue is the following:

If a thread has non zero migrate_count, we should still move it to a
different CPU upon hotplug cpu removal, even if this thread resists
migration. Care should be taken to send _all_ such threads to the _same_
CPU so they don't race for the per-cpu ressources. Does it make sense ?

We would have to keep the CPU affinity of the threads running on the
wrong CPU until they end their migrate disabled section, so that we can
put them back on their original CPU if it goes back online, otherwise we
could end up with concurrent per-cpu variables accesses.

(I'll wait for reply before coding a solution for this CPU HOTPLUG
related problem)

> (This patch adds a lot of #ifdef's, I think it could be simplified if you add
>  get_migrate_count() which is defined as 0 when !CONFIG_PREEMPT).

Sure. Added migrate_count() and task_migrate_count(task).

> 
> > @@ -4891,10 +4957,22 @@
> > list_del_init(head->next);
> >  
> > spin_unlock(&rq->lock);
> > -   __migrate_task(req->task, cpu, req->dest_cpu);
> > +   migrated = __migrate_task(req->task, cpu, req->dest_cpu);
> > local_irq_enable();
> > -
> > -   complete(&req->done);
> > +   if (!migrated) {
> > +   /*
> > +* If the process has not been migrated, let it run
> > +* until it reaches a migration_check() so it can
> > +* wake us up.
> > +*/
> > +   spin_lock_irq(&rq->lock);
> > +   head = &rq->migration_queue;
> > +   list_add(&req->list, head);
> > +   set_tsk_thread_flag(req->task, TIF_NEED_MIGRATE);
> > +   spin_unlock_irq(&rq->lock);
> > +   wake_up_process(req->task);
> > +   } else
> > +   complete(&req->done);
> 
> I guess this is migration_thread(). The wake_up_

Re: [PATCH] NET_CLS_RSVP6 should depend on IPV6

[Gabriel C]

Patrick McHardy wrote:
> Gabriel C wrote:
>   
>> cls_rsvp6 only works with IPV6 enabled kernels and IMO it should depends
>> on IPV6.
>> 
>
>
> I can't see any functional dependency on IPv6, what exactly are you
> refering to? People might want to use it on a bridge for example
> without having IPv6 running locally.
>
>   

I didn't knew it can be used with bridges , in this case just ignore the
patch and sorry for the noise.


Regards,

Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 3/5] asm/local.h cmpxchg

[Mathieu Desnoyers]

* Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> On Sat, 2007-07-14 at 13:14 -0400, Mathieu Desnoyers wrote:
> > * Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> > > From: Christoph Lameter <[EMAIL PROTECTED]>
> > > 
> > > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > > ---
> > >  include/asm-generic/local.h |   25 +++--
> > >  include/asm-i386/local.h|   13 +
> > >  include/asm-x86_64/local.h  |   16 
> > >  3 files changed, 52 insertions(+), 2 deletions(-)
> > > 
> > > Index: linux-2.6.22-rc6-mm1/include/asm-generic/local.h
> > > ===
> > > --- linux-2.6.22-rc6-mm1.orig/include/asm-generic/local.h 2007-07-12 
> > > 19:44:18.0 -0700
> > > +++ linux-2.6.22-rc6-mm1/include/asm-generic/local.h  2007-07-12 
> > > 19:44:57.0 -0700
> > > @@ -46,13 +46,34 @@ typedef struct
> > >  #define local_add_unless(l, a, u) atomic_long_add_unless((&(l)->a), (a), 
> > > (u))
> > >  #define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
> > >  
> > > -/* Non-atomic variants, ie. preemption disabled and won't be touched
> > > - * in interrupt, etc.  Some archs can optimize this case well. */
> > > +/*
> > > + * Establish a state necessary for __local_xx functions to work.
> > > + */
> > > +#define __local_begin(flags) local_irq_disable(flags)
> > > +
> > > +static inline void __local_end(unsigned long flags)
> > > +{
> > > + local_irq_restore(flags);
> > > +}
> > > +
> > 
> > Wouldn't it be cheaper to use preempt_disable/enable instead of irq
> > disable/enable in asm-generic to protect the __local accesses since they
> > are not supposed to be touched by interrupt context ?
> > 
> > I also think that __local_begin/end() should be changed into
> > local_begin() and local_end(). It makes sense to use this around all
> > local_t variable accesses.
> > 
> > > +/*
> > > + * Non-atomic variants, ie. within local_begin() / local_end() or
> > > + * preempt_disable / enable() and won't be touched in interrupt, etc.
> > > + * Some archs can optimize this case well.
> > > + */
> > >  #define __local_inc(l)   local_set((l), local_read(l) + 1)
> > >  #define __local_dec(l)   local_set((l), local_read(l) - 1)
> > >  #define __local_add(i,l) local_set((l), local_read(l) + (i))
> > >  #define __local_sub(i,l) local_set((l), local_read(l) - (i))
> > >  
> > > +#define __local_cmpxchg((v), (o), (n)) (*(v) = (n), (o))
> > 
> > Shouldn't this look like a while loop instead ? Where is the
> > comparison ? It should use local_set and local_read...
> 
> Yeah, needs more thought.
> 
> > The proper way to do this would be to take all architectures that only
> > define a atomic_cmpxchg and atomic_xchg and turn that into a cmpxchg and
> > xchg. Then, the same could be done for architectures which only have a
> > local_cmpxchg, but no cmpxchg_local.
> > 
> > Then, cmpxchg_local could be used to touch a variable in an atomic wrt
> > cpu fashion without wrapping the variable in a local_t.
> > 
> > All the local_*() functions should only touch local_t types.
> > 
> > If local_begin()/local_end() is defined as preempt disable/enable, then
> > it's ok to use this to protect __local_*() accesses. However, if you
> > turn this into a migrate_disable/enable(), then the protection against
> > other threads on the same CPU is not insured.
> 
> Yeah, the generic stuff is rather broken. For -rt begin/end should map
> to migrate_disable/enable, and the primitives could be done using
> preempt_disable/enable.
> 
> something like so:
> 
> static inline void local_begin(flags)
> {
>   migrate_disable();
> }
> 
> static inline void local_end(flags)
> {
>   migrate_enable();
> }
> 
> #define __local_cmpxchg(__p, __o, __n)\
> ({typeof(__o) o;  \
>   preempt_disable();  \
>   o = *(__p); \
>   if (o == (__o)) \
>   *(__p) = __n;   \
>   preempt_enable();   \
>   o; })
> 

Nitpicking:

This should be named __cmpxchg_local(), since it does not apply to
local_t variables.

Also, it would not hurt to have __local_begin and __local_end around
__cmpxchg_local to offer an interface similar to local_begin and
local_end. Those two would map to preempt_disable/enable.

> 
> Obviously that only works for -rt.
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -rt 4/5] use migrate_disable for __local_begin

[Mathieu Desnoyers]

* Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> On Sat, 2007-07-14 at 13:16 -0400, Mathieu Desnoyers wrote:
> > * Peter Zijlstra ([EMAIL PROTECTED]) wrote:
> > > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > > ---
> > >  include/asm-i386/local.h   |7 ---
> > >  include/asm-x86_64/local.h |7 ---
> > >  2 files changed, 8 insertions(+), 6 deletions(-)
> > > 
> > > Index: linux-2.6/include/asm-i386/local.h
> > > ===
> > > --- linux-2.6.orig/include/asm-i386/local.h
> > > +++ linux-2.6/include/asm-i386/local.h
> > > @@ -197,11 +197,12 @@ static __inline__ long local_sub_return(
> > >  #define __local_begin(__flags)   \
> > >  {\
> > >   (__flags) = 0;  \
> > > - preempt_disable();  \
> > > + migrate_disable();  \
> > 
> > B. That's wrong. Your non atomic __local*() updates only makes sense
> > when preempt_disable/enable() protects them from concurrent threads on
> > the same CPU, which is not the case of migrate_disable/enable(). This is
> > why I suggest that you use local_begin/end() mapped to
> > migrate_disable/enable() for normal local variables, and, if you really
> > want a __local_begin/end(), then it should be mapped to
> > preempt_disable/enable() and should state that it provides no protection
> > against interrupts.
> 
> Sure, but on -rt it does suffice, this part of the patch is rather WIP.
> 
> 

Hrm, how can it suffice, I wonder ? migrate_disable() does not protect
against other threads on the same CPU, so you could suffer from
concurrent updates to the same variables. How is it different in -rt ?

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Merging Nozomi Driver

[Michael Lothian]

Hi

I was wondering if there are any plans to merge the Nozomi driver
which has been living in mm for quite a while now into the main line
kernel.

I spoke about this a wee bitafter rc1 of 2.6.22 but I´m not sure if
the discussed clean up was ever implemented

I´d be greatful for any info

Thanks

Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Thread Migration Preemption - v3

[Mathieu Desnoyers]

Thread Migration Preemption

This patch adds the ability to protect critical sections from migration to
another CPU without disabling preemption.

This will be useful to minimize the amount of preemption disabling for the -rt
patch. It will help leveraging improvements brought by the local_t types in
asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
variables protected by migrate_disable must be either atomic or protected from
concurrent updates done by other threads.

Typical use:

migrate_disable();
local_inc(&__get_cpu_var(&my_local_t_var));
migrate_enable();

Which will increment the variable atomically wrt the local CPU.

Changes:

Do a check_migrate() upon migrate_enable() to answer to the migration
thread waiting for us to exit the migration disabled critical section. Use a
NEED_MIGRATE thread flag for this.

Note: (or we could say FIXME)
Is we ever want to check migration pending in assembly code, we will have to
make sure we test the right thread flag bits on each architectures. Care should
also be taken to check that the thread flags used won't trigger false positives
in non selective asm thread flag checks.

FIXME (HOTPLUG) :

> > /* Affinity changed (again). */
> > if (!cpu_isset(dest_cpu, p->cpus_allowed))
> > goto out;
> >  
> > on_rq = p->se.on_rq;
> > +#ifdef CONFIG_PREEMPT
> > +   if (!on_rq && task_thread_info(p)->migrate_count)
> > +   goto out;
> > +#endif
> 
> This means that move_task_off_dead_cpu() will spin until the task will be
> scheduled
> on the dead CPU. Given that we hold tasklist_lock and irqs are disabled, this
> may
> never happen.
>

Yes. My idea to fix this issue is the following:

If a thread has non zero migrate_count, we should still move it to a
different CPU upon hotplug cpu removal, even if this thread resists
migration. Care should be taken to send _all_ such threads to the _same_
CPU so they don't race for the per-cpu ressources. Does it make sense ?

We would have to keep the CPU affinity of the threads running on the
wrong CPU until they end their migrate disabled section, so that we can
put them back on their original CPU if it goes back online, otherwise we
could end up with concurrent per-cpu variables accesses.

(I'll wait for reply before coding a solution for this CPU HOTPLUG
related problem)


Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
 include/asm-alpha/thread_info.h |3 +
 include/asm-arm/thread_info.h   |5 +
 include/asm-arm26/thread_info.h |5 +
 include/asm-avr32/thread_info.h |4 +
 include/asm-blackfin/thread_info.h  |4 +
 include/asm-cris/thread_info.h  |4 +
 include/asm-frv/thread_info.h   |4 +
 include/asm-h8300/thread_info.h |4 +
 include/asm-i386/thread_info.h  |6 +-
 include/asm-ia64/thread_info.h  |4 +
 include/asm-m32r/thread_info.h  |4 +
 include/asm-m68k/thread_info.h  |2 
 include/asm-m68knommu/thread_info.h |3 +
 include/asm-mips/thread_info.h  |4 +
 include/asm-parisc/thread_info.h|4 +
 include/asm-powerpc/thread_info.h   |4 +
 include/asm-s390/thread_info.h  |4 +
 include/asm-sh/thread_info.h|4 +
 include/asm-sh64/thread_info.h  |4 +
 include/asm-sparc/thread_info.h |4 +
 include/asm-sparc64/thread_info.h   |5 +
 include/asm-um/thread_info.h|4 +
 include/asm-v850/thread_info.h  |4 +
 include/asm-x86_64/thread_info.h|4 +
 include/asm-xtensa/thread_info.h|4 +
 include/linux/preempt.h |   47 -
 kernel/sched.c  |   98 +---
 lib/smp_processor_id.c  |6 +-
 28 files changed, 240 insertions(+), 12 deletions(-)

Index: linux-2.6-lttng/include/asm-i386/thread_info.h
===
--- linux-2.6-lttng.orig/include/asm-i386/thread_info.h 2007-07-13 
14:18:26.0 -0400
+++ linux-2.6-lttng/include/asm-i386/thread_info.h  2007-07-14 
13:20:12.0 -0400
@@ -31,8 +31,7 @@ struct thread_info {
unsigned long   status; /* thread-synchronous flags */
__u32   cpu;/* current CPU */
int preempt_count;  /* 0 => preemptable, <0 => BUG 
*/
-
-
+   int migrate_count;/* 0: can migrate, <0: BUG */
mm_segment_taddr_limit; /* thread address space:
   0-0xBFFF for user-thead
   0-0x for 
kernel-thread
@@ -74,6 +73,7 @@ struct thread_info {
.flags  = 0,\
.cpu= 0,\
.preempt_count  = 1,\
+   .migrate_count = 0, \
.addr_limit = KERNEL_DS,\
.restart_block