twitter: linux.kernel - 26 new messages in 20 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* BUG mutex_unlock without mutex_lock in drivers/pnp/isapnp/core.c - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/2715d34247f3f583?hl=en
* : input: add support for VirtualBox touchscreen emulation to the Lifebook
driver - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/36b703b3286dcd72?hl=en
* gpio: introduce it8761e_gpio driver for IT8761E Super I/O chip - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/d2a40e6665d0d6c5?hl=en
* 2.6.33 problems - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3577fd3e959583de?hl=en
* msdos: add support for large disks - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/feedecd5f30fb05f?hl=en
* BUG: spinlock lockup on task_rq_lock in 2.6.33 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d3689fc14b36b1fd?hl=en
* Oops while booting 2.6.34-rc0 (block pull busted) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f7420e106a3c28db?hl=en
* inflate_fast: sout is already a short so ptr arith was off by one. - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/996a4a0deffd3974?hl=en
* LED driver for the Soekris net5501 board. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/484410bbbfae8034?hl=en
* drm request 2 - 6 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/25fd69fb4cbfc733?hl=en
* introduce sys_membarrier(): process-wide memory barrier (v9) - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/c66948a2bac76935?hl=en
* x86/irq and x86/apic changes for v2.6.34 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bd3bcfc4d2ef53c6?hl=en
* TTY patches for 2.6.33-git - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/08c1b2b68bc4f84b?hl=en
* ahci: Introduce ahci_set_em_messages() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f52e7d83445abba6?hl=en
* linux-next: manual merge of the usb tree with the block tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e33cbace23ba0fb6?hl=en
* ocfs2: ensure trusted xattrs are not returned to unprivileged users via
listxattr - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5b44e2eb8c050e04?hl=en
* driver core patches for 2.6.33-git - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/63818dfc875730b2?hl=en
* USB patches for 2.6.33-git - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3fc0932b9cc2fa65?hl=en
* memcg: dirty pages instrumentation - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
* 2.6.33 staging rt2870 += Belkin F5D8055 Wireless-N USB Dongle - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/46c759f6f4b38e5f?hl=en

==============================================================================
TOPIC: BUG mutex_unlock without mutex_lock in drivers/pnp/isapnp/core.c
http://groups.google.com/group/linux.kernel/t/2715d34247f3f583?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 2:40 pm
From: Bjorn Helgaas

On Monday 01 March 2010 08:59:40 am Alexander Strakh wrote:
> KERNEL_VERSION: 2.6.33
> SUBJECT: mutex_unlock without mutex_lock
> DESCRIBE:
> In drivers/pnp/isapnp/core.c in function isapnp_get_resources:
>
> ...
> 4. isapnp_cfg_end in line 886 calls mutex_unlock on &isapnp_cfg_mutex without
> mutex_lock (it was not locked in function isapnp_cfg_begin because of -
> EINVAL).

Looks like a bug to me. I'll send a patch.

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

==============================================================================
TOPIC: : input: add support for VirtualBox touchscreen emulation to the
Lifebook driver
http://groups.google.com/group/linux.kernel/t/36b703b3286dcd72?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 2:50 pm
From: Dmitry Torokhov

On Tue, Mar 02, 2010 at 11:00:19PM +0100, Michael Thayer wrote:
> Le mardi 02 mars 2010 � 13:28 -0800, Dmitry Torokhov a �crit :
> > On Tue, Mar 02, 2010 at 09:44:48PM +0100, Michael Thayer wrote:
> > > it still provides a reasonable user experience until the user has installed our
> > > guest drivers.
> >
> > It is your call but I would much rather if you worked on fixeng evdev to
> > work with your virtual device rather than having to install a new X
> > driver and going through the hoops trying to detect which one should be
> > used on a particular box. At least on Linux...
> That wouldn't really help us much here, as we are talking about distributions
> shipping X.Org Server 1.4 and earlier, and those distributions are no longer
> going to get that sort of update (in those cases in which they are still
> getting updates at all). Legacy support if you like.
>

You need to distribute something... Or do these older distros already
include your guest drivers?

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

== 2 of 2 ==
Date: Tues, Mar 2 2010 3:20 pm
From: Michael Thayer

Le mardi 02 mars 2010 à 14:39 -0800, Dmitry Torokhov a écrit :
> On Tue, Mar 02, 2010 at 11:00:19PM +0100, Michael Thayer wrote:
> > Le mardi 02 mars 2010 à 13:28 -0800, Dmitry Torokhov a écrit :
> > > It is your call but I would much rather if you worked on fixeng evdev to
> > > work with your virtual device rather than having to install a new X
> > > driver and going through the hoops trying to detect which one should be
> > > used on a particular box. At least on Linux...
> > That wouldn't really help us much here, as we are talking about distributions
> > shipping X.Org Server 1.4 and earlier, and those distributions are no longer
> > going to get that sort of update (in those cases in which they are still
> > getting updates at all). Legacy support if you like.

> You need to distribute something... Or do these older distros already
> include your guest drivers?
We provide the drivers for those distributions (as well as a couple of other
things like tools for clipboard integration with the host, or seamless desktop
integration) as part of the VirtualBox package (and yes, we do jump through
hoops to install them :) ). A couple of distributions do actually install them
by default (openSUSE, Pardus), but that is a bit of a mixed blessing for us, as
the versions installed are usually not the most recent, and it is hard for us to
update them.

Regards,

Michael
--
Sun Microsystems GmbH Michael Thayer
Werkstrasse 24 VirtualBox engineer
71384 Weinstadt, Germany mailto:michael.thayer@sun.com

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Haering

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

==============================================================================
TOPIC: gpio: introduce it8761e_gpio driver for IT8761E Super I/O chip
http://groups.google.com/group/linux.kernel/t/d2a40e6665d0d6c5?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 2:50 pm
From: Andrew Morton

On Sun, 28 Feb 2010 10:54:12 +0200
Denis Turischev <denis@compulab.co.il> wrote:

> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -101,6 +101,12 @@ config GPIO_SCH
> This driver can also be built as a module. If so, the module
> will be called sch-gpio.
>
> +config GPIO_IT8761E
> + tristate "IT8761E GPIO support"
> + depends on GPIOLIB
> + help
> + Say yes here to support GPIO functionality of IT8761E super I/O chip.
> +

The comment said "put expanders in the right section, in alphabetical
order". It wasn't in alphabetical order ;)

