[PATCH] ide: fix ide_unregister() vs. driver model
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This patch seem to have been lost, so here it is again. It fixes an Ooops
on unregistering hwifs due to the device model now having mandatory
release() functions. It also close the possible race we had on release if
the entry was in use (by or /sys typically) by using a semaphore waiting
for the release() to be called after doing an unregister.
As far as I verified this also fixes a bug when doing the
table lookup for IMM_EPP_32, that would result in "Unknown"
as IMM_EPP_32 is equal to 6 and there is the #ifdef...
ChangeSet@1.1386, 2003-09-02 00:11:07-03:00, acme@allegro.kerneljanitors.org
o scsi/*.h: remove not needed #define NULL
ChangeSet@1.1385, 2003-09-02 00:05:16-03:00, acme@allegro.kerneljanitors.org
o scsi/3w-xxx.h: use c99 style init
Rusty Russell [Mon, 1 Sep 2003 21:38:35 +0000 (14:38 -0700)]
[NET]: Use MODULE_ALIAS() in network families.
Previously, default aliases were hardwired into modutils. Now they
should be inside the modules, using MODULE_ALIAS() (they will be overridden
by any user alias).
Be a lot more careful about TS_USEDFPU and preemption
We had some races where we testecd (or set) TS_USEDFPU together
with sequences that depended on the setting (like clearing or
setting the TS flag in %cr0) and we could be preempted in between,
which screws up the FPU state, since preemption will itself change
USEDFPU and the TS flag.
This makes it a lot more explicit: the "internal" low-level FPU
functions ("__xxxx_fpu()") all require preemption to be disabled,
and the exported "real" functions will make sure that is the case.
One case - in __switch_to() - was switched to the non-preempt-safe
internal version, since the scheduler itself has already disabled
preemption.
From Tejun's posting:
>
> This patch fixes a race between del_timer_sync and recursive timers.
> Current implementation allows the value of timer->base that is used
> for timer_pending test to be fetched before finishing running_timer
> test, so it's possible for a recursive time to be pending after
> del_timer_sync. Adding smp_rmb before timer_pending removes the race.
Ben Collins [Mon, 1 Sep 2003 13:16:27 +0000 (06:16 -0700)]
[PATCH] Update IEEE1394 (r1047)
subsys : - Added hpsb_make_streampacket() helper
- Fix re-probe of bus after reset, when node's generation
changes
- Missing spinlock.h include for csr.c
general : - Fix a few warnings from size mismatches in printk's
raw1394 : - Added RAW1394_REQ_ASYNC_STREAM
- Use vmalloc/vfree for larger buffer support
ohci1394 : - Fix a few endianess bugs in ISO routines
Matthew Dharm [Mon, 1 Sep 2003 10:37:10 +0000 (03:37 -0700)]
[PATCH] sr.c should issue TEST_UNIT_READY
The linux/drivers/scsi/sr.c code will issue a MODE_SENSE[_10] command to
a device as the first command sent to the device. If the device has
just come out of reset, it will likely respond with a UNIT_ATTENTION /
NOT_READY status, which causes the MODE_SENSE to fail. In fact, the
device may have several UNIT_ATTENTION conditions queued up (power-up
reset, media change, etc.)
This results in the mode page 0x2a data not being properly read and
interpreted. As an end-effect, things like packet-writing don't work
(because the writeable bit is not set).
The solution to this is to issue one or more TEST_UNIT_READY commands to
the device to clear any pending UNIT_ATTENTION conditions. This is the
technique used by sd.c -- in fact, this code was lifted directly from
sd.c
At some point in the future, abstraction of this initial TEST_UNIT_READY
code between all high-level SCSI drivers may be apropriate. For now,
this patch makes sr.c issue TEST_UNIT_READY to clear the UNIT_ATTENTION,
thus allowing the mode page 0x2a code to work properly. Given the
approaching 2.6.0-final release, I urge that this patch be accepted.
Don't claim exclusive ownership of the device when doing
the SG_IO and SCSI_IOCTL_SEND_COMMAND ioctl's. That just
screws things up when the drive is mounted.
If somebody wants exclusive access, he should indicate that
at open time.
I've been trying to remove these, but apparently new ones crop up. Lets
just call it io scheduler, none of the ones in the kernel are using the
classic elevator algorithm.
Jeff Garzik [Mon, 1 Sep 2003 07:31:03 +0000 (03:31 -0400)]
[tokenring lanstreamer] clean up MWI / PCI_CACHE_LINE_SIZE usage
* remove PCI_CACHE_LINE_SIZE workaround, PCI core already does
this for us. (main change)
* propagate pci_set_dma_mask return value
* add 'ULL' suffix to pci_set_dma_mask arg
* propagate pci_enable_device return value
* call pci_set_mwi, check and propagate its return value
* call pci_clear_mwi and pci_disable_device on close, and probe error
* call iounmap when cleaning up
This adds support for software controlled hard drive LED activity.
This is really nice on such machines as Apple Powerbooks, where there is
no such LED in the first place and the sleep/suspend LED isn't used for
anything when the machine is running.
[IPV6]: Fix timer handling in ip6_flowlabel.c
- Use time_{before,after}() macros.
- Use mod_timer instead of del_timer/add_timer
- Properly synchronize timer resetting using ip6_fl_lock.
* The PCI layer now handles incorrect cacheline size settings,
as it should. Remove our own workarounds.
* Move pci_set_mwi up much earlier in the probe process,
and check its return value.
* Call pci_clear_mwi() in ->probe error handling
* Call pci_clear_mwi() in ->remove
Andrew Morton [Sun, 31 Aug 2003 11:36:41 +0000 (04:36 -0700)]
[PATCH] tty oops fix
Ancient bug, reported by Hiroshi Inoue <inoueh@uranus.dti.ne.jp>:
1. login to tty2 (not tty1)
2. start kon (Kanji cONsole emulator, console which support
Japanese characters)
3. exit kon
4. logout
It oopses in the debugging function check_tty_count(), walking a list_head
which has been list_del()'d. Call trace is:
#0 check_tty_count (tty=0x10d42000, routine=0xc817b00 ".paths") at include/asm/processor.h:583
#1 0x022c6c00 in do_tty_hangup (data=0x10d42000) at drivers/char/tty_io.c:426
#2 0x022c6f60 in tty_vhangup (tty=0xc817b00) at drivers/char/tty_io.c:536
#3 0x022c6fcc in disassociate_ctty (on_exit=1) at drivers/char/tty_io.c:574
#4 0x02127aee in do_exit (code=0) at kernel/exit.c:718
#5 0x02127caa in do_group_exit (exit_code=0) at kernel/exit.c:796
#6 0x02127cbc in sys_exit_group (error_code=0) at kernel/exit.c:807
The tty refcount is zero, so everything seems consistent and sensible. The
fix just uses list_del_init() on that list_head.
Heaven knows what the locking for tty->count is though. Some bizarre mixture
of BKL, tty_sem and nothing at all.
Andrew Morton [Sun, 31 Aug 2003 11:36:33 +0000 (04:36 -0700)]
[PATCH] scsi_unregister() oops fix
Some drivers such as aha1542 and aic7xxx_old will call scsi_register() and
then, if some succeeding operations fails they will call scsi_unregister(),
without an intervening scsi_set_host().
This causes an oops in scsi_put_device(), because kobj->parent is NULL.
In other words, scsi_register() immediately followed by scsi_unregister()
is guaranteed to oops.
The patch makes scsi_host_dev_release() more robust against this usage
pattern.
High Precision Event Timer (HPET) is next generation timer
hardware and has various advantages over legacy 8254
(PIT) timer, like:
- Associated registers are mapped to memory space. So, we no
longer require in and out on legacy ioports
- Memory map address is reported by ACPI (and are not
hard-coded)
- Each timer can be configured to generate separate interrupts,
even sharing lines with PCI devices
- HPET has a minimum period of 100 nanosecs and is not fixed.
Giving a flexibility of increasing the resolution in future.
- Most current implementations has 3 counters, but in future,
we can have as many as 32 timers per block, and 8
HPET timer blocks (total 256 timers)
- Can support 32bit and 64bit counting
(Refer to http://www.intel.com/labs/platcomp/hpet/hpetspec.htm
for complete specs)
The patchset that follow adds support for High Precision Event
Timer (HPET) based timer in kernel. This uses the HPET in
LegacyReplacement mode (so that counter 0 will be tied to IRQ0,
and counter 1 will be tied to IRQ 8). In this mode, HPET overrides
PIT and RTC interrupt lines. The patch will enable HPET by default,
on systems where ACPI tables reports this feature. The patch will
have no impact on systems that do not support this feature.
A major change from previous version is elimination of fixmap for HPET.
Based on Andrew Morton's suggestion, we have a new hook in init/main.c for
late_time_init(), at which time we can use ioremap, in place of fixmap.
Impact on other archs: Calibrate_delay() (and hence loops_per_jiffy
calculation) has moved down in main.c, from after time_init() to after
kmem_cache_init().
1/6 - hpet1.patch - main.c change to introduce late_time_init()
Andrew Morton [Sun, 31 Aug 2003 11:35:17 +0000 (04:35 -0700)]
[PATCH] vmscan: zone pressure simplification and fix
The zone->pressure field is supposed to record the amount of reclaim pressure
which this zone is under. We need this info so we know whether to unmap
pages from pagetables right from the outset of a balance_pgdat() or
try_to_free_pages() invokation.
The problem with the current code is that the exponential average gets tugged
around too much: as we perform the increasing-priority scan, the pressure
metric is made artificially low by the early part of the scan.
So instead what we do here is to record within the zone the scanning priority
from the zone's previous scan. It is defined as the priority at which the
zone achieved the "enough pages free" state. This prev_priority is used on
the next scan for the do-we-need-to-be-unmapping-pages decision.
Andrew Morton [Sun, 31 Aug 2003 11:35:09 +0000 (04:35 -0700)]
[PATCH] vmscan: zone pressure calculation fix
Off-by-one in balance_pgdat(): `priority' can never go negative. It causes
the scanning priority thresholds to be quite wrong and kswapd tends to go
berzerk when there is a lot of mapped memory around.
Andrew Morton [Sun, 31 Aug 2003 11:35:02 +0000 (04:35 -0700)]
[PATCH] ipc_init() uses vmalloc too early
From: Andrea Arcangeli <andrea@suse.de>
aka: "vmalloc allocations in ipc needs smp initialized (and vm must be
allowed to schedule in 2.6)"
In short if you change SEMMNI to 8192 the kernel will crash at boot, beause
it tries to call vmalloc before the smp is initialized. The reason is that
vmalloc calls into the pte alloc code, and the fast pte alloc is tried
first, but that reads into the pte_quicklist, that requires the cpu_data to
be initialized (and that happens in smp_init()).
the patch is obviously safe, since no piece of kernel (especially the code
in the check_bugs and smp_init paths ;) calls into the ipc subsystem.
The reason this started to trigger wasn't really that we increased SEMMNI,
but what happend is that some IPC data structure grown, and for some reason
the corruption due the uninitalized pte_quicklist triggers only for smp
boxes with less than 1G (not very common anymore ;). So it wasn't
immediatly reproducible on all setups.
2.6 doesn't suffer from the same problem, simply because 2.6 isn't using
the quicklist anymore, but I think it would be much more correct to make
the same change in 2.6 too, since whatever cond_resched() in the vm paths
(and they're definitely allowed to call it), will lead to a crash since the
init task isn't initialized and the scheduler can't be invoked yet. (and
2.6 already has the bigger data structures that should trigger the vmalloc
all the time on all setups)
Andrew Morton [Sun, 31 Aug 2003 11:34:53 +0000 (04:34 -0700)]
[PATCH] raw driver oops fix
From: Dave Olien <dmo@osdl.org>
The raw.c character device Oopses dereferencing a NULL pointer in
bd_claim() This problem occurred after bd_claim() in block_dev.c was
modified to "claim the whole device when a partition is claimed".
raw_open() made the mistake of calling bd_claim BEFORE calling blkdev_get().
At that time, the bdev->bd_contains field has not yet been initialized.
Switching the order allows blkdev_get() to initialize those fields before
calling bd_claim().
Also fixed up some error return paths:
igrab() should never fail under these circumstances since the caller
already has a reference to that inode through the bdev at that time.
In the event of blkdev_get() failure or set_blocksize() failure, not all
the work to unwind from the error was done.
Andrew Morton [Sun, 31 Aug 2003 11:34:26 +0000 (04:34 -0700)]
[PATCH] make voyager work again after the cpumask_t changes
From: James Bottomley <James.Bottomley@SteelEye.com>
Most is just simple fixes; however, the needless change from atomic to
non-atomic operations in smp_invalidate_interrupt() caused me a lot of
pain to track down since it introduced some very subtle bugs.
I've also taken phys_cpu_present_map out of smp.h. Since it
physid_mask_t is defined in mpspec.h anyway, and contains a duplicate
definition, I don't believe it can hurt anything.
Andrew Morton [Sun, 31 Aug 2003 11:34:11 +0000 (04:34 -0700)]
[PATCH] Use tgid rather than pid in dnotify
From: Ulrich Drepper <drepper@redhat.com>
I'm not entirely sure about this change. But it seems to be necessary.
The dnotify code stores the PID in the file structure. The entire process
shares the file and any signal (is it used for that?) should be sent to the
process (thread group), not the individual thread. Also keep in mind that
threads can go away while the process (and therefore file descriptor)
remain. And the ID of the thread can be reused.
Somebody who knows this code should take a good look.
Andrew Morton [Sun, 31 Aug 2003 11:33:50 +0000 (04:33 -0700)]
[PATCH] kbuild: warn if the user has old modutils
From: Valdis.Kletnieks@vt.edu, Sam Ravnborg <sam@ravnborg.org>
Adds an explicit check for the new modutils in the build system.
Generally we should avoid these sorts of hardwired checks for the right
versions of things, but we are still getting a significant number of problem
reports due to people not having the new tools. Let's help them out.
Andrew Morton [Sun, 31 Aug 2003 11:33:12 +0000 (04:33 -0700)]
[PATCH] large dev_t 12/12 oops fix
From: viro@parcelfarce.linux.theplanet.co.uk
On Wed, Aug 27, 2003 at 01:46:37AM -0700, Andrew Morton wrote:
>
> LILO seems to be oopsing in HDIO_GETGEO ioctl for some reason, in
> generic_ide_ioctl().
>
> I'm not sure quite why though. Could one of your patches affected this
> area?
The last one (fix for hd_struct handling). The fix follows:
Andrew Morton [Sun, 31 Aug 2003 11:32:56 +0000 (04:32 -0700)]
[PATCH] add context switch counters
From: Peter Chubb <peterc@gelato.unsw.edu.au>
Currently, the context switch counters reported by getrusage() are
always zero. The appended patch adds fields to struct task_struct to
count context switches, and adds code to do the counting.
The patch adds 4 longs to struct task struct, and a single addition to
the fast path in schedule().
projects / linux / log