<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v2.6.20.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v2.6.20.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v2.6.20.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2007-05-02T00:34:12+00:00</updated>
<entry>
<title>Linux 2.6.20.11</title>
<updated>2007-05-02T00:34:12+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2007-05-02T00:34:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6b99a1744ab187073bca84a9fd3ccbf091865ca6'/>
<id>urn:sha1:6b99a1744ab187073bca84a9fd3ccbf091865ca6</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Revert "adjust legacy IDE resource setting (v2)"</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Bartlomiej Zolnierkiewicz</name>
<email>bzolnier@gmail.com</email>
</author>
<published>2007-04-25T20:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=481576e9872a6366227bce3838f566a3fa338d81'/>
<id>urn:sha1:481576e9872a6366227bce3838f566a3fa338d81</id>
<content type='text'>
Revert "adjust legacy IDE resource setting (v2)"

This reverts commit ed8ccee0918ad063a4741c0656fda783e02df627.

It causes hang on boot for some users and we don't yet know why:

http://bugzilla.kernel.org/show_bug.cgi?id=7562

http://lkml.org/lkml/2007/4/20/404
http://lkml.org/lkml/2007/3/25/113

Just reverse it for 2.6.21-final, having broken X server is somehow
better than unbootable system.

Signed-off-by: Bartlomiej Zolnierkiewicz &lt;bzolnier@gmail.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>cfq-iosched: fix alias + front merge bug</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>jens.axboe@oracle.com</email>
</author>
<published>2007-04-25T11:42:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3720eda544ece8fa5ade8c87e5f2cf2fb05b0ff5'/>
<id>urn:sha1:3720eda544ece8fa5ade8c87e5f2cf2fb05b0ff5</id>
<content type='text'>
There's a really rare and obscure bug in CFQ, that causes a crash in
cfq_dispatch_insert() due to rq == NULL. One example of that is seen
here:

http://lkml.org/lkml/2007/4/15/41

Neil correctly diagnosed the situation for how this can happen, read
that analysis here:

http://lkml.org/lkml/2007/4/25/57

This looks like it requires md to trigger, even though it should
potentially be possible to due with O_DIRECT (at least if you edit the
kernel and doctor some of the unplug calls).

The fix is to move the -&gt;next_rq update to when we add a request to the
rbtree. Then we remove the possibility for a request to exist in the
rbtree code, but not have -&gt;next_rq correctly updated.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>AGPGART: intel_agp: fix G965 GTT size detect</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Wang Zhenyu</name>
<email>zhenyu.z.wang@intel.com</email>
</author>
<published>2007-04-25T19:07:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab02a65798ea8b940ea5645655238c778d4e4765'/>
<id>urn:sha1:ab02a65798ea8b940ea5645655238c778d4e4765</id>
<content type='text'>
[AGPGART] intel_agp: fix G965 GTT size detect

On G965, I810_PGETBL_CTL is a mmio offset, but we wrongly take it
as pci config space offset in detecting GTT size. This one line patch
fixs this.

Signed-off-by: Wang Zhenyu &lt;zhenyu.z.wang@intel.com&gt;
Signed-off-by: Dave Jones &lt;davej@redhat.com&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ALSA: intel8x0 - Fix speaker output after S2RAM</title>
<updated>2007-05-02T00:06:03+00:00</updated>
<author>
<name>Tommi Kyntola</name>
<email>tommi.kyntola@ray.fi</email>
</author>
<published>2007-04-25T19:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=27797cc764b52d417f5daf5703d4fa9f98867185'/>
<id>urn:sha1:27797cc764b52d417f5daf5703d4fa9f98867185</id>
<content type='text'>
[ALSA] intel8x0 - Fix speaker output after S2RAM

Fixed the mute speaker problem after S2RAM on some laptops:
	http://bugme.osdl.org/show_bug.cgi?id=6181