Is this a "Memory mapped GPIO expander"? Looks like it's IO-mapped,
but there isn't a section in Kconfig for that. PCI mapped?

==============================================================================
TOPIC: 2.6.33 problems
http://groups.google.com/group/linux.kernel/t/3577fd3e959583de?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 2:50 pm
From: Stephen Hemminger

On Tue, 2 Mar 2010 13:50:32 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sat, 27 Feb 2010 14:09:11 -0300 (GFT)
> werner@guyane.dyn-o-saur.com wrote:
>
> > For better error searching / correction, I add below the whole syslog.
> >
> > This is refered to 2.6.33 published (without patchs)
> >
> > This are different errors.
> >
> > The most of them exists since 2.6.33-rc1 or appr. -rc5.
> >
> > I posted here already the whole syslog.bz2 but nobody toke care.
> >
> > the boot_vga error occurs only after I start the grafics mode. It's the mainboard's embedded nvidia grafics. I use the vesa framebuffer driver of X 1.8
> >
> > the int6_init error occurs also in text mode. I think it have something to do with internet.
> >
> > Also the printk errors occur only when start the computer in the grafics mode, but not when starting it in the text mode.
> >
> > Below is also the kernel config. Its the same like since -rc7 (but the errors are also the same)
> >
> >
>
> Thanks.
>
> >
> > ...
> >
> > Feb 27 13:43:07 werner kernel: PERCPU: allocation failed, size=2048 align=8, failed to allocate new chunk
> > Feb 27 13:43:07 werner kernel: Pid: 5314, comm: modprobe Tainted: G C 2.6.33 #1
> > Feb 27 13:43:07 werner kernel: Call Trace:
> > Feb 27 13:43:07 werner kernel: [<c1c682ca>] ? printk+0x14/0x16
> > Feb 27 13:43:07 werner kernel: [<c10bdfa3>] pcpu_alloc+0x6ba/0x73b
> > Feb 27 13:43:07 werner kernel: [<c10bb0be>] ? get_slab+0x8/0x50
> > Feb 27 13:43:07 werner kernel: [<c1b7283d>] ? neigh_parms_alloc+0x55/0xd1
> > Feb 27 13:43:07 werner kernel: [<c10be047>] __alloc_percpu+0xf/0x14
> > Feb 27 13:43:07 werner kernel: [<c1bb26cb>] snmp_mib_init+0x22/0x5a
> > Feb 27 13:43:07 werner kernel: [<fed105af>] ipv6_add_dev+0x191/0x30b [ipv6]
> > Feb 27 13:43:07 werner kernel: [<fd269000>] ? inet6_init+0x0/0x2a2 [ipv6]
> > Feb 27 13:43:07 werner kernel: [<fd2692ec>] addrconf_init+0x3b/0x11b [ipv6]
> > Feb 27 13:43:07 werner kernel: [<fd269195>] inet6_init+0x195/0x2a2 [ipv6]
> > Feb 27 13:43:07 werner kernel: [<c1001143>] do_one_initcall+0x51/0x13f
> > Feb 27 13:43:07 werner kernel: [<c1066570>] sys_init_module+0xac/0x1e0
> > Feb 27 13:43:07 werner kernel: [<c1c6acec>] syscall_call+0x7/0xb
> > Feb 27 13:43:19 werner kdm_greet[5382]: Can't open default user face
> > Feb 27 13:44:24 werner kernel: PERCPU: allocation failed, size=2048 align=8, failed to allocate new chunk
> > Feb 27 13:44:24 werner kernel: Pid: 5737, comm: modprobe Tainted: G C 2.6.33 #1
> > Feb 27 13:44:24 werner kernel: Call Trace:
> > Feb 27 13:44:24 werner kernel: [<c1c682ca>] ? printk+0x14/0x16
> > Feb 27 13:44:24 werner kernel: [<c10bdfa3>] pcpu_alloc+0x6ba/0x73b
> > Feb 27 13:44:24 werner kernel: [<c10bb0be>] ? get_slab+0x8/0x50
> > Feb 27 13:44:24 werner kernel: [<c1b7283d>] ? neigh_parms_alloc+0x55/0xd1
> > Feb 27 13:44:24 werner kernel: [<c10be047>] __alloc_percpu+0xf/0x14
> > Feb 27 13:44:24 werner kernel: [<c1bb26cb>] snmp_mib_init+0x22/0x5a
> > Feb 27 13:44:24 werner kernel: [<fed105af>] ipv6_add_dev+0x191/0x30b [ipv6]
> > Feb 27 13:44:24 werner kernel: [<f91bf000>] ? inet6_init+0x0/0x2a2 [ipv6]
> > Feb 27 13:44:24 werner kernel: [<f91bf2ec>] addrconf_init+0x3b/0x11b [ipv6]
> > Feb 27 13:44:24 werner kernel: [<f91bf195>] inet6_init+0x195/0x2a2 [ipv6]
> > Feb 27 13:44:24 werner kernel: [<c1001143>] do_one_initcall+0x51/0x13f
> > Feb 27 13:44:24 werner kernel: [<c1066570>] sys_init_module+0xac/0x1e0
> > Feb 27 13:44:24 werner kernel: [<c1c6acec>] syscall_call+0x7/0xb
> > Feb 27 13:44:27 werner kernel: PERCPU: allocation failed, size=2048 align=8, failed to allocate new chunk
> > Feb 27 13:44:27 werner kernel: Pid: 5772, comm: modprobe Tainted: G C 2.6.33 #1
> > Feb 27 13:44:27 werner kernel: Call Trace:
> > Feb 27 13:44:27 werner kernel: [<c1c682ca>] ? printk+0x14/0x16
> > Feb 27 13:44:27 werner kernel: [<c10bdfa3>] pcpu_alloc+0x6ba/0x73b
> > Feb 27 13:44:27 werner kernel: [<c10bb0be>] ? get_slab+0x8/0x50
> > Feb 27 13:44:27 werner kernel: [<c1b7283d>] ? neigh_parms_alloc+0x55/0xd1
> > Feb 27 13:44:27 werner kernel: [<c10be047>] __alloc_percpu+0xf/0x14
> > Feb 27 13:44:27 werner kernel: [<c1bb26cb>] snmp_mib_init+0x22/0x5a
> > Feb 27 13:44:27 werner kernel: [<fee155af>] ipv6_add_dev+0x191/0x30b [ipv6]
> > Feb 27 13:44:27 werner kernel: [<f9185000>] ? inet6_init+0x0/0x2a2 [ipv6]
> > Feb 27 13:44:27 werner kernel: [<f91852ec>] addrconf_init+0x3b/0x11b [ipv6]
> > Feb 27 13:44:27 werner kernel: [<f9185195>] inet6_init+0x195/0x2a2 [ipv6]
> > Feb 27 13:44:27 werner kernel: [<c1001143>] do_one_initcall+0x51/0x13f
> > Feb 27 13:44:27 werner kernel: [<c1066570>] sys_init_module+0xac/0x1e0
> > Feb 27 13:44:27 werner kernel: [<c1c6acec>] syscall_call+0x7/0xb
>
> Methinks Tejun's stuff broke, and then triggered a bug in a
> hitherto-untested networking error recovery codepath.
>
>
> > Feb 27 13:44:27 werner kernel: BUG: unable to handle kernel paging request at fed348d4
> > Feb 27 13:44:27 werner kernel: IP: [<c1b68700>] unregister_pernet_operations+0x21/0x93
> > Feb 27 13:44:27 werner kernel: *pde = 360fc067 *pte = 00000000
> > Feb 27 13:44:27 werner kernel: Oops: 0002 [#1] PREEMPT SMP
> > Feb 27 13:44:27 werner kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:0d.0/boot_vga
> > Feb 27 13:44:27 werner kernel: Modules linked in: ipv6(+) bnep rfcomm hidp l2cap bluetooth snd_usb_audio snd_usb_lib snd_rawmidi snd_seq_device rt2860sta(C) uvcvideo usbvideo lp snd_hda_codec_analog rtc_cmos rtc_core rtc_lib rtl8187 tpm_tis tpm tpm_bios mac80211 led_class snd_hda_intel snd_hda_codec k8temp hwmon 8139too cfg80211 snd_hwdep snd_pcm rfkill snd_timer snd soundcore snd_page_alloc forcedeth i2c_nforce2
> > Feb 27 13:44:27 werner kernel:
> > Feb 27 13:44:27 werner kernel: Pid: 5772, comm: modprobe Tainted: G C 2.6.33 #1 M2N-VM DH/System Product Name
> > Feb 27 13:44:27 werner kernel: EIP: 0060:[<c1b68700>] EFLAGS: 00010246 CPU: 0
> > Feb 27 13:44:27 werner kernel: EIP is at unregister_pernet_operations+0x21/0x93
> > Feb 27 13:44:27 werner kernel: EAX: fed348d4 EBX: fee39850 ECX: f0d7bf58 EDX: fee398d4
> > Feb 27 13:44:27 werner kernel: ESI: fee39850 EDI: f9185000 EBP: f0d7bf6c ESP: f0d7bf58
> > Feb 27 13:44:27 werner kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > Feb 27 13:44:27 werner kernel: Process modprobe (pid: 5772, ti=f0d7a000 task=f0ccb660 task.ti=f0d7a000)
> > Feb 27 13:44:27 werner kernel: Stack:
> > Feb 27 13:44:27 werner kernel: f0d7bf58 f0d7bf58 fee39850 00000000 f9185000 f0d7bf78 c1b687c6 fffffff4
> > Feb 27 13:44:27 werner kernel: <0> f0d7bf84 f9185257 fee3b834 f0d7bf9c c1001143 00000000 fee3b834 00000000
> > Feb 27 13:44:27 werner kernel: <0> 0805e188 f0d7bfac c1066570 b7516008 0805e138 f0d7a000 c1c6acec b7516008
> > Feb 27 13:44:27 werner kernel: Call Trace:
> > Feb 27 13:44:27 werner kernel: [<f9185000>] ? inet6_init+0x0/0x2a2 [ipv6]
> > Feb 27 13:44:27 werner kernel: [<c1b687c6>] ? unregister_pernet_subsys+0x1c/0x29
> > Feb 27 13:44:27 werner kernel: [<f9185257>] ? inet6_init+0x257/0x2a2 [ipv6]
> > Feb 27 13:44:27 werner kernel: [<c1001143>] ? do_one_initcall+0x51/0x13f
> > Feb 27 13:44:27 werner kernel: [<c1066570>] ? sys_init_module+0xac/0x1e0
> > Feb 27 13:44:27 werner kernel: [<c1c6acec>] ? syscall_call+0x7/0xb
> > Feb 27 13:44:27 werner kernel: Code: c2 75 e5 e8 78 0a 51 ff eb 97 55 89 e5 57 56 53 83 ec 08 e8 03 b2 49 ff 89 c6 8d 4d ec 89 4d ec 89 4d f0 8b 10 8b 40 04 89 42 04 <89> 10 c7 06 00 01 10 00 c7 46 04 00 02 20 00 a1 b8 b7 10 c2 8d
> > Feb 27 13:44:27 werner kernel: EIP: [<c1b68700>] unregister_pernet_operations+0x21/0x93 SS:ESP 0068:f0d7bf58
> > Feb 27 13:44:27 werner kernel: CR2: 00000000fed348d4
> > Feb 27 13:44:27 werner kernel: ---[ end trace 120df121853896c9 ]---
> > Feb 27 13:45:39 werner kernel: BUG: Bad page map in process kio_http pte:fee39850 pmd:ace05067
> > Feb 27 13:45:39 werner kernel: addr:b6635000 vm_flags:08000075 anon_vma:(null) mapping:f20f434c index:5d
> > Feb 27 13:45:39 werner kernel: vma->vm_ops->fault: filemap_fault+0x0/0x2eb
> > Feb 27 13:45:39 werner kernel: vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x44
> > Feb 27 13:45:39 werner kernel: Pid: 5764, comm: kio_http Tainted: G D C 2.6.33 #1
> > Feb 27 13:45:39 werner kernel: Call Trace:
> > Feb 27 13:45:39 werner kernel: [<c10a47c7>] print_bad_pte+0x17e/0x190
> > Feb 27 13:45:39 werner kernel: [<c10a5782>] unmap_vmas+0x444/0x676
> > Feb 27 13:45:39 werner kernel: [<c10a461d>] ? __do_fault+0x3bd/0x3e9
> > Feb 27 13:45:39 werner kernel: [<c10988b9>] ? ____pagevec_lru_add+0x101/0x10f
> > Feb 27 13:45:39 werner kernel: [<c10a9344>] exit_mmap+0xab/0x13a
> > Feb 27 13:45:39 werner kernel: [<c1038cc1>] mmput+0x3a/0xb0
> > Feb 27 13:45:39 werner kernel: [<c103c669>] exit_mm+0xec/0xf4
> > Feb 27 13:45:39 werner kernel: [<c1c6a525>] ? _raw_spin_lock_irq+0xb/0x34
> > Feb 27 13:45:39 werner kernel: [<c1c6a855>] ? _raw_spin_unlock_irq+0x8/0x27
> > Feb 27 13:45:39 werner kernel: [<c103dbc1>] do_exit+0x1ad/0x605
> > Feb 27 13:45:39 werner kernel: [<c105554c>] ? up_read+0x8/0x18
> > Feb 27 13:45:39 werner kernel: [<c103e080>] do_group_exit+0x67/0x8a
> > Feb 27 13:45:39 werner kernel: [<c103e0bb>] sys_exit_group+0x18/0x1c
> > Feb 27 13:45:39 werner kernel: [<c1c6acec>] syscall_call+0x7/0xb

The SNMP MIB stuff does allocate a disproportionately large amount of percpu
data. Looks like 2 tables per MIB.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: msdos: add support for large disks
http://groups.google.com/group/linux.kernel/t/feedecd5f30fb05f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 2:50 pm
From: "Daniel Taylor"

In order to use disks larger than 2TiB on Windows XP, it is necessary to use
4096-byte logical sectors in an MBR.

Although the kernel storage and functions called from msdos.c used
"sector_t" internally, msdos.c still used u32 variables, which results in
the ability to handle XP-compatible large disks.

This patch changes the internal variables to "sector_t".

Signed-off-by: Daniel Taylor <daniel.taylor@wdc.com> diff --git
a/fs/partitions/msdos.c b/fs/partitions/msdos.c index 0028d2e..039bb61
100644
--- a/fs/partitions/msdos.c
+++ b/fs/partitions/msdos.c
@@ -32,13 +32,20 @@
#include <asm/unaligned.h>

#define SYS_IND(p) (get_unaligned(&p->sys_ind))
-#define NR_SECTS(p) ({ __le32 __a = get_unaligned(&p->nr_sects); \
- le32_to_cpu(__a); \
- })

