The USR 997902 is based on the 8169 chipset.
The value has been extracted from the sources of the driver which
comes with the manufacturer's cdrom. Heads-up and test by TommyDrum
<mycooc@yahoo.it>.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Even after the previous fix you can still set CONFIG_ACPI_BOOT
indirectly even without CONFIG_ACPI by choosing CONFIG_PCI and
CONFIG_PCI_MMCONFIG.
That doesn't build very well either.
This makes PCI_MMCONFIG depend on ACPI, fixing that hole.
[ I guess in theory Kconfig could follow the whole chain of dependencies
for things that get selected, but that sounds insanely complicated, so
we'll just fix up these things by hand. --Linus ]
Signed-off-by: Alexander Nyberg <alexn@telia.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix 2.6.12 CONFIG_ACPI=n build regression.
CONFIG_ACPI_BOOT shall be set only if CONFIG_ACPI.
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Delete quirk_via_bridge(), restore quirk_via_irqpic() -- but now
improved to be invoked upon device ENABLE, and now only for VIA devices
-- not all devices behind VIA bridges.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There is a race in the kernel cpuset code, between the code
to handle notify_on_release, and the code to remove a cpuset.
The notify_on_release code can end up trying to access a
cpuset that has been removed. In the most common case, this
causes a NULL pointer dereference from the routine cpuset_path.
However all manner of bad things are possible, in theory at least.
The existing code decrements the cpuset use count, and if the
count goes to zero, processes the notify_on_release request,
if appropriate. However, once the count goes to zero, unless we
are holding the global cpuset_sem semaphore, there is nothing to
stop another task from immediately removing the cpuset entirely,
and recycling its memory.
The obvious fix would be to always hold the cpuset_sem
semaphore while decrementing the use count and dealing with
notify_on_release. However we don't want to force a global
semaphore into the mainline task exit path, as that might create
a scaling problem.
The actual fix is almost as easy - since this is only an issue
for cpusets using notify_on_release, which the top level big
cpusets don't normally need to use, only take the cpuset_sem
for cpusets using notify_on_release.
This code has been run for hours without a hiccup, while running
a cpuset create/destroy stress test that could crash the existing
kernel in seconds. This patch applies to the current -linus
git kernel.
Signed-off-by: Paul Jackson <pj@sgi.com>
Acked-by: Simon Derr <simon.derr@bull.net>
Acked-by: Dinakar Guniguntala <dino@in.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The original pwc author raised some questions about the reverse
engineering of the decompressor algorithms used in the pwc driver.
Having done some detailed investigation it appears those concerns that
clean room policy was not followed are reasonable. I've also had a
friendly discussion with Philips to ask their view on this.
This removes the problem items of code which reduces the pwc
functionality in the kernel a little but leaves all the framework for
setup that will be needed for decompressors in user space (where they
eventually belong). This change set is designed to be the minimal risk
change set given that 2.6.12 is hopefully close to hand, with a view to
merging the much updated pwc code in 2.6.13 series kernels.
Someone else can then redo the decompressors properly (clean room) in
user space.
Note that while its easy to say that it should have been caught earlier,
but the violation was really only obvious to someone who had access to
both the proprietary source and the 'GPL' source.
Jens Axboe pointed out that the iounmap() call in libata was occurring
too early, and some drivers (ahci, probably others) were using ioremap'd
memory after it had been unmapped.
The patch should address that problem by way of improving the libata
driver API:
* move ->host_stop() call after all ->port_stop() calls have occurred.
* create default helper function ata_host_stop(), and move iounmap()
call there.
* add ->host_stop_prewalk() hook, use it in sata_qstor.c (hi Mark).
sata_qstor appears to require the host-stop-before-port-stop ordering
that existed prior to applying the attached patch.
We fixed this bug before, but it didn't take. It may have been the case
that the problem was first noticed to occur in a CONFIG_REGPARM compile.
But it's not regparm functions that need not to make tail calls, it's
asmlinkage functions called with a user pt_regs frame on the stack
supplying their arguments. prevent_tail_call probably doesn't do anything
at all in regparm functions (your argument registers are going to be
clobbered, period). It was a braino to conditionalize that definition in
the first place.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A new driver bnx2 for Broadcom bcm5706 is available.
The patch also includes new 1000BASE-X advertisement bit definitions in
mii.h
Thanks to David Miller and Jeff Garzik for reviewing and their valuable
feedback.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
"_s" suffix is certainly of hungarian origin.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[XFRM] Call dst_check() with appropriate cookie
This fixes infinite loop issue with IPv6 tunnel mode.
Signed-off-by: Kazunori Miyazawa <kazunori@miyazawa.org>
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Correcting the list traversal makes the problem go away.
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here is a fixed up version of the reorder feature of netem.
It is the same as the earlier patch plus with the bugfix from Julio merged in.
Has expected backwards compatibility behaviour.
Go ahead and merge this one, the TCP strangeness I was seeing was due
to the reordering bug, and previous version of TSO patch.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Netem works better if there if packets are just queued in the inner discipline
rather than having a separate delayed queue. Change to use the dequeue/requeue
to peek like TBF does.
By doing this potential qlen problems with the old method are avoided. The problems
happened when the netem_run that moved packets from the inner discipline to the nested
discipline failed (because inner queue was full). This happened in dequeue, so the
effective qlen of the netem would be decreased (because of the drop), but there was
no way to keep the outer qdisc (caller of netem dequeue) in sync.
The problem window is still there since this patch doesn't address the issue of
requeue failing in netem_dequeue, but that shouldn't happen since the sequence dequeue/requeue
should always work. Long term correct fix is to implement qdisc->peek in all the qdisc's
to allow for this (needed by several other qdisc's as well).
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Handle duplication of packets in netem by re-inserting at top of qdisc tree.
This avoid problems with qlen accounting with nested qdisc. This recursion
requires no additional locking but will potentially increase stack depth.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the aic driver is now taught to speak in terms of the generic
linux devices, we can now also dispense with the transport class get
routines (since we update the parameters when the driver sees they
change) and also plumb it into the spi transport transfer agreement
reporting infrastructure.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
In IA64 kernel, sys_mmap calls do_mmap2 and do_mmap2 returns addr if
len=0, which means the mmap sys call succeeds.
Posix.1 says:
The mmap() function shall fail if:
[EINVAL] The value of len is zero.
Here is a patch to fix it.
Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
Acked-by: David Mosberger <davidm@hpl.hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
This patch basically allows any HBA attached to the SPI transport class
to declare an extra area which the mid-layer will allocate as part of
its device and target allocations.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
drivers/ieee1394/sbp2.c: In function `sbp2_check_sbp2_response':
drivers/ieee1394/sbp2.c:2154: warning: unused variable `device_type'
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This gives the HBA driver notice when a target is created and
destroyed to allow it to manage its own target based allocations
accordingly.
This is a much reduced verson of the original patch sent in by
James.Smart@Emulex.com
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
From: Marcello Maggioni <hayarms@gmail.com>
Problem: Some drives (NEC 3500, TDK 1616N, Mad-dog MD-16XDVD9, RICOH
MP5163DA, Memorex DVD9 drive and IO-DATA's too for sure), if a
CD/DVD is inserted into the tray when the system is booted and if
before the OS bootup the BIOS checked for the presence of a bootable
CD/DVD into the drive, during the IDE probe phase the drive may
result busy and remain so for the next 25/30 seconds . This cause the
drive to be skipped during the booting phase and not begin usable
until the next reboot (if the reboot goes well and the drive doesn't
timeout again).
Solution: Rising the timeout time from 10 seconds to 35 seconds
(during these 35 seconds every drive should wake up for sure
according to the tests I've done).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
a) TYPE_SDAD renamed to TYPE_RBC and taken to scsi.h
b) in sbp2.c remapping of TYPE_RPB to TYPE_DISK turned off
c) relevant places in midlayer and sd.c taught to accept TYPE_RBC
d) sd.c::sd_read_cache_type() looks into page 6 when dealing with
TYPE_RBC - these guys have writeback cache flag there and are not guaranteed
to have page 8 at all.
e) sd_read_cache_type() got an extra sanity check - it checks that
it got the page it asked for before using its contents. And screams if
mismatch had happened. Rationale: there are broken devices out there that
are "helpful" enough to go for "I don't have a page you've asked for, here,
have another one". For example, PL3507 had been caught doing just that...
f) sbp2 sets sdev->use_10_for_rw and sdev->use_10_for_ms instead
of bothering to remap READ6/WRITE6/MOD_SENSE, so most of the conversions
in there are gone now.
Incidentally, I wonder if USB storage devices that have no
mode page 8 are simply RBC ones. I haven't touched that, but it might
be interesting to check...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
sym2 version 2.2.1:
- Fix MMIO BAR detection (Thanks to Bob Picco)
- Fix odd-sized transfers with a wide bus (Thanks to Larry Stephens)
- Write posting fixes (Thanks to Thibaut Varene)
- Change one of the GFP_KERNEL allocations back into a GFP_ATOMIC
- Make CCB_BA() return a script-endian address
- Move range checks and disabling of devices from the queuecommand path
to slave_alloc()
- Remove a warning in sym_setup_cdb()
- Keep a pointer to the scsi_target instead of the scsi_dev in the tcb
- Remove a check for the upper layers passing an oversized cmd
- Replace CAM_REQ_ constants with the Linux DID_ constants
- Replace CAM_DIR_ constants with the Linux DMA_ constants
- Inline sym_read_parisc_pdc() on non-parisc systems
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
From: Stuart Hayes <Stuart_Hayes@dell.com>
The system can panic with a null pointer dereference using ide-scsi if
PIO is being done on scatter gather pages that are in high memory,
because page_address() returns 0. We are actually seeing this using a
tape drive. This patch will kmap_atomic() the pages before performing
PIO.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
* add ide_bus_match() and export ide_bus_type
* split ide_remove_driver_from_hwgroup() out of ide_unregister()
* move device cleanup from ide_unregister() to drive_release_dev()
* convert ide_driver_t->name to driver->name
* convert ide_driver_t->{attach,cleanup} to driver->{probe,remove}
* remove ide_driver_t->busy as ide_bus_type->subsys.rwsem
protects against concurrent ->{probe,remove} calls
* make ide_{un}register_driver() void as it cannot fail now
* use driver_{un}register() directly, remove ide_{un}register_driver()
* use device_register() instead of ata_attach(), remove ata_attach()
* add proc_print_driver() and ide_drivers_show(), remove ide_drivers_op
* fix ide_replace_subdriver() and move it to ide-proc.c
* remove ide_driver_t->drives, ide_drives and drives_lock
* remove ide_driver_t->drivers, drivers and drivers_lock
* remove ide_drive_t->driver and DRIVER() macro
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
While they were all just simple blobs it made sense to just free them
as we walked through and logged them. Now that there are pointers to
other objects which need refcounting, we might as well revert to
_only_ logging them in audit_log_exit(), and put the code to free them
properly in only one place -- in audit_free_aux().
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
----------------------------------------------------------
When testing ATAPI PIO data transfer on the ppc64 platform, __atapi_pio_bytes() got zero when
sg_dma_len() is used. I checked the <asm-ppc64/scatterlish.h>, the struct scatterlist is defined as:
struct scatterlist {
struct page *page;
unsigned int offset;
unsigned int length;
/* For TCE support */
u32 dma_address;
u32 dma_length;
};
#define sg_dma_address(sg) ((sg)->dma_address)
#define sg_dma_len(sg) ((sg)->dma_length)
So, if the scatterlist is not DMA mapped, sg_dma_len() will return zero on ppc64.
The same problem should occur on the x86-64 platform.
On the i386 platform, sg_dma_len() returns sg->length, that's why the problem does not occur on an i386.
Changes:
- Use sg->length if the scatterlist is not DMA mapped (yet).
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Francois Romieu