Re: 2.6.23-rc7 - _random_ IRQ23 : nobody cared

[Paul Rolland]

Hi David,

On Mon, 24 Sep 2007 23:56:59 +0930
David Newall <[EMAIL PROTECTED]> wrote:

> Paul Rolland "(???) wrote:
> > Hell, IRQ 23 is shared between libata and my modem !!!
> >   
> 
> Tried using the modem?

When no problem is reported, both the libata part and the modem are OK.
When the problem is reported, at that time, only libata is handling IRQ23
(the modem is a WinModem, and the driver is an out-kernel module), this 
is still kernel boot time, and the disabling of the IRQ makes my machine
unable to complete the boot process (too many disk timeout).

It could be good to be able to delay the disabling of an IRQ something long
enough to allow all the modules to be loaded...

Paul

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

Re: 2.6.23-rc7-mm1: panic in scheduler

[Balbir Singh]

On 9/25/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Exactly same call trace is produced over IA64 Madison (up to 9M cache) with 8 
> cpu's.
> --

Hi, Kamalesh,

Could you please reproduce the problem or share the steps to reproduce
the problem?

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

Re: [PATCH] Fix CONFIG_NOHIGHMEM for extended crashkernel command line

[Andrew Morton]

On Tue, 25 Sep 2007 08:55:29 +0200 Bernhard Walle <[EMAIL PROTECTED]> wrote:

> @@ -381,6 +381,20 @@ extern unsigned long __init setup_memory
>  extern void zone_sizes_init(void);
>  #endif /* !CONFIG_NEED_MULTIPLE_NODES */
>  
> +

Only one line is needed between functions, please.

> +#ifdef CONFIG_HIGHMEM
> +static inline unsigned long long get_total_mem(void)
> +{
> + return (max_low_pfn + highend_pfn - highstart_pfn) << PAGE_SHIFT;
> +}
> +#else
> +static inline unsigned long long get_total_mem(void)
> +{
> + return max_low_pfn << PAGE_SHIFT;
> +}
> +#endif
> +
> +

Full of bugs.  (unsigned long << foo) returns an unsigned long.  With >4G
there will be truncation.

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

Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

[Jeff Garzik]

Peer Chen wrote:

Add the ahci controller legacy mode support to sata_nv.
Move the DIDs of legacy mode from ahci.c to sata_nv.c

The patch base on kernel 2.6.23-rc8

Signed-off-by: Peer Chen <[EMAIL PROTECTED]>


I don't understand why these are being moved?

If an interface can be driven via the AHCI driver, that is greatly 
preferred over the sata_nv driver.


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: 2.6.23-rc7 + radeonfb/s2ram

[Mihai Donțu]

On Monday 24 September 2007, Andreas Herrmann wrote:
> Have you tried to boot your kernel with
> 
>video=radeonfb:noaccel
> 
> I usual add this kernel parameter when running radeonfb and X.
> 
> Otherwise I've observed the same symptoms (e.g. with my radeon card
> at home: Radeon X300SE, 1002:5b70).

It works. Golden option. Should be documented somewhere.

Thanks,

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jan Engelhardt]

On Sep 24 2007 16:25, Jaswinder Singh wrote:

>So it is obsolete for user's point of view, right ?

.config is human-readable and serves as input for kconfig,

and autoconf.h is kconfig's output for the C binding that
you do not mess with.

Neither is obsolete, end of story.

If Linux were to have Perl bindings, there would probably
be an autoconf.pl.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Damien Wyart]

Hello,

After testing rc8, I noticed that I couldn't power off the computer
directly, it only got halted and I had to press the power button
manually. Just before displaying "System halted", the following message
is displayed:

  ACPI : PCI interrupt for device :02:08.0 disabled

I had to first revert 5a50fe709d527f31169263e36601dd83446d5744 then
f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to
recover previous behaviour.

Attached are the dmesg for rc7, rc8 and rc8 with the two patches
reverted.

-- 
Damien Wyart
Linux version 2.6.23-rc7-24092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 
(Debian 4.2.1-5)) #1 SMP Mon Sep 24 07:35:33 CEST 2007
BIOS-provided physical RAM map:
 BIOS-e820:  - 000a (usable)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 7ff74000 (usable)
 BIOS-e820: 7ff74000 - 7ff76000 (ACPI NVS)
 BIOS-e820: 7ff76000 - 7ff97000 (ACPI data)
 BIOS-e820: 7ff97000 - 8000 (reserved)
 BIOS-e820: fec0 - fec1 (reserved)
 BIOS-e820: fecf - fecf1000 (reserved)
 BIOS-e820: fed2 - fed9 (reserved)
 BIOS-e820: fee0 - fee1 (reserved)
 BIOS-e820: ffb0 - 0001 (reserved)
1151MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000fe710
Entering add_active_range(0, 0, 524148) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   229376
  HighMem229376 ->   524148
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 ->   524148
On node 0 totalpages: 524148
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 1760 pages used for memmap
  Normal zone: 223520 pages, LIFO batch:31
  HighMem zone: 2302 pages used for memmap
  HighMem zone: 292470 pages, LIFO batch:31
  Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000FEB90, 0014 (r0 DELL  )
ACPI: RSDT 000FD1CA, 0034 (r1 DELL8300   8 ASL61)
ACPI: FACP 000FD1FE, 0074 (r1 DELL8300   8 ASL61)
ACPI: DSDT FFFC6E75, 2426 (r1   DELLdt_ex 1000 MSFT  10D)
ACPI: FACS 7FF74000, 0040
ACPI: SSDT FFFC929B, 00A7 (r1   DELLst_ex 1000 MSFT  10D)
ACPI: APIC 000FD272, 006C (r1 DELL8300   8 ASL61)
ACPI: BOOT 000FD2DE, 0028 (r1 DELL8300   8 ASL61)
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8800 (gap: 8000:7ec0)
Built 1 zonelists in Zone order.  Total pages: 520054
Kernel command line: root=/dev/sdb2 ro vga=0x307 selinux=0 elevator=cfq 
video=vesafb:mtrr:3 
mapped APIC to b000 (fee0)
mapped IOAPIC to a000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0425000 soft=c0423000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 2992.558 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 815k 
data, 192k init, 1179088k highmem)
virtual kernel memory layout:
fixmap  : 0xfff9b000 - 0xf000   ( 400 kB)
pkmap   : 0xff80 - 0xffc0   (4096 kB)
vmalloc : 0xf880 - 0xff7fe000   ( 111 MB)
lowmem  : 0xc000 - 0xf800   ( 896 MB)
  .init : 0xc03f - 0xc042   ( 192 kB)
  .data : 0xc031ff34 - 0xc03ebd04   ( 815 kB)
  .text : 0xc010 - 0xc031ff34   (2175 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1
Calibrating delay using timer specific routine.. 5987.54 BogoMIPS (lpj=2993774)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff    041d 
  
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 

Re: [PATCH] Patches for tiny 386 kernels, again. Linux kernel 2.6.22.7

[Jan Engelhardt]

On Sep 24 2007 15:09, Dave Jones wrote:
>
> > +#if defined(__i386__) && defined(CONFIG_DMI)
> > dmi_check_system(acpi_dmi_table);
> >  #endif
> >  
> > +#ifdef CONFIG_DMI
> > dmi_scan_machine();
> > +#endif
> >  
> > +#ifdef CONFIG_DMI
> > /* Check and install the TSC clocksource */
> > dmi_check_system(bad_tsc_dmi_table);
> > +#endif
> >  
> > +#ifdef CONFIG_DMI
> > dmi_check_system(acpi_osl_dmi_table);
> > +#endif
> 
>Instead of adding all these ifdefs, we could just define
>add something along the lines of..
>
>#ifndef CONFIG_DMI
>#define dmi_check_system do {} while (0)
>#endif
>
>in some header, which hides the uglies away from the code
>whilst having the same net effect.

Need #define dmi_check_system(x) otherwise you get

/* Check and install the TSC clocksource */
do {} while (0) (bad_tsc_dmi_table);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc7-mm1

[Torsten Kaiser]

On 9/24/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Can your check whether 2.6.23-rc7 +
> http://tglx.de/projects/hrtimers/2.6.23-rc7/patch-2.6.23-rc7-hrt1.patch
>
> works for you ?

Yes, powers off normally.

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

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Andrew Morton]

On Tue, 25 Sep 2007 08:51:09 +0200 Damien Wyart <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> After testing rc8, I noticed that I couldn't power off the computer
> directly, it only got halted and I had to press the power button
> manually. Just before displaying "System halted", the following message
> is displayed:
> 
>   ACPI : PCI interrupt for device :02:08.0 disabled
> 
> I had to first revert 5a50fe709d527f31169263e36601dd83446d5744 then
> f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to
> recover previous behaviour.

Let's add some cc's.

> Attached are the dmesg for rc7, rc8 and rc8 with the two patches
> reverted.

"diff -u dmesg.rc8_revert dmesg.rc8" says:

--- dmesg.rc8_revert2007-09-25 00:31:33.0 -0700
+++ dmesg.rc8   2007-09-25 00:31:30.0 -0700
@@ -1,4 +1,4 @@
-Linux version 2.6.23-rc8-25092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 
(Debian 4.2.1-5)) #2 SMP Tue Sep 25 08:31:09 CEST 2007
+Linux version 2.6.23-rc8-25092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 
(Debian 4.2.1-5)) #1 SMP Tue Sep 25 07:27:10 CEST 2007
 BIOS-provided physical RAM map:
  BIOS-e820:  - 000a (usable)
  BIOS-e820: 000f - 0010 (reserved)
@@ -72,18 +72,18 @@
 console [tty0] enabled
 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 815k 
data, 192k init, 1179088k highmem)
+Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 816k 
data, 192k init, 1179088k highmem)
 virtual kernel memory layout:
 fixmap  : 0xfff9b000 - 0xf000   ( 400 kB)
 pkmap   : 0xff80 - 0xffc0   (4096 kB)
 vmalloc : 0xf880 - 0xff7fe000   ( 111 MB)
 lowmem  : 0xc000 - 0xf800   ( 896 MB)
   .init : 0xc03f - 0xc042   ( 192 kB)
-  .data : 0xc031fd5c - 0xc03ebd04   ( 815 kB)
-  .text : 0xc010 - 0xc031fd5c   (2175 kB)
+  .data : 0xc031fcd4 - 0xc03ebd04   ( 816 kB)
+  .text : 0xc010 - 0xc031fcd4   (2175 kB)
 Checking if this processor honours the WP bit even in supervisor mode... Ok.
 SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1
-Calibrating delay using timer specific routine.. 5987.66 BogoMIPS (lpj=2993833)
+Calibrating delay using timer specific routine.. 5987.60 BogoMIPS (lpj=2993802)
 Mount-cache hash table entries: 512
 CPU: After generic identify, caps: bfebfbff    
041d   
 monitor/mwait feature present.
@@ -104,7 +104,7 @@
 Booting processor 1/1 eip 2000
 CPU 1 irqstacks, hard=c0426000 soft=c0424000
 Initializing CPU#1
-Calibrating delay using timer specific routine.. 5984.18 BogoMIPS (lpj=2992093)
+Calibrating delay using timer specific routine.. 5984.16 BogoMIPS (lpj=2992084)
 CPU: After generic identify, caps: bfebfbff    
041d   
 monitor/mwait feature present.
 CPU: Trace cache: 12K uops, L1 D cache: 16K
@@ -116,7 +116,7 @@
 CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
 CPU1: Thermal monitoring enabled
 CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03
