Re: + spin_lock_irq-enable-interrupts-while-spinning-i386-implementation.patch added to -mm tree

[Andrew Morton]

On Sat, 06 Jan 2007 14:35:53 -0800
Daniel Walker <[EMAIL PROTECTED]> wrote:

> On Wed, 2007-01-03 at 13:12 -0800, [EMAIL PROTECTED] wrote:
> > -# define __raw_spin_lock_irq(lock) __raw_spin_lock(lock)
> > +
> > +static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
> > +{
> > +   asm volatile("\n1:\t"
> > +LOCK_PREFIX " ; decb %0\n\t"
> > +"jns 3f\n"
> > +STI_STRING "\n"
> > +"2:\t"
> > +"rep;nop\n\t"
> > +"cmpb $0,%0\n\t"
> > +"jle 2b\n\t"
> > +CLI_STRING "\n"
> > +"jmp 1b\n"
> > +"3:\n\t"
> > +: "+m" (lock->slock) : : "memory");
> > +}
> >  #endif
> >   
> 
> This doesn't compile when CONFIG_PARAVIRT is enabled. It changes the
> CLI_STRING and STI_STRING values.
> 


diff -puN 
include/asm-i386/spinlock.h~spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix
 include/asm-i386/spinlock.h
--- 
a/include/asm-i386/spinlock.h~spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix
+++ a/include/asm-i386/spinlock.h
@@ -86,17 +86,19 @@ static inline void __raw_spin_lock_flags
 static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
 {
asm volatile("\n1:\t"
-LOCK_PREFIX " ; decb %0\n\t"
+LOCK_PREFIX " ; decb %[slock]\n\t"
 "jns 3f\n"
 STI_STRING "\n"
 "2:\t"
 "rep;nop\n\t"
-"cmpb $0,%0\n\t"
+"cmpb $0,%[slock]\n\t"
 "jle 2b\n\t"
 CLI_STRING "\n"
 "jmp 1b\n"
 "3:\n\t"
-: "+m" (lock->slock) : : "memory");
+: [slock] "+m" (lock->slock)
+: __CLI_STI_INPUT_ARGS
+: "memory" CLI_STI_CLOBBERS);
 }
 #endif
 
diff -puN 
include/asm-i386/paravirt.h~spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix
 include/asm-i386/paravirt.h
--- 
a/include/asm-i386/paravirt.h~spin_lock_irq-enable-interrupts-while-spinning-i386-implementation-fix
+++ a/include/asm-i386/paravirt.h
@@ -509,10 +509,10 @@ static inline unsigned long __raw_local_
 "popl %%edx; popl %%ecx",  \
 PARAVIRT_IRQ_ENABLE, CLBR_EAX)
 #define CLI_STI_CLOBBERS , "%eax"
-#define CLI_STI_INPUT_ARGS \
-   ,   \
+#define __CLI_STI_INPUT_ARGS   \
[irq_disable] "i" (offsetof(struct paravirt_ops, irq_disable)), \
[irq_enable] "i" (offsetof(struct paravirt_ops, irq_enable))
+#define CLI_STI_INPUT_ARGS , __CLI_STI_INPUT_ARGS
 
 #else  /* __ASSEMBLY__ */
 
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 pci-increment-pos-before-looking-for-the-next-cap-in-__pci_find_next_ht_cap.patch added to gregkh-2.6 tree

[gregkh]

This is a note to let you know that I've just added the patch titled

 Subject: PCI: increment pos before looking for the next cap in 
__pci_find_next_ht_cap

to my gregkh-2.6 tree.  Its filename is

 
pci-increment-pos-before-looking-for-the-next-cap-in-__pci_find_next_ht_cap.patch

This tree can be found at 
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/


>From [EMAIL PROTECTED]  Fri Jan  5 15:01:21 2007
From: Brice Goglin <[EMAIL PROTECTED]>
Date: Fri, 05 Jan 2007 23:52:14 +0100
Subject: PCI: increment pos before looking for the next cap in 
__pci_find_next_ht_cap
To: Greg KH <[EMAIL PROTECTED]>, Michael Ellerman <[EMAIL PROTECTED]>
Cc: LKML 
Message-ID: <[EMAIL PROTECTED]>

While testing 2.6.20-rc3 on a machine with some CK804 chipsets, we
noticed that quirk_nvidia_ck804_msi_ht_cap() was not detecting HT
MSI capabilities anymore. It is actually caused by the MSI mapping
on the root chipset being the 2nd HT capability in the chain.
pci_find_ht_capability() does not seem to find anything but the
first HT cap correctly, because it forgets to increment the position
before looking for the next cap. The following patch seems to fix it.

At least, this prooves that having a ttl is good idea since the
machine would have been stucked in an infinite loop if we didn't
have a ttl :)

Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
Signed-off-by: Andrew J. Gallatin <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


---
 drivers/pci/pci.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- gregkh-2.6.orig/drivers/pci/pci.c
+++ gregkh-2.6/drivers/pci/pci.c
@@ -254,7 +254,8 @@ static int __pci_find_next_ht_cap(struct
if ((cap & mask) == ht_cap)
return pos;
 
-   pos = __pci_find_next_cap_ttl(dev->bus, dev->devfn, pos,
+   pos = __pci_find_next_cap_ttl(dev->bus, dev->devfn,
+ pos + PCI_CAP_LIST_NEXT,
  PCI_CAP_ID_HT, );
}
 


Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Squashfs 3.2 released

[Phillip Lougher]

Hi,

I'm pleased to announce the release of Squashfs 3.2.  NFS exporting  
is now supported, and the kernel code has been hardened against  
accidently or maliciously corrupted filesystems.  The new release  
correctly handles all corrupted filesystems generated by the fsfuzzer  
tool (written by LMH/Steve Grubb) without oopsing the kernel.  This  
in particular fixes the MOKB (Month of Kernel Bugs) report raised  
against Squashfs.


Squashfs can be dowloaded from http://squashfs.sourceforge.net. The  
full list of changes  are:


Improvements:

1. Squashfs filesystems can now be exported via NFS.
2. Unsquashfs now supports 2.x filesystems.
3. Mksquashfs now displays a progress bar.
4. Squashfs kernel code has been hardened against accidently or
maliciously corrupted Squashfs filesystems.

Bug fixes:

   5. Race condition occurring on S390 in readpage() fixed.
   6. Odd behaviour of MIPS memcpy in read_data() routine worked- 
around.

   7. Missing cache_flush in Squashfs symlink_readpage() added.

Phillip

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

ATA streaming feature support

[Manish Regmi]

Hi all,
  First of all sorry for bringing this topic again.
As discussed in  --> http://lkml.org/lkml/2006/5/5/47
The ATA Streaming feature set is not necessary to be in Kernel Space
(IDE driver). There is a suggestion creating user space library.

But how is the user space apps going to use the commands like READ
STREAM DMA EXT (0x2A). Shouldn't there be some support in kernel which
setups up PRD tables  and all.
It doesn't seem to be possible is it?

Does it sound normal if we have something like O_STREAM in open() or a
seperate IOCTL to command the driver to use STREAM commands (if
supported).

Will this feature be useful for streaming media apps like DVRs? (i am
working in one such.)


--
---
regards
Manish Regmi

---
UNIX without a C Compiler is like eating Spaghetti with your mouth
sewn shut. It just doesn't make sense.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] math-emu/setcc: avoid gcc extension

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

setcc() in math-emu is written as a gcc extension statement expression
macro that returns a value.  However, it's not used that way and it's
not needed like that, so just make it a do-while non-extension macro
so that we don't use an extension when it's not needed.

All 4 .c files that use setcc() produce the same code after this patch.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 arch/i386/math-emu/status_w.h|5 +++--

---
 arch/i386/math-emu/status_w.h |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-2620-rc2.orig/arch/i386/math-emu/status_w.h
+++ linux-2620-rc2/arch/i386/math-emu/status_w.h
@@ -48,9 +48,10 @@
 
 #define status_word() \
   ((partial_status & ~SW_Top & 0x) | ((top << SW_Top_Shift) & SW_Top))
-#define setcc(cc) ({ \
+#define setcc(cc) do { \
   partial_status &= ~(SW_C0|SW_C1|SW_C2|SW_C3); \
-  partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); })
+  partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); } \
+   while (0)
 
 #ifdef PECULIAR_486
/* Default, this conveys no information, but an 80486 does 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/

Linux 2.6.20-rc4

[Linus Torvalds]

There's absolutely nothing interesting here, unless you want to play with 
KVM, or happened to be bitten by the bug with really old versions of the 
linker that made parts of entry.S just go away.

But check it out anyway, and the shortlog gives more details on the 
various minor fixes that have accumulated this week. Mostly in random 
device drivers.

Linus

---
Adam Megacz (1):
  Add AFS_SUPER_MAGIC to magic.h

Adrian Bunk (2):
  [NET] drivers/net/loopback.c: convert to module_init()
  [X25]: proper prototype for x25_init_timers()

Alan (3):
  libata: fix combined mode
  atiixp: Old drivers/ide layer driver for the ATIIXP hang fix
  hpt37x: Two important bug fixes

Alan Stern (2):
  UHCI: make test for ASUS motherboard more specific
  UHCI: support device_may_wakeup

Alexey Dobriyan (2):
  [NETFILTER] xt_hashlimit.c: fix typo
  pata_optidma: typo in Kconfig

Andrew Morton (5):
  USB: funsoft is borken on sparc
  sisusb_con warning fixes
  PCI: disable PCI_MULTITHREAD_PROBE
  ip2 warning fix
  shrink_all_memory(): fix lru_pages handling

Ard van Breemen (3):
  start_kernel: test if irq's got enabled early, barf, and disable them 
again
  kernelparams: detect if and which parameter parsing enabled irq's
  PCI: prevent down_read when pci_devices is empty

Arnaud Patard (2):
  [ARM] 4065/1: S3C24XX: dma printk fixes
  [ARM] 4073/1: Prevent s3c24xx drivers from including asm/arch/hardware.h 
and asm/arch/irqs.h

Avi Kivity (39):
  KVM: Prevent stale bits in cr0 and cr4
  KVM: MMU: Implement simple reverse mapping
  KVM: MMU: Teach the page table walker to track guest page table gfns
  KVM: MMU: Load the pae pdptrs on cr3 change like the processor does
  KVM: MMU: Fold fetch_guest() into init_walker()
  KVM: MU: Special treatment for shadow pae root pages
  KVM: MMU: Use the guest pdptrs instead of mapping cr3 in pae mode
  KVM: MMU: Make the shadow page tables also special-case pae
  KVM: MMU: Make kvm_mmu_alloc_page() return a kvm_mmu_page pointer
  KVM: MMU: Shadow page table caching
  KVM: MMU: Write protect guest pages when a shadow is created for them
  KVM: MMU: Let the walker extract the target page gfn from the pte
  KVM: MMU: Support emulated writes into RAM
  KVM: MMU: Zap shadow page table entries on writes to guest page tables
  KVM: MMU: If emulating an instruction fails, try unprotecting the page
  KVM: MMU: Implement child shadow unlinking
  KVM: MMU: kvm_mmu_put_page() only removes one link to the page
  KVM: MMU: oom handling
  KVM: MMU: Remove invlpg interception
  KVM: MMU: Remove release_pt_page_64()
  KVM: MMU: Handle misaligned accesses to write protected guest page tables
  KVM: MMU: kvm a little earlier
  KVM: Add missing 'break'
  KVM: Don't set guest cr3 from vmx_vcpu_setup()
  KVM: MMU: Add missing dirty bit

Bartlomiej Zolnierkiewicz (1):
  via82cxxx: fix cable detection

Ben Dooks (1):
  [ARM] 4071/1: S3C24XX: Documentation update

Benjamin Herrenschmidt (1):
  [SUNGEM]: PHY updates & pause fixes (#2)

Brice Goglin (1):
  [CPUFREQ] speedstep-centrino: missing space and bracket

Christoph Hellwig (2):
  [XFRM_USER]: avoid pointless void ** casts
  Fix BUG at drivers/scsi/scsi_lib.c:1118 caused by "pktsetup dvd /dev/sr0"

Christoph Lameter (1):
  Check for populated zone in __drain_pages

Chuck Ebbert (1):
  [NETFILTER]: ebtables: don't compute gap before checking struct type

Cyrill V. Gorcunov (1):
  qconf: fix SIGSEGV on empty menu items

Dan Williams (1):
  [ARM] 4077/1: iop13xx: fix __io() macro

Dave Jones (3):
  [CPUFREQ] longhaul: Fix up unreachable code.
  [CPUFREQ] longhaul: Kill off warnings introduced by recent changes.
  Fix implicit declarations in via-pmu

David Brownell (4):
  i2c: Migration aids for i2c_adapter.dev removal
  USB: omap_udc build fixes (sync with linux-omap)
  rtc-at91rm9200 build fix
  Update the rtc-rs5c372 driver

David Hollis (1):
  USB: asix: Fix AX88772 device PHY selection

David L Stevens (1):
  [IPV4/IPV6]: Fix inet{,6} device initialization order.

David S. Miller (2):
  [PKTGEN]: Convert to kthread API.
  [SOUND] Sparc CS4231: Use 64 for period_bytes_min

Dmitry Mishin (1):
  [NETFILTER]: compat offsets size change

Dor Laor (2):
  KVM: Improve interrupt response
  KVM: Simplify test for interrupt window

Doug Chapman (1):
  ACPI: increase ACPI_MAX_REFERENCE_COUNT for larger systems

Eric Anholt (1):
  [AGPGART] fix detection of aperture size versus GTT size on G965

Eric Sandeen (1):
  fix memory corruption from misinterpreted bad_inode_ops return values

Erik Jacobson (1):
  connector: some fixes for ia64 unaligned access errors

Evgeniy Dushistov (1):
  fix garbage instead of zeroes in UFS

Gabriel Mansi (1):
  [AGPGART] 

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Andrew Morton]

On Sun, 7 Jan 2007 12:36:18 +1030
"Tom Lanyon" <[EMAIL PROTECTED]> wrote:

> On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > What would also actually be interesting is whether somebody can reproduce
> > this on Reiserfs, for example. I _think_ all the reports I've seen are on
> > ext2 or ext3, and if this is somehow writeback-related, it could be some
> > bug that is just shared between the two by virtue of them still having a
> > lot of stuff in common.
> >
> > Linus
> 
> I've been following this thread for a while now as I started
> experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
> am using reiserfs.

reiserfs defaults to data=ordered, so it's quite possibly the same bug.

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

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Tom Lanyon]

On 1/7/07, Tom Lanyon <[EMAIL PROTECTED]> wrote:

I've been following this thread for a while now as I started
experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
am using reiserfs.


However, moving to 2.6.20-rc3 does indeed seem to fix the issue thus far...

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

Re: How git affects kernel.org performance

[Linus Torvalds]

On Sat, 6 Jan 2007, H. Peter Anvin wrote:
> 
> During extremely high load, it appears that what slows kernel.org down more
> than anything else is the time that each individual getdents() call takes.
> When I've looked this I've observed times from 200 ms to almost 2 seconds!
> Since an unpacked *OR* unpruned git tree adds 256 directories to a cleanly
> packed tree, you can do the math yourself.

"getdents()" is totally serialized by the inode semaphore. It's one of the 
most expensive system calls in Linux, partly because of that, and partly 
because it has to call all the way down into the filesystem in a way that 
almost no other common system call has to (99% of all filesystem calls can 
be handled basically at the VFS layer with generic caches - but not 
getdents()).

So if there are concurrent readdirs on the same directory, they get 
serialized. If there is any file creation/deletion activity in the 
directory, it serializes getdents(). 

To make matters worse, I don't think it has any read-ahead at all when you 
use hashed directory entries. So if you have cold-cache case, you'll read 
every single block totally individually, and serialized. One block at a 
time (I think the non-hashed case is likely also suspect, but that's a 
separate issue)

In other words, I'm not at all surprised it hits on filldir time. 
Especially on ext3.

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

Re: kernel + gcc 4.1 = several problems

[Jeff Garzik]

Linus Torvalds wrote:
(That said, I think __builtin_memcpy() does a reasonable job these days 
with gcc, and we might drop the crap one day when we can trust the 
compiler to do ok. It didn't use to, and we continued using our 
ridiculous macro/__builtin_constant_p misuses just because it works with 
_all_ relevant gcc versions).



Yep, a ton of work by Roger Sayle, among others, really matured the gcc 
str*/mem* builtins in the 4.x series.  They are definitely worth another 
look.


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/

How git affects kernel.org performance

[H. Peter Anvin]

Some more data on how git affects kernel.org...

During extremely high load, it appears that what slows kernel.org down 
more than anything else is the time that each individual getdents() call 
takes.  When I've looked this I've observed times from 200 ms to almost 
2 seconds!  Since an unpacked *OR* unpruned git tree adds 256 
directories to a cleanly packed tree, you can do the math yourself.


I have tried reducing vm.vfs_cache_pressure down to 1 on the kernel.org 
machines in order to improve the situation, but even at that point it 
appears the kernel doesn't readily hold the entire directory hierarchy 
in memory, even though there is space to do so.  I have suggested that 
we might want to add a sysctl to change the denominator from the default 
100.


The one thing that we need done locally is to have a smart uploader, 
instead of relying on rsync.  That, unfortunately, is a fairly sizable 
project.


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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[H. Peter Anvin]

Nigel Cunningham wrote:

Hi.

On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:

Nigel Cunningham wrote:

Hi.

I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?


Not really.  In fact, it would hardly help at all.

The two things git users can do to help is:

1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned, to keep the file count down.

If you do this, the load imposed by a single git tree is fairly negible.


Sorry for the slow reply, and the ignorance... what's an alternatives
file? I've never heard of them before.



