Re: [PATCH] KVM: Fix lockup on 32-bit intel hosts with nx disabled in the bios

[Ingo Molnar]

* Avi Kivity <[EMAIL PROTECTED]> wrote:

> Intel hosts, without long mode, and with nx support disabled in the 
> bios have an efer that is readable but not writable.  This causes a 
> lockup on switch to guest mode (even though it should exit with reason 
> 34 according to the documentation).
> 
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>

i think this is for v2.6.20. I have tested this ontop of -rc7.

Acked-by: Ingo Molnar <[EMAIL PROTECTED]>

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] VIA IRQ quirk breakage fix

[Jean Delvare]

Hi Andrew,

Le Mercredi 31 Janvier 2007 03:37, Andrew Morton a écrit :
> On Tue, 30 Jan 2007 13:25:58 +0100
>
> Jean Delvare <[EMAIL PROTECTED]> wrote:
> > So here comes the third
> > (and hopefully last) iteration of the patch:
>
> argh, it looks like I sent v2 to Linus.
>
> Here's the missing bit.  Please confirm that we want it?

Yes, we want it. Please push it to Linus ASAP. Good thing we had this rc7 
after all :)

>
>
> From: Jean Delvare <[EMAIL PROTECTED]>
>
> Add special handling for the VT82C686.
>
> Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>
> Cc: Nick Piggin <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
>  drivers/pci/quirks.c |8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff -puN drivers/pci/quirks.c~via-quirk-fix-update drivers/pci/quirks.c
> --- a/drivers/pci/quirks.c~via-quirk-fix-update
> +++ a/drivers/pci/quirks.c
> @@ -661,9 +661,11 @@ static void quirk_via_bridge(struct pci_
>   /* See what bridge we have and find the device ranges */
>   switch (dev->device) {
>   case PCI_DEVICE_ID_VIA_82C686:
> - /* 82C686 is special */
> - via_vlink_dev_lo = 7;
> - via_vlink_dev_hi = 7;
> + /* The VT82C686 is special, it attaches to PCI and can have
> +any device number. All its subdevices are functions of
> +that single device. */
> + via_vlink_dev_lo = PCI_SLOT(dev->devfn);
> + via_vlink_dev_hi = PCI_SLOT(dev->devfn);
>   break;
>   case PCI_DEVICE_ID_VIA_8237:
>   case PCI_DEVICE_ID_VIA_8237A:
> _

-- 
Jean Delvare
Suse L3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] scsi: megaraid_{mm,mbox} cmd timeout

[Matthias Urlichs]

Hi,

Patro, Sumant:
> What I see in the log is cmd timeout(s) and is not related to the patch.
> 
Ouch.

Any ideas what causes my problem? It's a regression; I tested Ubuntu
Dapper and Edgy install CDs, and it's not worked since the latter.

I can pinpoint the change that triggers the problem more closely if
necessary.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
My father was a God-fearing man, but he never missed a copy of the
New York Times, either.
-- E.B. White


signature.asc
Description: Digital signature

Re: System crash after "No irq handler for vector" linux 2.6.19

[Eric W. Biederman]

"Luigi Genoni" <[EMAIL PROTECTED]> writes:

> OK,
> willing to test any patch.

Ok. I've finally figured out what is going on.  The code is
race free but the programmer was an idiot.

In the local apic there are two relevant registers.
ISR (in service register) describing all of the
interrupts that the cpu in the process of handling.
IRR (intrerupt request register) which lists all of
the interrupts that are currently pending.

Well it happens that IRR is used to catch the case
when we are servicing an interrupt and that same interrupt
comes in again.  When that happens as soon as we are
done service the interrupt that same interrupt fires again.

We perform interrupt migration in an interrupt handler, so
we can be race free.

It turns out that if I'm performing migration (updating all
of the data structures and hardware registers) while IRR
is set the interrupt will happen in the old location immediate after
my migration work is complete.  And since the kernel is not
setup to deal with it we get an ugly error message.

Anyway now that I know what is going on I'm going to have to think
about this a little bit more to figure out how to fix this.  My hunch
is the easy fix will be simply not to migrate until I have an
interrupt instance when IRR is clear.  

Anyway with a little luck tomorrow I will be able to figure it out,
it's to bed with me now.

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] ubi: int versus size_t printk warnings

[Artem Bityutskiy]