-Total of 2 processors activated (11971.85 BogoMIPS).
+Total of 2 processors activated (11971.77 BogoMIPS).
 ENABLING IO-APIC IRQs
 ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
 checking TSC synchronization [CPU#0 -> CPU#1]: passed.
@@ -279,6 +279,7 @@
 EXT3-fs: mounted filesystem with ordered data mode.
 VFS: Mounted root (ext3 filesystem) readonly.
 Freeing unused kernel memory: 192k freed
+input: PC Speaker as /devices/platform/pcspkr/input/input4
 sr0: scsi3-mmc drive: 1x/48x cd/rw xa/form2 cdda tray
 Uniform CD-ROM driver Revision: 3.20
 sr 1:0:0:0: Attached scsi CD-ROM sr0
@@ -287,7 +288,6 @@
 usbcore: registered new interface driver usbfs
 usbcore: registered new interface driver hub
 usbcore: registered new device driver usb
-input: PC Speaker as /devices/platform/pcspkr/input/input4
 parport_pc 00:0a: reported by Plug and Play ACPI
 parport0: PC-style at 0x378 (0x778), irq 7, using FIFO 
[PCSPP,TRISTATE,COMPAT,ECP]
 USB Universal Host Controller Interface driver v3.0
@@ -299,46 +299,42 @@
 usb usb1: configuration #1 chosen from 1 choice
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 2 ports detected
-ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 20
-PCI: Setting latency timer of device :00:1d.1 to 64
-uhci_hcd :00:1d.1: UHCI Host Controller
-uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 2
-uhci_hcd :00:1d.1: irq 20, io base 0xff60
+ACPI: PCI Interrupt :00:1d.7[D] -> GSI 23 (level, low) -> IRQ 20
+PCI: Setting latency timer of device :00:1d.7 to 64
+ehci_hcd :00:1d.7: EHCI Host Controller
+ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 2
+ehci_hcd :00:1d.7: debug port 1
+PCI: cache line size of 128 is not supported b

Re: [git] CFS-devel, latest code

[Mike Galbraith]

On Tue, 2007-09-25 at 08:10 +0200, Mike Galbraith wrote:
>  no news is good news.

Darn, have news: latency thing isn't dead.  Two busy loops, one at nice
0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
latencies below for nice -5 Xorg.  Didn't kill the box though.

se.wait_max  :10.068169
se.wait_max  : 7.465334
se.wait_max  :   135.501816
se.wait_max  : 0.884483
se.wait_max  :   144.218955
se.wait_max  :   128.578376
se.wait_max  :93.975768
se.wait_max  : 4.965965
se.wait_max  :   113.655533
se.wait_max  : 4.301075

sched_debug (attached) is.. strange.

-Mike


sched_debug.gz
Description: GNU Zip compressed data

Re: [PATCH 1/1] Kernel compile bug in 2.6.22.6/7 {maybe more} ARM/StrongARM

[Russell King]

On Mon, Sep 24, 2007 at 05:53:57PM -0500, [EMAIL PROTECTED] wrote:
> I was building a kernel for an iPaq {SA1110} and ran into this.
> 
> linux-2.6.22.7/arch/arm/mach-sa1100/generic.c:
> Has a: #include 
> Then afterwards there is a: #if defined(CONFIG_CPU_FREQ_SA1100) ||
> defined(CONFIG_CPU_FREQ_SA1110)
> who's else section redefines the cpufreq_get function inhereited from
> the header
> 
> I'm guessing no one ever ended up in the "else" section until now, and
> that the header was added some time ago and no one caught this.
> This patch worked for me to get rid of the compile time problems.  I'm
> having issues with the kernel, but as far as I can tell they are form
> the Frame buffer and not because of this.  If this assessment is correct
> {the not needing this code anymore} then please pass this along so it
> makes it into an upcoming release.
> 
> --- linux-2.6.22.7/arch/arm/mach-sa1100/generic.c.orig  2007-09-24
> 17:36:21.0 -0500
> +++ linux-2.6.22.7/arch/arm/mach-sa1100/generic.c   2007-09-24
> 17:40:02.0 -0500
> @@ -107,15 +107,6 @@ unsigned int sa11x0_getspeed(unsigned in
> return cclk_frequency_100khz[PPCR & 0xf] * 100;
>  }
> 
> -#else
> -/*
> - * We still need to provide this so building without cpufreq works.
> - */
> -unsigned int cpufreq_get(unsigned int cpu)
> -{
> -   return cclk_frequency_100khz[PPCR & 0xf] * 100;
> -}
> -EXPORT_SYMBOL(cpufreq_get);
>  #endif
> 
>  /*

No.  That code is required - the StrongARM 1100 framebuffer driver
*needs* to know what the CPU frequency is so it can set the pixel
clock divisor.

The real problem is the silly people who added this to cpufreq.h:

#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_get(unsigned int cpu);
#else
static inline unsigned int cpufreq_quick_get(unsigned int cpu)
{
return 0;
}
static inline unsigned int cpufreq_get(unsigned int cpu)
{
return 0;
}
#endif

which utterly bogus.

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

Re: [git] CFS-devel, latest code

[Andrew Morton]

On Mon, 24 Sep 2007 23:45:37 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:

> The latest sched-devel.git tree can be pulled from:
>  
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git

This doornails the Vaio.  After grub handover the screen remains black
and the fan goes whir.

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

Re: 2.6.23-rc7-mm1

[Thomas Gleixner]

On Tue, 2007-09-25 at 09:32 +0200, Torsten Kaiser wrote:
> On 9/24/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > Can your check whether 2.6.23-rc7 +
> > http://tglx.de/projects/hrtimers/2.6.23-rc7/patch-2.6.23-rc7-hrt1.patch
> >
> > works for you ?
> 
> Yes, powers off normally.

Ok, so it's probably some merge artifact in -mm. We'll get this sorted
out once Len has his new tree available.

tglx


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

Re: sys_chroot+sys_fchdir Fix

[David Newall]

Serge E. Hallyn wrote:

Quoting David Newall ([EMAIL PROTECTED]):
  
It might be tidy if pivot_root could be used (instead of a hack based on a 
chroot bug), but it'd still be unportable.



It can.

Please re-read my previous msg.


I read it.  Currently pivot_root can't be used to affect a single 
process.  It can be modified; obviously.  Maybe it should be, too, but 
is there a need for that?

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

Re: [RFC] New kernel-message logging API

[linux]

>> Even the "kp_" prefix is actually pretty unnecessary.  It's "info"
>> and a human-readable string that make it recognizable as a log message.

> While I agree a prefix isn't necessary, info, warn, err
> are already frequently #define'd and used.
>
> kp_ isn't currently in use.
> 
> $ egrep -r -l --include=*.[ch] 
> "^[[:space:]]*#[[:space:]]*define[[:space:]]+(info|err|warn)\b" * | wc -l
> 29

Sorry for being unclear.  I wasn't seriously recommending no prefix,
due to name collisions (exactly your point), but rather saying that no
prefix is necessary for human understanding.

Something to avoid the ambiguity is still useful.  I was just saying
that it can be pretty much anything withouyt confusing the casual
reader.

We're in violent agreement, I just didn't say it very well the first
time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

[Peer Chen]

We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being 
load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI being 
selected, which will verify if our legacy mode work well and have additional 
option if there is any
bug for the ahci mode.

 
Peer Chen
2007-09-25

-
·¢¼þÈË£ºJeff Garzik
·¢ËÍÈÕÆÚ£º2007-09-25 15:08:45
ÊÕ¼þÈË£ºPeer Chen
³­ËÍ£ºlinux-kernel; linux-ide; akpm
Ö÷Ì⣺Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

Peer Chen wrote:
> Add the ahci controller legacy mode support to sata_nv.
> Move the DIDs of legacy mode from ahci.c to sata_nv.c
> 
> The patch base on kernel 2.6.23-rc8
> 
> Signed-off-by: Peer Chen <[EMAIL PROTECTED]>

I don't understand why these are being moved?

If an interface can be driven via the AHCI driver, that is greatly 
preferred over the sata_nv driver.

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/

s2ram + usb

[Mihai Donțu]

Hi,

I've been trying to make suspend-to-ram part of my day-by-day life, but there
are still some issues. For example, I did:

$ sync && echo "mem" >/sys/power/state

(I don't know if sync is needed or helps, but I do it anyway - I *really* love 
my data)

unplugged everything (power, mouse, network cable, ...), got to work, plugged
everything back, power up, dmesg:

[1.367928] Restarting tasks ... <4>ohci_hcd :00:13.1: Unlink after 
no-IRQ?  Controller is probably using the wrong IRQ.
[1.402715] done.
[1.627564] tg3: eth0: Link is up at 100 Mbps, full duplex.
[1.627568] tg3: eth0: Flow control is on for TX and on for RX.
[   10.448935] usb 3-3: USB disconnect, address 3
[   10.811866] ohci_hcd :00:13.1: IRQ INTR_SF lossage
[   10.811871] ohci_hcd :00:13.1: leak ed 810037991050 (#00) state 0 
(has tds)

After this my mouse doesn't work and I'm unable to reboot/poweroff my laptop 
(not
even alt+sysreq+b work). It locks hard.

I have been playing with pci=assign-busses (thinking about IRQ-s here) and 
pci=noacpi.
No result. However, with pci=assign-busses I got this (a small variation of the 
message above):

[1.743528] Restarting tasks ... <3>hub 1-0:1.0: port 5 disabled by hub 
(EMI?), re-enabling...
[1.743563] usb 1-5: USB disconnect, address 3
[1.782485] usb 1-5: new high speed USB device using ehci_hcd and address 6
[1.785747] done.
[1.831805] usb 1-5: configuration #1 chosen from 1 choice
[1.834418] scsi3 : SCSI emulation for USB Mass Storage devices
[1.834741] usb-storage: device found at 6
[1.834785] usb-storage: waiting for device to settle before scanning
[1.845293] ohci_hcd :00:13.1: Unlink after no-IRQ?  Controller is 
probably using the wrong IRQ.

I looked in 'kernel-parameters.txt" and in "x86_86/boot-options.txt" but I did 
not find
anything that could help (that is: usb related).

Has anyone else experienced this?

I'll try to pull 2.6.23-rc8 tonight and play with it. I've seen some ACPI 
related stuff
in ChangeLog. Who knows ...

Thanks,

-- 
Mihai Donțu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix messed hunks in generic_setlease

[Pavel Emelyanov]

I have noticed, that one hunk was lost and one duplicated 
during merging the fix-potential-oops-in-generic_setlease(-xxx) 
patches. One of the fixes is already in the hot-fixes, but the
second one is still lost.

The returned pointer was not the one allocated, but some temporary
used to scan through the inode's locks list. This caused and OOPS 
during Kamalesh's testing.

Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>

---

diff --git a/fs/locks.c b/fs/locks.c
index c0fe71a..c1198e3 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1423,7 +1418,7 @@ int generic_setlease(struct file *filp, 
locks_copy_lock(new_fl, lease);
locks_insert_lock(before, new_fl);
 
-   *flp = fl;
+   *flp = new_fl;
return 0;
 
 out:

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

Re: [PATCH 1/4] module: implement module_inhibit_unload()

[Cornelia Huck]

On Tue, 25 Sep 2007 14:38:38 +1000,
Rusty Russell <[EMAIL PROTECTED]> wrote:

> Have you tested that *this* path works?  Let's take your first change as
> an example:
> 
> +   mutex_lock(&gdev->reg_mutex);
> +   __ccwgroup_remove_symlinks(gdev);
> +   device_unregister(dev);
> +   mutex_unlock(&gdev->reg_mutex);
> 
> Now, are you sure that calling cleanup_ccwgroup just after
> device_unregister() works?
> 
> static void __exit
> cleanup_ccwgroup (void)
> {
>   bus_unregister (&ccwgroup_bus_type);
> }
> 

ccwgroup is a bit special. The ccwgroup drivers (say, qeth) will
unregister their ccwgroup_driver in their exit function. ccwgroup will
then unregister all devices bound to this driver (a ccwgroup device
without a driver does not make sense, since they are artifically
created by writing to a 'group' attribute provided by the driver). This
makes sure that ccwgroup cannot be unloaded while there are still
devices on the bus, so your example won't hit.

> > I think it's too much work for the
> > users of the API and it will be easy to pass the wrong @owner and go
> > unnoticed.
> 
> But your shortcut insists that all module authors be aware that
> functions can be running after exit() is called.  That's a recipe for
> instability and disaster.

There are already problems like this with ->release().


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

Re: [2.6.22] circular lock detected

[Peter Zijlstra]

On Mon, 3 Sep 2007 16:01:35 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:

> On Mon 03-09-07 05:49:59, Andrew Morton wrote:
> > > On Mon, 3 Sep 2007 14:27:02 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> > > > > On Fri, 24 Aug 2007 23:00:33 +0200 Folkert van Heusden <[EMAIL 
> > > > > PROTECTED]> wrote:

> > > > Has been reported before, but I don't recall whether we fixed it.  Jan,
> > > > do you know>?
> > >   I think we at least found a solution: Teach lockdep that I_MUTEX for
> > > different filesystems is different. Peter Zilstra wrote a patch for that
> > > and Folkert even confirmed that it fixes the problem for him. I'm not
> > > sure what happened with the patch afterwards though. Adding Peter to CC
> > > :).
> > 
> > But this is a tty_lock-versus-dqptr_sem ranking error.  Unrelated to 
> > i_mutex?
>   The final report is for this ranking but the locking chain (if I understand 
> it
> right) is:
> tty_mutex (con_close) -> i_mutex (sysfs: remove_subdir)
> i_mutex (do_truncate) -> i_alloc_sem (notify_change) -> truncate_mutex 
> (ext3_truncate)
> truncate_mutex (ext3_get_blocks_handle) -> dqptr_sem (dquot_alloc_space)
> 
> So it complains about tty_mutex vs dqptr_sem (I don't know why it does not
> complain about tty_mutex vs i_mutex) but the wrong link in the chain is
> that i_mutex from remove_subdir() [sysfs] and i_mutex from do_truncate()
> [ext3] are different and should never depend on each other...
> 

Found it again.

---

Give each filesystem its own inode lock class. The various filesystems have
different locking order wrt the inode locks; esp. the pseudo filesystems
differ from the rest.

Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
 fs/inode.c |   12 +---
 include/linux/fs.h |5 +
 2 files changed, 14 insertions(+), 3 deletions(-)

Index: linux-2.6/fs/inode.c
===
--- linux-2.6.orig/fs/inode.c
+++ linux-2.6/fs/inode.c
@@ -142,6 +142,15 @@ static struct inode *alloc_inode(struct 
return NULL;
}
 
+   spin_lock_init(&inode->i_lock);
+   lockdep_set_class(&inode->i_lock, &sb->s_type->i_lock_key);
+
+   mutex_init(&inode->i_mutex);
+   lockdep_set_class(&inode->i_mutex, &sb->s_type->i_mutex_key);
+
+   init_rwsem(&inode->i_alloc_sem);
+   lockdep_set_class(&inode->i_alloc_sem, 
&sb->s_type->i_alloc_sem_key);
+
mapping->a_ops = &empty_aops;
mapping->host = inode;
mapping->flags = 0;
@@ -190,8 +199,6 @@ void inode_init_once(struct inode *inode
INIT_HLIST_NODE(&inode->i_hash);
INIT_LIST_HEAD(&inode->i_dentry);
INIT_LIST_HEAD(&inode->i_devices);
-   mutex_init(&inode->i_mutex);
-   init_rwsem(&inode->i_alloc_sem);
INIT_RADIX_TREE(&inode->i_data.page_tree, GFP_ATOMIC);
rwlock_init(&inode->i_data.tree_lock);
spin_lock_init(&inode->i_data.i_mmap_lock);
@@ -199,7 +206,6 @@ void inode_init_once(struct inode *inode
spin_lock_init(&inode->i_data.private_lock);
INIT_RAW_PRIO_TREE_ROOT(&inode->i_data.i_mmap);
INIT_LIST_HEAD(&inode->i_data.i_mmap_nonlinear);
-   spin_lock_init(&inode->i_lock);
i_size_ordered_init(inode);
 #ifdef CONFIG_INOTIFY
INIT_LIST_HEAD(&inode->inotify_watches);
Index: linux-2.6/include/linux/fs.h
===
--- linux-2.6.orig/include/linux/fs.h
+++ linux-2.6/include/linux/fs.h
@@ -1302,8 +1302,13 @@ struct file_system_type {
struct module *owner;
struct file_system_type * next;
struct list_head fs_supers;
+
struct lock_class_key s_lock_key;
struct lock_class_key s_umount_key;
+
+   struct lock_class_key i_lock_key;
+   struct lock_class_key i_mutex_key;
+   struct lock_class_key i_alloc_sem_key;
 };
 
 extern int get_sb_bdev(struct file_system_type *fs_type,

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

oom on wireless network saturation

[Keith Chew]

Hi

We are stress testing the wireless network driver on our linux system.
We use ping flood to saturate the network, and within 24 hours, we
managed to crash the driver.

This was a good test, as it hightlighted a timer problem in the
driver. After fixing that, we are now getting out of memory errors.
The OOM killer starts to kick in and the system freezes.

Can someone advise at a high level, what should the network driver do
in such a scenario? Essentially, the wireless packets get queued up in
the driver and eventually it just breaks. What is the correct way to
handle this gracefully?

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

Re: 2.6.23-rc7-mm1: panic in scheduler

[Kamalesh Babulal]

Balbir Singh wrote:
> On 9/25/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>> Exactly same call trace is produced over IA64 Madison (up to 9M cache) with 
>> 8 cpu's.
>> --
> 
> Hi, Kamalesh,
> 
> Could you please reproduce the problem or share the steps to reproduce
> the problem?
> 
> Thanks,
> Balbir
> -

Hi Balbir,

Yes, i am able to reproduce the problem. The problem can be reproduced
using the ltprunall.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] New kernel-message logging API

[Vegard Nossum]

On 9/25/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-09-25 at 00:58 -0400, [EMAIL PROTECTED] wrote:
> > Even the "kp_" prefix is actually pretty unnecessary.  It's "info"
> > and a human-readable string that make it recognizable as a log message.
>
> While I agree a prefix isn't necessary, info, warn, err
> are already frequently #define'd and used.
>
> kp_ isn't currently in use.
>
> $ egrep -r -l --include=*.[ch] 
> "^[[:space:]]*#[[:space:]]*define[[:space:]]+(info|err|warn)\b" * | wc -l
> 29

Yes, this is a very good point, they're already used. If they hadn't
been, everything would have been perfect. Actually, I'd have preferred
info/warn/err over kprint_ if it wasn't for the fact that
they're used (and in slightly different ways too).

As I wrote initially, one of the absolute requirements of a new API is
to retain full backwards compatibility with printk(). Which means that
using simply err()/info()/warn() is out of the question *for now*.
That is not to say we can't change this at a later time.

I think it would be good to have a base layer containing the functions
kprint_(), just to have something that 1) has a meaningful
name, and 2) doesn't disturb anybody else's names. err/info/warn or
kp_err/info/warn() (in order to have shorter names) can then be
implemented in terms of this.

I suppose that another goal of a new API would be to unify the
somewhat-a-mess of API that is now, i.e. many alternatives that do the
same thing is also not good. But this can be changed with patches (to
convert to new API) later.

If you look closer at the current definitions of erro/warn/info, it
turns out that most of them also do this to automatically prefix all
messages with the driver name. This makes me realize that there really
is a need for a way to automatically prefix messages or store a
per-message "subsystem" field. I propose the following solution:

The kprint.h header file looks like this:

/* This is a back-up string to be used if the source file doesn't
define this as a macro. */
const char *SUBSYSTEM = "";

/* Call this macro whatever you want, it's just an example anyway. */
#define info(msg, ...) printf("%s: " msg, SUBSYSTEM, ## __VA_ARGS__)

Then you can have a C file that overrides SUBSYSTEM by defining it as a macro:
#include 
#define SUBSYSTEM "usb"
info("test");
--> results in printf("%s: " "test", "usb");

Or, a C file that doesn't:
#include 
info("test");
--> results in printf("%s: " "test", SYBSYSTEM);
--> output is ": test"


Though, instead of actually incorporating this SUBSYSTEM name into the
string, I suggest passing it off as an argument into the real kprint()
machinery, to be stored along (but seperately) with timestamp, etc.

Hm, that's a digression. But thanks for the idea :)


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

Re: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.

[Eric Valette]

Rob Hussey wrote:
> On 9/15/07, ポール・ロラン Paul Rolland <[EMAIL PROTECTED]> wrote:
>   
>> Hi Eric,
>>
>> On Sat, 15 Sep 2007 20:30:14 +0200
>> Eric Valette <[EMAIL PROTECTED]> wrote:
>>
>> 
>>> Rob Hussey wrote:
>>>   
 On 9/15/07, Eric Valette <[EMAIL PROTECTED]> wrote:
 
> Eric Valette wrote:
>
>   
>>> Thanks for your help: it does indeed fix the problem.
>>>   
>> Nice it works for you too !
>>
>> 
>>> Now I have two side questions:
>>>   - the code is no more symetric "subsys_initcall" -> "module_exit".
>>> Do not know if it is "normal" but I love symmetry in code :-). Did not test
>>> it still works as a module...
>>>   
>> Symmetry is not broken, as we have :
>> #define subsys_initcall(fn) module_init(fn)
>> in include/linux/init.h where compiling as a module, and when not compiling
>> as a module, I doubt the exit function is called unless you are shuting
>> down your machine...
>>
>> 
>>>   - Who takes the responsability to push a patch to Linus? I guess it
>>> is urgent unless he plans a rc7
>>>   
>> Good point ! I expect the patches to be already in some queue waiting to be
>> pulled !
>> 
>
> The patches are on their way to making it into 2.6.23:
> http://marc.info/?l=linux-netdev&m=118986368303529&w=2
>
> Regards,
> Rob
>   
I'm a little bit worried as rc8 is out and ots still not in git.

-- eric

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

Re: [PATCH] Fix messed hunks in generic_setlease

[Andrew Morton]

On Tue, 25 Sep 2007 11:57:45 +0400 Pavel Emelyanov <[EMAIL PROTECTED]> wrote:

> I have noticed, that one hunk was lost and one duplicated 
> during merging the fix-potential-oops-in-generic_setlease(-xxx) 
> patches. One of the fixes is already in the hot-fixes, but the
> second one is still lost.
> 
> The returned pointer was not the one allocated, but some temporary
> used to scan through the inode's locks list. This caused and OOPS 
> during Kamalesh's testing.
> 
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> 
> ---
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index c0fe71a..c1198e3 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1423,7 +1418,7 @@ int generic_setlease(struct file *filp, 
>   locks_copy_lock(new_fl, lease);
>   locks_insert_lock(before, new_fl);
>  
> - *flp = fl;
> + *flp = new_fl;
>   return 0;
>  
>  out:

argh, what a mess - there are way too many trees playing with fs/locks.c.

umm, I think this is not a mismerge and that the original patch
(http://lkml.org/lkml/2007/9/20/141) had this bug in it.

And I've just sent that buggy patch to Linus.  Do you agree?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents

[Thomas Gleixner]

On Tue, 2007-09-25 at 10:14 +0400, Mikhail Kshevetskiy wrote:
> Hello Thomas, Rafael
> 
> > We know, that
> > - disabling local apic timers work
> 
> As i can see from the log, you are booting on computer with dualcore AMD
> processor. Do you have C1E feature enabled? 
> 
> i386 kernel disable lapic on dualcore AMD with C1E support (see 
> http://lkml.org/lkml/2007/3/29/199). x86_64 kernel do not have this
> patch still (it's required for tickless kernel only).

Well it is required for non tickless mode as well.

>  As result, if
> you run x86_64 kernel with hrt patch on such computer, the system
> will stall during boot on lapic timer calibration.

Thanks for the reminder. I have a look into this.

tglx


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

Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

[Jeff Garzik]

Peer Chen wrote:

We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being 
load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI being 
selected, which will verify if our legacy mode work well and have additional 
option if there is any
bug for the ahci mode.


I understand that logic, but look at what happens in practice:

1) User installs new OS in AHCI mode.  Distro updates initramfs (loaded 
at kernel boot time, with boot drivers) to include ahci driver.

2) User reboots into BIOS setup, and switches from AHCI mode to IDE mode.
3) BIOS setup reboots computer.
4) OS kernel and initramfs image are loaded.  ahci driver load fails.
5) User is left without a bootable system.

The same situation happens in reverse, if you install in IDE mode 
(sata_nv in initramfs), and then switch to AHCI/RAID mode.


Additionally, AHCI provides better performance and more direct exposure 
to the SATA frames.  This is key for supporting many modern SATA 
features that cannot be accessed via IDE legacy mode.  AHCI lacks 
in-silicon simulation of an IDE interface, which time has shown is a 
less stable, edge-case-prone approach to SATA.


I do not find the "verify nvidia's legacy mode works" argument 
compelling; that is not the kernel's job, nor the user's.  And if there 
is an AHCI silicon bug, let us deal with that when such a bug appears.


Overall, AFAICS this patch -introduces- new ways for the user to easily 
render their systems unbootable.


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 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 09:31:08PM -0400, Steven Rostedt wrote:
>  looking at Documentation/lguest/
> 
>  Oh wait, nothing to see here. Move along please.

lguest is an even bigger nightmare.  It's userspace code, but we can't
move it because it pokes into non-exported headers.

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

Re: [2.6.22] circular lock detected

[Jan Kara]

On Tue 25-09-07 10:02:43, Peter Zijlstra wrote:
> On Mon, 3 Sep 2007 16:01:35 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> 
> > On Mon 03-09-07 05:49:59, Andrew Morton wrote:
> > > > On Mon, 3 Sep 2007 14:27:02 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> > > > > > On Fri, 24 Aug 2007 23:00:33 +0200 Folkert van Heusden <[EMAIL 
> > > > > > PROTECTED]> wrote:
> 
> > > > > Has been reported before, but I don't recall whether we fixed it.  
> > > > > Jan,
> > > > > do you know>?
> > > >   I think we at least found a solution: Teach lockdep that I_MUTEX for
> > > > different filesystems is different. Peter Zilstra wrote a patch for that
> > > > and Folkert even confirmed that it fixes the problem for him. I'm not
> > > > sure what happened with the patch afterwards though. Adding Peter to CC
> > > > :).
> > > 
> > > But this is a tty_lock-versus-dqptr_sem ranking error.  Unrelated to 
> > > i_mutex?
> >   The final report is for this ranking but the locking chain (if I 
> > understand it
> > right) is:
> > tty_mutex (con_close) -> i_mutex (sysfs: remove_subdir)
> > i_mutex (do_truncate) -> i_alloc_sem (notify_change) -> truncate_mutex 
> > (ext3_truncate)
> > truncate_mutex (ext3_get_blocks_handle) -> dqptr_sem (dquot_alloc_space)
> > 
> > So it complains about tty_mutex vs dqptr_sem (I don't know why it does not
> > complain about tty_mutex vs i_mutex) but the wrong link in the chain is
> > that i_mutex from remove_subdir() [sysfs] and i_mutex from do_truncate()
> > [ext3] are different and should never depend on each other...
> > 
> 
> Found it again.
  Cool, thanks Peter. Andrew, would you put it into -mm? This should take care 
of
the false lockdep warnings from the quota code. If I recall correctly, one
of the reporters even confirmed it fixes the problem for him.
  The patch looks fine. You can add:
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>

Honza