-#define START_SECT(p) ({ __le32 __a = get_unaligned(&p->start_sect); \
- le32_to_cpu(__a); \
- })
+static inline sector_t nr_sects(struct partition *p) {
+ u32 number_of_sectors = le32_to_cpu(get_unaligned(&p->nr_sects));
+
+ return (sector_t)number_of_sectors;
+}
+
+static inline sector_t start_sect(struct partition *p) {
+ u32 start_sector = le32_to_cpu(get_unaligned(&p->start_sect));
+
+ return (sector_t)start_sector;
+}

static inline int is_extended_partition(struct partition *p) { @@ -104,13
+111,13 @@ static int aix_magic_present(unsigned char *p, struct
block_device *bdev)

static void
parse_extended(struct parsed_partitions *state, struct block_device *bdev,
- u32 first_sector, u32 first_size)
+ sector_t first_sector, sector_t first_size)
{
struct partition *p;
Sector sect;
unsigned char *data;
- u32 this_sector, this_size;
- int sector_size = bdev_logical_block_size(bdev) / 512;
+ sector_t this_sector, this_size;
+ sector_t sector_size = bdev_logical_block_size(bdev) / 512;
int loopct = 0; /* number of links followed
without finding a data partition */
int i;
@@ -145,14 +152,14 @@ parse_extended(struct parsed_partitions *state, struct
block_device *bdev,
* First process the data partition(s)
*/
for (i=0; i<4; i++, p++) {
- u32 offs, size, next;
- if (!NR_SECTS(p) || is_extended_partition(p))
+ sector_t offs, size, next;
+ if (!nr_sects(p) || is_extended_partition(p))
continue;

/* Check the 3rd and 4th entries -
these sometimes contain random garbage */
- offs = START_SECT(p)*sector_size;
- size = NR_SECTS(p)*sector_size;
+ offs = start_sect(p)*sector_size;
+ size = nr_sects(p)*sector_size;
next = this_sector + offs;
if (i >= 2) {
if (offs + size > this_size)
@@ -179,13 +186,13 @@ parse_extended(struct parsed_partitions *state, struct
block_device *bdev,
*/
p -= 4;
for (i=0; i<4; i++, p++)
- if (NR_SECTS(p) && is_extended_partition(p))
+ if (nr_sects(p) && is_extended_partition(p))
break;
if (i == 4)
goto done; /* nothing left to do */

- this_sector = first_sector + START_SECT(p) * sector_size;
- this_size = NR_SECTS(p) * sector_size;
+ this_sector = first_sector + start_sect(p) * sector_size;
+ this_size = nr_sects(p) * sector_size;
put_dev_sector(sect);
}
done:
@@ -197,7 +204,7 @@ done:

static void
parse_solaris_x86(struct parsed_partitions *state, struct block_device
*bdev,
- u32 offset, u32 size, int origin)
+ sector_t offset, sector_t size, int origin)
{
#ifdef CONFIG_SOLARIS_X86_PARTITION
Sector sect;
@@ -244,7 +251,7 @@ parse_solaris_x86(struct parsed_partitions *state,
struct block_device *bdev,
*/
static void
parse_bsd(struct parsed_partitions *state, struct block_device *bdev,
- u32 offset, u32 size, int origin, char *flavour,
+ sector_t offset, sector_t size, int origin, char *flavour,
int max_partitions)
{
Sector sect;
@@ -263,7 +270,7 @@ parse_bsd(struct parsed_partitions *state, struct
block_device *bdev,
if (le16_to_cpu(l->d_npartitions) < max_partitions)
max_partitions = le16_to_cpu(l->d_npartitions);
for (p = l->d_partitions; p - l->d_partitions < max_partitions; p++)
{
- u32 bsd_start, bsd_size;
+ sector_t bsd_start, bsd_size;

if (state->next == state->limit)
break;
@@ -290,7 +297,7 @@ parse_bsd(struct parsed_partitions *state, struct
block_device *bdev,

static void
parse_freebsd(struct parsed_partitions *state, struct block_device *bdev,
- u32 offset, u32 size, int origin)
+ sector_t offset, sector_t size, int origin)
{
#ifdef CONFIG_BSD_DISKLABEL
parse_bsd(state, bdev, offset, size, origin, @@ -300,7 +307,7 @@
parse_freebsd(struct parsed_partitions *state, struct block_device *bdev,

static void
parse_netbsd(struct parsed_partitions *state, struct block_device *bdev,
- u32 offset, u32 size, int origin)
+ sector_t offset, sector_t size, int origin)
{
#ifdef CONFIG_BSD_DISKLABEL
parse_bsd(state, bdev, offset, size, origin, @@ -310,7 +317,7 @@
parse_netbsd(struct parsed_partitions *state, struct block_device *bdev,

static void
parse_openbsd(struct parsed_partitions *state, struct block_device *bdev,
- u32 offset, u32 size, int origin)
+ sector_t offset, sector_t size, int origin)
{
#ifdef CONFIG_BSD_DISKLABEL
parse_bsd(state, bdev, offset, size, origin, @@ -324,7 +331,7 @@
parse_openbsd(struct parsed_partitions *state, struct block_device *bdev,
*/
static void
parse_unixware(struct parsed_partitions *state, struct block_device *bdev,
- u32 offset, u32 size, int origin)
+ sector_t offset, sector_t size, int origin)
{
#ifdef CONFIG_UNIXWARE_DISKLABEL
Sector sect;
@@ -348,7 +355,8 @@ parse_unixware(struct parsed_partitions *state, struct
block_device *bdev,

if (p->s_label != UNIXWARE_FS_UNUSED)
put_partition(state, state->next++,
- START_SECT(p), NR_SECTS(p));
+ start_sect((struct partition *)p),
+ nr_sects((struct partition *)p));
p++;
}
put_dev_sector(sect);
@@ -363,7 +371,7 @@ parse_unixware(struct parsed_partitions *state, struct
block_device *bdev,
*/
static void
parse_minix(struct parsed_partitions *state, struct block_device *bdev,
- u32 offset, u32 size, int origin)
+ sector_t offset, sector_t size, int origin)
{
#ifdef CONFIG_MINIX_SUBPARTITION
Sector sect;
@@ -390,7 +398,7 @@ parse_minix(struct parsed_partitions *state, struct
block_device *bdev,
/* add each partition in use */
if (SYS_IND(p) == MINIX_PARTITION)
put_partition(state, state->next++,
- START_SECT(p), NR_SECTS(p));
+ start_sect(p), nr_sects(p));
}
printk(" >\n");
}
@@ -401,7 +409,7 @@ parse_minix(struct parsed_partitions *state, struct
block_device *bdev, static struct {
unsigned char id;
void (*parse)(struct parsed_partitions *, struct block_device *,
- u32, u32, int);
+ sector_t, sector_t, int);
} subtypes[] = {
{FREEBSD_PARTITION, parse_freebsd},
{NETBSD_PARTITION, parse_netbsd},
@@ -415,7 +423,7 @@ static struct {

int msdos_partition(struct parsed_partitions *state, struct block_device
*bdev) {
- int sector_size = bdev_logical_block_size(bdev) / 512;
+ sector_t sector_size = bdev_logical_block_size(bdev) / 512;
Sector sect;
unsigned char *data;
struct partition *p;
@@ -483,8 +491,8 @@ int msdos_partition(struct parsed_partitions *state,
struct block_device *bdev)

state->next = 5;
for (slot = 1 ; slot <= 4 ; slot++, p++) {
- u32 start = START_SECT(p)*sector_size;
- u32 size = NR_SECTS(p)*sector_size;
+ sector_t start = start_sect(p)*sector_size;
+ sector_t size = nr_sects(p)*sector_size;
if (!size)
continue;
if (is_extended_partition(p)) {
@@ -513,7 +521,7 @@ int msdos_partition(struct parsed_partitions *state,
struct block_device *bdev)
unsigned char id = SYS_IND(p);
int n;

- if (!NR_SECTS(p))
+ if (!nr_sects(p))
continue;

for (n = 0; subtypes[n].parse && id != subtypes[n].id; n++)
@@ -521,8 +529,8 @@ int msdos_partition(struct parsed_partitions *state,
struct block_device *bdev)

if (!subtypes[n].parse)
continue;
- subtypes[n].parse(state, bdev, START_SECT(p)*sector_size,
- NR_SECTS(p)*sector_size,
slot);
+ subtypes[n].parse(state, bdev, start_sect(p)*sector_size,
+ nr_sects(p)*sector_size,
slot);
}
put_dev_sector(sect);
return 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: BUG: spinlock lockup on task_rq_lock in 2.6.33
http://groups.google.com/group/linux.kernel/t/d3689fc14b36b1fd?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:00 pm
From: Thomas Gleixner

On Wed, 3 Mar 2010, Dave Chinner wrote:
> On Tue, Mar 02, 2010 at 11:08:50AM +0100, Thomas Gleixner wrote:
> > Dave,
> >
> > On Tue, 2 Mar 2010, Dave Chinner wrote:
> >
> > > Hi Folks,
> > >
> > > I just locked up a machine with the following trace:
> > >
> > > [ 5247.149256] BUG: spinlock lockup on CPU#1, dd/7018, ffff8800059d4380
> > > [ 5247.150009] BUG: spinlock lockup on CPU#0, dd/6211, ffff8800059d4380
> > > [ 5247.150009] Pid: 6211, comm: dd Not tainted 2.6.33-dgc #86
> > > [ 5247.150009] Call Trace:
> > > [ 5247.150009] [<ffffffff8140ad40>] do_raw_spin_lock+0x160/0x170
> > > [ 5247.150009] [<ffffffff8170fec6>] _raw_spin_lock+0x56/0x70
> > > [ 5247.150009] [<ffffffff8103d092>] ? task_rq_lock+0x52/0x90
> > > [ 5247.150009] [<ffffffff8103d092>] task_rq_lock+0x52/0x90
> > > [ 5247.150009] [<ffffffff81044a70>] try_to_wake_up+0x40/0x3d0
> > > [ 5247.150009] [<ffffffff81044e55>] wake_up_process+0x15/0x20
> >
> > I can't say it for sure, but that might be related to a problem with
> > TASK_WAKING which we discovered recently. The fix is in linus tree
> > (commit 0970d2992dfd7d5ec2c787417cf464f01eeaf42a) and on the way to stable.
>
> Thanks Thomas - I'll pull that commit in and see if it has any
> effect on the problems I'm seeing.

I have a hard time to see how that might lead to a deadlock, but hell,
that load balancing code is a maze.

Thanks,

tglx

==============================================================================
TOPIC: Oops while booting 2.6.34-rc0 (block pull busted)
http://groups.google.com/group/linux.kernel/t/f7420e106a3c28db?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:00 pm
From: Dmitry Torokhov

On Tue, Mar 02, 2010 at 01:35:48AM -0800, Dmitry Torokhov wrote:
> On Tue, Mar 02, 2010 at 09:39:07AM +0100, Jens Axboe wrote:
> > On Tue, Mar 02 2010, Jens Axboe wrote:
> > > On Tue, Mar 02 2010, Jens Axboe wrote:
> > > > On Mon, Mar 01 2010, Dmitry Torokhov wrote:
> > > > > Hi,
> > > > >
> > > > > It looks like block tree that has been pulled today into mainline is
> > > > > busted, I am getting the Opps below on boot with the following commit:
> > > > >
> > > > > commit b1bf9368407ae7e89d8a005bb40beb70a41df539
> > > > > Merge: 524df55 4671a13
> > > > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > > > Date: Mon Mar 1 09:00:29 2010 -0800
> > > > >
> > > > > Merge branch 'for-2.6.34' of git://git.kernel.dk/linux-2.6-block
> > > > >
> > > > >
> > > > > but not with the previous one:
> > > > >
> > > > > commit 524df55725217b13d5a232fb5badb5846418ea0e
> > > > > Merge: 0f45339 6679ee1
> > > > > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > > > > Date: Mon Mar 1 08:58:44 2010 -0800
> > > > >
> > > > > Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
> > > > >
> > > > > This is on plain Fedora 12 VM.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > --
> > > > > Dmitry
> > > > >
> > > > > sd 2:0:0:0: Attached scsi generic sg1 type 0
> > > > > sd 2:0:0:0: [sda] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB)
> > > > > sd 2:0:0:0: [sda] Write Protect is off
> > > > > sd 2:0:0:0: [sda] Cache data unavailable
> > > > > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > > > > sd 2:0:0:0: [sda] Cache data unavailable
> > > > > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > > > > sda: sda1 sda2
> > > > > sd 2:0:0:0: [sda] Cache data unavailable
> > > > > sd 2:0:0:0: [sda] Assuming drive cache: write through
> > > > > sd 2:0:0:0: [sda] Attached SCSI disk
> > > > > device-mapper: multipath: version 1.1.1 loaded
> > > > > dracut: Scanning devices sda2 for LVM volume groups
> > > > > dracut: Reading all physical volumes. This may take a while...
> > > > > dracut: Found volume group "VolGroup" using metadata type lvm2
> > > > > dracut: 2 logical volume(s) in volume group "VolGroup" now active
> > > > > EXT4-fs (dm-0): mounted filesystem with ordered data mode
> > > > > BUG: unable to handle kernel NULL pointer dereference at (null)
> > > > > IP: [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
> > > > > PGD 3b776067 PUD 3b7b1067 PMD 0
> > > > > Oops: 0002 [#1] SMP
> > > > > last sysfs file: /sys/kernel/uevent_seqnum
> > > > > CPU 0
> > > > > Modules linked in: dm_multipath mptspi mptscsih mptbase scsi_transport_spi floppy [last unloaded: scsi_wait_scan]
> > > > >
> > > > > Pid: 1, comm: init Not tainted 2.6.33 #4 440BX Desktop Reference Platform/VMware Virtual Platform
> > > > > RIP: 0010:[<ffffffff81128ee1>] [<ffffffff81128ee1>] mpage_end_io_read+0x45/0x6f
> > > >
> > > > Can you check where that is? Just do a gdb vmlinux and then an
> > > > l *mpage_end_io_read+0x45
> > >
> > > I tried checking mine here, but we must be using vastly different gcc
> > > versions. So I'd like that output. Can you also try and see if reverting
> > > 9f7cdbc33f36d28e57eaba0093f68f0d14c38c5b makes it work?
> >
> > OK, so disasm of that reveals that
> >
> > 12: 3e 80 0f 08 orb $0x8,%ds:(%rdi)
> >
> > is the start of the faulting instruction. You are running UP. 0x8 is the
> > 4th bit, so I'd be surprised if that isn't SetPageUptodate(page).
> >
>
> Sorry, don't have access to that box at the moment... Will try checking
> tomorrow.
>

You are absolutely right, it crashes in SetPageUptodate():

(gdb) l *bio_endio+0x2b
0xffffffff8112209d is in bio_endio (fs/bio.c:1433).
1428 else if (!test_bit(BIO_UPTODATE, &bio->bi_flags))
1429 error = -EIO;
1430
1431 if (bio->bi_end_io)
1432 bio->bi_end_io(bio, error);
1433 }
1434 EXPORT_SYMBOL(bio_endio);
1435
1436 void bio_pair_release(struct bio_pair *bp)
1437 {
(gdb) l *mpage_end_io_read+0x45
0xffffffff811268b1 is in mpage_end_io_read (/home/dtor/kernel/linus/arch/x86/include/asm/bitops.h:63).
58 */
59 static __always_inline void
60 set_bit(unsigned int nr, volatile unsigned long *addr)
61 {
62 if (IS_IMMEDIATE(nr)) {
63 asm volatile(LOCK_PREFIX "orb %1,%0"
64 : CONST_MASK_ADDR(nr, addr)
65 : "iq" ((u8)CONST_MASK(nr))
66 : "memory");
67 } else {
(gdb) l *mpage_end_io_read+0x44
0xffffffff811268b0 is in mpage_end_io_read (fs/mpage.c:53).
48 struct page *page = bvec->bv_page;
49
50 if (--bvec >= bio->bi_io_vec)
51 prefetchw(&bvec->bv_page->flags);
52
53 if (uptodate) {
54 SetPageUptodate(page);
55 } else {
56 ClearPageUptodate(page);
57 SetPageError(page);

==============================================================================
TOPIC: inflate_fast: sout is already a short so ptr arith was off by one.
http://groups.google.com/group/linux.kernel/t/996a4a0deffd3974?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:00 pm
From: Andrew Morton

On Sun, 28 Feb 2010 17:06:02 +0100
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote:

> This won't change anything for current code, but post increment
> will break without this fix, should anyone want to try that.
>

The description is a bit cryptic. Hopefully you understand what you
mean, but does anyone else?

> diff --git a/lib/zlib_inflate/inffast.c b/lib/zlib_inflate/inffast.c
> index fa62fc7..2c13ecc 100644
> --- a/lib/zlib_inflate/inffast.c
> +++ b/lib/zlib_inflate/inffast.c
> @@ -286,7 +286,7 @@ void inflate_fast(z_streamp strm, unsigned start)
> } else { /* dist == 1 or dist == 2 */
> unsigned short pat16;
>
> - pat16 = *(sout-2+2*OFF);
> + pat16 = *(sout-1+OFF);
> if (dist == 1) {
> union uu mm;
> /* copy one char pattern to both bytes */

The code you're altering was changed two months ago by, err, you. I
don't know if the patch still makes sense in current kernels.

Please don't raise patches against old kernels. Please check that,
redo the patch, add a changelog which helps non-inffast.c people
understand what it does, then resend?

==============================================================================
TOPIC: LED driver for the Soekris net5501 board.
http://groups.google.com/group/linux.kernel/t/484410bbbfae8034?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Andrew Morton

On Sun, 28 Feb 2010 17:01:13 +0000
Bjarke Istrup Pedersen <gurligebis@gentoo.org> wrote:

> LED driver for the Soekris net5501 board.

Thanks, I queued this for sending to Richard.

> It is based on the previously submitted code by Alessandro Zummo, but is changed to use the new GPIO driver with 2.6.33, and the driver has been moved to drivers/leds where it belongs.

It should have Alessandro's Signed-off-by: at least.

It perhaps should have his From:, also. Please work out with Alessandro
who should be credited as primary author of this driver.

> Signed-off-by: Bjarke Istrup Pedersen <gurligebis@gentoo.org>
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: drm request 2
http://groups.google.com/group/linux.kernel/t/25fd69fb4cbfc733?hl=en
==============================================================================

== 1 of 6 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Linus Torvalds

On Tue, 2 Mar 2010, Dave Airlie wrote:
>
> because it does nothing on anything except the laptops in question and on
> those it does nothing except add a control file in debugfs?

It's still code. And if the user didn't ask for it, it should damn well
not be there.

> So how am I supposed to indicate to distro vendors that something should
> be turned on? If you think that distro kernel maintainers really
> understand every config option that goes past, I've got a bridge.

User configurations is _not_ your job. Your job is to make sure that the
kernel works, and people who don't ask for new feaures don't get them.

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

== 2 of 6 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Linus Torvalds

On Mon, 1 Mar 2010, Dave Airlie wrote:
>
> Same tree as yesterday with a warning + PPC build fix + fix for build on
> x86 after PPC (I think I just validated Ingo).

Why is VGA_SWITCHEROO enabled by default?

We don't do things like that. New drivers and new features are _not_
enabled by default, unless there is some overriding reason why they should
be. And I don't see that reason.

Please stop doing that. The whole "default y" is a f*cking disease. Yes, a
developer always thinks that _his_ new code is so special and important
that it should be enabled by default, BUT HE IS WRONG.

So remember: unless your new feature cures cancer, it should damn well not
be enabled by default.

I disabled it in the merge, since I had to fix up that file anyway. But
please don't make me do these so-called "evil merges" where I end up
modifying the thing I merge.

== 3 of 6 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Linus Torvalds

On Tue, 2 Mar 2010, Linus Torvalds wrote:
>
> I disabled it in the merge, since I had to fix up that file anyway. But
> please don't make me do these so-called "evil merges" where I end up
> modifying the thing I merge.

Never mind. I've unpulled the whole effin' mess since it doesn't even
compile:

drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ¡nouveau_register_dsm_handler¢
drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ¡nouveau_register_dsm_handler¢ was here
drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ¡nouveau_unregister_dsm_handler¢
drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ¡nouveau_unregister_dsm_handler¢ was here

because not only was that VGA_SWITCHEROO Kconfig default the wrong way
around, the thing had clearly never ever been tested at all.

Why does sh*t like this even make it to me? Was this ever at all in -next?
I assume not, since that would have picked up on basic compile failures.

Grr. Things like this is what makes me go "Ok, there's always the next
merge window, maybe it will have gotten some testing by then".

== 4 of 6 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Linus Torvalds

On Tue, 2 Mar 2010, Linus Torvalds wrote:
>
> It's still code. And if the user didn't ask for it, it should damn well
> not be there.

And I repeat: unless the feature cures cancer, it's not on by default.

Sometimes we split up _old_ features as config options, or do things that
are meant to be turned off only for embedded people. THEN we use that
whole 'default y' thing, because doing a "make oldconfig" should give you
the same configuration you had before.

But if it's not an old feature that used to not have a config option at
all, and it doesn't cure cancer, you never EVER do "default y". Because
when I do "make oldconfig", and I see a "Y" default, it makes me go "I'm
not pulling that piece of sh*t".

== 5 of 6 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Dave Airlie

> > x86 after PPC (I think I just validated Ingo).
>
> Why is VGA_SWITCHEROO enabled by default?

because it does nothing on anything except the laptops in question and on
those it does nothing except add a control file in debugfs?

So how am I supposed to indicate to distro vendors that something should
be turned on? If you think that distro kernel maintainers really
understand every config option that goes past, I've got a bridge.

Dave.

== 6 of 6 ==
Date: Tues, Mar 2 2010 3:20 pm
From: Dave Airlie

>
> Never mind. I've unpulled the whole effin' mess since it doesn't even
> compile:
>
> drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of 'nouveau_register_dsm_handler'
> drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of 'nouveau_register_dsm_handler' was here
> drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of 'nouveau_unregister_dsm_handler'
> drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of 'nouveau_unregister_dsm_handler' was here
>
> because not only was that VGA_SWITCHEROO Kconfig default the wrong way
> around, the thing had clearly never ever been tested at all.
>
> Why does sh*t like this even make it to me? Was this ever at all in -next?
> I assume not, since that would have picked up on basic compile failures.
>
> Grr. Things like this is what makes me go "Ok, there's always the next
> merge window, maybe it will have gotten some testing by then".

Linux next didn't pick up this build failure, wierdly neither did the
powerpc build I did with this turned off, because ACPI was also off on
ppc, it was in linux-next for at least 2 days, and from what I can see
that found the ppc problems, it never found the x86 option since it was on
by default.

I'm going to just rip the nouveau bits out of the patch, btw nouveau is in
staging, so you are being a bit OTT, calm down.

Dave.

==============================================================================
TOPIC: introduce sys_membarrier(): process-wide memory barrier (v9)
http://groups.google.com/group/linux.kernel/t/c66948a2bac76935?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:10 pm
From: Mathieu Desnoyers

* Josh Triplett (josh@joshtriplett.org) wrote:
> On Thu, Feb 25, 2010 at 06:23:16PM -0500, Mathieu Desnoyers wrote:
> > I am proposing this patch for the 2.6.34 merge window, as I think it is ready
> > for inclusion.
> >
> > Here is an implementation of a new system call, sys_membarrier(), which
> > executes a memory barrier on all threads of the current process.
> [...]
>
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > Acked-by: Steven Rostedt <rostedt@goodmis.org>
> > Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > CC: Nicholas Miell <nmiell@comcast.net>
> > CC: Linus Torvalds <torvalds@linux-foundation.org>
> > CC: mingo@elte.hu
> > CC: laijs@cn.fujitsu.com
> > CC: dipankar@in.ibm.com
> > CC: akpm@linux-foundation.org
> > CC: josh@joshtriplett.org
>
> Acked-by: Josh Triplett <josh@joshtriplett.org>
>
> I agree that v9 seems ready for inclusion.

Thanks!

>
> Out of curiosity, do you have any benchmarks for the case of not
> detecting sys_membarrier dynamically? Detecting it at library
> initialization time, for instance, or even just compiling to assume its
> presence? I'd like to know how much that would improve the numbers.

Citing the patch changelog:

Results in liburcu:

Operations in 10s, 6 readers, 2 writers:

(what we previously had)
memory barriers in reader: 973494744 reads, 892368 writes
signal-based scheme: 6289946025 reads, 1251 writes

(what we have now, with dynamic sys_membarrier check, expedited scheme)
memory barriers in reader: 907693804 reads, 817793 writes
sys_membarrier scheme: 4316818891 reads, 503790 writes

So basically, yes, there is a significant overhead on the read-side if we
compare the dynamic check (0.39 ns/read per reader) to the signal-based scheme
(0.26 ns/read per reader) (which only needs the barrier()). On the update-side,
we cannot care less though.

>
> If significant, it might make sense to try to have a mechanism similar
> to SMP alternatives, to have different code in either case. dlopen,
> function pointers, runtime code patching (nop out the rmb), or similar.

Yes, definitely. It could also be useful to switch between UP and SMP primitives
dynamically when spawning the second thread in a process. We should be careful
when sharing memory maps between processes though.

Thanks,

Mathieu

>
> - Josh Triplett

--
Mathieu Desnoyers
Operating System Efficiency Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86/irq and x86/apic changes for v2.6.34
http://groups.google.com/group/linux.kernel/t/bd3bcfc4d2ef53c6?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 3:10 pm
From: "H. Peter Anvin"

Hi Linus,

The APIC- and IRQ-related changes from the x86 tree for v2.6.34 are
available in the git repository at:

ssh://master.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-apic-for-linus

Brandon Phiilps (1):
x86: Avoid race condition in pci_enable_msix()

Brandon Philips (1):
x86, irq: Keep chip_data in create_irq_nr and destroy_irq

Eric W. Biederman (2):
xen: Remove unnecessary arch specific xen irq functions.
x86: Fix out of order of gsi

H. Peter Anvin (4):
x86, apic: Reclaim IDT vectors 0x20-0x2f
x86, apic: Don't waste a vector to improve vector spread
Merge branch 'x86/urgent' into x86/irq
Merge branch 'x86/irq' into x86/apic

Ingo Molnar (1):
x86: apic: Fix mismerge, add arch_probe_nr_irqs() again

Jiri Slaby (1):
x86, ia32_aout: do not kill argument mapping

Justin P. Mattock (1):
x86: Add iMac9,1 to pci_reboot_dmi_table

Suresh Siddha (5):
x86, vmi: Fix vmi_get_timer_vector() to use IRQ0_VECTOR
x86, irq: Use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR instead of 0x1f
x86, irq: Don't block IRQ0_VECTOR..IRQ15_VECTOR's on all cpu's
x86, irq: Update the vector domain for legacy irqs handled by io-apic
x86, irq: Move __setup_vector_irq() before the first irq enable in cpu online path

Thomas Gleixner (3):
x86: Convert ioapic_lock and vector_lock to raw_spinlock
x86: Convert nmi_lock to raw_spinlock
x86: Convert i8259_lock to raw_spinlock

Yinghai Lu (8):
x86: Increase NR_IRQS and nr_irqs
x86: Fix SCI on IOAPIC != 0
irq: Remove unnecessary bootmem code
init: Move radix_tree_init() early
sparseirq: Change irq_desc_ptrs to static
sparseirq: Use radix_tree instead of ptrs array
x86, irq: Remove arch_probe_nr_irqs
smp: Use nr_cpus= to set nr_cpu_ids early

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index fbcddc5..d80930d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1794,6 +1794,12 @@ and is between 256 and 4096 characters. It is defined in the file
purges which is reported from either PAL_VM_SUMMARY or
SAL PALO.

+ nr_cpus= [SMP] Maximum number of processors that an SMP kernel
+ could support. nr_cpus=n : n >= 1 limits the kernel to
+ supporting 'n' processors. Later in runtime you can not
+ use hotplug cpu feature to put more cpu back to online.
+ just like you compile the kernel NR_CPUS=n
+
nr_uarts= [SERIAL] maximum number of UARTs to be registered.

numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
diff --git a/arch/ia64/include/asm/xen/events.h b/arch/ia64/include/asm/xen/events.h
index b8370c8..baa74c8 100644
--- a/arch/ia64/include/asm/xen/events.h
+++ b/arch/ia64/include/asm/xen/events.h
@@ -36,10 +36,6 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return !(ia64_psr(regs)->i);
}

-static inline void handle_irq(int irq, struct pt_regs *regs)
-{
- __do_IRQ(irq);
-}
#define irq_ctx_init(cpu) do { } while (0)

twitter

Tuesday, March 2, 2010

linux.kernel - 26 new messages in 20 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts