<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v2.6.27.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v2.6.27.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v2.6.27.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2008-10-18T17:57:22+00:00</updated>
<entry>
<title>Linux 2.6.27.2</title>
<updated>2008-10-18T17:57:22+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2008-10-18T17:57:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6bcd6d778419101dd96cbbdf03eeab8d779b1d66'/>
<id>urn:sha1:6bcd6d778419101dd96cbbdf03eeab8d779b1d66</id>
<content type='text'>
</content>
</entry>
<entry>
<title>netdrvr: atl1e: Don't take the mdio_lock in atl1e_probe</title>
<updated>2008-10-18T17:49:13+00:00</updated>
<author>
<name>Matthew Wilcox</name>
<email>matthew@wil.cx</email>
</author>
<published>2008-08-12T13:13:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6505670551fa3deeb6e5d7cab6983514384c7220'/>
<id>urn:sha1:6505670551fa3deeb6e5d7cab6983514384c7220</id>
<content type='text'>
commit f382a0a8e9403c6d7f8b2cfa21e41fefb5d0c9bd upstream

Lockdep warns about the mdio_lock taken with interrupts enabled then later
taken from interrupt context.  Initially, I considered changing these
to spin_lock_irq/spin_unlock_irq, but then I looked at atl1e_phy_init()
and saw that it calls msleep().  Sleeping while holding a spinlock is
not allowed either.

In the probe path, we haven't registered the interrupt handler, so
it can't poke at this card yet.  It's before we call register_netdev(),
so I don't think any other threads can reach this card either.  If I'm
right, we don't need a spinlock at all.

Signed-off-by: Matthew Wilcox &lt;willy@linux.intel.com&gt;
Cc: Jay Cliburn &lt;jacliburn@bellsouth.net&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>sky2: Fix WOL regression</title>
<updated>2008-10-18T17:49:13+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rjw@sisk.pl</email>
</author>
<published>2008-10-13T03:59:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0018d3e671060d5576fe99a2fe1985db4b1ea946'/>
<id>urn:sha1:0018d3e671060d5576fe99a2fe1985db4b1ea946</id>
<content type='text'>
commit 9d731d77c9794bb0a264f58d35949a1ab6dcc41c upstream

Since dev-&gt;power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
sky2_set_wol().

Remove an open-coded reference to the standard PCI PM registers that
is not used any more.

Signed-off-by: Rafael J. Wysocki &lt;rjw@sisk.pl&gt;
Cc: Tino Keitel &lt;tino.keitel@gmx.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>x86: improve UP kernel when CPU-hotplug and SMP is enabled</title>
<updated>2008-10-18T17:49:13+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-10-13T17:15:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f558a0f3f28dcdb969d56ce9bad1391d001c3b31'/>
<id>urn:sha1:f558a0f3f28dcdb969d56ce9bad1391d001c3b31</id>
<content type='text'>
commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream

num_possible_cpus() can be &gt; 1 when disabled CPUs have been accounted.

Disabled CPUs are not in the cpu_present_map, so we can use
num_present_cpus() as a safe indicator to switch to UP alternatives.

Reported-by: Chuck Ebbert &lt;cebbert@redhat.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC</title>
<updated>2008-10-18T17:49:13+00:00</updated>
<author>
<name>Andreas Herrmann</name>
<email>andreas.herrmann3@amd.com</email>
</author>
<published>2008-10-12T19:40:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e87898fdba90f9a270ae6bdb8ce98da91338a951'/>
<id>urn:sha1:e87898fdba90f9a270ae6bdb8ce98da91338a951</id>
<content type='text'>
commit 33fb0e4eb53f16af312f9698f974e2e64af39c12 upstream

On some HP nx6... laptops (e.g. nx6325) BIOS reports an IRQ0 override
but the SB450 chipset is configured such that timer interrupts goe to
INT0 of IOAPIC.

Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
timer override.

[ This more generic PCI ID based quirk should alleviate the need for
  dmi_ignore_irq0_timer_override DMI quirks. ]

Signed-off-by: Andreas Herrmann &lt;andreas.herrmann3@amd.com&gt;
Acked-by: "Maciej W. Rozycki" &lt;macro@linux-mips.org&gt;
Tested-by: Dmitry Torokhov &lt;dtor@mail.ru&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>x86, early_ioremap: fix fencepost error</title>
<updated>2008-10-18T17:49:12+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@redhat.com</email>
</author>
<published>2008-10-12T19:40:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d344a53f2e264ea07c950691c1451a4ff355694b'/>
<id>urn:sha1:d344a53f2e264ea07c950691c1451a4ff355694b</id>
<content type='text'>
commit c613ec1a7ff3714da11c7c48a13bab03beb5c376 upstream