> Give each filesystem its own inode lock class. The various filesystems have
> different locking order wrt the inode locks; esp. the pseudo filesystems
> differ from the rest.
> 
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> ---
>  fs/inode.c |   12 +---
>  include/linux/fs.h |5 +
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> Index: linux-2.6/fs/inode.c
> ===
> --- linux-2.6.orig/fs/inode.c
> +++ linux-2.6/fs/inode.c
> @@ -142,6 +142,15 @@ static struct inode *alloc_inode(struct 
>   return NULL;
>   }
>  
> + spin_lock_init(&inode->i_lock);
> + lockdep_set_class(&inode->i_lock, &sb->s_type->i_lock_key);
> +
> + mutex_init(&inode->i_mutex);
> + lockdep_set_class(&inode->i_mutex, &sb->s_type->i_mutex_key);
> +
> + init_rwsem(&inode->i_alloc_sem);
> + lockdep_set_class(&inode->i_alloc_sem, 
> &sb->s_type->i_alloc_sem_key);
> +
>   mapping->a_ops = &empty_aops;
>   mapping->host = inode;
>   mapping->flags = 0;
> @@ -190,8 +199,6 @@ void inode_init_once(struct inode *inode
>   INIT_HLIST_NODE(&inode->i_hash);
>   INIT_LIST_HEAD(&inode->i_dentry);
>   INIT_LIST_HEAD(&inode->i_devices);
> - mutex_init(&inode->i_mutex);
> - init_rwsem(&inode->i_alloc_sem);
>   INIT_RADIX_TREE(&inode->i_data.page_tree, GFP_ATOMIC);
>   rwlock_init(&inode->i_data.tree_lock);
>   spin_lock_init(&inode->i_data.i_mmap_lock);
> @@ -199,7 +206,6 @@ void inode_init_once(struct inode *inode
>   spin_lock_init(&inode->i_data.private_lock);
>   INIT_RAW_PRIO_TREE_ROOT(&inode->i_data.i_mmap);
>   INIT_LIST_HEAD(&inode->i_data.i_mmap_nonlinear);
> - spin_lock_init(&inode->i_lock);
>   i_size_ordered_init(inode);
>  #ifdef CONFIG_INOTIFY
>   INIT_LIST_HEAD(&inode->inotify_watches);
> Index: linux-2.6/include/linux/fs.h
> ===
> --- linux-2.6.orig/include/linux/fs.h
> +++ linux-2.6/include/linux/fs.h
> @@ -1302,8 +1302,13 @@ struct file_system_type {
>   struct module *owner;
>   struct file_system_type * next;
>   struct list_head fs_supers;
> +
>   struct lock_class_key s_lock_key;
>   struct lock_class_key s_umount_key;
> +
> + struct lock_class_key i_lock_key;
> + struct lock_class_key i_mutex_key;
> + struct lock_class_key i_alloc_sem_key;
>  };
>  
>  extern int get_sb_bdev(struct file_system_type *fs_type,
> 
-- 
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/4] module: implement module_inhibit_unload()

[Tejun Heo]

Rusty Russell wrote:
> On Tue, 2007-09-25 at 12:36 +0900, Tejun Heo wrote:
>> Rusty Russell wrote:
>>> As stated you cannot protect arbitrary code this way, as you are trying
>>> to do.  I do not think you've broken any of the current code, but I
>>> cannot tell.  You're certainly going to surprise unsuspecting future
>>> authors.
>> Can you elaborate a bit?  Why can't it protect the code?
> 
> Because you don't know what that code does.  After all, it's assumed
> that module code doesn't get called after exit and you're deliberately
> violating that assumption.

What I meant by protecting 'code' was the 'code' itself.  Those pages
containing instructions that cpu executes.  It of course can't protect
against all the things they do.

>>> Can you really not figure out the module owner of the sysfs entry to inc
>>> its use count during this procedure?  (__module_get()).
>> I can but I don't think it's worth the effort.  It will involve passing
>> @owner parameter down through kobject to sysfs but the path is pretty
>> obscure and thus difficult to test.
> 
> Have you tested that *this* path works?  Let's take your first change as
> an example:
> 
> +   mutex_lock(&gdev->reg_mutex);
> +   __ccwgroup_remove_symlinks(gdev);
> +   device_unregister(dev);
> +   mutex_unlock(&gdev->reg_mutex);
> 
> Now, are you sure that calling cleanup_ccwgroup just after
> device_unregister() works?
> 
> static void __exit
> cleanup_ccwgroup (void)
> {
>   bus_unregister (&ccwgroup_bus_type);
> }

It should.  After ->exit() is called, there can't be any object left
behind.  If a module is hosting objects which can't be destroyed from
->exit(), its module ref count shouldn't be zero.  So, either 1.
refcount != 0 or 2. ->exit() can destroy all objects.  As Cornelia
explains, for ccwgroup, it's #1.  Note that unload inhibition doesn't
change anything about this.

>> I think it's too much work for the
>> users of the API and it will be easy to pass the wrong @owner and go
>> unnoticed.
> 
> But your shortcut insists that all module authors be aware that
> functions can be running after exit() is called.  That's a recipe for
> instability and disaster.

No, it doesn't change that at all.  All unload inhibition does is
postponing removal of code (and data too of course) section a bit so
that a module can host code which issues unloading of itself.  Object
synchronization rules remain exactly the same.  Formerly broken code is
still broken and I don't even think unload inhibition would mask them
too much either.

I think the naming is too ambiguous.  Maybe it should be named something
like "hold_module_for_suicide".

Thanks.

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

[PATCH] include/linux/mutex.h: unclear reference to convention

[Matti Linnanvuori]

If you want to maintain the convention of documenting the interface only in .c 
files, 
you should write the convention in so many places in .h files that no one could 
overlook it.
But I think the convention is bad and it would be better to document the 
interface also in
.h files where it is defined. The convention is bad because it requires people 
to jump to
other files to understand .h files.



  __  
Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! 
www.yahoo.de/clever
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

menuconfig idea: lift fs menu

[Jan Engelhardt]

Lift the FS menu a bit by moving filesystem-specific
parts into their own menu.

This is an idea I had. Comments please, if any.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 fs/Kconfig  |   19 ---
 fs/gfs2/Kconfig |9 ++---
 fs/xfs/Kconfig  |   10 +-
 3 files changed, 27 insertions(+), 11 deletions(-)

Index: linux-2.6.23/fs/Kconfig
===
--- linux-2.6.23.orig/fs/Kconfig
+++ linux-2.6.23/fs/Kconfig
@@ -6,6 +6,17 @@ menu "File systems"
 
 if BLOCK
 
+menuconfig EXT_FS
+   bool "Extended filesystem family"
+   default y
+   ---help---
+ Say Y here to get to see options for the 'ext' filesystems.
+ This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and 
disabled.
+
+if EXT_FS
+
 config EXT2_FS
tristate "Second extended fs support"
help
@@ -272,7 +283,9 @@ config FS_MBCACHE
default y if EXT2_FS=y || EXT3_FS=y || EXT4DEV_FS=y
default m if EXT2_FS=m || EXT3_FS=m || EXT4DEV_FS=m
 
-config REISERFS_FS
+endif # EXT_FS
+
+menuconfig REISERFS_FS
tristate "Reiserfs support"
help
  Stores not just filenames but the files themselves in a balanced
@@ -358,7 +371,7 @@ config REISERFS_FS_SECURITY
  If you are not using a security module that requires using
  extended attributes for file security labels, say N.
 
-config JFS_FS
+menuconfig JFS_FS
tristate "JFS filesystem support"
select NLS
help
@@ -420,7 +433,7 @@ config FS_POSIX_ACL
 source "fs/xfs/Kconfig"
 source "fs/gfs2/Kconfig"
 
-config OCFS2_FS
+menuconfig OCFS2_FS
tristate "OCFS2 file system support"
depends on NET && SYSFS
select CONFIGFS_FS
Index: linux-2.6.23/fs/gfs2/Kconfig
===
--- linux-2.6.23.orig/fs/gfs2/Kconfig
+++ linux-2.6.23/fs/gfs2/Kconfig
@@ -1,4 +1,4 @@
-config GFS2_FS
+menuconfig GFS2_FS
tristate "GFS2 file system support"
depends on EXPERIMENTAL
select FS_POSIX_ACL
@@ -18,9 +18,10 @@ config GFS2_FS
  the below locking modules. Documentation and utilities for GFS2 can
  be found here: http://sources.redhat.com/cluster
 
+if GFS2_FS
+
 config GFS2_FS_LOCKING_NOLOCK
tristate "GFS2 \"nolock\" locking module"
-   depends on GFS2_FS
help
  Single node locking module for GFS2.
 
@@ -34,7 +35,7 @@ config GFS2_FS_LOCKING_NOLOCK
 
 config GFS2_FS_LOCKING_DLM
tristate "GFS2 DLM locking module"
-   depends on GFS2_FS && SYSFS && NET && INET && (IPV6 || IPV6=n)
+   depends on SYSFS && NET && INET && (IPV6 || IPV6=n)
select IP_SCTP if DLM_SCTP
select CONFIGFS_FS
select DLM
@@ -44,3 +45,5 @@ config GFS2_FS_LOCKING_DLM
  Most users of GFS2 will require this module. It provides the locking
  interface between GFS2 and the DLM, which is required to use GFS2
  in a cluster environment.
+
+endif # GFS2_FS
Index: linux-2.6.23/fs/xfs/Kconfig
===
--- linux-2.6.23.orig/fs/xfs/Kconfig
+++ linux-2.6.23/fs/xfs/Kconfig
@@ -1,4 +1,4 @@
-config XFS_FS
+menuconfig XFS_FS
tristate "XFS filesystem support"
depends on BLOCK
help
@@ -18,9 +18,10 @@ config XFS_FS
  system of your root partition is compiled as a module, you'll need
  to use an initial ramdisk (initrd) to boot.
 
+if XFS_FS
+
 config XFS_QUOTA
bool "XFS Quota support"
-   depends on XFS_FS
help
  If you say Y here, you will be able to set limits for disk usage on
  a per user and/or a per group basis under XFS.  XFS considers quota
@@ -37,7 +38,6 @@ config XFS_QUOTA
 
 config XFS_SECURITY
bool "XFS Security Label support"
-   depends on XFS_FS
help
  Security labels support alternative access control models
  implemented by security modules like SELinux.  This option
@@ -49,7 +49,6 @@ config XFS_SECURITY
 
 config XFS_POSIX_ACL
bool "XFS POSIX ACL support"
-   depends on XFS_FS
help
  POSIX Access Control Lists (ACLs) support permissions for users and
  groups beyond the owner/group/world scheme.
@@ -61,7 +60,6 @@ config XFS_POSIX_ACL
 
 config XFS_RT
bool "XFS Realtime subvolume support"
-   depends on XFS_FS
help
  If you say Y here you will be able to mount and use XFS filesystems
  which contain a realtime subvolume.  The realtime subvolume is a
@@ -76,3 +74,5 @@ config XFS_RT
  See the xfs man page in section 5 for additional information.
 
  If unsure, say N.
+
+endif # XFS_FS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/ma

[patch 2/2] menuconfig: transform Network Filesystems menu

[Jan Engelhardt]

Turn Network File Systems into a menuconfig so that it can be
disabled at once.

(Note: I added a "default y". If you do not like that, speak up.)

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 fs/Kconfig |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

Index: linux-2.6.23/fs/Kconfig
===
--- linux-2.6.23.orig/fs/Kconfig
+++ linux-2.6.23/fs/Kconfig
@@ -1516,8 +1516,20 @@ config UFS_DEBUG
 
 endmenu
 
-menu "Network File Systems"
+menuconfig NETWORK_FILESYSTEMS
+   bool "Network File Systems"
+   default y
depends on NET
+   ---help---
+ Say Y here to get to see options for network filesystems and
+ filesystem-related networking code, such as NFS daemon and
+ RPCSEC security modules.
+ This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and
+ disabled; if unsure, say Y here.
+
+if NETWORK_FILESYSTEMS
 
 config NFS_FS
tristate "NFS file system support"
@@ -2055,7 +2067,7 @@ config 9P_FS
 
  If unsure, say N.
 
-endmenu
+endif # NETWORK_FILESYSTEMS
 
 if BLOCK
 menu "Partition Types"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] menuconfig: transform NLS and DLM menus

[Jan Engelhardt]

Changes NLS and DLM menus into a 'menuconfig' object
so that it can be disabled at once without having to enter
the menu first to disable the config option.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>

---
 fs/dlm/Kconfig |8 ++--
 fs/nls/Kconfig |   50 +-
 2 files changed, 7 insertions(+), 51 deletions(-)

Index: linux-2.6.23/fs/dlm/Kconfig
===
--- linux-2.6.23.orig/fs/dlm/Kconfig
+++ linux-2.6.23/fs/dlm/Kconfig
@@ -1,8 +1,6 @@
-menu "Distributed Lock Manager"
-   depends on EXPERIMENTAL && INET
-
-config DLM
+menuconfig DLM
tristate "Distributed Lock Manager (DLM)"
+   depends on EXPERIMENTAL && INET
depends on SYSFS && (IPV6 || IPV6=n)
select CONFIGFS_FS
select IP_SCTP
@@ -17,5 +15,3 @@ config DLM_DEBUG
Under the debugfs mount point, the name of each lockspace will
appear as a file in the "dlm" directory.  The output is the
list of resource and locks the local node knows about.
-
-endmenu
Index: linux-2.6.23/fs/nls/Kconfig
===
--- linux-2.6.23.orig/fs/nls/Kconfig
+++ linux-2.6.23/fs/nls/Kconfig
@@ -2,10 +2,8 @@
 # Native language support configuration
 #
 
-menu "Native Language Support"
-
-config NLS
-   tristate "Base native language support"
+menuconfig NLS
+   tristate "Native language support"
---help---
  The base Native Language Support. A number of filesystems
  depend on it (e.g. FAT, JOLIET, NT, BEOS filesystems), as well
@@ -17,9 +15,10 @@ config NLS
  To compile this code as a module, choose M here: the module
  will be called nls_base.
 
+if NLS
+
 config NLS_DEFAULT
string "Default NLS Option"
-   depends on NLS
default "iso8859-1"
---help---
  The default NLS used when mounting file system. Note, that this is
@@ -39,7 +38,6 @@ config NLS_DEFAULT
 
 config NLS_CODEPAGE_437
tristate "Codepage 437 (United States, Canada)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored
@@ -52,7 +50,6 @@ config NLS_CODEPAGE_437
 
 config NLS_CODEPAGE_737
tristate "Codepage 737 (Greek)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored
@@ -65,7 +62,6 @@ config NLS_CODEPAGE_737
 
 config NLS_CODEPAGE_775
tristate "Codepage 775 (Baltic Rim)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored
@@ -79,7 +75,6 @@ config NLS_CODEPAGE_775
 
 config NLS_CODEPAGE_850
tristate "Codepage 850 (Europe)"
-   depends on NLS
---help---
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored in
@@ -96,7 +91,6 @@ config NLS_CODEPAGE_850
 
 config NLS_CODEPAGE_852
tristate "Codepage 852 (Central/Eastern Europe)"
-   depends on NLS
---help---
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored in
@@ -112,7 +106,6 @@ config NLS_CODEPAGE_852
 
 config NLS_CODEPAGE_855
tristate "Codepage 855 (Cyrillic)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored in
@@ -124,7 +117,6 @@ config NLS_CODEPAGE_855
 
 config NLS_CODEPAGE_857
tristate "Codepage 857 (Turkish)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored in
@@ -136,7 +128,6 @@ config NLS_CODEPAGE_857
 
 config NLS_CODEPAGE_860
tristate "Codepage 860 (Portuguese)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored in
@@ -148,7 +139,6 @@ config NLS_CODEPAGE_860
 
 config NLS_CODEPAGE_861
tristate "Codepage 861 (Icelandic)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character sets are stored in
@@ -160,7 +150,6 @@ config NLS_CODEPAGE_861
 
 config NLS_CODEPAGE_862
tristate "Codepage 862 (Hebrew)"
-   depends on NLS
help
  The Microsoft FAT file system family can deal with filenames in
  native language character sets. These character se

Re: [git] CFS-devel, latest code

[Srivatsa Vaddagiri]

On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
> This doornails the Vaio.  After grub handover the screen remains black
> and the fan goes whir.
> 
> http://userweb.kernel.org/~akpm/config-sony.txt

This seems to be UP regression. Sorry abt that. I could recreate 
the problem very easily with CONFIG_SMP turned off.

Can you check if this patch works? Works for me here.

--

Fix UP breakage.

Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>


---
 kernel/sched.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: current/kernel/sched.c
===
--- current.orig/kernel/sched.c
+++ current/kernel/sched.c
@@ -1029,8 +1029,8 @@ static inline void __set_task_cpu(struct
 {
 #ifdef CONFIG_SMP
task_thread_info(p)->cpu = cpu;
-   set_task_cfs_rq(p);
 #endif
+   set_task_cfs_rq(p);
 }
 
 #ifdef CONFIG_SMP

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

Re: [git] CFS-devel, latest code

[Mike Galbraith]

On Tue, 2007-09-25 at 09:35 +0200, Mike Galbraith wrote:

> Darn, have news: latency thing isn't dead.  Two busy loops, one at nice
> 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> latencies below for nice -5 Xorg.  Didn't kill the box though.
> 
> se.wait_max  :10.068169
> se.wait_max  : 7.465334
> se.wait_max  :   135.501816
> se.wait_max  : 0.884483
> se.wait_max  :   144.218955
> se.wait_max  :   128.578376
> se.wait_max  :93.975768
> se.wait_max  : 4.965965
> se.wait_max  :   113.655533
> se.wait_max  : 4.301075
> 
> sched_debug (attached) is.. strange.

Disabling CONFIG_FAIR_GROUP_SCHED fixed both.  Latencies of up to 336ms
hit me during the recompile (make -j3), with nothing else running.
Since reboot, latencies are, so far, very very nice.  I'm leaving it
disabled for now.

-Mike 

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

Re: [PATCH] Fix messed hunks in generic_setlease

[Pavel Emelyanov]

Andrew Morton wrote:
> On Tue, 25 Sep 2007 11:57:45 +0400 Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> 
>> I have noticed, that one hunk was lost and one duplicated 
>> during merging the fix-potential-oops-in-generic_setlease(-xxx) 
>> patches. One of the fixes is already in the hot-fixes, but the
>> second one is still lost.
>>
>> The returned pointer was not the one allocated, but some temporary
>> used to scan through the inode's locks list. This caused and OOPS 
>> during Kamalesh's testing.
>>
>> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
>>
>> ---
>>
>> diff --git a/fs/locks.c b/fs/locks.c
>> index c0fe71a..c1198e3 100644
>> --- a/fs/locks.c
>> +++ b/fs/locks.c
>> @@ -1423,7 +1418,7 @@ int generic_setlease(struct file *filp, 
>>  locks_copy_lock(new_fl, lease);
>>  locks_insert_lock(before, new_fl);
>>  
>> -*flp = fl;
>> +*flp = new_fl;
>>  return 0;
>>  
>>  out:
> 
> argh, what a mess - there are way too many trees playing with fs/locks.c.
> 
> umm, I think this is not a mismerge and that the original patch
> (http://lkml.org/lkml/2007/9/20/141) had this bug in it.

Indeed... :(

> And I've just sent that buggy patch to Linus.  Do you agree?

Shame on me... Sorry :(

(going to the blackboard to write "I will check my patches twice before
 sending them to Andrew" for 100 times)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Alexey Starikovskiy]

Do you have CONFIG_ACPI_SLEEP enabled in your .config?

Andrew Morton wrote:
> On Tue, 25 Sep 2007 08:51:09 +0200 Damien Wyart <[EMAIL PROTECTED]> wrote:
> 
>> Hello,
>>
>> After testing rc8, I noticed that I couldn't power off the computer
>> directly, it only got halted and I had to press the power button
>> manually. Just before displaying "System halted", the following message
>> is displayed:
>>
>>   ACPI : PCI interrupt for device :02:08.0 disabled
>>
>> I had to first revert 5a50fe709d527f31169263e36601dd83446d5744 then
>> f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to
>> recover previous behaviour.
> 
> Let's add some cc's.
> 
>> Attached are the dmesg for rc7, rc8 and rc8 with the two patches
>> reverted.
> 
> "diff -u dmesg.rc8_revert dmesg.rc8" says:
> 
> --- dmesg.rc8_revert  2007-09-25 00:31:33.0 -0700
> +++ dmesg.rc8 2007-09-25 00:31:30.0 -0700
> @@ -1,4 +1,4 @@
> -Linux version 2.6.23-rc8-25092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 
> (Debian 4.2.1-5)) #2 SMP Tue Sep 25 08:31:09 CEST 2007
> +Linux version 2.6.23-rc8-25092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 
> (Debian 4.2.1-5)) #1 SMP Tue Sep 25 07:27:10 CEST 2007
>  BIOS-provided physical RAM map:
>   BIOS-e820:  - 000a (usable)
>   BIOS-e820: 000f - 0010 (reserved)
> @@ -72,18 +72,18 @@
>  console [tty0] enabled
>  Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>  Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> -Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 
> 815k data, 192k init, 1179088k highmem)
> +Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 
> 816k data, 192k init, 1179088k highmem)
>  virtual kernel memory layout:
>  fixmap  : 0xfff9b000 - 0xf000   ( 400 kB)
>  pkmap   : 0xff80 - 0xffc0   (4096 kB)
>  vmalloc : 0xf880 - 0xff7fe000   ( 111 MB)
>  lowmem  : 0xc000 - 0xf800   ( 896 MB)
>.init : 0xc03f - 0xc042   ( 192 kB)
> -  .data : 0xc031fd5c - 0xc03ebd04   ( 815 kB)
> -  .text : 0xc010 - 0xc031fd5c   (2175 kB)
> +  .data : 0xc031fcd4 - 0xc03ebd04   ( 816 kB)
> +  .text : 0xc010 - 0xc031fcd4   (2175 kB)
>  Checking if this processor honours the WP bit even in supervisor mode... Ok.
>  SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1
> -Calibrating delay using timer specific routine.. 5987.66 BogoMIPS 
> (lpj=2993833)
> +Calibrating delay using timer specific routine.. 5987.60 BogoMIPS 
> (lpj=2993802)
>  Mount-cache hash table entries: 512
>  CPU: After generic identify, caps: bfebfbff    
> 041d   
>  monitor/mwait feature present.
> @@ -104,7 +104,7 @@
>  Booting processor 1/1 eip 2000
>  CPU 1 irqstacks, hard=c0426000 soft=c0424000
>  Initializing CPU#1
> -Calibrating delay using timer specific routine.. 5984.18 BogoMIPS 
> (lpj=2992093)
> +Calibrating delay using timer specific routine.. 5984.16 BogoMIPS 
> (lpj=2992084)
>  CPU: After generic identify, caps: bfebfbff    
> 041d   
>  monitor/mwait feature present.
>  CPU: Trace cache: 12K uops, L1 D cache: 16K
> @@ -116,7 +116,7 @@
>  CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
>  CPU1: Thermal monitoring enabled
>  CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03
> -Total of 2 processors activated (11971.85 BogoMIPS).
> +Total of 2 processors activated (11971.77 BogoMIPS).
>  ENABLING IO-APIC IRQs
>  ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>  checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> @@ -279,6 +279,7 @@
>  EXT3-fs: mounted filesystem with ordered data mode.
>  VFS: Mounted root (ext3 filesystem) readonly.
>  Freeing unused kernel memory: 192k freed
> +input: PC Speaker as /devices/platform/pcspkr/input/input4
>  sr0: scsi3-mmc drive: 1x/48x cd/rw xa/form2 cdda tray
>  Uniform CD-ROM driver Revision: 3.20
>  sr 1:0:0:0: Attached scsi CD-ROM sr0
> @@ -287,7 +288,6 @@
>  usbcore: registered new interface driver usbfs
>  usbcore: registered new interface driver hub
>  usbcore: registered new device driver usb
> -input: PC Speaker as /devices/platform/pcspkr/input/input4
>  parport_pc 00:0a: reported by Plug and Play ACPI
>  parport0: PC-style at 0x378 (0x778), irq 7, using FIFO 
> [PCSPP,TRISTATE,COMPAT,ECP]
>  USB Universal Host Controller Interface driver v3.0
> @@ -299,46 +299,42 @@
>  usb usb1: configuration #1 chosen from 1 choice
>  hub 1-0:1.0: USB hub found
>  hub 1-0:1.0: 2 ports detected
> -ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 20
> -PCI: Setting latency timer of device :00:1d.1 to 64
> -uhci_hcd :00:1d.1: UHCI Host Controller
> -uhci_hcd :00:1d.1: new USB bus registered, assigned bus number 2
> -uhci_hcd :00:1d.1: irq 20, io base 0xff60
> +ACPI: PCI Interrupt :00:1d.7[D] -> GSI 23 (le

Re: [PATCH 1/4] module: implement module_inhibit_unload()

[Tejun Heo]

Tejun Heo wrote:
> Rusty Russell wrote:
>> Now, are you sure that calling cleanup_ccwgroup just after
>> device_unregister() works?
>>
>> static void __exit
>> cleanup_ccwgroup (void)
>> {
>>  bus_unregister (&ccwgroup_bus_type);
>> }
> 
> It should.  After ->exit() is called, there can't be any object left
> behind.  If a module is hosting objects which can't be destroyed from
> ->exit(), its module ref count shouldn't be zero.  So, either 1.
> refcount != 0 or 2. ->exit() can destroy all objects.  As Cornelia
> explains, for ccwgroup, it's #1.  Note that unload inhibition doesn't
> change anything about this.

Hmmm There doesn't seem to any reason why the blocking should be
after calling ->exit().  And, yeah, it would be more useful and
intuitive if blocking happens before ->exit().  What do you think?

Thanks.

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

RE: Problems with 2.6.23-rc6 on AMD Geode LX800

[Joerg Pommnitz]

Chuck, Jordan,
thanks for taking an interest in this problem. As suggested by Jordan I tried a 
new
BIOS revision from
http://www.digitallogic.ch/index.php?id=256&dir=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21&mountpoint=23

Unfortunately the kernel still fails to boot in the same way.

Do you still need the disassembled reserve_bootmem_core? 
--  
Thanks and kind regards
 Joerg



   
Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr 
Wissen. www.yahoo.de/clever

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RFC] video gfx: merge kconfig menus

[Dave Airlie]

On 9/25/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> Is there some reason that we don't put all video gfx config in one
> place?  Is the split just historical, based on subdirectory locations,
> or is there a bigger reason for it?
>
> [to apply cleanly, this patch depends on a patch that was sent
> to linux-fbdev-devel, which is subscribers-only, so I didn't cc: lkml
> on it:  http://marc.info/?l=linux-fbdev-devel&m=119070044232621&w=2]
>
> ---
>
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Move AGP and DRM menus into the video graphics support menu.
>   They use 'menuconfig' so that they can all be disabled with
>   one selection.
> Make the console menu use 'menuconfig' so that it can all be
>   disabled with one selection.
> Make the frame buffer menu use 'menuconfig' so that it can all be
>   disabled with one selection.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

Fine by me.. some day we might move the directories but this is a good start..

Acked-by: Dave Airlie <[EMAIL PROTECTED]>

Dave.
> ---
>  drivers/char/Kconfig |4 
>  drivers/char/agp/Kconfig |2 +-
>  drivers/char/drm/Kconfig |2 +-
>  drivers/video/Kconfig|   11 +++
>  4 files changed, 9 insertions(+), 10 deletions(-)
>
> --- linux-2.6.23-rc8.orig/drivers/char/Kconfig
> +++ linux-2.6.23-rc8/drivers/char/Kconfig
> @@ -896,10 +896,6 @@ config GPIO_TB0219
> depends on TANBAC_TB022X
> select GPIO_VR41XX
>
> -source "drivers/char/agp/Kconfig"
> -
> -source "drivers/char/drm/Kconfig"
> -
>  source "drivers/char/pcmcia/Kconfig"
>
>  config MWAVE
> --- linux-2.6.23-rc8.orig/drivers/video/Kconfig
> +++ linux-2.6.23-rc8/drivers/video/Kconfig
> @@ -5,8 +5,9 @@
>  menu "Graphics support"
> depends on HAS_IOMEM
>
> -source "drivers/video/backlight/Kconfig"
> -source "drivers/video/display/Kconfig"
> +source "drivers/char/agp/Kconfig"
> +
> +source "drivers/char/drm/Kconfig"
>
>  config VGASTATE
> tristate
> @@ -19,7 +20,7 @@ config VIDEO_OUTPUT_CONTROL
>   This framework adds support for low-level control of the video
>   output switch.
>
> -config FB
> +menuconfig FB
> tristate "Support for frame buffer devices"
> ---help---
>   The frame buffer device provides an abstraction for the graphics
> @@ -1860,6 +1861,9 @@ if ARCH_OMAP
> source "drivers/video/omap/Kconfig"
>  endif
>
> +source "drivers/video/backlight/Kconfig"
> +source "drivers/video/display/Kconfig"
> +
>  if VT
> source "drivers/video/console/Kconfig"
>  endif
> @@ -1869,4 +1873,3 @@ if FB || SGI_NEWPORT_CONSOLE
>  endif
>
>  endmenu
> -
> --- linux-2.6.23-rc8.orig/drivers/char/agp/Kconfig
> +++ linux-2.6.23-rc8/drivers/char/agp/Kconfig
> @@ -1,4 +1,4 @@
> -config AGP
> +menuconfig AGP
> tristate "/dev/agpgart (AGP Support)"
> depends on ALPHA || IA64 || PARISC || PPC || X86
> depends on PCI
> --- linux-2.6.23-rc8.orig/drivers/char/drm/Kconfig
> +++ linux-2.6.23-rc8/drivers/char/drm/Kconfig
> @@ -4,7 +4,7 @@
>  # This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  #
> -config DRM
> +menuconfig DRM
> tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
> support)"
> depends on (AGP || AGP=n) && PCI && !EMULATED_CMPXCHG
> help
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git] CFS-devel, latest code

[Srivatsa Vaddagiri]

On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
> > Darn, have news: latency thing isn't dead.  Two busy loops, one at nice
> > 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> > latencies below for nice -5 Xorg.  Didn't kill the box though.
> > 
> > se.wait_max  :10.068169
> > se.wait_max  : 7.465334
> > se.wait_max  :   135.501816
> > se.wait_max  : 0.884483
> > se.wait_max  :   144.218955
> > se.wait_max  :   128.578376
> > se.wait_max  :93.975768
> > se.wait_max  : 4.965965
> > se.wait_max  :   113.655533
> > se.wait_max  : 4.301075
> > 
> > sched_debug (attached) is.. strange.

Mike,
Do you have FAIR_USER_SCHED turned on as well? Can you send me
your .config pls?

Also how do you check se.wait_max?

> Disabling CONFIG_FAIR_GROUP_SCHED fixed both.  Latencies of up to 336ms
> hit me during the recompile (make -j3), with nothing else running.
> Since reboot, latencies are, so far, very very nice.  I'm leaving it
> disabled for now.

-- 
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RFC] samples/: move kprobes sources to samples

[Ananth N Mavinakayanahalli]

On Mon, Sep 24, 2007 at 02:58:28PM -0700, Randy Dunlap wrote:
> 
> This is RFC patch 2/2.
> Patch 1/2 introduces the samples/ infrastructure:
>   http://lkml.org/lkml/2007/9/24/397
> 
> 
> ---
> 
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Move kprobes source files from Documentation/kprobes.txt to
> samples/kprobes/ and add them to the build system.
> 
> Fix sparse warnings in all 3 kprobes samples source files.
> 
> Although kprobe-example.c is x86-specific, make it build on any
> platform by surrounding some code in ifdef/endif blocks.
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>

Thanks Randy for kicking this off. I've updated kprobe_example.c to work
on powerpc also. In addition I have:

o Removed samples/Kbuild so the build goes on fine
o Modified examples slightly to display output better (cosmetic)
o Changed the kretprobe_example.c to probe do_fork and log the new pid
o Fixed code per roel's nitpicks
o Renamed kretprobe-example.c to kretprobe_example.c for consistancy


Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
---
 samples/Kbuild  |2 
 Documentation/kprobes.txt   |  206 
 samples/Kconfig |5 
 samples/Makefile|3 
 samples/kprobes/Makefile|5 
 samples/kprobes/jprobe_example.c|   69 
 samples/kprobes/kprobe_example.c|   92 
 samples/kprobes/kretprobe_example.c |   61 ++
 8 files changed, 240 insertions(+), 203 deletions(-)

Index: linux-2.6.23-rc7/samples/kprobes/Makefile
===
--- /dev/null
+++ linux-2.6.23-rc7/samples/kprobes/Makefile
@@ -0,0 +1,5 @@
+# builds the kprobes example kernel modules;
+# then to use one (as root):  insmod 
+
+obj-$(CONFIG_SAMPLE_KPROBES) += kprobe_example.o jprobe_example.o \
+   kretprobe_example.o
Index: linux-2.6.23-rc7/samples/Kconfig
===
--- linux-2.6.23-rc7.orig/samples/Kconfig
+++ linux-2.6.23-rc7/samples/Kconfig
@@ -7,5 +7,10 @@ menuconfig SAMPLES
 
 if SAMPLES
 
+config SAMPLE_KPROBES
+   tristate "Build kprobes examples -- loadable modules only"
+   depends on KPROBES && m
+   help
+ This builds several kprobes example modules.
 
 endif # SAMPLES
Index: linux-2.6.23-rc7/samples/kprobes/jprobe_example.c
===
--- /dev/null
+++ linux-2.6.23-rc7/samples/kprobes/jprobe_example.c
@@ -0,0 +1,69 @@
+/*jprobe-example.c */
+/*
+ * Here's a sample kernel module showing the use of jprobes to dump
+ * the arguments of do_fork().
+ *
+ * Build and insert the kernel module as done in the kprobe example.
+ * You will see the trace data in /var/log/messages and on the
+ * console whenever do_fork() is invoked to create a new process.
+ * (Some messages may be suppressed if syslogd is configured to
+ * eliminate duplicate messages.)
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Jumper probe for do_fork.
+ * Mirror principle enables access to arguments of the probed routine
+ * from the probe handler.
+ */
+static const char *probed_func = "do_fork";
+
+/* Proxy routine having the same arguments as actual do_fork() routine */
+static long jdo_fork(unsigned long clone_flags, unsigned long stack_start,
+ struct pt_regs *regs, unsigned long stack_size,
+ int __user * parent_tidptr, int __user * child_tidptr)
+{
+   printk("jprobe: clone_flags = 0x%lx, stack_size = 0x%lx, regs = 0x%p\n",
+  clone_flags, stack_size, regs);
+
+   /* Always end with a call to jprobe_return(). */
+   jprobe_return();
+
+   /*NOTREACHED*/
+   return 0;
+}
+
+static struct jprobe my_jprobe = {
+   .entry = jdo_fork
+};
+
+static int __init jprobe_init(void)
+{
+   int ret;
+   my_jprobe.kp.symbol_name = (char *)probed_func;
+
+   ret = register_jprobe(&my_jprobe);
+   if (ret < 0) {
+   printk("register_jprobe failed, returned %d\n", ret);
+   return -1;
+   }
+   printk("Planted jprobe at %p, handler addr %p\n",
+  my_jprobe.kp.addr, my_jprobe.entry);
+   return 0;
+}
+
+static void __exit jprobe_exit(void)
+{
+   unregister_jprobe(&my_jprobe);
+   printk("jprobe on %s unregistered\n", probed_func);
+}
+
+module_init(jprobe_init)
+module_exit(jprobe_exit)
+MODULE_LICENSE("GPL");
Index: linux-2.6.23-rc7/samples/kprobes/kprobe_example.c
===
--- /dev/null
+++ linux-2.6.23-rc7/samples/kprobes/kprobe_example.c
@@ -0,0 +1,92 @@
+/*kprobe_example.c*/
+/*
+ * NOTE: This example is works on x86 and powerpc.
+ * Here's a sample kernel module showing the use of kprobes to dump a
+ * stack trace and selected registers when

2.6.23-rc8-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/

- Various fixes against 2.6.23-rc7-mm1.

- I repulled the subsystem git trees, but not the subsystem quilt trees. 
  Large amounts of stuff broke as a result - not a bad effort for 24 hours :(

- git-sched.patch broke and was dropped

- The cpuidle code wasn't readded to the acpi tree today, so it still isn't in
  2.6.23-rc8-mm1.



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git 
tag v2.6.16-rc2-mm1
  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

echo "subscribe mm-commits" | mail [EMAIL PROTECTED]

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
  email Subject: in some manner to reflect the nature of the bug.  Some
  developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.



Changes since 2.6.23-rc7-mm1:


 git-acpi.patch
 git-alsa.patch
 git-arm.patch
 git-audit-master.patch
 git-avr32.patch
 git-cifs.patch
 git-cpufreq.patch
 git-powerpc.patch
 git-powerpc-galak.patch
 git-drm.patch
 git-dvb.patch
 git-hwmon.patch
 git-gfs2-nmw.patch
 git-hid.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-input.patch
 git-jfs.patch
 git-jg-misc.patch
 git-kbuild.patch
 git-kvm.patch
 git-leds.patch
 git-libata-all.patch
 git-md-accel.patch
 git-mips.patch
 git-mmc.patch
 git-mtd.patch
 git-ubi.patch
 git-net.patch
 git-backlight.patch
 git-nfs.patch
 git-nfsd.patch
 git-ocfs2.patch
 git-r8169.patch
 git-selinux.patch
 git-s390.patch
 git-sh.patch
 git-scsi-misc.patch
 git-block.patch
 git-unionfs.patch
 git-watchdog.patch
 git-wireless.patch
 git-ipwireless_cs.patch
 git-newsetup.patch
 git-xfs.patch
 git-cryptodev.patch
 git-kgdb.patch

 git trees

-alsa-procfs-fix.patch
-ehca_irq-misc-cpuinit-section-annotations-and-ifdef-cleanups.patch
-git-backlight-build-fix.patch

 Merged into mainline or a subsystem tree

-fix-potential-oops-in-generic_setlease-v2.patch

 Folded into fix-potential-oops-in-generic_setlease.patch

+fix-potential-oops-in-generic_setlease-fix.patch

 Fix fix-potential-oops-in-generic_setlease.patch

+fix-modules-oopsing-in-lguest-guests.patch

 lguest fix

+git-cifs-build-fix.patch

 Fix git-cifs.patch

+git-hwmon-fixup.patch

 Fix rejects in git-hwmon.patch

+git-jg-warning-fixes.patch

 Fix git-jg-misc.patch

-git-mips-fixup.patch

 Unneeded

-mips-add-gpio-support-to-the-bcm947xx-platform-update.patch

 Folded into  mips-add-gpio-support-to-the-bcm947xx-platform.patch

-mips-gpio-led-driver-for-the-wgt634u-machine.patch
-mips-move-platform-independent-cfe-code-into-arch-mips-cfe.patch
-mips-add-cfe-support-to-bcm947xx-code.patch

 Merged, or broken by git-mips changes.

+git-net-sctp-build-fix.patch
+mv643xx_eth-remove-redundant-multiple-initialization.patch
+iseries_veth-kill-unused-variable.patch
+git-net-fix-pasemi_mac.patch

 Keep fixing git-net.patch

+net-bluetooth-hidp-corec-make-hidp_setup_input.patch

 bluetooth fix

+git-nfsd-fix-generic_setlease-mismerge.patch
+git-nfsd-fix-memory-shortage-can-result-in-inconsistent-flocks-state.patch

 Fix stuff in git-nfsd.patch

+ipsc-update-version-information.patch

 scsi driver fix

+git-block-dasd_eckd-fix.patch
+git-block-ps3disk-fix.patch

 Fix git-block

+usb-skeleton-leaking-locks-on-open.patch

 USB fix

-iwl3945-is-bust.patch
-git-wireless-b44-is-bust.patch

 Unneeded - wireless got better.

+x86-64-calgary-fix-calgary=disable=busnum-for-calioc2.patch
+x86-64-calgary-get-rid-of-translate_phb.patch

 Calgary updates

+mm-use-pagevec-to-rotate-reclaimable-page-fix-2.patch

 Fix mm-use-pagevec-to-rotate-reclaimable-page.patch some more

+memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code-fix-2-3.patch

 Fix memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch
 some more

+maps-pssproportional-set-size-accounting-in-smaps.patch

 /proc/pid/smaps feature

+oom-move-prototypes-to-appropriate-header-file-fix.patch

 Fix oom-move-prototypes-to-appropriate-h

Re: [git] CFS-devel, latest code

[Andrew Morton]

On Tue, 25 Sep 2007 14:13:27 +0530 Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
> > This doornails the Vaio.  After grub handover the screen remains black
> > and the fan goes whir.
> > 
> > http://userweb.kernel.org/~akpm/config-sony.txt
> 
> This seems to be UP regression. Sorry abt that. I could recreate 
> the problem very easily with CONFIG_SMP turned off.
> 
> Can you check if this patch works? Works for me here.
> 
> --
> 
> Fix UP breakage.
> 
> Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
> 
> 
> ---
>  kernel/sched.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: current/kernel/sched.c
> ===
> --- current.orig/kernel/sched.c
> +++ current/kernel/sched.c
> @@ -1029,8 +1029,8 @@ static inline void __set_task_cpu(struct
>  {
>  #ifdef CONFIG_SMP
>   task_thread_info(p)->cpu = cpu;
> - set_task_cfs_rq(p);
>  #endif
> + set_task_cfs_rq(p);
>  }
>  
>  #ifdef CONFIG_SMP

yup, that's a fix.  It was 15 minutes too late for rc8-mm1 though :(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/4] [-mm patch] Rename macros returning the size.

[Ken'ichi Ohmichi]

Hi Satyam,

Satyam Sharma wrote:
> > On Thu, 20 Sep 2007, Ken'ichi Ohmichi wrote:
>> >> [PATCH 5/4] [-mm patch] Rename macros returning the size.
>> >>  The #define SIZE() should be renamed STRUCT_SIZE() since it's always 
>> >>  returning the size of the struct with a given name.  This would allow 
>> >>  TYPEDEF_SIZE() to simply become SIZE() since it need not be used 
>> >>  exclusively for typedefs. This idea is David Rientjes's.
>> >>  http://www.ussg.iu.edu/hypermail/linux/kernel/0709.1/1964.html
>> >>
>> >> Thanks
>> >> Ken'ichi Ohmichi
>> >>
>> >> ---
>> >> Signed-off-by: David Rientjes <[EMAIL PROTECTED]>
> > 
> > Hmm, I think adding a s-o-b line for David here isn't quite correct.
> > When someone reviews a patch and gives a suggestion, you only need to
> > copy him on the next iteration (and he may ack it or whatever, if he
> > wants) -- but adding a s-o-b line like that ends up (incorrectly)
> > denoting that he came between the author-to-git-commit chain ...

Thank you for kind explanation.
I can understand s-o-b clearly.


>> >> Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
> > 
>> >> --- a/include/linux/kexec.h   2007-09-18 15:22:19.0 +0900
>> >> +++ b/include/linux/kexec.h   2007-09-18 15:23:22.0 +0900
>> >> @@ -131,10 +131,10 @@ unsigned long paddr_vmcoreinfo_note(void
>> >>   vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
>> >>  #define VMCOREINFO_SIZE(name) \
>> >>   vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
>> >> -   (unsigned long)sizeof(struct name))
>> >> -#define VMCOREINFO_TYPEDEF_SIZE(name) \
>> >> - vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
>> >> (unsigned long)sizeof(name))
>> >> +#define VMCOREINFO_STRUCT_SIZE(name) \
>> >> + vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
>> >> +   (unsigned long)sizeof(struct name))
>> >>  #define VMCOREINFO_OFFSET(name, field) \
>> >>   vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
>> >> (unsigned long)&(((struct name *)0)->field))
> > 
> > Please use %zu and lose all the ugly (unsigned long) casts here.

That sounds good.
I updated the patch according to your comment.


Thanks
Ken'ichi Ohmichi 

---
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
Acked-by: David Rientjes <[EMAIL PROTECTED]>

---
diff -rpuN a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
--- a/arch/ia64/kernel/machine_kexec.c  2007-09-21 09:25:35.0 +0900
+++ b/arch/ia64/kernel/machine_kexec.c  2007-09-21 09:26:13.0 +0900
@@ -137,7 +137,7 @@ void arch_crash_save_vmcoreinfo(void)
 
VMCOREINFO_SYMBOL(node_memblk);
VMCOREINFO_LENGTH(node_memblk, NR_NODE_MEMBLKS);
-   VMCOREINFO_SIZE(node_memblk_s);
+   VMCOREINFO_STRUCT_SIZE(node_memblk_s);
VMCOREINFO_OFFSET(node_memblk_s, start_paddr);
VMCOREINFO_OFFSET(node_memblk_s, size);
 #endif
diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h
--- a/include/linux/kexec.h 2007-09-21 09:25:32.0 +0900
+++ b/include/linux/kexec.h 2007-09-21 09:27:23.0 +0900
@@ -130,11 +130,9 @@ unsigned long paddr_vmcoreinfo_note(void
 #define VMCOREINFO_SYMBOL(name) \
vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
 #define VMCOREINFO_SIZE(name) \
-   vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
- (unsigned long)sizeof(struct name))
-#define VMCOREINFO_TYPEDEF_SIZE(name) \
-   vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
- (unsigned long)sizeof(name))
+   vmcoreinfo_append_str("SIZE(%s)=%zu\n", #name, sizeof(name))
+#define VMCOREINFO_STRUCT_SIZE(name) \
+   vmcoreinfo_append_str("SIZE(%s)=%zu\n", #name, sizeof(struct name))
 #define VMCOREINFO_OFFSET(name, field) \
vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
  (unsigned long)&(((struct name *)0)->field))
diff -rpuN a/kernel/kexec.c b/kernel/kexec.c
--- a/kernel/kexec.c2007-09-21 09:25:27.0 +0900
+++ b/kernel/kexec.c2007-09-21 09:26:13.0 +0900
@@ -1210,15 +1210,15 @@ static int __init crash_save_vmcoreinfo_
 #ifdef CONFIG_SPARSEMEM
VMCOREINFO_SYMBOL(mem_section);
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
-   VMCOREINFO_SIZE(mem_section);
+   VMCOREINFO_STRUCT_SIZE(mem_section);
VMCOREINFO_OFFSET(mem_section, section_mem_map);
 #endif
-   VMCOREINFO_SIZE(page);
-   VMCOREINFO_SIZE(pglist_data);
-   VMCOREINFO_SIZE(zone);
-   VMCOREINFO_SIZE(free_area);
-   VMCOREINFO_SIZE(list_head);
-   VMCOREINFO_TYPEDEF_SIZE(nodemask_t);
+   VMCOREINFO_STRUCT_SIZE(page);
+   VMCOREINFO_STRUCT_SIZE(pglist_data);
+   VMCOREINFO_STRUCT_SIZE(zone);
+   VMCOREINFO_STRUCT_SIZE(free_area);
+   VMCOREINFO_STRUCT_SIZE(list_head);
+   VMCOREINFO_SIZE(nodemask_t);
VMCOREI

Re: [PATCH 1/4] module: implement module_inhibit_unload()

[Rusty Russell]

On Tue, 2007-09-25 at 17:36 +0900, Tejun Heo wrote:
> Hmmm There doesn't seem to any reason why the blocking should be
> after calling ->exit().  And, yeah, it would be more useful and
> intuitive if blocking happens before ->exit().  What do you think?

*That* I have no problem with.

I was going to say "just grab a reference to every module" except if a
new module is loaded you don't know about it.

If you move your blocking, it seems fine.

Thanks!
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: [PATCH 6/4] [-mm patch] use the existing offsetof().

[Ken'ichi Ohmichi]

Hi Satyam,

Satyam Sharma wrote:
> > BTW I don't think these macros are such a big win in readability or
> > code clarity anyway. And I noticed that there are still some open
> > calls to vmcoreinfo_append_str() in kexec.c (such as for the OS_RELEASE
> > case) which you haven't macro-ized ... we end up having code that looks
> > like:
> > 
> > vmcoreinfo_append_str(...);
> > ...
> > 
> > ...
> > VMCOREINFO_OFFSET(...);
> > ...
> > 
> > and it's not even obvious (unless you follow on to the definition of the
> > later macro) that the above two are *exactly* the same. So you could also
> > consider just losing the macros altogether.

I want to use these macros for calls to vmcoreinfo_append_str(), because
the strings included in each macro ("SIZE(XXX)=", "OFFSET(XXX)=", etc.)
are very important. makedumpfile command reads these strings and gets the
debugging information (structure sizes, field offsets, etc.). If losing
these macros and there is a typo like "OFESET(page.mapping)=", the command
cannot run. To prevent this mistake, these macros are very useful.

For more readability, I think it is good that all the calls are changed
to macros having a prefix "VMCOREINFO_" like the attached patch.


Thanks
Ken'ichi Ohmichi 

---
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>

---
diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h
--- a/include/linux/kexec.h 2007-09-21 09:28:23.0 +0900
+++ b/include/linux/kexec.h 2007-09-21 10:26:24.0 +0900
@@ -127,6 +127,10 @@ void vmcoreinfo_append_str(const char *f
__attribute__ ((format (printf, 1, 2)));
 unsigned long paddr_vmcoreinfo_note(void);
 
+#define VMCOREINFO_OSRELEASE(name) \
+   vmcoreinfo_append_str("OSRELEASE=%s\n", #name)
+#define VMCOREINFO_PAGESIZE(value) \
+   vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
 #define VMCOREINFO_SYMBOL(name) \
vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)&name)
 #define VMCOREINFO_SIZE(name) \
@@ -134,8 +138,8 @@ unsigned long paddr_vmcoreinfo_note(void
 #define VMCOREINFO_STRUCT_SIZE(name) \
vmcoreinfo_append_str("SIZE(%s)=%zu\n", #name, sizeof(struct name))
 #define VMCOREINFO_OFFSET(name, field) \
-   vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
- (unsigned long)&(((struct name *)0)->field))
+   vmcoreinfo_append_str("OFFSET(%s.%s)=%zu\n", #name, #field, \
+ offsetof(struct name, field))
 #define VMCOREINFO_LENGTH(name, value) \
vmcoreinfo_append_str("LENGTH(%s)=%lu\n", #name, (unsigned long)value)
 #define VMCOREINFO_NUMBER(name) \
diff -rpuN a/kernel/kexec.c b/kernel/kexec.c
--- a/kernel/kexec.c2007-09-21 09:28:22.0 +0900
+++ b/kernel/kexec.c2007-09-21 10:17:56.0 +0900
@@ -1195,8 +1195,8 @@ unsigned long __attribute__ ((weak)) pad
 
 static int __init crash_save_vmcoreinfo_init(void)
 {
-   vmcoreinfo_append_str("OSRELEASE=%s\n", init_uts_ns.name.release);
-   vmcoreinfo_append_str("PAGESIZE=%ld\n", PAGE_SIZE);
+   VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
+   VMCOREINFO_PAGESIZE(PAGE_SIZE);
 
VMCOREINFO_SYMBOL(init_uts_ns);
VMCOREINFO_SYMBOL(node_online_map);
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RFC] samples/: move kprobes sources to samples

[Christoph Hellwig]

On Tue, Sep 25, 2007 at 02:13:33PM +0530, Ananth N Mavinakayanahalli wrote:
> +++ linux-2.6.23-rc7/samples/kprobes/jprobe_example.c
> @@ -0,0 +1,69 @@
> +/*jprobe-example.c */

I don't think we should have this type of comment in any of the files.

> +#include 
> +#include 
> +#include 
> +#include 

I don't think you'll need uio,h here.

> + * Jumper probe for do_fork.
> + * Mirror principle enables access to arguments of the probed routine
> + * from the probe handler.
> + */
> +static const char *probed_func = "do_fork";
> +

> + /* Always end with a call to jprobe_return(). */
> + jprobe_return();
> +
> + /*NOTREACHED*/
> + return 0;

I'd rather write this as:

/* Always end with a call to jprobe_return(). */
jprobe_return();
return 0;
}

