Fix VIA-based TB/Decrementer calibration , previously it wouldn't work
properly with HZ != 100, causing tb_to_us to be wrong and gettimeofday()
to return strangely "off" results
There is a bug in cpufreq call back funtion in timer_tsc routines,
that can result in system deadlock. The issue is: grabbing the
write_lock on xtime_lock without disabling the interrupts. So,=20
if we happen to get a timer interrupt while we are in this code,
system will go into a deadlock.
This bug only effects the kernels that have CONFIG_CPU_FREQ enabled.
Ingo Molnar [Sat, 11 Oct 2003 12:54:53 +0000 (05:54 -0700)]
[PATCH] SMP races in the timer code
This fixes two del_timer_sync() races that are still in the timer code.
The first race was actually triggered in a 2.4 backport of the 2.6 timer
code. The second race was never triggered - it is mostly theoretical on
a standalone kernel. (It's more likely in any virtualized or otherwise
preemptable environment.)
Both races happen when self-rearming timers are used. One mainstream
example is kernel/itimer.c. The effect of the races is that
del_timer_sync() lets a timer running instead of synchronizing with it,
causing logic bugs (and crashes) in the affected kernel code. One
typical incarnation of the race is a double add_timer().
CPU0 gets stuck at the [*] code-point briefly - after the timer->base has
been set to NULL, but before the base->running_timer pointer has been set
up. This is a fundamentally volatile scenario, as there's _zero_ knowledge
in the data structures that this timer is about to be executed!
Now CPU1 comes along and calls del_timer_sync(). It will find nothing -
neither timer->base nor base->running_timer will cause it to synchronize.
It will return and report that the timer has been deleted - shortly
afterwards CPU1 continues to execute the timer fn, which will cause
crashes.
This particular race is easy to fix by reordering the timer->base
clearing with set_running_timer(), and putting a wmb() between them, but
there's more races:
race #2
The checking of del_timer_sync() for 'pending or running timer' is
fundamentally unrobust. Eg. if CPU0 gets stuck at the [***] point below:
base = &per_cpu(tvec_bases, i);
if (base->running_timer == timer) {
while (base->running_timer == timer) {
cpu_relax();
preempt_check_resched();
}
[***]
break;
}
}
smp_rmb();
if (timer_pending(timer))
goto del_again;
then del_timer_sync() has already decided that this timer is not running
(we just finished loop-waiting for it), but we have not done the
timer_pending() check yet.
If the timer has re-armed itself, and if the timer expires on CPU1 (this
needs a long delay on CPU0 but that's not hard to achieve eg. in UML or
with kernel preemption enabled), then CPU1 could start to expire the
timer and gets to the [**] point in __run_timers (see above), then CPU1
gets stalled and CPU0 is unstalled, then the timer_pending() check in
del_timer_sync() will not notice the running timer, and del_timer_sync()
returns - while CPU1 is just about to run the timer!
Fixing this second race is hard - it involves a heavy race-check
operation that has to lock all bases, and has to re-check the
base->running_timer value, and timer_pending condition atomically.
This fix also fixes the first race, due to forcing del_timer_sync() to
always observe the timer state atomically, so the [*] code point will
always synchronize with del_timer_sync().
The patch is ugly but safe, and it has fixed the crashes in the 2.4
backport. I tested the patch on 2.6.0-test7 with some heavy itimer use
and it works fine. Removing self-arming timers safely is the sole
purpose of del_timer_sync(), so there's no way around this overhead i
think. I believe we should ultimately fix all major del_timer_sync()
users to not use self-arming timers - having del_timer_sync() in the
thread-exit path is now a considerable source of SMP overhead. But this
is out of the scope of current 2.6 fixes of course, and we have to
support self-arming timers as well.
Dave Jones [Fri, 10 Oct 2003 23:31:17 +0000 (00:31 +0100)]
Merge wopr.codemonkey.org.uk:/mnt/nfs/sepia/bar/src/kernel/2.6/trees/bk-linus
into wopr.codemonkey.org.uk:/mnt/nfs/sepia/bar/src/kernel/2.6/trees/cpufreq
Dave Jones [Fri, 10 Oct 2003 23:24:13 +0000 (00:24 +0100)]
[CPUFREQ] Kill longhaul warnings
(Blah about unused variables).
This code still won't be used, as its still not tested/debugged properly
on a Nehemiah.
Dave Jones [Fri, 10 Oct 2003 21:57:10 +0000 (22:57 +0100)]
[CPUFREQ] Fix longhauls speed calculations.
We got half multipliers horribly wrong, which made us think we could
clock the CPU much higher than we actually could.
Dave Jones [Fri, 10 Oct 2003 21:02:19 +0000 (22:02 +0100)]
[CPUFREQ] Make VIA longhaul work on Samuel2 & Ezra again.
These CPUs are actually only longhaul v1 compliant.
This was catastrophic, as the MSRs moved between v1 and v2.
There was also massive confusion in the documentation regarding Ezra.
It's not another variant, so 'v2' never existed.
Renamed v3 (Powersaver) to v2 as a result of this.
[PATCH] I2C: fix i2c-dev class release function bug.
There was no release function, that was the bug :)
It caused bad messages to show up in the syslog whenever a i2c driver was removed, and could
easily oops.
Alexander Malysh [Fri, 10 Oct 2003 07:11:04 +0000 (00:11 -0700)]
[PATCH] I2C: i2c-sis630 driver fixes
attached you can find a patch that should fix i2c-sis630 driver for
2.6.0-X kernel. With i2c-sis630 from stock 2.6.0-X we have oops and
driver was not correct registered against i2c-core.
Changes:
1) fixed a oops while modprobing
2) added check for buffer overflow for i2c block data read transaction
3) added 'force' modprobe parameter. It's allow more easily
testing for not yet supported SiS chips.
Noah J. Misch [Thu, 9 Oct 2003 06:17:49 +0000 (23:17 -0700)]
[PATCH] USB: Make Ethernet Gadget depend on CONFIG_NET
Previously, one could configure a kernel that wouldn't link by doing a 'make
allnoconfig' and then a 'make menuconfig' and enabling CONFIG_EXPERIMENTAL,
CONFIG_PCI, CONFIG_USB_GADGET, and CONFIG_USB_ETH.
Noah J. Misch [Thu, 9 Oct 2003 06:17:37 +0000 (23:17 -0700)]
[PATCH] USB: Make ISD-200 USB/ATA Bridge depend on BLK_DEV_IDE
This usb driver needs ide_fix_driveid from drivers/ide/ide-ops.c, which
needs BLK_DEV_IDE ("Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy
support") to get built.
Without this patch, you can configure an un-linkable kernel by doing make
allnoconfig, make menuconfig, and setting CONFIG_PCI, CONFIG_USB,
CONFIG_USB_STORAGE, and CONFIG_USB_STORAGE_ISD200 only.
Paul Mundt [Thu, 9 Oct 2003 05:33:22 +0000 (22:33 -0700)]
[PATCH] net/sunrpc/clnt.c compile fix
net/sunrpc/clnt.c does not compile if RPC_DEBUG is not enabled, due to
the fact that tk_pid is protected by RPC_DEBUG (which in turn depends on
CONFIG_SYSCTL).
The printk's that use it don't actually need to print it out at all,
the rpc_task tag isn't really interesting here.
Matthew Wilcox [Thu, 9 Oct 2003 04:25:22 +0000 (21:25 -0700)]
[PATCH] Build fixes for zoran on PA-RISC
The Zoran driver doesn't include <asm/io.h> and thus won't compile
on architectures where that doesn't get implicitly included through
some other path.
Andi Kleen [Thu, 9 Oct 2003 04:23:31 +0000 (21:23 -0700)]
[PATCH] Prefetch workaround for Athlon/Opteron
This is the latest iteration of the workaround for the Athlon/Opteron
prefetch erratum. Sometimes the CPU would incorrectly report an
exception on prefetch.
This supercedes the previous dumb workaround of checking for AMD CPUs in
prefetch(). That one bloated the kernel by several KB and lead to lots
of unnecessary checks in hot paths.
Also this one handles user space faults too, so the kernel can
effectively isolte the user space from caring about this errata.
Instead it handles it in the slow path of the exception handler (the
check is only done when the kernel would normally trigger seg fault or
crash anyways)
All the serious criticisms to the previous patches have been addressed.
It checks segment bases now, handles vm86 mode and avoids deadlocks when
the prefetch exception happened inside mmap_sem.
This includes review and fixes from Jamie Lokier and Andrew Morton.
Opcode decoder based on code from Richard Brunner.
David Brownell [Thu, 9 Oct 2003 03:30:54 +0000 (20:30 -0700)]
[PATCH] USB: make more driver names match module names
This resolves a bug in osdl bugtraq (#1261) by making
some more driver names match their module names. Such
mismatches are bad because scripts often need to add
special cases, handling multiple names for drivers.
Paul Mackerras [Thu, 9 Oct 2003 03:30:27 +0000 (20:30 -0700)]
[PATCH] USB: Fix USB suspend in 2.6.0-test6
In drivers/usb/core/hcd-pci.c, the code forgets to set hcd->state to
USB_STATE_SUSPENDED on suspend. The effect is that on resume, the
code refuses to wake the HCD up, and instead prints a message saying
the interface hasn't been suspended.
The patch below fixes this. It is against 2.6.0-test6. With this
patch I can suspend and resume my Apple PowerBook G4, and the USB
works after resuming.
David Brownell [Thu, 9 Oct 2003 03:26:58 +0000 (20:26 -0700)]
[PATCH] USB: minor net2280 cleanup
This holds minor net2280 cleanups:
- Cleaner handling for cases where dma_alloc_coherent() must be
used instead of kmalloc(). (Kmalloc is more memory-efficient
for the "small buffers" case.) Both MIPS cases should work,
as well as others.
- Prefetch cachelines on PIO paths.
The first of those gets rid of one <linux/version.h> usage, no
longer useful now that 2.4 and 2.6 versions have forked.
Since 2.6.0-test6, ftape can't be configured as a built-in driver.
test6 changed ftape-init.c to call ftape_proc_destroy() also in
the non-MODULE case; however, ftape_proc_destroy() is only defined
when the driver is built as a module. The result is a linkage error.
This fixes this by deleting the #if MODULE around ftape_proc_destroy()'s
definition.
Michael Hunold [Thu, 9 Oct 2003 00:51:06 +0000 (17:51 -0700)]
[PATCH] Update the AV7110 DVB driver
- add vbi device handling for dvb-c cards with analog module
- fix error handling upon device initialization
- fix DD1_INIT handling of DVB-C w/ analog module installed. (Jon
Burgess)
Michael Hunold [Thu, 9 Oct 2003 00:50:57 +0000 (17:50 -0700)]
[PATCH] Misc. fixes for AT76C651 DVB frontend driver
- fixed some return values in device attach functions
- allow private data to be associated with frontend devices here, too
- misc bugfixes and performance improvements (endianess, function split up)
Michael Hunold [Thu, 9 Oct 2003 00:50:49 +0000 (17:50 -0700)]
[PATCH] Misc. fixes for ALPS TDLB7 DVB frontend driver
- applied latest changes by Juergen Peitz (great work!)
o as a workaround for the lockup problem the data valid signal is
checked after every channel switch. If it is not set FEC parameters
are set again.
o disabled autoprobing if FEC settings are known (from sp887x).
o added support for FE_READ_UNCORRECTED_BLOCKS (from sp887x).
o added support for FE_SLEEP (from sp887x).
o bit error rate is now not only read from register 0xC07 but also
from 0xC08 (from sp887x).
o I2C feedthrough to the tuner is now only enabled when needed (from
sp887x).
o Added FE_CAN_QAM_AUTO and FE_CAN_HIERARCHY_AUTO to
dvb_frontend_info.
o Removed obsolete setting of default frontend parameters in
sp8870_init.
o Removed obsolete module parameter 'loadcode' because changes in the
saa7146 driver made firmware loading very fast.
Michael Hunold [Thu, 9 Oct 2003 00:50:32 +0000 (17:50 -0700)]
[PATCH] Add private data pointer to DVB frontends
- allow private data to be associated with dvb frontend devices
(Andreas Oberritter)
- fixed fe_count countint in nxt6000 frontend driver (Andreas
Oberritter)
Michael Hunold [Thu, 9 Oct 2003 00:50:23 +0000 (17:50 -0700)]
[PATCH] Fix vbi handling in saa7146 core driver
- add some debug and safety checks for video/vbi capture buffer
handling
- add new flag SAA7146_USE_PORT_B_FOR_VBI, so we can distinguish on
which video port to apply the vbi workaround
- add del_timer(...) for vbi capture queue and vbi_read timers,
prevents oopses on vbi usage
Rusty Russell [Thu, 9 Oct 2003 00:42:03 +0000 (17:42 -0700)]
[PATCH] ipt_limit fix for HZ=1000
The range that the iptables limit extension can specify depends on HZ.
This means that rules which worked i386 2.4 (100 HZ) won't work on
2.6.
The solution is to adjust the precision based on the HZ value (keeping
the range of possible values the same). For extra geek cred, this is
done by calculating a power-of-two constant below the maximum
multiplication factor, which gcc then turns into a simple shift.
Paul Mackerras [Thu, 9 Oct 2003 00:23:30 +0000 (17:23 -0700)]
[PATCH] Fix compile on PPC
At the moment the aty128fb and matroxfb frame buffer drivers don't
compile on PPC. In both cases the error is pretty trivial. This
patch is the minimum change to fix the problems.
The _IOR() type problem fix in aty128fb.c depends on the fact that the
size of a pointer is the same as "size_t", so we don't have to use
_IOR_BAD() to keep the ioctl number the same.
Linus Torvalds [Wed, 8 Oct 2003 13:47:40 +0000 (06:47 -0700)]
disable_irq() should synchronize with irq handler only if one exists.
Noted by Al Viro: if no handler exists (and we have IRQ_INPROGRESS set
because of an earlier irq that got through), synchronize_irq() will
end up waiting forever.
Jamie Lokier [Wed, 8 Oct 2003 11:59:24 +0000 (04:59 -0700)]
[PATCH] futex bug fixes
This fixes two serious bugs in the futex code.
One is a race condition which results in list corruption when
FUTEX_REQUEUE is used. It is due to the split locks change introduced
in 2.6.0-test6, and oopses when triggered.
The other is a security hole. A program can use FUTEX_FD to create
futexes on mms or inodes which don't reference them, and when those
structures are reused by a different mm or inode, the addresses match.
The effect is that a malicious or flawed program can steal wakeups from
completely unrelated tasks, causing them to block (or worse if they are
counting on the token passing property).
These are the specific changes:
1. Each futex_q retains a reference to its key mm or inode.
2. The condition for a futex_q to indicate that it's woken can usually
be interrogated lock-free.
3. futex_wait calls the hash function once instead of three times,
and usually takes the per-bucket lock once too.
4. When a futex is woken, the per-bucket lock is not usually taken,
so that's one less cache line transfer during heavy SMP futex use.
5. The wait condition and barriers in futex_wait are simpler.
5. FUTEX_REQUEUE is fixed. The per-bucket lock juggling is done
in such a way that there are no race conditions against the tests
for whether a futex is woken.
This patch is an combination of patches previously sent to the list. An
equivalent patch has been in Andrew Morton's tree for a while, with no
failure reports. Also I have been running it on my own SMP box for a
while. Conversely, we have received an oops report for the 2.6.0-test6
code, so the fix is needed.
projects / linux / log