Just a minor correction; it's the "alternates" file 
(objects/info/alternates).


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

Re: kernel + gcc 4.1 = several problems

[Linus Torvalds]

On Sun, 7 Jan 2007, Denis Vlasenko wrote:
> 
> I'd say "care about obvious, safe optimizations which we still not do".
> I want this:
> 
> char v[4];
> ...
>   memcmp(v, "abcd", 4) == 0
> 
> compile to single cmpl on i386.

Yeah. For a more relevant case, look at the hoops we used to jump through 
to get "memcpy()" to generate ok code for trivial fixed-sized cases.

(That said, I think __builtin_memcpy() does a reasonable job these days 
with gcc, and we might drop the crap one day when we can trust the 
compiler to do ok. It didn't use to, and we continued using our 
ridiculous macro/__builtin_constant_p misuses just because it works with 
_all_ relevant gcc versions).

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Nigel Cunningham]

Hi.

On Sat, 2007-01-06 at 23:10 -0500, Jeff Garzik wrote:
> Nigel Cunningham wrote:
> > Hi.
> > 
> > On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> >> Nigel Cunningham wrote:
> >>> Hi.
> >>>
> >>> I've have git trees against a few versions besides Linus', and have just
> >>> moved all but Linus' to staging to help until you can get your new
> >>> hardware. If others were encouraged to do the same, it might help a lot?
> >>>
> >> Not really.  In fact, it would hardly help at all.
> >>
> >> The two things git users can do to help is:
> >>
> >> 1. Make sure your alternatives file is set up correctly;
> >> 2. Keep your trees packed and pruned, to keep the file count down.
> >>
> >> If you do this, the load imposed by a single git tree is fairly negible.
> > 
> > Sorry for the slow reply, and the ignorance... what's an alternatives
> > file? I've never heard of them before.
> 
> It's highly useful but poorly documented method of referencing 
> repository B's objects from repository A.
> 
> When you clone locally
> 
>   git clone --reference linus-2.6 linus-2.6 nigel-2.6
> 
> it will create nigel-2.6 with zero objects, and an alternatives file 
> pointing to 'linus-2.6' local repository.  When you commit, only the 
> objects not already in linus-2.6 will be found in nigel-2.6.
> 
> It's far better "git clone -l ..." because you don't even have the 
> additional hardlinked inodes, and don't have to run "git relink" locally.

Cool. I'll have a play :)

Thanks!

Nigel

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Linus Torvalds]

On Sat, 6 Jan 2007, Jeff Garzik wrote:
> 
> Also, I wonder if "git push" will push only the non-linux-2.6.git objects, if
> both local and remote sides have the proper alternatives set up?

Yes.

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

Re: kernel + gcc 4.1 = several problems

[Denis Vlasenko]

On Thursday 04 January 2007 18:37, Linus Torvalds wrote:
> With 7+ million lines of C code and headers, I'm not interested in 
> compilers that read the letter of the law. We don't want some really 
> clever code generation that gets us .5% on some unrealistic load. We want 
> good _solid_ code generation that does the obvious thing.
> 
> Compiler writers seem to seldom even realize this. A lot of commercial 
> code gets shipped with basically no optimizations at all (or with specific 
> optimizations turned off), because people want to ship what they debug and 
> work with.

I'd say "care about obvious, safe optimizations which we still not do".
I want this:

char v[4];
...
memcmp(v, "abcd", 4) == 0

compile to single cmpl on i386. This (gcc 4.1.1) is ridiculous:

.LC0:
.string "abcd"
.text
...
pushl   $4
pushl   $.LC0
pushl   $v
callmemcmp
addl$12, %esp
testl   %eax, %eax

There are tons of examples where you can improve code generation.
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Jeff Garzik]

On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:

Not really.  In fact, it would hardly help at all.

The two things git users can do to help is:

1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned, to keep the file count down.

If you do this, the load imposed by a single git tree is fairly negible.



Would kernel hackers be amenable to having their trees auto-repacked, 
and linked via alternatives to Linus's linux-2.6.git?


Looking through kernel.org, we have a ton of repositories, however 
packed, that carrying their own copies of the linux-2.6.git repo.


Also, I wonder if "git push" will push only the non-linux-2.6.git 
objects, if both local and remote sides have the proper alternatives set up?


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/

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Jeff Garzik]

Nigel Cunningham wrote:

Hi.

On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:

Nigel Cunningham wrote:

Hi.

I've have git trees against a few versions besides Linus', and have just
moved all but Linus' to staging to help until you can get your new
hardware. If others were encouraged to do the same, it might help a lot?


Not really.  In fact, it would hardly help at all.

The two things git users can do to help is:

1. Make sure your alternatives file is set up correctly;
2. Keep your trees packed and pruned, to keep the file count down.

If you do this, the load imposed by a single git tree is fairly negible.


Sorry for the slow reply, and the ignorance... what's an alternatives
file? I've never heard of them before.


It's highly useful but poorly documented method of referencing 
repository B's objects from repository A.


When you clone locally

git clone --reference linus-2.6 linus-2.6 nigel-2.6

it will create nigel-2.6 with zero objects, and an alternatives file 
pointing to 'linus-2.6' local repository.  When you commit, only the 
objects not already in linus-2.6 will be found in nigel-2.6.


It's far better "git clone -l ..." because you don't even have the 
additional hardlinked inodes, and don't have to run "git relink" locally.


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/

Re: [PATCH] Discuss a couple common errors in kernel-doc usage.

[Randy Dunlap]

On Fri, 5 Jan 2007 10:03:53 -0500 (EST) Robert P. J. Day wrote:

> 
>   Explain a couple of the most common errors in kernel-doc usage.
> 
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

Acked-by: Randy Dunlap <[EMAIL PROTECTED]>

It seems that you have been looking at my kdoc todo list


> ---
> 
>   seems useful to emphasize these issues since they occur occasionally
> in the source.
> 
> diff --git a/Documentation/kernel-doc-nano-HOWTO.txt 
> b/Documentation/kernel-doc-nano-HOWTO.txt
> index 284e7e1..ba50129 100644
> --- a/Documentation/kernel-doc-nano-HOWTO.txt
> +++ b/Documentation/kernel-doc-nano-HOWTO.txt
> @@ -107,10 +107,14 @@ The format of the block comment is like this:
>   * (section header: (section description)? )*
>  (*)?*/
> 
> -The short function description cannot be multiline, but the other
> -descriptions can be (and they can contain blank lines). Avoid putting a
> -spurious blank line after the function name, or else the description will
> -be repeated!
> +The short function description ***cannot be multiline***, but the other
> +descriptions can be (and they can contain blank lines).  If you continue
> +that initial short description onto a second line, that second line will
> +appear further down at the beginning of the description section, which is
> +almost certainly not what you had in mind.
> +
> +Avoid putting a spurious blank line after the function name, or else the
> +description will be repeated!
> 
>  All descriptive text is further processed, scanning for the following special
>  patterns, which are highlighted appropriately.
> @@ -121,6 +125,31 @@ patterns, which are highlighted appropriately.
>  '@parameter' - name of a parameter
>  '%CONST' - name of a constant.
> 
> +NOTE 1:  The multi-line descriptive text you provide does *not* recognize
> +line breaks, so if you try to format some text nicely, as in:
> +
> +  Return codes
> +0 - cool
> +1 - invalid arg
> +2 - out of memory
> +
> +this will all run together and produce:
> +
> +  Return codes 0 - cool 1 - invalid arg 2 - out of memory
> +
> +NOTE 2:  If the descriptive text you provide has lines that begin with
> +some phrase followed by a colon, each of those phrases will be taken as
> +a new section heading, which means you should similarly try to avoid text
> +like:
> +
> +  Return codes:
> +0: cool
> +1: invalid arg
> +2: out of memory
> +
> +every line of which would start a new section.  Again, probably not
> +what you were after.
> +
>  Take a look around the source tree for examples.
> 
> 
> -

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Nigel Cunningham]

Hi.

On Tue, 2006-12-26 at 08:49 -0800, H. Peter Anvin wrote:
> Nigel Cunningham wrote:
> > Hi.
> > 
> > I've have git trees against a few versions besides Linus', and have just
> > moved all but Linus' to staging to help until you can get your new
> > hardware. If others were encouraged to do the same, it might help a lot?
> > 
> 
> Not really.  In fact, it would hardly help at all.
> 
> The two things git users can do to help is:
> 
> 1. Make sure your alternatives file is set up correctly;
> 2. Keep your trees packed and pruned, to keep the file count down.
> 
> If you do this, the load imposed by a single git tree is fairly negible.

Sorry for the slow reply, and the ignorance... what's an alternatives
file? I've never heard of them before.

Regards,

Nigel

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

Re: RTC subsystem and fractions of seconds

[David Brownell]

> > Hmm ... "looping" fights against "quickly"; as would "wait for next
> > update IRQ" (on RTCs that support that).  But it would improve precision,
> > at least in the sense of having the system clock and that RTC spending
> > less time with the lowest "seconds" digit disagreeing.
> > 
> > This is something you could write a patch for, n'est-ce pas?
>
> If you're thinking of going that way,

Philippe seemed to be ...


>   it'd be courteous to CC Matt,
> who devoted some effort to removing just that loop in 2.6.17 ;)

Hmm ... "git whatchanged drivers/rtc/hctosys.c" shows no such change.
So I can't find any record of such a change or its rationale.


- dave


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

Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups

[Jesper Juhl]

On 07/01/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote:

On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote:

> On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote:
>
> > Hi all,
> > I'm not able to find the DAC960 block driver maintainer. If someones knows
> > please reply :).
>
> It's orphaned.  Andrew can decide to merge this, or one of the
> storage or block maintainers could possibly do that.
> or it could go thru KJ, but then Andrew may still end up
> merging it.

Should Kernel janitors then care of cleaning orphaned files ?.
If so, I should forward it to Andrew Morton without CCing LKML again, right ?



Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups

[Jesper Juhl]

On 07/01/07, Ahmed S. Darwish <[EMAIL PROTECTED]> wrote:

On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote:

> On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote:
>
> > Hi all,
> > I'm not able to find the DAC960 block driver maintainer. If someones knows
> > please reply :).
>
> It's orphaned.  Andrew can decide to merge this, or one of the
> storage or block maintainers could possibly do that.
> or it could go thru KJ, but then Andrew may still end up
> merging it.

Should Kernel janitors then care of cleaning orphaned files ?.
If so, I should forward it to Andrew Morton without CCing LKML again, right ?



Sending the patch to LKML and Cc'ing Andrew and KJ would be my approach.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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 1/2 v4] sysrq: showBlockedTasks is sysrq-W

[Dave Jones]

On Sat, Jan 06, 2007 at 06:36:28PM -0800, Randy Dunlap wrote:
 > On Sat, 6 Jan 2007 19:09:45 -0500 Dave Jones wrote:
 > 
 > > On Sat, Jan 06, 2007 at 02:04:24PM -0800, Randy Dunlap wrote:
 > > 
 > >  > +   .help_msg   = "showBlockedTasks(W)",
 > > 
 > > Why not the same scheme as the existing help msgs..
 > 
 > Yes.  Thanks.
 > 
 > > shoWblockedtasks  ?
 > 
 > Would shoW-blocked-tasks be OK?

Works for me.

thanks,

Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] faster vgetcpu using sidt

[dean gaudet]

below is a patch which improves vgetcpu latency on all x86_64 
implementations i've tested.

Nathan Laredo pointed out the sgdt/sidt/sldt instructions are 
userland-accessible and we could use their limit fields to tuck away a few 
bits of per-cpu information.

vgetcpu generally uses lsl at present, but all of sgdt/sidt/sldt are 
faster than lsl on all x86_64 processors i've tested.  on p4 processers 
lsl tends to be 150 cycles whereas the s*dt instructions are 15 cycles or 
less.  lsl requires microcoded permission testing whereas s*dt are free 
of any such hassle.

sldt is the least expensive of the three instructions however it's a 
hassle to use because processes may want to adjust their ldt.  sidt/sgdt 
have essentially the same performance across all the major architectures 
-- however sidt has the advantage that its limit field is 16-bits, yet any 
value >= 0xfff is essentially "infinite" because there are only 256 (16 
byte) descriptors.  so sidt is probably the best choice of the three.

in benchmarking i've discovered the rdtscp implementation of vgetcpu is 
slower than even the lsl-based implementation on opteron revF.  so i've 
dropped the rdtscp implementation in this patch.  however i've left the 
rdtscp_aux register initialized because i'm sure it's the right choice for 
various proposed vgettimeofday / per-cpu tsc state improvements which need 
the atomic nature of the rdtscp instruction and i hope it'll be used in 
those situations.