Signed-off-by: Tommi Kyntola &lt;tommi.kyntola@ray.fi&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jaroslav Kysela &lt;perex@suse.cz&gt;
Cc: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
</entry>
<entry>
<title>hwmon/w83627ehf: Fix the fan5 clock divider write</title>
<updated>2007-05-02T00:06:02+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>khali@linux-fr.org</email>
</author>
<published>2007-04-25T07:51:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=87b814c9a7e7316ae4ea64767dbd0ae2fd6c179d'/>
<id>urn:sha1:87b814c9a7e7316ae4ea64767dbd0ae2fd6c179d</id>
<content type='text'>
Users have been complaining about the w83627ehf driver flooding their
logs with debug messages like:

w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128

or:

w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8

The reason is that we failed to actually write the LSB of the encoded
clock divider value for that fan, causing the next read to report the
same old value again and again.

Additionally, the fan number was improperly reported, making the bug
harder to find.

Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>reiserfs: fix xattr root locking/refcount bug</title>
<updated>2007-05-02T00:06:02+00:00</updated>
<author>
<name>Jeff Mahoney</name>
<email>jeffm@suse.com</email>
</author>
<published>2007-04-23T21:41:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b3bac165e24b4e5711b8bcf3ca7e7a990f5a22c'/>
<id>urn:sha1:1b3bac165e24b4e5711b8bcf3ca7e7a990f5a22c</id>
<content type='text'>
The listxattr() and getxattr() operations are only protected by a read
lock.  As a result, if either of these operations run in parallel, a race
condition exists where the xattr_root will end up being cached twice, which
results in the leaking of a reference and a BUG() on umount.

This patch refactors get_xa_root(), __get_xa_root(), and create_xa_root(),
into one get_xa_root() function that takes the appropriate locking around
the entire critical section.

Reported, diagnosed and tested by Andrea Righi &lt;a.righi@cineca.it&gt;

Signed-off-by: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Andrea Righi &lt;a.righi@cineca.it&gt;
Cc: "Vladimir V. Saveliev" &lt;vs@namesys.com&gt;
Cc: Edward Shishkin &lt;edward@namesys.com&gt;
Cc: Alex Zarochentsev &lt;zam@namesys.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Taskstats fix the structure members alignment issue</title>
<updated>2007-05-02T00:06:02+00:00</updated>
<author>
<name>Balbir Singh</name>
<email>balbir@in.ibm.com</email>
</author>
<published>2007-04-23T21:41:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b2c594d5faa4c85db286ed015df78ee02138eec'/>
<id>urn:sha1:2b2c594d5faa4c85db286ed015df78ee02138eec</id>
<content type='text'>
We broke the the alignment of members of taskstats to the 8 byte boundary
with the CSA patches.  In the current kernel, the taskstats structure is
not suitable for use by 32 bit applications in a 64 bit kernel.

On x86_64

Offsets of taskstats' members (64 bit kernel, 64 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        116,    # ac_uid
        120,    # ac_gid
        124,    # ac_pid
        128,    # ac_ppid
        132,    # ac_btime
        136,    # ac_etime
        144,    # ac_utime
        152,    # ac_stime
        160,    # ac_minflt
        168,    # ac_majflt
        176,    # coremem
        184,    # virtmem
        192,    # hiwater_rss
        200,    # hiwater_vm
        208,    # read_char
        216,    # write_char
        224,    # read_syscalls
        232,    # write_syscalls
        240,    # read_bytes
        248,    # write_bytes
        256,    # cancelled_write_bytes
    );

Offsets of taskstats' members (64 bit kernel, 32 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        12,     # cpu_count
        20,     # cpu_delay_total
        28,     # blkio_count
        36,     # blkio_delay_total
        44,     # swapin_count
        52,     # swapin_delay_total
        60,     # cpu_run_real_total
        68,     # cpu_run_virtual_total
        76,     # ac_comm
        108,    # ac_sched
        109,    # ac_pad
        112,    # ac_uid
        116,    # ac_gid
        120,    # ac_pid
        124,    # ac_ppid
        128,    # ac_btime
        132,    # ac_etime
        140,    # ac_utime
        148,    # ac_stime
        156,    # ac_minflt
        164,    # ac_majflt
        172,    # coremem
        180,    # virtmem
        188,    # hiwater_rss
        196,    # hiwater_vm
        204,    # read_char
        212,    # write_char
        220,    # read_syscalls
        228,    # write_syscalls
        236,    # read_bytes
        244,    # write_bytes
        252,    # cancelled_write_bytes
    );