Also a a note not to these example but general kprobes code I've
bee wondering whether jprobe_return() should just include the return.
Yes, macros including a return are ugly, but in this case jprobe_return
actually handles the return anyway through deep magic.

> +static struct jprobe my_jprobe = {
> + .entry = jdo_fork
> +};
> +
> +static int __init jprobe_init(void)
> +{
> + int ret;
> + my_jprobe.kp.symbol_name = (char *)probed_func;

Shouldn't this be simply done in the static initialization, ala:

static struct jprobe my_jprobe = {
.entry  = jdo_fork,
.kp = {
.symbol_name= "do_fork",
},
};

(same for the other examples)

> +static int handler_pre(struct kprobe *p, struct pt_regs *regs)
> +{
> +#ifdef CONFIG_X86_32
> + printk("pre_handler: p->addr = 0x%p, eip = %lx, eflags = 0x%lx\n",
> + p->addr, regs->eip, regs->eflags);
> +#endif
> +#ifdef CONFIG_X86_64
> + printk("pre_handler: p->addr = 0x%p, rip = %lx, eflags = 0x%lx\n",
> + p->addr, regs->rip, regs->eflags);
> +#endif
> +#ifdef CONFIG_PPC
> + printk("pre_handler: p->addr = 0x%p, nip = 0x%lx, msr = 0x%lx\n",
> + p->addr, regs->nip, regs->msr);
> +#endif

Now this is really ugly.  We should really have macros for the interesting
registers (instruction pointer, frame pointer, stack pointer) in kdebug.h.
systemtap runtime already has them for supported architectures, any care
to port them over?

(note that this is not an objection to the patch as-is, but rather a
 suggestion for later improvement of the whole thing)



Thanks a lot for moving this in the right place!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [-mm patch] Add a prefix "VMCOREINFO_" to the vmcoreinfo macros.

[Ken'ichi Ohmichi]

Hi Andrew,

Andrew Morton wrote:
> > I plan on folding all of
> > 
> > add-vmcoreinfo.patch
> > add-vmcore-cleanup-the-coding-style-according-to-andrews-comments.patch
> > add-vmcore-add-nodemask_ts-size-and-nr_free_pagess-value-to-vmcoreinfo_data.patch
> > add-vmcore-use-the-existing-ia64_tpa-instead-of-asm-code.patch
> > add-vmcore-add-a-prefix-vmcoreinfo_-to-the-vmcoreinfo-macros.patch
> > 
> > into a single patch for upstream.

I created a new single add-vmcoreinfo.patch with the following cleanup patches.

* Cleanup patches:
  1. add-vmcore-cleanup-the-coding-style-according-to-andrews-comments.patch
  2. 
add-vmcore-add-nodemask_ts-size-and-nr_free_pagess-value-to-vmcoreinfo_data.patch
  3. add-vmcore-use-the-existing-ia64_tpa-instead-of-asm-code.patch
  4. add-vmcore-add-a-prefix-vmcoreinfo_-to-the-vmcoreinfo-macros.patch
  5. Re: [PATCH 5/4] [-mm patch] Rename macros returning the size.
 from Ken'ichi Ohmichi, 2007/09/25
 http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0582.html
  6. Re: [PATCH 6/4] [-mm patch] use the existing offsetof().
 from Ken'ichi Ohmichi, 2007/09/25
 http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0584.html

Thanks
Ken'ichi Ohmichi 

---
Signed-off-by: Dan Aloni <[EMAIL PROTECTED]>
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
Signed-off-by: Daisuke Nishimura <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>

---
diff -rpuN a/arch/i386/kernel/machine_kexec.c b/arch/i386/kernel/machine_kexec.c
--- a/arch/i386/kernel/machine_kexec.c  2007-09-21 13:56:02.0 +0900
+++ b/arch/i386/kernel/machine_kexec.c  2007-09-21 13:56:13.0 +0900
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -169,3 +170,15 @@ static int __init parse_crashkernel(char
return 0;
 }
 early_param("crashkernel", parse_crashkernel);
+
+void arch_crash_save_vmcoreinfo(void)
+{
+#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
+   VMCOREINFO_SYMBOL(node_data);
+   VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
+#endif
+#ifdef CONFIG_X86_PAE
+   VMCOREINFO_CONFIG(X86_PAE);
+#endif
+}
+
diff -rpuN a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
--- a/arch/ia64/kernel/machine_kexec.c  2007-09-21 13:56:02.0 +0900
+++ b/arch/ia64/kernel/machine_kexec.c  2007-09-21 14:00:15.0 +0900
@@ -15,10 +15,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 typedef NORET_TYPE void (*relocate_new_kernel_t)(
unsigned long indirection_page,
@@ -125,3 +128,28 @@ void machine_kexec(struct kimage *image)
unw_init_running(ia64_machine_kexec, image);
for(;;);
 }
+
+void arch_crash_save_vmcoreinfo(void)
+{
+#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
+   VMCOREINFO_SYMBOL(pgdat_list);
+   VMCOREINFO_LENGTH(pgdat_list, MAX_NUMNODES);
+
+   VMCOREINFO_SYMBOL(node_memblk);
+   VMCOREINFO_LENGTH(node_memblk, NR_NODE_MEMBLKS);
+   VMCOREINFO_STRUCT_SIZE(node_memblk_s);
+   VMCOREINFO_OFFSET(node_memblk_s, start_paddr);
+   VMCOREINFO_OFFSET(node_memblk_s, size);
+#endif
+#ifdef CONFIG_PGTABLE_3
+   VMCOREINFO_CONFIG(PGTABLE_3);
+#elif CONFIG_PGTABLE_4
+   VMCOREINFO_CONFIG(PGTABLE_4);
+#endif
+}
+
+unsigned long paddr_vmcoreinfo_note(void)
+{
+   return ia64_tpa((unsigned long)(char *)&vmcoreinfo_note);
+}
+
diff -rpuN a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
--- a/arch/ia64/mm/discontig.c  2007-09-21 13:56:02.0 +0900
+++ b/arch/ia64/mm/discontig.c  2007-09-21 13:56:14.0 +0900
@@ -48,7 +48,7 @@ struct early_node_data {
 static struct early_node_data mem_data[MAX_NUMNODES] __initdata;
 static nodemask_t memory_less_mask __initdata;
 
-static pg_data_t *pgdat_list[MAX_NUMNODES];
+pg_data_t *pgdat_list[MAX_NUMNODES];
 
 /*
  * To prevent cache aliasing effects, align per-node structures so that they
diff -rpuN a/arch/x86_64/kernel/machine_kexec.c 
b/arch/x86_64/kernel/machine_kexec.c
--- a/arch/x86_64/kernel/machine_kexec.c2007-09-21 13:56:02.0 
+0900
+++ b/arch/x86_64/kernel/machine_kexec.c2007-09-21 13:56:14.0 
+0900
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -257,3 +258,11 @@ static int __init setup_crashkernel(char
 }
 early_param("crashkernel", setup_crashkernel);
 
+void arch_crash_save_vmcoreinfo(void)
+{
+#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
+   VMCOREINFO_SYMBOL(node_data);
+   VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
+#endif
+}
+
diff -rpuN a/include/asm-ia64/numa.h b/include/asm-ia64/numa.h
--- a/include/asm-ia64/numa.h   2007-09-21 13:56:02.0 +0900
+++ b/include/asm-ia64/numa.h   2007-09-21 13:56:12.0 +0900
@@ -24,6 +24,7 @@
 
 extern u16 cpu_to_node_map[NR_CPUS] __cacheline_aligned;
 extern cpumask_t node_to_cpu_mask[MAX_NUMNODES] __

Re: [RFC] New kernel-message logging API

[Michael Holzheu]

On Mon, 2007-09-24 at 08:19 -0700, Joe Perches wrote:
> On Mon, 2007-09-24 at 11:22 +0200, Michael Holzheu wrote:
> > Together with the idea of not allowing multiple lines in the kprint_xxx
> > functions, that would go with our approach having message numbers to
> > identify a message.
> 
> How does this equate/give message numbers?

It does not give us message numbers. It allows us to tag printks, which
have more than one line, with exactly one number.

Michael

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

Re: [git] CFS-devel, latest code

[Srivatsa Vaddagiri]

On Tue, Sep 25, 2007 at 02:23:29PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
> > > Darn, have news: latency thing isn't dead.  Two busy loops, one at nice
> > > 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> > > latencies below for nice -5 Xorg.  Didn't kill the box though.

These busy loops - are they spawned by the same user? Is it the root
user? Also is this seen in UP mode also?

Can you also pls check if tuning root user's cpu share helps? Basically,

# echo 4096 > /proc/root_user_share

[or any other higher value]

> Also how do you check se.wait_max?

Ok ..I see that it is in /proc/sched_debug.


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

Re: Why do so many machines need "noapic"?

[Thomas Gleixner]

Chuck,

On Thu, 2007-09-13 at 12:38 -0400, Chuck Ebbert wrote:
> On 09/10/2007 03:44 PM, Andi Kleen wrote:
> >> Yes, it has an hpet. And I tried every combination of options I could
> >> think of.
> > 
> >> But, even stranger, x86_64 works (only i386 fails.)
> > 
> > x86-64 has quite different time code (at least until the dyntick patches
> > currently in mm) 
> > 
> > Obvious thing would be to diff the boot messages and see if anything
> > jumps out (e.g. in interrupt routing).  
> > 
> > Or check with mm and if x86-64 is broken there too then it's likely
> > the new time code.
> 
> I reported too soon that x86_64 works. It does not work, it just takes
> a bit longer before it freezes. There are message threads all over the
> place discussing this problem with the HP Pavilion tx 1000, and it seems
> the best workaround is to use the "nolapic" option instead of "noapic".
> Using that, it is totally stable _and_ there are no spurious interrupts
> that would otherwise break USB. Interrupt setup is a bit strange, though:

can you please send me 32 and 64 bit boot logs of mainline and fedora
kernels ?

tglx


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

Re: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

[Peer Chen]

Yes,I hear what you are saying but user should know what they are setting in 
BIOS,there are lots of ways to change the BIOS setting result in unbootable 
system not only change AHCI/IDE mode. If they encounter booting failure after 
changing the BIOS setting,they should restore it.
Using legacy driver for legacy mode won't affect user to enjoy the feature of 
AHCI,just select AHCI/RAID mode will ok.
As I know, Intel did it in the same way,and I think it's reasonable.


--   
Peer Chen
2007-09-25

-
·¢¼þÈË£ºJeff Garzik
·¢ËÍÈÕÆÚ£º2007-09-25 16:13:52
ÊÕ¼þÈË£ºPeer Chen
³­ËÍ£ºlinux-kernel; linux-ide; akpm
Ö÷Ì⣺Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv

Peer Chen wrote:
> We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being 
> load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI 
> being selected, which will verify if our legacy mode work well and have 
> additional option if there is any
> bug for the ahci mode.

I understand that logic, but look at what happens in practice:

1) User installs new OS in AHCI mode.  Distro updates initramfs (loaded 
at kernel boot time, with boot drivers) to include ahci driver.
2) User reboots into BIOS setup, and switches from AHCI mode to IDE mode.
3) BIOS setup reboots computer.
4) OS kernel and initramfs image are loaded.  ahci driver load fails.
5) User is left without a bootable system.

The same situation happens in reverse, if you install in IDE mode 
(sata_nv in initramfs), and then switch to AHCI/RAID mode.

Additionally, AHCI provides better performance and more direct exposure 
to the SATA frames.  This is key for supporting many modern SATA 
features that cannot be accessed via IDE legacy mode.  AHCI lacks 
in-silicon simulation of an IDE interface, which time has shown is a 
less stable, edge-case-prone approach to SATA.

I do not find the "verify nvidia's legacy mode works" argument 
compelling; that is not the kernel's job, nor the user's.  And if there 
is an AHCI silicon bug, let us deal with that when such a bug appears.

Overall, AFAICS this patch -introduces- new ways for the user to easily 
render their systems unbootable.

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: [git] CFS-devel, latest code

[Mike Galbraith]

On Tue, 2007-09-25 at 14:23 +0530, Srivatsa Vaddagiri wrote:

> Mike,
>   Do you have FAIR_USER_SCHED turned on as well? Can you send me
> your .config pls?

I did have.  gzipped config attached.. this is current though, after
disabling groups.  I'm still beating on the basic changes (boy does it
ever feel nice [awaits other shoe]).

-Mike


config.gz
Description: GNU Zip compressed data

Re: [git] CFS-devel, latest code

[Ingo Molnar]

* Mike Galbraith <[EMAIL PROTECTED]> wrote:

> > sched_debug (attached) is.. strange.
> 
> Disabling CONFIG_FAIR_GROUP_SCHED fixed both.  [...]

heh. Evil plan to enable the group scheduler by default worked out as 
planned! ;-) [guess how many container users would do ... interactivity 
tests like you do??]

> [...] Latencies of up to 336ms hit me during the recompile (make -j3), 
> with nothing else running. Since reboot, latencies are, so far, very 
> very nice. [...]

'very very nice' == 'best ever' ? :-)

> [...] I'm leaving it disabled for now.

ok, i'm too seeing some sort of latency weirdness with 
CONFIG_FAIR_GROUP_SCHED enabled, _if_ there's Xorg involved which runs 
under root uid on my box - and hence gets 50% of all CPU time.

Srivatsa, any ideas? It could either be an accounting buglet (less 
likely, seems like the group scheduling bits stick to the 50% splitup 
nicely), or a preemption buglet. One potential preemption buglet would 
be for the group scheduler to not properly preempt a running task when a 
task from another uid is woken?

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: [git] CFS-devel, latest code

[Mike Galbraith]

On Tue, 2007-09-25 at 14:41 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Sep 25, 2007 at 02:23:29PM +0530, Srivatsa Vaddagiri wrote:
> > On Tue, Sep 25, 2007 at 10:33:27AM +0200, Mike Galbraith wrote:
> > > > Darn, have news: latency thing isn't dead.  Two busy loops, one at nice
> > > > 0 pinned to CPU0, and one at nice 19 pinned to CPU1 produced the
> > > > latencies below for nice -5 Xorg.  Didn't kill the box though.
> 
> These busy loops - are they spawned by the same user? Is it the root
> user? Also is this seen in UP mode also?
> 
> Can you also pls check if tuning root user's cpu share helps? Basically,
> 
>   # echo 4096 > /proc/root_user_share
> 
> [or any other higher value]

I'll try these after I beat on the box some more.

-Mike

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

Re: [git] CFS-devel, latest code

[Mike Galbraith]

On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:

> > [...] Latencies of up to 336ms hit me during the recompile (make -j3), 
> > with nothing else running. Since reboot, latencies are, so far, very 
> > very nice. [...]
> 
> 'very very nice' == 'best ever' ? :-)

Yes.  Very VERY nice feel.

-Mike

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

Re: [git] CFS-devel, latest code

[Ingo Molnar]

* S.Çağlar Onur <[EMAIL PROTECTED]> wrote:

> Seems like following trivial change needed to compile without 
> CONFIG_SCHEDSTATS
> 
> [EMAIL PROTECTED] linux-2.6 $ LC_ALL=C make
>   CHK include/linux/version.h
>   CHK include/linux/utsrelease.h
>   CALLscripts/checksyscalls.sh
>   CHK include/linux/compile.h
>   CC  kernel/sched.o
> In file included from kernel/sched.c:853:
> kernel/sched_debug.c: In function `print_cfs_rq':
> kernel/sched_debug.c:139: error: structure has no member named `bkl_cnt'
> kernel/sched_debug.c:139: error: structure has no member named `bkl_cnt'
> make[1]: *** [kernel/sched.o] Error 1
> make: *** [kernel] Error 2
> 
> Signed-off-by: S.Çağlar Onur <[EMAIL PROTECTED]>

thanks, applied!

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: Mask Issue?

[Mel Gorman]

On (24/09/07 18:07), Chris Holvenstot didst pronounce:
> 
> On Mon, 2007-09-24 at 16:39 +0100, Mel Gorman wrote:
> > On (19/09/07 17:57), Chris Holvenstot didst pronounce:
> > > Still being a little new at this I am not sure if this is an issue at
> > > all or not but I noted that while building the 2.6.23-rc6-git8 kernel
> > > this afternoon I received the following error message: 
> > > 
> > > Building modules, stage 2.
> > >   MODPOST 1670 modules
> > > WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0
> > > 
> > > I have been building each of the kernels in the 2.6.23-rc series and had
> > > not noted this message before.  I apologize if this is a non-issue.
> > > 
> > 
> > I noticed this in a -mm recently and never got around to kicking it
> > properly because I suspected it was a compiler issue. What version
> > of gcc and binutils are you using?
> > 
> > David Woodhouse added to cc in case this is a known problem.
> > 
> 
> Mel - 
> 
> Thank you for the response.  I was a little unsure if this was to
> trivial to report.  
> 

It's never trivial but don't be discouraged if your report appears to
fall between the cracks - it happens from time to time particularly when
the subject is a bit obtuse.

> In any case to answer your question I use version 4.1.2 of GCC and the
> binutils package shows as 2.17.20070103cvs-0ubuntu2
> 

As David says the check will go away in the near future, I reckon it's safe
to ignore the problem (unless David objects) and disable it in your .config
and continue with your testing. As the driver is specific to the One Laptop
Per Child project, I'm guessing you are not affected.

Thanks for testing and reporting.

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

Re: libata broken on Pegasos PPC platform (was: Re: IDE broken on Pegasos PPC platform)

[Olaf Hering]

On Mon, Sep 24, Alan Cox wrote:

> hopefully that means the hack in the old VIA driver can also be killed
> off.

Not that I know. But I did not browse the IDE core long enough to figure
out how to assign both irqs in a generic way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IDE broken on Pegasos PPC platform

[Benjamin Herrenschmidt]

On Mon, 2007-09-24 at 22:27 +0100, Matt Sealey wrote:
> Yeah I'll ack it if it matters, although I'd make a nit about the
> fixing of device tree entries in prom_init and have it moved to
> nvramrc or a Forth script or boot loader..
> 
> Pegasos IDE quirks have been "fixed" so many times now in Linux,
> this code's going to get reshuffled again in other changes, I
> think the device tree should be fixed at the firmware level and
> not in the kernel.

In that case though, OF contains correct values for the interrupts, it's
more of an issue related to the device being in legacy mode and the
pci_dev only carrying one interrupt anyway.

Ben.


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

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Damien Wyart]

Hello,

> On 9/25/07, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
> > Do you have CONFIG_ACPI_SLEEP enabled in your .config?

* Torsten Kaiser <[EMAIL PROTECTED]> [2007-09-25 11:08]:
> I'm answering that too, because I suspect that my "2.6.23-rc7-mm1 does
> not power off"-error might have the same cause.

> No, I do not have CONFIG_ACPI_SLEEP set,
> because I do not have CONFIG_PM_SLEEP set,
> because I do not want SUSPEND and/or HIBERNATION.

Same answer from my side: I do not have CONFIG_ACPI_SLEEP for the same
reason (and this worked fine without them in rc7). I do not think these
settings should have changed between rc7 and rc8.

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

Re: Xen kernel 2.6.23-rc7 bug at xen_mc_flush (arch/i386/xen/multicalls.c:68)

[osth]

>Hm, it just seems that its trying to unpin an mm on the error path of
>execve, and so it hasn't been pinned.  The simplest way to reproduce is:
...
>Anyway, try this patch.
Bug is solved by this patch. Thanks! - Maybe this patch can make it into
2.6.23 final?

Christian Ostheimer


Neu: Das erste ADSL-Abo ohne Monatsgebühr! Steigen Sie jetzt auf sunrise
ADSL free um.
http://www.sunrise.ch/privatkunden/iminternetsurfen/adsl/adsl_abosundpreise/adsl_gelegenheitssurfer/adsl_free.htm



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

Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents

[Thomas Gleixner]

Rafael,

On Tue, 2007-09-25 at 10:07 +0200, Thomas Gleixner wrote:
> On Tue, 2007-09-25 at 10:14 +0400, Mikhail Kshevetskiy wrote:
> > Hello Thomas, Rafael
> > 
> > > We know, that
> > > - disabling local apic timers work
> > 
> > As i can see from the log, you are booting on computer with dualcore AMD
> > processor. Do you have C1E feature enabled? 
> > 
> > i386 kernel disable lapic on dualcore AMD with C1E support (see 
> > http://lkml.org/lkml/2007/3/29/199). x86_64 kernel do not have this
> > patch still (it's required for tickless kernel only).
> 
> Well it is required for non tickless mode as well.
> 
> >  As result, if
> > you run x86_64 kernel with hrt patch on such computer, the system
> > will stall during boot on lapic timer calibration.
> 
> Thanks for the reminder. I have a look into this.

Can you please boot mainline and provide the output of:

# cat /proc/interrupts; sleep 10; cat /proc/interrupts

Thanks,

tglx


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

Re: [git] CFS-devel, latest code

[Srivatsa Vaddagiri]

On Tue, Sep 25, 2007 at 11:13:31AM +0200, Ingo Molnar wrote:
> ok, i'm too seeing some sort of latency weirdness with 
> CONFIG_FAIR_GROUP_SCHED enabled, _if_ there's Xorg involved which runs 
> under root uid on my box - and hence gets 50% of all CPU time.
> 
> Srivatsa, any ideas? It could either be an accounting buglet (less 
> likely, seems like the group scheduling bits stick to the 50% splitup 
> nicely), or a preemption buglet. One potential preemption buglet would 
> be for the group scheduler to not properly preempt a running task when a 
> task from another uid is woken?

Yep, I noticed that too.

check_preempt_wakeup()
{
...

if (is_same_group(curr, p)) {
^

resched_task();
}

}

Will try a fix to check for preemption at higher levels ..

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

jbd : config_jbd_debug cannot create /proc entry

[richard kennedy]

I enabled config_jbd_debug in the hope that it may help track down the
lockup I'm seeing, but unfortunately the /proc entry does not get
created.

any ideas how to fix this ?

My machine is an Athlon 64X2 - fedora 7 x86_64 - 2.6.23-rc7

CONFIG_EXT3_FS=m
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y

I added the following patch that shows create_proc_entry is failing

Richard

diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 06ab3c1..40e7ea3 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -1983,7 +1983,8 @@ static void __init create_jbd_proc_entry(void)
/* Why is this so hard? */
proc_jbd_debug->read_proc = read_jbd_debug;
proc_jbd_debug->write_proc = write_jbd_debug;
-   }
+   } else 
+ printk( KERN_WARNING "jbd:cannot create proc entry : " JBD_PROC_NAME 
"\n");
 }
 
 static void __exit remove_jbd_proc_entry(void)


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

Re: [git] CFS-devel, latest code

[Ingo Molnar]

* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 25, 2007 at 11:13:31AM +0200, Ingo Molnar wrote:
> > ok, i'm too seeing some sort of latency weirdness with 
> > CONFIG_FAIR_GROUP_SCHED enabled, _if_ there's Xorg involved which runs 
> > under root uid on my box - and hence gets 50% of all CPU time.
> > 
> > Srivatsa, any ideas? It could either be an accounting buglet (less 
> > likely, seems like the group scheduling bits stick to the 50% splitup 
> > nicely), or a preemption buglet. One potential preemption buglet would 
> > be for the group scheduler to not properly preempt a running task when a 
> > task from another uid is woken?
> 
> Yep, I noticed that too.
> 
> check_preempt_wakeup()
> {
>   ...
> 
>   if (is_same_group(curr, p)) {
>   ^
> 
>   resched_task();
>   }
> 
> }
> 
> Will try a fix to check for preemption at higher levels ..

i bet fixing this will increase precision of group scheduling as well. 
Those long latencies can be thought of as noise as well, and the 
fair-scheduling "engine" might not be capable to offset all sources of 
noise. So generally, while we allow a certain amount of lag in 
preemption decisions (wakeup-granularity, etc.), with which the fairness 
engine will cope just fine, we do not want to allow unlimited lag.

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

Re: [patch 1/2] Enable link power management for ata drivers

[Alan Cox]

> It converts several macros to inline functions (encouraged), and also 
> illustrates a nice, clean way of testing an ID word's validity. 
> [obviously the final implementation varies, depending on that ID word's 
> history]

Its in -mm and I thought you put a copy in your tree after I said it
hadn't upset anything in -mm ?

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: [git] CFS-devel, latest code

[Ingo Molnar]

* Mike Galbraith <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
> 
> > > [...] Latencies of up to 336ms hit me during the recompile (make -j3), 
> > > with nothing else running. Since reboot, latencies are, so far, very 
> > > very nice. [...]
> > 
> > 'very very nice' == 'best ever' ? :-)
> 
> Yes.  Very VERY nice feel.

