On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> Hi Oliver,
>
> I was working with this JMicron device and using the uas driver.
> I am seeing the following 2 issues.
>
> 1) On connect I see the following messages.
Thanks. Do you want to submit it to Greg?
The patch is fine.
> 2) On d
On Wed, 2016-12-21 at 12:54 +0100, Hans de Goede wrote:
> Hi,
>
> On 21-12-16 12:42, Oliver Neukum wrote:
> > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> >> Hi Oliver,
> >>
> >> I was working with this JMicron device and using the uas drive
On Wed, 2016-12-21 at 17:37 +0530, George Cherian wrote:
>
> On 12/21/2016 05:12 PM, Oliver Neukum wrote:
> > On Wed, 2016-12-21 at 17:09 +0530, George Cherian wrote:
> >> Hi Oliver,
> >>
> >> I was working with this JMicron device and using the uas driver.
ed patch and do a SCSI log of the enumeration?
Regards
Oliver
From d4ddac88bbf9cb15e7d8638582f96d31e245f15b Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 21 Dec 2016 15:34:54 +0100
Subject: [PATCH] uas: device crashes on reset
We avoid resetting it.
Signed-of
On Thu, 2016-12-22 at 15:43 +0530, George Cherian wrote:
> dmesg with the patch applied
Hi,
did you apply both patches, yours and the one I posted?
And did you physically disconnect your device?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:
> I don't see how this patch fixes anything. Unless I'm mistaken, it
> just avoids the problem by preventing the system from issuing the
> command that provokes the error, rather than really fixing the
> underlying error.
Please clarify. If a r
On Tue, 2016-12-27 at 10:20 -0500, Alan Stern wrote:
> On Tue, 27 Dec 2016, Oliver Neukum wrote:
>
> > On Thu, 2016-12-22 at 17:44 -0500, Alan Stern wrote:
> > > I don't see how this patch fixes anything. Unless I'm mistaken, it
> > > just avoids the probl
On Tue, 2016-12-27 at 21:19 -0500, Alan Stern wrote:
> On Tue, 27 Dec 2016, George Cherian wrote:
> > True. I am afraid that there necessarily is a window for resetting a
> > disconnected device. But the check you proposed is better.
> > however, I'd like to encapsulate that together with a test f
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
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-st
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 valu
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
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 yo
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
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 re
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 checki
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" i
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> I've access to a number of different uas devices now, and none of them use
> old style sense urbs. The only case where these code-paths trigger is with
> the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes
> status iu
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 deb
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 comp
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 n
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 mi
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 you
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 flus
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 you
liver
>From 8c90d860652aa99e6e60d9b32bc3aa8d4db9efa5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
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 a
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
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
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,
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
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
> > &g
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 aw
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 guideli
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_
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?
Regard
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
> >
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 ca
On Fri, 2013-09-13 at 06:37 -0700, Andy Lutomirski wrote:
> What's the status of this? Do I still need to test it?
>
> I won't have access to the Nook that triggered it the first time for a
> couple weeks, but I could try to find another device like that.
It works for me.
I'll push upstream in a
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
On Sunday 06 January 2013 16:41:37 Aaron Lu wrote:
> From: Lin Ming
>
> Uses block layer runtime pm helper functions in
> scsi_runtime_suspend/resume.
> Remove scsi_autopm_* from sd open/release path and check_events path.
> And remove the quiesce call in runtime suspend path, as we know there is
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 for an app to open the block device
> file(/dev/sr0), issue a command(play audio), then close the device file.
> From the OS
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
> &
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 c
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
Acked-by: Oliver Neukum
--
To unsubscribe from this list: s
On Thu, 2015-12-03 at 13:36 -0500, Alan Stern wrote:
> This is an old problem, but it was never resolved and it still affects
> people (Bugzilla #89511). In short, there are USB-(S)ATA bridges that
> claim to be write-back but don't support the SYNCHRONIZE CACHE
> command.
> This causes errors w
On Tue, 2016-01-26 at 10:28 -0500, Alan Stern wrote:
> On Tue, 26 Jan 2016, Oliver Neukum wrote:
> > That is problematic. The ABORT_TMF does need IO for which we need
> > to wait. And if we just submit and pretend the abort worked, the tag
> > will be reused.
> >
On Thu, 2016-02-04 at 19:22 +0800, Charles Chiou wrote:
> +static int stex_choice_sleep_mic(pm_message_t state)
> +{
> +switch (state.event) {
> +case PM_EVENT_SUSPEND:
> +return ST_S3;
> +case PM_EVENT_FREEZE:
Why do you react to PM_EVENT_FREEZE at all?
That is too early. You
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 cu
Am Dienstag 20 November 2007 schrieb James Bottomley:
>
> On Tue, 2007-11-20 at 16:07 +0100, Oliver Neukum wrote:
> > Am Dienstag 20 November 2007 schrieb James Bottomley:
> > > I don't understand why you want to do this. Power management is a
> > > layere
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 a
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 "autosuspe
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
>
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, otherwi
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
> > &
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.
Regar
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
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
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
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 http://vger.kernel.org/m
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 im
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?
>
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.
Am Dienstag, 29. Januar 2008 16:50:35 schrieb Boaz Harrosh:
> On Tue, Jan 29 2008 at 16:31 +0200, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> I can not see what it is. Yes CONFIG_USB_STORAGE_DEBUG will help.
> I have a device here that uses the same trasport/protocol I'll
&g
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 ScsiReqB
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 i
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 ‘m
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
> &
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]
M
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?
>
>
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 ll
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 managem
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
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.
&g
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
> >
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 m
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
> >
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_ co
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
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 PROTEC
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 invol
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 thr
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.
> >
Am Freitag 28 September 2007 schrieb Greg KH:
> On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
> >
> > PS: Whoever designed klists is suffering from a case of overengineeringosis.
>
> No objection from me there. If you can think of a way to do list
>
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
> devices when it gets handed a command, because the commands to spin-up
> the drives would have to b
Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
>
> > > > 1. autosuspend should not be specific to USB
> > >
> > > Correct. Which means support for it should be added to the SCSI
> > > drivers.
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
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 u
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
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 tha
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 powe
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: Rick
but it fixes
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
+01
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 n
been made.
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/unusua
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: se
1 - 100 of 190 matches
Mail list logo
