patch 1/2 (revised):
- Fix drive->waiting_for_dma to work with CDB-intr devices.
- Do the dma status clearing in ide_intr() and add a new
hwif->ide_dma_clear_irq for Intel ICHx controllers.
Revised per Alan, Sergei and Bart's advice.
Patch against 2.6.20-rc6. Tested ok on my ICH4 and pdc20275 adapters.
Please review/apply, thanks.
Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Going through the string and waiting for _pointer_ to become '\0'
is not what the authors meant...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Ben Collins <ben.collins@ubuntu.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The Linux kernel ignored the PROM's serial settings (115200,n,8,1 in
my case). This was because mode_prop remained "ttyX-mode" (expected:
"ttya-mode") due to the constness of string literals when used with
"char *". Since there is no "ttyX-mode" property in the PROM, Linux
always used the default 9600.
[ Investigation of the suncore.s assembler reveals that gcc optimizied
away the stores, yet did not emit a warning, which is a pretty
anti-social thing to do and is the only reason this bug lived for
so long -DaveM ]
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
On ia64, kernel headers define REGION_OFFSET so we can't use that.
Reported by Andrew Morton.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Two functions are called from __devinit context, but they are marked as
__init. Fix this.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This patch fixes a possible race that leads to double freeing an idr index.
When the master begin to close, release_dev() is called and then
pty_close() is called:
if (tty->driver->close)
tty->driver->close(tty, filp);
This is done without helding any locks other than BKL. Inside pty_close(),
being a master close, the devpts entry will be removed:
#ifdef CONFIG_UNIX98_PTYS
if (tty->driver == ptm_driver)
devpts_pty_kill(tty->index);
#endif
But devpts_pty_kill() will call get_node() that may sleep while waiting for
&devpts_root->d_inode->i_sem. When this happens and the slave is being
opened, tty_open() just found the driver and index:
driver = get_tty_driver(device, &index);
if (!driver) {
mutex_unlock(&tty_mutex);
return -ENODEV;
}
This part of the code is already protected under tty_mute. The problem is
that the slave close already got an index. Then init_dev() is called and
blocks waiting for the same &devpts_root->d_inode->i_sem.
When the master close resumes, it removes the devpts entry, and the
relation between idr index and the tty is gone. The master then sleeps
waiting for the tty_mutex on release_dev().
Slave open resumes and found no tty for that index. As result, a NULL tty
is returned and init_dev() doesn't flow to fast_track:
/* check whether we're reopening an existing tty */
if (driver->flags & TTY_DRIVER_DEVPTS_MEM) {
tty = devpts_get_tty(idx);
if (tty && driver->subtype == PTY_TYPE_MASTER)
tty = tty->link;
} else {
tty = driver->ttys[idx];
}
if (tty) goto fast_track;
The result of this, is that a new tty will be created and init_dev() returns
sucessfull. After returning, tty_mutex is dropped and master close may resume.
Master close finds it's the only use and both sides are closing, then releases
the tty and the index. At this point, the idr index is free, but slave still
has it.
Slave open then calls pty_open() and finds that tty->link->count is 0,
because there's no master and returns error. Then tty_open() calls
release_dev() which executes without any warning, as it was a case of last
slave close when the master is already closed (master->count == 0,
slave->count == 1). The tty is then released with the already released idr
index.
This normally would only issue a warning on idr_remove() but in case of a
customer's critical application, it's never too simple:
thread1: opens master, gets index X
thread1: begin closing master
thread2: begin opening slave with index X
thread1: finishes closing master, index X released
thread3: opens master, gets index X, just released
thread2: fails opening slave, releases index X <----
thread4: opens master, gets index X, init_dev() then find an already in use
and healthy tty and fails
If no more indexes are released, ptmx_open() will keep failing, as the
first free index available is X, and it will make init_dev() fail because
you're trying to "reopen a master" which isn't valid.
The patch notices when this race happens and make init_dev() fail
imediately. The init_dev() function is called with tty_mutex held, so it's
safe to continue with tty till the end of function because release_dev()
won't make any further changes without grabbing the tty_mutex.
Without the patch, on some machines it's possible get easily idr warnings
like this one:
idr_remove called for id=15 which is not allocated.
[<c02555b9>] idr_remove+0x139/0x170
[<c02a1b62>] release_mem+0x182/0x230
[<c02a28e7>] release_dev+0x4b7/0x700
[<c02a0ea7>] tty_ldisc_enable+0x27/0x30
[<c02a1e64>] init_dev+0x254/0x580
[<c02a0d64>] check_tty_count+0x14/0xb0
[<c02a4f05>] tty_open+0x1c5/0x340
[<c02a4d40>] tty_open+0x0/0x340
[<c017388f>] chrdev_open+0xaf/0x180
[<c017c2ac>] open_namei+0x8c/0x760
[<c01737e0>] chrdev_open+0x0/0x180
[<c0167bc9>] __dentry_open+0xc9/0x210
[<c0167e2c>] do_filp_open+0x5c/0x70
[<c0167a91>] get_unused_fd+0x61/0xd0
[<c0167e93>] do_sys_open+0x53/0x100
[<c0167f97>] sys_open+0x27/0x30
[<c010303b>] syscall_call+0x7/0xb
using this test application available on:
http://www.ruivo.org/~aris/pty_sodomizer.c
Signed-off-by: Aristeu Sergio Rozanski Filho <aris@ruivo.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Users have been complaining about the w83627ehf driver flooding their logs
with debug messages like:
w83627ehf 9191-0a10: Increasing fan 4 clock divider from 64 to 128
or:
w83627ehf 9191-0290: Increasing fan 4 clock divider from 4 to 8
The reason is that we failed to actually write the LSB of the encoded clock
divider value for that fan, causing the next read to report the same old value
again and again.
Additionally, the fan number was improperly reported, making the bug harder to
find.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
We only map DMA when cmd->request_bufflen is non-zero for non-sg
buffers, we thus should make the same check when unmapping.
Based upon a report from Pasi Pirhonen.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The ADEF bits in the TSCR register have different meanings in read and
write mode. For this reason ADEF has to be reset on every
read-modify-write operation.
This patch introduces a special write function for this register, which
takes care of it.
Thanks to Holger Magnussen for pointing my nose at this problem.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
All the radio drivers need video_dev, but they were depending on
VIDEO_DEV!=n. That meant that one could try to compile the driver into
the kernel when VIDEO_DEV=m, which will not work. If video_dev is a
module, then the radio drivers must be modules too.
(cherry picked from commit b10fece583)
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Autodetect LG TAPC G701D as tuner type 37, fixing
mis-detected tuners in some Hauppauge tv tuner cards.
Thanks to Adonis Papas, for pointing this out.
(cherry picked from commit 1323fbda13)
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The irq handler schedules a NAPI poll request unconditionally as soon as
the status register is not clean. It has been there - and wrong - for
ages but a recent timing change made it apparently easier to trigger.
Adrian Bunk:
backported to 2.6.16
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The PM hooks are no-op if the r8169 interface is down (i.e. !IFF_UP).
However, as the chipset is enabled, the device will not work after a
suspend/resume cycle. The patch always issue the required PCI suspend
sequence and removes the module unload/reload workaround.
Signed-off-by: Arnaud Patard <apatard@mandriva.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Initialize the timer with the rest of the private-struct.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The attached fixes an oops in the usbnet driver. The same patch is
in 2.6.21-rc1, but that one has many whitespace changes. This is much
smaller.
Signed-off-by: David Brownell <david-b@pacbell.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Fix two typos found by SiI680A documentation check. They caused the taskfile
transfer overclocking:
- in PIO mode 1 as 0x2283 must be used for both data and taskfile transfers;
- in PIO mode 2 as data and taskfile timings are swapped when writing to the
MMIO regs.
Fix coding style and trailing whitespace in enclosing statements while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This together with the phys_to_virt fix in lib/swiotlb.c::swiotlb_sync_sg
fixes video1394 DMA on machines with DMA bounce buffers, especially Intel
x86-64 machines with > 3GB RAM.
Signed-off-by: David Moore <dcm@acm.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
A ZIP or similar with unformatted media will cause crashes when attempts
are made to read/write it in some cases. This is because bs_factor is
zero and we divide by it causing an oops.
As the size of a non-accessible/non-existant media is really a bit of a
zen question it doesn't matter if non-existant media is 512 bytes per
sector or zero. Setting it to 1 causes us to generate 512 bytes/sector
accesses and error properly.
Based on a fix found lurking in an ancient bugzilla entry since about 2004 (ugghhh)
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The input_device pointer is not refcounted, which means the device may
disappear while packets are queued, causing a crash when ifb passes packets
with a stale skb->dev pointer to netif_rx().
Fix by storing the interface index instead and do a lookup where neccessary.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The determination of whether the DAC has inverted cursor logic is
broken, import the version checks the X.org driver uses to fix this.
Next, when we change the timing generator, borrow code from X.org that
does 10 NOP reads of the timing generator register afterwards to make
sure the video-enable transition occurs cleanly.
Finally, use macros for the DAC registers and fields in order to
provide documentation for the next person who reads this code.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
A serial card might have been removed when the system is resumed.
This results in a suspended port being shut down, which results in
the ports shutdown method being called twice in a row. This causes
BUGs. Avoid this by tracking the suspended state separately from
the initialised state.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
I have seen mdadm oops after successfully unloading md module.
This patch privents from unloading md module while
mdadm is polling /proc/mdstat.
Signed-off-by: Akinbou Mita <akinobu.mita@gmail.com>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
When iterating through an array, one must be careful to test one's index
variable rather than another similarly-named variable.
The loop will read off the end of conf->disks[] in the following
(pathological) case:
% dd bs=1 seek=840716287 if=/dev/zero of=d1 count=1
% for i in 2 3 4; do dd if=/dev/zero of=d$i bs=1k count=$(($i+150)); done
% ./vmlinux ubd0=root ubd1=d1 ubd2=d2 ubd3=d3 ubd4=d4
# mdadm -C /dev/md0 --level=linear --raid-devices=4 /dev/ubd[1234]
adding some printks, I saw this:
[42949374.960000] hash_spacing = 821120
[42949374.960000] cnt = 4
[42949374.960000] min_spacing = 801
[42949374.960000] j=0 size=820928 sz=820928
[42949374.960000] i=0 sz=820928 hash_spacing=820928
[42949374.960000] j=1 size=64 sz=64
[42949374.960000] j=2 size=64 sz=128
[42949374.960000] j=3 size=64 sz=192
[42949374.960000] j=4 size=1515870810 sz=1515871002
Signed-off-by: Adrian Bunk <bunk@stusta.de>
md raidX make_request functions strip off the BIO_RW_SYNC flag, thus
introducing additional latency.
Fixing this in raid1 and raid10 seems to be straightforward enough.
For our particular usage case in DRBD, passing this flag improved some
initialization time from ~5 minutes to ~5 seconds.
Signed-off-by: Lars Ellenberg <lars@linbit.com>
Acked-by: NeilBrown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
If save_raid_disk is >= 0, then the device could be a device that is
already in sync that is being re-added. So we need to default this
value to -1.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
If a drive is added with HOT_ADD_DISK rather than ADD_NEW_DISK,
saved_raid_disk isn't initialised properly, and the drive can be
included in the array without a resync.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This patch (as846) adds the IGNORE_RESIDUE flag to the unusual_devs
entry for Sony-Ericsson's P990i phone.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This patch (as749) extends the unusual_devs entry for the Sony DSC-T1 and
T5 to cover the H5 as well.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
American Megatrends did something wrong in their floppy emulator. It breaks
with both kinds of MODE SENSE which our stack sends. Alan and I tried a few
tweaks, and got LUNs sensed right, but US_FL_NO_WP_DETECT is still needed.
I set the firmware bracket to 1.00 exactly, in case AMI or Sun fix it with a
firmware update. Hey, you never know.
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Recently this entry's bcd scope was narrowed so as not to falsly apply
to bcd's other than 0x0110. But while it breaks those of a larger bcd,
it is still needed for those of a smaller bcd - so this changes the
lower bcd limit to 0x0000.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The existing unusual_devs entry for the UCR-61S2B appears to have too
wide a revision range. It matches at least one device that doesn't
respond to the initialization sequence. Perhaps the sequence needs to
be updated, or perhaps something else can be done. For now, this patch
(as764) restricts the range to include only the revision mentioned in
the original comment.
This resolves (for now!) Bugzilla entry #6950.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This combines patches from Alan Stern and Robert Schedel for two "Super Top"
drives that need the IGNORE_RESIDUE flag but have different vendor IDs.
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
When the Nokia E70 Phone is plugged in to the USB port, I get:
end_request: I/O error, dev sda, sector 1824527
sd 0:0:0:0: SCSI error: return code = 0x10070000
end_request: I/O error, dev sda, sector 1824535
sd 0:0:0:0: SCSI error: return code = 0x10070000
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
The mass storage device from Digitech designed for Flash Cards, as found
on (for example) the GNX4 device has issues with residue, similar to the
bug report at http://kerneltrap.org/node/6297. This patch adds the
faulty storage device to unusual_devs.h, this not only reduces the noise
in dmesg but also increases the transfer speeds by a factor of 7x for me
(89kB/s -> 637kB/s).
T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1210 ProdID=0003 Rev= 1.00
S: Manufacturer=DigiTech HMG
S: Product=DigiTech Mass Storage
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
Driver=usb-storage
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Signed-off-by: Jaco Kroon <jaco@kroon.co.za>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Albert Lee