cool :-)

Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work 
properly then your Xorg will have a load-independent 50% of CPU time all 
to itself. (Group scheduling is quite impressive already: i can log in 
as root without feeling _any_ effect from a perpetual 'hackbench 100' 
running as uid mingo. Fork bombs no more.) Will the Amarok gforce plugin 
like that CPU time splitup? (or is most of the gforce overhead under 
your user uid?)

it could also work out negatively, _sometimes_ X does not like being too 
high prio. (weird as that might be.) So we'll see.

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/

kbuild: LDFLAGS_MODULE unusable for external module builds (2.6.23-rc2)

[Henry Nestler]

In reference of git 114f51577724b782a30f4f5ceaee9880de93d776:

kbuild: use LDFLAGS_MODULE only for .ko links

Sam Ravnborg pointed out that Documentation/kbuild/makefiles.txt already

says this is what it's for.  This patch makes the reality live up to the
documentation.  This fixes the problem of LDFLAGS_BUILD_ID getting into too
many places.


LDFLAGS_MODULE is not usable in module build out of kernel tree since
2.6.23-rc2. LDFLAGS_$@ should use, but does never work. - Not for
external module builds with the option "M=..."

What macro should set for linker parameters of foo.o ? I'm not shure.
Currently found, that only LDFLAGS is usable. But, found LDFLAGS in
modpost calls, there also exist a --start-group/--end-group. Is it right
to use it for external module?