at compile time this patch detects if 0x1000 + 
(CONFIG_NR_CPUS

-dean

Signed-off-by: dean gaudet <[EMAIL PROTECTED]>

Index: linux/arch/x86_64/kernel/time.c
===
--- linux.orig/arch/x86_64/kernel/time.c2007-01-06 13:31:10.0 
-0800
+++ linux/arch/x86_64/kernel/time.c 2007-01-06 16:04:01.0 -0800
@@ -957,11 +957,6 @@
if (unsynchronized_tsc())
notsc = 1;
 
-   if (cpu_has(_cpu_data, X86_FEATURE_RDTSCP))
-   vgetcpu_mode = VGETCPU_RDTSCP;
-   else
-   vgetcpu_mode = VGETCPU_LSL;
-
if (vxtime.hpet_address && notsc) {
timetype = hpet_use_timer ? "HPET" : "PIT/HPET";
if (hpet_use_timer)
Index: linux/arch/x86_64/kernel/vsyscall.c
===
--- linux.orig/arch/x86_64/kernel/vsyscall.c2007-01-06 13:31:10.0 
-0800
+++ linux/arch/x86_64/kernel/vsyscall.c 2007-01-06 17:29:36.0 -0800
@@ -40,13 +40,18 @@
 #include 
 #include 
 #include 
+#include 
 
 #define __vsyscall(nr) __attribute__ ((unused,__section__(".vsyscall_" #nr)))
 #define __syscall_clobber "r11","rcx","memory"
 
 int __sysctl_vsyscall __section_sysctl_vsyscall = 1;
 seqlock_t __xtime_lock __section_xtime_lock = SEQLOCK_UNLOCKED;
-int __vgetcpu_mode __section_vgetcpu_mode;
+
+/* is this necessary? */
+#ifndef CONFIG_NODES_SHIFT
+#define CONFIG_NODES_SHIFT 0
+#endif
 
 #include 
 
@@ -147,11 +152,21 @@
 long __vsyscall(2)
 vgetcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *tcache)
 {
-   unsigned int dummy, p;
+   unsigned int p;
+#ifdef VGETCPU_USE_SIDT
+   struct {
+   char pad[6];/* avoid unaligned stores */
+   u16 size;
+   u64 address;
+   } idt;
+
+   asm("sidt %0" : "=m" (idt.size));
+   p = idt.size - 0x1000;
+#else
unsigned long j = 0;
 
/* Fast cache - only recompute value once per jiffies and avoid
-  relatively costly rdtscp/cpuid otherwise.
+  relatively costly lsl otherwise.
   This works because the scheduler usually keeps the process
   on the same CPU and this syscall doesn't guarantee its
   results anyways.
@@ -160,21 +175,20 @@
   If you don't like it pass NULL. */
if (tcache && tcache->blob[0] == (j = __jiffies)) {
p = tcache->blob[1];
-   } else if (__vgetcpu_mode == VGETCPU_RDTSCP) {
-   /* Load per CPU data from RDTSCP */
-   rdtscp(dummy, dummy, p);
-   } else {
+   }
+   else {
/* Load per CPU data from GDT */
asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+   if (tcache) {
+   tcache->blob[0] = j;
+   tcache->blob[1] = p;
+   }
}
-   if (tcache) {
-   tcache->blob[0] = j;
-   tcache->blob[1] = p;
-   }
+#endif
if (cpu)
-   *cpu = p & 0xfff;
+   *cpu = p >> CONFIG_NODES_SHIFT;
if (node)
-   *node = p >> 12;
+   *node = p & ((1<> 4) << 48;
+  in user space in vgetcpu. */
+   {
+   unsigned long *d;
+   d = (unsigned long *)(cpu_gdt(cpu) + GDT_ENTRY_PER_CPU);
+   *d = 0x0f400ULL;
+   *d |= cpu_node_encoding & 0x;
+

[PATCH 1/2 v4] sysrq: showBlockedTasks is sysrq-W

[Randy Dunlap]

On Sat, 6 Jan 2007 19:09:45 -0500 Dave Jones wrote:

> On Sat, Jan 06, 2007 at 02:04:24PM -0800, Randy Dunlap wrote:
> 
>  > +  .help_msg   = "showBlockedTasks(W)",
> 
> Why not the same scheme as the existing help msgs..

Yes.  Thanks.

> shoWblockedtasks  ?

Would shoW-blocked-tasks be OK?

---
From: Randy Dunlap <[EMAIL PROTECTED]>

Change SysRq showBlockedTasks from sysrq-X to sysrq-W and show that
in the Help message.

It was previously done via X, but X is already used for Xmon
on ppc & powerpc platforms and this collision needs to be avoided.

All callers of register_sysrq_key() are now marked in the
sysrq op/key table.  I didn't mark 'h' as Help because Help
is just printed for any unknown key, such as '?'.

Added some omitted sysrq key entries in the sysrq.txt file.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 Documentation/sysrq.txt |   66 +---
 drivers/char/sysrq.c|   20 --
 2 files changed, 46 insertions(+), 40 deletions(-)

--- linux-2620-rc3g4.orig/drivers/char/sysrq.c
+++ linux-2620-rc3g4/drivers/char/sysrq.c
@@ -215,7 +215,7 @@ static void sysrq_handle_showstate_block
 }
 static struct sysrq_key_op sysrq_showstate_blocked_op = {
.handler= sysrq_handle_showstate_blocked,
-   .help_msg   = "showBlockedTasks",
+   .help_msg   = "shoW-blocked-tasks",
.action_msg = "Show Blocked State",
.enable_mask= SYSRQ_ENABLE_DUMP,
 };
@@ -315,15 +315,16 @@ static struct sysrq_key_op *sysrq_key_ta
_loglevel_op, /* 9 */
 
/*
-* Don't use for system provided sysrqs, it is handled specially on
-* sparc and will never arrive
+* a: Don't use for system provided sysrqs, it is handled specially on
+* sparc and will never arrive.
 */
NULL,   /* a */
_reboot_op,   /* b */
-   _crashdump_op,/* c */
+   _crashdump_op,/* c & ibm_emac driver debug */
_showlocks_op,/* d */
_term_op, /* e */
_moom_op, /* f */
+   /* g: May be registered by ppc for kgdb */
NULL,   /* g */
NULL,   /* h */
_kill_op, /* i */
@@ -332,18 +333,19 @@ static struct sysrq_key_op *sysrq_key_ta
NULL,   /* l */
_showmem_op,  /* m */
_unrt_op, /* n */
-   /* This will often be registered as 'Off' at init time */
+   /* o: This will often be registered as 'Off' at init time */
NULL,   /* o */
_showregs_op, /* p */
NULL,   /* q */
-   _unraw_op,/* r */
+   _unraw_op,/* r */
_sync_op, /* s */
_showstate_op,/* t */
_mountro_op,  /* u */
-   /* May be assigned at init time by SMP VOYAGER */
+   /* v: May be registered at init time by SMP VOYAGER */
NULL,   /* v */
-   NULL,   /* w */
-   _showstate_blocked_op,/* x */
+   _showstate_blocked_op,/* w */
+   /* x: May be registered on ppc/powerpc for xmon */
+   NULL,   /* x */
NULL,   /* y */
NULL/* z */
 };
--- linux-2620-rc3g4.orig/Documentation/sysrq.txt
+++ linux-2620-rc3g4/Documentation/sysrq.txt
@@ -1,6 +1,6 @@
 Linux Magic System Request Key Hacks
-Documentation for sysrq.c version 1.15
-Last update: $Date: 2001/01/28 10:15:59 $
+Documentation for sysrq.c
+Last update: 2007-JAN-06
 
 *  What is the magic SysRq key?
 ~~~
@@ -35,7 +35,7 @@ You can set the value in the file by the
 
 Note that the value of /proc/sys/kernel/sysrq influences only the invocation
 via a keyboard. Invocation of any operation via /proc/sysrq-trigger is always
-allowed.
+allowed (by a user with admin privileges).
 
 *  How do I use the magic SysRq key?
 
@@ -58,7 +58,7 @@ On PowerPC - Press 'ALT - Print Screen (
 On other - If you know of the key combos for other architectures, please
let me know so I can add them to this section.
 
-On all -  write a character to /proc/sysrq-trigger.  eg:
+On all -  write a character to /proc/sysrq-trigger.  e.g.:
 
echo t > /proc/sysrq-trigger
 
@@ -74,6 +74,8 @@ On all -  write a character to /proc/sys
 
 'c'- Will perform a kexec reboot in order to take a crashdump.
 
+'d'- Shows all locks that are held.
+
 'o' - Will shut your system off (if configured and supported).
 
 's' - Will attempt to sync all mounted filesystems.
@@ -87,38 +89,43 @@ On all -  write a character to /proc/sys
 
 'm' - 

Re: BUG: warning at mm/truncate.c:60/cancel_dirty_page()

[Sami Farin]

On Sat, Jan 06, 2007 at 21:11:07 +, Hugh Dickins wrote:
> On Sat, 6 Jan 2007, Sami Farin wrote:
> 
> > Linux 2.6.19.1 SMP [2] on Pentium D...
> > I was running dt-15.14 [2] and I ran
> > "cinfo datafile" (it does mincore()).
> > Well it went OK but when I ran "strace cinfo datafile"...:
> > 04:18:48.062466 mincore(0x37f1f000, 2147266560, 
> 
> You rightly noted in a followup that there have been changes to
> mincore, but I doubt they have any bearing on this: I think the
> BUG just happened at the same time as your mincore.

BUG does not happen if I do not do "strace cinfo dtfile" with O_DIRECT
test file.  It's easy to reproduce.
Without strace BUG does not happen.

Now I got it again, with also the mincore patch applied:

01:48:42.831060 mincore(0x37ff1000, 2147254272, ^[

2007-01-07 01:48:51.480531500 <4>BUG: warning at 
mm/truncate.c:60/cancel_dirty_page()
2007-01-07 01:48:51.480532500 <4> [] dump_trace+0x215/0x21a
2007-01-07 01:48:51.480557500 <4> [] show_trace_log_lvl+0x1a/0x30
2007-01-07 01:48:51.480559500 <4> [] show_trace+0x12/0x14
2007-01-07 01:48:51.480560500 <4> [] dump_stack+0x19/0x1b
2007-01-07 01:48:51.480561500 <4> [] cancel_dirty_page+0x7e/0x80
2007-01-07 01:48:51.480562500 <4> [] truncate_complete_page+0x1a/0x47
2007-01-07 01:48:51.480563500 <4> [] 
truncate_inode_pages_range+0x114/0x2ae
2007-01-07 01:48:51.480564500 <4> [] truncate_inode_pages+0x1a/0x1c
2007-01-07 01:48:51.480574500 <4> [] fs_flushinval_pages+0x40/0x77
2007-01-07 01:48:51.480575500 <4> [] xfs_write+0x8c4/0xb68
2007-01-07 01:48:51.480576500 <4> [] xfs_file_aio_write+0x7e/0x95
2007-01-07 01:48:51.480577500 <4> [] do_sync_write+0xca/0x119
2007-01-07 01:48:51.480578500 <4> [] vfs_write+0x187/0x18c
2007-01-07 01:48:51.480579500 <4> [] sys_write+0x3d/0x64
2007-01-07 01:48:51.480589500 <4> [] syscall_call+0x7/0xb
2007-01-07 01:48:51.480590500 <4> [<00bed410>] 0xbed410

$ /sbin/sysctl -n vm.dirty_expire_centisecs
999

cancel_dirty_page would be more useful if it executed WARN_ON
at max once per 10s or something instead of five times out of 2^32 or 2^64
errors...  I mean, user might think program/kernel started to work OK when
BUGs stop if he/she doesn't check cancel_dirty_page() function.


--- linux-2.6.19/mm/truncate.c.bak  2007-01-01 19:10:00.62731 +0200
+++ linux-2.6.19/mm/truncate.c  2007-01-07 02:35:53.786636897 +0200
@@ -55,11 +55,16 @@ void cancel_dirty_page(struct page *page
 {
/* If we're cancelling the page, it had better not be mapped any more */
if (page_mapped(page)) {
-   static unsigned int warncount;
+   static int first = 1;
+   static unsigned long lastwarn;
 
-   WARN_ON(++warncount < 5);
+   if (unlikely(first) || time_after(jiffies, (lastwarn + 10*HZ))) 
{
+   first = 0;
+   lastwarn = jiffies;
+   WARN_ON(42);
+   }
}
-   
+
if (TestClearPageDirty(page)) {
struct address_space *mapping = page->mapping;
if (mapping && mapping_cap_account_dirty(mapping)) {


> > ...
> > 2007-01-06 04:19:03.788181500 <4>BUG: warning at 
> > mm/truncate.c:60/cancel_dirty_page()
> > 2007-01-06 04:19:03.788221500 <4> [] dump_trace+0x215/0x21a
> > 2007-01-06 04:19:03.788223500 <4> [] show_trace_log_lvl+0x1a/0x30
> > 2007-01-06 04:19:03.788224500 <4> [] show_trace+0x12/0x14
> > 2007-01-06 04:19:03.788225500 <4> [] dump_stack+0x19/0x1b
> > 2007-01-06 04:19:03.788227500 <4> [] cancel_dirty_page+0x7e/0x80
> > 2007-01-06 04:19:03.788228500 <4> [] 
> > truncate_complete_page+0x1a/0x47
> > 2007-01-06 04:19:03.788229500 <4> [] 
> > truncate_inode_pages_range+0x114/0x2ae
> > 2007-01-06 04:19:03.788245500 <4> [] 
> > truncate_inode_pages+0x1a/0x1c
> > 2007-01-06 04:19:03.788247500 <4> [] fs_flushinval_pages+0x40/0x77
> > 2007-01-06 04:19:03.788248500 <4> [] xfs_write+0x8c4/0xb68
> > 2007-01-06 04:19:03.788250500 <4> [] xfs_file_aio_write+0x7e/0x95
> > 2007-01-06 04:19:03.788251500 <4> [] do_sync_write+0xca/0x119
> > 2007-01-06 04:19:03.788265500 <4> [] vfs_write+0x187/0x18c
> > 2007-01-06 04:19:03.788267500 <4> [] sys_write+0x3d/0x64
> > 2007-01-06 04:19:03.788268500 <4> [] syscall_call+0x7/0xb
> > 2007-01-06 04:19:03.788269500 <4> [<001cf410>] 0x1cf410
> > 2007-01-06 04:19:03.788289500 <4> ===
> 
> So... XFS uses truncate_inode_pages when serving the write system call.
> That's very inventive, and now it looks like Linus' cancel_dirty_page
> and new warning have caught it out.  VM people expect it to be called
> either when freeing an inode no longer in use, or when doing a truncate,
> after ensuring that all pages mapped into userspace have been taken out.

Maybe XFS people can tell is their code doing something unwise?

And about my earlier xfs_freeze issue... =)

...
> Gosh.  Might be better to reproduce it on 2.6.20-rc3;

Well those were not all the patches =)
I have spent so many days with 2.6.18 

Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups

[Randy Dunlap]

On Sun, 7 Jan 2007 04:00:10 +0200 Ahmed S. Darwish wrote:

> On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote:
> 
> > On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote:
> > 
> > > Hi all,
> > > I'm not able to find the DAC960 block driver maintainer. If someones knows
> > > please reply :).
> > 
> > It's orphaned.  Andrew can decide to merge this, or one of the
> > storage or block maintainers could possibly do that.
> > or it could go thru KJ, but then Andrew may still end up
> > merging it.
> 
> Should Kernel janitors then care of cleaning orphaned files ?.

Kernel janitors could do that (IMO).  It's up to you where you want
to send the patch.

> If so, I should forward it to Andrew Morton without CCing LKML again, right ?

I would expect that Andrew has seen the patch.  Anyway, you should
always send the patch to a mailing list and usually to a specific
maintainer also (like Andrew or a subsystem maintainer or the KJ
maintainer).  [except for some security-related patches]

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

Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups

[Alan]

> Should Kernel janitors then care of cleaning orphaned files ?.

If you have the hardware to run tests then yes, if not then they are best
handled with caution. Working is preferred to pretty.

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: qconf handling NULL pointers

[Roman Zippel]

Hi,

On Saturday 06 January 2007 12:44, Cyrill V. Gorcunov wrote:

> I found qconf have a few malloc(), strdup() without any check for NULL
> returned code. May be it should be fixed? Am I wrong?

The code isn't really supposed to deal with it, at most they could be replaced 
with a variant that prints an error message and exits.

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

sonypi not for 64bit?

[Jan Engelhardt]

Hi sonypi (ex-)maintainers ;-)


drivers/char/Kconfig lists SONYPI as being !64BIT, however, there seem 
to be sony users with x86_64 [1] around. Is it just caution (it's also 
marked EXPERIMENTAL) or is it definitely known to break on 64bit?

-`J'

[1] (a german forum) 
http://www.linux-club.de/viewtopic.php?t=74400=sonypi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] atiixp.c: add cable detection support for ATI IDE

[Bartlomiej Zolnierkiewicz]

On 1/6/07, Conke Hu <[EMAIL PROTECTED]> wrote:

IDE HDD does not work if it uses a 40-pin PATA cable on ATI chipset.
This patch fixes the bug.

Signed-off-by: Conke Hu <[EMAIL PROTECTED]>


Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

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

Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values

[Roman Zippel]

Hi,

On Thu, 4 Jan 2007, Al Viro wrote:

> PS: what would be the sane strategy for timer series merge, BTW?

PPS: I still don't like it. It fixes a rather theoretical problem with 
absolutely no practical relevance.
PPPS: type safety is also possible with container_of(), the prototype 
patch below demonstrates how to check that the signature matches and 
additionally it doesn't require to convert everything at once. More 
sophisticated checks can be done by putting this information into a 
separate section, from where it can be extracted at compile/run time.

bye, Roman

---
 include/linux/timer.h |   24 
 kernel/timer.c|   18 +-
 kernel/workqueue.c|   24 ++--
 3 files changed, 51 insertions(+), 15 deletions(-)

Index: linux-2.6-git/include/linux/timer.h
===
--- linux-2.6-git.orig/include/linux/timer.h2007-01-06 20:45:02.0 
+0100
+++ linux-2.6-git/include/linux/timer.h 2007-01-06 21:00:07.0 +0100
@@ -13,16 +13,40 @@ struct timer_list {
 
void (*function)(unsigned long);
unsigned long data;
+   unsigned long _sig;
 
struct tvec_t_base_s *base;
 };
 
+#define __timer_sig(type, member) ((offsetof(type, member) << 16) | 
sizeof(type))
+
+#define __TIMER_OLD_SIG(0xa5005a)
+
+typedef void timer_cb_t(struct timer_list *);
+
+extern void __timer_init(struct timer_list *t, timer_cb_t *func, long sig);
+
+#define timer_init(ptr, member, func)  \
+   __timer_init(&(ptr)->member, func,  \
+__timer_sig(typeof(*ptr), member))
+
+#define timer_of(ptr, type, member) ({ \
+   const struct timer_list *_t = (ptr);\
+   if (_t->_sig != __timer_sig(type, member)) {\
+   WARN_ON(_t->_sig != -__timer_sig(type, member));\
+   return; \
+   }   \
+   container_of(ptr, type, member);\
+})
+
+
 extern struct tvec_t_base_s boot_tvec_bases;
 
 #define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires),  \
.data = (_data),\
+   ._sig = __TIMER_OLD_SIG,\
.base = _tvec_bases,   \
}
 
Index: linux-2.6-git/kernel/timer.c
===
--- linux-2.6-git.orig/kernel/timer.c   2007-01-06 20:45:02.0 +0100
+++ linux-2.6-git/kernel/timer.c2007-01-06 21:00:07.0 +0100
@@ -226,6 +226,11 @@ static void internal_add_timer(tvec_base
unsigned long idx = expires - base->timer_jiffies;
struct list_head *vec;
 
+   if (!timer->_sig) {
+   WARN_ON(1);
+   timer->_sig = __TIMER_OLD_SIG;
+   }
+
if (idx < TVR_SIZE) {
int i = expires & TVR_MASK;
vec = base->tv1.vec + i;
@@ -271,11 +276,22 @@ static void internal_add_timer(tvec_base
  */
 void fastcall init_timer(struct timer_list *timer)
 {
+   timer->_sig = __TIMER_OLD_SIG;
timer->entry.next = NULL;
timer->base = __raw_get_cpu_var(tvec_bases);
 }
 EXPORT_SYMBOL(init_timer);
 
+extern void __timer_init(struct timer_list *t, timer_cb_t *func, long sig)
+{
+   t->function = (void *)func;
+   t->_sig = -sig;
+   func(t);
+   t->_sig = sig;
+   t->entry.next = NULL;
+   t->base = __raw_get_cpu_var(tvec_bases);
+}
+
 static inline void detach_timer(struct timer_list *timer,
int clear_pending)
 {
@@ -567,7 +583,7 @@ static inline void __run_timers(tvec_bas
 
timer = list_entry(head->next,struct timer_list,entry);
fn = timer->function;
-   data = timer->data;
+   data = timer->_sig == __TIMER_OLD_SIG ? timer->data : 
(unsigned long)timer;
 
set_running_timer(base, timer);
detach_timer(timer, 1);
Index: linux-2.6-git/kernel/workqueue.c
===
--- linux-2.6-git.orig/kernel/workqueue.c   2007-01-06 19:51:40.0 
+0100
+++ linux-2.6-git/kernel/workqueue.c2007-01-06 21:02:59.0 +0100
@@ -218,9 +218,9 @@ int fastcall queue_work(struct workqueue
 }
 EXPORT_SYMBOL_GPL(queue_work);
 
-static void delayed_work_timer_fn(unsigned long __data)
+static void delayed_work_timer_fn(struct timer_list *timer)
 {
-   struct delayed_work *dwork = (struct delayed_work *)__data;
+   struct delayed_work *dwork = timer_of(timer, struct 

Re: [PATCH 2/3] atiixp.c: sb600 ide only has one channel

[Bartlomiej Zolnierkiewicz]

On 1/6/07, Conke Hu <[EMAIL PROTECTED]> wrote:

AMD/ATI SB600 IDE/PATA controller only has one channel.

Signed-off-by: Conke Hu <[EMAIL PROTECTED]>


Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

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

Re: [PATCH 1/3] atiixp.c: remove unused code

[Bartlomiej Zolnierkiewicz]

On 1/6/07, Conke Hu <[EMAIL PROTECTED]> wrote:

A previous patch to atiixp.c was removed but some code has not been


This one?

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ab17443a3df35abe4b7529e83511a591aa7384f3

Doesn't it break existing setups without giving ANY warning?

theoretical (I don't have hardware in question) scenario:
- user uses atiixp and has modular libata/ahci (or no libata/ahci et all)
- user does kernel upgrade
- boot fails
- ...

If this is true please add something like

printk(KERN_WARNING "PCI: setting SB600 SATA to AHCI mode"
" (please use ahci driver instead of atiixp)\n");

to quirk_sb600_sata() so people will at least know what is wrong...


cleaned. Now we remove these code sine they are no use any longer.


Acked-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>

[ but the patch is line wrapped and unfortunately doesn't apply ]

PS: please always cc: linux-ide@vger.kernel.org on PATA/SATA patches

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] HZ free ntp

[Roman Zippel]

Hi,

On Tuesday 02 January 2007 20:42, john stultz wrote:

> > tick_nsec doesn't require special treatment, in the middle term it's
> > obsolete anyway, it could be replaced with (current_tick_length() >>
> > TICK_LENGTH_SHIFT) and current_tick_length() being inlined.
>
> If NTP_INTERVAL_FREQ is different then HZ, then tick_nsec still has a
> different meaning then (current_tick_length() >> TICK_LENGTH_SHIFT).
> So since tick_nsec is still used in quite a few places, so I'm hesitant
> to pull it.

The current usage under arch is pretty much bogus and they likely can't use 
dyntick anyway, so it would be easier to disable tick_nsec completely if 
dyntick is enabled.

> > NTP_INTERVAL_FREQ could be a real variable (so it can be initialized at
> > runtime), it's already gone from all important paths.
>
> Wait, so you're suggesting NTP_INTERVAL_FREQ be a dynamic variable
> instead of a constant? Curious, could you give a bit more detail on why?

We already have more than enough config options, where the user has barely any 
idea what to do, so we should try to configure and initialize as much as 
possible at runtime depending on what the hardware is capable of.

That reminds me that the main problem left for a dynamic variable is 
time_offset. It should become a 64 bit value, so SHIFT_UPDATE isn't needed 
anymore. Right now it depends on HZ to maximize the value range.

> > In the short term I'd prefered a clock would store its frequency instead
> > of using NTP_INTERVAL_LENGTH in clocksource_calculate_interval(), so it
> > doesn't has to be derived there.
>
> I don't follow this at all. clocksources do store their own frequency
> (via mult/shift). Could you explain?

mult is not a constant and calculating the frequency like this is not very 
precise.

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

Re: [RFC] HZ free ntp

[Roman Zippel]

Hi,

On Tuesday 02 January 2007 21:50, john stultz wrote:

> > > It should be called every NTP_INTERVAL_FREQ times, but occasionally
> > > it's off
>
> Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
> (instead of every second)? Surely that's not right.

But it is, that's the reason the various adjustment values are divided by it, 
so they are applied to the next NTP_INTERVAL_FREQ times.

BTW I think NTP_INTERVAL_FREQ isn't the right name, CLOCK_UPDATE_FREQ would be 
a better name, currently ntp is the main user, but a clock can also be 
updated via other means (e.g. adjtimex or another clock).

> > > So in this case the loop in update_wall_time() should rather look like
> > > this:
> > >
> > >   while (offset >= clock->cycle_interval) {
> > >   ...
> > >   second_overflow();
> > >   while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
> > >   clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
> > >   xtime.tv_sec++;
> > >   }
> > >   ...
> > >   }
> > >
> > > (Also note the change from "if" to "while".)
>
> This would assume that clock->cycle_interval would *always* be the
> length of a full second and that isn't what the patch trying to do.
>
> Maybe could you explain this some more?

As I said this was the case for a value of one.
Anyway, to avoid these problems, I'd prefer to keep it at least at 2 or better 
at 4. This would still drastically reduce the time spent in the loop and we 
can revisit the issue later.

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

Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

[Tom Lanyon]

On 12/27/06, Linus Torvalds <[EMAIL PROTECTED]> wrote:

What would also actually be interesting is whether somebody can reproduce
this on Reiserfs, for example. I _think_ all the reports I've seen are on
ext2 or ext3, and if this is somehow writeback-related, it could be some
bug that is just shared between the two by virtue of them still having a
lot of stuff in common.

Linus


I've been following this thread for a while now as I started
experiencing file corruption in rtorrent when I upgraded to 2.6.19. I
am using reiserfs.

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

Re: [PATCH 2.6.20-rc3] DAC960: kmalloc->kzalloc/Casting cleanups

[Ahmed S. Darwish]

On Sat, Jan 06, 2007 at 09:46:30AM -0800, Randy Dunlap wrote:

> On Sat, 6 Jan 2007 15:17:25 +0200 Ahmed S. Darwish wrote:
> 
> > Hi all,
> > I'm not able to find the DAC960 block driver maintainer. If someones knows
> > please reply :).
> 
> It's orphaned.  Andrew can decide to merge this, or one of the
> storage or block maintainers could possibly do that.
> or it could go thru KJ, but then Andrew may still end up
> merging it.

Should Kernel janitors then care of cleaning orphaned files ?.
If so, I should forward it to Andrew Morton without CCing LKML again, right ?

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

Re: RTC subsystem and fractions of seconds

[Hugh Dickins]

On Sat, 6 Jan 2007, David Brownell wrote:
> On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote:
> 
> > The way it is done currently 
> > in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
> > precision by looping there until the next change (next second for old 
> > clocks,
> > next 0.01 second for m41t81, maybe even better for other ones).
> 
> Hmm ... "looping" fights against "quickly"; as would "wait for next
> update IRQ" (on RTCs that support that).  But it would improve precision,
> at least in the sense of having the system clock and that RTC spending
> less time with the lowest "seconds" digit disagreeing.
> 
> This is something you could write a patch for, n'est-ce pas?

If you're thinking of going that way, it'd be courteous to CC Matt,
who devoted some effort to removing just that loop in 2.6.17 ;)

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] paravirt: isolate module ops

[Rusty Russell]

On Sat, 2007-01-06 at 12:55 -0800, Zachary Amsden wrote:
> Rusty Russell wrote:
> >
> > +int paravirt_write_msr(unsigned int msr, u64 val);
> 
> If binary modules using debug registers makes us nervous, the 
> reprogramming MSRs is also similarly bad.

Yes, but this is simply from experience.  Several modules wrote msrs
(you can take out the EXPORT_SYMBOL and find them quite quickly).

> > +void raw_safe_halt(void);
> > +void halt(void);
> 
> These shouldn't be done by modules, ever.  Only the scheduler should 
> decide to halt.

Several modules implement alternate halt loops.  I guess being in a
module for specific CPUs makes sense...

Cheers!
Rusty.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 + gcc 4.1 = several problems

[Alistair John Strachan]

On Sunday 07 January 2007 00:36, Pavel Machek wrote:
[snip]
> > However, this patch is mostly useless if you have a separate stack for
> > IRQ's (since if that happens, any interrupt will be taken on a different
> > stack which we don't see any more), so you should NOT enable the 4KSTACKS
> > config option if you try this out.
>
> stupid idea... perhaps gcc-4.1 generates bigger stackframe somewhere,
> and stack overflows?

The primary reason it's not 4KSTACKS already is that I run multiple XFS 
partitions on top of an md RAID 1. LVM isn't involved, however, and I'm not 
using any other filesystem overlays like dm.

I'm fairly sceptical that it's a stack overflow, but I'll be sure to enable 
the debugging option on the next try.

> that hw monitoring thingie... I'd turn it off. Its interactions with
> acpi are non-trivial and dangerous.

Well, GCC 3.4 kernels seem to run fine with it, but as I said to Linus I'll be 
sure to turn this and the sound drivers off in the next build.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 + gcc 4.1 = several problems

[Pavel Machek]

Hi!

> > (I realise with problems like these it's almost always some sort of obscure 
> > hardware problem, but I find that very difficult to believe when I can 
> > toggle 
> > from 3 years of stability to 6-18 hours crashing by switching compiler. 
> > I've 
> > also ran extensive stability test programs on the hardware with absolutely 
> > no 
> > negative results.)
> 
> The thing is, I agree with you - it does seem to be compiler-related. But 
> at the same time, I'm almost positive that it's not in "pipe_poll()" 
> itself, because that function is just too simple, and looking at the 
> assembly code, I don't see how what you describe could happen in THAT 
> function.
> 
> HOWEVER.
> 
> I can easily see an NMI coming in, or another interrupt, or something, and 
> that one corrupting the stack under it because of a compiler bug (or a 
> kernel bug that just needs a specific compiler to trigger). For example, 
> we've had problems before with the compiler thinking it owns the stack 
> frame for an "asmlinkage" function, and us having no way to tell the 
> compiler to keep its hands off - so the compiler ended up touching 
> registers that were actually in the "save area" of the interrupt or system 
> call, and then returning with corrupted state.
> 
> Here's a stupid patch. It just adds more debugging to the oops message, 
> and shows all the code pointers it can find on the WHOLE stack.
> 
> It also makes the raw stack dumping print out as much of the stack 
> contents _under_ the stack pointer as it does above it too.
> 
> However, this patch is mostly useless if you have a separate stack for 
> IRQ's (since if that happens, any interrupt will be taken on a different 
> stack which we don't see any more), so you should NOT enable the 4KSTACKS 
> config option if you try this out.

stupid idea... perhaps gcc-4.1 generates bigger stackframe somewhere,
and stack overflows?

that hw monitoring thingie... I'd turn it off. Its interactions with
acpi are non-trivial and dangerous.
Pavel
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Question on ALSA intel8x0

[J.A. Magallón]

Hi...

I have a curious issue with snd_intel8x0 ALSA driver:

Jan  7 01:14:27 werewolf-wl kernel: ACPI: PCI interrupt for device :00:1f.5 
disabled
Jan  7 01:14:27 werewolf-wl kernel: ACPI: PCI Interrupt :00:1f.5[B] -> GSI 
17 (level, low) -> IRQ 21
Jan  7 01:14:27 werewolf-wl kernel: PCI: Setting latency timer of device 
:00:1f.5 to 64
Jan  7 01:14:27 werewolf-wl kernel: AC'97 0 analog subsections not ready
Jan  7 01:14:27 werewolf-wl kernel: intel8x0_measure_ac97_clock: measured 50136 
usecs
Jan  7 01:14:27 werewolf-wl kernel: intel8x0: measured clock 219 rejected
Jan  7 01:14:27 werewolf-wl kernel: intel8x0: clocking to 48000

And this file is created:

/dev/.udev/failed/[EMAIL PROTECTED]@controlC0

What does this 'failed' mean ? Why is my card 'not ready' ?
Sound works, anyways.

BTW, before alsa driver loads, I hear a strange whisper through the speakers,
nothing since the sound subsystem is initialized. Bad connections ?

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.19-jam03 (gcc 4.1.2 20061110 (prerelease) 
(4.1.2-0.20061110.1mdv2007.1)) #0 SMP PREEMPT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [announce] [patch] KVM paravirtualization for Linux

[Pavel Machek]

Hi!

> i'm pleased to announce the first release of paravirtualized KVM (Linux 
> under Linux), which includes support for the hardware cr3-cache feature 
> of Intel-VMX CPUs. (which speeds up context switches and TLB flushes)
> 
> the patch is against 2.6.20-rc3 + KVM trunk and can be found at:
> 
>http://redhat.com/~mingo/kvm-paravirt-patches/
> 
> Some aspects of the code are still a bit ad-hoc and incomplete, but the 
> code is stable enough in my testing and i'd like to have some feedback. 
> 
> Firstly, here are some numbers:
> 
> 2-task context-switch performance (in microseconds, lower is better):
> 
>  native:   1.11
>  --
>  Qemu:61.18
>  KVM upstream:53.01
>  KVM trunk:6.36
>  KVM trunk+paravirt/cr3:   1.60

Does this make Xen obsolete? I mean... we have xen patches in suse
kernels, should we keep updating them, or just drop them in favour of
KVM?
Pavel
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc3-mm1 - rewrite-lock-in-cpufreq-to-eliminate-cpufreq-hotplug-related-issues.patch

[Valdis . Kletnieks]

On Sat, 06 Jan 2007 17:59:06 +0100, Mattia Dongili said:
> On Sat, Jan 06, 2007 at 08:44:51AM -0500, [EMAIL PROTECTED] wrote:
> > One of these 3 patches:
> > 
> > rewrite-lock-in-cpufreq-to-eliminate-cpufreq-hotplug-related-issues.patch

> Does the following help?
> 
> Signed-off-by: Mattia Dongili <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index a7b17ab..1112f31 100644

Yes, that fixes the problem.  Thanks.


pgpOAOdVbq0Gu.pgp
Description: PGP signature

Re: 2.6.20-rc3-mm1 - reiser4-sb_sync_inodes.patch causes boot hang

[Valdis . Kletnieks]

On Sat, 06 Jan 2007 11:14:21 PST, Andrew Morton said:
>
> Yeah, that's an akpm screwup, sorry.
> 
> Take a peek in
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/hot-fixes/

Confirming that reiser4-sb_sync_inodes-fix.patch fixes my problem.


pgpN1BlvAVF6Q.pgp
Description: PGP signature

Experimental driver for Ricoh Bay1Controller SD Card readers

[Sascha Sommer]

Hi,

Attached is a very experimental driver for a Ricoh SD Card reader that can be 
found in some notebooks like the Samsung P35.

Whenever a sd card is inserted into one of these notebooks, a virtual pcmcia 
card will show up:

Socket 0:
  product info: "RICOH", "Bay1Controller", "", ""
  manfid: 0x, 0x

In order to write this driver I hacked qemu to have access to the cardbus 
bridge containing this card. I then logged the register accesses of the 
windows xp driver and tryed to analyse them.

As the meanings of most of the register are still unknown to me, I consider 
this driver very experimental. It is possible that this driver might destroy 
your data or your hardware. Use at your own risk! 

Other problems:
- I only implemented reading support
- I only tested with a 128 MB SD card, no idea what would be needed to support
  other card types
- irqs are not supported
- dma is not supported
- it is very slow
- the registers can be found on the cardbus bridge and not on the virtual 
  pcmcia card. The cardbus bridge is already claimed by yenta_socket. 
  Therefore the driver currently uses pci_find_device to find the cardbus
  bridge containing the sd card reader registers.
- it will probably crash when you remove the sd card without unmounting first
- the ios stuff is not really understood
- there are a bunch of extra MMC_APP_CMDs inside the driver
- only tested with kernel 2.6.18

apart from all these problems reading an image from my sd card seems to have 
worked ;) 

If you are still brave enough to try it out make at least a backup of the data 
on your sd card.

Feedback is highly appreciated.

Regards

Sascha

KERNEL_VERSION = $(shell uname -r)
KERNEL_DIR = /lib/modules/$(KERNEL_VERSION)/build
MDIR = /lib/modules/$(KERNEL_VERSION)/kernel/drivers/mmc

obj-m += sdricoh_cs.o

default:
	$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules

install:
	if test ! -d $(MDIR) ; then mkdir -p $(MDIR) ; fi
	install -D -m 644 *.ko $(MDIR)
	depmod -a

clean:
	rm -f *.o *.ko *.mod.c .*o.cmd .*o.d .*o.flags
	rm -rf .tmp_versions


sdricoh_cs.c.gz
Description: GNU Zip compressed data

Re: [PATCH 1/2 v3] sysrq: showBlockedTasks is sysrq-W

[Dave Jones]

On Sat, Jan 06, 2007 at 02:04:24PM -0800, Randy Dunlap wrote:

 > +.help_msg   = "showBlockedTasks(W)",

Why not the same scheme as the existing help msgs..

shoWblockedtasks  ?

Dave

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

Re: RTC subsystem and fractions of seconds

[David Brownell]

On Saturday 06 January 2007 3:26 pm, Philippe De Muyter wrote:
> On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> > >   Those rtc's actually have a 1/100th of second
> > > register.  Should the generic rtc interface not support that?
> > 
> > Are you implying a new userspace API, or just an in-kernel update?
> 
> My only concern at the moment is initializing linux's timeofday from the rtc
> quickly and with a good precision. 

There will necessarily be a bit of fuzz there since it can take time to
get that RTC's mutex, and the task setting that time can be preempted.
Plus, there can also be delays at the I2C or SPI transaction level.


> The way it is done currently 
> in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
> precision by looping there until the next change (next second for old clocks,
> next 0.01 second for m41t81, maybe even better for other ones).

Hmm ... "looping" fights against "quickly"; as would "wait for next
update IRQ" (on RTCs that support that).  But it would improve precision,
at least in the sense of having the system clock and that RTC spending
less time with the lowest "seconds" digit disagreeing.

This is something you could write a patch for, n'est-ce pas?

- Dave



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

Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver

[David Brownell]

On Saturday 06 January 2007 9:17 am, Woody Suwalski wrote:
> >> There are PPC, M68K, SPARC, and other boards that could also
> >> use this; ARMs tend to integrate some other RTC on-chip.  ...
> 
> > Let me put that differently.  That should be done as a separate
> > patch, adding (a) that platform_device, and maybe platform_data
> > if it's got additional alarm registers, and (b) Kconfig support
> > to let that work.  I'd call it a "patch #4 of 3".  ;)
> > ...
> 
> I will try to play with the new code on Monday on ARM...

Thanks.  Could you describe your ARM board?  None of mine have an
RTC using this register API.  Does it support system sleep states
(/sys/power/state) with a wakeup-capable (enable_irq_wake) RTC irq? 

- Dave

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[H. Peter Anvin]

Andrew Morton wrote:


The most fundamental problem seems to be that I can't tell currnt Linux 
kernels that the dcache/icache is precious, and that it's way too eager 
to dump dcache and icache in favour of data blocks.  If I could do that, 
this problem would be much, much smaller.


Usually people complain about the exact opposite of this.


Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to do
this?


yup.


Well, it appears that even a setting of 1 is too aggressive for 
kernel.org.  We're still ending up with each and every getdents() call 
taking anywhere from 200 ms to over a second.


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

Re: RTC subsystem and fractions of seconds

[Philippe De Muyter]

On Fri, Jan 05, 2007 at 07:49:00PM -0800, David Brownell wrote:
> > Those rtc's actually have a 1/100th of second
> > register.  Should the generic rtc interface not support that?
> 
> Are you implying a new userspace API, or just an in-kernel update?

My only concern at the moment is initializing linux's timeofday from the rtc
quickly and with a good precision.  The way it is done currently
in drivers/rtc/hctosys.c is 0.5 sec off.  We could obtain a much better
precision by looping there until the next change (next second for old clocks,
next 0.01 second for m41t81, maybe even better for other ones).

> 
> Either way, that raises the question of what other features should
> be included.  What sub-second precision?  Multiple alarms?  Ways
> to manage output clocks?  Sub-HZ periodic alarms?

I cannot answer that, but others may have other needs.

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

Re: [ANNOUNCE] Guilt 0.16

[Juergen Ruehle]

Jan Engelhardt writes:
 > 
 > On Jan 6 2007 13:46, Josef Sipek wrote:
 > >
 > >Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
 > 
 > "I feel so guilty when using guilt!"
 > 
 > Oh well I should point out that people should give
 > tools a better naming. :-)

I didn't know there was a tool name 'goodness' metric:-)

I rather like 'Guilt'.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc3: known unfixed regressions (v4)

[Brice Goglin]

Adrian Bunk wrote:
> This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
> that are not yet fixed in Linus' tree.
>   

I reported another one yesterday, about HT MSI capability lookup being
broken (can only find the first one in the chain). See
http://lkml.org/lkml/2007/1/5/215. The patch works well here, but I
didn't get any comment so far.

The regression has been confirmed by Robert Hancock.

Brice

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

Re: revert PIE randomization?

[David Woodhouse]

On Sat, 2007-01-06 at 20:11 +, Hugh Dickins wrote:
> And I notice that Andi added a personality & ADDR_NO_RANDOMIZE check
> into randomize_stack_top: I cannot see why that's necessary there,
> but if it is, then should the ET_DYN case add it too?)

While I think of it... it seems that ADDR_NO_RANDOMIZE isn't "inherited"
across exec of 32-bit binaries on x86_64 or ppc64. The personality flags
get wiped out when we detect a 32-bit ELF executable and set the
personality to PER_LINUX32.

This causes suboptimal behaviour from userspace code which checks
whether it can set ADDR_NO_RANDOMIZE with a sys_personality() call, and
if so re-execs itself. Run on x86_64 or ppc64, these go into an endless
loop because it always gets cleared in the exec.

I've seen such code in two places recently (Macaulay2 and sbcl, iirc).

-- 
dwmw2

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

Re: + spin_lock_irq-enable-interrupts-while-spinning-i386-implementation.patch added to -mm tree

[Daniel Walker]

On Wed, 2007-01-03 at 13:12 -0800, [EMAIL PROTECTED] wrote:
> -# define __raw_spin_lock_irq(lock) __raw_spin_lock(lock)
> +
> +static inline void __raw_spin_lock_irq(raw_spinlock_t *lock)
> +{
> +   asm volatile("\n1:\t"
> +LOCK_PREFIX " ; decb %0\n\t"
> +"jns 3f\n"
> +STI_STRING "\n"
> +"2:\t"
> +"rep;nop\n\t"
> +"cmpb $0,%0\n\t"
> +"jle 2b\n\t"
> +CLI_STRING "\n"
> +"jmp 1b\n"
> +"3:\n\t"
> +: "+m" (lock->slock) : : "memory");
> +}
>  #endif
>   

This doesn't compile when CONFIG_PARAVIRT is enabled. It changes the
CLI_STRING and STI_STRING values.

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: JMicron JMB363 SATA hard disk appears twice (sda + hdg)

[Giuseppe Bilotta]

On Sat, 6 Jan 2007 19:35:41 +, Alan wrote:

> The kernel drivers work on the basis that if you are using drivers/ide
> then the IDE driver will grab all the ports, if you are using libata then
> the PCI boot quirks will switch to split AHCI and PATA mode and the
> libata drivers will take both. 
> 
> If you build both IDE and libata support for the same hardware into your
> kernel it should generally end up with only one driver claiming the
> hardware but the AHCI case doesn't handle this in 2.6.18.

[and in another post:]

> You have both the drivers for the Jmicron via drivers/ide and via
> drivers/ata (libata) loaded. In that specific combination the two drivers
> don't use the same resources so don't spot the other one is busy.

Thanks for the explanation. I had suspected such an interaction,
especially since browsing the LKML it seems that this doubling of the
interfaces with the JMicron controllers is an intentional change:
http://lkml.org/lkml/2006/7/12/133>.

So the only problem is how to tell the kernel to not use ide on the
SATA channels, and this is what I had tried to do with ide2=noprobe
ide3=noprobe. However, this doesn't seem to happen. Am I
misinterpreting the meaning of the idex=noprobe parameter?

BTW, is there a preference for libata or the jmicron ide driver?
Assuming I finally manage to only make it appear once, which one
should I go for?

-- 
Giuseppe "Oblomov" Bilotta

"I weep for our generation" -- Charlie Brown

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

Re: [PATCH 4/4] Add MMC Password Protection (lock/unlock) support V9: mmc_sysfs.diff

[Pierre Ossman]

I've queued it up for -mm, but there a few more comments I want resolved
before this can move to Linus...

You need to clean up mmc_lockable_store(). It had a few broken variable
declarations that even prevented it from compiling, and after I fixed
that I still get:

drivers/mmc/mmc_sysfs.c: In function ‘mmc_lockable_store’:
drivers/mmc/mmc_sysfs.c:160: warning: ignoring return value of
‘device_attach’, declared with attribute warn_unused_result
drivers/mmc/mmc_sysfs.c:93: warning: ‘mmc_key’ may be used uninitialized
in this function

There's also no handling for an invalid string written to the sysfs node.

And third, you're a bit excessive on the goto:s. E.g. out_unlocked is
used in a single place, so it is completely unnecessary. Please do a
general cleanup of the control flow.

Rgds

-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org

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

Re: [ANNOUNCE] Guilt 0.16

[Josef Sipek]

On Sat, Jan 06, 2007 at 04:57:31PM -0300, Horst H. von Brand wrote:
> Josef Sipek <[EMAIL PROTECTED]> wrote:
> > Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
> > queues-like [1] functionality and interface to git.  The one distinguishing
> > feature from other quilt-like porcelains, is the format of the patches
> > directory. _All_ the information is stored as plain text - a series file and
> > the patches (one per file). This easily lends itself to versioning the
> > patches using any number of of SCMs.
> 
> A installation script/Makefile (or at least instructions) is missing...

Ah, good point. Just include the dir in your path. That's all.

/me goes to make a small makefile

Josef "Jeff" Sipek.

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

[PATCH 2/2] sysrq: alphabetize command keys doc.

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

Alphabetize the sysrq command keys list.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 Documentation/sysrq.txt |   44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

--- linux-2620-rc3g4.orig/Documentation/sysrq.txt
+++ linux-2620-rc3g4/Documentation/sysrq.txt
@@ -64,11 +64,6 @@ On all -  write a character to /proc/sys
 
 *  What are the 'command' keys?
 ~~~
-'r' - Turns off keyboard raw mode and sets it to XLATE.
-
-'k' - Secure Access Key (SAK) Kills all programs on the current virtual
-  console. NOTE: See important comments below in SAK section.
-
 'b' - Will immediately reboot the system without syncing or unmounting
   your disks.
 
@@ -76,21 +71,37 @@ On all -  write a character to /proc/sys
 
 'd'- Shows all locks that are held.
 
-'o' - Will shut your system off (if configured and supported).
+'e' - Send a SIGTERM to all processes, except for init.
 
-'s' - Will attempt to sync all mounted filesystems.
+'f'- Will call oom_kill to kill a memory hog process.
 
-'u' - Will attempt to remount all mounted filesystems read-only.
+'g'- Used by kgdb on ppc platforms.
 
-'p' - Will dump the current registers and flags to your console.
+'h' - Will display help (actually any other key than those listed
+  above will display help. but 'h' is easy to remember :-)
 
-'t' - Will dump a list of current tasks and their information to your
-  console.
+'i' - Send a SIGKILL to all processes, except for init.
+
+'k' - Secure Access Key (SAK) Kills all programs on the current virtual
+  console. NOTE: See important comments below in SAK section.
 
 'm' - Will dump current memory info to your console.
 
 'n'- Used to make RT tasks nice-able
 
+'o' - Will shut your system off (if configured and supported).
+
+'p' - Will dump the current registers and flags to your console.
+
+'r' - Turns off keyboard raw mode and sets it to XLATE.
+
+'s' - Will attempt to sync all mounted filesystems.
+
+'t' - Will dump a list of current tasks and their information to your
+  console.
+
+'u' - Will attempt to remount all mounted filesystems read-only.
+
 'v'- Dumps Voyager SMP processor info to your console.
 
 'w'- Dumps tasks that are in uninterruptable (blocked) state.
@@ -102,17 +113,6 @@ On all -  write a character to /proc/sys
   it so that only emergency messages like PANICs or OOPSes would
   make it to your console.)
 
-'f'- Will call oom_kill to kill a memory hog process.
-
-'e' - Send a SIGTERM to all processes, except for init.
-
-'g'- Used by kgdb on ppc platforms.
-
-'i' - Send a SIGKILL to all processes, except for init.
-
-'h' - Will display help (actually any other key than those listed
-  above will display help. but 'h' is easy to remember :-)
-
 *  Okay, so what can I use them for?
 
 Well, un'R'aw is very handy when your X server or a svgalib program crashes.

---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2 v3] sysrq: showBlockedTasks is sysrq-W

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

SysRq showBlockedTasks is not done via B or T, it's done via W,
so put that in the Help message.

It was previously done via X, but X is already used for Xmon
on ppc & powerpc platforms and this collision needs to be avoided.

All callers of register_sysrq_key() are now marked in the
sysrq op/key table.  I didn't mark 'h' as Help because Help
is just printed for any unknown key, such as '?'.

Added some omitted sysrq key entries in the sysrq.txt file.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 Documentation/sysrq.txt |   66 +---
 drivers/char/sysrq.c|   20 --
 2 files changed, 46 insertions(+), 40 deletions(-)

--- linux-2620-rc3g4.orig/drivers/char/sysrq.c
+++ linux-2620-rc3g4/drivers/char/sysrq.c
@@ -215,7 +215,7 @@ static void sysrq_handle_showstate_block
 }
 static struct sysrq_key_op sysrq_showstate_blocked_op = {
.handler= sysrq_handle_showstate_blocked,
-   .help_msg   = "showBlockedTasks",
+   .help_msg   = "showBlockedTasks(W)",
.action_msg = "Show Blocked State",
.enable_mask= SYSRQ_ENABLE_DUMP,
 };
@@ -315,15 +315,16 @@ static struct sysrq_key_op *sysrq_key_ta
_loglevel_op, /* 9 */
 
/*
-* Don't use for system provided sysrqs, it is handled specially on
-* sparc and will never arrive
+* a: Don't use for system provided sysrqs, it is handled specially on
+* sparc and will never arrive.
 */
NULL,   /* a */
_reboot_op,   /* b */
-   _crashdump_op,/* c */
+   _crashdump_op,/* c & ibm_emac driver debug */
_showlocks_op,/* d */
_term_op, /* e */
_moom_op, /* f */
+   /* g: May be registered by ppc for kgdb */
NULL,   /* g */
NULL,   /* h */
_kill_op, /* i */
@@ -332,18 +333,19 @@ static struct sysrq_key_op *sysrq_key_ta
NULL,   /* l */
_showmem_op,  /* m */
_unrt_op, /* n */
-   /* This will often be registered as 'Off' at init time */
+   /* o: This will often be registered as 'Off' at init time */
NULL,   /* o */
_showregs_op, /* p */
NULL,   /* q */
-   _unraw_op,/* r */
+   _unraw_op,/* r */
_sync_op, /* s */
_showstate_op,/* t */
_mountro_op,  /* u */
-   /* May be assigned at init time by SMP VOYAGER */
+   /* v: May be registered at init time by SMP VOYAGER */
NULL,   /* v */
-   NULL,   /* w */
-   _showstate_blocked_op,/* x */
+   _showstate_blocked_op,/* w */
+   /* x: May be registered on ppc/powerpc for xmon */
+   NULL,   /* x */
NULL,   /* y */
NULL/* z */
 };
--- linux-2620-rc3g4.orig/Documentation/sysrq.txt
+++ linux-2620-rc3g4/Documentation/sysrq.txt
@@ -1,6 +1,6 @@
 Linux Magic System Request Key Hacks
-Documentation for sysrq.c version 1.15
-Last update: $Date: 2001/01/28 10:15:59 $
+Documentation for sysrq.c
+Last update: 2007-JAN-06
 
 *  What is the magic SysRq key?
 ~~~
@@ -35,7 +35,7 @@ You can set the value in the file by the
 
 Note that the value of /proc/sys/kernel/sysrq influences only the invocation
 via a keyboard. Invocation of any operation via /proc/sysrq-trigger is always
-allowed.
+allowed (by a user with admin privileges).
 
 *  How do I use the magic SysRq key?
 
@@ -58,7 +58,7 @@ On PowerPC - Press 'ALT - Print Screen (
 On other - If you know of the key combos for other architectures, please
let me know so I can add them to this section.
 
-On all -  write a character to /proc/sysrq-trigger.  eg:
+On all -  write a character to /proc/sysrq-trigger.  e.g.:
 
echo t > /proc/sysrq-trigger
 
@@ -74,6 +74,8 @@ On all -  write a character to /proc/sys
 
 'c'- Will perform a kexec reboot in order to take a crashdump.
 
+'d'- Shows all locks that are held.
+
 'o' - Will shut your system off (if configured and supported).
 
 's' - Will attempt to sync all mounted filesystems.
@@ -87,38 +89,43 @@ On all -  write a character to /proc/sys
 
 'm' - Will dump current memory info to your console.
 
+'n'- Used to make RT tasks nice-able
+
 'v'- Dumps Voyager SMP processor info to your console.
 
+'w'- Dumps tasks that are in uninterruptable (blocked) state.
+
+'x'- Used by xmon interface on ppc/powerpc platforms.
+
 '0'-'9' - 

Re: x86 instability with 2.6.1{8,9}

[Randy Dunlap]

On Tue, 2 Jan 2007 19:34:59 + Ken Moffat wrote:

> On Tue, Jan 02, 2007 at 01:42:32PM -0500, Len Brown wrote:
> > 
> > You might remove and re-insert the DIMMS.
> > Sometimes there are poor contacts if the DIMMS are not fully seated and 
> > clicked in.
> > 
> > The real mystery is the 32 vs 64-bit thing.
> > Are the devices configured the same way -- ie are they both in IOAPIC mode
> > and /proc/interrupts looks the same for both modes?
> > 
> > -Len
> 
>  Too late, I've started memtest-86+.  If it seems ok after an
> overnight run, I'll take a look at /proc/interrupts.  How can I tell
> it is in IOAPIC mode, please ?  Google was not helpful for this, but
> if it's an override, the only things on my command lines are root=
> and video= settings.

(did anyone ever answer this?)

In IO-APIC mode, /proc/interrupts contains entries like these:

   CPU0   CPU1   
  0:  121218123  0IO-APIC-edge  timer
  1: 715259  0IO-APIC-edge  i8042
  6:  5  0IO-APIC-edge  floppy
  7:  0  0IO-APIC-edge  parport0
  9:  0  0   IO-APIC-level  acpi
 12:   10011272  0IO-APIC-edge  i8042
 14:   11561548  0IO-APIC-edge  ide0
 66:4525183  0 PCI-MSI  libata
 74:   1711  0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb6
 82:  4  0   IO-APIC-level  ohci_hcd:usb2, ohci_hcd:usb3, 
ohci_hcd:usb4, ohci_hcd:usb5
 98: 101326  0 PCI-MSI  HDA Intel
106:   17747181  0 PCI-MSI  eth0
169:  0  0   IO-APIC-level  uhci_hcd:usb9
177:  3  0   IO-APIC-level  ohci1394
185: 15  0   IO-APIC-level  uhci_hcd:usb8, aic79xx
193: 427962  0   IO-APIC-level  uhci_hcd:usb7, aic79xx

If not in IO-APIC mode, lots of those will say "XT-PIC" instead
of IO-APIC.

>  Certainly, it seems likely that the configs could be fairly
> different in their detail.


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

Re: revert PIE randomization?

[Marcus Meissner]

On Sat, Jan 06, 2007 at 10:45:05PM +0100, Ingo Molnar wrote:
> 
> * Marcus Meissner <[EMAIL PROTECTED]> wrote:
> 
> > > You're right. I'm inclined to just revert it, modulo some comments 
> > > from others. Marcus?
> > 
> > After thinking about this, yes.
> > 
> > I would rather have a working range used here (perhaps like Hugh 
> > suggested), but feel free to revert the original patch if you are not 
> > confident with it.
> 
> i'm wondering why you had to try to reinvent the wheel, instead of 
> picking up exec-shield's remaining bits of randomization implementation 
> from Fedora, which was tested for a long time and achieves PIE 
> randomization and more?

Because it is i386 only last time I checked.

And it requires relaying out the heap (which you did only for i386), with
architecture specific code, which I was too afraid to touch.

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

Re: revert PIE randomization?

[Ingo Molnar]

* Marcus Meissner <[EMAIL PROTECTED]> wrote:

> > You're right. I'm inclined to just revert it, modulo some comments 
> > from others. Marcus?
> 
> After thinking about this, yes.
> 
> I would rather have a working range used here (perhaps like Hugh 
> suggested), but feel free to revert the original patch if you are not 
> confident with it.

i'm wondering why you had to try to reinvent the wheel, instead of 
picking up exec-shield's remaining bits of randomization implementation 
from Fedora, which was tested for a long time and achieves PIE 
randomization and more?

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

Re: BUG: warning at mm/truncate.c:60/cancel_dirty_page()

[Hugh Dickins]

On Sat, 6 Jan 2007, Sami Farin wrote:

> Linux 2.6.19.1 SMP [2] on Pentium D...
> I was running dt-15.14 [2] and I ran
> "cinfo datafile" (it does mincore()).
> Well it went OK but when I ran "strace cinfo datafile"...:
> 04:18:48.062466 mincore(0x37f1f000, 2147266560, 

You rightly noted in a followup that there have been changes to
mincore, but I doubt they have any bearing on this: I think the
BUG just happened at the same time as your mincore.

> ...
> 2007-01-06 04:19:03.788181500 <4>BUG: warning at 
> mm/truncate.c:60/cancel_dirty_page()
> 2007-01-06 04:19:03.788221500 <4> [] dump_trace+0x215/0x21a
> 2007-01-06 04:19:03.788223500 <4> [] show_trace_log_lvl+0x1a/0x30
> 2007-01-06 04:19:03.788224500 <4> [] show_trace+0x12/0x14
> 2007-01-06 04:19:03.788225500 <4> [] dump_stack+0x19/0x1b
> 2007-01-06 04:19:03.788227500 <4> [] cancel_dirty_page+0x7e/0x80
> 2007-01-06 04:19:03.788228500 <4> [] 
> truncate_complete_page+0x1a/0x47
> 2007-01-06 04:19:03.788229500 <4> [] 
> truncate_inode_pages_range+0x114/0x2ae
> 2007-01-06 04:19:03.788245500 <4> [] truncate_inode_pages+0x1a/0x1c
> 2007-01-06 04:19:03.788247500 <4> [] fs_flushinval_pages+0x40/0x77
> 2007-01-06 04:19:03.788248500 <4> [] xfs_write+0x8c4/0xb68
> 2007-01-06 04:19:03.788250500 <4> [] xfs_file_aio_write+0x7e/0x95
> 2007-01-06 04:19:03.788251500 <4> [] do_sync_write+0xca/0x119
> 2007-01-06 04:19:03.788265500 <4> [] vfs_write+0x187/0x18c
> 2007-01-06 04:19:03.788267500 <4> [] sys_write+0x3d/0x64
> 2007-01-06 04:19:03.788268500 <4> [] syscall_call+0x7/0xb
> 2007-01-06 04:19:03.788269500 <4> [<001cf410>] 0x1cf410
> 2007-01-06 04:19:03.788289500 <4> ===

So... XFS uses truncate_inode_pages when serving the write system call.
That's very inventive, and now it looks like Linus' cancel_dirty_page
and new warning have caught it out.  VM people expect it to be called
either when freeing an inode no longer in use, or when doing a truncate,
after ensuring that all pages mapped into userspace have been taken out.

> 
> funny that when stracing, mincore does not return?
> 
> $ time cinfo dtfile-2091
> dtfile-2091: 524285 pages, 0 pages cached (0.00%)
> 
> real0m0.049s
> user0m0.003s
> sys 0m0.046s
> 
> safari6941 29.9 10.8 2098768 108788 pts/2  D+   04:20   3:41 strace 
> -vfttT cinfo dtfile-2091
> 
> straceD C179A000 0  6941   8737  6942  2089 (NOTLB)
>e790 0046 c172e240 c179a000 c1731880 c17c51a0 c17b5be0 c1771c20
>e9b1f740 0086 d55dd74c e76c  c02666b8 c17fd700 c2c2513c
>fdac b2203610 616f c2c25030 c17fd700 e7f8 c17d31f0 e79c
> Call Trace:
>  [] io_schedule+0x26/0x30
>  [] sync_page+0x3d/0x48
>  [] __wait_on_bit_lock+0x45/0x67
>  [] __lock_page+0x88/0x95
>  [] filemap_nopage+0x1f4/0x386
>  [] do_no_page+0x82/0x2fa
>  [] __handle_mm_fault+0x1fe/0x2eb
>  [] get_user_pages+0xc7/0x2e5
>  [] access_process_vm+0x74/0x116
>  [] arch_ptrace+0x388/0x539
>  [] sys_ptrace+0x58/0xb9
>  [] syscall_call+0x7/0xb
>  [<0081e410>] 0x81e410
>  ===
> cinfo t CB7DA040 0  6942   6941 (NOTLB)
>e5fcdee8 0046 ce7d9284 cb7da040 ce7d9284 cb7da078 cb7da040 e5fcdf10
>cb7da040 13a973f5 60e3 0078  c2c25030 c1805700 d483013c
>0021fd53 13a97513 60e3 d4830030 e5fcdf04 0005  e5fcdefc
> Call Trace:
>  [] ptrace_stop+0xf8/0x17f
>  [] ptrace_notify+0x6a/0x92
>  [] do_syscall_trace+0xd4/0x1eb
>  [] syscall_exit_work+0x16/0x1b
>  [<00878410>] 0x878410
>  ===
> 
> 
> [1]
> includes these
> 8c08540f8755c451d8b96ea14cfe796bc3cd712d [PATCH] clean up 
> __set_page_dirty_nobuffers()
> 55e829af06681e5d731c03ba04febbd1c76ca293 [PATCH] io-accounting: write 
> accounting
> e08748ce01e02f0ec154b141f392ccb9555333f4 [PATCH] io-accounting: 
> write-cancel accounting
> fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 VM: Remove 
> "clear_page_dirty()" and "test_clear_page_dirty()" functions
> 3e67c0987d7567ad41164a153dca9a43b11d [PATCH] truncate: clear page 
> dirtiness before running try_to_free_buffers()
> 5f2a105d5e33a038a717995d2738434f9c25aed2 [PATCH] truncate: dirty 
> memory accounting fix
> 8368e328dfe1c534957051333a87b3210a12743b Clean up and export 
> cancel_dirty_page() to modules
> 7658cc289288b8ae7dd2c2224549a048431222b3 VM: Fix nasty and subtle 
> race in shared mmap'ed page writeback
> 7c3ab7381e79dfc7db14a67c6f4f3285664e1ec2 [PATCH] io-accounting: core 
> statistics
> cb876f451455b6187a7d69de2c112c45ec4b7f99 Fix up CIFS for 
> "test_clear_page_dirty()" removal
> 7dfb71030f7636a0d65200158113c37764552f93 [PATCH] Add 
> include/linux/freezer.h and move definitions from sched.h
> 46d2277c796f9f4937bfa668c40b2e3f43e93dd0 Clean up and make 
> try_to_free_buffers() not race with dirty 
> e61c90188b9956edae1105eef361d8981a352fcd [PATCH] optimize o_direct on 
> 

Re: revert PIE randomization?

[Marcus Meissner]

On Sat, Jan 06, 2007 at 01:04:02PM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Jan 2007, Hugh Dickins wrote:
> > 
> > Isn't that randomization, anywhere from 0x1 to ELF_ET_DYN_BASE,
> > sure to place the ET_DYN from time to time just where the comment says
> > it's trying to avoid?  I assume that somehow results in the error reported.
> 
> Hmm.. It's certainly the case that it would appear that the randomization 
> might put the binary just under the heap, and cause conflicts with brk 
> and the mmap heap.
> 
> You're right. I'm inclined to just revert it, modulo some comments from 
> others. Marcus?

After thinking about this, yes.

I would rather have a working range used here (perhaps like Hugh suggested),
but feel free to revert the original patch if you are not confident with it.

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

Re: revert PIE randomization?

[Linus Torvalds]

On Sat, 6 Jan 2007, Hugh Dickins wrote:
> 
> Isn't that randomization, anywhere from 0x1 to ELF_ET_DYN_BASE,
> sure to place the ET_DYN from time to time just where the comment says
> it's trying to avoid?  I assume that somehow results in the error reported.

Hmm.. It's certainly the case that it would appear that the randomization 
might put the binary just under the heap, and cause conflicts with brk 
and the mmap heap.

You're right. I'm inclined to just revert it, modulo some comments from 
others. Marcus?

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

2.6.20-rc3: known unfixed regressions (v4)

[Adrian Bunk]

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject: x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
 http://lkml.org/lkml/2007/1/3/9
Submitter  : Tobias Diedrich <[EMAIL PROTECTED]>
Caused-By  : Andi Kleen <[EMAIL PROTECTED]>
 commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu <[EMAIL PROTECTED]>
 Eric W. Biederman <[EMAIL PROTECTED]>
Status : patches are being discussed


Subject: BUG: scheduling while atomic: hald-addon-stor/...
 cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
 http://lkml.org/lkml/2006/12/29/22
 http://lkml.org/lkml/2006/12/31/133
Submitter  : Jon Smirl <[EMAIL PROTECTED]>
 Damien Wyart <[EMAIL PROTECTED]>
 Aaron Sethman <[EMAIL PROTECTED]>
Status : unknown


Subject: problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter  : Uwe Bugla <[EMAIL PROTECTED]>
Status : unknown


Subject: USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
 http://lkml.org/lkml/2006/12/26/106
Submitter  : Florin Iucha <[EMAIL PROTECTED]>
Status : unknown


Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter  : Berthold Cogel <[EMAIL PROTECTED]>
Handled-By : Alexey Starikovskiy <[EMAIL PROTECTED]>
Status : problem is being debugged


Subject: ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter  : Komuro <[EMAIL PROTECTED]>
Caused-By  : YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
 commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Status : problem is being debugged


Subject: PIE randomization causes random failures of kernel compiles
References : http://lkml.org/lkml/2007/1/6/124
Submitter  : Hugh Dickins <[EMAIL PROTECTED]>
Caused-By  : Marcus Meissner <[EMAIL PROTECTED]>
 commit 59287c0913cc9a6c75712a775f6c1c1ef418ef3b
Handled-By : Hugh Dickins <[EMAIL PROTECTED]>
Patch  : http://lkml.org/lkml/2007/1/6/124
Status : patch was suggested

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] paravirt: isolate module ops

[Zachary Amsden]

Rusty Russell wrote:


+int paravirt_write_msr(unsigned int msr, u64 val);


If binary modules using debug registers makes us nervous, the 
reprogramming MSRs is also similarly bad.




+void raw_safe_halt(void);
+void halt(void);
  


These shouldn't be done by modules, ever.  Only the scheduler should 
decide to halt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] cx88xx: Fix lockup on suspend

[Nigel Cunningham]

Hi.

On Sat, 2007-01-06 at 12:25 -0600, Robert Hancock wrote:
> Pavel Machek wrote:
> > Ack,
> >   
> > but your patch was whitespace-damaged. Can you retry?
> >   
> 
> Here's another try with it attached (Thunderbird is deciding to be a
> pain unfortunately..)
> 
> ---
> 
> Suspending with the cx88xx module loaded causes the system to lock up
> because the cx88_audio_thread kthread was missing a try_to_freeze()
> call, which caused it to go into a tight loop and result in softlockup
> when suspending. Fix that.
> 
> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]>


I have just gotten a cx88 card and had to do the same thing, but hadn't
had time to send the patch yet. The cards (or at least my one) need more
attention than this though; after resuming mine doesn't tune.

Regards,

Nigel

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

Re: + paravirt-vmi-timer-patches.patch added to -mm tree

[Zachary Amsden]

Daniel Walker wrote:

On Fri, 2006-12-15 at 14:27 -0800, [EMAIL PROTECTED] wrote:
  

+
+unsigned long long vmi_sched_clock(void)
+{
+   return read_available_cycles();
+}
+ 




This sched_clock is likely broken if it's returning something other than
nanoseconds. It looks like cycles, but it's also getting piped through
an ops pointer so I'm not sure what's getting returned here.
  


Thanks, I'll fix that.

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

Re: + paravirt-vmi-timer-patches.patch added to -mm tree

[Zachary Amsden]

Daniel Walker wrote:

On Sat, 2007-01-06 at 12:37 -0800, Zachary Amsden wrote:

  

There is already a dynamic tick (NO_HZ) system in the -mm tree .. Given
that this implementation seems unnecessary. Why do you need another
different system to do this?
  
  
We don't.  This was written before the dynamic tick code, and now they 
need to be merged.  Until then, they can safely coexist.



So really this can't go upstream till that merge happens. What's
preventing you from just directly using NO_HZ without changes?
  


For one thing, the fact that it doesn't account for stolen time.  But 
mostly because going through the regular PIT / APIC timer paths has a 
lot of overhead.  So we need a separate timer device, and weaving this 
in with the local APIC timer dependency for SMP on i386 requires changes 
on top of NO_HZ.


Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 2.6 patch] remove the broken SCSI_ACORNSCSI_3 driver

[Adrian Bunk]

The SCSI_ACORNSCSI_3 driver:
- has been marked as BROKEN for more than one year and
- is still marked as BROKEN.

Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.

But if anyone wants to ever revive this driver, the code is still
present in the older kernel releases.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

Due to it's size, the compressed patch is attached.

 drivers/scsi/arm/Kconfig|   29 
 drivers/scsi/arm/Makefile   |3 
 drivers/scsi/arm/acornscsi-io.S |  145 -
 drivers/scsi/arm/acornscsi.c| 3130 
 drivers/scsi/arm/acornscsi.h|  358 ---
 5 files changed, 3665 deletions(-)



patch-remove-SCSI_ACORNSCSI_3.gz
Description: Binary data

[2.6 patch] remove bogus con_is_present() prototypes

[Adrian Bunk]

Although gcc seems to accept "extern" prototypes after it has seen the
"static inline" function, that's not really correct.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/video/aty/atyfb_base.c |2 --
 drivers/video/igafb.c  |1 -
 2 files changed, 3 deletions(-)

--- linux-2.6.20-rc3-mm1/drivers/video/igafb.c.old  2007-01-06 
19:45:32.0 +0100
+++ linux-2.6.20-rc3-mm1/drivers/video/igafb.c  2007-01-06 19:53:06.0 
+0100
@@ -370,7 +370,6 @@
 
 int __init igafb_init(void)
 {
-extern int con_is_present(void);
 struct fb_info *info;
 struct pci_dev *pdev;
 struct iga_par *par;
--- linux-2.6.20-rc3-mm1/drivers/video/aty/atyfb_base.c.old 2007-01-06 
20:14:25.0 +0100
+++ linux-2.6.20-rc3-mm1/drivers/video/aty/atyfb_base.c 2007-01-06 
20:14:32.0 +0100
@@ -2957,8 +2957,6 @@
 static int __devinit atyfb_setup_sparc(struct pci_dev *pdev,
struct fb_info *info, unsigned long addr)
 {
-   extern int con_is_present(void);
-
struct atyfb_par *par = info->par;
struct pcidev_cookie *pcp;
char prop[128];

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] make isa_bridge Alpha-only

[Adrian Bunk]

Since isa_bridge is neither assigned any value !NULL nor used on !Alpha, 
there's no reason for providing it.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/alpha/kernel/pci.c |4 
 drivers/pci/pci.c   |6 --
 include/asm-alpha/pci.h |2 ++
 include/linux/pci.h |6 --
 4 files changed, 6 insertions(+), 12 deletions(-)

--- linux-2.6.20-rc3-mm1/include/linux/pci.h.old2007-01-06 
18:07:12.0 +0100
+++ linux-2.6.20-rc3-mm1/include/linux/pci.h2007-01-06 18:11:45.0 
+0100
@@ -620,10 +620,6 @@
   strategy_parameter byte boundaries */
 };
 
-#if defined(CONFIG_ISA) || defined(CONFIG_EISA)
-extern struct pci_dev *isa_bridge;
-#endif
-
 struct msix_entry {
u16 vector; /* kernel uses to write allocated vector */
u16 entry;  /* driver uses to specify entry, OS writes */
@@ -731,8 +727,6 @@
 static inline pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t 
state) { return PCI_D0; }
 static inline int pci_enable_wake(struct pci_dev *dev, pci_power_t state, int 
enable) { return 0; }
 
-#defineisa_bridge  ((struct pci_dev *)NULL)
-
 #define pci_dma_burst_advice(pdev, strat, strategy_parameter) do { } while (0)
 
 static inline void pci_block_user_cfg_access(struct pci_dev *dev) { }
--- linux-2.6.20-rc3-mm1/include/asm-alpha/pci.h.old2007-01-06 
18:07:42.0 +0100
+++ linux-2.6.20-rc3-mm1/include/asm-alpha/pci.h2007-01-06 
18:14:33.0 +0100
@@ -293,4 +293,6 @@
 #define IOBASE_ROOT_BUS5
 #define IOBASE_FROM_HOSE   0x1
 
+extern struct pci_dev *isa_bridge;
+
 #endif /* __ALPHA_PCI_H */
--- linux-2.6.20-rc3-mm1/drivers/pci/pci.c.old  2007-01-06 18:12:48.0 
+0100
+++ linux-2.6.20-rc3-mm1/drivers/pci/pci.c  2007-01-06 18:13:17.0 
+0100
@@ -1223,12 +1223,6 @@
 
 device_initcall(pci_init);
 
-#if defined(CONFIG_ISA) || defined(CONFIG_EISA)
-/* FIXME: Some boxes have multiple ISA bridges! */
-struct pci_dev *isa_bridge;
-EXPORT_SYMBOL(isa_bridge);
-#endif
-
 EXPORT_SYMBOL_GPL(pci_restore_bars);
 EXPORT_SYMBOL(pci_enable_device_bars);
 EXPORT_SYMBOL(pci_enable_device);
--- linux-2.6.20-rc3-mm1/arch/alpha/kernel/pci.c.old2007-01-06 
18:12:15.0 +0100
+++ linux-2.6.20-rc3-mm1/arch/alpha/kernel/pci.c2007-01-06 
18:14:03.0 +0100
@@ -575,3 +575,7 @@
 
 EXPORT_SYMBOL(pci_iomap);
 EXPORT_SYMBOL(pci_iounmap);
+
+/* FIXME: Some boxes have multiple ISA bridges! */
+struct pci_dev *isa_bridge;
+EXPORT_SYMBOL(isa_bridge);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc3 regression? hdparm shows 1/2...1/3 the throughput

[Stefan Richter]

> Tim Schmielau wrote:
>> See
>>   http://lkml.org/lkml/2007/1/2/75
>> for the solution.

OK; this has already been committed a few days ago. I assume this closes
the issue. I will post after -rc4 in the unlikely case that it doesn't.
-- 
Stefan Richter
-=-=-=== ---= --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: + paravirt-vmi-timer-patches.patch added to -mm tree

[Daniel Walker]

On Sat, 2007-01-06 at 12:37 -0800, Zachary Amsden wrote:

> >
> > There is already a dynamic tick (NO_HZ) system in the -mm tree .. Given
> > that this implementation seems unnecessary. Why do you need another
> > different system to do this?
> >   
> 
> We don't.  This was written before the dynamic tick code, and now they 
> need to be merged.  Until then, they can safely coexist.

So really this can't go upstream till that merge happens. What's
preventing you from just directly using NO_HZ without changes?

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: [KORG] Re: kernel.org lies about latest -mm kernel

[Andrew Morton]

On Sat, 06 Jan 2007 12:20:27 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:

> Andrew Morton wrote:
> >>
> >> Unfortunately that affects all three of: dcache, icache, and mbcache. 
> >> Maybe we could split that sysctl in two (Andrew?), so that one sysctl 
> >> affects dcache/icache and another affects mbcache.
> >>
> > 
> > That would be simple enough to do, if someone can demonstrate a
> > need.
> > 
> 
> Is there an easy way to find out how much memory is occupied by the 
> various caches?  If so I should be able to tell you in a couple of days.

/proc/meminfo:SReclaimable is a lumped sum.  /proc/slabinfo has the most
detail.

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

Re: + paravirt-vmi-timer-patches.patch added to -mm tree

[Zachary Amsden]

Daniel Walker wrote:

On Fri, 2006-12-15 at 14:27 -0800, [EMAIL PROTECTED] wrote:
  

+
+config NO_IDLE_HZ
+   bool
+   depends on PARAVIRT
+   default y
+   help
+ Switches the regular HZ timer off when the system is going
idle.
+ This helps a hypervisor detect that the Linux system is
idle,
+ reducing the overhead of idle systems. 




There is already a dynamic tick (NO_HZ) system in the -mm tree .. Given
that this implementation seems unnecessary. Why do you need another
different system to do this?
  


We don't.  This was written before the dynamic tick code, and now they 
need to be merged.  Until then, they can safely coexist.


Zach

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

This patch adds ATAPI support for the PATA port on Promise 2037x chips.
It depends on the common sata_promise ATAPI support patch.

First-generation chips don't support ATAPI on their SATA ports, so
the patch removes ATA_FLAG_NO_ATAPI from the 2037x common host flags,
and adds it back via the _port_flags[] entries for the SATA ports.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-06 
17:10:56.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 17:14:23.0 
+0100
@@ -187,7 +187,7 @@ static const struct ata_port_info pdc_po
/* board_2037x */
{
.sht= _ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI /* | 
ATA_FLAG_SATA */,
+   .flags  = PDC_COMMON_FLAGS /* | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA */,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -996,6 +996,10 @@ static int pdc_ata_init_one (struct pci_
probe_ent->n_ports = 2;
probe_ent->_port_flags[0] = ATA_FLAG_SATA;
probe_ent->_port_flags[1] = ATA_FLAG_SATA;
+   if (board_idx == board_2037x) {
+   probe_ent->_port_flags[0] |= ATA_FLAG_NO_ATAPI;
+   probe_ent->_port_flags[1] |= ATA_FLAG_NO_ATAPI;
+   }
break;
case board_20619:
probe_ent->n_ports = 4;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 libata #promise-sata-pata] sata_promise: unbreak 20619

[Mikael Pettersson]

The PATA support patch for sata_promise appears, from
code inspection, to break the PATA-only 20619 chip.

The patch removes the SATA flag from the TX2plus SATA+PATA
boards' common flags, with the intention of adding it back
via the _port_flags[] entries for those boards' SATA ports.

However, it unconditionally marks ports 0 and 1 as SATA
for all boards. This causes the 20619 (TX4000) to announce
its first two PATA ports as SATA | ATA_FLAG_SLAVE_POSS.

I don't have a TX4000 so I don't know what the actual
consequences of this bug are, but surely this isn't Ok.

Fixed by moving the port 0 and 1 settings as SATA into
the TX4 and TX2plus specific initialisation code.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-06 
17:05:29.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 17:10:56.0 
+0100
@@ -957,9 +957,6 @@ static int pdc_ata_init_one (struct pci_
probe_ent->port[0].scr_addr = base + 0x400;
probe_ent->port[1].scr_addr = base + 0x500;
 
-   probe_ent->_port_flags[0] = ATA_FLAG_SATA;
-   probe_ent->_port_flags[1] = ATA_FLAG_SATA;
-   
/* notice 4-port boards */
switch (board_idx) {
case board_40518:
@@ -974,6 +971,8 @@ static int pdc_ata_init_one (struct pci_
probe_ent->port[2].scr_addr = base + 0x600;
probe_ent->port[3].scr_addr = base + 0x700;

+   probe_ent->_port_flags[0] = ATA_FLAG_SATA;
+   probe_ent->_port_flags[1] = ATA_FLAG_SATA;
probe_ent->_port_flags[2] = ATA_FLAG_SATA;
probe_ent->_port_flags[3] = ATA_FLAG_SATA;
break;
@@ -995,6 +994,8 @@ static int pdc_ata_init_one (struct pci_
}
else
probe_ent->n_ports = 2;
+   probe_ent->_port_flags[0] = ATA_FLAG_SATA;
+   probe_ent->_port_flags[1] = ATA_FLAG_SATA;
break;
case board_20619:
probe_ent->n_ports = 4;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6.20-rc3] sata_promise: ATAPI support

[Mikael Pettersson]

This patch adds ATAPI support to the sata_promise driver.
This has been tested on both first- and second-generation
chips (20378 and 20575), and with both SATAPI and PATAPI
devices. CD-writing works, and bulk data transfers use DMA.

SATAPI works on second-generation chips, but not on
first-generation chips due to HW limitations.
PATAPI works on both first- and second-generation chips,
but requires the PATA support patch as well (which needs
an update due to a conflict in the board_2037x definition).

The functional changes to the driver are:
- remove ATA_FLAG_NO_ATAPI from PDC_COMMON_FLAGS, and add it
  back to the boards that cannot support SATAPI (20319, 2037x)
- add ->check_atapi() operation to enable DMA for bulk data
  transfers but force PIO for other ATAPI commands; this filter
  is taken from Promise's driver and pata_pdc207x.c
- add handling of ATAPI protocols to pdc_qc_prep(), pdc_host_intr(),
  and pdc_qc_issue_prot(): ATAPI_DMA is handled by the driver
  while non-DMA protocols are handed over to libata generic code
- add pdc_issue_atapi_pkt_cmd() to handle the initial steps in
  issuing ATAPI DMA commands before sending the actual CDB;
  this procedure was ported from Promise's driver

With this patch ATAPI will work on SATA ports on second-generation
chips, and on the first-generation PATA-only 20619. ATAPI on the
2057x' PATA port will work automatically when #promise-sata-pata
is updated. ATAPI on the 2037x' PATA port is enabled by a followup
patch for the #promise-sata-pata branch.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-01 
13:32:35.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 15:36:43.0 
+0100
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -77,7 +78,7 @@ enum {
PDC_RESET   = (1 << 11), /* HDMA reset */
 
PDC_COMMON_FLAGS= ATA_FLAG_NO_LEGACY |
- ATA_FLAG_MMIO | ATA_FLAG_NO_ATAPI |
+ ATA_FLAG_MMIO |
  ATA_FLAG_PIO_POLLING,
 
/* hp->flags bits */
@@ -105,6 +106,7 @@ static void pdc_pata_phy_reset(struct at
 static void pdc_qc_prep(struct ata_queued_cmd *qc);
 static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile 
*tf);
 static void pdc_exec_command_mmio(struct ata_port *ap, const struct 
ata_taskfile *tf);
+static int pdc_check_atapi_dma(struct ata_queued_cmd *qc);
 static void pdc_irq_clear(struct ata_port *ap);
 static unsigned int pdc_qc_issue_prot(struct ata_queued_cmd *qc);
 static void pdc_host_stop(struct ata_host *host);
@@ -139,6 +141,7 @@ static const struct ata_port_operations 
.check_status   = ata_check_status,
.exec_command   = pdc_exec_command_mmio,
.dev_select = ata_std_dev_select,
+   .check_atapi_dma= pdc_check_atapi_dma,
 
.qc_prep= pdc_qc_prep,
.qc_issue   = pdc_qc_issue_prot,
@@ -164,6 +167,7 @@ static const struct ata_port_operations 
.check_status   = ata_check_status,
.exec_command   = pdc_exec_command_mmio,
.dev_select = ata_std_dev_select,
+   .check_atapi_dma= pdc_check_atapi_dma,
 
.phy_reset  = pdc_pata_phy_reset,
 
@@ -183,7 +187,7 @@ static const struct ata_port_info pdc_po
/* board_2037x */
{
.sht= _ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
+   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -193,7 +197,7 @@ static const struct ata_port_info pdc_po
/* board_20319 */
{
.sht= _ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
+   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -391,6 +395,30 @@ static void pdc_sata_scr_write (struct a
writel(val, (void __iomem *) ap->ioaddr.scr_addr + (sc_reg * 4));
 }
 
+static void pdc_atapi_dma_pkt(struct ata_taskfile *tf,
+ dma_addr_t sg_table,
+ unsigned int cdb_len, u8 *cdb,
+ u8 *buf)
+{
+   u32 *buf32 = (u32 *) buf;
+
+   /* set control bits (byte 0), zero delay seq id (byte 3),
+* and seq id (byte 2)
+*/
+   if (!(tf->flags & ATA_TFLAG_WRITE))
+   buf32[0] = cpu_to_le32(PDC_PKT_READ);
+   else
+   

Re: [ANNOUNCE] Guilt 0.16

[Stefan Richter]

Jan Engelhardt wrote:
> "I feel so guilty when using guilt!"
> 
> Oh well I should point out that people should give
> tools a better naming. :-)
> Prime examples are "Squid", "Icecream", and to a
> lesser extent "Apache".
> Perhaps gquilt?

Both guilt and gquilt introduce a potential of mistyped commands.
guilt is nicer to type though.
-- 
Stefan Richter
-=-=-=== ---= --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[H. Peter Anvin]

Andrew Morton wrote:


Unfortunately that affects all three of: dcache, icache, and mbcache. 
Maybe we could split that sysctl in two (Andrew?), so that one sysctl 
affects dcache/icache and another affects mbcache.




That would be simple enough to do, if someone can demonstrate a
need.



Is there an easy way to find out how much memory is occupied by the 
various caches?  If so I should be able to tell you in a couple of days.


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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[H. Peter Anvin]

Andrew Morton wrote:


The most fundamental problem seems to be that I can't tell currnt Linux 
kernels that the dcache/icache is precious, and that it's way too eager 
to dump dcache and icache in favour of data blocks.  If I could do that, 
this problem would be much, much smaller.


Usually people complain about the exact opposite of this.


Yeah, but we constantly have all-filesystem sweeps, and being able to 
retain those in memory would be a key to performance, *especially* from 
the upload latency standpoint.



Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to do
this?


Just tweaked it (setting it to 1).  There really should be another 
sysctl to set the denominator instead of hardcoding it at 100, since the 
granularity of this sysctl at the very low end is really much too coarse.


I missed this sysctl since the name isn't really all that obvious.

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Andrew Morton]

On Sat, 06 Jan 2007 15:13:50 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:

> H. Peter Anvin wrote:
> > Randy Dunlap wrote:
> >>
>  BTW, yesterday my 2.4 patches were not published, but I noticed that
>  they were not even signed not bziped on hera. At first I simply thought
>  it was related, but right now I have a doubt. Maybe the automatic 
>  script
>  has been temporarily been disabled on hera too ?
> >>> The script that deals with the uploads also deals with the packaging -
> >>> so yes the problem is related.
> >>
> >> and with the finger_banner and version info on www.kernel.org page?
> > 
> > Yes, they're all connected.
> > 
> > The load on *both* machines were up above the 300s yesterday, probably 
> > due to the release of a new Knoppix DVD.
> > 
> > The most fundamental problem seems to be that I can't tell currnt Linux 
> > kernels that the dcache/icache is precious, and that it's way too eager 
> > to dump dcache and icache in favour of data blocks.  If I could do that, 
> > this problem would be much, much smaller.
> 
> Have you messed around with /proc/sys/vm/vfs_cache_pressure?
> 
> Unfortunately that affects all three of: dcache, icache, and mbcache. 
> Maybe we could split that sysctl in two (Andrew?), so that one sysctl 
> affects dcache/icache and another affects mbcache.
> 

That would be simple enough to do, if someone can demonstrate a
need.

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Andrew Morton]

On Sat, 06 Jan 2007 11:37:46 -0800
Nicholas Miell <[EMAIL PROTECTED]> wrote:

> On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
> > Randy Dunlap wrote:
> > >
> > >>> BTW, yesterday my 2.4 patches were not published, but I noticed that
> > >>> they were not even signed not bziped on hera. At first I simply thought
> > >>> it was related, but right now I have a doubt. Maybe the automatic script
> > >>> has been temporarily been disabled on hera too ?
> > >> The script that deals with the uploads also deals with the packaging -
> > >> so yes the problem is related.
> > > 
> > > and with the finger_banner and version info on www.kernel.org page?
> > 
> > Yes, they're all connected.
> > 
> > The load on *both* machines were up above the 300s yesterday, probably 
> > due to the release of a new Knoppix DVD.
> > 
> > The most fundamental problem seems to be that I can't tell currnt Linux 
> > kernels that the dcache/icache is precious, and that it's way too eager 
> > to dump dcache and icache in favour of data blocks.  If I could do that, 
> > this problem would be much, much smaller.

Usually people complain about the exact opposite of this.

> Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to do
> this?

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Jeff Garzik]

H. Peter Anvin wrote:

Randy Dunlap wrote:



BTW, yesterday my 2.4 patches were not published, but I noticed that
they were not even signed not bziped on hera. At first I simply thought
it was related, but right now I have a doubt. Maybe the automatic 
script

has been temporarily been disabled on hera too ?

The script that deals with the uploads also deals with the packaging -
so yes the problem is related.


and with the finger_banner and version info on www.kernel.org page?


Yes, they're all connected.

The load on *both* machines were up above the 300s yesterday, probably 
due to the release of a new Knoppix DVD.


The most fundamental problem seems to be that I can't tell currnt Linux 
kernels that the dcache/icache is precious, and that it's way too eager 
to dump dcache and icache in favour of data blocks.  If I could do that, 
this problem would be much, much smaller.


Have you messed around with /proc/sys/vm/vfs_cache_pressure?

Unfortunately that affects all three of: dcache, icache, and mbcache. 
Maybe we could split that sysctl in two (Andrew?), so that one sysctl 
affects dcache/icache and another affects mbcache.


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/

revert PIE randomization?

[Hugh Dickins]

There's a lot of gaps in my understanding, but I think 2.6.20-rc's
59287c0913cc9a6c75712a775f6c1c1ef418ef3b (randomize PIE binaries)
needs to be reverted for now.

Running any 2.6.20-rc kernel on i386 openSUSE 10.2, my kernel builds
occasionally fail with an ld.so error when building some .o or .ko
(then succeed when restarted in the same tree immediately after): e.g. 

  LD [M]  fs/vfat/vfat.o
Inconsistency detected by ld.so: rtld.c: 1217: dl_main:
 Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
make[2]: *** [fs/vfat/vfat.o] Error 127

I guessed a TLB problem, but no, bisection points to the random PIE
patch.  I've no idea how it arrives at the particular failure seen,
but the code does look wrong to me:

vaddr = elf_ppnt->p_vaddr;
if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) {
elf_flags |= MAP_FIXED;
} else if (loc->elf_ex.e_type == ET_DYN) {
/* Try and get dynamic programs out of the way of the
 * default mmap base, as well as whatever program they
 * might try to exec.  This is because the brk will
 * follow the loader, and is not movable.  */
if (current->flags & PF_RANDOMIZE)
load_bias = randomize_range(0x1,
ELF_ET_DYN_BASE,
0);
else
load_bias = ELF_ET_DYN_BASE;
load_bias = ELF_PAGESTART(load_bias - vaddr);
}
error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt,
elf_prot, elf_flags);

Isn't that randomization, anywhere from 0x1 to ELF_ET_DYN_BASE,
sure to place the ET_DYN from time to time just where the comment says
it's trying to avoid?  I assume that somehow results in the error reported.

No problem yet seen on x86_64 or ppc64, I suppose because the address
space is so much larger.  No problem seen before openSUSE 10.2, while
running 2.6.19-rc-mm which contained the patch: hmm, the oS /bin/bash
is a "shared object" rather than the familiar "executable", maybe that
has something to do with it.  No problem seen if I revert that patch;
nor if I add on the patch below, which does a much more limited
randomization - but my guess is others will improve upon it.

(I probably have my priorities wrong, going up from ELF_ET_DYN_BASE
because I don't like calling the top of a range _BASE: with stack
coming randomly down on most arches, maybe it'd better go below.

And I notice that Andi added a personality & ADDR_NO_RANDOMIZE check
into randomize_stack_top: I cannot see why that's necessary there,
but if it is, then should the ET_DYN case add it too?)

Hugh

--- 2.6.20-rc3/fs/binfmt_elf.c  2007-01-01 10:30:40.0 +
+++ linux/fs/binfmt_elf.c   2007-01-05 17:01:31.0 +
@@ -509,6 +509,12 @@ out:
 #define STACK_RND_MASK 0x7ff   /* with 4K pages 8MB of VA */
 #endif
 
+/*
+ * Though STACK_RND_MASK was introduced to govern randomizing the stack,
+ * it should also be appropriate to govern randomizing the ET_DYN base.
+ */
+#define ELF_ET_DYN_HIBASE (ELF_ET_DYN_BASE + ((STACK_RND_MASK+1)

Re: [ANNOUNCE] Guilt 0.16

[Jan Engelhardt]

On Jan 6 2007 13:46, Josef Sipek wrote:
>
>Guilt (Git Quilt) is a series of bash scripts which add a Mercurial

"I feel so guilty when using guilt!"

Oh well I should point out that people should give
tools a better naming. :-)
Prime examples are "Squid", "Icecream", and to a
lesser extent "Apache".
Perhaps gquilt?

>queues-like [1] functionality and interface to git.  The one distinguishing
>feature from other quilt-like porcelains, is the format of the patches
>directory. _All_ the information is stored as plain text - a series file and
>the patches (one per file). This easily lends itself to versioning the
>patches using any number of of SCMs.

-`J'
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] sysrq: showBlockedTasks is sysrq-W

[Randy Dunlap]

On Sat, 6 Jan 2007 20:19:29 +0100 Torsten Kaiser wrote:

> On Saturday 06 January 2007 19:25, Randy Dunlap wrote:
> > On Fri, 5 Jan 2007 20:36:05 +0100 Olaf Hering wrote:
> > >
> > > Weird, who failed to run this command before adding new stuff?!
> > > find * -type f -print0 | xargs -0 env -i grep -nw register_sysrq_key
> > >
> > > sysrq x is for xmon, see arch/powerpc/xmon/xmon.c
> > > Better switch the new stuff to 'z' or 'w'
> 
> Also used: 
> * c for kexec/crashdump and emac (drivers/net/ibm_emac/ibm_emac_debug.c)

ibm_emac is ppc 4xx only.  Does kexec/crashdump work on that
platform or are they mutually exclusive?

> * g for KGDB on ppc

Is that in mainline?


> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > SysRq showBlockedTasks is not done via B or T, it's done via W,
> > so put that in the Help message.
> >
> > It was previously done via X, but X is already used for Xmon
> > on powerpc platforms and this collision needs to be avoided.
> 
> > @@ -342,8 +342,8 @@ static struct sysrq_key_op *sysrq_key_ta
> > _mountro_op,  /* u */
> > /* May be assigned at init time by SMP VOYAGER */
> > NULL,   /* v */
> 
> Nice marker that v is in use.
> 
> > -   NULL,   /* w */
> > -   _showstate_blocked_op,/* x */
> > +   _showstate_blocked_op,/* w */
> > +   NULL,   /* x */
> 
> Wouldn't it be better to also put an marker for xmon here?
> And marker for 'c' and 'g' (maybe even 'h')?

OK, I'll do that.

> > NULL,   /* y */
> > NULL/* z */
> >  };
> 
> Also Documentation/sysrq.txt is not uptodate.
> 
> It is missing c (emac meaning), d (lockdep), n (un-RT), q (timer), w 
> (blocked) and x (xmon), but is documenting 'l' with no longer seems to be 
> implemented.

and I'll look into that.  Thanks.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-doc: what is the purpose of ""?

[Jan Engelhardt]

On Jan 6 2007 10:00, Randy Dunlap wrote:
>On Sat, 6 Jan 2007 09:44:39 -0500 (EST) Robert P. J. Day wrote:
>
>>   according to the kernel-doc HOWTO, the following should be
>> "highlighted" in some way if found in the extractable documentation of
>> your source file:
>> 
>>   '_name' - name of a structure (up to two words including 'struct')
>> 
>> but examples of that, at least in the HTML, are simply printed in
>> regular font prefixed with '&' -- i don't see that any "highlighting"
>> is being done.
>
>The struct name is highlighted in 'man' output mode.
>Not done in text or html output modes.

 is quite ambiguous when it comes near C code. So far,
I have only used e.g. %NULL (%CONSTANT) since % is not an unary 
operator in C. On the other side, no marking up of any "struct".

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

Re: [ANNOUNCE] Guilt 0.16

[Horst H. von Brand]

Josef Sipek <[EMAIL PROTECTED]> wrote:
> Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
> queues-like [1] functionality and interface to git.  The one distinguishing
> feature from other quilt-like porcelains, is the format of the patches
> directory. _All_ the information is stored as plain text - a series file and
> the patches (one per file). This easily lends itself to versioning the
> patches using any number of of SCMs.

A installation script/Makefile (or at least instructions) is missing...
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de InformaticaFono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile   Fax:  +56 32 2797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc3 regression? hdparm shows 1/2...1/3 the throughput

[Stefan Richter]

Tim Schmielau wrote:
> On Sat, 6 Jan 2007, Stefan Richter wrote:
> 
>> Did anybody else notice this?  The result of "hdparm -t" under 2.6.20-rc
>> seems to be less than half of what you get on 2.6.19.  However, disk I/O
>> did *not* get slower according to bonnie++.
> 
> yes. See
>   http://lkml.org/lkml/2007/1/2/75
> for the solution.
> 
> Tim

Thanks. I should have remembered that.

# hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   10864 MB in  2.00 seconds = 5440.10 MB/sec
 Timing buffered disk reads:   58 MB in  3.06 seconds =  18.94 MB/sec
# cat /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   10680 MB in  2.00 seconds = 5347.20 MB/sec
 Timing buffered disk reads:  148 MB in  3.02 seconds =  49.03 MB/sec

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

IP Networking: ip_queue_xmit, sockets and TCP output question (Linux 2.6.17)

[Manuel Feier]

Dear Linux kernel hackers, 

I'm trying to extend the kernel in a way that I am able to collect
user-based IP networking information (e.g. which system user generated
how much IP traffic). Unfortunately this doesn't seem to be a topic that
is well documented, so I try my luck here.

For capturing the outgoing TCP traffic, I found the function
"ip_queue_xmit" (net/ipv4/ip_output.c) would be adequate. I added the
following code to the function right after the line
skb->priority = sk->sk_priority; 

if (sk && sk->sk_socket) {
ip4acct_user_sent(SOCK_INODE(sk->sk_socket)->i_uid,
ntohs(iph->tot_len),6); 
}
else {
ip4acct_user_sent(IPACCT_NOUSER,
ntohs(iph->tot_len),6);
}

This seems to work well if I send a small amount of TCP
data (512 bytes) with nc from an unprivileged user of that host. If I
open a website (lots of data / images) however, a few packets
don't appear to be be related to a socket and
hence are accounted to NOUSER (~2 %). If I continuously keep opening
multiple webpages at a time, some outgoing TCP traffic even gets
accounted to user root (uid 0) instead of the unprivileged user that
owns the webbrowser.

For debugging, I logged the source and destination address of those
packets that go into the else{} branch above, and it appears these
are packets that clearly belong to the webbrowser connection.

I now wonder what I am getting wrong about the function ip_queue_xmit:

- How can it be that a TCP/IP packet which belongs to a http
transmission has no socket that could be found with the first function
above?
- How can it be that (seemingly under increased network load) another
socket owner is returned than the one responsible for the load?

I'd appreciate your help very much, also ideas about debugging or
conceptual hints.

Thanks,

Manuel

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

Re: [KORG] Re: kernel.org lies about latest -mm kernel

[Nicholas Miell]

On Sat, 2007-01-06 at 11:18 -0800, H. Peter Anvin wrote:
> Randy Dunlap wrote:
> >
> >>> BTW, yesterday my 2.4 patches were not published, but I noticed that
> >>> they were not even signed not bziped on hera. At first I simply thought
> >>> it was related, but right now I have a doubt. Maybe the automatic script
> >>> has been temporarily been disabled on hera too ?
> >> The script that deals with the uploads also deals with the packaging -
> >> so yes the problem is related.
> > 
> > and with the finger_banner and version info on www.kernel.org page?
> 
> Yes, they're all connected.
> 
> The load on *both* machines were up above the 300s yesterday, probably 
> due to the release of a new Knoppix DVD.
> 
> The most fundamental problem seems to be that I can't tell currnt Linux 
> kernels that the dcache/icache is precious, and that it's way too eager 
> to dump dcache and icache in favour of data blocks.  If I could do that, 
> this problem would be much, much smaller.
> 
>   -hpa

Isn't setting the vm.vfs_cache_pressure sysctl below 100 supposed to do
this?

-- 
Nicholas Miell <[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: [KORG] Re: kernel.org lies about latest -mm kernel

[Willy Tarreau]

On Sat, Jan 06, 2007 at 11:18:37AM -0800, H. Peter Anvin wrote:
> Randy Dunlap wrote:
> >
> >>>BTW, yesterday my 2.4 patches were not published, but I noticed that
> >>>they were not even signed not bziped on hera. At first I simply thought
> >>>it was related, but right now I have a doubt. Maybe the automatic script
> >>>has been temporarily been disabled on hera too ?
> >>The script that deals with the uploads also deals with the packaging -
> >>so yes the problem is related.
> >
> >and with the finger_banner and version info on www.kernel.org page?
> 
> Yes, they're all connected.
> 
> The load on *both* machines were up above the 300s yesterday, probably 
> due to the release of a new Knoppix DVD.

I have one trivial idea : would it help to use 2 addresses to server data,
one for pure kernel usage (eg: git, rsync) and one with other stuff such
as DVDs, but with a low limit on the number of concurrent connections ?

> The most fundamental problem seems to be that I can't tell currnt Linux 
> kernels that the dcache/icache is precious, and that it's way too eager 
> to dump dcache and icache in favour of data blocks.  If I could do that, 
> this problem would be much, much smaller.

I often have this problem on some of my machines after slocate runs.
Everything is consumed in dcache/icache and no data blocks are cacheable
anymore. I never found a way to tell the kernel to assign a higher prio
to data than to [di]cache. To remedy this, I wrote this stupid program that
I run when I need to free memory. It does simply allocate the memory size
I ask, which causes a flush of the [di]caches, and when it exits, this
memory is usable again for data blocks. 

I'm not sure it would be easy to automatically run such a thing, but
maybe it could sometimes help when the [id]caches are too fat.

Willy

#include 
main(int argc, char **argv) {
  unsigned long int i,k=0, max;
  char *p;

  max = (argc>1) ? atol(argv[1]) : 102400; // default to 100 MB
  printf("Allocating %lu kB...\n",max);
  while (((p=(char *)malloc(1048576))!=NULL) && (k+1024<=max)) {
for (i=0;i<256;p[4096*i++]=0); /* mark block dirty */
k+=1024;
fprintf(stderr,"\r%d kB allocated",k);
  }
  fprintf(stderr,"\nMemory freed.\n");
  exit(0);
}

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

Re: [patch] paravirt: isolate module ops

[Christoph Hellwig]

On Sun, Jan 07, 2007 at 03:18:45AM +1100, Rusty Russell wrote:
> PS.  drm_memory.h has a "drm_follow_page": this forces us to uninline
> various page tables ops.  Can this use follow_page() somehow, or do we
> need an "__follow_page" export for this case?

Not if avoidable.  And it seems avoidable as drm really should be using
vmalloc_to_page.  Untested patch below:


Index: linux-2.6/drivers/char/drm/drm_memory.c
===
--- linux-2.6.orig/drivers/char/drm/drm_memory.c2007-01-06 
20:21:07.0 +0100
+++ linux-2.6/drivers/char/drm/drm_memory.c 2007-01-06 20:29:03.0 
+0100
@@ -211,6 +211,23 @@
 }
 #endif  /*  0  */
 
+static int is_agp_mapping(void *pt, unsigned long size, drm_device_t *dev)
+{
+   unsigned long addr = (unsigned long)pt;
+
+   if (addr >= VMALLOC_START && addr < VMALLOC_END) {
+   unsigned long phys;
+   drm_map_t *map;
+
+   phys = page_to_phys(vmalloc_to_page(pt)) + offset_in_page(pt);
+   map = drm_lookup_map(phys, size, dev);
+   if (map && map->type == _DRM_AGP)
+   return 1;
+   }
+
+   return 0;
+}
+
 void drm_ioremapfree(void *pt, unsigned long size,
   drm_device_t * dev)
 {
@@ -219,21 +236,11 @@
 * routines for handling mappings in the AGP space.  Hopefully this can 
be done in
 * a future revision of the interface...
 */
-   if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture
-   && ((unsigned long)pt >= VMALLOC_START
-   && (unsigned long)pt < VMALLOC_END)) {
-   unsigned long offset;
-   drm_map_t *map;
-
-   offset = drm_follow_page(pt) | ((unsigned long)pt & ~PAGE_MASK);
-   map = drm_lookup_map(offset, size, dev);
-   if (map && map->type == _DRM_AGP) {
-   vunmap(pt);
-   return;
-   }
-   }
-
-   iounmap(pt);
+   if (drm_core_has_AGP(dev) && dev->agp && dev->agp->cant_use_aperture &&
+   is_agp_mapping(pt, size, dev))
+   vunmap(pt);
+   else
+   iounmap(pt);
 }
 EXPORT_SYMBOL(drm_ioremapfree);
 
Index: linux-2.6/drivers/char/drm/drm_memory.h
===
--- linux-2.6.orig/drivers/char/drm/drm_memory.h2007-01-06 
20:21:07.0 +0100
+++ linux-2.6/drivers/char/drm/drm_memory.h 2007-01-06 20:26:50.0 
+0100
@@ -55,23 +55,6 @@
 #  define PAGE_AGP PAGE_KERNEL
 # endif
 #endif
-
-static inline unsigned long drm_follow_page(void *vaddr)
-{
-   pgd_t *pgd = pgd_offset_k((unsigned long)vaddr);
-   pud_t *pud = pud_offset(pgd, (unsigned long)vaddr);
-   pmd_t *pmd = pmd_offset(pud, (unsigned long)vaddr);
-   pte_t *ptep = pte_offset_kernel(pmd, (unsigned long)vaddr);
-   return pte_pfn(*ptep) << PAGE_SHIFT;
-}
-
-#else  /* __OS_HAS_AGP */
-
-static inline unsigned long drm_follow_page(void *vaddr)
-{
-   return 0;
-}
-
 #endif
 
 void *drm_ioremap(unsigned long offset, unsigned long size,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc3-mm1: umount reiser4 FS stuck in D state

[Vladimir V. Saveliev]

Hello

On Saturday 06 January 2007 13:58, Laurent Riffard wrote:
> Le 05.01.2007 07:02, Andrew Morton a écrit :
> > Temporarily at
> > 
> > http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1/
> > 
> > will appear later at
> > 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/
> 
> Hello,
> 
> got this with 2.6.20-rc3-mm1:
> 
> ===
> SysRq : Show Blocked State
> 
>  freesibling
>   task PCstack   pid father child younger older
> umountD C013135E  6044  1168   1150 (NOTLB)
>de591ae4 0086 de591abc c013135e dff979c8 c012a6fe 0046 
> 0007 
>dfd94ac0 128d3000 0026  dfd94bcc dff979c8 de591ae4 
> dffda038 
>0002 dff979c0 dff979bc dff979c8 de591b10 c012d600 dff979f8 
>  
> Call Trace:
>  [] synchronize_qrcu+0x70/0x8c
>  [] __make_request+0x4c/0x29b
>  [] generic_make_request+0x1b0/0x1de
>  [] submit_bio+0xda/0xe2
>  [] write_jnodes_to_disk_extent+0x920/0x974 [reiser4]
>  [] update_journal_footer+0x29f/0x2b7 [reiser4]
>  [] write_tx_back+0x149/0x185 [reiser4]
>  [] reiser4_write_logs+0xea4/0xfd2 [reiser4]
>  [] try_commit_txnh+0x7e6/0xa4f [reiser4]
>  [] reiser4_txn_end+0x148/0x3cf [reiser4]
>  [] reiser4_txn_restart+0xb/0x1a [reiser4]
>  [] reiser4_txn_restart_current+0x73/0x75 [reiser4]
>  [] force_commit_atom+0x258/0x261 [reiser4]
>  [] txnmgr_force_commit_all+0x406/0x697 [reiser4]
>  [] release_format40+0x10c/0x193 [reiser4]
>  [] reiser4_put_super+0x134/0x16a [reiser4]
>  [] generic_shutdown_super+0x55/0xd8
>  [] kill_block_super+0x20/0x32
>  [] deactivate_super+0x3f/0x51
>  [] mntput_no_expire+0x42/0x5f
>  [] path_release_on_umount+0x15/0x18
>  [] sys_umount+0x1a3/0x1cb
>  [] sys_oldumount+0x19/0x1b
>  [] sysenter_past_esp+0x5f/0x99
>  ===
> 
> Scenario:
> - umount a reiser4 FS (no need to write something before)

Hmm, I can not reproduce this with 2.6.20-rc3-mm1. Probably I need to config 
the kernel more close to your system.

> 
> Earlier kernels were OK.
> 
> I tested Frederik Deweerdt's patch for "lockdep: unbalance at 
> generic_sync_sb_inodes", it did not help.
> 
> I think I'll a give a try to 
> http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1x.bz2 (basically 
> 2.6.20-rc3-mm1, minus git-block.patch).
> 
> .config attached
> 


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