This is one way to solve the problem without re-arranging structure members
is to pack the structure.  The patch adds an __attribute__((aligned(8))) to
the taskstats structure members so that 32 bit applications using taskstats
can work with a 64 bit kernel.

Using __attribute__((packed)) would break the 64 bit alignment of members.

The fix was tested on x86_64. After the fix, we got

Offsets of taskstats' members (64 bit kernel, 64 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        120,    # ac_uid
        124,    # ac_gid
        128,    # ac_pid
        132,    # ac_ppid
        136,    # ac_btime
        144,    # ac_etime
        152,    # ac_utime
        160,    # ac_stime
        168,    # ac_minflt
        176,    # ac_majflt
        184,    # coremem
        192,    # virtmem
        200,    # hiwater_rss
        208,    # hiwater_vm
        216,    # read_char
        224,    # write_char
        232,    # read_syscalls
        240,    # write_syscalls
        248,    # read_bytes
        256,    # write_bytes
        264,    # cancelled_write_bytes
    );

Offsets of taskstats' members (64 bit kernel, 32 bit application)

@taskstats'offsetof[@taskstats'indices] = (
        0,      # version
        4,      # ac_exitcode
        8,      # ac_flag
        9,      # ac_nice
        16,     # cpu_count
        24,     # cpu_delay_total
        32,     # blkio_count
        40,     # blkio_delay_total
        48,     # swapin_count
        56,     # swapin_delay_total
        64,     # cpu_run_real_total
        72,     # cpu_run_virtual_total
        80,     # ac_comm
        112,    # ac_sched
        113,    # ac_pad
        120,    # ac_uid
        124,    # ac_gid
        128,    # ac_pid
        132,    # ac_ppid
        136,    # ac_btime
        144,    # ac_etime
        152,    # ac_utime
        160,    # ac_stime
        168,    # ac_minflt
        176,    # ac_majflt
        184,    # coremem
        192,    # virtmem
        200,    # hiwater_rss
        208,    # hiwater_vm
        216,    # read_char
        224,    # write_char
        232,    # read_syscalls
        240,    # write_syscalls
        248,    # read_bytes
        256,    # write_bytes
        264,    # cancelled_write_bytes
    );

Signed-off-by: Balbir Singh &lt;balbir@linux.vnet.ibm.com&gt;
Cc: Jay Lan &lt;jlan@engr.sgi.com&gt;
Cc: Shailabh Nagar &lt;nagar@watson.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>page migration: fix NR_FILE_PAGES accounting</title>
<updated>2007-05-02T00:06:01+00:00</updated>
<author>
<name>Christoph Lameter</name>
<email>clameter@sgi.com</email>
</author>
<published>2007-04-23T21:41:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=637fc7e479a60ae55357c0e3ffeca5a475ef5733'/>
<id>urn:sha1:637fc7e479a60ae55357c0e3ffeca5a475ef5733</id>
<content type='text'>
NR_FILE_PAGES must be accounted for depending on the zone that the page
belongs to.  If we replace the page in the radix tree then we may have to
shift the count to another zone.

Suggested-by: Ethan Solomita &lt;solo@google.com&gt;
Cc: Martin Bligh &lt;mbligh@mbligh.org&gt;
Signed-off-by: Christoph Lameter &lt;clameter@sgi.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Fix possible NULL pointer access in 8250 serial driver</title>
<updated>2007-05-02T00:06:01+00:00</updated>
<author>
<name>Taku Izumi</name>
<email>izumi2005@soft.fujitsu.com</email>
</author>
<published>2007-04-23T21:41:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aad6bcca0b1ca356ede42583c96dc7ada541cffe'/>
<id>urn:sha1:aad6bcca0b1ca356ede42583c96dc7ada541cffe</id>
<content type='text'>
I encountered the following kernel panic.  The cause of this problem was
NULL pointer access in check_modem_status() in 8250.c.  I confirmed this
problem is fixed by the attached patch, but I don't know this is the
correct fix.

sadc[4378]: NaT consumption 2216203124768 [1]
Modules linked in: binfmt_misc dm_mirror dm_mod thermal processor fan
container button sg e100 eepro100 mii ehci_hcd ohci_hcd