Here examples and the outputs. Host and target is an i686 SMP Linux.

mkdir /tmp/test; cd /tmp/test
cat >Makefile 

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Damien Wyart]

> > No, I do not have CONFIG_ACPI_SLEEP set,
> > because I do not have CONFIG_PM_SLEEP set,
> > because I do not want SUSPEND and/or HIBERNATION.

> Same answer from my side: I do not have CONFIG_ACPI_SLEEP for the same
> reason (and this worked fine without them in rc7). I do not think
> these settings should have changed between rc7 and rc8.

Also, another test I just did: on another computer, rc8 is fine
regarding ACPI power off, even if CONFIG_ACPI_SLEEP is not set. I can
provide config if needed.


Best,

-- 
Damien Wyart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/RFC] samples/: move kprobes sources to samples

[Ananth N Mavinakayanahalli]

On Tue, Sep 25, 2007 at 09:57:11AM +0100, Christoph Hellwig wrote:
> On Tue, Sep 25, 2007 at 02:13:33PM +0530, Ananth N Mavinakayanahalli wrote:
> > +++ linux-2.6.23-rc7/samples/kprobes/jprobe_example.c
> > @@ -0,0 +1,69 @@
> > +/*jprobe-example.c */
> 
> I don't think we should have this type of comment in any of the files.
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> I don't think you'll need uio,h here.

Fixed. Actually, we don't need the fs.h either... I've audited and
cleaned up the other examples also.

> > + * Jumper probe for do_fork.
> > + * Mirror principle enables access to arguments of the probed routine
> > + * from the probe handler.
> > + */
> > +static const char *probed_func = "do_fork";
> > +
> 
> > +   /* Always end with a call to jprobe_return(). */
> > +   jprobe_return();
> > +
> > +   /*NOTREACHED*/
> > +   return 0;
> 
> I'd rather write this as:
> 
>   /* Always end with a call to jprobe_return(). */
>   jprobe_return();
>   return 0;
> }

Fixed

> Also a a note not to these example but general kprobes code I've
> bee wondering whether jprobe_return() should just include the return.
> Yes, macros including a return are ugly, but in this case jprobe_return
> actually handles the return anyway through deep magic.

Right; but the issue here is that in jprobe_return() we don't know what
the jprobed function would return. Also, we've left this the way it
is just so the compiler is happy. (And jprobe_return() is a function
with each arch doing its own magic :-))

> > +static struct jprobe my_jprobe = {
> > +   .entry = jdo_fork
> > +};
> > +
> > +static int __init jprobe_init(void)
> > +{
> > +   int ret;
> > +   my_jprobe.kp.symbol_name = (char *)probed_func;
> 
> Shouldn't this be simply done in the static initialization, ala:
> 
> static struct jprobe my_jprobe = {
>   .entry  = jdo_fork,
>   .kp = {
>   .symbol_name= "do_fork",
>   },
> };
> 
> (same for the other examples)

Agreed. Fixed.

> > +static int handler_pre(struct kprobe *p, struct pt_regs *regs)
> > +{
> > +#ifdef CONFIG_X86_32
> > +   printk("pre_handler: p->addr = 0x%p, eip = %lx, eflags = 0x%lx\n",
> > +   p->addr, regs->eip, regs->eflags);
> > +#endif
> > +#ifdef CONFIG_X86_64
> > +   printk("pre_handler: p->addr = 0x%p, rip = %lx, eflags = 0x%lx\n",
> > +   p->addr, regs->rip, regs->eflags);
> > +#endif
> > +#ifdef CONFIG_PPC
> > +   printk("pre_handler: p->addr = 0x%p, nip = 0x%lx, msr = 0x%lx\n",
> > +   p->addr, regs->nip, regs->msr);
> > +#endif
> 
> Now this is really ugly.  We should really have macros for the interesting
> registers (instruction pointer, frame pointer, stack pointer) in kdebug.h.
> systemtap runtime already has them for supported architectures, any care
> to port them over?
> 
> (note that this is not an objection to the patch as-is, but rather a
>  suggestion for later improvement of the whole thing)

Agreed
 
> Thanks a lot for moving this in the right place!

Updated patch...

Thanks Randy for kicking this off. I've updated kprobe_example.c to work
on powerpc also. In addition I have:

o Removed samples/Kbuild so the build goes on fine
o Modified examples slightly to display output better (cosmetic)
o Changed the kretprobe_example.c to probe do_fork and log the new pid
o Fixed code per roel's nitpicks
o Renamed kretprobe-example.c to kretprobe_example.c for consistancy
o Made changes suggested by Christoph
o Cleaned up unneeded #includes


Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Ananth N Mavinakayanahalli <[EMAIL PROTECTED]>
---
 Documentation/kprobes.txt   |  214 
 samples/Kbuild  |2 
 samples/Kconfig |5 
 samples/Makefile|3 
 samples/kprobes/Makefile|5 
 samples/kprobes/jprobe_example.c|   64 ++
 samples/kprobes/kprobe_example.c|   89 ++
 samples/kprobes/kretprobe_example.c |   59 +
 8 files changed, 230 insertions(+), 211 deletions(-)

Index: linux-2.6.23-rc7/samples/kprobes/Makefile
===
--- /dev/null
+++ linux-2.6.23-rc7/samples/kprobes/Makefile
@@ -0,0 +1,5 @@
+# builds the kprobes example kernel modules;
+# then to use one (as root):  insmod 
+
+obj-$(CONFIG_SAMPLE_KPROBES) += kprobe_example.o jprobe_example.o \
+   kretprobe_example.o
Index: linux-2.6.23-rc7/samples/Kconfig
===
--- linux-2.6.23-rc7.orig/samples/Kconfig
+++ linux-2.6.23-rc7/samples/Kconfig
@@ -7,5 +7,10 @@ menuconfig SAMPLES
 
 if SAMPLES
 
+config SAMPLE_KPROBES
+   tristate "Build kprobes examples -- loadable modules only"
+   depends on KPROBES && m
+   help
+ This builds several kprobes example modules.
 
 endif # SAMPLES
Index: linux-2.6.23-rc7/samples/kprobes/jprobe_

Re: [git] CFS-devel, latest code

[Mike Galbraith]

On Tue, 2007-09-25 at 11:47 +0200, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, 2007-09-25 at 11:13 +0200, Ingo Molnar wrote:
> > 
> > > > [...] Latencies of up to 336ms hit me during the recompile (make -j3), 
> > > > with nothing else running. Since reboot, latencies are, so far, very 
> > > > very nice. [...]
> > > 
> > > 'very very nice' == 'best ever' ? :-)
> > 
> > Yes.  Very VERY nice feel.
> 
> cool :-)
> 
> Maybe there's more to come: if we can get CONFIG_FAIR_USER_SCHED to work 
> properly then your Xorg will have a load-independent 50% of CPU time all 
> to itself. (Group scheduling is quite impressive already: i can log in 
> as root without feeling _any_ effect from a perpetual 'hackbench 100' 
> running as uid mingo. Fork bombs no more.) Will the Amarok gforce plugin 
> like that CPU time splitup? (or is most of the gforce overhead under 
> your user uid?)

