Hi list,
as the big kernel lock is no longer held during open, scsi_unregister_module
races with open. I've discussed this with David Hinds. It will affect the
pcmcia scsi drivers.
The patch I've attached grabs the big kernel lock and returns error codes in
case unregistering fails. Failure
On Dienstag, 13. Februar 2001 10:42, Jeremy Higdon wrote:
On Feb 13, 10:24am, Oliver Neukum wrote:
We currently support a RAID which uses vendor unique commands to do
device management. We need special versions of drivers that understand
the implied direction of the vendor unique
This means that it would be compiled into the kernel several times.
You should add it to the core scsi code and _not_ declare it static.
I considered doing it this way. As I saw it, it's a tradeoff between
including the code even if none of the drivers in question are
configured in, or
However, in light of other email in this thread, it looks like maybe the
table can go altogether, so hopefully this question is now moot.
Oh yes, I saw the mail you are refering to.
Let me put it this way: If we get rid of 'direction unknown'
then I'd be comfortable with killing it.
I'll put
Hi,
where is the usage count of the sg module increased ?
I looked at sg_open , but only the count of the low level driver
is increased.
TIA
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
Hi,
I was thinking about power management and the sg driver.
Shouldn't the sg driver block any request for putting the system to sleep
while and sg devices are open ?
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a
Hi,
I think there's a small window during which a low level driver can be
unloaded while sg_open() is executing.
The attached patch should fix it by incrementing the usage counter before
sg_open() might sleep.
Regards
Oliver
--- drivers/scsi/sg.c.alt Tue Mar 6
Hi list,
has anybody collected proposals for what is to be done to the scsi layer
in 2.5 ?
TIA
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
Hi,
scsi_unregister_host first checks the use count and then marks the device
offline. The order is wrong. By the time the device goes offline, it might
have been opened again.
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the
Hi,
what conditions have to be met for detach to be called safely ?
TIA
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
nothing other than sg will bind anyway. This seems like a reasonable
convention for drivers like yours and requires no modifications to the
current SCSI subsystem.
Precisely that is the point. If that feature is common, it should be
implemented in common code.
However this device is not
Am Samstag, 29. Januar 2005 15:46 schrieb James Bottomley:
I wouldn't have noticed this at all since you didn't send it to the scsi
list, but fortunately, Al Viro drew it politely to my attention as
another example of SCSI refcounting problems.
Sorry, it happening in cdrom_release fooled me
On Fri, 2013-07-26 at 09:54 -0700, Andy Lutomirski wrote:
This is kernel 3.9.9-302.fc19.x86_64.
I plugged in a BN Nook (a usb mass storage device), used it, and
ejected it. This makes suspend fail:
[50135.265514] PM: Entering freeze sleep
[50135.265517] Suspending console(s) (use
On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
In addition to my earlier comment, the patch below should be applied.
It will fix your immediate problem, although not in the best way.
Alan,
I think your diagnosis is correct, but not the fix.
This is run even in the runtime case. We
On Tue, 2013-07-30 at 13:00 -0400, Alan Stern wrote:
That's why I said the patch would fix the immediate problem but it
wasn't the best solution. You do agree that the patch is correct, as
far as it goes?
It will allow the system to sleep. But it seems to me that
a genuine error while
On Mon, 2013-07-29 at 10:21 -0400, Alan Stern wrote:
On Mon, 29 Jul 2013, Oliver Neukum wrote:
On Fri, 2013-07-26 at 16:31 -0400, Alan Stern wrote:
In addition to my earlier comment, the patch below should be applied.
It will fix your immediate problem, although not in the best way
8c90d860652aa99e6e60d9b32bc3aa8d4db9efa5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Thu, 1 Aug 2013 10:08:20 +0200
Subject: [PATCH] sd: error handling during flushing caches
It makes no sense to flush the cache of a device without medium.
Errors during suspend must be handled according
On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote:
On Thu, 1 Aug 2013, Oliver Neukum wrote:
On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:
More importantly, if we already know that the medium is not present or
has been changed since it was last used, then there's no reason
On Thu, 2013-08-01 at 23:40 +, Brandt, Todd E wrote:
This patch is a potential way to reduce the S3 resume time for SATA drives.
Essentially this patch removes the hard disk resume time from the total
system resume time, with the disks still taking as long to come back online
but in the
On Fri, 2013-08-02 at 09:54 -0400, Alan Stern wrote:
On Fri, 2 Aug 2013, Oliver Neukum wrote:
On Thu, 2013-08-01 at 11:53 -0400, Alan Stern wrote:
On Thu, 1 Aug 2013, Oliver Neukum wrote:
On Wed, 2013-07-31 at 11:13 -0400, Alan Stern wrote:
More importantly, if we already
On Fri, 2013-08-02 at 16:41 +, Brandt, Todd E wrote:
Do you mean in terms of debug after a failure? I can resubmit the patch with
the scsi_sense_hdr buffer still in place. I just wanted to keep the first
draft simple to get the concept across.
How are errors reported?
Regards
On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
@@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType *eeprom,
unsigned long io_port)
*/
dprintkl(KERN_WARNING,
EEProm checksum error: using default values and
options.\n);
On Wed, 2013-08-07 at 15:58 +0900, Jingoo Han wrote:
On Wednesday, August 07, 2013 3:50 PM, Oliver Neukum wrote:
On Wed, 2013-08-07 at 12:55 +0900, Jingoo Han wrote:
@@ -4183,15 +4183,17 @@ static void check_eeprom(struct NvRamType
*eeprom, unsigned long io_port
On Fri, 2013-08-09 at 01:09 +, Brandt, Todd E wrote:
static struct ata_force_ent *ata_force_tbl;
static int ata_force_tbl_size;
+int ata_resume_status;
A single global variable for multiple ports?
static char ata_force_param_buf[PAGE_SIZE] __initdata;
/* param_buf is thrown away
On Mon, 2014-08-25 at 10:58 +, Alfredo Dal Ava Junior wrote:
- 1TB and 2TB: READ_CAPACITY_10 returns correct size value
- 3TB and 4TB: READ_CAPACITY_10 returns size in a 2TB modulus
If we fix capacity size by reporting (READ_CAPACITY_10 + MODULO_2TB), the
result
will be invalid when
On Mon, 2014-08-25 at 16:21 -0400, Alan Stern wrote:
On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote:
Well, it is causing problems anyway... from user perspective, it's a
Linux compatibility issue, as it works fine on Windows. I'm not an
expert, but I'm wondering that if usb-storage
On Tue, 2014-08-26 at 09:58 +, David Laight wrote:
Part of the problem is that usb-storage has no way to know that
anything strange is going on. It's normal for READ CAPACITY(16) to
fail (this depend on the SCSI level), and it's normal for the READ
CAPACITY(10) to report a value less
On Tue, 2014-08-26 at 10:47 -0400, Alan Stern wrote:
On Mon, 25 Aug 2014, Oliver Neukum wrote:
Just set US_FL_NEEDS_CAP16. If READ CAPACITY(16) fails in that case,
it is clear that something is wrong. It must be set or READ CAPACITY(10)
alone would be taken as giving a valid answer.
You
On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
Hi,
Note this series is NOT intended for stable, but I accidentally
had cc = sta...@vger.kernel.org in my .git/config when sending
this series, please ignore for stable.
NACK for stable.
If this is not for stable, what do you intend
On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote:
Hi,
On 09/10/2014 01:56 PM, Oliver Neukum wrote:
On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
Hi,
Note this series is NOT intended for stable, but I accidentally
had cc = sta...@vger.kernel.org in my .git/config when
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
This commit removes the abort / lun-reset error handling paths, and also the
taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the
(tested and testable) usb-device-reset error handling path in place.
Note I
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
- Make sure we always hold the lock when setting / checking resetting
- Check resetting before checking urb-status
- Add missing check for resetting to uas_data_cmplt
- Add missing check for resetting to uas_do_work
Why is the checking
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
Check for both type of cancellation codes for sense and data urbs.
Then you should also check for -ESHUTDOWN (unplug of HC)
Regards
Oliver
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
uas_log_cmd_state(cmnd, __func__);
- /* all urbs are killed, clear inflight bits */
- cmdinfo-state = ~(COMMAND_INFLIGHT |
- DATA_IN_URB_INFLIGHT |
-
On Mon, 2014-09-15 at 08:42 +, David Laight wrote:
From: Alan Stern
You must not add an aditional value for a module parameter without
documenting it in Documentation/kernel-parameters.txt.
How can this work as a 'module parameter'?
It cannot. This parameter is an aid to debugging.
On Sun, 2014-09-14 at 11:34 +0100, James Bottomley wrote:
I'm agnostic on that. I was just combatting the impression that you had
to be careful about side effects in known macro statements.
No you haven't. But it is very good practice to not have side effects
in warnings, as people, not
Hi,
which function should a lldd call to make the scsi layer flush
a device's buffers and spin it down? Which kind of locking is
required?
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
Am Dienstag 18 September 2007 schrieb James Bottomley:
On Tue, 2007-09-18 at 10:32 +0200, Oliver Neukum wrote:
which function should a lldd call to make the scsi layer flush
a device's buffers and spin it down? Which kind of locking is
required?
Depends on the context
Am Dienstag 18 September 2007 schrieb James Bottomley:
On Tue, 2007-09-18 at 16:15 +0200, Oliver Neukum wrote:
Am Dienstag 18 September 2007 schrieb James Bottomley:
On Tue, 2007-09-18 at 10:32 +0200, Oliver Neukum wrote:
which function should a lldd call to make the scsi layer flush
Am Montag 24 September 2007 schrieb Alan Stern:
On Mon, 24 Sep 2007, Oliver Neukum wrote:
Am Dienstag 18 September 2007 schrieb James Bottomley:
On Tue, 2007-09-18 at 16:15 +0200, Oliver Neukum wrote:
It is for runtime power management. We've gotten a bug report about
a drive
Am Montag 24 September 2007 schrieb Alan Stern:
On Mon, 24 Sep 2007, Oliver Neukum wrote:
suspend. The PM and driver cores don't include _any_ provision for
runtime suspend; it has to be managed separately by each subsystem.
There we have a problem. We'd have to solve it for each
Am Montag 24 September 2007 schrieb Alan Stern:
On Mon, 24 Sep 2007, Oliver Neukum wrote:
But we don't bother when suspending the whole system. So why not simply
walk the subtrees under a USB device? Let the subsystem choose what
depth of sleep to use.
Because by doing so you
Am Montag 24 September 2007 schrieb Alan Stern:
On Mon, 24 Sep 2007, Oliver Neukum wrote:
subsystem implements its own form of runtime PM support, then you'll be
able to use it properly. But until then, there isn't anything much you
can do.
Well, we can't simply cut power
Hi,
what is the difference between these states? What function should
I call to block a device in order to securely flush the caches?
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More
Am Montag 24 September 2007 schrieb Alan Stern:
On Mon, 24 Sep 2007, Oliver Neukum wrote:
subsystem implements its own form of runtime PM support, then you'll be
able to use it properly. But until then, there isn't anything much you
can do.
Well, we can't simply cut power
Am Dienstag 25 September 2007 schrieb Hannes Reinecke:
Oliver Neukum wrote:
Hi,
what is the difference between these states? What function should
I call to block a device in order to securely flush the caches?
SDEV_BLOCK blocks _any_ commands from the midlayer; eg. if the LLDD
Am Dienstag 25 September 2007 schrieb Alan Stern:
Furthermore for many devices it will take real user intervention to
determine what is in the enclosure. This isn't very good. I think
we can do better.
If by we you mean the Linux kernel in general, then I agree. If by
we you mean the
Hi,
I am getting an oops with a scsi disk put into quiesced state.
Is there an easy way to reverse this from user space so I can
cleanly reboot?
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL
Am Dienstag 25 September 2007 schrieb Alan Stern:
Getting all this to work will be tricky, because sd is a block device
driven by requests issued through the block layer in atomic context,
whereas suspend and resume require a process context. Probably the
SCSI core would have to get involved
Am Donnerstag 27 September 2007 schrieb Alan Stern:
On Thu, 27 Sep 2007, Oliver Neukum wrote:
Am Dienstag 25 September 2007 schrieb Alan Stern:
Getting all this to work will be tricky, because sd is a block device
driven by requests issued through the block layer in atomic context
Am Donnerstag 27 September 2007 schrieb Alan Stern:
On Thu, 27 Sep 2007, Oliver Neukum wrote:
Oliver, I'm surprised at you! This patch is a big hack, not to mention
a layering violation and an inversion of the proper calling sequence.
Well,
1. autosuspend should
Am Donnerstag 27 September 2007 schrieb Alan Stern:
There's also a philosophical objection. Who is in a better position to
judge when a device like a SCSI drive should be autosuspended: its own
driver (sd) or someone else (usb-storage)?
Then a philosophical answer. The highest entity which
Am Freitag 28 September 2007 schrieb Alan Stern:
On Fri, 28 Sep 2007, Oliver Neukum wrote:
Am Donnerstag 27 September 2007 schrieb Alan Stern:
There's also a philosophical objection. Who is in a better position to
judge when a device like a SCSI drive should be autosuspended: its own
Am Freitag 28 September 2007 schrieb Alan Stern:
On Fri, 28 Sep 2007, Oliver Neukum wrote:
Am Donnerstag 27 September 2007 schrieb Alan Stern:
Have you thought about how autoresume would fit into this picture? I
don't think you can rely on usb-storage telling the SCSI core to resume
Am Samstag 29 September 2007 schrieb Alan Stern:
On Fri, 28 Sep 2007, Oliver Neukum wrote:
Unless I am very mistaken, further down in storage_suspend, I call
+ /* In case of autosuspend device must be unblocked again */
+ if (us-pusb_dev-auto_pm) {
+err_unblock
Am Samstag 29 September 2007 schrieb Alan Stern:
On Fri, 28 Sep 2007, Oliver Neukum wrote:
Am Freitag 28 September 2007 schrieb Alan Stern:
On Fri, 28 Sep 2007, Oliver Neukum wrote:
I don't know what that's supposed to mean. And whatever that means, it
must be equally true that usb
Am Samstag 29 September 2007 schrieb Alan Stern:
I disagree. That bug report shows that problems arise when we try to
suspend a parent without making sure the children are suspended first.
If the sd suspend method had already run then it would have been okay
for the enclosure to cut power.
Am Dienstag 20 November 2007 schrieb James Bottomley:
I don't understand why you want to do this. Power management is a
layered issue on SCSI, divided (as always) into host, device and
transport. The idle you're talking about is a pure device thing, so it
can be managed by the ULD (and
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:
When all the devices under a host are suspended, the LLD is informed
(via a new autosuspend method in the host template) so that it can
That is most certainly a mistake. Is there a good reason to not modify
to extend suspend() to take an
Am Montag, 7. Januar 2008 22:34:52 schrieb Alan Stern:
On Mon, 7 Jan 2008, Oliver Neukum wrote:
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:
When all the devices under a host are suspended, the LLD is informed
(via a new autosuspend method in the host template) so that it can
Am Dienstag, 8. Januar 2008 04:56:03 schrieb Alan Stern:
You'll have to add this method whenever a new subsystem is affected
by power management.
Sorry, I don't understand your point. If you mean that we'll have to
add autosuspend and autoresume code to every driver that wants to
support
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:
/**
+ * autoresume - perform dynamic (runtime) host resume
+ [EMAIL PROTECTED]: host to resume
+ *
+ * Resume (return to an operational power level) the specified host.
+ * Return 0 if the resume was successful, otherwise a
Am Dienstag, 8. Januar 2008 16:06:53 schrieb Alan Stern:
Eventually parts of the autosuspend mechanism will go there. But first
I thought we should have a proof-of-concept version working for at
least two different subsystems (such as SCSI and USB), so that we can
understand what should go
Am Dienstag, 8. Januar 2008 16:12:52 schrieb Alan Stern:
On Tue, 8 Jan 2008, Oliver Neukum wrote:
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:
/**
+ * autoresume - perform dynamic (runtime) host resume
+ [EMAIL PROTECTED]: host to resume
+ *
+ * Resume
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:
This patch applies to 2.6.24-rc6. Comments and suggestions are
welcome.
What about the SG_IO ioctl() ? It seems to me that you must not autosuspend
a device after that ioctl() has been used until the file handle is closed.
Am Dienstag, 8. Januar 2008 16:16:43 schrieb Alan Stern:
What about the SG_IO ioctl() ? It seems to me that you must not autosuspend
a device after that ioctl() has been used until the file handle is closed.
That's an open problem. The patch does block autosuspends as long as
an sg file
On Wednesday 19 September 2012 13:27:47 James Bottomley wrote:
On Wed, 2012-09-19 at 16:03 +0800, Aaron Lu wrote:
Hi James,
May I know if this patchset will enter v3.7?
Sigh, well, I was hoping to persuade the PM people to sort this out
first.
The first observation is that all this
On Friday 21 September 2012 23:18:27 Rafael J. Wysocki wrote:
Now, James says he doesn't like the way ready_to_power_off is used. Sure
enough, it is totally irrelevant to the majority of SCSI devices. It actually
is totally irrelevant to everything in the SCSI subsystem except for the sr
On Tuesday 25 September 2012 22:20:21 Aaron Lu wrote:
On Tue, Sep 25, 2012 at 01:47:52PM +0200, Rafael J. Wysocki wrote:
On Tuesday, September 25, 2012, Aaron Lu wrote:
I'm thinking of enabling this GPE in sr_suspend once we decided that it
is ready to be powered off, so the time frame
On Tuesday 25 September 2012 16:01:35 Aaron Lu wrote:
On Mon, Sep 24, 2012 at 11:40:18PM +0200, Rafael J. Wysocki wrote:
On Monday, September 24, 2012, Aaron Lu wrote:
On Mon, Sep 24, 2012 at 02:55:31PM +0200, Rafael J. Wysocki wrote:
I just checked the spec again and tested, when the ODD
On Tuesday 22 January 2013 10:25:31 Aaron Lu wrote:
On Mon, Jan 21, 2013 at 03:56:43PM +0100, Oliver Neukum wrote:
On Monday 21 January 2013 17:11:04 Aaron Lu wrote:
It is not easy for the OS to tell if the drive is being used or not
sometimes
Alan has reminded me it is possible
On Tuesday 22 January 2013 11:05:35 James Bottomley wrote:
May 3 18:19:06 relampago3 kernel: [ 3948.472796] sd 7:0:0:0: [sdf]
1565565872 512-byte logical blocks: (801 GB/746 GiB)
This looks like a wrap around of your actual size. This appears to
indicate the device isn't replying
On Monday 11 February 2013 22:03:18 Dan Carpenter wrote:
This bug was introduced back in bitkeeper days in 2003. We use
dcb-dev_mode before it has been initialized.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Acked-by: Oliver Neukum oli...@neukum.org
--
To unsubscribe from
On Fri, 2013-08-23 at 14:43 -0700, Brandt, Todd E wrote:
This is v3 of the non-blocking S3 resume patch. It's been broken into
two pieces, this part is for the scsi subsystem. I've addressed Alan
Stern's comments in particular by reformatting the call to conform
to the proper style
On Mon, 2013-09-02 at 13:25 +0200, Gerd Hoffmann wrote:
+static void uas_zap_dead(struct uas_dev_info *devinfo)
+{
+ struct uas_cmd_info *cmdinfo;
+ struct uas_cmd_info *temp;
+ struct list_head list;
+ unsigned long flags;
+
+ spin_lock_irq(uas_lists_lock);
Hi Hannes,
you objected to this patch saying there's a possibilty that
HS devices may also need this feature, which would require
a quirk. Does this mean that the patch is acceptable only
with an additional predefined quirk, or do you insist that all
devices be handled with quirks?
On Tue, 2013-09-10 at 13:25 -0400, Alan Stern wrote:
On Tue, 10 Sep 2013, Oliver Neukum wrote:
Hi Hannes,
you objected to this patch saying there's a possibilty that
HS devices may also need this feature, which would require
a quirk. Does this mean that the patch is acceptable only
On Wed, 2013-09-11 at 10:14 -0400, Alan Stern wrote:
There are three possibilities: nothing, your proposed patch, and a new
Nothing is feasible only if Windows uses READ_CAPACITY_10.
quirk flag. The flag is safest, but also the hardest to maintain.
Again the same answer.
I think we can
On Thu, 2013-09-12 at 07:47 +0200, Hannes Reinecke wrote:
On 09/11/2013 04:14 PM, Alan Stern wrote:
On Tue, 10 Sep 2013, Oliver Neukum wrote:
I think we can be sure that no drive enclosure will crash
with READ_CAPACITY_16.
I wouldn't count on it, but I don't know of any examples
On Fri, 2013-11-15 at 17:53 -0200, Geyslan Gregório Bem wrote:
Hi,
Hi guys,
In the function msgin_qtag() [line 2632], this dereference was intentional?
static struct ScsiReqBlk *msgin_qtag(struct AdapterCtlBlk *acb,
struct DeviceCtlBlk *dcb, u8 tag)
{
struct ScsiReqBlk *srb
On Thu, 2014-01-16 at 11:59 -0500, Alan Stern wrote:
Since the START-STOP and TEST UNIT READY (or REQUEST SENSE or
whatever)
commands are likely to take a long time, they should all be carried
out
asynchronously with respect to the resume procedure. I don't know
what
the best way is to
On Sun, 2014-05-18 at 21:50 +0200, Guennadi Liakhovetski wrote:
On Sun, 18 May 2014, Rickard Strandqvist wrote:
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard
Am Dienstag, 5. Juni 2007 06:08 schrieb Andrew Morton:
Everything in USB appears to already be fixed, apart from the io_ti.c bug.
Yes, that's a bug. I've queued a patch.
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a
Am Donnerstag, 12. Juli 2007 schrieb Boaz Harrosh:
- use scsi_cmnd data accessors
- Clean the !use_sg code paths
This doesn't compile, at least on x86_64, so NAK.
Regards
Oliver
CC [M] drivers/usb/image/microtek.o
drivers/usb/image/microtek.c: In function
Am Donnerstag, 12. Juli 2007 schrieb James Bottomley:
On Thu, 2007-07-12 at 15:29 +0200, Oliver Neukum wrote:
Am Donnerstag, 12. Juli 2007 schrieb Boaz Harrosh:
- use scsi_cmnd data accessors
- Clean the !use_sg code paths
This doesn't compile, at least on x86_64, so NAK
Am Freitag, 15. Dezember 2006 14:34 schrieb Krzysztof Halasa:
I find it really hard to believe there are still users of things like
CDU-31A CDs, XT MFM disk controllers, or NCR5380 SCSI host adapters
(especially the real ones, not DOMEX etc. clones bundled with scanner
just ~ 10 years ago).
an ugly bug.
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--- a/drivers/usb/storage/unusual_devs.h2007-02-06 14:14:49.0
+0100
+++ b/drivers/usb/storage/unusual_devs.h2007-02-07 15:14:01.0
+0100
@@ -1430,7 +1430,7
Am Mittwoch, 7. Februar 2007 16:05 schrieb Christoph Hellwig:
On Wed, Feb 07, 2007 at 03:22:39PM +0100, Oliver Neukum wrote:
Hi,
there's a USB mass storage device which exists in two version. One
reports the correct size and the other does not. Apart from that they
are identical
.
Greg, can this go through your tree?
Regards
Oliver
Signed-off-by: Oliver Neukum [EMAIL PROTECTED]
--
--- linux-2.6.20/drivers/usb/storage/unusual_devs.h 2007-02-06
14:14:49.0 +0100
+++ linux-2.6.20-autosusp/drivers/usb/storage/unusual_devs.h2007-02
Am Dienstag, 20. März 2007 17:39 schrieb Alan Cox:
* sdev-manage_start_stop is set to 1 in ata_scsi_slave_config().
This fixes spindown on shutdown and suspend-to-disk.
Yay
Which kernel version is this?
Regards
Oliver
-
To unsubscribe from this list: send the
Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:
When all the devices under a host are suspended, the LLD is informed
(via a new autosuspend method in the host template) so that it can
put the host adapter in a low-power state. Likewise, a new
autoresume method is called when the
Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern:
On Wed, 9 Jan 2008, Oliver Neukum wrote:
This has an interesting implication. As the storage driver can share
a device with in principle any other usb driver, we must audit all usb
drivers if we wish to adopt this patch.
All
Hello,
is there a way to distinguish calls to sd_open() from mount() from
calls to open() ?
Regards
Oliver
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Am Mittwoch, 9. Januar 2008 21:36:20 schrieb Alan Stern:
On Wed, 9 Jan 2008, Oliver Neukum wrote:
Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern:
On Wed, 9 Jan 2008, Oliver Neukum wrote:
This has an interesting implication. As the storage driver can share
a device
Hi,
could you explain to me why this code can get away with allocating the
sense buffer on the stack?
static int sg_io(struct file *file, struct request_queue *q,
struct gendisk *bd_disk, struct sg_io_hdr *hdr)
{
unsigned long start_time;
int writing = 0, ret = 0,
Am Donnerstag, 10. Januar 2008 14:05:25 schrieb Boaz Harrosh:
On Thu, Jan 10 2008 at 14:33 +0200, Oliver Neukum [EMAIL PROTECTED] wrote:
Hi,
could you explain to me why this code can get away with allocating the
sense buffer on the stack?
static int sg_io(struct file *file, struct
Am Dienstag, 29. Januar 2008 15:11:08 schrieb Jens Axboe:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
On Tue, Jan 29 2008 at 15:54 +0200, Jens Axboe [EMAIL PROTECTED] wrote:
On Tue, Jan 29 2008, Boaz Harrosh wrote:
Greg KH wrote:
No difference, still just a lot of resets.
Where
On Thursday 26 July 2012 18:05:24 Aaron Lu wrote:
If the device is using autosuspend, when scsi_autopm_put_device is
called for it, use autosuspend runtime pm calls instead of the sync
call.
What is the purpose of this approach?
You need a very good reason to have an API do two different
On Thursday 26 July 2012 20:43:32 Aaron Lu wrote:
What is the purpose of this approach?
The purpose is to let scsi layer driver(sd, sr, etc.) use the same pm
api(scsi_autopm_put_device) to put the device to runtime suspended
state.
When the device is ready to be suspended, if it does not
with unplugging eSATA devices
before suspending the system.
Signed-off-by: Oliver Neukum oneu...@suse.de
---
drivers/scsi/sd.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index a344220..49b0c52 100644
1 - 100 of 157 matches
Mail list logo
