Documentation/video4linux/CARDLIST.au0828 | 2
Makefile | 2
arch/x86/kernel/alternative.c | 2
arch/x86/kernel/early-quirks.c | 48 +++++++++++
arch/x86/kernel/io_apic_32.c | 3
arch/x86/mm/ioremap.c | 2
drivers/base/core.c | 25 ++++-
drivers/char/tty_io.c | 2
drivers/gpu/drm/i915/i915_dma.c | 2
drivers/md/md.c | 6 -
drivers/media/dvb/siano/sms-cards.c | 4
drivers/media/video/au0828/au0828-cards.c | 3
drivers/media/video/tvaudio.c | 2
drivers/net/atl1e/atl1e_main.c | 2
drivers/net/sky2.c | 19 +---
drivers/net/wireless/ath9k/core.h | 2
drivers/net/wireless/ath9k/main.c | 8 +
drivers/net/wireless/b43legacy/xmit.c | 2
drivers/net/wireless/libertas/main.c | 20 ++++
drivers/usb/core/hcd.c | 4
drivers/usb/core/hcd.h | 6 +
drivers/usb/gadget/s3c2410_udc.c | 2
drivers/usb/gadget/u_ether.c | 7 +
drivers/usb/host/ehci-hcd.c | 15 +++
drivers/usb/host/ohci-hcd.c | 3
drivers/usb/host/ohci-hub.c | 87 ++++++++++++--------
drivers/usb/host/uhci-hcd.c | 3
drivers/usb/musb/Kconfig | 4
drivers/usb/musb/cppi_dma.h | 4
drivers/usb/musb/davinci.c | 20 ----
drivers/usb/musb/musb_core.c | 8 -
drivers/usb/musb/musb_host.c | 6 -
drivers/video/console/fbcon.c | 4
fs/cifs/cifsglob.h | 1
fs/cifs/cifssmb.c | 4
fs/cifs/readdir.c | 128 +++++++++++++++---------------
fs/xfs/linux-2.6/xfs_buf.c | 3
fs/xfs/linux-2.6/xfs_buf.h | 8 +
fs/xfs/linux-2.6/xfs_super.c | 2
fs/xfs/xfs_log.c | 7 -
kernel/module.c | 2
kernel/sched_rt.c | 8 -
net/mac80211/debugfs_netdev.c | 14 ++-
net/mac80211/wext.c | 2
net/rfkill/rfkill.c | 5 -
45 files changed, 328 insertions(+), 185 deletions(-)
New commits:
commit 322df44ba33ce740d4980019d7202e6f6a3df53c
Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Date: Wed Oct 22 14:38:01 2008 -0700
Linux 2.6.27.3
commit cd9f58efb861a86283931f3db17aa2a4fe4da642
Author: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Fri Oct 10 21:16:12 2008 -0700
security: avoid calling a NULL function pointer in drivers/video/tvaudio.c
commit 5ba2f67afb02c5302b2898949ed6fc3b3d37dcf1 upstream
NULL function pointers are very bad security wise. This one got caught by
kerneloops.org quite a few times, so it's happening in the field....
Fix is simple, check the function pointer for NULL, like 6 other places
in the same function are already doing.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 686c714cce06e8804e15daf7ce3d4f80c35c6a69
Author: Michael Krufky <[EMAIL PROTECTED]>
Date: Sat Oct 18 10:36:06 2008 -0400
DVB: sms1xxx: support two new revisions of the Hauppauge WinTV MiniStick
(cherry picked from commit 3dfbe31f09fb1da5f17437fd384cdfb6114765d9)
DVB: sms1xxx: support two new revisions of the Hauppauge WinTV MiniStick
Autodetect 2040:5520 and 2040:5530 as Hauppauge WinTV MiniStick
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 3937df1fec50759893da5d9fa675cbc3a74eb6b2
Author: Michael Krufky <[EMAIL PROTECTED]>
Date: Sat Oct 18 10:36:01 2008 -0400
DVB: au0828: add support for another USB id for Hauppauge HVR950Q
(cherry picked from commit a636da6bab3307fc8c6e6a22a63b0b25ba0687be)
DVB: au0828: add support for another USB id for Hauppauge HVR950Q
Add autodetection support for a new revision of the Hauppauge HVR950Q
(2040:721e)
Signed-off-by: Michael Krufky <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit f8d61d1be61999a76cb207125d3bfb1885cd40eb
Author: Matthias Hopf <[EMAIL PROTECTED]>
Date: Sat Oct 18 07:18:05 2008 +1000
drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)
commit 4b40893918203ee1a1f6a114316c2a19c072e9bd upstream
Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.
It only affects the Intel G33 series and newer.
Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit ee3b0b543db121a5fe144d755fcb7c0429d1fa50
Author: David Brownell <[EMAIL PROTECTED]>
Date: Fri Oct 17 23:10:16 2008 +0000
usb: musb_hdrc build fixes
commit c767c1c6f1febbd1351cc152bba6e37889322d17 upstream
Minor musb_hdrc updates:
- so it'll build on DaVinci, given relevant platform updates;
* remove support for an un-shipped OTG prototype
* rely on gpiolib framework conversion for the I2C GPIOs
* the <asm/arch/hdrc_cnf.h> mechanism has been removed
- catch comments up to the recent removal of the per-SOC header
with the silicon configuration data;
- and remove two inappropriate "inline" declarations which
just bloat host side code.
There are still some more <asm/arch/XYZ.h> ==> <mach/XYZ.h>
changes needed in this driver, catching up to the relocation
of most of the include/asm-arm/arch-* contents.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 4e4ce5b5cb10b08eeafff642b286eb302d53f7eb
Author: David Brownell <[EMAIL PROTECTED]>
Date: Fri Oct 17 23:10:12 2008 +0000
usb gadget: cdc ethernet notification bugfix
commit 29bac7b7661bbbdbbd32bc1e6cedca22f260da7f upstream
Bugfix for the new CDC Ethernet code: as part of activating the
network interface's USB link, make sure its link management code
knows whether the interface is open or not.
Without this fix, the link won't work right when it's brought up
before the link is active ... because the initial notification it
sends will have the wrong link state (down, not up). Makes it
hard to bridge these links (on the host side), among other things.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit c78487b1d935d938014ddbec7b3d5816c1580fce
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Fri Oct 17 23:10:07 2008 +0000
USB: EHCI: log a warning if ehci-hcd is not loaded first
commit 9beeee6584b9aa4f9192055512411484a2a624df upstream
This patch (as1139) adds a warning to the system log whenever ehci-hcd
is loaded after ohci-hcd or uhci-hcd. Nowadays most distributions are
pretty good about not doing this; maybe the warning will help convince
anyone still doing it wrong.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 1f41088c56185a338b1e916a95c2ce11e3996e6a
Author: Yauhen Kharuzhy <[EMAIL PROTECTED]>
Date: Fri Oct 17 23:10:20 2008 +0000
USB: Fix s3c2410_udc usb speed handling
commit f9e9cff613b8239ce9159735aa662c9c85b478bf upstream
The new composite framework revealed a weakness in the
s3c2410_udc driver gadget register function. Instead of
checking if speed asked for was USB_LOW_SPEED upon
usb_gadget_register() to deny service, it checked only
for USB_FULL_SPEED, thus denying service to usb high
speed capable gadgets (like g_ether).
Signed-off-by: Yauhen Kharuzhy <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 48e12d72efd753818139a1870ee840ceb1a776e3
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Fri Oct 17 23:10:03 2008 +0000
USB: OHCI: fix endless polling behavior
commit 71b7497c078a97e2afb774ad7c1f8ff5bdda8a60 upstream
This patch (as1149) fixes an obscure problem in OHCI polling. In the
current code, if the RHSC interrupt status flag turns on at a time
when RHSC interrupts are disabled, it will remain on forever:
The interrupt handler is the only place where RHSC status
gets turned back off;
The interrupt handler won't turn RHSC status off because it
doesn't turn off status flags if the corresponding interrupt
isn't enabled;
RHSC interrupts will never get enabled because
ohci_root_hub_state_changes() doesn't reenable RHSC if RHSC
status is on!
As a result we will continue polling indefinitely instead of reverting
to interrupt-driven operation, and the root hub will not autosuspend.
This particular sequence of events is not at all unusual; in fact
plugging a USB device into an OHCI controller will usually cause it to
occur.
Of course, this is a bug. The proper thing to do is to turn off RHSC
status just before reading the actual port status values. That way
either a port status change will be detected (if it occurs before the
status read) or it will turn RHSC back on. Possibly both, but that
won't hurt anything.
We can still check for systems in which RHSC is totally broken, by
re-reading RHSC after clearing it and before reading the port
statuses. (This re-read has to be done anyway, to post the earlier
write.) If RHSC is on but no port-change statuses are set, then we
know that RHSC is broken and we can avoid re-enabling it.
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 5bad3352aa6262a0e4515315060d93d691913399
Author: Alan Stern <[EMAIL PROTECTED]>
Date: Fri Oct 17 23:10:23 2008 +0000
OHCI: Allow broken controllers to auto-stop
commit 4a511bc3f5829bc18428bcf11c25417a79d09396 upstream
This patch (as1134) attempts to improve the way we handle OHCI
controllers with broken Root Hub Status Change interrupt support. In
these controllers the RHSC interrupt bit essentially never turns off,
making RHSC interrupts useless -- they have to remain permanently
disabled.
Such controllers should still be allowed to turn off their root hubs
when no devices are attached. Polling for new connections can
continue while the root hub is suspended. The patch implements this
feature. (It won't have much effect unless CONFIG_PM is enabled and
CONFIG_USB_SUSPEND is disabled, but since the overhead is very small
we may as well do it.)
Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit dd1f7982f569821f0f35237644e1900456adc58e
Author: Luis R. Rodriguez <[EMAIL PROTECTED]>
Date: Fri Oct 3 15:45:26 2008 -0700
ath9k: fix oops on trying to hold the wrong spinlock
commit a477e4e6d48d3ac7c7a75bad40585cb391e5c237 upstream
We were trying to hold the wrong spinlock due to a typo
on IEEE80211_BAR_CTL_TID_S's definition. We use this to
compute the tid number and then hold this this tid number's
spinlock.
Tested-by: Steven Noonan <[EMAIL PROTECTED]>
Signed-off-by: Vasanthakumar Thiagarajan <[EMAIL PROTECTED]>
Signed-off-by: Sujith <[EMAIL PROTECTED]>
Signed-off-by: Luis R. Rodriguez <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit c068663ae65e507814545b59a8e2090f48a85613
Author: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sun Oct 12 14:30:44 2008 +0200
xfs: fix remount rw with unrecognized options
commit 6c5e51dae2c37127e00be392f40842e08077e96a upstream
When we skip unrecognized options in xfs_fs_remount we should just break
out of the switch and not return because otherwise we may skip clearing
the xfs-internal read-only flag. This will only show up on some
operations like touch because most read-only checks are done by the VFS
which thinks this filesystem is r/w. Eventually we should replace the
XFS read-only flag with a helper that always checks the VFS flag to make
sure they can never get out of sync.
Bug reported and fix verified by Marcel Beister on #xfs.
Bug fix verified by updated xfstests/189.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Acked-by: Eric Sandeen <[EMAIL PROTECTED]>
Signed-off-by: Timothy Shimmin <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 72da00bb9053a46e338496def4225febb5137ed3
Author: Chris Webb <[EMAIL PROTECTED]>
Date: Thu Oct 16 19:05:16 2008 +0000
md: Fix rdev_size_store with size == 0
commit 7d3c6f8717ee6c2bf6cba5fa0bda3b28fbda6015 upstream
Fix rdev_size_store with size == 0.
size == 0 means to use the largest size allowed by the
underlying device and is used when modifying an active array.
This fixes a regression introduced by
commit d7027458d68b2f1752a28016dcf2ffd0a7e8f567
Signed-off-by: Chris Webb <[EMAIL PROTECTED]>
Signed-off-by: NeilBrown <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit f76f2408cccf448917c8a2a2b775571fd60aee30
Author: Johannes Berg <[EMAIL PROTECTED]>
Date: Thu Oct 16 19:05:12 2008 +0000
ath9k/mac80211: disallow fragmentation in ath9k, report to userspace
commit 4233df6b748193d45f79fb7448991a473061a65d upstream
As I've reported, ath9k currently fails utterly when fragmentation
is enabled. This makes ath9k "support" hardware fragmentation by
not supporting fragmentation at all to avoid the double-free issue.
The patch also changes mac80211 to report errors from the driver
operation to userspace.
That hack in ath9k should be removed once the rate control algorithm
it has is fixed, and we can at that time consider removing the hw
fragmentation support entirely since it's not used by any driver.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Acked-by: Luis R. Rodriguez <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 02d4bc2c23cabd7930011b4d030807db2c6604a2
Author: Cornelia Huck <[EMAIL PROTECTED]>
Date: Thu Oct 16 22:05:07 2008 +0000
Driver core: Clarify device cleanup.
commit 5739411acbaa63a6c22c91e340fdcdbcc7d82a51 upstream
Make the comments on how to use device_initialize(), device_add()
and device_register() a bit clearer - in particular, explicitly
note that put_device() must be used once we tried to add the device
to the hierarchy.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit c552cad06920b6dc20bb0b41bbb37b60f194e46a
Author: Cornelia Huck <[EMAIL PROTECTED]>
Date: Thu Oct 16 22:05:05 2008 +0000
Driver core: Fix cleanup in device_create_vargs().
commit 286661b3777897220ecfcd774bccc68a34667f39 upstream
If device_register() in device_create_vargs() fails, the device
must be cleaned up with put_device() (which is also fine on NULL)
instead of kfree().
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 0b84283d642d6865e15ddad62dd2f1a092812f5a
Author: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Thu Oct 16 22:05:10 2008 +0000
modules: fix module "notes" kobject leak
commit e94320939f44e0cbaccc3f259a5778abced4949c upstream
Fix "notes" kobject leak
It happens every rmmod if KALLSYMS=y and SYSFS=y.
# modprobe foo
kobject: 'foo' (ffffffffa00743d0): kobject_add_internal: parent: 'module',
set: 'module'
kobject: 'holders' (ffff88017e7c5770): kobject_add_internal: parent: 'foo',
set: '<NULL>'
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'notes' (ffff88017fa9b668): kobject_add_internal: parent: 'foo',
set: '<NULL>'
^^^^^
# rmmod foo
kobject: 'holders' (ffff88017e7c5770): kobject_cleanup
kobject: 'holders' (ffff88017e7c5770): auto cleanup kobject_del
kobject: 'holders' (ffff88017e7c5770): calling ktype release
kobject: (ffff88017e7c5770): dynamic_kobj_release
kobject: 'holders': free name
kobject: 'foo' (ffffffffa00743d0): kobject_cleanup
kobject: 'foo' (ffffffffa00743d0): does not have a release() function, it
is broken and must be fixed.
kobject: 'foo' (ffffffffa00743d0): auto cleanup 'remove' event
kobject: 'foo' (ffffffffa00743d0): kobject_uevent_env
kobject: 'foo' (ffffffffa00743d0): fill_kobj_path: path = '/module/foo'
kobject: 'foo' (ffffffffa00743d0): auto cleanup kobject_del
kobject: 'foo': free name
[whooops]
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit e6e5cdaae090c6c5c5bfe7d058983cd464269ca6
Author: Oleg Nesterov <[EMAIL PROTECTED]>
Date: Thu Oct 16 19:05:07 2008 +0000
fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles
commit 232fb69a53a5ec3f22a8104d447abe4806848a8f upstream
echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
console. Result:
BUG: unable to handle kernel paging request at ffffc20005d00000
IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
Oops: 0002 [1] SMP
CPU 1
Modules linked in: [...a lot...]
Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
RIP: 0010:[bitfill_aligned+149/265] [bitfill_aligned+149/265]
bitfill_aligned+0x95/0x109
RSP: 0018:ffff81007d811bc8 EFLAGS: 00010216
RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
FS: 0000000000000000(0000) GS:ffff81007e004780(0000)
knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process events/1 (pid: 10, threadinfo ffff81007d810000, task
ffff81007d808000)
Stack: ffff81007c9d75a0 0000000000000000 0000000000000000
ffff81007d811c80
ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
Call Trace:
[cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
[soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
[ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
[fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
[fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
[redraw_screen+261/481] redraw_screen+0x105/0x1e1
[ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
[complete_change_console+48/190] complete_change_console+0x30/0xbe
[change_console+115/120] change_console+0x73/0x78
[console_callback+0/292] ? console_callback+0x0/0x124
[console_callback+97/292] console_callback+0x61/0x124
[schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
[run_workqueue+139/282] run_workqueue+0x8b/0x11a
[worker_thread+221/238] worker_thread+0xdd/0xee
[autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
[worker_thread+0/238] ? worker_thread+0x0/0xee
[kthread+73/118] kthread+0x49/0x76
[child_rip+10/18] child_rip+0xa/0x12
[kthread+0/118] ? kthread+0x0/0x76
[child_rip+0/18] ? child_rip+0x0/0x12
Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
of fbcon_ops->rotate, and vc_resize() has no effect because it is called
with
new_cols/rows == ->vc_cols/rows.
Tested on 2.6.26.5-45.fc9.x86_64, but
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
have the same problem.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Cc: Krzysztof Helt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 6bcd6d778419101dd96cbbdf03eeab8d779b1d66
Author: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Date: Sat Oct 18 10:57:22 2008 -0700
Linux 2.6.27.2
commit 6505670551fa3deeb6e5d7cab6983514384c7220
Author: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Tue Aug 12 07:13:14 2008 -0600
netdrvr: atl1e: Don't take the mdio_lock in atl1e_probe
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 <[EMAIL PROTECTED]>
Cc: Jay Cliburn <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 0018d3e671060d5576fe99a2fe1985db4b1ea946
Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
Date: Sun Oct 12 20:59:48 2008 -0700
sky2: Fix WOL regression
commit 9d731d77c9794bb0a264f58d35949a1ab6dcc41c upstream
Since dev->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 <[EMAIL PROTECTED]>
Cc: Tino Keitel <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit f558a0f3f28dcdb969d56ce9bad1391d001c3b31
Author: Thomas Gleixner <[EMAIL PROTECTED]>
Date: Mon Oct 13 17:15:23 2008 +0000
x86: improve UP kernel when CPU-hotplug and SMP is enabled
commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream
num_possible_cpus() can be > 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 <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit e87898fdba90f9a270ae6bdb8ce98da91338a951
Author: Andreas Herrmann <[EMAIL PROTECTED]>
Date: Sun Oct 12 19:40:11 2008 +0000
x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC
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 <[EMAIL PROTECTED]>
Acked-by: "Maciej W. Rozycki" <[EMAIL PROTECTED]>
Tested-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit d344a53f2e264ea07c950691c1451a4ff355694b
Author: Alan Cox <[EMAIL PROTECTED]>
Date: Sun Oct 12 19:40:08 2008 +0000
x86, early_ioremap: fix fencepost error
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 <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 432283d2c4e674181b892d77d9ac757b0f9899ea
Author: Larry Finger <[EMAIL PROTECTED]>
Date: Sat Oct 11 16:55:21 2008 +0000
b43legacy: Fix failure in rate-adjustment mechanism
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 <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit a273874b531262d699d4fc1fdc0037798997a123
Author: Dan Williams <[EMAIL PROTECTED]>
Date: Sat Oct 11 16:55:19 2008 +0000
libertas: clear current command on card removal
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 <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 95a3690291668508570c593ccc8b69af1f0e3f3f
Author: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Date: Sat Oct 11 16:55:13 2008 +0000
rfkill: update LEDs for all state changes
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->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 <[EMAIL PROTECTED]>
Acked-by: Ivo van Doorn <[EMAIL PROTECTED]>
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 92fa67e9260a65f69d868c4fcc92c9cee428c6f9
Author: Steve French <[EMAIL PROTECTED]>
Date: Sat Oct 11 16:55:11 2008 +0000
CIFS: make sure we have the right resume info before calling CIFSFindNext
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 <[EMAIL PROTECTED]>
Signed-off-by: Steve French <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 074555fe0e36c1bde7795e8f3f7350d228b9dd1c
Author: Alan Cox <[EMAIL PROTECTED]>
Date: Mon Oct 13 10:38:46 2008 +0100
tty: Termios locking - sort out real_tty confusions and lock reads
commit 8f520021837d45c47d0ab57e7271f8d88bf7f3a4 upstream
(only the tty_io.c portion of this commit)
This moves us towards sanity and should mean our termios locking is now
complete and comprehensive.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 769b0455c1ec257b9e5067129accab1a6052de4c
Author: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Fri Oct 10 17:28:29 2008 +1100
Fix barrier fail detection in XFS
commit 73f6aa4d44ab6157badc456ddfa05b31e58de5f0 upstream.
Currently we disable barriers as soon as we get a buffer in xlog_iodone
that has the XBF_ORDERED flag cleared. But this can be the case not only
for buffers where the barrier failed, but also the first buffer of a
split log write in case of a log wraparound. Due to the disabled
barriers we can easily get directory corruption on unclean shutdowns.
So instead of using this check add a new buffer flag for failed barrier
writes.
This is a regression vs 2.6.26 caused by patch to use the right macro
to check for the ORDERED flag, as we previously got true returned for
every buffer.
Thanks to Toei Rei for reporting the bug.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Reviewed-by: Eric Sandeen <[EMAIL PROTECTED]>
Reviewed-by: David Chinner <[EMAIL PROTECTED]>
Signed-off-by: Tim Shimmin <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 60b216fffd66fc2ad2824a05d6838aff6b59d827
Author: Johannes Berg <[EMAIL PROTECTED]>
Date: Fri Oct 10 17:52:49 2008 +0200
mac80211: fix two issues in debugfs
Not in trees above 2.6.27 as it is fixed differently in .28.
This fixes RHBZ 466264, whenever the master interface is
renamed this code would BUG_ON. Also fixes a separately
reported bug with the debugfs dir being NULL.
This patch is not applicable to the next kernel version
because both these issues have been fixed, the first one
by not having the master interface have a ieee80211_ptr
at all, and the second one by also leaving the function
early.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Cc: John Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit 7ae3a769f9cbde6564b7335b0ea45d19066c7f7c
Author: Stefan Bader <[EMAIL PROTECTED]>
Date: Sat Sep 27 11:07:30 2008 -0400
x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.
Not in upstream above 2.6.27 due to change in the way this code works
(has been fixed differently there.)
Someone from the community found out, that after repeatedly unloading
and loading a device driver that uses MSI IRQs, the system eventually
assigned the vector initially reserved for IRQ0 to the device driver.
The reason for this is, that although IRQ0 is tied to the
FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
corresponding bit in the used_vectors map is not set. So, if vectors are
released and assigned often enough, the vector will get assigned to
another interrupt. This happens more often with MSI interrupts as those
are exclusively using a vector.
Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.
Signed-off-by: Stefan Bader <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
commit d49d50a98a807e9322bc287e5da26d70168cd4c0
Author: Dario Faggioli <[EMAIL PROTECTED]>
Date: Fri Oct 10 20:15:02 2008 +0000
sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream
While working on the new version of the code for SCHED_SPORADIC I
noticed something strange in the present throttling mechanism. More
specifically in the throttling timer handler in sched_rt.c
(do_sched_rt_period_timer()) and in rt_rq_enqueue().
The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
asks for rescheduling if the runqueue has a sched_entity associated to
it (i.e., rt_rq->rt_se != NULL).
Now, if the runqueue is the root rq (which has a rt_se = NULL)
rescheduling does not take place, and it is delayed to some undefined
instant in the future.
This imply some random bandwidth usage by the RT tasks under throttling.
For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
task will get less than 95%. In our tests we got something varying
between 70% to 95%.
Using smaller time values, e.g., 95ms/100ms, things are even worse, and
I can see values also going down to 20-25%!!
The tests we performed are simply running 'yes' as a SCHED_FIFO task,
and checking the CPU usage with top, but we can investigate thoroughly
if you think it is needed.
Things go much better, for us, with the attached patch... Don't know if
it is the best approach, but it solved the issue for us.
Signed-off-by: Dario Faggioli <[EMAIL PROTECTED]>
Signed-off-by: Michael Trimarchi <[EMAIL PROTECTED]>
Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=322df44ba33ce740d4980019d7202e6f6a3df53c
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=cd9f58efb861a86283931f3db17aa2a4fe4da642
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=686c714cce06e8804e15daf7ce3d4f80c35c6a69
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=3937df1fec50759893da5d9fa675cbc3a74eb6b2
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=f8d61d1be61999a76cb207125d3bfb1885cd40eb
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=ee3b0b543db121a5fe144d755fcb7c0429d1fa50
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=4e4ce5b5cb10b08eeafff642b286eb302d53f7eb
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=c78487b1d935d938014ddbec7b3d5816c1580fce
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=1f41088c56185a338b1e916a95c2ce11e3996e6a
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=48e12d72efd753818139a1870ee840ceb1a776e3
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=5bad3352aa6262a0e4515315060d93d691913399
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=dd1f7982f569821f0f35237644e1900456adc58e
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=c068663ae65e507814545b59a8e2090f48a85613
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=72da00bb9053a46e338496def4225febb5137ed3
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=f76f2408cccf448917c8a2a2b775571fd60aee30
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=02d4bc2c23cabd7930011b4d030807db2c6604a2
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=c552cad06920b6dc20bb0b41bbb37b60f194e46a
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=0b84283d642d6865e15ddad62dd2f1a092812f5a
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=e6e5cdaae090c6c5c5bfe7d058983cd464269ca6
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=6bcd6d778419101dd96cbbdf03eeab8d779b1d66
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=6505670551fa3deeb6e5d7cab6983514384c7220
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=0018d3e671060d5576fe99a2fe1985db4b1ea946
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=f558a0f3f28dcdb969d56ce9bad1391d001c3b31
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=e87898fdba90f9a270ae6bdb8ce98da91338a951
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=d344a53f2e264ea07c950691c1451a4ff355694b
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=432283d2c4e674181b892d77d9ac757b0f9899ea
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=a273874b531262d699d4fc1fdc0037798997a123
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=95a3690291668508570c593ccc8b69af1f0e3f3f
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=92fa67e9260a65f69d868c4fcc92c9cee428c6f9
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=074555fe0e36c1bde7795e8f3f7350d228b9dd1c
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=769b0455c1ec257b9e5067129accab1a6052de4c
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=60b216fffd66fc2ad2824a05d6838aff6b59d827
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=7ae3a769f9cbde6564b7335b0ea45d19066c7f7c
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=d49d50a98a807e9322bc287e5da26d70168cd4c0
_______________________________________________
svn mailing list
[email protected]
http://mailman.vyatta.com/mailman/listinfo/svn
