The proper designator of an invalid CSR address is ~(u64)0, not (u64)0.
Use the correct value in initialization and deregistration.
Also, scsi_id->sbp2_lun does not need to be initialized twice.
(scsi_id was kzalloc'd.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
I've been experimenting to track down the cause of suspend/resume problems
on my Compaq Presario X1050 laptop:
http://bugzilla.kernel.org/show_bug.cgi?id=6075
Essentially the ACPI Embedded Controller and keyboard controller would
get into a bizarre, confused state after resume.
I found that unloading the ohci1394 module before suspend and reloading it
after resume made the problem go away. Diffing the dmesg output from
resume, with and without the module loaded, I found that with the module
loaded I was missing these:
PM: Writing back config space on device 0000:02:00.0 at offset 1. (Was 2100080, writing 2100007)
PM: Writing back config space on device 0000:02:00.0 at offset 3. (Was 0, writing 8008)
PM: Writing back config space on device 0000:02:00.0 at offset 4. (Was 0, writing 90200000)
PM: Writing back config space on device 0000:02:00.0 at offset 5. (Was 1, writing 2401)
PM: Writing back config space on device 0000:02:00.0 at offset f. (Was 20000100, writing 2000010a)
The default PCI driver performs the pci_restore_state when no driver is
loaded for the device. When the ohci1394 driver is loaded, it is supposed
to do this, however it appears not to do so.
I created the patch below and tested it, and it appears to resolve the
suspend problems I was having with the module loaded. I only added in the
pci_save_state and pci_restore_state - however, though I know little of
this hardware, surely the driver should really be doing more than this when
suspending and resuming? Currently it does almost nothing, what if there
are commands in progress, etc?
Signed-off-by: Robert Hancock <hancockr@shaw.ca>
Cc: Jody McIntyre <scjody@modernduck.com>
Cc: Ben Collins <bcollins@debian.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
It seems to have worked without the attribute during all the years
just because sizes of all struct members are multiples of 32 bits.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
It appears I will not get it fixed overnight.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
If sbp2 is forced to move data via ARM handler, the maximum packet size
allowed for S800 transfers exceeds ohci1394's buffer size on platforms
where PAGE_SIZE is 4096.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Being able to switch physical DMA on and off at run time would be a nice
feature but a PITA to support by highlevel drivers and userspace apps.
Therefore allow it only to be set when the driver is being loaded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
This patch supplies the API extension introduced by patch
"ieee1394: extend lowlevel API for address range properties"
with proper addresses.
Like in patch ''ohci1394, sbp2: fix "scsi_add_device failed"
with PL-3507 based devices'', 1 TeraByte is chosen as physical
upper bound. This leaves a window for the middle address range.
This choice is only relevant for adapters which actually have a
programmable pysical upper bound register. (Only ALi and
Fujitsu adapters are known for this. Most adapters have a fixed
bound at 4 GB.) The middle address range is suitable for posted
writes.
AFAIK, PCILynx does not support physical DMA nor posted writes,
therefore no equivalent change in the pcilynx driver is necessary.
There is also a driver for GP2Lynx, although not in mainline Linux.
I assume this hardware does not support these OHCI features either.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Host adapter hardware imposes certain restrictions and features on
address ranges. Instead of hard-wire such ranges into the ieee1394
core or even into protocol drivers, let lowlevel drivers specify
these ranges via struct hpsb_host.
Patch "ohci1394: set address range properties" must be applied too,
else hpsb_allocate_and_register_addrspace() won't work properly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Since this is useful information, promote it from a debug macro to
a regular log message. The message appears only if the user set
exclusive_login=0, therefore won't clutter the logs in normal use.
Also update the comment on exclusive_login.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
This code became ineffective a few Linux releases ago and is not
required anyway.
Note from Christoph Hellwig: scsi_cmnd.request_buffer is always a
scatterlist these days. Checking random bites into it and then
mangling the data in sbp2_check_sbp2_response will cause really bad
memory corruption when you're not lucky enough to have the check not
trigger by luck.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Since broadcast transactions are already complete when the request has
been sent, the same transaction label can be reused all over again, see
IEEE 1394 7.3.2.5 and 6.2.4.3. Therefore we can reduce the footprint
of struct hpsb_host by the size of one struct hpsb_tlabel_pool.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Add support for the following types of hardware:
+ nodes that have a link speed < PHY speed
+ 1394b PHYs that are less than S800 capable
+ 1394b/1394a adapter cable between two 1394b PHYs
Also, S1600 and S3200 are now supported if IEEE1394_SPEED_MAX is raised.
A probing function is added to nodemgr's config ROM fetching routine
which adjusts the allowable speed if an access problem was encountered.
Pros and Cons of the approach:
+ minimum code footprint to support this less widely used hardware
+ nearly no overhead for unaffected hardware
- ineffective before nodemgr began to read the ROM of affected nodes
- ineffective if ieee1394 is loaded with disable_nodemgr=1
The speed map CSRs which are published to the bus are not touched by the
patch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Hakan Ardo <hakan@debian.org>
Cc: Calculex <linux@calculex.com>
Cc: Robert J. Kosinski <robk@cmcherald.com>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
This patch modifies the ohci1394.c file to enable and manage the "cycle too
long" interrupt.
If this interrupt occurs, the "LinkControl.CycleMaster" bit of the host
controller is reseted. This implies, that the host controller does not send
"cycle start" packet anymore freezing then the isochronous communication.
The management of the interrupt added by the patch is that when the interrupt
occurs, the OHCI irq handler prints a kernel log warning and then sets the
"LinkControl.CycleMaster" bit again resuming the isochronous communication.
Signed-off-by: Jean-Baptiste Mur <jeanbaptiste@maunakeatech.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Ben Collins <bcollins@debian.org>
Cc: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
The workarounds are not required for DViCO Momobay FX-3A and AFAIR not
for Momobay CX-2. These contain an TSB42AA9A but feature the same
firmware_revision value as the older DViCO Momobay CX-1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
spotted by Adrian Bunk. Also remove some superfluous comments.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
when attempting to find the 'last' part of the dma region continue the
search from where we left off, instead of starting the search over.
Signed-off-by: Jim Westfall <jwestfall@surrealistic.net>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
When working with multiple cameras and intensive applications, our logs
get flooded with video1394 information which isn't of much interest.
Any objections to demoting these messages to debug messages?
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
shmem_rmdir() must undo the increment of i_nlink done in
shmem_get_inode() for directories, otherwise at least
IN_DELETE_SELF inotify event generation is broken.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On 64-bit machines, we just lost the uppermost 32 bits.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
I noticed a strange behavior in a tmpfs file system the other day, while
building packages - occasionally, and seemingly at random, make decided to
rebuild a target. However, only on tmpfs.
A file would be created, and if checked, it had a sub-second timestamp.
However, after an utimes related call where sub-seconds should be set, they
were zeroed instead. In the case that a file was created, and utimes(...,NULL)
was used on it in the same second, the timestamp on the file moved backwards.
After some digging, I found that this was being caused by tmpfs not having a
time granularity set, thus inheriting the default 1 second granularity.
Hugh adds: yes, we missed tmpfs when the s_time_gran mods went into 2.6.11.
Unfortunately, the granularity of CURRENT_TIME, often used in filesystems,
does not match the default granularity set by alloc_super. A few more such
discrepancies have been found, but this is the most important to fix now.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Acked-by: Andi Kleen <ak@suse.de>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes two independent problems: it would not save the PCI state on
suspend (and thus try to resume a nonexistent state on resume), and
while shut off, if an interrupt happened on the same shared irq, the irq
handler would react very badly to the interrupt status being an invalid
all-ones state.
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Received from Mark Salyzyn
clear_user return is 0 for success, the code fragment is written to
assume that it is the count of the number of bytes zero'd.
Signed-off-by: Mark Haverkamp <markh@osdl.org>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This is a hold over from the end device/expander conversion. Apparently
the rphy list pointer is never initialised, so list_del() on the
uninitialised pointer can panic the system
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
For a legacy ATA controller, libata registers two separate host sets.
There was no connection between the two hosts making it impossible to
traverse all ports related to the controller. This patch adds
host_set->next which points to the second host_set and makes
ata_pci_remove_one() remove all associated host_sets.
* On device removal, all ports hanging off the device are properly
detached. Prior to this patch, ports on the first host_set weren't
detached casuing oops on driver unloading.
* On device removal, both host_sets are properly freed
This will also be used by new power management code to suspend and
resume all ports of a controller. host_set/port representation will
be improved to handle legacy controllers better and this host_set
linking will go away with it.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Depending on timing, ata_scsi_dev_rescan() might encounter a device
which is enabled but not yet attached to sdev. On such cases, the
original code caused oops. This patch makes ata_scsi_dev_rescan()
rescan only device which are attached to sdevs.
While at it, properly indent leading comment and add description about
how it's synchronized with sdev attach/detach.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
SIEN on some 3112 controllers doesn't mask SATA IRQ properly. IRQ
stays asserted even after SIEN is masked and IRQ is acked. Also, even
while frozen, any SATA PHY event including hardreset raises SATA IRQ.
Clearing SError seems to be the only way to deassert SATA IRQ.
This patch makes sil_host_intr() clear SError on SATA IRQs and ignore
SATA IRQs reported while frozen so that hardreset doesn't trigger
hotplug event (which ends up hardresetting again).
In such cases, the port still gets re-frozen to minimize the danger of
screaming interrupts. This results in one nil EH repeat on
controllers with broken SIEN but other than that does no harm.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The pgdir field in the paca was a leftover from the dynamic VSIDs
patch, and is not used in the current kernel code. This removes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
ATA_EH_REVALIDATE should be cleared after all devices on the target
port have been revalidated. Fix ata_eh_revalidate_and_attach()
accordingly.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Short-circuit interrupt handling if BMDMA2 is reported as 0xffffffff
indicating device removal.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
From: Aki M Nyrhinen <anyrhine@cs.helsinki.fi>
IMHO the current fix to the problem (in_flight underflow in reno)
is incorrect. it treats the symptons but ignores the problem. the
problem is timing out packets other than the head packet when we
don't have sack. i try to explain (sorry if explaining the obvious).
with sack, scanning the retransmit queue for timed out packets is
fine because we know which packets in our retransmit queue have been
acked by the receiver.
without sack, we know only how many packets in our retransmit queue the
receiver has acknowledged, but no idea which packets.
think of a "typical" slow-start overshoot case, where for example
every third packet in a window get lost because a router buffer gets
full.
with sack, we check for timeouts on those every third packet (as the
rest have been sacked). the packet counting works out and if there
is no reordering, we'll retransmit exactly the packets that were
lost.
without sack, however, we check for timeout on every packet and end up
retransmitting consecutive packets in the retransmit queue. in our
slow-start example, 2/3 of those retransmissions are unnecessary. these
unnecessary retransmissions eat the congestion window and evetually
prevent fast recovery from continuing, if enough packets were lost.
Signed-off-by: David S. Miller <davem@davemloft.net>
A soft lockup existed in the handling of ack vector records.
Specifically, when a tail of the list of ack vector records was
removed, it was possible to end up iterating infinitely on an element
of the tail.
Signed-off-by: Andrea Bittau <a.bittau@cs.ucl.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
People have been reporting that PPP connections over ptys, such as
used with PPTP, will hang randomly when transferring large amounts of
data, for instance in http://bugzilla.kernel.org/show_bug.cgi?id=6530.
I have managed to reproduce the problem, and the patch below fixes the
actual cause.
The problem is not in fact in ppp_async.c but in n_tty.c. What
happens is that when pptp reads from the pty, we call read_chan() in
drivers/char/n_tty.c on the master side of the pty. That copies all
the characters out of its buffer to userspace and then calls
check_unthrottle(), which calls the pty unthrottle routine, which
calls tty_wakeup on the slave side, which calls ppp_asynctty_wakeup,
which calls tasklet_schedule. So far so good. Since we are in
process context, the tasklet runs immediately and calls
ppp_async_process(), which calls ppp_async_push, which calls the
tty->driver->write function to send some more output.
However, tty->driver->write() returns zero, because the master
tty->receive_room is still zero. We haven't returned from
check_unthrottle() yet, and read_chan() only updates tty->receive_room
_after_ calling check_unthrottle. That means that the driver->write
call in ppp_async_process() returns 0. That would be fine if we were
going to get a subsequent wakeup call, but we aren't (we just had it,
and the buffer is now empty).
The solution is for n_tty.c to update tty->receive_room _before_
calling the driver unthrottle routine. The patch below does this.
With this patch I was able to transfer a 900MB file over a PPTP
connection (taking about 25 minutes), whereas without the patch the
connection would always stall in under a minute.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Setup nbytes in ata_sg_init_one to the total transfer length
of the command. This is needed by some HBAs that need to know
the total transfer length of each command.
Signed-off-by: Brian King <brking@us.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