I run everything as root (naughty me), so I'd have to change my evil
ways to reap the benefits.  (I'll do that to test, but it's unlikely to
ever become a permanent habit here)  Amarok/Gforce will definitely like
the user split as long as latency is low.  Visualizations are not only
bandwidth hungry, they're extremely latency sensitive.

-Mike

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

Re: [git] CFS-devel, latest code

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> 
> * Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Sep 25, 2007 at 11:13:31AM +0200, Ingo Molnar wrote:
> > > ok, i'm too seeing some sort of latency weirdness with 
> > > CONFIG_FAIR_GROUP_SCHED enabled, _if_ there's Xorg involved which runs 
> > > under root uid on my box - and hence gets 50% of all CPU time.
> > > 
> > > Srivatsa, any ideas? It could either be an accounting buglet (less 
> > > likely, seems like the group scheduling bits stick to the 50% splitup 
> > > nicely), or a preemption buglet. One potential preemption buglet would 
> > > be for the group scheduler to not properly preempt a running task when a 
> > > task from another uid is woken?
> > 
> > Yep, I noticed that too.
> > 
> > check_preempt_wakeup()
> > {
> > ...
> > 
> > if (is_same_group(curr, p)) {
> > ^
> > 
> > resched_task();
> > }
> > 
> > }
> > 
> > Will try a fix to check for preemption at higher levels ..
> 
> i bet fixing this will increase precision of group scheduling as well. 
> Those long latencies can be thought of as noise as well, and the 
> fair-scheduling "engine" might not be capable to offset all sources of 
> noise. So generally, while we allow a certain amount of lag in 
> preemption decisions (wakeup-granularity, etc.), with which the 
> fairness engine will cope just fine, we do not want to allow unlimited 
> lag.

hm, i tried the naive patch. In theory the vruntime of all scheduling 
entities should be 'compatible' and comparable (that's the point behind 
using vruntime - the fairness engine drives each vruntime forward and 
tries to balance them).

So the patch below just removes the is_same_group() condition. But i can 
still see bad (and obvious) latencies with Mike's 2-hogs test:

 taskset 01 perl -e 'while (1) {}' &
 nice -19 taskset 02 perl -e 'while (1) {}' &

So something's amiss.

Ingo

--->
Subject: sched: group scheduler wakeup latency fix
From: Ingo Molnar <[EMAIL PROTECTED]>

group scheduler wakeup latency fix.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 kernel/sched_fair.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: linux/kernel/sched_fair.c
===
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -785,6 +785,7 @@ static void check_preempt_wakeup(struct 
 {
struct task_struct *curr = rq->curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
+   s64 delta;
 
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -792,12 +793,10 @@ static void check_preempt_wakeup(struct 
resched_task(curr);
return;
}
-   if (is_same_group(curr, p)) {
-   s64 delta = curr->se.vruntime - p->se.vruntime;
+   delta = curr->se.vruntime - p->se.vruntime;
 
-   if (delta > (s64)sysctl_sched_wakeup_granularity)
-   resched_task(curr);
-   }
+   if (delta > (s64)sysctl_sched_wakeup_granularity)
+   resched_task(curr);
 }
 
 static struct task_struct *pick_next_task_fair(struct rq *rq)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd high CPU usage with no swap

[Jan Kundrát]

Rik van Riel wrote:
> How much memory did you have in "cached" when you looked
> with top (and no swap enabled) ?

Hi Rik,
it was pretty low number (several thousands, or maybe tens of thousands).

In the meanwhile, I've come across your patch [1] ("prevent kswapd from
freeing excessive amounts of lowmem") and applied it locally. I'll see
if it fixes my problem, but at a first glance, it seems that it might
actually slow other things down -- when I switch windows, konqueror's
screen redrawing seems to be pretty slow and I can see it progressing
from top to bottom...

[1] http://lkml.org/lkml/2007/9/5/289

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [git] CFS-devel, latest code

[Srivatsa Vaddagiri]

On Tue, Sep 25, 2007 at 12:10:44PM +0200, Ingo Molnar wrote:
> So the patch below just removes the is_same_group() condition. But i can 
> still see bad (and obvious) latencies with Mike's 2-hogs test:
> 
>  taskset 01 perl -e 'while (1) {}' &
>  nice -19 taskset 02 perl -e 'while (1) {}' &
> 
> So something's amiss.

While I try recreating this myself, I wonder if this patch helps?

---
 kernel/sched_fair.c |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

Index: current/kernel/sched_fair.c
===
--- current.orig/kernel/sched_fair.c
+++ current/kernel/sched_fair.c
@@ -794,7 +794,8 @@ static void yield_task_fair(struct rq *r
 static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
 {
struct task_struct *curr = rq->curr;
-   struct cfs_rq *cfs_rq = task_cfs_rq(curr);
+   struct cfs_rq *cfs_rq = task_cfs_rq(curr), *pcfs_rq;
+   struct sched_entity *se = &curr->se, *pse = &p->se;
 
if (unlikely(rt_prio(p->prio))) {
update_rq_clock(rq);
@@ -802,11 +803,19 @@ static void check_preempt_wakeup(struct 
resched_task(curr);
return;
}
-   if (is_same_group(curr, p)) {
-   s64 delta = curr->se.vruntime - p->se.vruntime;
 
-   if (delta > (s64)sysctl_sched_wakeup_granularity)
-   resched_task(curr);
+   for_each_sched_entity(se) {
+   cfs_rq = cfs_rq_of(se);
+   pcfs_rq = cfs_rq_of(pse);
+
+   if (cfs_rq == pcfs_rq) {
+   s64 delta = se->vruntime - pse->vruntime;
+
+   if (delta > (s64)sysctl_sched_wakeup_granularity)
+   resched_task(curr);
+   break;
+   }
+   pse = pse->parent;
}
 }
 

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

Re: s2ram + usb

[Jiri Kosina]

(linux-usb-devel added to CC)

On Tue, 25 Sep 2007, Mihai Don?u wrote:

> [1.743528] Restarting tasks ... <3>hub 1-0:1.0: port 5 disabled by hub 
> (EMI?), re-enabling...
> [1.743563] usb 1-5: USB disconnect, address 3
> [1.782485] usb 1-5: new high speed USB device using ehci_hcd and address 6
> [1.785747] done.
> [1.831805] usb 1-5: configuration #1 chosen from 1 choice
> [1.834418] scsi3 : SCSI emulation for USB Mass Storage devices
> [1.834741] usb-storage: device found at 6
> [1.834785] usb-storage: waiting for device to settle before scanning
> [1.845293] ohci_hcd :00:13.1: Unlink after no-IRQ?  Controller is 
> probably using the wrong IRQ.

Hi Mihai,

does booting with 'irqpoll' kernel parameter have any effect?

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

Re: 2.6.23-rc7-mm1

[Mel Gorman]

On (25/09/07 01:11), Kamalesh Babulal didst pronounce:

Hi Kamalesh,

> The build fails with following error
> 
> CC drivers/block/ps3disk.o
> drivers/block/ps3disk.c: In function ???ps3disk_scatter_gather???:
> drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in this
> function)
> drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
> reported only once
> drivers/block/ps3disk.c:115: error: for each function it appears in.)
> drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
> function)
> drivers/block/ps3disk.c:116: error: implicit declaration of function
> ???bio_kunmap_bvec???
> make[2]: *** [drivers/block/ps3disk.o] Error 1
> make[1]: *** [drivers/block] Error 2
> make: *** [drivers] Error 2
> 
> The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
> as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
> find this function.
> 
> Previously this function was replaced by __bio_kunmap_atomic();
> This patch does not solves the implicit "declaration of function
> ???bio_kunmap_bvec???"
> 
> Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]
> >

Your mailer appears to have mangled both your signoff and the whitespace in
the patch and it does not apply. However, fixing it does not solve the problem
because of this mysterious bio_kunmap_bvec() that is only referenced by this
driver. Was it accidently added during the addition of sg chaining support?

> ---
> 
> --- linux-2.6.23-rc7/drivers/block/ps3disk.c2007-09-24 20:50:41.0 
> +0530
> +++ linux-2.6.23-rc7/drivers/block/~ps3disk.c   2007-09-24 20:50:59.0 
> +0530
> @@ -112,7 +112,7 @@ static void ps3disk_scatter_gather(struc
> else
> memcpy(buf, dev->bounce_buf+offset, size);
> offset += size;
> -   flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
> +  flush_kernel_dcache_page(bio_iovec_idx(iter.bio, 
> iter.i)->bv_page);
> bio_kunmap_bvec(bvec, flags);
> i++;
> }
> 
> -- 
> 
> Thanks & Regards,
> Kamalesh Babulal,
> Linux Technology Center,
> IBM, ISTL.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: 2.6.23-rc7-mm1

[Jens Axboe]

On Tue, Sep 25 2007, Mel Gorman wrote:
> On (25/09/07 01:11), Kamalesh Babulal didst pronounce:
> 
> Hi Kamalesh,
> 
> > The build fails with following error
> > 
> > CC drivers/block/ps3disk.o
> > drivers/block/ps3disk.c: In function ???ps3disk_scatter_gather???:
> > drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in this
> > function)
> > drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
> > reported only once
> > drivers/block/ps3disk.c:115: error: for each function it appears in.)
> > drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
> > function)
> > drivers/block/ps3disk.c:116: error: implicit declaration of function
> > ???bio_kunmap_bvec???
> > make[2]: *** [drivers/block/ps3disk.o] Error 1
> > make[1]: *** [drivers/block] Error 2
> > make: *** [drivers] Error 2
> > 
> > The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
> > as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
> > find this function.
> > 
> > Previously this function was replaced by __bio_kunmap_atomic();
> > This patch does not solves the implicit "declaration of function
> > ???bio_kunmap_bvec???"
> > 
> > Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]
> > >
> 
> Your mailer appears to have mangled both your signoff and the whitespace in
> the patch and it does not apply. However, fixing it does not solve the problem
> because of this mysterious bio_kunmap_bvec() that is only referenced by this
> driver. Was it accidently added during the addition of sg chaining support?

This should fix things up.

diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 8e05ba7..a7fd66a 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -106,14 +106,14 @@ static void ps3disk_scatter_gather(struct 
ps3_storage_device *dev,
(unsigned long)iter.bio->bi_sector);
 
size = bvec->bv_len;
-   buf = bvec_kmap_irq(bvec, flags);
+   buf = bvec_kmap_irq(bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
-   flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
-   bio_kunmap_bvec(bvec, flags);
+   flush_kernel_dcache_page(bvec->bv_page);
+   bvec_kunmap_irq(buf, &flags);
i++;
}
 }

-- 
Jens Axboe

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

Re: [git] CFS-devel, latest code

[Ingo Molnar]

* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 25, 2007 at 12:10:44PM +0200, Ingo Molnar wrote:
> > So the patch below just removes the is_same_group() condition. But i can 
> > still see bad (and obvious) latencies with Mike's 2-hogs test:
> > 
> >  taskset 01 perl -e 'while (1) {}' &
> >  nice -19 taskset 02 perl -e 'while (1) {}' &
> > 
> > So something's amiss.
> 
> While I try recreating this myself, I wonder if this patch helps?

you should be able to recreate this easily by booting with maxcpus=1 and 
the commands above - then run a few instances of chew-max (without them 
being bound to any particular CPUs) and the latencies should show up.

i have tried your patch and it does not solve the problem - i think 
there's a more fundamental bug lurking, besides the wakeup latency 
problem.

Find below a /proc/sched_debug output of a really large latency. The 
latency is caused by the _huge_ (~450 seconds!) vruntime offset that 
'loop_silent' and 'sshd' has:

task   PID tree-key  switches  prio exec-runtime
 ---
 loop_silent  2391 55344.211189   203   120 55344.211189
sshd  2440513334.978030 4   120513334.978030
Rcat  2496513672.558835 4   120513672.558835

hm. perhaps this fixup in kernel/sched.c:set_task_cpu():

p->se.vruntime -= old_rq->cfs.min_vruntime - new_rq->cfs.min_vruntime;

needs to become properly group-hierarchy aware?

Ingo

-->
Sched Debug Version: v0.05-v20, 2.6.23-rc7 #89
now at 95878.065440 msecs
  .sysctl_sched_latency: 20.00
  .sysctl_sched_min_granularity: 2.00
  .sysctl_sched_wakeup_granularity : 2.00
  .sysctl_sched_batch_wakeup_granularity   : 25.00
  .sysctl_sched_child_runs_first   : 0.01
  .sysctl_sched_features   : 3

cpu#0, 1828.868 MHz
  .nr_running: 3
  .load  : 3072
  .nr_switches   : 32032
  .nr_load_updates   : 95906
  .nr_uninterruptible: 4294967238
  .jiffies   : 4294763202
  .next_balance  : 4294.763420
  .curr->pid : 2496
  .clock : 95893.484495
  .idle_clock: 55385.089335
  .prev_clock_raw: 84753.749367
  .clock_warps   : 0
  .clock_overflows   : 1737
  .clock_deep_idle_events: 71815
  .clock_max_delta   : 0.999843
  .cpu_load[0]   : 3072
  .cpu_load[1]   : 2560
  .cpu_load[2]   : 2304
  .cpu_load[3]   : 2176
  .cpu_load[4]   : 2119

cfs_rq
  .exec_clock: 38202.223241
  .MIN_vruntime  : 36334.281860
  .min_vruntime  : 36334.279140
  .max_vruntime  : 36334.281860
  .spread: 0.00
  .spread0   : 0.00
  .nr_running: 2
  .load  : 3072
  .bkl_cnt   : 3934
  .nr_spread_over: 37

cfs_rq
  .exec_clock: 34769.316246
  .MIN_vruntime  : 55344.211189
  .min_vruntime  : 36334.279140
  .max_vruntime  : 513334.978030
  .spread: 457990.766841
  .spread0   : 0.00
  .nr_running: 2
  .load  : 2048
  .bkl_cnt   : 3934
  .nr_spread_over: 10

cfs_rq
  .exec_clock: 36.982394
  .MIN_vruntime  : 0.01
  .min_vruntime  : 36334.279140
  .max_vruntime  : 0.01
  .spread: 0.00
  .spread0   : 0.00
  .nr_running: 0
  .load  : 0
  .bkl_cnt   : 3934
  .nr_spread_over: 1

cfs_rq
  .exec_clock: 20.244893
  .MIN_vruntime  : 0.01
  .min_vruntime  : 36334.279140
  .max_vruntime  : 0.01
  .spread: 0.00
  .spread0   : 0.00
  .nr_running: 0
  .load  : 0
  .bkl_cnt   : 3934
  .nr_spread_over: 0

cfs_rq
  .exec_clock: 3305.155973
  .MIN_vruntime  : 0.01
  .min_vruntime  : 36334.279140
  .max_vruntime  : 0.01
  .spread: 0.00
  .spread0   : 0.00
  .nr_running: 1
  .load  : 1024
  .bkl_cnt   : 3934
  .nr_spread_over 

Re: [PATCH/RFC] samples/: move kprobes sources to samples

[Sam Ravnborg]

Hi Ananth.

> o Removed samples/Kbuild so the build goes on fine

You could have added the obj-y assignment to Kbuild
for the same effect.
Kbuild is the first filename searched by kbuild, next is Makefile.

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

Re: [PATCH] Fix messed hunks in generic_setlease

[Kamalesh Babulal]