The x86 implementation of early_ioremap has an off by one error. If we get
an object which ends on the first byte of a page we undermap by one page and
this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit
this alignment.

The size computation is currently

	last_addr = phys_addr + size - 1;
	npages = (PAGE_ALIGN(last_addr) - phys_addr)

(Consider a request for 1 byte at alignment 0...)

Closes #11693

Debugging work by Ian Campbell/Felix Geyer

Signed-off-by: Alan Cox &lt;alan@rehat.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>b43legacy: Fix failure in rate-adjustment mechanism</title>
<updated>2008-10-18T17:49:12+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2008-10-11T16:55:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=432283d2c4e674181b892d77d9ac757b0f9899ea'/>
<id>urn:sha1:432283d2c4e674181b892d77d9ac757b0f9899ea</id>
<content type='text'>
commit c6a2afdacccd56cc0be8e9a7977f0ed1509069f6 upstream
Date: Sat, 6 Sep 2008 16:51:22 -0500
Subject: b43legacy: Fix failure in rate-adjustment mechanism

A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211. The driver has been forced to remain at a 1 Mb/s rate.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>libertas: clear current command on card removal</title>
<updated>2008-10-18T17:49:12+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dcbw@redhat.com</email>
</author>
<published>2008-10-11T16:55:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a273874b531262d699d4fc1fdc0037798997a123'/>
<id>urn:sha1:a273874b531262d699d4fc1fdc0037798997a123</id>
<content type='text'>
commit 71b35f3abeb8f7f7e0afd7573424540cc5aae2d5 upstream

If certain commands were in-flight when the card was pulled or the
driver rmmod-ed, cleanup would block on the work queue stopping, but the
work queue was in turn blocked on the current command being canceled,
which didn't happen.  Fix that.

Signed-off-by: Dan Williams &lt;dcbw@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rfkill: update LEDs for all state changes</title>
<updated>2008-10-18T17:49:12+00:00</updated>
<author>
<name>Henrique de Moraes Holschuh</name>
<email>hmh@hmh.eng.br</email>
</author>
<published>2008-10-11T16:55:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=95a3690291668508570c593ccc8b69af1f0e3f3f'/>
<id>urn:sha1:95a3690291668508570c593ccc8b69af1f0e3f3f</id>
<content type='text'>
commit 417bd25ac4c6f76c8aafe8a584f3620f4a936b72 upstream

The LED state was not being updated by rfkill_force_state(), which
will cause regressions in wireless drivers that had old-style rfkill
support and are updated to use rfkill_force_state().

The LED state was not being updated when a change was detected through
the rfkill-&gt;get_state() hook, either.

Move the LED trigger update calls into notify_rfkill_state_change(),
where it should have been in the first place.  This takes care of both
issues above.

Signed-off-by: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>CIFS: make sure we have the right resume info before calling CIFSFindNext</title>
<updated>2008-10-18T17:49:11+00:00</updated>
<author>
<name>Steve French</name>
<email>sfrench@us.ibm.com</email>
</author>
<published>2008-10-11T16:55:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92fa67e9260a65f69d868c4fcc92c9cee428c6f9'/>
<id>urn:sha1:92fa67e9260a65f69d868c4fcc92c9cee428c6f9</id>
<content type='text'>
commit 0752f1522a9120f731232919f7ad904e9e22b8ce upstream

When we do a seekdir() or equivalent, we usually end up doing a
FindFirst call and then call FindNext until we get to the offset that we
want. The problem is that when we call FindNext, the code usually
doesn't have the proper info (mostly, the filename of the entry from the
last search) to resume the search.

Add a "last_entry" field to the cifs_search_info that points to the last
entry in the search. We calculate this pointer by using the
LastNameOffset field from the search parms that are returned. We then
use that info to do a cifs_save_resume_key before we call CIFSFindNext.

This patch allows CIFS to reliably pass the "telldir" connectathon test.

Signed-off-by: Jeff Layton &lt;jlayton@redhat.com&gt;
Signed-off-by: Steve French &lt;sfrench@us.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

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