Pid: 4378, CPU 0, comm: sadc
psr : 00001210085a2010 ifs : 8000000000000289 ip : [&lt;a000000100482071&gt;]
Not tainted
ip is at check_modem_status+0xf1/0x360
unat: 0000000000000000 pfs : 0000000000000289 rsc : 0000000000000003
rnat: 800000000000cc18 bsps: 0000000000000000 pr : 0000000000aa6a99
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a000000100481fb0 b6 : a0000001004822e0 b7 : a000000100477f20
f6 : 1003e2222222222222222 f7 : 0ffdba200000000000000
f8 : 100018000000000000000 f9 : 10002a000000000000000
f10 : 0fffdccccccccc8c00000 f11 : 1003e0000000000000000
r1 : a000000100b9af40 r2 : 0000000000000008 r3 : a000000100ad4e21
r8 : 00000000000000bb r9 : 0000000000000001 r10 : 0000000000000000
r11 : a000000100ad4d58 r12 : e0000000037b7df0 r13 : e0000000037b0000
r14 : 0000000000000001 r15 : 0000000000000018 r16 : a000000100ad4d6c
r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000
r20 : a00000010099bc88 r21 : 00000000000000bb r22 : 00000000000000bb
r23 : c003fffffc0ff3fe r24 : c003fffffc000000 r25 : 00000000000ff3fe
r26 : a0000001009b7ad0 r27 : 0000000000000001 r28 : a0000001009b7ad8
r29 : 0000000000000000 r30 : a0000001009b7ad0 r31 : a0000001009b7ad0

Call Trace:
[&lt;a000000100013940&gt;] show_stack+0x40/0xa0
sp=e0000000037b7810 bsp=e0000000037b1118
[&lt;a0000001000145a0&gt;] show_regs+0x840/0x880
sp=e0000000037b79e0 bsp=e0000000037b10c0
[&lt;a0000001000368e0&gt;] die+0x1c0/0x2c0
sp=e0000000037b79e0 bsp=e0000000037b1078
[&lt;a000000100036a30&gt;] die_if_kernel+0x50/0x80
sp=e0000000037b7a00 bsp=e0000000037b1048
[&lt;a000000100037c40&gt;] ia64_fault+0x11e0/0x1300
sp=e0000000037b7a00 bsp=e0000000037b0fe8
[&lt;a00000010000bdc0&gt;] ia64_leave_kernel+0x0/0x280
sp=e0000000037b7c20 bsp=e0000000037b0fe8
[&lt;a000000100482070&gt;] check_modem_status+0xf0/0x360
sp=e0000000037b7df0 bsp=e0000000037b0fa0
[&lt;a000000100482300&gt;] serial8250_get_mctrl+0x20/0xa0
sp=e0000000037b7df0 bsp=e0000000037b0f80
[&lt;a000000100478170&gt;] uart_read_proc+0x250/0x860
sp=e0000000037b7df0 bsp=e0000000037b0ee0
[&lt;a0000001001c16d0&gt;] proc_file_read+0x1d0/0x4c0
sp=e0000000037b7e10 bsp=e0000000037b0e80
[&lt;a0000001001394b0&gt;] vfs_read+0x1b0/0x300
sp=e0000000037b7e20 bsp=e0000000037b0e30
[&lt;a000000100139cd0&gt;] sys_read+0x70/0xe0
sp=e0000000037b7e20 bsp=e0000000037b0db0
[&lt;a00000010000bc20&gt;] ia64_ret_from_syscall+0x0/0x20
sp=e0000000037b7e30 bsp=e0000000037b0db0
[&lt;a000000000010620&gt;] __kernel_syscall_via_break+0x0/0x20
sp=e0000000037b8000 bsp=e0000000037b0db0


Fix the possible NULL pointer access in check_modem_status() in 8250.c.  The
check_modem_status() would access 'info' member of uart_port structure, but it
is not initialized before uart_open() is called.  The check_modem_status() can
be called through /proc/tty/driver/serial before uart_open() is called.

Signed-off-by: Kenji Kaneshige &lt;kaneshige.kenji@jp.fujitsu.com&gt;
Signed-off-by: Taku Izumi &lt;izumi2005@soft.fujitsu.com&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