Pavel Emelyanov wrote:
> I have noticed, that one hunk was lost and one duplicated 
> during merging the fix-potential-oops-in-generic_setlease(-xxx) 
> patches. One of the fixes is already in the hot-fixes, but the
> second one is still lost.
> 
> The returned pointer was not the one allocated, but some temporary
> used to scan through the inode's locks list. This caused and OOPS 
> during Kamalesh's testing.
> 
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> 
> ---
> 
> diff --git a/fs/locks.c b/fs/locks.c
> index c0fe71a..c1198e3 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1423,7 +1418,7 @@ int generic_setlease(struct file *filp, 
>   locks_copy_lock(new_fl, lease);
>   locks_insert_lock(before, new_fl);
> 
> - *flp = fl;
> + *flp = new_fl;
>   return 0;
> 
>  out:
> 

Hi Pavel,

I tested your patch and NULL pointer dereference is not triggered.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc8-mm1

[Kamalesh Babulal]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm1/

Hi Andrew,

The build error reported at http://lkml.org/lkml/2007/9/20/210 for the
drivers/ata/pata_scc.c is seen in both 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1.

The patch proposed for this build error at http://lkml.org/lkml/2007/9/21/557
is not seen in the latest 2.6.23-rc8-mm1 patch's.

-- 
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: jbd : config_jbd_debug cannot create /proc entry

[Jan Kara]

> I enabled config_jbd_debug in the hope that it may help track down the
> lockup I'm seeing, but unfortunately the /proc entry does not get
> created.
> 
> any ideas how to fix this ?
  Attached is a patch that should fix it. Andrew, would you queue it up?

Honza

JBD debug code used old way of creating proc entries for jbd-debug file.
Change it to use sysctl instead.

Signed-off-by: Jan Kara <[EMAIL PROTECTED]>

diff -rupX /home/jack/.kerndiffexclude linux-2.6.23-rc6/fs/jbd/journal.c 
linux-2.6.23-rc6-1-jbddebug_fix/fs/jbd/journal.c
--- linux-2.6.23-rc6/fs/jbd/journal.c   2007-09-25 12:39:53.0 +0200
+++ linux-2.6.23-rc6-1-jbddebug_fix/fs/jbd/journal.c2007-09-25 
13:05:05.0 +0200
@@ -1944,58 +1944,29 @@ void journal_put_journal_head(struct jou
 #if defined(CONFIG_JBD_DEBUG)
 int journal_enable_debug;
 EXPORT_SYMBOL(journal_enable_debug);
-#endif
-
-#if defined(CONFIG_JBD_DEBUG) && defined(CONFIG_PROC_FS)
-
-static struct proc_dir_entry *proc_jbd_debug;
-
-static int read_jbd_debug(char *page, char **start, off_t off,
- int count, int *eof, void *data)
-{
-   int ret;
-
-   ret = sprintf(page + off, "%d\n", journal_enable_debug);
-   *eof = 1;
-   return ret;
-}
-
-static int write_jbd_debug(struct file *file, const char __user *buffer,
-  unsigned long count, void *data)
-{
-   char buf[32];
-
-   if (count > ARRAY_SIZE(buf) - 1)
-   count = ARRAY_SIZE(buf) - 1;
-   if (copy_from_user(buf, buffer, count))
-   return -EFAULT;
-   buf[ARRAY_SIZE(buf) - 1] = '\0';
-   journal_enable_debug = simple_strtoul(buf, NULL, 10);
-   return count;
-}
+static struct ctl_table_header *jbd_debug_table;
 
-#define JBD_PROC_NAME "sys/fs/jbd-debug"
-
-static void __init create_jbd_proc_entry(void)
-{
-   proc_jbd_debug = create_proc_entry(JBD_PROC_NAME, 0644, NULL);
-   if (proc_jbd_debug) {
-   /* Why is this so hard? */
-   proc_jbd_debug->read_proc = read_jbd_debug;
-   proc_jbd_debug->write_proc = write_jbd_debug;
-   }
-}
-
-static void __exit remove_jbd_proc_entry(void)
-{
-   if (proc_jbd_debug)
-   remove_proc_entry(JBD_PROC_NAME, NULL);
-}
-
-#else
-
-#define create_jbd_proc_entry() do {} while (0)
-#define remove_jbd_proc_entry() do {} while (0)
+static ctl_table fs_table[] = {
+   {
+.ctl_name   = -1,  /* Don't want it */
+.procname   = "jbd-debug",
+.data   = &journal_enable_debug,
+.maxlen = sizeof(int),
+.mode   = 0644,
+.proc_handler   = &proc_dointvec,
+},
+{ .ctl_name = 0 },
+};
+
+static ctl_table sys_table[] = {
+{
+.ctl_name   = CTL_FS,
+.procname   = "fs",
+.mode   = 0555,
+.child  = fs_table,
+},
+{ .ctl_name = 0 },
+};
 
 #endif
 
@@ -2054,7 +2025,10 @@ static int __init journal_init(void)
ret = journal_init_caches();
if (ret != 0)
journal_destroy_caches();
-   create_jbd_proc_entry();
+
+#ifdef CONFIG_JBD_DEBUG
+   jbd_debug_table = register_sysctl_table(sys_table);
+#endif
return ret;
 }
 
@@ -2064,8 +2038,8 @@ static void __exit journal_exit(void)
int n = atomic_read(&nr_journal_heads);
if (n)
printk(KERN_EMERG "JBD: leaked %d journal_heads!\n", n);
+   unregister_sysctl_table(jbd_debug_table);
 #endif
-   remove_jbd_proc_entry();
journal_destroy_caches();
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Uninline the task_xid_nr_ns() calls

[Pavel Emelyanov]

Since these are expanded into call to pid_nr_ns() anyway, it's
OK to move the whole routine out-of-line. This is a cheap way 
to save ~100 bytes from vmlinux. Together with the previous two
patches, it saves half-a-kilo from the vmlinux.

Un-inline other (currently inlined) functions must be done with
additional performance testing.

Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>

---

diff --git a/include/linux/sched.h b/include/linux/sched.h
index fe238fb..4108cce 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1228,11 +1228,7 @@ static inline pid_t task_pid_nr(struct t
return tsk->pid;
 }
 
-static inline pid_t task_pid_nr_ns(struct task_struct *tsk,
-   struct pid_namespace *ns)
-{
-   return pid_nr_ns(task_pid(tsk), ns);
-}
+pid_t task_pid_nr_ns(struct task_struct *tsk, struct pid_namespace *ns);
 
 static inline pid_t task_pid_vnr(struct task_struct *tsk)
 {
@@ -1245,11 +1241,7 @@ static inline pid_t task_tgid_nr(struct 
return tsk->tgid;
 }
 
-static inline pid_t task_tgid_nr_ns(struct task_struct *tsk,
-   struct pid_namespace *ns)
-{
-   return pid_nr_ns(task_tgid(tsk), ns);
-}
+pid_t task_tgid_nr_ns(struct task_struct *tsk, struct pid_namespace *ns);
 
 static inline pid_t task_tgid_vnr(struct task_struct *tsk)
 {
@@ -1262,11 +1254,7 @@ static inline pid_t task_pgrp_nr(struct 
return tsk->signal->__pgrp;
 }
 
-static inline pid_t task_pgrp_nr_ns(struct task_struct *tsk,
-   struct pid_namespace *ns)
-{
-   return pid_nr_ns(task_pgrp(tsk), ns);
-}
+pid_t task_pgrp_nr_ns(struct task_struct *tsk, struct pid_namespace *ns);
 
 static inline pid_t task_pgrp_vnr(struct task_struct *tsk)
 {
@@ -1279,11 +1267,7 @@ static inline pid_t task_session_nr(stru
return tsk->signal->__session;
 }
 
-static inline pid_t task_session_nr_ns(struct task_struct *tsk,
-   struct pid_namespace *ns)
-{
-   return pid_nr_ns(task_session(tsk), ns);
-}
+pid_t task_session_nr_ns(struct task_struct *tsk, struct pid_namespace *ns);
 
 static inline pid_t task_session_vnr(struct task_struct *tsk)
 {
diff --git a/kernel/pid.c b/kernel/pid.c
index e2e060e..0032a88 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -412,6 +412,30 @@ pid_t pid_nr_ns(struct pid *pid, struct 
return nr;
 }
 
+pid_t task_pid_nr_ns(struct task_struct *tsk, struct pid_namespace *ns)
+{
+   return pid_nr_ns(task_pid(tsk), ns);
+}
+EXPORT_SYMBOL(task_pid_nr_ns);
+
+pid_t task_tgid_nr_ns(struct task_struct *tsk, struct pid_namespace *ns)
+{
+   return pid_nr_ns(task_tgid(tsk), ns);
+}
+EXPORT_SYMBOL(task_tgid_nr_ns);
+
+pid_t task_pgrp_nr_ns(struct task_struct *tsk, struct pid_namespace *ns)
+{
+   return pid_nr_ns(task_pgrp(tsk), ns);
+}
+EXPORT_SYMBOL(task_pgrp_nr_ns);
+
+pid_t task_session_nr_ns(struct task_struct *tsk, struct pid_namespace *ns)
+{
+   return pid_nr_ns(task_session(tsk), ns);
+}
+EXPORT_SYMBOL(task_session_nr_ns);
+
 /*
  * Used by proc to find the first pid that is greater then or equal to nr.
  *
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 6/7] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers wrote:
> >* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> >>On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
> >>
> >>>* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
> 
> >Christoph Hellwig wrote:
> >>On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> >>>I think that samples are perfectly fine for documentation and
> >>>that the trace example is a good example.  I think that most people
> >>>who need something like that would need to customize it for their
> >>>specific needs anyway.
> >>>
> >>>We don't seem to be making progress...
> >>Time to bring in a Tie-Breaker :)
> >Yes.  Is anyone else interested?   :(
> 
> I guess that's everyone (except those who are sleeping).
> 
> Let's not hold up progress.  Just use samples/ for code.
> >>>Would you already have the 
> >>>
> >>>Makefile
> >>>samples/Kconfig
> >>>samples/Makefile
> >>>
> >>>core code handy per chance ? (and probably Kconfig sourcing in every
> >>>arch ?)
> >>Yes.  Here it is.  I'm working on add kprobes to it, but you
> >>can go ahead with markers also.
> >>
> >>
> >
> >Hi Randy,
> >
> >I got everything working and I'm thinking about posting all this stuff
> >soon. Do you think your patch (having renamed Kbuild to Makefile) is
> >ready to post ?
> 
> Yes, AFAIK it is.  Do you want me to resend it or do you want to
> make it patch M/N in your patches?
> 

I'll include it with my patches. Thanks!

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

Re: [git] CFS-devel, latest code

[Ingo Molnar]

* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 25, 2007 at 12:41:20AM -0700, Andrew Morton wrote:
> > This doornails the Vaio.  After grub handover the screen remains black
> > and the fan goes whir.
> > 
> > http://userweb.kernel.org/~akpm/config-sony.txt
> 
> This seems to be UP regression. Sorry abt that. I could recreate 
> the problem very easily with CONFIG_SMP turned off.
> 
> Can you check if this patch works? Works for me here.

thanks - i've put this fix into the core group-scheduling patch.

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: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Daniel Ritz]

does that one help?

[ as attachment since i'm on webmail ]

ACPI: acpi_sleep_prepare() should not depent on CONFIG_SUSPEND
Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser


acpi-sleep.patch
Description: Binary data

Re: jbd : config_jbd_debug cannot create /proc entry

[Aneesh Kumar K.V]

Jan Kara wrote:



-#define create_jbd_proc_entry() do {} while (0)
-#define remove_jbd_proc_entry() do {} while (0)
+static ctl_table fs_table[] = {
+   {
+.ctl_name   = -1,  /* Don't want it */




shouldn't this be CTL_UNNUMBERED ?



+.procname   = "jbd-debug",
+.data   = &journal_enable_debug,
+.maxlen = sizeof(int),
+.mode   = 0644,
+.proc_handler   = &proc_dointvec,
+},
+{ .ctl_name = 0 },
+};



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

Re: 2.6.23-rc7-mm1

[Peter Zijlstra]

On Mon, 24 Sep 2007 21:20:58 +0200 Peter Zijlstra
<[EMAIL PROTECTED]> wrote:

> > > Nope, and the stacktrace is utterly puzzling.
> > > 
> > > /me goes read the lkml.org link
> > > 
> > > Kamalesh Babulal: do you still get:
> > >   BUG: spinlock bad magic on
> > > 
> > > msgs?
> > > 
> > > Because those I could reproduce using fsx, and I fixed all that.
> > Hi Peter,
> > 
> > I do not get BUG: spinlock bad magic messages any more, but the softlock 
> > message is
> > thrown more than 30 time, while running the ltp runall.
> 
> It would be good to know what function on_each_cpu is executing, could
> you try something like:

I've just completed 2 full ltp runs on a dual-core opteron machine but
could not reproduce this problem.

Kamalesh, would it be possible for you to reproduce with that patch, so
we can see what function is holding up the cpu?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc7-mm1

[Mel Gorman]

On (25/09/07 12:31), Jens Axboe didst pronounce:
> On Tue, Sep 25 2007, Mel Gorman wrote:
> > On (25/09/07 01:11), Kamalesh Babulal didst pronounce:
> > 
> > Hi Kamalesh,
> > 
> > > The build fails with following error
> > > 
> > > CC drivers/block/ps3disk.o
> > > drivers/block/ps3disk.c: In function ???ps3disk_scatter_gather???:
> > > drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in 
> > > this
> > > function)
> > > drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
> > > reported only once
> > > drivers/block/ps3disk.c:115: error: for each function it appears in.)
> > > drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
> > > function)
> > > drivers/block/ps3disk.c:116: error: implicit declaration of function
> > > ???bio_kunmap_bvec???
> > > make[2]: *** [drivers/block/ps3disk.o] Error 1
> > > make[1]: *** [drivers/block] Error 2
> > > make: *** [drivers] Error 2
> > > 
> > > The function bio_kunmap_bvec is missing.I tried checking the 
> > > git-block.patch
> > > as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
> > > find this function.
> > > 
> > > Previously this function was replaced by __bio_kunmap_atomic();
> > > This patch does not solves the implicit "declaration of function
> > > ???bio_kunmap_bvec???"
> > > 
> > > Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]
> > > >
> > 
> > Your mailer appears to have mangled both your signoff and the whitespace in
> > the patch and it does not apply. However, fixing it does not solve the 
> > problem
> > because of this mysterious bio_kunmap_bvec() that is only referenced by this
> > driver. Was it accidently added during the addition of sg chaining support?
> 
> This should fix things up.
> 

This builds although I lack the hardware to really test it. However, in
2.6.23-rc8-mm1 it collides with git-block-ps3disk-fix.patch. This is a
version on top of that stack but I guess the best thing to do is replace
git-block-ps3disk-fix.patch with Jens patch once it is signed off.

Not signing off because this is just a rebase. Assuming the other one
gets signed off, consider it;

Acked-by: Mel Gorman <[EMAIL PROTECTED]>

--- 

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff 
linux-2.6.23-rc8-mm1-clean/drivers/block/ps3disk.c 
linux-2.6.23-rc8-mm1-fix-ps3disk/drivers/block/ps3disk.c
--- linux-2.6.23-rc8-mm1-clean/drivers/block/ps3disk.c  2007-09-25 
12:05:40.0 +0100
+++ linux-2.6.23-rc8-mm1-fix-ps3disk/drivers/block/ps3disk.c2007-09-25 
12:09:19.0 +0100
@@ -106,14 +106,14 @@ static void ps3disk_scatter_gather(struc
(unsigned long)iter.bio->bi_sector);
 
size = bvec->bv_len;
-   buf = bvec_kmap_irq(bvec, flags);
+   buf = bvec_kmap_irq(bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
-   flush_kernel_dcache_page(bio_iovec_idx(iter.bio, 
iter.i)->bv_page);
-   bio_kunmap_bvec(bvec, flags);
+   flush_kernel_dcache_page(bvec->bv_page);
+   bvec_kunmap_irq(buf, &flags);
i++;
}
 }

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

Re: 2.6.23-rc7-mm1

[Jens Axboe]

On Tue, Sep 25 2007, Mel Gorman wrote:
> On (25/09/07 12:31), Jens Axboe didst pronounce:
> > On Tue, Sep 25 2007, Mel Gorman wrote:
> > > On (25/09/07 01:11), Kamalesh Babulal didst pronounce:
> > > 
> > > Hi Kamalesh,
> > > 
> > > > The build fails with following error
> > > > 
> > > > CC drivers/block/ps3disk.o
> > > > drivers/block/ps3disk.c: In function ???ps3disk_scatter_gather???:
> > > > drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in 
> > > > this
> > > > function)
> > > > drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
> > > > reported only once
> > > > drivers/block/ps3disk.c:115: error: for each function it appears in.)
> > > > drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in 
> > > > this
> > > > function)
> > > > drivers/block/ps3disk.c:116: error: implicit declaration of function
> > > > ???bio_kunmap_bvec???
> > > > make[2]: *** [drivers/block/ps3disk.o] Error 1
> > > > make[1]: *** [drivers/block] Error 2
> > > > make: *** [drivers] Error 2
> > > > 
> > > > The function bio_kunmap_bvec is missing.I tried checking the 
> > > > git-block.patch
> > > > as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
> > > > find this function.
> > > > 
> > > > Previously this function was replaced by __bio_kunmap_atomic();
> > > > This patch does not solves the implicit "declaration of function
> > > > ???bio_kunmap_bvec???"
> > > > 
> > > > Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]
> > > > >
> > > 
> > > Your mailer appears to have mangled both your signoff and the whitespace 
> > > in
> > > the patch and it does not apply. However, fixing it does not solve the 
> > > problem
> > > because of this mysterious bio_kunmap_bvec() that is only referenced by 
> > > this
> > > driver. Was it accidently added during the addition of sg chaining 
> > > support?
> > 
> > This should fix things up.
> > 
> 
> This builds although I lack the hardware to really test it. However, in
> 2.6.23-rc8-mm1 it collides with git-block-ps3disk-fix.patch. This is a
> version on top of that stack but I guess the best thing to do is replace
> git-block-ps3disk-fix.patch with Jens patch once it is signed off.
> 
> Not signing off because this is just a rebase. Assuming the other one
> gets signed off, consider it;

Thanks, but I already integrated the fix into the existing patch, so
that bisect will work.

-- 
Jens Axboe

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

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Alexey Starikovskiy]

Torsten Kaiser wrote:
> On 9/25/07, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote:
>> Do you have CONFIG_ACPI_SLEEP enabled in your .config?
> 
> I'm answering that too, because I suspect that my "2.6.23-rc7-mm1 does
> not power off"-error might have the same cause.
> 
> No, I do not have CONFIG_ACPI_SLEEP set,
> because I do not have CONFIG_PM_SLEEP set,
> because I do not want SUSPEND and/or HIBERNATION.
This is not the reason. SUSPEND is controlled with CONFIG_SUSPEND and 
HIBERNATION is controlled with CONFIG_HIBERNATION.
But if you want S5 ACPI sleep state you might want to enable ACPI_SLEEP...
> 
> .config from 2.6.23-rc7-mm1 attached.
> 
> Torsten
> 

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

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Alexey Starikovskiy]

Daniel, thanks for the patch, but patch for solving your issue is already done.
And it is different from one we having here.

If you feel "patchy" today you may try to remove ACPI_SLEEP from 
drivers/acpi/sleep/Makefile in the raw of main.o

Regards,
Alex.

Daniel Ritz wrote:
> does that one help?
> 
> [ as attachment since i'm on webmail ]
> 
> ACPI: acpi_sleep_prepare() should not depent on CONFIG_SUSPEND
> Signed-off-by: Daniel Ritz <[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: [git] CFS-devel, latest code

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> hm. perhaps this fixup in kernel/sched.c:set_task_cpu():
> 
> p->se.vruntime -= old_rq->cfs.min_vruntime - new_rq->cfs.min_vruntime;
> 
> needs to become properly group-hierarchy aware?

a quick first stab like the one below does not appear to solve the 
problem.

Ingo

--->
Subject: sched: group scheduler SMP migration fix
From: Ingo Molnar <[EMAIL PROTECTED]>

group scheduler SMP migration fix.

Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 kernel/sched.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Index: linux/kernel/sched.c
===
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -1039,7 +1039,8 @@ void set_task_cpu(struct task_struct *p,
 {
int old_cpu = task_cpu(p);
struct rq *old_rq = cpu_rq(old_cpu), *new_rq = cpu_rq(new_cpu);
-   u64 clock_offset;
+   struct sched_entity *se;
+   u64 clock_offset, voffset;
 
clock_offset = old_rq->clock - new_rq->clock;
 
@@ -1051,7 +1052,11 @@ void set_task_cpu(struct task_struct *p,
if (p->se.block_start)
p->se.block_start -= clock_offset;
 #endif
-   p->se.vruntime -= old_rq->cfs.min_vruntime - new_rq->cfs.min_vruntime;
+
+   se = &p->se;
+   voffset = old_rq->cfs.min_vruntime - new_rq->cfs.min_vruntime;
+   for_each_sched_entity(se)
+   se->vruntime -= voffset;
 
__set_task_cpu(p, new_cpu);
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Celinux-dev] Re: [Announce] Linux-tiny project revival

[Geert Uytterhoeven]

On Thu, 20 Sep 2007, Joe Perches wrote:
> On Thu, 2007-09-20 at 15:38 -0500, Rob Landley wrote:
> > And so far no behavior has changed.  But now the _fun_ part is, you can add 
> > a 
> > config symbol for "what is the minimum loglevel I care about?"  Set that as 
> > a 
> > number from 0-9.  And then you can define the printk to do:
> > 
> > #define printk(level, str, ...) \
> >   do { \
> > if (level < CONFIG_PRINTK_DOICARE) \
> >   actual_printk("<" #level ">" str, __VA_ARGS__); \
> >   } while(0);
> > 
> > And viola (however you spell that, I think I'm using the stringed 
> > instrument 
> 
> > But this doesn't _completely_ eliminate 
> > printks, so you can still get the panic() calls and such.  You tweak 
> > precisly 
> > how much bloat you want, using the granularity information that's already 
> > there in the source code...
> > Opinions?
> 
> I'd rather take the opportunity to convert all the printks to
> use pr_.  That way, you can pick'n'choose if you want
> arbitrary combinations of KERN_ compiled in or not.

Or:

if ((1 << level) & CONFIG_PRINTK_MASK)
actual_printk("<" #level ">" str, __VA_ARGS__);

But it would indeed be nice to have all of pr_ (and not only pr_info()
and pr_debug()) anyway.

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:+32 (0)2 700 8453 
Fax:  +32 (0)2 700 8622 
E-mail:   [EMAIL PROTECTED] 
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe  
A division of Sony Service Centre (Europe) N.V. 
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium  
VAT BE 0413.825.160 · RPR Brussels  
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)

[Rafael J. Wysocki]

On Tuesday, 25 September 2007 11:58, Damien Wyart wrote:
> > > No, I do not have CONFIG_ACPI_SLEEP set,
> > > because I do not have CONFIG_PM_SLEEP set,
> > > because I do not want SUSPEND and/or HIBERNATION.
> 
> > Same answer from my side: I do not have CONFIG_ACPI_SLEEP for the same
> > reason (and this worked fine without them in rc7). I do not think
> > these settings should have changed between rc7 and rc8.

Well, we haven't changed much.

> Also, another test I just did: on another computer, rc8 is fine
> regarding ACPI power off, even if CONFIG_ACPI_SLEEP is not set. I can
> provide config if needed.

On the box that fails to power off, can you please test -rc8 with these two
commits reverted:

commit 5a50fe709d527f31169263e36601dd83446d5744
ACPI: suspend: consolidate handling of Sx states addendum

commit f216cc3748a3a22c2b99390fddcdafa0583791a2
ACPI: suspend: consolidate handling of Sx states.

and see if it works?

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

Re: 2.6.23-rc6-mm1: IPC: sleeping function called ...

[Jarek Poplawski]

On Mon, Sep 24, 2007 at 11:50:23AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> >safe (memory barriers): it's not atomic, so locking is needed, but
> >e.g. in do_msgsnd() kern_ipc_perm lock is used for this, while
> >freeque() calls ipc_rcu_putref() with ipc_ids mutex only.
> >
> >3. Probably similar problem is possible with msr_d.r_msg which is
> >read in do_msgrcv() under rcu_read_lock() only.
> >
> 
> In think here they have avoided refcoutning by using r_msg:
> r_msg is initialzed to -EAGAIN before releasing the msq lock. if 
> freequeue() is called it sets r_msg to EIDRM (see expunge_all(-EIDRM)).
> Setting r_msg is always done under the msq lock (expunge_all() / 
> pipelined_Sned()).
>  Since rcu_read_lock is called right after schedule, they are sure the 
> msq pointer is still valid when they re-lock it once a msg is present in 
> the receive queue.
> 
> Please tell me if I'm not clear ;-)

All clear!

Except... this r_msg is still unclear to me. Since it's read without
msq lock I doubt this first check after schedule() is of any value. A
comment: "Lockless receive, part 2" tells about some safety against a
race with pipeline_send() and expunge_all() when in wake_up_process(),
but how can we be sure this r_msg is not just to be changed and this
wake_up_process() is running while "while" check still sees
ERR_PTR(-EAGAIN) instead of NULL?

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