On Wed, 2007-01-31 at 17:06 +, David Woodhouse wrote:
> > +   ubi_err("error %d while reading %Zd bytes from PEB %d:%d, "
> 
> Nak. %Zd is a gratuitous GNUism. In C, we use %zd.
> 
> Artem (dedekind) is the correct person to deal with UBI stuff. I've
> added him to Cc.

Yeah, there was a problem of mixing size_t and int in UBI and it was
mostly fixed - thanks to akpm. These are leftovers. I will look through
the code and fix things like this.

Thanks.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

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

Re: New module-init-tools pre-release (v3.3-pre6)

[Andrew Morton]

On Thu, 01 Feb 2007 01:28:59 -0500 Jon Masters <[EMAIL PROTECTED]> wrote:

> I took over upstream maintainership of the module-init-tools package 
> from Rusty at the end of last year.

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

Re: Kernel BUG at fs/aio.c:509

[Andrew Morton]

On Thu, 1 Feb 2007 09:13:51 +0300 "Ananiev, Leonid I" <[EMAIL PROTECTED]> wrote:

> While repeatedly running 'aiostress -O -o 2' test I've got in
> /var/log/messages:
> 
> BUG: warning at mm/truncate.c:398/invalidate_inode_pages2_range()
> Call Trace:
>  [] invalidate_inode_pages2_range+0x236/0x26b
>  [] ext3_direct_IO+0x16c/0x19e
>  [] ext3_get_block+0x0/0xe2
>  [] generic_file_direct_IO+0xb9/0xcf
>  [] generic_file_direct_write+0x67/0x10e
>  [] __generic_file_aio_write_nolock+0x2d6/0x3fe
>  [] __switch_to+0x26f/0x27e
>  [] thread_return+0x0/0xd8
>  [] generic_file_aio_write+0x67/0xc7
>  [] ext3_file_write+0x0/0x8f
>  [] ext3_file_write+0x16/0x8f
>  [] ext3_file_write+0x0/0x8f
>  [] aio_rw_vect_retry+0x72/0x14f
>  [] aio_run_iocb+0xe6/0x187
>  [] io_submit_one+0x296/0x2e3
>  [] sys_io_submit+0x9b/0x108
>  [] default_wake_function+0x0/0xe
>  [] system_call+0x7e/0x83

That warning got removed from -rc7.  It's harmless, in most cases.  We think.

It's a bit of a worry that aio-on-ext3 is triggering it.  That's
unexpected.

> --- [cut here ] - [please bite here ] -
> Kernel BUG at fs/aio.c:509
> invalid opcode:  [1] SMP 
> CPU 1 
> Modules linked in: firmware_class
> Pid: 11362, comm: aiostress Not tainted 2.6.19 #1

Oh.  2.6.19.  Did you try 2.6.19.latest?

> RIP: 0010:[]  []
> __aio_put_req+0x27/0x162
> RSP: 0018:81000c167e88  EFLAGS: 00010096
> RAX:  RBX: 8100184f8dc0 RCX: 1d44f000
> RDX: 000d RSI: 8100184f8dc0 RDI: 81001d44ee80
> RBP: 81001d44ee80 R08: 6db6db6db6db6db7 R09: 81000100
> R10:  R11: 0046 R12: 810037341c80
> R13: 81001d44ee80 R14: 00606998 R15: 
> FS:  2ab979b0ee90() GS:810037e896c0()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2aea207c3950 CR3: 1009c000 CR4: 06e0
> Process aiostress (pid: 11362, threadinfo 81000c166000, task
> 81003f49f5a0)
> Stack:  8100184f8dc0 81001d44ee80 810037341c80
> 80284ff6
>  8100184f8dc0 8100184f8dc0  80285409
>  00607fb0 81001d44ee80 00606998 0001
> Call Trace:
>  [] aio_put_req+0x21/0x59
> 80284ff1:   e8 cd f1 ff ff  callq  802841c3
> <__aio_put_req>
>  [] io_submit_one+0x2bd/0x2e3
>  [] sys_io_submit+0x9b/0x108
>  [] default_wake_function+0x0/0xe
>  [] system_call+0x7e/0x83
> 
> 
> Code: 0f 0b 68 76 e6 4a 80 c2 fd 01 85 c0 74 07 31 c0 e9 21 01 00 
> RIP  [] __aio_put_req+0x27/0x162
>  RSP 
> NMI Watchdog detected LOCKUP on CPU 1
> CPU 1 
> Modules linked in: firmware_class
> Pid: 11362, comm: aiostress Not tainted 2.6.19 #1
> RIP: 0010:[]  []
> _spin_lock_irq+0x8/0x10
> RSP: 0018:81000c167c10  EFLAGS: 0086
> RAX: 81003e0f0001 RBX: 81001d44ee80 RCX: 2ab979b0ef40
> RDX:  RSI: 0246 RDI: 81001d44eeb8
> RBP: 81001d44ee80 R08: 0286 R09: 0018
> R10: 0286 R11: 0046 R12: 0001
> R13: 000b R14: 804a5904 R15: 
> FS:  () GS:810037e896c0()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 2aea207c3950 CR3: 1009c000 CR4: 06e0
> Process aiostress (pid: 11362, threadinfo 81000c166000, task
> 81003f49f5a0)
> Stack:  80284050 0286 802441cc
> 0018
> 8047cebe 0246 81001d44ee80 
> 80285880 81003e0f12c0 81003e0f12c0 81003f49f5a0
> Call Trace:
> [] aio_cancel_all+0x12/0x87
> 0x12:   e8 9d 93 1f 00  callq  8047d3ed
> <_spin_lock_irq>
> [] lock_hrtimer_base+0x26/0x4c
> [] __down_read+0x12/0x9a
> [] exit_aio+0x2e/0x8c
> [] mmput+0x19/0x98
> [] do_exit+0x1f7/0x825
> [] vgacon_set_cursor_size+0x36/0xd1
> [] kernel_math_error+0x0/0x90
> [] do_invalid_op+0xad/0xb7
> [] __aio_put_req+0x27/0x162
> [] __generic_file_aio_write_nolock+0x2d6/0x3fe
> [] __switch_to+0x26f/0x27e
> [] error_exit+0x0/0x84
> [] __aio_put_req+0x27/0x162
> [] aio_put_req+0x21/0x59
> [] io_submit_one+0x2bd/0x2e3
> [] sys_io_submit+0x9b/0x108
> [] default_wake_function+0x0/0xe
> [] system_call+0x7e/0x83
> Code: 83 3f 00 7e f9 eb f2 c3 53 48 89 fb e8 06 7b db ff f0 ff 0b 
> <1>Fixing recursive fault but reboot is needed!
> 
> ===
> 
> It stable happens after 2-5 aiosterss runs on 2.6.20-rc6 as well as on
> 2.6.19 in 4 processor Xeon.
> 
> fs/aio.c:509 line is  BUG_ON(req->ki_users < 0);
> It may be an effect of return 1 from invalidate_inode_pages2_range() one
> second earlier as you can see in log.
> To investigate a root cause of ret=0 in invalidate_inode_pages2_range()
> I have added printk() calls.
> As a result I can say that

Re: 2.6.20-rc6-mm3

[Andrew Morton]

On Thu, 1 Feb 2007 17:20:18 +1100 David Chinner <[EMAIL PROTECTED]> wrote:

> What are the new unplugging rules introduced by the git-block
> patch?

Pretty simple: you read the largely-useless changelog then call the bravely
uncommented blk_plug_current() when you're about to submit some IO and you
call the audaciously uncommented blk_unplug_current() when you've finished
and you're ready to let it rip.

But usually none of that is necessary, because io_schedule() does all the
work for you.

err, this might help.

--- a/fs/xfs/linux-2.6/xfs_buf.c~git-block-xfs-fix
+++ a/fs/xfs/linux-2.6/xfs_buf.c
@@ -979,7 +979,7 @@ xfs_buf_wait_unpin(
set_current_state(TASK_UNINTERRUPTIBLE);
if (atomic_read(>b_pin_count) == 0)
break;
-   schedule();
+   io_schedule();
}
remove_wait_queue(>b_waiters, );
set_current_state(TASK_RUNNING);
_

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

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

[Evgeniy Polyakov]

On Wed, Jan 31, 2007 at 11:28:07PM -0500, Lee Revell ([EMAIL PROTECTED]) wrote:
> On 1/29/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >1. Scheduling fairness.
> >Since kernel does not know about multiple threads behind given process,
> >it can not add it appropriate number of timeslices for execution.
> >Can be solved either by more tight collaboarion of the userspace and
> >kernelspace schedulers or simply by increasing process' nice value.
> 
> nice value is only meaningful for SCHED_OTHER.  How will you handle a
> multithreaded realtime application that uses SCHED_OTHER as well as
> SCHED_FIFO threads?

Threads created inside one process obviously can not compete with RT
threads created by other process. Instead process, which threads have RT
priority itself should change its priority to RT to compete with other
RT process. (By RT I mean any cases except SCHED_OTHER which is
default).

> Lee

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

Mach-O loader

[Trent Waddington]

Anyone know if a loader for Mach-O binaries for Linux has been written?

Thanks,

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

Re: 2.6.20-rc6-mm[2-3] ACPI issues

[Len Brown]

On Wednesday 31 January 2007 15:25, Bob Picco wrote:
> Hi Len,
> 
> On 2.6.20-rc6-mm2 my rx2600 wouldn't boot unless I reverted all changes
> to drivers/acpi/tables.c.

2.6.20-rc6-mm2 git-acpi.patch contained only the acpi_table_parse()
fix for bugzilla-7465.  The version of the patch that made -mm2 had a flaw
where if the HPET were not connfigured, it would BUG_ON() due to a NULL
handler it didn't expect -- and this generally happened before VGA was enabled.
That bug got fixed, and also bugzilla-7465 is not in -mm3 -- which explains
why it went away.

> Nearly all major early boot detected ACPI tables 
> weren't discovered.

That part I can't explain.

> I never had time to resolve because 2.6.20-rc6-mm3 
> showed up. The -mm2 problem appears corrected but the machine now crashes in
> acpi_init for -mm3. 2.6.20-rc6 and 2.6.20-rc6-mm3 boot logs are included
> at end of email.
> 
> For 2.6.20-rc6-mm3 the HP internal simualtor for a NUMA machine is
> getting a preposterous pxm value and subsequently MCAs in pxm_to_node
> because of large pxm. It seems like table parsing is being done
> incorrectly.
> 
> Nope this is the issue:
> 
> Index: linux-2.6.20-rc6-mm3/include/acpi/actbl1.h
> ===
> --- linux-2.6.20-rc6-mm3.orig/include/acpi/actbl1.h   2007-01-30 
> 09:27:44.0 -0500
> +++ linux-2.6.20-rc6-mm3/include/acpi/actbl1.h2007-01-31 
> 14:41:32.0 -0500
> @@ -654,8 +654,8 @@ struct acpi_srat_cpu_affinity {
>  
>  struct acpi_srat_mem_affinity {
>   struct acpi_subtable_header header;
> - u32 proximity_domain;
> - u16 reserved;   /* Reserved, must be zero */
> + u8  proximity_domain;
> + u8  reserved[5];/* Reserved, must be zero */
>   u64 base_address;
>   u64 length;
>   u32 memory_type;/* See acpi_address_range_id */
> Index: linux-2.6.20-rc6-mm3/arch/ia64/kernel/acpi.c
> ===
> --- linux-2.6.20-rc6-mm3.orig/arch/ia64/kernel/acpi.c 2007-01-30 
> 13:55:08.0 -0500
> +++ linux-2.6.20-rc6-mm3/arch/ia64/kernel/acpi.c  2007-01-31 
> 14:49:26.0 -0500
> @@ -423,7 +423,7 @@ int get_memory_proximity_domain(struct a
>  
>   pxm = ma->proximity_domain;
>   if (ia64_platform_is("sn2"))
> - pxm += ma->reserved << 8;
> + pxm += ma->reserved[0] << 8;
>  
>   return pxm;
>  }
> 
> I doubt you'll want to apply this patch. It appears HP firmware has some
> of the reserved field not initialized to zero. This results in the huge
> pxm. Was the pxm size expanded with a recent ACPI spec revision? 

Yep.
The original code was programmed to the Microsoft SRAT spec -- which
identifies itself as version 1.  The new code is talking to ACPI 3.0 SRAT spec
which identifies itself as version 2.

In the SRAT memory affinity structure, the difference is that the 
proximity_domain
is now 4-bytes instead of 1.

We need to be checking for the SRAT revision and handling both revisions.

Might be safer to build w/o NUMA until we get the SRAT fixed.

> Well with this patch I can pursue the acpi_init panic on simulator.
> 
> rx2600 (2 CPU MP) and NUMA simulator (1 node and 4 cpus)  boot successfully
> on 2.6.20-rc6.
> 
> bob
> 
> 
> Linux version 2.6.20-rc6 ([EMAIL PROTECTED]) (gcc version 3.4.1) #1 SMP Mon 
> Jan 29 14:40:17 EST 2007
> EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 
> HCDP=0x3fb2c000
> PCDP: v0 at 0x3fb2c000
> Early serial console at MMIO 0xf803 (options '9600n8')
> ACPI: RSDP (v002 HP) @ 0x3fb2e000
> ACPI: XSDT (v001 HP   rx2600 0x HP 0x) @ 
> 0x3fb2e02c
> ACPI: FADT (v003 HP   rx2600 0x HP 0x) @ 
> 0x3fb369e0
> ACPI: SPCR (v001 HP   rx2600 0x HP 0x) @ 
> 0x3fb36b18
> ACPI: DBGP (v001 HP   rx2600 0x HP 0x) @ 
> 0x3fb36b68
> ACPI: MADT (v001 HP   rx2600 0x HP 0x) @ 
> 0x3fb36c28
> ACPI: SPMI (v004 HP   rx2600 0x HP 0x) @ 
> 0x3fb36ba0
> ACPI: CPEP (v001 HP   rx2600 0x HP 0x) @ 
> 0x3fb36bf0
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb33870
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb33a50
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb33da0
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb347c0
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb351e0
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb35c00
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb36620
> ACPI: SSDT (v001 HP   rx2600 0x0006 INTL 0x02012044) @ 
> 0x3fb36800
> ACPI: SSDT (v001 HP 

Re: Linux 2.6.20-rc7

[H. Peter Anvin]

Alexander E. Patrakov wrote:


What's the proper way to make sure that the fix, when it appears, ends 
up in my inbox?




Say "please", and give prompt feedback on any test patches that we send you.

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

New module-init-tools pre-release (v3.3-pre6)

[Jon Masters]

Yo,

I took over upstream maintainership of the module-init-tools package 
from Rusty at the end of last year. At this point, there's a public 
wiki, new pre-release, bugzilla and all that jazz up and running:


http://www.kerneltools.org/ has links to the latest release.

There's a mailing list, etc. and most of us involved in m-i-t 
development seem to have already noticed, but just in case, I'm sending 
this reminder out to LKML now. I don't plan on shouting about every 
minor release from this point on - unless it's critically serious.


If you've got any patches (preferably git trees), let me know.

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

Re: 2.6.20-rc7 mtrr handling

[H. Peter Anvin]

Sebastian Kemper wrote:

On Thursday 01 February 2007 07:13, you wrote:

Sebastian Kemper wrote:

But now /proc/mtrr shows 256MB of video ram, same as lspci, whereas
the real amount of video ram (as properly detected by X) is only
128MB.

The size of the aperture doesn't have to match the actual amount of
memory.  For many cards it doesn't.

-hpa


Hello Peter,

sorry, I don't understand. Are you talking about the AGP Aperture size 
that I can set in my BIOS or about the actual video ram on the graphics 
card. Because that's the one that the mtrr sets to its double size.


Neither.  I'm talking about the window in the address space, as shown in 
/proc/pci.


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

Re: Linux 2.6.20-rc7

[Pekka Enberg]

On 1/31/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:

When do_tune_cpucache() is called at bootup, I'm not sure how safe it is
to do the kzalloc() thing.


The kzalloc thing is safe as we have already successfully boostrapped
all kmalloc caches at that point. The per-CPU caches that are replaced
by do_tune_cpucache() point to boostrap-time array caches there (see
use of struct arraycache_init in setup_cpu_cache).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.20-rc7

[Alexander E. Patrakov]

H. Peter Anvin wrote:

Linus Torvalds wrote:


On Wed, 31 Jan 2007, H. Peter Anvin wrote:
It would be interesting to know what the inode numbers are in the 
image; also,
what is the exact behaviour -- do you end up with a missing link, or 
do both

entries end up getting hard-linked to an empty file?


Judging by the

request_module: runaway loop modprobe binfmt-

one or more of the hardlinked binaries (modprobe being one, but not 
necessarily the one that initially triggers hits) will read all zeroes-


Or at least bytes at offsets 2 and 3 will read as zero, causing it to 
not be recognized as a proper binary, causing that "binfmt-" thing.




Or perhaps not read at all, which would explain the problem.

cpio represents a hard link as who headers with the same type and the 
same file (inode) number and a link count that is > 1.  Only the first 
one contains data; the subsequent ones have length 0.  It's fairly easy 
for a bug in the decoder to truncate the file upon encountering the 
second header, since this is somewhat of a special case (it would have 
been better if the cpio format distinguished "hard link" explicitly, as 
tar does.)


I will look into this as soon as I can, but as I'm currently in the 
middle of job hunting it might take until the weekend.


What's the proper way to make sure that the fix, when it appears, ends up in 
my inbox?


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

Re: 2.6.20-rc7 mtrr handling

[Sebastian Kemper]

On Thursday 01 February 2007 07:13, you wrote:
> Sebastian Kemper wrote:
> > But now /proc/mtrr shows 256MB of video ram, same as lspci, whereas
> > the real amount of video ram (as properly detected by X) is only
> > 128MB.
>
> The size of the aperture doesn't have to match the actual amount of
> memory.  For many cards it doesn't.
>
>   -hpa

Hello Peter,

sorry, I don't understand. Are you talking about the AGP Aperture size 
that I can set in my BIOS or about the actual video ram on the graphics 
card. Because that's the one that the mtrr sets to its double size.

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

Re: 2.6.20-rc6-mm3

[David Chinner]

On Wed, Jan 31, 2007 at 04:36:38PM -0800, Andrew Morton wrote:
> On Wed, 31 Jan 2007 16:27:16 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 31 Jan 2007, Andrew Morton wrote:
> > 
> > > ow.  Please don't make me drop git-block-and-lots-of-other-things again.
> > > Was 2.6.20-rc6-mm2 OK?  It didn't have git-block.
> > 
> > Yes, 2.6.20-rc6-mm2 was okay. Sorry.
> 
> OK, thanks.
> 
> Actually, we might not have lost an IO: it could be that we're simply
> missing an unplug.

Could be - I can't be certain but I think we've got one thread
waiting for a buffer to be unpinned before it is written, and
the other thread waiting for log I/O to complete. The first thread
won't unplug the device, and the log I/o is async so it won't either.

What are the new unplugging rules introduced by the git-block
patch? How do they differ from the existing rules?

Cheers,

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

Kernel BUG at fs/aio.c:509

[Ananiev, Leonid I]

While repeatedly running 'aiostress -O -o 2' test I've got in
/var/log/messages:

BUG: warning at mm/truncate.c:398/invalidate_inode_pages2_range()
Call Trace:
 [] invalidate_inode_pages2_range+0x236/0x26b
 [] ext3_direct_IO+0x16c/0x19e
 [] ext3_get_block+0x0/0xe2
 [] generic_file_direct_IO+0xb9/0xcf
 [] generic_file_direct_write+0x67/0x10e
 [] __generic_file_aio_write_nolock+0x2d6/0x3fe
 [] __switch_to+0x26f/0x27e
 [] thread_return+0x0/0xd8
 [] generic_file_aio_write+0x67/0xc7
 [] ext3_file_write+0x0/0x8f
 [] ext3_file_write+0x16/0x8f
 [] ext3_file_write+0x0/0x8f
 [] aio_rw_vect_retry+0x72/0x14f
 [] aio_run_iocb+0xe6/0x187
 [] io_submit_one+0x296/0x2e3
 [] sys_io_submit+0x9b/0x108
 [] default_wake_function+0x0/0xe
 [] system_call+0x7e/0x83

--- [cut here ] - [please bite here ] -
Kernel BUG at fs/aio.c:509
invalid opcode:  [1] SMP 
CPU 1 
Modules linked in: firmware_class
Pid: 11362, comm: aiostress Not tainted 2.6.19 #1
RIP: 0010:[]  []
__aio_put_req+0x27/0x162
RSP: 0018:81000c167e88  EFLAGS: 00010096
RAX:  RBX: 8100184f8dc0 RCX: 1d44f000
RDX: 000d RSI: 8100184f8dc0 RDI: 81001d44ee80
RBP: 81001d44ee80 R08: 6db6db6db6db6db7 R09: 81000100
R10:  R11: 0046 R12: 810037341c80
R13: 81001d44ee80 R14: 00606998 R15: 
FS:  2ab979b0ee90() GS:810037e896c0()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2aea207c3950 CR3: 1009c000 CR4: 06e0
Process aiostress (pid: 11362, threadinfo 81000c166000, task
81003f49f5a0)
Stack:  8100184f8dc0 81001d44ee80 810037341c80
80284ff6
 8100184f8dc0 8100184f8dc0  80285409
 00607fb0 81001d44ee80 00606998 0001
Call Trace:
 [] aio_put_req+0x21/0x59
80284ff1:   e8 cd f1 ff ff  callq  802841c3
<__aio_put_req>
 [] io_submit_one+0x2bd/0x2e3
 [] sys_io_submit+0x9b/0x108
 [] default_wake_function+0x0/0xe
 [] system_call+0x7e/0x83


Code: 0f 0b 68 76 e6 4a 80 c2 fd 01 85 c0 74 07 31 c0 e9 21 01 00 
RIP  [] __aio_put_req+0x27/0x162
 RSP 
NMI Watchdog detected LOCKUP on CPU 1
CPU 1 
Modules linked in: firmware_class
Pid: 11362, comm: aiostress Not tainted 2.6.19 #1
RIP: 0010:[]  []
_spin_lock_irq+0x8/0x10
RSP: 0018:81000c167c10  EFLAGS: 0086
RAX: 81003e0f0001 RBX: 81001d44ee80 RCX: 2ab979b0ef40
RDX:  RSI: 0246 RDI: 81001d44eeb8
RBP: 81001d44ee80 R08: 0286 R09: 0018
R10: 0286 R11: 0046 R12: 0001
R13: 000b R14: 804a5904 R15: 
FS:  () GS:810037e896c0()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2aea207c3950 CR3: 1009c000 CR4: 06e0
Process aiostress (pid: 11362, threadinfo 81000c166000, task
81003f49f5a0)
Stack:  80284050 0286 802441cc
0018
8047cebe 0246 81001d44ee80 
80285880 81003e0f12c0 81003e0f12c0 81003f49f5a0
Call Trace:
[] aio_cancel_all+0x12/0x87
0x12:   e8 9d 93 1f 00  callq  8047d3ed
<_spin_lock_irq>
[] lock_hrtimer_base+0x26/0x4c
[] __down_read+0x12/0x9a
[] exit_aio+0x2e/0x8c
[] mmput+0x19/0x98
[] do_exit+0x1f7/0x825
[] vgacon_set_cursor_size+0x36/0xd1
[] kernel_math_error+0x0/0x90
[] do_invalid_op+0xad/0xb7
[] __aio_put_req+0x27/0x162
[] __generic_file_aio_write_nolock+0x2d6/0x3fe
[] __switch_to+0x26f/0x27e
[] error_exit+0x0/0x84
[] __aio_put_req+0x27/0x162
[] aio_put_req+0x21/0x59
[] io_submit_one+0x2bd/0x2e3
[] sys_io_submit+0x9b/0x108
[] default_wake_function+0x0/0xe
[] system_call+0x7e/0x83
Code: 83 3f 00 7e f9 eb f2 c3 53 48 89 fb e8 06 7b db ff f0 ff 0b 
<1>Fixing recursive fault but reboot is needed!

===

It stable happens after 2-5 aiosterss runs on 2.6.20-rc6 as well as on
2.6.19 in 4 processor Xeon.

fs/aio.c:509 line is  BUG_ON(req->ki_users < 0);
It may be an effect of return 1 from invalidate_inode_pages2_range() one
second earlier as you can see in log.
To investigate a root cause of ret=0 in invalidate_inode_pages2_range()
I have added printk() calls.
As a result I can say that
 invalidate_inode_pages2_range() reports BUG: warning at
mm/truncate.c:398  occurs becouse of
 invalidate_complete_page2()returns 0; it
returns 0 because of
 try_to_release_page()returns 0; it
returns 0 because of
 ext3_releasepage()returns 0; it
returns 0 because of
 journal_try_to_free_buffers() returns 0; it returns
0 because of
 try_to_free_buffers() 

Re: 2.6.20-rc7 mtrr handling

[H. Peter Anvin]

Sebastian Kemper wrote:


But now /proc/mtrr shows 256MB of video ram, same as lspci, whereas the 
real amount of video ram (as properly detected by X) is only 128MB.




The size of the aperture doesn't have to match the actual amount of 
memory.  For many cards it doesn't.


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

Re: Linux 2.6.20-rc7

[H. Peter Anvin]

Linus Torvalds wrote:


On Wed, 31 Jan 2007, H. Peter Anvin wrote:

It would be interesting to know what the inode numbers are in the image; also,
what is the exact behaviour -- do you end up with a missing link, or do both
entries end up getting hard-linked to an empty file?


Judging by the

request_module: runaway loop modprobe binfmt-

one or more of the hardlinked binaries (modprobe being one, but not 
necessarily the one that initially triggers hits) will read all zeroes-


Or at least bytes at offsets 2 and 3 will read as zero, causing it to not 
be recognized as a proper binary, causing that "binfmt-" thing.




Or perhaps not read at all, which would explain the problem.

cpio represents a hard link as who headers with the same type and the 
same file (inode) number and a link count that is > 1.  Only the first 
one contains data; the subsequent ones have length 0.  It's fairly easy 
for a bug in the decoder to truncate the file upon encountering the 
second header, since this is somewhat of a special case (it would have 
been better if the cpio format distinguished "hard link" explicitly, as 
tar does.)


I will look into this as soon as I can, but as I'm currently in the 
middle of job hunting it might take until the weekend.


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

[PATCH 1/2] pata_platform: fix devres conversion

[Tejun Heo]

devres updates for pata_platform were dropped while merging devres
patches due to merge conflict.  This is the updated version.

Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
 drivers/ata/pata_platform.c |   31 +++
 1 file changed, 7 insertions(+), 24 deletions(-)

Index: work/drivers/ata/pata_platform.c
===
--- work.orig/drivers/ata/pata_platform.c
+++ work/drivers/ata/pata_platform.c
@@ -47,23 +47,6 @@ static int pata_platform_set_mode(struct
return 0;
 }
 
-static void pata_platform_host_stop(struct ata_host *host)
-{
-   int i;
-
-   /*
-* Unmap the bases for MMIO
-*/
-   for (i = 0; i < host->n_ports; i++) {
-   struct ata_port *ap = host->ports[i];
-
-   if (ap->flags & ATA_FLAG_MMIO) {
-   iounmap((void __iomem *)ap->ioaddr.ctl_addr);
-   iounmap((void __iomem *)ap->ioaddr.cmd_addr);
-   }
-   }
-}
-
 static struct scsi_host_template pata_platform_sht = {
.module = THIS_MODULE,
.name   = DRV_NAME,
@@ -106,8 +89,6 @@ static struct ata_port_operations pata_p
.irq_clear  = ata_bmdma_irq_clear,
 
.port_start = ata_port_start,
-   .port_stop  = ata_port_stop,
-   .host_stop  = pata_platform_host_stop
 };
 
 static void pata_platform_setup_port(struct ata_ioports *ioaddr,
@@ -209,15 +190,17 @@ static int __devinit pata_platform_probe
if (mmio) {
ae.port_flags |= ATA_FLAG_MMIO;
 
-   ae.port[0].cmd_addr = (unsigned long)ioremap(io_res->start,
-   io_res->end - io_res->start + 1);
+   ae.port[0].cmd_addr = (unsigned long)
+   devm_ioremap(>dev, io_res->start,
+io_res->end - io_res->start + 1);
if (unlikely(!ae.port[0].cmd_addr)) {
dev_err(>dev, "failed to remap IO base\n");
return -ENXIO;
}
 
-   ae.port[0].ctl_addr = (unsigned long)ioremap(ctl_res->start,
-   ctl_res->end - ctl_res->start + 1);
+   ae.port[0].ctl_addr = (unsigned long)
+   devm_ioremap(>dev, ctl_res->start,
+ctl_res->end - ctl_res->start + 1);
if (unlikely(!ae.port[0].ctl_addr)) {
dev_err(>dev, "failed to remap CTL base\n");
ret = -ENXIO;
@@ -261,7 +244,7 @@ static int __devexit pata_platform_remov
struct device *dev = >dev;
struct ata_host *host = dev_get_drvdata(dev);
 
-   ata_host_remove(host);
+   ata_host_detach(host);
dev_set_drvdata(dev, NULL);
 
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.20-rc7

[Linus Torvalds]

On Wed, 31 Jan 2007, H. Peter Anvin wrote:
> 
> It would be interesting to know what the inode numbers are in the image; also,
> what is the exact behaviour -- do you end up with a missing link, or do both
> entries end up getting hard-linked to an empty file?

Judging by the

request_module: runaway loop modprobe binfmt-

one or more of the hardlinked binaries (modprobe being one, but not 
necessarily the one that initially triggers hits) will read all zeroes-

Or at least bytes at offsets 2 and 3 will read as zero, causing it to not 
be recognized as a proper binary, causing that "binfmt-" thing.

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

Re: System crash after "No irq handler for vector" linux 2.6.19

[Eric W. Biederman]

"Luigi Genoni" <[EMAIL PROTECTED]> writes:

> OK,
> willing to test any patch.

Sure.  After I get things working on this end I will copy you,
on any fixes so you can confirm they work for you.

I am still root causing this but I have found a small fix that should
keep the system from going down when this problem occurs.

If you could confirm that it keeps your system from going down I'd
appreciate it.

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/

[PATCH] x86_64: Survive having no irq mapping for a vector

[Eric W. Biederman]

Occasionally the kernel has bugs that result in no irq being found for
a given cpu vector.  If we acknowledge the irq the system has a good
chance of continuing even though we dropped an irq message.  If we
continue to simply print a message and not acknowledge the irq the
system is likely to become non-responsive shortly there after. 

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 arch/x86_64/kernel/irq.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 0c06af6..648055a 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -120,9 +120,14 @@ asmlinkage unsigned int do_IRQ(struct pt_regs *regs)
 
if (likely(irq < NR_IRQS))
generic_handle_irq(irq);
-   else if (printk_ratelimit())
-   printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n",
-   __func__, smp_processor_id(), vector);
+   else {
+   if (!disable_apic)
+   ack_APIC_irq();
+
+   if (printk_ratelimit())
+   printk(KERN_EMERG "%s: %d.%d No irq handler for 
vector\n",
+   __func__, smp_processor_id(), vector);
+   }
 
irq_exit();
 
-- 
1.4.4.1.g278f

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 01:37:58PM -0500, Bob Copeland wrote:
> >Putting the "codingstyle" control aside, often it's because things look
> >too hackish.
> 
> Also sometimes the authors know it's hackish, or just don't expect it
> to be generally useful to the world.  I happen to own an out-of-tree
> filesystem which I have little desire to have reviewed for mainline:
> only a dozen people use it at most, and I know it would get pinged
> mercilessly for using buffer heads and general insanity if it ever
> made it past "use FUSE instead" (which would admittedly be a perfectly
> fine response).  It works though, so I keep it up to date with the VFS
> changes.
> 
> I do have some interest in working on various device drivers, though.
> Greg, assuming this somehow kicks off some avalanche of specs, will
> there be a ML for hooking up driver writers with specs and willing
> users?

I don't really want to create yet-another-mailing list for something
like this.

So far I've just been taking down people's names and email addresses and
a short description of what types of drivers they would like to work on.
We already have a nice list of people willing to help out.

Anyone else is welcome to email me if they wish to join in.

thanks,

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 10:15:20PM +0100, Nicolas Mailhot wrote:
> Le mercredi 31 janvier 2007 ?? 12:12 -0800, Greg KH a ??crit :
> > On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
> 
> [Reordering for the sake of argument]
> 
> > > There are many out-of-tree drivers (ivtv, lirc, various webcam 
> > > drivers,
> > > enhanced USB keyboard handlers...) with merging not planified or taking
> > > ages.
> > 
> > See my above comment about lirc.  As for the others, everyone knows
> > where we are at, and what the critera is for getting their code into the
> > tree, so it's not like we are hiding anywhere :)
> 
> The perception of many out-of-tree projects is "if I try to get in-tree
> I'll be submitted to vicious review, and I'll have to fix the code my
> myself, and that's assuming someone bothers to review it at all". What
> you've just wrote is no different:
> 
> > we will gladly take any
> > currently out-of-the-tree drivers into mainline, as long as they follow
> > our rules and coding style issues, please do so.
> 
> In other words, getting an out-of-tree driver in is a major unrewarding
> work commitment for its author (especially considering that if he was
> familiar with good kernel coding, chances are he'd have worked in-tree
> from the start, with an experimental driver)
> 
> Contrast it with "give us a partial NDAed spec and we'll write a driver
> from scratch for you".

Sometimes doing a driver from scratch is much less effort than trying to
reengineer a badly designed and written driver to get it into the kernel
tree.

Also, almost all out-of-tree driver authors know what they need to do to
get the code into the kernel tree.

Again, I've offered my services to many such groups in the past.  A lot
of them do get into the tree, and I'll continue to offer my services to
do this.

But again, that's not the main point of this announcement sorry.

> You're asking way more of people that have a lot less resources than
> hardware manufacturers. Many of those projects did try to get in-tree at
> least once before giving up.

Persistance is everything :)

> Meanwhile you're asking for specs of hardware no Linux user has, because
> no form of Linux support ever existed. This is a strange use of
> resources.

You are free to use your resources however you wish, and mine how I
wish.  Would you want it to be any other way?  :)

thanks,

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 08:41:03PM +0300, Sergei Organov wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> [...]
> >> And there are plenty of documented devices that no one cares enough
> >> about to submit a driver for.
> >
> > Any specific examples?  I have a long list of people who wish to write
> > new drivers but just don't know which hardware is not yet supported.
> 
> Maybe not entirely a new driver, as there already exist out-of-kernel
> vendor GPL driver, but if somebody is willing to resolve the issue
> described here:
> 
> 
> 
> please contact me, and I'll be willing to help in testing as I have the
> hardware.

Do you have a pointer to the driver source anywhere?

I suggest just posting it as a patch to the tree as documented in
Documentation/SubmittingPatches and seeing how that goes.

thanks,

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

Re: Linux 2.6.20-rc7

[H. Peter Anvin]

Linus Torvalds wrote:


On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
I think i found the cause of the problem, initramfs can't handle hardlinks 
anymore (which works with 2.6.18), copying same /sbin/busybox binary with 
different names into initramfs (which ends ups with 50 MB image) or using 
symbolic ones instead of hards seems works.


Ok, it would still be interesting to hear what triggered this.



It would be interesting to know what the inode numbers are in the image; 
also, what is the exact behaviour -- do you end up with a missing link, 
or do both entries end up getting hard-linked to an empty file?


-hpa

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

Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 LinuxKernel Summit

[Dirk Hohndel]

On 1/31/07 3:30 PM, "H. Peter Anvin" <[EMAIL PROTECTED]> wrote:

> Gerrit Huizenga wrote:
>> Don't confused KS with a conference;
>> it is a workshop for a very, very large, very very active project.
> 
> ... and *growing*, which is the real issue I think.
> 
> Something that might make sense for KS is to have multiple sessions
> (perhaps replacing some or all of the "mini-summits" that have cropped
> up) combined with some bigger, overall sessions.  At least that way
> there would be more cross-pollination between the various groups than if
> we eventually end up meeting everywhere.
> 
> That's of course only practical if KS is separated from any other
> conference (like OLS.)

I have discussed this idea with a few people in the past. One could organize
a set of interlocking / overlapping mini summits and end with a joint day
for everyone. This would almost certainly create some idle time for almost
every attendee - but obviously that can be filled by a hack fest or
something.

I don't think this could be organized for September (actually, I don't know
how firm the contracts with the facilities are at this point), but certainly
something we could plan for next year. One nice side-effect would be to
allow for an overall larger group - you could have 30-40 people per "track"
and maybe 100-120 total. Yes, this makes the conversation on the last day
harder, but it would still stay productive and interactive for the most
part.

/D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.19.2 oops after resume from ram (corruption?)

[Nigel Cunningham]

Hi.

On Thu, 2007-02-01 at 06:30 +0100, Mike Galbraith wrote:
> Rebuilding this particular kernel with slab debugging would probably be
> a waste of time since stable kernels get very little runtime here, but
> I'll re-add it to my config for test kernels just in case a survivable
> event should happen.

Thanks, Mike.

Regards,

Nigel

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

Re: 2.6.19.2 oops after resume from ram (corruption?)

[Mike Galbraith]

On Thu, 2007-02-01 at 08:42 +1100, Nigel Cunningham wrote:
> Hi.
> 
> On Wed, 2007-01-31 at 11:56 +0100, Mike Galbraith wrote:
> > Greetings,
> > 
> > I received the below upon first poke of firefox icon after a resume.  
> 
> Are you able to reproduce it reliably? Failing that, could you try
> enabling some the kernel configuration options that help with debugging
> memory corruption (slab corruption checking in particular will probably
> be the most useful thing here).

No, it's a never before seen event.  That said, I have had a couple of
dead box after resume events with other kernels in the last few months,
so I may have had corruption of a more deadly variety.  Unfortunately,
when I'm resuming, my serial console box is almost guaranteed to be off.

Rebuilding this particular kernel with slab debugging would probably be
a waste of time since stable kernels get very little runtime here, but
I'll re-add it to my config for test kernels just in case a survivable
event should happen.

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

[PATCH] MTD: add missing kernel-doc item

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

Fix kernel-doc warning in mtd/nand.h.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 include/linux/mtd/nand.h |1 +
 1 file changed, 1 insertion(+)

--- linux-2620-rc7.orig/include/linux/mtd/nand.h
+++ linux-2620-rc7/include/linux/mtd/nand.h
@@ -343,6 +343,7 @@ struct nand_buffers {
  * @options:   [BOARDSPECIFIC] various chip options. They can partly 
be set to inform nand_scan about
  * special functionality. See the defines for further 
explanation
  * @badblockpos:   [INTERN] position of the bad block marker in the oob 
area
+ * @cellinfo:  MLC/multichip data (newer devices have more ID bytes)
  * @numchips:  [INTERN] number of physical chips
  * @chipsize:  [INTERN] the size of one chip for multichip arrays
  * @pagemask:  [INTERN] page number mask = number of (pages / chip) - 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/6] MSI portability cleanups

[Greg KH]

On Mon, Jan 29, 2007 at 09:09:14AM +1100, Benjamin Herrenschmidt wrote:
> 
> If we followed that "only do incrementental changes" rule all the time,
> imagine in what state would be our USB stack today since we couldn't
> have dropped in Linus replacement one ...

Bad example, that is not what happened at all.  There was not an
in-kernel USB stack when Linus wrote his.  Inaky had his
all-singing-all-dancing stack outside of the tree, and no one was really
helping out with it.

Only when Linus added his code to mainline did we all jump on it and
_incrementally_ improve it to what we have today.

So, in a way, you just proved that we need to do this in an incremental
fashion, which is what I was also saying all along :)

thanks,

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

Re: [RFC/PATCH] revokeat/frevoke system calls V5

[Serge E. Hallyn]

Quoting Pekka J Enberg ([EMAIL PROTECTED]):
> From: Pekka Enberg <[EMAIL PROTECTED]>
> 
> The revokeat(2) and frevoke(2) system calls invalidate open file
> descriptors and shared mappings of an inode. After an successful
> revocation, operations on file descriptors fail with the EBADF or
> ENXIO error code for regular and device files,
> respectively. Attempting to read from or write to a revoked mapping
> causes SIGBUS.
> 
> The actual operation is done in two passes:
> 
>  1. Revoke all file descriptors that point to the given inode. We do
> this under tasklist_lock so that after this pass, we don't need
> to worry about racing with close(2) or dup(2).
> 
>  2. Take down shared memory mappings of each revoked file and close
> the file pointer.
> 
> The file descriptors are kept until the owning task does close(2) and
> memory mapping ranges preserved until the owning task does munmap(2).

With the attached patch, this passes all your revoke tests on s390,
as well as ltp runalltests.sh.

thanks,
-serge

From: "Serge E. Hallyn" <[EMAIL PROTECTED]>
Subject: [PATCH] revoke: do s390 syscalls

revoke: do s390 syscalls

Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
(cherry picked from 9962b52d7bd7b70b99e7515d30b8217b0de491b3 commit)

---

 arch/s390/kernel/compat_wrapper.S |   11 +++
 arch/s390/kernel/syscalls.S   |2 ++
 include/asm-s390/unistd.h |4 +++-
 3 files changed, 16 insertions(+), 1 deletions(-)

3f0afa7b9a6b8c9ec930bdef73601f7260c79f47
diff --git a/arch/s390/kernel/compat_wrapper.S 
b/arch/s390/kernel/compat_wrapper.S
index 71e54ef..b5c2bfa 100644
--- a/arch/s390/kernel/compat_wrapper.S
+++ b/arch/s390/kernel/compat_wrapper.S
@@ -1665,3 +1665,14 @@ sys_getcpu_wrapper:
llgtr   %r3,%r3 # unsigned *
llgtr   %r4,%r4 # struct getcpu_cache *
jg  sys_getcpu
+
+   .globl sys_revokeat_wrapper
+sys_revokeat_wrapper:
+   lgfr%r2,%r2 # int
+   llgtr   %r3,%r3 # const char *
+   jg  sys_revokeat
+
+   .globl sys_frevoke_wrapper
+sys_frevoke_wrapper:
+   llgfr   %r2,%r2 # unsigned int
+   jg  sys_frevoke
diff --git a/arch/s390/kernel/syscalls.S b/arch/s390/kernel/syscalls.S
index a4ceae3..85a6673 100644
--- a/arch/s390/kernel/syscalls.S
+++ b/arch/s390/kernel/syscalls.S
@@ -321,3 +321,5 @@ SYSCALL(sys_vmsplice,sys_vmsplice,compat
 NI_SYSCALL /* 310 
sys_move_pages */
 SYSCALL(sys_getcpu,sys_getcpu,sys_getcpu_wrapper)
 SYSCALL(sys_epoll_pwait,sys_epoll_pwait,sys_ni_syscall)
+SYSCALL(sys_revokeat,sys_revokeat,sys_revokeat_wrapper)
+SYSCALL(sys_frevoke,sys_frevoke,sys_frevoke_wrapper)
diff --git a/include/asm-s390/unistd.h b/include/asm-s390/unistd.h
index fb6fef9..6651cb1 100644
--- a/include/asm-s390/unistd.h
+++ b/include/asm-s390/unistd.h
@@ -250,8 +250,10 @@
 /* Number 310 is reserved for new sys_move_pages */
 #define __NR_getcpu311
 #define __NR_epoll_pwait   312
+#define __NR_revokeat  313
+#define __NR_frevoke   314
 
-#define NR_syscalls 313
+#define NR_syscalls 315
 
 /* 
  * There are some system calls that are not present on 64 bit, some
-- 
1.1.6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

[Lee Revell]

On 1/29/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:

1. Scheduling fairness.
Since kernel does not know about multiple threads behind given process,
it can not add it appropriate number of timeslices for execution.
Can be solved either by more tight collaboarion of the userspace and
kernelspace schedulers or simply by increasing process' nice value.


nice value is only meaningful for SCHED_OTHER.  How will you handle a
multithreaded realtime application that uses SCHED_OTHER as well as
SCHED_FIFO threads?

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

Re: 2.6.20-rc6-mm3

[Len Brown]

On Tuesday 30 January 2007 04:26, Andrew Morton wrote:
> On Tue, 30 Jan 2007 10:06:45 +0100
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, Jan 29, 2007 at 08:45:28PM -0800, Andrew Morton wrote:
> > > -x86_64-mm-share-whats-shareable.patch
> > > -x86_64-mm-only-call-unreachable_devices-when-type-1-is-available.patch
> > > -x86_64-mm-only-map-whats-necessary.patch
> > > -x86_64-mm-detect-and-support-the-e7520-and-the-945g-gz-p-pl.patch
> > > -x86_64-mm-reserve-resources-but-only-when-were-sure-about-them.patch
> > 
> > Want me to update these?  And maybe the other mmconfig related ones if
> > I can find them.
> > 
> 
> Thanks.  That depends upon which of Andi or Len merges first.
> 
> If Andi goes first, then Len has rather a bit of hackwork to do.
> 
> If Len goes first then things are probably simpler, but that ACPI codedrop
> is very new and might have problems.  We wouldn't want to hold the x86
> merge back because of it.

I think chances are actually quite good we'll be able to proceed with
pushing the ACPI table re-write immediately upon 2.6.21 open.

Note that while it is sort of big text-wise, it isn't that complicated --
and failures in this type of code tend to be massively obvious boot failures.
Note also that  2.6.20-rc6-mm3 is not the maiden voyage to -mm for this code.
It has been there several times before as it has matured.

The table re-write broke the HP simulator -- but I think we can fix that 
quickly.
I don't know yet what broke the HP rx2600.
The sysfs branch is what broke the button and the Altix boot.
Sysfs may or may not go upstream at 2.6.21 open -- but that isn't
the code you are conflicting with here so that is moot.

cheers,
-Len


> For now, I guess we sit back while Len and Andi sort out what they're going
> to do.
> 
> Len, what was in that merge anyway?  Lots of renaming and shuffling things
> around - the sorts of things which are safe as long as they compile OK.  But
> was there much substantive material in there as well?
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] filesystem: Disk Errors at boot-time caused by probe of partitions

[Robert Hancock]

TJ wrote:

From: TJ <[EMAIL PROTECTED]>

Applies to: up-to and including 2.6.20-rc7 


This rare but critical bug has the potential to cause a hardware failure on 
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of 
the physical
disk, causing sustained 'head banging'.


It seems pretty unlikely that telling a hard drive to seek past its 
capacity would cause it to damage itself, that would be some pretty 
moronic firmware. Though, you never know - if it's true, let me know 
what kind of drives these are, so I know never to buy one :-)


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

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

Re: 2.6.20-rc6-mm3

[Andrew Morton]

On Wed, 31 Jan 2007 23:10:32 -0500 Len Brown <[EMAIL PROTECTED]> wrote:

> >   CC  arch/i386/kernel/traps.o
> >   CC  arch/i386/kernel/irq.o
> >   CC  arch/i386/kernel/ptrace.o
> >   CC  arch/i386/kernel/time.o
> >   CC  arch/i386/kernel/ioport.o
> >   CC  arch/i386/kernel/ldt.o
> >   CC  arch/i386/kernel/setup.o
> > In file included from include/acpi/acpi.h:62,
> >  from include/linux/acpi.h:37,
> >  from arch/i386/kernel/setup.c:31:
> > include/acpi/acpixf.h:100: warning: 'struct acpi_pointer' declared
> > inside parameter list
> > include/acpi/acpixf.h:100: warning: its scope is only this definition or
> > declaration, which is probably not what you want
> > include/acpi/acpixf.h:115: error: expected ')' before 'table_type'
> > make[2]: *** [arch/i386/kernel/setup.o] Błąd 1
> > make[1]: *** [arch/i386/kernel] Błąd 2
> > make[1]: Opuszczenie katalogu `/usr/src/linux-rc'
> > make: *** [debian/stamp-build-kernel] Błąd 2
> > 
> > "Błąd"="Error" (in polish).
> 
> Note that you can always get the latest ACPI patch and drop it directly onto 
> Linus' tree here:
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.20/

I'm suspecting that Maciej misapplied the -mm patch somehow:

box:/usr/src/foo> grep acpi_pointer include/acpi/acpixf.h
box:/usr/src/foo> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unidentified Intel wifi network card

[Ross Vandegrift]

On Wed, Jan 31, 2007 at 03:54:55PM -0500, [EMAIL PROTECTED] wrote:
> Only gotcha I know of:  Sometimes one of the ipw3945d kernel threads will
> hang in a loop if the RFKill switch is set to "kill" when the system comes
> up.  I also don't know how it handles suspend, I don't use that on my D820.

I have a D820 and I had a horrible time with the wireless for a long
time.  Every five minutes or so, the card would flip out and burn 100%
CPU making the box unusable for 15-45 seconds.

The most recent version of the firmware fixed this issue and now
things are much better.

-- 
Ross Vandegrift
[EMAIL PROTECTED]

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc6-mm3

[Len Brown]

On Wednesday 31 January 2007 06:54, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
> 
> > OK, thanks.  That might be due to the time-management updates as well. 
> > I'll see if I can reproduce this.
> > 
> > If you're keen, you could test just 2.6.19-rc6+origin.patch+git-acpi.patch
> > from
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out
> > and see which of these problems remain.
> > 
> 
> I try 2.6.19-rc6 witch origin.patch and git-acpi.patch. This patch
> didn't add correctly (see patch_output.txt). Also I have compiling error:
> 
> AS  arch/i386/kernel/entry.o
>   CC  arch/i386/kernel/traps.o
>   CC  arch/i386/kernel/irq.o
>   CC  arch/i386/kernel/ptrace.o
>   CC  arch/i386/kernel/time.o
>   CC  arch/i386/kernel/ioport.o
>   CC  arch/i386/kernel/ldt.o
>   CC  arch/i386/kernel/setup.o
> In file included from include/acpi/acpi.h:62,
>  from include/linux/acpi.h:37,
>  from arch/i386/kernel/setup.c:31:
> include/acpi/acpixf.h:100: warning: 'struct acpi_pointer' declared
> inside parameter list
> include/acpi/acpixf.h:100: warning: its scope is only this definition or
> declaration, which is probably not what you want
> include/acpi/acpixf.h:115: error: expected ')' before 'table_type'
> make[2]: *** [arch/i386/kernel/setup.o] Błąd 1
> make[1]: *** [arch/i386/kernel] Błąd 2
> make[1]: Opuszczenie katalogu `/usr/src/linux-rc'
> make: *** [debian/stamp-build-kernel] Błąd 2
> 
> "Błąd"="Error" (in polish).

Note that you can always get the latest ACPI patch and drop it directly onto 
Linus' tree here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.20/

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

Re: Linux 2.6.20-rc7

[Linus Torvalds]

On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
> 
> I think i found the cause of the problem, initramfs can't handle hardlinks 
> anymore (which works with 2.6.18), copying same /sbin/busybox binary with 
> different names into initramfs (which ends ups with 50 MB image) or using 
> symbolic ones instead of hards seems works.

Ok, it would still be interesting to hear what triggered this.

There's really only two initramfs-related changes in the whole 2.6.20 
development series that I can see, and neither of them are even _remotely_ 
likely to cause this, afaik. We have:

 - commit 8d610dd52dd1da696e199e4b4545f33a2a5de5c6

   "Make sure we populate the initroot filesystem late enough"

(but "late enough" is still _way_ before we actually mount it, so ..) and

 - commit 2e591bbc0d563e12f5a260fbbca0df7d5810910e

   "Make initramfs printk a warning on incorrect cpio type"

and the latter is just a build-time sanity-check.

Since 2.6.18, there's been a couple more, but none of them look even 
remotely likely either. Which is why it really would be good if you can 
"git bisect" this behaviour.

There _was_ a hardlink-related thing some time ago, but that was back in 
May, and before 2.6.18. So if it worked for you in 2.6.18, I don't see 
that being it.

I've added some initramfs people to the Cc: in case somebody has better 
ideas, but in the absense of that, it really would be good to do that 
bisection. Also, you might want to double-check that your cpio actually 
generates a good initramfs image (it that it's not some user-mode upgrade 
that caused it to stop working).

Linus

Re: Linux 2.6.20-rc7

[S.Çağlar Onur]

01 Şub 2007 Per tarihinde, Linus Torvalds şunları yazmıştı: 
> That _usually_ just means that /sbin/modprobe is corrupt, or compiled with
> a binfmt that itself needs a module to load.
>
> Are you 100% certain that you didn't just happen to put an /sbin/modprobe
> into your initramfs that happens to be a.out, with a.out being modular? Or
> something similarly silly?

Yep, i'm sure config and binary is OK.

zangetsu ~ # readelf -h /sbin/busybox
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   Intel 80386
  Version:   0x1
  Entry point address:   0x8048130
  Start of program headers:  52 (bytes into file)
  Start of section headers:  1010608 (bytes into file)
  Flags: 0x0
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 5
  Size of section headers:   40 (bytes)
  Number of section headers: 25
  Section header string table index: 24

zangetsu ~ #  zcat /proc/config.gz | grep BINFMT
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

And as i said before same binaries works within initrd image with same kernel

> Actually, with that "binfmt-", I guess the most likely thing is a
> corrupt /sbin/modprobe that isn't a valid binfmt format at all (but the
> kernel won't know the difference between a missing binfmt thing and an
> invalid one). It has bytes 2/3 being zero, which is neither ELF nor
> a.out, methinks.
>
> BUT! If that's not it, doing a "git bisect" to figure out exactly what
> triggered it would be a wonderful idea..

I think i found the cause of the problem, initramfs can't handle hardlinks 
anymore (which works with 2.6.18), copying same /sbin/busybox binary with 
different names into initramfs (which ends ups with 50 MB image) or using 
symbolic ones instead of hards seems works.

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

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


pgp1WAfuE7ToU.pgp
Description: PGP signature

Re: [kvm-devel] [PATCH] KVM: Fix lockup on 32-bit intel hosts with nx disabled in the bios

[Jeff Chua]

On 1/31/07, Avi Kivity <[EMAIL PROTECTED]> wrote:

Intel hosts, without long mode, and with nx support disabled in the bios
have an efer that is readable but not writable.  This causes a lockup on
switch to guest mode (even though it should exit with reason 34 according to
the documentation).


Avi, thank you for the patch. I can confirm that this patch works on
my IBM X60s notebook. Without it, the whole PC locks up upon starting
qemu.

Thanks,
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.20-rc6-mm3 - interesting dmesg

[Len Brown]

On Tuesday 30 January 2007 06:52, Sunil Naidu wrote:
> Hi Andrew,
> 
> I did compile the same, it's a trouble free boot. I did observe
> interesting changes in the dmesg between 2.6.20-rc6 & 2.6.20-rc6-mm3
> (wondering why there are so many changes in the output). Anyway, the
> changes in brief:-
> 
> a) ACPI values

The new ACPI messages are normal.
They are the result of new table management code.

thanks,
-Len

> b) pnp - iomem range reserved values
> c) Drive selection (hda, hdb)
> d) USB Subsystem - (usb1, usb2, usb3, usb4, usb5, usb 2-1) - new
> devices found.
> e) EXT3-fs - warning - maximal_mount_count reached (???)
> 
> Here is the dmesg info:-

> ACPI: RSDP @ 0x000f4eb0/0x0014 (v000 ACPIAM)
> ACPI: RSDT @ 0x1f73/0x003C (v001 INTEL  D915GAV  0x20060222 MSFT 
> 0x0097)
> ACPI: FACP @ 0x1f730200/0x0081 (v002 INTEL  D915GAV  0x20060222 MSFT 
> 0x0097)
> ACPI: DSDT @ 0x1f730440/0x5C05 (v001 INTEL  D915GAV  0x0001 INTL 
> 0x02002026)
> ACPI: FACS @ 0x1f74/0x0040
> ACPI: APIC @ 0x1f730390/0x0068 (v001 INTEL  D915GAV  0x20060222 MSFT 
> 0x0097)
> ACPI: MCFG @ 0x1f730400/0x003C (v001 INTEL  D915GAV  0x20060222 MSFT 
> 0x0097)
> ACPI: ASF! @ 0x1f736050/0x0099 (v016 LEGEND I865PASF 0x0001 INTL 
> 0x02002026)
> ACPI: TCPA @ 0x1f7360f0/0x0032 (v001 INTEL  TBLOEMID 0x0001 MSFT 
> 0x0097)
> ACPI: WDDT @ 0x1f736122/0x0040 (v001 INTEL  OEMWDDT  0x0001 INTL 
> 0x02002026)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] kbuild: correctly skip tilded backups in localversion files

[Andrew Morton]

On Thu, 1 Feb 2007 03:37:17 +0100 Oleg Verych <[EMAIL PROTECTED]> wrote:

> On Wed, Jan 31, 2007 at 03:56:51PM -0800, Andrew Morton wrote:
> > On Wed, 31 Jan 2007 07:11:04 +
> > Oleg Verych <[EMAIL PROTECTED]> wrote:
> > 
> > > kbuild: correctly skip tilded backups in localversion files
> > 
> > Does this patch replace Bastian's patch, below?
> 
> Along with "Message-ID: <[EMAIL PROTECTED]>" -- yes.
> 

OK.  Just to avoid mistakes, can you please resend everything, against
2.6.20-rc7?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture

[Nigel Cunningham]

Hi Paul.

On Wed, 2007-01-31 at 18:31 -0800, Paul E. McKenney wrote:
> Good to hear from you, Nigel!

Thanks :)

> Should indeed be OK to freeze during suspend/hibernate.  Will my
> schedule_timeout_interruptible() be sufficient to allow the freeze
> to happen, or do I need to add an explicit try_to_freeze()?

You need a try_to_freeze() - the process has to enter the refrigerator()
function to be counted as frozen.

> Ah, and I probably need to use the same trick that mtd_blktrans_thread()
> does to avoid having all my sleeps killed of by an errant signal:
> 
>   spin_lock_irq(>sighand->siglock);
>   sigfillset(>blocked);
>   recalc_sigpending();
>   spin_unlock_irq(>sighand->siglock);
> 
> Or is such paranoia unnecessary?

Yeah. try_to_freeze() is a function now, so you can do something if
(try_to_freeze()) goto sleep_again if you so desire.

Regards,

Nigel

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

Re: Linux 2.6.20-rc7

[Linus Torvalds]

On Thu, 1 Feb 2007, S.ÃaÄlar Onur wrote:
> 
> For me, both 2.6.20-rc6 and 2.6.20-rc7 fails while booting with initramfs 
> (initramfs that uses busybox) with "request_module: runaway loop modprobe 
> binfmt-" error. 

That _usually_ just means that /sbin/modprobe is corrupt, or compiled with 
a binfmt that itself needs a module to load.

Are you 100% certain that you didn't just happen to put an /sbin/modprobe 
into your initramfs that happens to be a.out, with a.out being modular? Or 
something similarly silly?

Actually, with that "binfmt-", I guess the most likely thing is a 
corrupt /sbin/modprobe that isn't a valid binfmt format at all (but the 
kernel won't know the difference between a missing binfmt thing and an 
invalid one). It has bytes 2/3 being zero, which is neither ELF nor 
a.out, methinks.

BUT! If that's not it, doing a "git bisect" to figure out exactly what 
triggered it would be a wonderful idea..

Linus

Re: [BUG]: 2.6.19.2: Weird serial core issue

[Aubrey Li]

On 2/1/07, Alan <[EMAIL PROTECTED]> wrote:

> When I telnet my board and run the following command:
>  root:~> stty -F /dev/ttyS0 -crtscts
>
> I got the following result from the console of my board:
>  root:~>new_termios flag: 0x1cb1, old_termios flag: 0x80001cb1
>
> That's correct. CRTSCTS flag is clear
>
> But when I type "ENTER" key on the console, I got:
> root:~>new_termios flag: 0x80001cb1, old_termios flag: 0x1cb1

What code is running on that console at the time. Most likely that user
code is also saving/restoring terminal settings so overwrite yours



I implemented the serial driver by myself, :). See the attachment.
I didn't save/restore terminal setting in the my_set_termios().

I trace this back till tty_tioctl(..., unsigned long arg), everytime I
type "ENTER" key,
the argument "arg" passed into tty_ioctl() is the address of a termios
structure, which include wrong c_cflag. It seems once the flag is
assigned by uart_set_options the first time, it's never changed. So
even userspace application changed the flag, it will be set back soon.
I'll dig into it. But I still think it's a bug.

-Aubrey


bfin_5xx.c
Description: Binary data

Re: [PATCH] EFI x86: pass firmware call parameters on the stack

[bibo,mao]

Frédéric Riss wrote:

Le mardi 30 janvier 2007 à 12:17 -0700, Bjorn Helgaas a écrit :

On Tuesday 30 January 2007 12:01, Frédéric Riss wrote:

When calling into an EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
when run in EFI mode (efi.get_time is called during the suspend phase).
...
This patch fixes the issue for x86, but the file is also used by IA64. I
would have used asmlinkage to force arguments on the stack, but it has a
special meaning on IA64, thus I used a raw regparm(0) GCC attribute.
This attribute is documented only for x86, I hope it has no side effect
on other archs.

It seems wrong to put this sort of architecture-dependent stuff in
an architecture-independent file.  If EFI needs a specific calling
convention on x86, x86 should provide wrappers that guarantee that
convention.  ia64 already provides such wrappers (phys_get_time(),
virt_get_time(), etc).


[ Disclaimer: I don't know much about EFI. I wanted to download the
spec, but it required me to sign some sort of agreement about needing a
license to write an implementation... I ran away. ]

You're totally right, I first thought it wasn't possible, but the
functions in the 'struct efi' can be set to whatever is wanted. Bellow's
a patch which won't have any impact on ia64 and fixes the issue on my
Mac Mini. I don't think x86_64 can be configured to boot from EFI, so
this shouldn't cause any regression on that front. How does that look?

currently x86_64 kernel does not support efi, efi convention comply to
MS convention. On ia32 parameter is passed on stack, on x86_64 parameter
is passed by registers but that is different from x86_64 linux convention.

How about adding EFIAPI prefix before efi runtime service function, this
prefix has different definition in different architecture. 


thanks
bibo,mao

--- 2.6.20-rc6/include/linux/efi.h.bak  2007-02-01 10:49:13.0 +0800
+++ 2.6.20-rc6/include/linux/efi.h  2007-02-01 10:54:24.0 +0800
@@ -157,22 +157,28 @@ typedef struct {
unsigned long reset_system;
} efi_runtime_services_t;

-typedef efi_status_t efi_get_time_t (efi_time_t *tm, efi_time_cap_t *tc);
-typedef efi_status_t efi_set_time_t (efi_time_t *tm);
-typedef efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, efi_bool_t 
*pending,
+#ifdef CONFIG_X86_32 
+#define EFIAPI	asmlinkage

+# else
+#define EFIAPI
+# endif
+
+typedef EFIAPI efi_status_t efi_get_time_t (efi_time_t *tm, efi_time_cap_t 
*tc);
+typedef EFIAPI efi_status_t efi_set_time_t (efi_time_t *tm);
+typedef EFIAPI efi_status_t efi_get_wakeup_time_t (efi_bool_t *enabled, 
efi_bool_t *pending,
efi_time_t *tm);
-typedef efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled, efi_time_t 
*tm);
-typedef efi_status_t efi_get_variable_t (efi_char16_t *name, efi_guid_t 
*vendor, u32 *attr,
+typedef EFIAPI efi_status_t efi_set_wakeup_time_t (efi_bool_t enabled, 
efi_time_t *tm);
+typedef EFIAPI efi_status_t efi_get_variable_t (efi_char16_t *name, efi_guid_t 
*vendor, u32 *attr,
 unsigned long *data_size, void *data);
-typedef efi_status_t efi_get_next_variable_t (unsigned long *name_size, 
efi_char16_t *name,
+typedef EFIAPI efi_status_t efi_get_next_variable_t (unsigned long *name_size, 
efi_char16_t *name,
  efi_guid_t *vendor);
-typedef efi_status_t efi_set_variable_t (efi_char16_t *name, efi_guid_t *vendor, 
+typedef EFIAPI efi_status_t efi_set_variable_t (efi_char16_t *name, efi_guid_t *vendor, 
	 unsigned long attr, unsigned long data_size, 
	 void *data);

-typedef efi_status_t efi_get_next_high_mono_count_t (u32 *count);
-typedef void efi_reset_system_t (int reset_type, efi_status_t status,
+typedef EFIAPI efi_status_t efi_get_next_high_mono_count_t (u32 *count);
+typedef EFIAPI void efi_reset_system_t (int reset_type, efi_status_t status,
 unsigned long data_size, efi_char16_t *data);
-typedef efi_status_t efi_set_virtual_address_map_t (unsigned long 
memory_map_size,
+typedef EFIAPI efi_status_t efi_set_virtual_address_map_t (unsigned long 
memory_map_size,
unsigned long descriptor_size,
u32 descriptor_version,
efi_memory_desc_t *virtual_map);




When calling into the EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
(efi.get_time is called during the suspend phase).

Signed-off-by: Frederic Riss <[EMAIL PROTECTED]>

---

diff --git a/arch/i386/kernel/efi.c b/arch/i386/kernel/efi.c
index b92c7f0..6196314 100644
--- a/arch/i386/kernel/efi.c
+++ 

Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture

[Paul E. McKenney]

On Thu, Feb 01, 2007 at 01:12:16PM +1100, Nigel Cunningham wrote:
> Hi Paul.
> 
> On Wed, 2007-01-31 at 17:26 -0800, Paul E. McKenney wrote:
> > This patch adds an optional preemption kernel thread to the rcutorture
> > tests.  This thread sets itself to a low RT priority and chews up CPU
> > in 10-second bursts, verifying that grace periods progress during this
> > 10-second interval.  Passes RCU torture testing on a 4-CPU (a pair of
> > 2-CPU dies) 64-bit Xeon system.
> 
> [...]
> 
> > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> > +static int rcu_torture_preempt(void *arg)
> > +{
> > +   int completedstart;
> > +   int err;
> > +   time_t gcstart;
> > +   struct sched_param sp;
> > +
> > +   sp.sched_priority = MAX_RT_PRIO - 1;
> > +   err = sched_setscheduler(current, SCHED_RR, );
> > +   if (err != 0)
> > +   printk(KERN_ALERT "rcu_torture_preempt() priority err: %d\n",
> > +  err);
> > +   current->flags |= PF_NOFREEZE;
> > +
> > +   do {
> > +   completedstart = rcu_torture_completed();
> > +   gcstart = xtime.tv_sec;
> > +   while ((xtime.tv_sec - gcstart < 10) &&
> > +  (rcu_torture_completed() == completedstart))
> > +   cond_resched();
> > +   if (rcu_torture_completed() == completedstart)
> > +   rcu_torture_preempt_errors++;
> > +   schedule_timeout_interruptible(HZ);
> > +   } while (!kthread_should_stop());
> > +   return 0;
> > +}
> 
> Does it need to be NOFREEZE? I would think that it should be frozen
> during a suspend/hibernate.

Good to hear from you, Nigel!

Should indeed be OK to freeze during suspend/hibernate.  Will my
schedule_timeout_interruptible() be sufficient to allow the freeze
to happen, or do I need to add an explicit try_to_freeze()?

Ah, and I probably need to use the same trick that mtd_blktrans_thread()
does to avoid having all my sleeps killed of by an errant signal:

spin_lock_irq(>sighand->siglock);
sigfillset(>blocked);
recalc_sigpending();
spin_unlock_irq(>sighand->siglock);

Or is such paranoia unnecessary?

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

Re: [patch] kbuild: correctly skip tilded backups in localversion files

[Oleg Verych]

On Wed, Jan 31, 2007 at 03:56:51PM -0800, Andrew Morton wrote:
> On Wed, 31 Jan 2007 07:11:04 +
> Oleg Verych <[EMAIL PROTECTED]> wrote:
> 
> > kbuild: correctly skip tilded backups in localversion files
> 
> Does this patch replace Bastian's patch, below?

Along with "Message-ID: <[EMAIL PROTECTED]>" -- yes.

Note, that they also make a little bit of cleanup to top makefile's mess,
And, i think, have more elegant, portable, clean solution.

Roman commented on another my patch, saying, that tilde in the end isn't
the only way to name backups. Filename, containing '~' is a backup in the
sources, thus i'm proposing new patch.

Unfortunately still no more comments from anybody. Roman joined, but
seems busy now, to comment on such minor stuff.

Anyway, thanks.


> From: Bastian Blank <[EMAIL PROTECTED]>
> 
> Fix the problem that localversion files were ignored if the tree lives in
> a path which contains a ~.  It changes the test to apply to the filename
> only.
> 
> Debian allows versions which contains ~ in it.  The upstream part of the
> version is in the directory name of the build tree and we got weird results
> because the localversion files was just got ignored in this case.
> 
> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
> Cc: Roman Zippel <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
> 
>  Makefile |2 +-
>  1 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN 
> Makefile~kbuild-dont-ignore-localversion-files-if-the-path-includes-a Makefile
> --- a/Makefile~kbuild-dont-ignore-localversion-files-if-the-path-includes-a
> +++ a/Makefile
> @@ -793,7 +793,7 @@ space  := $(nullstring) # end of lin
>  ___localver = $(objtree)/localversion* $(srctree)/localversion*
>  __localver  = $(sort $(wildcard $(___localver)))
>  # skip backup files (containing '~')
> -_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(f)),,$(f)))
> +_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(notdir 
> $(f))),,$(f)))
>  
>  localver = $(subst $(space),, \
>  $(shell cat /dev/null $(_localver)) \
> _
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.20-rc7

[S.Çağlar Onur]

Hi;

31 Oca 2007 Çar tarihinde şunları yazmıştınız:
> In other words, please do give it a good testing. We should have fixed the
> nasty stuff on Adrian's list (and here's another thanks to Adrian for
> keeping me on my toes!) and it's all good. But please give it a quick
> shake-down to make sure that nothing silly happened while fixing the bad
> stuff.

For me, both 2.6.20-rc6 and 2.6.20-rc7 fails while booting with initramfs 
(initramfs that uses busybox) with "request_module: runaway loop modprobe 
binfmt-" error. 

So i modified kmod.c with [1] to get dump_stack, here is the picture taken 
with [2] dump_stack enabled one with description below.

And here is the some observations that i made;

* Booting without an initramfs works,
* Booting with converted initrd from failed initramfs's content works,
* Booting with "Hello world" type initramfs described 
in "Documentation/filesystems/ramfs-rootfs-initramfs.txt" works,

But what is not working is busybox binaries inside the _initramfs_, modifiying 
our init shell script to use staticly linked bash with confirms that, bash 
script interpretted without a problem by staticaly linked bash until 
busybox's mount binary called inside the initramfs.

First i thought somehow busybox is broken but copying initramfs's content into 
initrd works without a problem and also same binaries are working with 2.6.18 
so i think its a regression in kernel but of course im not sure :), if you 
need more information please ask.

[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg109266.html
[2] http://cekirdek.uludag.org.tr/~caglar/error.png

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

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


pgpoicz4utmTQ.pgp
Description: PGP signature

Re: [RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture

[Nigel Cunningham]

Hi Paul.

On Wed, 2007-01-31 at 17:26 -0800, Paul E. McKenney wrote:
> This patch adds an optional preemption kernel thread to the rcutorture
> tests.  This thread sets itself to a low RT priority and chews up CPU
> in 10-second bursts, verifying that grace periods progress during this
> 10-second interval.  Passes RCU torture testing on a 4-CPU (a pair of
> 2-CPU dies) 64-bit Xeon system.

[...]

> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> +static int rcu_torture_preempt(void *arg)
> +{
> + int completedstart;
> + int err;
> + time_t gcstart;
> + struct sched_param sp;
> +
> + sp.sched_priority = MAX_RT_PRIO - 1;
> + err = sched_setscheduler(current, SCHED_RR, );
> + if (err != 0)
> + printk(KERN_ALERT "rcu_torture_preempt() priority err: %d\n",
> +err);
> + current->flags |= PF_NOFREEZE;
> +
> + do {
> + completedstart = rcu_torture_completed();
> + gcstart = xtime.tv_sec;
> + while ((xtime.tv_sec - gcstart < 10) &&
> +(rcu_torture_completed() == completedstart))
> + cond_resched();
> + if (rcu_torture_completed() == completedstart)
> + rcu_torture_preempt_errors++;
> + schedule_timeout_interruptible(HZ);
> + } while (!kthread_should_stop());
> + return 0;
> +}

Does it need to be NOFREEZE? I would think that it should be frozen
during a suspend/hibernate.

Regards,

Nigel

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

Re: [PATCH 1/10] cxgb3 - FW versioning

[Divy Le Ray]

Hi Jeff,

Please see my replies in line.

You need to submit a patch to remove the following ioctls:

CHELSIO_SETREG:
CHELSIO_GETREG:


These will get removed.


CHELSIO_SET_QSET_PARAMS: (use ethtool instead)
CHELSIO_GET_QSET_PARAMS: (use ethtool instead)


The T3 adapter supports multiple Tx/Rx queue sets,
each can be can individually configured through these ioctls.

ethtool is not adequate replacement because it can't configure
each queue individually on such a device. We'd love it if ethtool
were to be extended to provide good support for multi queue devices.


CHELSIO_SET_QSET_NUM: (use ethtool instead)
CHELSIO_GET_QSET_NUM: (use ethtool instead)


These are used to set the number of queue sets per port.
That also could be integrated in ethtool if extended
to add support for multiple queue devices.
We could alternatively use a sysfs attribute.


CHELSIO_SETMTUTAB:


This one is needed to setup the device for RDMA.


CHELSIO_GET_MEM:


This one is used for field diagnostics.
It dumps the state of on-card memory.


CHELSIO_SET_TRACE_FILTER:


This one is used for RDMA.
It allows to see the ethernet packets the RDMA function
puts on the wire/receives from the wire.


CHELSIO_SET_PKTSCHED:


This one binds a queue set to a port.
It could be turned to a sysfs attribute.



explain and possibly remove

CHELSIO_GET_PM:
CHELSIO_SET_PM:


These are used to configure the on-card memory (tx/rx size
and number of pages). They could be turned into sysfs attributes.

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

Re: Free Linux Driver Development!

[Greg KH]

On Thu, Feb 01, 2007 at 10:07:53AM +1000, Trent Waddington wrote:
> On 2/1/07, Greg KH <[EMAIL PROTECTED]> wrote:
> >No, I'm going by Linus's rule here, if a person doesn't want their code
> >in the kernel tree, then I'm not going to forcefully put it there.
> >That's just being rude.
> 
> Makes sense when you put it that way.  However, perhaps an offer to
> take over the maintenance of the driver when incorporating it into the
> kernel tree would be welcomed more readily by some people than just
> "so when ya gunna merge?" style badgering.

You would be supprised, not all people welcome this.  Believe me, I've
tried...

thanks,

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

[PATCH 1/1] filesystem: Disk Errors at boot-time caused by probe of partitions

[TJ]

From: TJ <[EMAIL PROTECTED]>

Applies to: up-to and including 2.6.20-rc7 

Update to previous patch.

Fixed logical error in if() statements for conditional printk(). Replaced 
bit-wise OR with AND.

Signed-off-by: TJ <[EMAIL PROTECTED]>

--- fs/partitions/msdos.tj.c2007-02-01 00:41:57.0 +
+++ fs/partitions/msdos.tj.1.c  2007-02-01 01:07:31.0 +
@@ -459,13 +459,13 @@ int check_sane_values(struct partition *
if (insane) { /* insanity found; report it */
ret = -1; /* error code */
printk("\n"); /* start error report on a fresh line */
-   if (insane | 1)
+   if (insane & 1)
printk(" partition %d: start (sector %d) beyond 
end of disk (sector %d)\n",
 slot, START_SECT(p), (unsigned int) 
bdev->bd_disk->capacity-1);
-   if (insane | 2)
+   if (insane & 2)
printk(" partition %d: end (sector %d) beyond 
end of disk (sector %d)\n",
 slot, START_SECT(p)+NR_SECTS(p)-1, (unsigned 
int) bdev->bd_disk->capacity-1);
-   if (insane | 4)
+   if (insane & 4)
printk(" partition %d: insane extended 
contents\n", slot);
}
}




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

Re: Free Linux Driver Development!

[Lee Revell]

On 1/31/07, Mark Lord <[EMAIL PROTECTED]> wrote:

Randy Dunlap wrote:
> On Wed, 31 Jan 2007 18:00:15 -0500 Theodore Tso wrote:
..
>> More specifically, Dave said that it "seemed rude" to just take the
>> driver and send updates, but maybe the best way of dealing with
>> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
>> kind of spec release, and just have someone in the community forcibly
>> take the code, fix it up, and then get it merged.  Maybe it's being
>> "rude", but so is not responding to requests to get it merged.

I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.

It's just not worth the effort/abuse for many maintainers to pursue it.


That seems like the easy part - it seems like anyone bright enough to
write a working Linux driver would be good enough with their editor or
perl or bash to knock that out in 10 minutes.

I would think rules like "no new ioctls" and "no new /proc entries",
that might seem arbitrary to one who doesn't follow kernel
development, plus the occasionally insulting code reviewer, would be
more of an issue.

Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 8/10] cxgb3 - Unmap offload packets when they are freed.

[Divy Le Ray]

Jeff Garzik wrote:

Divy Le Ray wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Offload packets may be DMAed long after their SGE Tx descriptors are 
done

so they must remain mapped until they are freed rather than until their
descriptors are freed.  Unmap such packets through an skb destructor.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>


this is questionable and sounds like you are working around a bug.  I 
can't think of another driver that uses skb destructors, and I could 
have sworn that skb destructors were not for drivers to use anyway
It's not a bug work around.  The payload of RDMA packets is DMAd lazily, 
potentially well after the DMA descriptors themselves have been 
processed and released. On plaftorms w/ IOMMUs, the packets need to 
remain mapped in the IOMMU until their payload is fetched, at which time 
the Scatter/Gather Engine may or may not still have knowledge of those 
packets.  So the SGE maps them for the IOMMU, then sets up the 
destructor so they can be unmapped whenever they complete.  It's true 
that drivers don't typically set up destructors but the lazy DMA this 
device does is also uncommon.  Packets carrying these destructors are 
exchanged between the RDMA driver and the low-level driver and aren't 
visible to any parts of the stack that may have different expectations 
of destructors.  Using the destructor is the simplest, most convenient 
way to solve this problem.


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

[RFC PATCH -rt 2/2] RCU priority boosting additions to rcutorture

[Paul E. McKenney]

This patch adds an optional preemption kernel thread to the rcutorture
tests.  This thread sets itself to a low RT priority and chews up CPU
in 10-second bursts, verifying that grace periods progress during this
10-second interval.  Passes RCU torture testing on a 4-CPU (a pair of
2-CPU dies) 64-bit Xeon system.

Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---

 rcutorture.c |   90 +--
 1 files changed, 76 insertions(+), 14 deletions(-)

diff -urpNa -X dontdiff linux-2.6.20-rc6-rt4/kernel/rcutorture.c 
linux-2.6.20-rc6-rt4-rcubtorture/kernel/rcutorture.c
--- linux-2.6.20-rc6-rt4/kernel/rcutorture.c2007-01-29 17:02:10.0 
-0800
+++ linux-2.6.20-rc6-rt4-rcubtorture/kernel/rcutorture.c2007-01-29 
17:58:38.0 -0800
@@ -58,6 +58,7 @@ static int stat_interval; /* Interval be
 static int verbose;/* Print more debug info. */
 static int test_no_idle_hz;/* Test RCU's support for tickless idle CPUs. */
 static int shuffle_interval = 5; /* Interval between shuffles (in sec)*/
+static int preempt_torture = 0;/* Realtime task preempts torture 
readers. */
 static char *torture_type = "rcu"; /* What RCU implementation to torture. */
 
 module_param(nreaders, int, 0);
@@ -72,6 +73,8 @@ module_param(test_no_idle_hz, bool, 0);
 MODULE_PARM_DESC(test_no_idle_hz, "Test support for tickless idle CPUs");
 module_param(shuffle_interval, int, 0);
 MODULE_PARM_DESC(shuffle_interval, "Number of seconds between shuffles");
+module_param(preempt_torture, bool, 0);
+MODULE_PARM_DESC(preempt_torture, "Enable realtime preemption torture");
 module_param(torture_type, charp, 0);
 MODULE_PARM_DESC(torture_type, "Type of RCU to torture (rcu, rcu_bh, srcu)");
 
@@ -194,6 +197,8 @@ struct rcu_torture_ops {
int (*completed)(void);
void (*deferredfree)(struct rcu_torture *p);
void (*sync)(void);
+   long (*preemptstart)(void);
+   void (*preemptend)(void);
int (*stats)(char *page);
char *name;
 };
@@ -258,16 +263,74 @@ static void rcu_torture_deferred_free(st
call_rcu(>rtort_rcu, rcu_torture_cb);
 }
 
+static struct task_struct *rcu_preeempt_task;
+static unsigned long rcu_torture_preempt_errors = 0;
+
+static int rcu_torture_preempt(void *arg)
+{
+   int completedstart;
+   int err;
+   time_t gcstart;
+   struct sched_param sp;
+
+   sp.sched_priority = MAX_RT_PRIO - 1;
+   err = sched_setscheduler(current, SCHED_RR, );
+   if (err != 0)
+   printk(KERN_ALERT "rcu_torture_preempt() priority err: %d\n",
+  err);
+   current->flags |= PF_NOFREEZE;
+
+   do {
+   completedstart = rcu_torture_completed();
+   gcstart = xtime.tv_sec;
+   while ((xtime.tv_sec - gcstart < 10) &&
+  (rcu_torture_completed() == completedstart))
+   cond_resched();
+   if (rcu_torture_completed() == completedstart)
+   rcu_torture_preempt_errors++;
+   schedule_timeout_interruptible(HZ);
+   } while (!kthread_should_stop());
+   return 0;
+}
+
+static long rcu_preempt_start(void)
+{
+   long retval = 0;
+
+   rcu_preeempt_task = kthread_run(rcu_torture_preempt, NULL,
+   "rcu_torture_preempt");
+   if (IS_ERR(rcu_preeempt_task)) {
+   VERBOSE_PRINTK_ERRSTRING("Failed to create preempter");
+   retval = PTR_ERR(rcu_preeempt_task);
+   rcu_preeempt_task = NULL;
+   }
+   return retval;
+}
+
+static void rcu_preempt_end(void)
+{
+   if (rcu_preeempt_task != NULL) {
+   VERBOSE_PRINTK_STRING("Stopping rcu_preempt task");
+   kthread_stop(rcu_preeempt_task);
+   }
+   rcu_preeempt_task = NULL;
+}
+
+static int rcu_preempt_stats(char *page) {
+   return sprintf(page,
+  "Preemption stalls: %lu\n", rcu_torture_preempt_errors);
+}
+
 static struct rcu_torture_ops rcu_ops = {
-   .init = NULL,
-   .cleanup = NULL,
.readlock = rcu_torture_read_lock,
.readdelay = rcu_read_delay,
.readunlock = rcu_torture_read_unlock,
.completed = rcu_torture_completed,
.deferredfree = rcu_torture_deferred_free,
.sync = synchronize_rcu,
-   .stats = NULL,
+   .preemptstart = rcu_preempt_start,
+   .preemptend = rcu_preempt_end,
+   .stats = rcu_preempt_stats,
.name = "rcu"
 };
 
@@ -299,14 +362,12 @@ static void rcu_sync_torture_init(void)
 
 static struct rcu_torture_ops rcu_sync_ops = {
.init = rcu_sync_torture_init,
-   .cleanup = NULL,
.readlock = rcu_torture_read_lock,
.readdelay = rcu_read_delay,
.readunlock = rcu_torture_read_unlock,
.completed = rcu_torture_completed,
.deferredfree = rcu_sync_torture_deferred_free,
.sync = 

[RFC PATCH -rt 1/2] RCU priority boosting that survives vicious testing

[Paul E. McKenney]

Here is the RCU priority-boosting patch.  Pretty close to the
http://lkml.org/lkml/2007/1/24/295 version.  This patch prevents
preempted or blocked low-priority RCU readers from indefinitely
stalling RCU grace periods.

Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---

 include/linux/init_task.h  |   12 +
 include/linux/rcupdate.h   |   12 +
 include/linux/rcupreempt.h |   20 +
 include/linux/sched.h  |   16 +
 init/main.c|1 
 kernel/Kconfig.preempt |   32 ++
 kernel/fork.c  |6 
 kernel/rcupreempt.c|  528 +
 kernel/rtmutex.c   |7 
 kernel/sched.c |5 
 10 files changed, 636 insertions(+), 3 deletions(-)

diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/include/linux/init_task.h 
linux-2.6.20-rc4-rt1-rcub/include/linux/init_task.h
--- linux-2.6.20-rc4-rt1/include/linux/init_task.h  2007-01-09 
10:59:54.0 -0800
+++ linux-2.6.20-rc4-rt1-rcub/include/linux/init_task.h 2007-01-09 
11:01:12.0 -0800
@@ -87,6 +87,17 @@ extern struct nsproxy init_nsproxy;
.siglock= __SPIN_LOCK_UNLOCKED(sighand.siglock),\
 }
 
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+#define INIT_RCU_BOOST_PRIO .rcu_prio  = MAX_PRIO,
+#define INIT_PREEMPT_RCU_BOOST(tsk)\
+   .rcub_rbdp  = NULL, \
+   .rcub_state = RCU_BOOST_IDLE,   \
+   .rcub_entry = LIST_HEAD_INIT(tsk.rcub_entry),
+#else /* #ifdef CONFIG_PREEMPT_RCU_BOOST */
+#define INIT_RCU_BOOST_PRIO
+#define INIT_PREEMPT_RCU_BOOST(tsk)
+#endif /* #else #ifdef CONFIG_PREEMPT_RCU_BOOST */
+
 extern struct group_info init_groups;
 
 /*
@@ -143,6 +154,7 @@ extern struct group_info init_groups;
.pi_lock= RAW_SPIN_LOCK_UNLOCKED(tsk.pi_lock),  \
INIT_TRACE_IRQFLAGS \
INIT_LOCKDEP\
+   INIT_PREEMPT_RCU_BOOST(tsk) \
 }
 
 
diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/include/linux/rcupdate.h 
linux-2.6.20-rc4-rt1-rcub/include/linux/rcupdate.h
--- linux-2.6.20-rc4-rt1/include/linux/rcupdate.h   2007-01-09 
10:59:54.0 -0800
+++ linux-2.6.20-rc4-rt1-rcub/include/linux/rcupdate.h  2007-01-09 
11:01:12.0 -0800
@@ -227,6 +227,18 @@ extern void rcu_barrier(void);
 extern void rcu_init(void);
 extern void rcu_advance_callbacks(int cpu, int user);
 extern void rcu_check_callbacks(int cpu, int user);
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+extern void init_rcu_boost_late(void);
+extern void __rcu_preempt_boost(void);
+#define rcu_preempt_boost() \
+   do { \
+   if (unlikely(current->rcu_read_lock_nesting > 0)) \
+   __rcu_preempt_boost(); \
+   } while (0)
+#else /* #ifdef CONFIG_PREEMPT_RCU_BOOST */
+#define init_rcu_boost_late()
+#define rcu_preempt_boost()
+#endif /* #else #ifdef CONFIG_PREEMPT_RCU_BOOST */
 
 #endif /* __KERNEL__ */
 #endif /* __LINUX_RCUPDATE_H */
diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/include/linux/rcupreempt.h 
linux-2.6.20-rc4-rt1-rcub/include/linux/rcupreempt.h
--- linux-2.6.20-rc4-rt1/include/linux/rcupreempt.h 2007-01-09 
10:59:54.0 -0800
+++ linux-2.6.20-rc4-rt1-rcub/include/linux/rcupreempt.h2007-01-25 
16:30:46.0 -0800
@@ -42,6 +42,26 @@
 #include 
 #include 
 
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+/*
+ * Task state with respect to being RCU-boosted.  This state is changed
+ * by the task itself in response to the following three events:
+ * 1. Preemption (or block on lock) while in RCU read-side critical section.
+ * 2. Outermost rcu_read_unlock() for blocked RCU read-side critical section.
+ *
+ * The RCU-boost task also updates the state when boosting priority.
+ */
+enum rcu_boost_state {
+   RCU_BOOST_IDLE = 0,/* Not yet blocked if in RCU read-side. */
+   RCU_BOOST_BLOCKED = 1, /* Blocked from RCU read-side. */
+   RCU_BOOSTED = 2,   /* Boosting complete. */
+   RCU_BOOST_INVALID = 3, /* For bogus state sightings. */
+};
+
+#define N_RCU_BOOST_STATE (RCU_BOOST_INVALID + 1)
+
+#endif /* #ifdef CONFIG_PREEMPT_RCU_BOOST */
+
 #define rcu_qsctr_inc(cpu)
 #define rcu_bh_qsctr_inc(cpu)
 #define call_rcu_bh(head, rcu) call_rcu(head, rcu)
diff -urpNa -X dontdiff linux-2.6.20-rc4-rt1/include/linux/sched.h 
linux-2.6.20-rc4-rt1-rcub/include/linux/sched.h
--- linux-2.6.20-rc4-rt1/include/linux/sched.h  2007-01-09 10:59:54.0 
-0800
+++ linux-2.6.20-rc4-rt1-rcub/include/linux/sched.h 2007-01-09 
11:01:12.0 -0800
@@ -699,6 +699,14 @@ struct signal_struct {
 #define is_rt_policy(p)((p) != SCHED_NORMAL && (p) != 
SCHED_BATCH)
 #define has_rt_policy(p)   unlikely(is_rt_policy((p)->policy))
 
+#ifdef CONFIG_PREEMPT_RCU_BOOST
+#define set_rcu_prio(p, prio)  ((p)->rcu_prio = 

[RFC PATCH -rt 0/2] RCU priority boosting that survives vicious testing

[Paul E. McKenney]

Hello!

This is yet another update of the RCU priority-boosting patch
(see http://lkml.org/lkml/2007/1/24/294 for the previous version).
This series contains the RCU-boost patch itself and rcutorture
modifications to test it more thoroughly.  This version incorporates
feedback from Josh Triplett and applies cleanly to 2.6.20-rc6-rt6.

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

[PATCH 2.6.20-rc7 2/2] atl1: add ethtool set ring params functionality

[Jay Cliburn]

From: Jay Cliburn <[EMAIL PROTECTED]>

Fix up some constants relating to max and min ring descriptor counts.
Also add functionality to enable ethtool to set tx and rx ring parameters.

Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---

 drivers/net/atl1/atl1.h |4 +-
 drivers/net/atl1/atl1_ethtool.c |   78 ++-
 2 files changed, 78 insertions(+), 4 deletions(-)

diff --git a/drivers/net/atl1/atl1.h b/drivers/net/atl1/atl1.h
index cc18016..da4bf87 100644
--- a/drivers/net/atl1/atl1.h
+++ b/drivers/net/atl1/atl1.h
@@ -44,11 +44,11 @@ struct atl1_adapter;
 #define ATL1_MAX_INTR  3
 
 #define ATL1_DEFAULT_TPD   256
-#define ATL1_MAX_TPD   1023
+#define ATL1_MAX_TPD   1024
 #define ATL1_MIN_TPD   64
 #define ATL1_DEFAULT_RFD   512
 #define ATL1_MIN_RFD   128
-#define ATL1_MAX_RFD   2047
+#define ATL1_MAX_RFD   2048
 
 #define ATL1_GET_DESC(R, i, type)  (&(((type *)((R)->desc))[i]))
 #define ATL1_RFD_DESC(R, i)ATL1_GET_DESC(R, i, struct rx_free_desc)
diff --git a/drivers/net/atl1/atl1_ethtool.c b/drivers/net/atl1/atl1_ethtool.c
index 8ce4d06..b7cd7b3 100644
--- a/drivers/net/atl1/atl1_ethtool.c
+++ b/drivers/net/atl1/atl1_ethtool.c
@@ -308,8 +308,8 @@ static void atl1_get_ringparam(struct net_device *netdev,
struct atl1_tpd_ring *txdr = >tpd_ring;
struct atl1_rfd_ring *rxdr = >rfd_ring;
 
-   ring->rx_max_pending = 2048;
-   ring->tx_max_pending = 1024;
+   ring->rx_max_pending = ATL1_MAX_RFD;
+   ring->tx_max_pending = ATL1_MAX_TPD;
ring->rx_mini_max_pending = 0;
ring->rx_jumbo_max_pending = 0;
ring->rx_pending = rxdr->count;
@@ -318,6 +318,79 @@ static void atl1_get_ringparam(struct net_device *netdev,
ring->rx_jumbo_pending = 0;
 }
 
+static int atl1_set_ringparam (struct net_device *netdev,
+   struct ethtool_ringparam *ring)
+{
+   struct atl1_adapter *adapter = netdev_priv(netdev);
+   struct atl1_tpd_ring *tpdr = >tpd_ring;
+   struct atl1_rrd_ring *rrdr = >rrd_ring;
+   struct atl1_rfd_ring *rfdr = >rfd_ring;
+
+   struct atl1_tpd_ring tpd_old, tpd_new;
+   struct atl1_rfd_ring rfd_old, rfd_new;
+   struct atl1_rrd_ring rrd_old, rrd_new;
+   struct atl1_ring_header rhdr_old, rhdr_new;
+   int err;
+
+   tpd_old = adapter->tpd_ring;
+   rfd_old = adapter->rfd_ring;
+   rrd_old = adapter->rrd_ring;
+   rhdr_old = adapter->ring_header;
+
+   if (netif_running(adapter->netdev))
+   atl1_down(adapter);
+
+   rfdr->count = (u16) max(ring->rx_pending, (u32) ATL1_MIN_RFD);
+   rfdr->count = rfdr->count > ATL1_MAX_RFD ? ATL1_MAX_RFD :
+   rfdr->count;
+   rfdr->count = (rfdr->count + 3) & ~3;
+   rrdr->count = rfdr->count;
+
+   tpdr->count = (u16) max(ring->tx_pending, (u32) ATL1_MIN_TPD);
+   tpdr->count = tpdr->count > ATL1_MAX_TPD ? ATL1_MAX_TPD :
+   tpdr->count;
+   tpdr->count = (tpdr->count + 3) & ~3;
+
+   if (netif_running(adapter->netdev)) {
+   /* try to get new resources before deleting old */
+   err = atl1_setup_ring_resources(adapter);
+   if (err)
+   goto err_setup_ring;
+
+   /*
+* save the new, restore the old in order to free it,
+* then restore the new back again
+*/
+
+   rfd_new = adapter->rfd_ring;
+   rrd_new = adapter->rrd_ring;
+   tpd_new = adapter->tpd_ring;
+   rhdr_new = adapter->ring_header;
+   adapter->rfd_ring = rfd_old;
+   adapter->rrd_ring = rrd_old;
+   adapter->tpd_ring = tpd_old;
+   adapter->ring_header = rhdr_old;
+   atl1_free_ring_resources(adapter);
+   adapter->rfd_ring = rfd_new;
+   adapter->rrd_ring = rrd_new;
+   adapter->tpd_ring = tpd_new;
+   adapter->ring_header = rhdr_new;
+
+   err = atl1_up(adapter);
+   if (err)
+   return err;
+   }
+   return 0;
+
+err_setup_ring:
+   adapter->rfd_ring = rfd_old;
+   adapter->rrd_ring = rrd_old;
+   adapter->tpd_ring = tpd_old;
+   adapter->ring_header = rhdr_old;
+   atl1_up(adapter);
+   return err;
+}
+
 static void atl1_get_pauseparam(struct net_device *netdev,
 struct ethtool_pauseparam *epause)
 {
@@ -417,6 +490,7 @@ const struct ethtool_ops atl1_ethtool_ops = {
.get_wol= atl1_get_wol,
.set_wol= atl1_set_wol,
.get_ringparam  = atl1_get_ringparam,
+   .set_ringparam  = atl1_set_ringparam,
.get_pauseparam = atl1_get_pauseparam,
.set_pauseparam = atl1_set_pauseparam,
.get_rx_csum  

[PATCH 2.6.20-rc7 1/2] atl1: get rid of pci_module_init

[Jay Cliburn]

From: Jay Cliburn <[EMAIL PROTECTED]>

pci_module_init is deprecated.  Use pci_register_driver instead.
Discovered by and modification suggested by Alan Cox.

Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---

 drivers/net/atl1/atl1_main.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 0afa9c1..793c43b 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -2461,12 +2461,9 @@ static void __exit atl1_exit_module(void)
  */
 static int __init atl1_init_module(void)
 {
-   int ret;
printk(KERN_INFO "%s - version %s\n", atl1_driver_string, 
DRIVER_VERSION);
printk(KERN_INFO "%s\n", atl1_copyright);
-   ret = pci_module_init(_driver);
-
-   return ret;
+   return pci_register_driver(_driver);
 }
 
 module_init(atl1_init_module);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Mark Lord]

Randy Dunlap wrote:

On Wed, 31 Jan 2007 18:00:15 -0500 Theodore Tso wrote:

..

More specifically, Dave said that it "seemed rude" to just take the
driver and send updates, but maybe the best way of dealing with
out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
kind of spec release, and just have someone in the community forcibly
take the code, fix it up, and then get it merged.  Maybe it's being
"rude", but so is not responding to requests to get it merged.


I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.

It's just not worth the effort/abuse for many maintainers to pursue it.


and I'm quite willing to apply Doc/CodingStyle to driver source file(s).
That's as easy as replying to an email with comments about it.


That's a very decent offer, and exactly what's needed here!

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

Re: [PATCH] libata: fix translation for START STOP UNIT

[Mark Lord]

Tejun Heo wrote:


A much better solution with thunderbird is using external editor
extension.

http://globs.org/articles.php?lng=en=2


Brilliant!  Installed, and now tested (the max_cmd_len patch posting).

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

Re: Linux 2.6.20-rc7

[Linus Torvalds]

On Thu, 1 Feb 2007, Nick Piggin wrote:
> 
> We could make them both unsigned, and _add_ everything to min rather than
> subtracting from free_pages?

Yeah, that's the right thing to do, probably. However, since we do that 
"min >>=1" thing, we'd have to do that to a separate "correction" factor 
(also unsigned).

No worth it for 2.6.20. I just reverted it. But feel free to send the 
fixed/updated micro-optimization after 2.6.20 has been released..

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

Re: [PATCH] procfs: Fix listing of /proc/NOT_A_TGID/task

[Eric W. Biederman]

Guillaume Chazarain <[EMAIL PROTECTED]> writes:

> Hi,
>
> I think this is 2.6.20 material, if it gets appropriately reviewed ;-)

Look good to me.

Lookup doesn't have this problem because it only tests for tgid.
I'm not certain at the moment if we need the rcu_read_lock,
and pid_alive checks, but at worst they are overkill.

> Thanks.
>
> -- 
> Guillaume
>
> Listing /proc/PID/task were PID is not a TGID
> should not result in duplicated entries.
>
> [g ~]$ pidof thunderbird-bin
> 2751
> [g ~]$ ls /proc/2751/task
> 2751  2770  2771  2824  2826  2834  2835  2851  2853
> [g ~]$ ls /proc/2770/task
> 2751  2770  2771  2824  2826  2834  2835  2851  2853
> 2770  2771  2824  2826  2834  2835  2851  2853
> [g ~]$ 
>
> Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
> ---
>
>  fs/proc/base.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff -r f99a8b402753 fs/proc/base.c
> --- a/fs/proc/base.c  Wed Jan 31 05:00:31 2007 +
> +++ b/fs/proc/base.c  Thu Feb 01 00:25:33 2007 +0100
> @@ -2328,13 +2328,23 @@ static int proc_task_readdir(struct file
>  {
>   struct dentry *dentry = filp->f_path.dentry;
>   struct inode *inode = dentry->d_inode;
> - struct task_struct *leader = get_proc_task(inode);
> + struct task_struct *leader = NULL;
>   struct task_struct *task;
>   int retval = -ENOENT;
>   ino_t ino;
>   int tid;
>   unsigned long pos = filp->f_pos; /* avoiding "long long" filp->f_pos */
>  
> + task = get_proc_task(inode);
> + if (!task)
> + goto out_no_task;
> + rcu_read_lock();
> + if (pid_alive(task)) {
> + leader = task->group_leader;
> + get_task_struct(leader);
> + }
> + rcu_read_unlock();
> + put_task_struct(task);
>   if (!leader)
>   goto out_no_task;
>   retval = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] barrier: a scalable synchonisation barrier

[Paul E. McKenney]

On Thu, Feb 01, 2007 at 01:03:09AM +0100, Peter Zijlstra wrote:
> On Wed, 2007-01-31 at 15:32 -0800, Paul E. McKenney wrote:
> 
> > The wakeup in barrier_sync() would mean that the counter was zero
> > at some point in the past.  The counter would then be rechecked, and
> > if it were still zero, barrier_sync() would invoke finish_wait() and
> > then return -- but the counter might well become non-zero in the
> > meantime, right?
> > 
> > So given that barrier_sync() is permitted to return after the counter
> > becomes non-zero, why can't it just rely on the fact that barrier_unlock()
> > saw it as zero not long in the past?
> > 
> > > >  It looks like barrier_sync() is more a
> > > > rw semaphore biased to readers.
> > > 
> > > Indeed, the locked sections are designed to be the rare case.
> > 
> > OK -- but barrier_sync() just waits for readers, it doesn't exclude them.
> > 
> > If all barrier_sync() needs to do is to wait until all pre-existing
> > barrier_lock()/barrier_unlock() pairs to complete, it seems to me to
> > be compatible with qrcu's semantics.
> > 
> > So what am I missing here?
> 
> I might be the one missing stuff, I'll have a hard look at qrcu.
> 
> The intent was that barrier_sync() would not write to memory when there
> are no active locked sections, so that the cacheline can stay shared,
> thus keeping is fast.
> 
> If qrcu does exactly this, then yes we have a match.

QRCU as currently written (http://lkml.org/lkml/2006/11/29/330) doesn't
do what you want, as it acquires the lock unconditionally.  I am proposing
that synchronize_qrcu() change to something like the following:

void synchronize_qrcu(struct qrcu_struct *qp)
{
int idx;

smp_mb();

if (atomic_read(qp->ctr[0]) + atomic_read(qp->ctr[1]) <= 1) {
smp_rmb();
if (atomic_read(qp->ctr[0]) +
atomic_read(qp->ctr[1]) <= 1)
goto out;
}

mutex_lock(>mutex);
idx = qp->completed & 0x1;
atomic_inc(qp->ctr + (idx ^ 0x1));
/* Reduce the likelihood that qrcu_read_lock() will loop */
smp_mb__after_atomic_inc();
qp->completed++;

atomic_dec(qp->ctr + idx);
__wait_event(qp->wq, !atomic_read(qp->ctr + idx));
mutex_unlock(>mutex);
out:
smp_mb();
}

For the first "if" to give a false positive, a concurrent switch had
to have happened.  For example, qp->ctr[0] was zero and qp->ctr[1]
was two at the time of the first atomic_read(), but then qp->completed
switched so that both qp->ctr[0] and qp->ctr[1] were one at the time
of the second atomic_read.  The only way the second "if" can give us a
false positive is if there was another change to qp->completed in the
meantime -- but that means that all of the pre-existing qrcu_read_lock()
holders must have gotten done, otherwise the second switch could not
have happened.  Yes, you do incur three memory barriers on the fast
path, but the best you could hope for with your approach was two of them
(unless I am confused about how you were using barrier_sync()).

Oleg, does this look safe?

Ugly at best, I know, but I do very much sympathize with Christoph's
desire to keep the number of synchronization primitives down to a
dull roar.  ;-)

Thanx, 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: Linux 2.6.20-rc7

[Nick Piggin]

Linus Torvalds wrote:


if (free_pages <= min + z->lowmem_reserve[classzone_idx])
return 0;

gets broken, because the negative 'free_pages' will look like a huge 
unsigned positive number (and we'll make it unsigned becaue 'min' got 
turned unsigned). There was a reason that thing was signed in the first 
place, and neither me nor Andrew noticed.


Bad Nick. And bad me and Andrew for not noticing.


Sorry. I think I even wrote that comment at the top of the function.
And probably the function as well :(

I should either revert that commit or just check for "free_pages" being 
negative. The latter, in many ways, is probably better, because generally 
we simply should never work with negative numbers in the kernel, so when 
something potentially goes negative, we're probably just better off always 
testing it explicitly anyway.


Nick, Andrew, any preferences? 


As Andrew says, it would need to be checked each time, because we have
nothing synchronising against free_pages at the top, or nr_free in the
loop.

We could make them both unsigned, and _add_ everything to min rather than
subtracting from free_pages?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


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

Re: Linux 2.6.20-rc7

[Linus Torvalds]

On Wed, 31 Jan 2007, Andrew Morton wrote:
> 
> It would be cleaner to check for negativity, but note that we keep
> subtracting stuff from free_pages in the later loop, so we'd need to check
> there as well.

Yeah, not worth it. I'll just revert it.

If we really want to do the micro-optimization that Nick was after, we can 
just do

// 'min' is always positive
min = (unsigned long) min >> 1;

or something.

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

RE: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump

[Patro, Sumant]

The patch is specific to kdump scenario.
What I see in the log is cmd timeout(s) and is not related to the patch.

--Sumant

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthias Urlichs
Sent: Wednesday, January 31, 2007 9:50 AM
To: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: megaraid_{mm,mbox} init fix for kdump

On Fri, 05 Jan 2007 07:10:09 -0800, Sumant Patro wrote:

> This command clears the pending commands in the adapter
> and re-initialize its internal RAID structure.
> Without this change, megaraid driver either panics or fails to
> initialize the adapter during kdump's second kernel boot
> if there are pending commands or interrupts from other devices
> sharing the same IRQ.

Nice. Is there a chance that this patch will also fix the regression
I've noticed (today, unfortunately) on (at least one) Dell server?

FWIW, here's the relevant LSPCI output and kernel logs:

0d:0e.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID (rev 07)
Subsystem: Dell Unknown device 0002
Flags: bus master, stepping, 66MHz, medium devsel, latency 64,
IRQ 18
Memory at d80f (32-bit, prefetchable) [size=64K]
Memory at fc4c (32-bit, non-prefetchable) [size=256K]
Expansion ROM at fc50 [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable-
Capabilities: [e0] PCI-X non-bridge device

Jan 31 14:41:34 kernel: [ 232.873327] megaraid cmm: 2.20.2.7 (Release
Date: Sun Jul 16 00:01:03 EST 2006) Jan 31 14:41:34 kernel: [
232.877616] SCSI subsystem initialized Jan 31 14:41:34 kernel: [
232.888779] megaraid: 2.20.4.9 (Release Date: Sun Jul 16 12:27:22 EST
2006) Jan 31 14:41:34 kernel: [ 232.889835] megasas: 00.00.03.05 Mon Oct
02 11:21:32 PDT 2006 Jan 31 14:41:34 kernel: [ 233.513659] megasas:
0x1028:0x0015:0x1028:0x1f03: <6>megaraid: probe new device
0x1000:0x0408:0x1028:0x0002: bus 13:slot 14:func 0 Jan 31 14:41:34
kernel: [ 233.514770] megasas: FW now in Ready state Jan 31 14:41:34
kernel: [ 233.528893] megaraid: fw version:[522A] bios version:[H430]
Jan 31 14:41:34 kernel: [ 233.554778] scsi2 : LSI Logic SAS based
MegaRAID driver Jan 31 14:41:34 kernel: [ 233.36] scsi 2:0:0:0:
Direct-Access MAXTOR ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34
kernel: [ 233.556173] scsi 2:0:1:0: Direct-Access MAXTOR
ATLAS10K5_073SAS BP00 PQ: 0 ANSI: 5 Jan 31 14:41:34 kernel: [
233.569337] scsi3 : LSI Logic MegaRAID driver Jan 31 14:41:34 kernel: [
233.569550] scsi[3]: scanning scsi channel 0 [Phy 0] for non-raid
devices Jan 31 14:41:34 kernel: [ 233.604522] scsi 2:0:8:0: Enclosure DP
BACKPLANE 1.00 PQ: 0 ANSI: 5 Jan 31 14:41:41 kernel: [ 243.115199]
megaraid: aborting-16 cmd=12  Jan 31 14:41:41 kernel: [
243.115206] megaraid abort: 16:0[0:12], fw owner Jan 31 14:41:41 kernel:
[ 243.115217] megaraid: 1 outstanding commands. Max wait 300 sec Jan 31
14:41:41 kernel: [ 243.115221] megaraid mbox: Wait for 1 commands to
complete:300 Jan 31 14:41:46 kernel: [ 248.125812] megaraid mbox: Wait
for 1 commands to complete:295 Jan 31 14:41:48 kernel: [ 250.134075]
megaraid mbox: reset sequence completed sucessfully Jan 31 14:41:58
kernel: [ 260.117201] megaraid: aborting-16 cmd=0 Jan 31
14:41:58 kernel: [ 260.117207] megaraid abort: 16:0[0:12], fw owner Jan
31 14:41:58 kernel: [ 260.117217] megaraid: 1 outstanding commands. Max
wait 300 sec Jan 31 14:41:58 kernel: [ 260.117223] megaraid mbox: Wait
for 1 commands to complete:300 Jan 31 14:42:03 kernel: [ 265.127417]
megaraid mbox: Wait for 1 commands to complete:295 Jan 31 14:42:08
kernel: [ 270.140211] megaraid mbox: Wait for 1 commands to complete:290
Jan 31 14:42:12 kernel: [ 274.146803] megaraid mbox: reset sequence
completed sucessfully [ nothing else that appears relevant ]


-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |
[EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. |
http://smurf.noris.de
 - -
Those who welcome death have only tried it from the ears up.
-- Wilson Mizner

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

Re: 2.6.20-rc6 ramdisk problem

[Thomas Gleixner]

On Wed, 2007-01-31 at 18:14 -0600, Robert Hancock wrote:
> > So either #1 or #2 should have failed in the first place. Failing in #3
> > is definitely a BUG in #1 or #2.
> > 
> > How does your advise help to fix that BUG ? Ignoring it by using
> > something else ?
> 
> Yes, there is likely a bug here of some sort. However, that doesn't 
> change the fact that ramdisks are sub-optimal for most uses.

You still did not answer my question: 
How does this deep insight help us to track down that BUG ?

Michal is actively testing the kernel and provides extremly useful
information about problems. He pointed out a bug and we want to fix it.
Adding special instructions, which are appropriate for a LUG
mailinglist, does us not get any further.

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: 2.6.20-rc6-mm3

[Christoph Lameter]

On Wed, 31 Jan 2007, Andrew Morton wrote:

> Actually, we might not have lost an IO: it could be that we're simply
> missing an unplug.  Are you able to unblock things by forcing some other IO
> against that queue?  Say, do a read from /dev/sda?

The system does not come up to a prompt. The traces were taken via NMI 
during bootup (shortly after udev came up).

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

Re: 2.6.20-rc6-mm3

[Andrew Morton]

On Wed, 31 Jan 2007 16:27:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Wed, 31 Jan 2007, Andrew Morton wrote:
> 
> > ow.  Please don't make me drop git-block-and-lots-of-other-things again.
> > Was 2.6.20-rc6-mm2 OK?  It didn't have git-block.
> 
> Yes, 2.6.20-rc6-mm2 was okay. Sorry.

OK, thanks.

Actually, we might not have lost an IO: it could be that we're simply
missing an unplug.  Are you able to unblock things by forcing some other IO
against that queue?  Say, do a read from /dev/sda?

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

Re: [PATCH 14/23] clocksource: increase initcall priority

[Thomas Gleixner]

On Wed, 2007-01-31 at 16:15 -0800, Daniel Walker wrote:
> > clocksource_initcall is simply superfluid. 
>
> My position has always been that clocksources should be registered as
> early as possible .. The fs_initcall() usage is a compromise stemming
> from early resistance that John, and you gave to moving the clocks up in
> the initcall sequence.

No. I never objected against the registering of clocks at any given
time. Why would I have otherwise accepted ARM patches, which register
their clocksources in the early timer init ?

The only concern I had and still have is when we decide to use something
else than the "safe" heaven of jiffies.

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: Linux 2.6.20-rc7

[Andrew Morton]

On Wed, 31 Jan 2007 16:19:06 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:

> I should either revert that commit or just check for "free_pages" being 
> negative. The latter, in many ways, is probably better, because generally 
> we simply should never work with negative numbers in the kernel, so when 
> something potentially goes negative, we're probably just better off always 
> testing it explicitly anyway.
> 
> Nick, Andrew, any preferences? 

It would be cleaner to check for negativity, but note that we keep
subtracting stuff from free_pages in the later loop, so we'd need to check
there as well.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] libata: fix translation for START STOP UNIT

[Tejun Heo]

Mark Lord wrote:
> Robert Hancock wrote:
>> I'd love to, but unfortunately nobody seems to have come up with a way
>> of doing this in Thunderbird that keeps it from mangling whitespace 
> 
> Yup, major nuisance.  I have to fire up Kmail whenever I'm posting patches,
> and then go back to Thunderbird again afterwards.

A much better solution with thunderbird is using external editor
extension.

http://globs.org/articles.php?lng=en=2

Install the extension.  Configure it with your favorite editor.
Thunderbird won't do a thing about your message if you turn off
linewrap.

 For example, this line starts with a tab and a space and (double tab)  
is very long and I'm writing in emacs fired up from thunderbird. 
(double space)  

Cheers.

-- 
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: 2.6.20-rc6-mm3

[Christoph Lameter]

On Wed, 31 Jan 2007, Andrew Morton wrote:

> ow.  Please don't make me drop git-block-and-lots-of-other-things again.
> Was 2.6.20-rc6-mm2 OK?  It didn't have git-block.

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

Re: 2.6.20-rc6-mm3

[Andrew Morton]

On Wed, 31 Jan 2007 16:14:10 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Mon, 29 Jan 2007, Andrew Morton wrote:
> 
> > - Restored git-block.patch: mainly the block unplugging rework.  The
> >   problematic CFQ updates have been taken out.
> 
> MD hung again as before so I compiled a kernel 
> without it. Next XFS started hanging during bootup.

ow.  Please don't make me drop git-block-and-lots-of-other-things again.
Was 2.6.20-rc6-mm2 OK?  It didn't have git-block.

> Some traces of processes hung but I do not have a clue as to what is 
> wrong here...:

Probably an IO got lost.

> Call Trace:
>  [] schedule+0x1bf0/0x1ec0
> sp=e0301560fac0 bsp=e03015608fc8
>  [] xfs_buf_iorequest+0x130/0x820
> sp=e0301560fbd0 bsp=e03015608f58
>  [] xfs_bdstrat_cb+0x60/0x100
> sp=e0301560fc00 bsp=e03015608f38
>  [] xfs_bwrite+0xe0/0x1e0
> sp=e0301560fc00 bsp=e03015608f00
>  [] xfs_syncsub+0x2c0/0x520
> sp=e0301560fc00 bsp=e03015608eb0
>  [] xfs_sync+0x70/0xa0
> sp=e0301560fc00 bsp=e03015608e88
>  [] vfs_sync+0xa0/0xc0
> sp=e0301560fc00 bsp=e03015608e58
>  [] xfs_fs_write_super+0x70/0xa0
> sp=e0301560fc00 bsp=e03015608e38
>  [] sync_supers+0x150/0x260
> sp=e0301560fc00 bsp=e03015608e08
>  [] wb_kupdate+0x60/0x280
> sp=e0301560fc00 bsp=e03015608dc8
>  [] pdflush+0x330/0x4e0
> sp=e0301560fc50 bsp=e03015608d90
>  [] kthread+0x220/0x2a0
> sp=e0301560fd50 bsp=e03015608d48
>  [] kernel_thread_helper+0xd0/0x100
> sp=e0301560fe30 bsp=e03015608d20
>  [] start_kernel_thread+0x20/0x40
> sp=e0301560fe30 bsp=e03015608d20
>   
>
> Call Trace:
>  [] schedule+0x1bf0/0x1ec0
> sp=e1b03869f8b0 bsp=e1b038699618
>  [] schedule_timeout+0x40/0x180
> sp=e1b03869f9c0 bsp=e1b0386995e0
>  [] _xfs_log_force+0x500/0x5c0
> sp=e1b03869f9f0 bsp=e1b038699580
>  [] xfs_alloc_search_busy+0x190/0x1e0
> sp=e1b03869fa20 bsp=e1b038699538
>  [] xfs_alloc_ag_vextent+0x2250/0x2420
> sp=e1b03869fa20 bsp=e1b0386994a8
>  [] xfs_alloc_vextent+0x690/0x9c0
> sp=e1b03869fa60 bsp=e1b038699428
>  [] xfs_bmapi+0x1e00/0x33a0
> sp=e1b03869fa60 bsp=e1b0386992d8
>  [] xfs_iomap_write_allocate+0x3f0/0x760
> sp=e1b03869fba0 bsp=e1b038699248
>  [] xfs_iomap+0x670/0xb00
> sp=e1b03869fc30 bsp=e1b0386991d0
>  [] xfs_bmap+0x40/0x60
> sp=e1b03869fc80 bsp=e1b038699188
>  [] xfs_map_blocks+0xa0/0x120
> sp=e1b03869fc80 bsp=e1b038699148
>  [] xfs_page_state_convert+0x540/0x1a40
> sp=e1b03869fc90 bsp=e1b038699080
>  [] xfs_vm_writepage+0x180/0x220
> sp=e1b03869fd50 bsp=e1b038699040
>  [] generic_writepages+0x420/0x800
> sp=e1b03869fd60 bsp=e1b038698fc0
>  [] xfs_vm_writepages+0x90/0xc0
> sp=e1b03869fdf0 bsp=e1b038698f88
>  [] do_writepages+0xb0/0x120
> sp=e1b03869fdf0 bsp=e1b038698f58
>  [] __filemap_fdatawrite_range+0xb0/0xe0
> sp=e1b03869fdf0 bsp=e1b038698f20
>  [] filemap_fdatawrite+0x40/0x60
> sp=e1b03869fe30 bsp=e1b038698f00
>  [] fs_flush_pages+0xc0/0x100
> sp=e1b03869fe30 bsp=e1b038698eb8
>  [] xfs_close+0x190/0x1e0
> sp=e1b03869fe30 bsp=e1b038698e80
>  [] xfs_file_close+0xa0/0xc0
> sp=e1b03869fe30 bsp=e1b038698e60
>  [] filp_close+0xd0/0x140
> sp=e1b03869fe30 bsp=e1b038698e30
>  [] sys_close+0x140/0x1e0
> sp=e1b03869fe30 bsp=e1b038698db0
>  [] ia64_ret_from_syscall+0x0/0x20
> sp=e1b03869fe30 bsp=e1b038698db0
>  [] __kernel_syscall_via_break+0x0/0x20
> sp=e1b0386a bsp=e1b038698db0
-
To unsubscribe from this list: send the line "unsubscribe 

[ANNOUNCE] GIT 1.5.0-rc3

[Junio C Hamano]

It's been a week and a half, and here comes the -rc3

  http://www.kernel.org/pub/software/scm/git/

  git-1.5.0-rc3.tar.{gz,bz2}(tarball)
  git-htmldocs-1.5.0-rc3.tar.{gz,bz2}   (preformatted docs)
  git-manpages-1.5.0-rc3.tar.{gz,bz2}   (preformatted docs)
  testing/git-*-1.5.0-rc3-1.$arch.rpm   (RPM)

Hopefully this will be the last -rc before the final 1.5.0.

This contains the "git user's manual" by J. Bruce Fields.  While
it still has its own "To Do" section, it has already been in a
very good shape for some time, giving information with coherence
and guiding a new user in a carefully chosen order of topics
into much more pleasant git experience than before.



Changes since v1.5.0-rc2 are as follows:

Alex Riesen (5):
  Insert ACTIVESTATE_STRING in Git.pm
  Force Activestate Perl to tie git command pipe handle to a handle class
  Cleanup uninitialized value in chomp
  Allow default core.logallrefupdates to be overridden with template's config
  Fix git-update-index to work with relative pathnames.

Alexandre Julliard (1):
  vc-git.el: Take into account the destination name in vc-checkout.

Andy Parkins (5):
  New files in git weren't being downloaded during CVS update
  If abbrev is set to zero in git-describe, don't add the unique suffix
  Allow the tag signing key to be specified in the config file
  UNIX reference time of 1970-01-01 00:00 is UTC timezone, not local time zone
  Heavily expanded update hook to send more useful emails than the old hook

Aneesh Kumar K.V (2):
  blameview: Use git-cat-file to read the file content.
  Update git-cat-file documentation

Bill Lear (1):
  Document --check option to git diff.

David Kågedal (1):
  Improved error message from git-rebase

Eric Wong (1):
  git-svn: remove leading slash when printing removed directories

J. Bruce Fields (31):
  Documentation: add git user's manual
  Documentation: expand preface and todo's
  Documentation: git-rebase discussion, miscellaneous user-manual updates
  Documentation: more user-manual todo's
  Documentation: reorder development section, todo's
  Documentation: begin discussion of git-remote in user manual
  Documentation: rev-list -> rev-parse, other typos, start examples
  user manual: answer some comments from Junio
  user-manual: replace init-db by init
  user-manual: reindent
  user-manual:  rewrap, fix heading levels
  user-manual: add "quick start" as chapter 1
  user-manual: minor quickstart reorganization
  user-manual: clarify difference between tag and branch
  user-manual: update references discussion
  user-manual: update git-gc discussion
  user-manual: stub discussion of fsck and reflog
  user-manual: reorganize fetch discussion, add internals, etc.
  user-manual: git-fsck, dangling objects
  user-manual: fsck-objects -> fsck
  user-manual: repo-config -> config
  user-manual: add references to git-config man page
  user-manual: typo fix
  user-manual: fix a header level
  user-manual: reflogs, other recovery
  user-manual: rewrap a few long lines
  user-manual: minor "TODO" updates
  user-manual: document git-show-branch example
  user-manual: SHA1 -> object name
  user-manual: point to README for gitweb information
  user-manual: todo's

Jakub Narebski (3):
  Documentation/config.txt: Document config file syntax better
  t/t1300-repo-config.sh: value continued on next line
  Documentation/config.txt: Correct info about subsection name

Jason Riedy (1):
  Use inttypes.h rather than stdint.h.

Jeff King (4):
  format-patch: fix bug with --stdout in a subdirectory
  contrib/vim: update syntax for changed commit template
  diffcore-pickaxe: fix infinite loop on zero-length needle
  Add a sample program 'blameview' to show how to use git-blame --incremental

Johannes Schindelin (2):
  annotate: use pager
  reflog inspection: introduce shortcut "-g"

Johannes Sixt (1):
  Add a missing fork() error check.

Junio C Hamano (43):
  User manual: fix typos in examples
  Documentation/tutorial-2: Fix interesting typo in an example.
  Revert "prune: --grace=time"
  Make sure git_connect() always give two file descriptors.
  is_repository_shallow(): prototype fix.
  shallow repository: disable unsupported operations for now.
  git-gc: do not run git-prune by default.
  cvsimport: activate -a option, really.
  .mailmap: fix screw-ups in Uwe's name
  honor --author even with --amend, -C, and -c.
  reflog gc: a tag that does not point at a commit is not a crime.
  git-checkout -m: fix merge case
  git-daemon documentation on enabling services.
  ls-remote and clone: accept --upload-pack= as well.
  Refactor the pack header reading function out of receive-pack.c
  Allow fetch-pack to decide keeping the fetched pack without exploding
  fetch-pack: remove --keep-auto and make it the default.
  Consolidate {receive,fetch}.unpackLimit
  Allow non-developer to clone, checkout and fetch more easily.
  parse-remote: do 

Re: [PATCH 14/23] clocksource: increase initcall priority

[David Brownell]

On Wednesday 31 January 2007 2:47 pm, Daniel Walker wrote:
> On Wed, 2007-01-31 at 11:43 -0800, David Brownell wrote:
> > > As a note, arm and mips both register their clocksources during
> > > time_init() instead of using initcalls.
> > 
> > That's actually platform-specific.  ...
> > 
> > So don't assume any platform doesn't use clocksource initcalls.
> 
> What does your OMAP clocksource do now ? 

OMAP being one family of ARMs ... well, maybe a few families
under the same branding umbrella.


>   I thought one of the changes 
> that you made was to have both 32k and mpu both registered ..

Some OMAP1 chips will do that, if the MPU timer is configured *AND*
they have that 32K counter register.  Not OMAP2 (which doesn't have
MPU timers), and not the older OMAP1 chips (no 32K counter).

It turned out to be simpler to do it that way.  Otherwise the
configuration options get too confusing.  There are three types
of timer (MPU timers on most OMAP1 systems, 32K timer on some, dual
mode timers on newer chips including OMAP2) that can generate ticks.

In some cases, another of those timers wil also be used in free
run mode as a clocksource.  That 32K counter isn't a timer, but
it's a fine clocksource (if present).  But until clockevents go
upstream, it's kind of pointless to factor it all differently.

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

Re: Linux 2.6.20-rc7

[Linus Torvalds]

On Thu, 1 Feb 2007, PaweÅ Sikora wrote:
> 
> 2.6.18 works, 2.6.19-rc1 doesn't work.
> git bisect found this bad commit:

Git bisect rocks.

I'll give myself yet abother pat on the back for writing it. You can never 
encourage genius like that too much.

> commit e80ee884ae0e3794ef2b65a18a767d502ad712ee
> Author: Nick Piggin <[EMAIL PROTECTED]>
> Date:   Wed Oct 4 02:15:23 2006 -0700
> 
> [PATCH] mm: micro optimise zone_watermark_ok
>
> reverting mentioned commit removes the oops.

Ok, that commit is just totally broken.

If "free_pages" turns negative (which it can, since it's just doing a

long free_pages = z->free_pages - (1 << order) + 1;

to initialize it, and for all we know, you have an empty or close-to-empty 
zone or two, the whole test to do

if (free_pages <= min + z->lowmem_reserve[classzone_idx])
return 0;

gets broken, because the negative 'free_pages' will look like a huge 
unsigned positive number (and we'll make it unsigned becaue 'min' got 
turned unsigned). There was a reason that thing was signed in the first 
place, and neither me nor Andrew noticed.

Bad Nick. And bad me and Andrew for not noticing.

I should either revert that commit or just check for "free_pages" being 
negative. The latter, in many ways, is probably better, because generally 
we simply should never work with negative numbers in the kernel, so when 
something potentially goes negative, we're probably just better off always 
testing it explicitly anyway.

Nick, Andrew, any preferences? 

Linus

Re: Linux 2.6.20-rc7

[Andrew Morton]

On Thu, 1 Feb 2007 00:37:48 +0100
Pawe__ Sikora <[EMAIL PROTECTED]> wrote:

> On Wednesday 31 of January 2007 17:04:29 Linus Torvalds wrote:
> > On Wed, 31 Jan 2007, Pawe__ Sikora wrote:
> > > The 2.6.20-rcX have the same nasty bug as 2.6.19.x.
> > >
> > > [ an oops inside kmem_get_pages ]
> > > http://bugzilla.kernel.org/show_bug.cgi?id=7889
> >
> > Pabel, can you detail more exactly which kernels don't work, and which do?
> 
> 2.6.18 works, 2.6.19-rc1 doesn't work.
> git bisect found this bad commit:
> 
> commit e80ee884ae0e3794ef2b65a18a767d502ad712ee
> Author: Nick Piggin <[EMAIL PROTECTED]>
> Date:   Wed Oct 4 02:15:23 2006 -0700
> 
> [PATCH] mm: micro optimise zone_watermark_ok
> 
> Having min be a signed quantity means gcc can't turn high latency divides
> into shifts.  There happen to be two such divides for GFP_ATOMIC (ie.
> networking, ie.  important) allocations, one of which depends on the 
> other.
>  Fixing this makes code smaller as a bonus.
> 
> Shame on somebody (probably me).
> 
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> 
> - mm/page_alloc.c ---
> @@ -900,7 +900,8 @@ int zone_watermark_ok(struct zone *z, int order, unsigned 
> long mark,
> int classzone_idx, int alloc_flags)
>  {
>   /* free_pages my go negative - that's OK */
> - long min = mark, free_pages = z->free_pages - (1 << order) + 1;
> + unsigned long min = mark;
> + long free_pages = z->free_pages - (1 << order) + 1;
>   int o;
> 
>   if (alloc_flags & ALLOC_HIGH)
> 
> 
> > Apparently it only happens with MEMORY_HOTPLUG (and possibly with just an
> > SMP kernel on UP), which probably explains why it's been around without
> > people really complaining very loudly.
> 
> reverting mentioned commit removes the oops.
> 

urgh.  zone->free_pages is very small - probably zero.  We shouldn't have
got here at all, so something else is wrong.

But local `free_pages' can go negative in normal operation.  I guess
that'll cause us to incorrectly return `true' from zone_watermark_ok, thus
ignoring the watermarks.

The below, I guess.  But we still don't know why this got called against an
empty zone.




Subject: zone_watermark_ok: signedness fix
From: Andrew Morton <[EMAIL PROTECTED]>

Local `free_pages' can go negative in normal operation.  I guess that'll cause
us to incorrectly return `true' from zone_watermark_ok, thus ignoring the
watermarks.

Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 mm/page_alloc.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN mm/page_alloc.c~zone_watermark_ok-signedness-fix mm/page_alloc.c
--- a/mm/page_alloc.c~zone_watermark_ok-signedness-fix
+++ a/mm/page_alloc.c
@@ -1013,7 +1013,7 @@ int zone_watermark_ok(struct zone *z, in
  int classzone_idx, int alloc_flags)
 {
/* free_pages my go negative - that's OK */
-   unsigned long min = mark;
+   long min = mark;
long free_pages = zone_page_state(z, NR_FREE_PAGES)
- (1 << order) + 1;
int o;
_

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

Re: [PATCH 14/23] clocksource: increase initcall priority

[Daniel Walker]

On Thu, 2007-02-01 at 00:23 +0100, Thomas Gleixner wrote:
> Daniel,
> 
> On Wed, 2007-01-31 at 14:47 -0800, Daniel Walker wrote:
> > > So don't assume any platform doesn't use clocksource initcalls.
> > 
> > What does your OMAP clocksource do now ? I thought one of the changes
> > that you made was to have both 32k and mpu both registered ..
> 
> It is up to the clocksource driver, when the clocksource_register() call
> is done. This may happen in early boot as well as after initializing
> some other things first.
> 
> Johns clocksource code works with ARM which does the register call in
> timer_init() as well as with some other hardware which gets initialized
> late in the boot process.
> 
> clocksource_initcall is simply superfluid. 
> 


My position has always been that clocksources should be registered as
early as possible .. The fs_initcall() usage is a compromise stemming
from early resistance that John, and you gave to moving the clocks up in
the initcall sequence. the clocksource_initcall() exists only to allow
the clocks easily be raised if it was needed ..

I'm glad that you, John, and myself have come to a consensus on the
issue offline ..

Daniel 

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

Re: 2.6.20-rc6 ramdisk problem

[Robert Hancock]

Thomas Gleixner wrote:

On Wed, 2007-01-31 at 17:54 -0600, Robert Hancock wrote:
I'm not sure if there's an inherent max ramdisk size limit, however I 
should point out that in most cases, using a tmpfs or ramfs file system 
is better than old-style ramdisks. Those filesystems return unused 
memory to the kernel (ramdisks statically allocate the entire space) and 
also avoid the filesystem overhead of ramdisks (the files are mapped 
into pagecache directly).


This is not a question of what's better or not. 


Michal stepped into a real life problem:

1. ramdisk gets created in the first place w/o problems
2. formatting the same ramdisk succeeds
3. trying to use it fails

So either #1 or #2 should have failed in the first place. Failing in #3
is definitely a BUG in #1 or #2.

How does your advise help to fix that BUG ? Ignoring it by using
something else ?


Yes, there is likely a bug here of some sort. However, that doesn't 
change the fact that ramdisks are sub-optimal for most uses.


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


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

Re: 2.6.20-rc6-mm3

[Christoph Lameter]

On Mon, 29 Jan 2007, Andrew Morton wrote:

> - Restored git-block.patch: mainly the block unplugging rework.  The
>   problematic CFQ updates have been taken out.

MD hung again as before so I compiled a kernel 
without it. Next XFS started hanging during bootup.

Some traces of processes hung but I do not have a clue as to what is 
wrong here...:

Call Trace:
 [] schedule+0x1bf0/0x1ec0
sp=e0301560fac0 bsp=e03015608fc8
 [] xfs_buf_iorequest+0x130/0x820
sp=e0301560fbd0 bsp=e03015608f58
 [] xfs_bdstrat_cb+0x60/0x100
sp=e0301560fc00 bsp=e03015608f38
 [] xfs_bwrite+0xe0/0x1e0
sp=e0301560fc00 bsp=e03015608f00
 [] xfs_syncsub+0x2c0/0x520
sp=e0301560fc00 bsp=e03015608eb0
 [] xfs_sync+0x70/0xa0
sp=e0301560fc00 bsp=e03015608e88
 [] vfs_sync+0xa0/0xc0
sp=e0301560fc00 bsp=e03015608e58
 [] xfs_fs_write_super+0x70/0xa0
sp=e0301560fc00 bsp=e03015608e38
 [] sync_supers+0x150/0x260
sp=e0301560fc00 bsp=e03015608e08
 [] wb_kupdate+0x60/0x280
sp=e0301560fc00 bsp=e03015608dc8
 [] pdflush+0x330/0x4e0
sp=e0301560fc50 bsp=e03015608d90
 [] kthread+0x220/0x2a0
sp=e0301560fd50 bsp=e03015608d48
 [] kernel_thread_helper+0xd0/0x100
sp=e0301560fe30 bsp=e03015608d20
 [] start_kernel_thread+0x20/0x40
sp=e0301560fe30 bsp=e03015608d20

 
Call Trace:
 [] schedule+0x1bf0/0x1ec0
sp=e1b03869f8b0 bsp=e1b038699618
 [] schedule_timeout+0x40/0x180
sp=e1b03869f9c0 bsp=e1b0386995e0
 [] _xfs_log_force+0x500/0x5c0
sp=e1b03869f9f0 bsp=e1b038699580
 [] xfs_alloc_search_busy+0x190/0x1e0
sp=e1b03869fa20 bsp=e1b038699538
 [] xfs_alloc_ag_vextent+0x2250/0x2420
sp=e1b03869fa20 bsp=e1b0386994a8
 [] xfs_alloc_vextent+0x690/0x9c0
sp=e1b03869fa60 bsp=e1b038699428
 [] xfs_bmapi+0x1e00/0x33a0
sp=e1b03869fa60 bsp=e1b0386992d8
 [] xfs_iomap_write_allocate+0x3f0/0x760
sp=e1b03869fba0 bsp=e1b038699248
 [] xfs_iomap+0x670/0xb00
sp=e1b03869fc30 bsp=e1b0386991d0
 [] xfs_bmap+0x40/0x60
sp=e1b03869fc80 bsp=e1b038699188
 [] xfs_map_blocks+0xa0/0x120
sp=e1b03869fc80 bsp=e1b038699148
 [] xfs_page_state_convert+0x540/0x1a40
sp=e1b03869fc90 bsp=e1b038699080
 [] xfs_vm_writepage+0x180/0x220
sp=e1b03869fd50 bsp=e1b038699040
 [] generic_writepages+0x420/0x800
sp=e1b03869fd60 bsp=e1b038698fc0
 [] xfs_vm_writepages+0x90/0xc0
sp=e1b03869fdf0 bsp=e1b038698f88
 [] do_writepages+0xb0/0x120
sp=e1b03869fdf0 bsp=e1b038698f58
 [] __filemap_fdatawrite_range+0xb0/0xe0
sp=e1b03869fdf0 bsp=e1b038698f20
 [] filemap_fdatawrite+0x40/0x60
sp=e1b03869fe30 bsp=e1b038698f00
 [] fs_flush_pages+0xc0/0x100
sp=e1b03869fe30 bsp=e1b038698eb8
 [] xfs_close+0x190/0x1e0
sp=e1b03869fe30 bsp=e1b038698e80
 [] xfs_file_close+0xa0/0xc0
sp=e1b03869fe30 bsp=e1b038698e60
 [] filp_close+0xd0/0x140
sp=e1b03869fe30 bsp=e1b038698e30
 [] sys_close+0x140/0x1e0
sp=e1b03869fe30 bsp=e1b038698db0
 [] ia64_ret_from_syscall+0x0/0x20
sp=e1b03869fe30 bsp=e1b038698db0
 [] __kernel_syscall_via_break+0x0/0x20
sp=e1b0386a bsp=e1b038698db0


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

Re: Free Linux Driver Development!

[Trent Waddington]

On 2/1/07, Greg KH <[EMAIL PROTECTED]> wrote:

No, I'm going by Linus's rule here, if a person doesn't want their code
in the kernel tree, then I'm not going to forcefully put it there.
That's just being rude.


Makes sense when you put it that way.  However, perhaps an offer to
take over the maintenance of the driver when incorporating it into the
kernel tree would be welcomed more readily by some people than just
"so when ya gunna merge?" style badgering.

Not that I'm not a fan of badgering.

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

Re: Oops on serial access on kernel 2.6.16.38

[Frederik Deweerdt]

On Tue, Jan 30, 2007 at 12:55:49PM +, Jose Goncalves wrote:
> Jose Goncalves wrote:
> > Frederik Deweerdt wrote:
> >   
> >> On Fri, Jan 26, 2007 at 06:17:03PM +, Jose Goncalves wrote:
> >>   
> >> 
> >>> Frederik Deweerdt wrote:
> >>> 
> >>>   
>  On Fri, Jan 26, 2007 at 03:50:25PM +, Jose Goncalves wrote:
>    
>    
>  
> > I'm having a problem with the latest 2.6.16 kernel (I've found the
> > problem on 2.6.16.37 and 2.6.16.38). I have a application that retreives
> > data from a GPS connected on a serial port. From time to time a get a
> > kernel Oops, like this:
> >
> > 
> > 
> >   
>  Could you send your .config?
>    
>    
>  
> >>> Here it goes...
> >>>
> >>> 
> >>>   
> >> Thanks. It looks like something is wrong with port->ops->startup() in
> >> uart_startup(), could you apply the following patch and report the
> >> results? And btw, you're using a plain 8250 serial port, isn't it?
> >>   
> >> 
> >
> > OK. I've applied the patch and I'm now waiting for the kernel Oops...
> > sometimes it takes two days until it happens.
> > I'm using a standard 16550A serial controller found on my hardware, that
> > is a PC/104 SBC:
> >
> >  http://www.icop.com.tw/products_detail.asp?ProductID=70
> >
> > We have a custom hardware that has another serial controller (TL16C554A)
> > with 4 extra serial ports (also, 16550A type), and the problem happens
> > in a test program that is retreiving data from ttyS0 (from the SBC) and
> > ttyS3 (from our custom hardware).
> > The serial ports initialization, as reported by the kernel:
> >
> > [   15.216847] Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ
> > sharing disabled
> > [   15.219517] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> > [   15.221963] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> > [   15.223907] serial8250: ttyS2 at I/O 0x3e8 (irq = 5) is a 16550A
> > [   15.225757] serial8250: ttyS3 at I/O 0x2e8 (irq = 5) is a 16550A
> > [   15.227644] serial8250: ttyS4 at I/O 0x1a0 (irq = 6) is a 16550A
> > [   15.229656] serial8250: ttyS5 at I/O 0x1a8 (irq = 6) is a 16550A
> >
> > With your patch I'm now getting the following for each iteration of my
> > test program:
> >
> > <4>[  298.918962] type is 4
> > <4>[  298.919011] ops is c0292f00
> > <4>[  298.919033] ops->startup is c01bd777
> > <4>[  299.436980] type is 4
> > <4>[  299.437030] ops is c0292f00
> > <4>[  299.437051] ops->startup is c01bd777
> >
> > I don't know if it's relevant or not but the kernel is running in
> > NFS-Root mode.
> >   
> I've had a new kernel Oops with your patch applied:
> 
> <4>[35769.361941] type is 4
> <4>[35769.361994] ops is c0292f00
> <4>[35769.362016] ops->startup is c01bd777
> <4>[35769.958983] type is 4
> <4>[35769.959038] ops is c0292f00
> <4>[35769.959060] ops->startup is c01bd777
> <1>[35769.959201] Unable to handle kernel NULL pointer dereference at
> virtual address 
> <1>[35769.966797]  printing eip:
> <4>[35769.974265] 
> <1>[35769.974296] *pde = 
> <0>[35769.981814] Oops:  [#1]
> <4>[35769.989367] Modules linked in:
> <0>[35769.996955] CPU:0
> <4>[35769.996974] EIP:0060:[<>]Not tainted VLI
> <4>[35769.996990] EFLAGS: 00010202   (2.6.16.38-mtm4-debug2 #1)
> <0>[35770.020533] EIP is at rest_init+0x3feffdc0/0x1e
> <0>[35770.029044] eax: 0060   ebx:    ecx:    edx:
> 02fd
> <0>[35770.038017] esi:    edi: 0040   ebp: 0202   esp:
> c72e9e34
> <0>[35770.047118] ds: 007b   es: 007b   ss: 0068
> <0>[35770.056257] Process gp_position (pid: 15013, threadinfo=c72e8000
> task=c11a15a0)
> <0>[35770.057042] Stack: <0>c02fae70 0005 c02fae70 c77f6de0 c12815e4
> c77714e0 c01ba4c4 c02fae70
> <0>[35770.077407]c025f18a c01bd777 c025f17f c0292f00 c025f173
> 0004 c12815e4 
> <0>[35770.089263]c77714e0 c77714e0 c01bbacc c12815e4 
> ffed c77714e0 0100
> <0>[35770.101473] Call Trace:
> <0>[35770.113147]  [] uart_startup+0x8d/0x120
> <0>[35770.125473]  [] serial8250_startup+0x0/0x2a5
> <0>[35770.138071]  [] uart_open+0xaa/0xec
> <0>[35770.150859]  [] tty_open+0x16c/0x270
> <0>[35770.163665]  [] chrdev_open+0xd7/0xf0
> <0>[35770.176636]  [] chrdev_open+0x0/0xf0
> <0>[35770.189587]  [] __dentry_open+0xb4/0x180
> <0>[35770.202755]  [] nameidata_to_filp+0x1f/0x31
> <0>[35770.216107]  [] do_filp_open+0x37/0x3f
> <0>[35770.229554]  [] __fput+0x11e/0x126
> <0>[35770.242947]  [] strncpy_from_user+0x2e/0x4c
> <0>[35770.256773]  [] get_unused_fd+0x4c/0x91
> <0>[35770.270556]  [] do_sys_open+0x40/0xb5
> <0>[35770.284545]  [] sys_open+0x13/0x17
> <0>[35770.298620]  [] syscall_call+0x7/0xb
> <0>[35770.312965] Code:  Bad EIP value.
> <4>[35770.357131]  type is 4
> <4>[35775.528001] ops is c0292f00
> <4>[35775.541519] ops->startup is c01bd777
> 
Duh, not what I expected :(. is there a way that I could get 

[PATCH 1/1] filesystem: Disk Errors at boot-time caused by probe of partitions

[TJ]

From: TJ <[EMAIL PROTECTED]>

Applies to: up-to and including 2.6.20-rc7 

This rare but critical bug has the potential to cause a hardware failure on 
disk drives by
allowing the system to repeatedly attempt to seek to sectors beyond the end of 
the physical
disk, causing sustained 'head banging'.

The bug particularly affects dmraid-managed RAID 1 stripes of the type hde+hdf 
where the
first physical disk hde contains a standard partition table which relates to 
the larger
logical disk represented by hde+hdf.

The essence is that probing of physical disks that are part of a larger logical 
disk
should be prevented because those disks will be managed by a driver that loads 
later in the
boot sequence.
This patch doesn't prevent probing of disks with 'sane' partition table entries.

At boot-time when drives are being probed the disks are scanned for partition 
tables by
fs/partitions/check.c:check_partition() which makes calls to all registered 
partition-types.

In the case of the commonly used "msdos" partition-type used for Linux, BSD, 
Solaris, MS-DOS,
extended and others, the checking is done in

fs/partitions/msdos.c:msdos_partition().

The partition table is only checked for validity based on the 'magic bytes' 
55AA in the boot
sector. The sector values in the partition table are copied without any checks 
to ensure they
are within the bounds of the disk device. 

As a result, block devices are created based on the partition structures and 
then various
file-systems are given the task of scanning the partition to determine if it is 
one they will
manage.

This scanning, in a partition that has sector numbers outside the bounds of the 
device, causes
the errors.

Signed-off-by: TJ <[EMAIL PROTECTED]>
---

I'm not sure if this bug will affect mdraid RAID-1 stripes, or other software
RAID configurations.

The bug was discovered on a RAID 1+0 array consisting of 4x60GB drives on a
Promise FastTrak PDC20271 2-channel IDE controller (hde+hdf mirrored to hdg+hdh)
with logical block addressing (LBA).

There are 3 prolonged periods of disk-probing each lasting about 20 seconds
during which the 'head banging' is quite scary. The first two occur during the
kernel boot, and the last will occur when a GUI environment such as Gnome
initialises.

In the system where this bug appeared this caused thousands of disk-read errors
during boot (which overflowed dmesg log), and 'head bangs' the drive(s) so hard
that sometimes the system has to be powered off for a considerable time before
the disk(s) will re-initialise.

--- fs/partitions/msdos.c   2006-11-29 21:57:37.0 +
+++ fs/partitions/msdos.tj.c2007-01-31 23:39:09.0 +
@@ -399,6 +399,79 @@ static struct {
{NEW_SOLARIS_X86_PARTITION, parse_solaris_x86},
{0, NULL},
 };
+
+/* 
+ * Check that *all* sector offsets are valid before actually building the 
partition structure.
+ *
+ * This prevents physical damage to disks and boot-time problems caused by an 
apparently valid
+ * partition table causing attempts to read sectors beyond the end of the 
physical disk.
+ *
+ * This is especially important where this is the first physical disk in a 
striped RAID array
+ * and the partition table contains sector offsets into the larger logical 
disk (beyond the end
+ * of this physical disk).
+ *
+ * The RAID module will correctly manage the disks.
+ *
+ * The function is re-entrant so it can call itself to check extended 
partitions.
+ * 
+ * @param p partition table
+ * @param bdev block device
+ * @returns -1 if insane values found; 0 otherwise
+ * @copy Copyright 31 January 2007
+ * @author TJ <[EMAIL PROTECTED]>
+ */ 
+int check_sane_values(struct partition *p, struct block_device *bdev) {
+   unsigned char *data;
+   struct partition *ext;
+   Sector sect;
+   int slot;
+   int insane;
+   int sector_size = bdev_hardsect_size(bdev) / 512;
+   int ret = 0; /* default is to report ok */
+
+   /* don't return early; allow all partition entries to be checked */
+   for (slot = 1 ; slot <= 4 ; slot++, p++) { 
+   insane = 0; /* track sanity within each table entry */
+
+   if (NR_SECTS(p) == 0)
+   continue; /* ignore zero-sized entries */
+
+   if (START_SECT(p) > bdev->bd_disk->capacity-1) { /* invalid - 
beyond end of disk */
+   insane |= 1; /* bit-0 flags insane start */
+   }
+   if (START_SECT(p)+NR_SECTS(p)-1 > bdev->bd_disk->capacity-1) { 
/* invalid - beyond end of disk */
+   insane |= 2; /* bit-1 flags insane end */
+   }
+   if (!insane && is_extended_partition(p)) { /* check the 
extended partition */
+   data = read_dev_sector(bdev, START_SECT(p)*sector_size, 
); /* fetch sector from cache */
+   if (data) {
+   if (msdos_magic_present(data + 510)) { /* check 
for signature 

Re: 2.6.20-rc6 ramdisk problem

[Thomas Gleixner]

On Wed, 2007-01-31 at 17:54 -0600, Robert Hancock wrote:
> I'm not sure if there's an inherent max ramdisk size limit, however I 
> should point out that in most cases, using a tmpfs or ramfs file system 
> is better than old-style ramdisks. Those filesystems return unused 
> memory to the kernel (ramdisks statically allocate the entire space) and 
> also avoid the filesystem overhead of ramdisks (the files are mapped 
> into pagecache directly).

This is not a question of what's better or not. 

Michal stepped into a real life problem:

1. ramdisk gets created in the first place w/o problems
2. formatting the same ramdisk succeeds
3. trying to use it fails

So either #1 or #2 should have failed in the first place. Failing in #3
is definitely a BUG in #1 or #2.

How does your advise help to fix that BUG ? Ignoring it by using
something else ?

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 3/7] barrier: a scalable synchonisation barrier

[Peter Zijlstra]

On Wed, 2007-01-31 at 15:32 -0800, Paul E. McKenney wrote:

> The wakeup in barrier_sync() would mean that the counter was zero
> at some point in the past.  The counter would then be rechecked, and
> if it were still zero, barrier_sync() would invoke finish_wait() and
> then return -- but the counter might well become non-zero in the
> meantime, right?
> 
> So given that barrier_sync() is permitted to return after the counter
> becomes non-zero, why can't it just rely on the fact that barrier_unlock()
> saw it as zero not long in the past?
> 
> > >  It looks like barrier_sync() is more a
> > > rw semaphore biased to readers.
> > 
> > Indeed, the locked sections are designed to be the rare case.
> 
> OK -- but barrier_sync() just waits for readers, it doesn't exclude them.
> 
> If all barrier_sync() needs to do is to wait until all pre-existing
> barrier_lock()/barrier_unlock() pairs to complete, it seems to me to
> be compatible with qrcu's semantics.
> 
> So what am I missing here?

I might be the one missing stuff, I'll have a hard look at qrcu.

The intent was that barrier_sync() would not write to memory when there
are no active locked sections, so that the cacheline can stay shared,
thus keeping is fast.

If qrcu does exactly this, then yes we have a match.

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

Re: Free Linux Driver Development!

[Lee Revell]

On 1/31/07, Theodore Tso <[EMAIL PROTECTED]> wrote:

More specifically, Dave said that it "seemed rude" to just take the
driver and send updates, but maybe the best way of dealing with
out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
kind of spec release, and just have someone in the community forcibly
take the code, fix it up, and then get it merged.


But if the maintainer is unwilling to work with the kernel developers,
the driver won't get bugfixes or updates for new hardware.

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

Re: 2.6.20-rc6 ramdisk problem

[Robert Hancock]

Michal Piotrowski wrote:

Hi,

I want to create a large ramdisk - 1GB

CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=1
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024

kernel comman line: ramdisk_size=100


..



With ramdisk_size=50 everything is ok.

machine
CPU P4 (ia32)
2 GB RAM

Is this is a hardware (arch) or software limitation? Maybe a bug?

Regards,
Michal


I'm not sure if there's an inherent max ramdisk size limit, however I 
should point out that in most cases, using a tmpfs or ramfs file system 
is better than old-style ramdisks. Those filesystems return unused 
memory to the kernel (ramdisks statically allocate the entire space) and 
also avoid the filesystem overhead of ramdisks (the files are mapped 
into pagecache directly).


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

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

Re: [patch] kbuild: correctly skip tilded backups in localversion files

[Andrew Morton]

On Wed, 31 Jan 2007 07:11:04 +
Oleg Verych <[EMAIL PROTECTED]> wrote:

> kbuild: correctly skip tilded backups in localversion files

Does this patch replace Bastian's patch, below?


From: Bastian Blank <[EMAIL PROTECTED]>

Fix the problem that localversion files were ignored if the tree lives in
a path which contains a ~.  It changes the test to apply to the filename
only.

Debian allows versions which contains ~ in it.  The upstream part of the
version is in the directory name of the build tree and we got weird results
because the localversion files was just got ignored in this case.

Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roman Zippel <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 Makefile |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN Makefile~kbuild-dont-ignore-localversion-files-if-the-path-includes-a 
Makefile
--- a/Makefile~kbuild-dont-ignore-localversion-files-if-the-path-includes-a
+++ a/Makefile
@@ -793,7 +793,7 @@ space  := $(nullstring) # end of lin
 ___localver = $(objtree)/localversion* $(srctree)/localversion*
 __localver  = $(sort $(wildcard $(___localver)))
 # skip backup files (containing '~')
-_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(f)),,$(f)))
+_localver = $(foreach f, $(__localver), $(if $(findstring ~, $(notdir 
$(f))),,$(f)))
 
 localver = $(subst $(space),, \
   $(shell cat /dev/null $(_localver)) \
_

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

Re: [Ksummit-2007-discuss] Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Gerrit Huizenga]

On Wed, 31 Jan 2007 15:30:43 PST, "H. Peter Anvin" wrote:
> Gerrit Huizenga wrote:
> > Don't confused KS with a conference;
> > it is a workshop for a very, very large, very very active project.
> 
> ... and *growing*, which is the real issue I think.
> 
> Something that might make sense for KS is to have multiple sessions 
> (perhaps replacing some or all of the "mini-summits" that have cropped 
> up) combined with some bigger, overall sessions.  At least that way 
> there would be more cross-pollination between the various groups than if 
> we eventually end up meeting everywhere.
> 
> That's of course only practical if KS is separated from any other 
> conference (like OLS.)

Are you thinking something like "core VM/scheduler/locking/etc." as one set of
not-quite-so-mini-summit, and a "block IO/storage drivers/filesystems" as 
another,
"arch maintainers" as another, and "all the nutty drivers and their writers" as
perhaps a fourth?  In other words, some semi-logical grouping of issues
each as more free floating meetings?  Or did I miss your suggestion?

Easy on the judgement on practicality, btw.  For instance, FAST is going
to try to do some part of one of these - possibly larger than a networking
mini-summit in scope but otherwise with similar goals.

I think there are some options to consider for hosting some targetted
working meetings in some of these areas, including the examples already
given for some mini-summits.  Some sponsors might help set up mini-summits
(and some have in the psat), including considering the Linux Foundation as
they do with the Desktop Architects Meeting (my favorite DAM meeting!).

The challenge is to figure out what people want to have happen, the see if
we can make it happen.

gerrit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] sd: spin down disks on removal or power-down

[Robert Hancock]

Stefan Richter wrote:

Robert Hancock wrote:

http://marc.theaimsgroup.com/?t=11692262122

It looks like Tejun's patch essentially does the same thing as mine with
the addition of the control from userspace. There is one exception
though, my patch also does the stop on removal of the SCSI disk (i.e.
writing 1 to its "delete" file in sysfs, what scsiadd -r does).


Isn't sd_shutdown called at this occasion?


Ah, indeed it is. I was thinking of the way I had written my patch, 
where it only does the spindown if the system state is SYSTEM_POWER_OFF 
so I needed an extra call to force this on removal. Tejun's patch just 
checks for not SYSTEM_RESTART, so it should happen on removal as well.


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

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

Re: Free Linux Driver Development!

[Greg KH]

On Wed, Jan 31, 2007 at 06:00:15PM -0500, Theodore Tso wrote:
> On Wed, Jan 31, 2007 at 12:12:58PM -0800, Greg KH wrote:
> > 
> > This kind of offer has _always_ been there for out-of-tree GPL drivers.
> > I have contacted many different groups and driver authors over the years
> > to offer my help in trying to get their code into the mainline kernel.
> > 
> > Some take me up on the offer, others ignore it, and still others activly
> > refuse to do so, saying they want to stay out-of-the tree (lirc is one
> > of these examples...)
> 
> I think the point is that if we are offering free development effort
> to write a driver which goes into mainline, maybe we should provide
> more than "providing rules and guidelines" so that people can spend
> engineering $$$ to get the driver into mainline.   

I do that a lot for a lot of different drivers and companies today.  So
do other people in the community.

But again, if you wish to publicize this, that's great, but it wasn't
the main goal of my announcement.

> More specifically, Dave said that it "seemed rude" to just take the
> driver and send updates, but maybe the best way of dealing with
> out-of-tree drivers like lirc is to treat the out-of-tree drivers as a
> kind of spec release, and just have someone in the community forcibly
> take the code, fix it up, and then get it merged.  Maybe it's being
> "rude", but so is not responding to requests to get it merged.

No, I'm going by Linus's rule here, if a person doesn't want their code
in the kernel tree, then I'm not going to forcefully put it there.
That's just being rude.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] procfs: Fix listing of /proc/NOT_A_TGID/task

[Guillaume Chazarain]

Hi,

I think this is 2.6.20 material, if it gets appropriately reviewed ;-)

Thanks.

--
Guillaume

Listing /proc/PID/task were PID is not a TGID
should not result in duplicated entries.

[g ~]$ pidof thunderbird-bin
2751
[g ~]$ ls /proc/2751/task
2751  2770  2771  2824  2826  2834  2835  2851  2853
[g ~]$ ls /proc/2770/task
2751  2770  2771  2824  2826  2834  2835  2851  2853
2770  2771  2824  2826  2834  2835  2851  2853
[g ~]$ 

Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---

 fs/proc/base.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff -r f99a8b402753 fs/proc/base.c
--- a/fs/proc/base.c	Wed Jan 31 05:00:31 2007 +
+++ b/fs/proc/base.c	Thu Feb 01 00:25:33 2007 +0100
@@ -2328,13 +2328,23 @@ static int proc_task_readdir(struct file
 {
 	struct dentry *dentry = filp->f_path.dentry;
 	struct inode *inode = dentry->d_inode;
-	struct task_struct *leader = get_proc_task(inode);
+	struct task_struct *leader = NULL;
 	struct task_struct *task;
 	int retval = -ENOENT;
 	ino_t ino;
 	int tid;
 	unsigned long pos = filp->f_pos;  /* avoiding "long long" filp->f_pos */
 
+	task = get_proc_task(inode);
+	if (!task)
+		goto out_no_task;
+	rcu_read_lock();
+	if (pid_alive(task)) {
+		leader = task->group_leader;
+		get_task_struct(leader);
+	}
+	rcu_read_unlock();
+	put_task_struct(task);
 	if (!leader)
 		goto out_no_task;
 	retval = 0;

Re: [PATCH 3/3] cxacru: Store all device status information and report it when atm_proc_read is called.

[Andrew Morton]

On Tue, 30 Jan 2007 21:30:29 +
Simon Arlott <[EMAIL PROTECTED]> wrote:

> +static int cxacru_proc_read(struct usbatm_data *usbatm_instance,
> + struct atm_dev *atm_dev, loff_t * pos, char *page)
> +{
> + struct cxacru_data *instance = usbatm_instance->driver_data;
> + u32 *cxinf = instance->cxinf_status;
> + int left = *pos;
> +
> + if (!left--)
> + return sprintf(page, "# %s\n", usbatm_instance->description);
> +
> + if (!left--) {
> + if (cxinf[CXINF_LINE_STATUS] == 5) {
> + return sprintf(page, "# UP %u/%u\n",
> + cxinf[CXINF_DOWNSTREAM_RATE],
> + cxinf[CXINF_UPSTREAM_RATE]);
> + } else {
> + return sprintf(page, "# DOWN\n");
> + }
> + }

hm, how well-tested was this proc interface?  The pread() and lseek()
behaviour might be strange.

I guess as long as it doesn't oops, hang or anything like that then it'll
be OK.  Anyone who does anything apart from a single big-fat-read from a 
procfile has a good chance of getting into trouble :(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/