Andrew sent this to linus-usb-devel, but it should have gone to
linux-scsi.
-- Forwarded message --
Date: Sun, 26 Sep 2004 10:31:06 -0700
From: Andrew Morton <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [linux-usb-devel] Fw: [Bug 3466] New: Bug while connecting USB-HDD
Did
On Sun, 26 Sep 2004, David Brownell wrote:
> > If the USB drivers are linked into the kernel, what happens when they
> > start initializing devices during the resume-from-disk bootup? What about
> > the early-HC-disable patch that was recently added?
>
> Systems that rely on that patch are syste
On Sun, 26 Sep 2004, David Brownell wrote:
> No, I'm saying your model has to be more flexible about the
> way it accomodates policy constraints. STR is a system policy
> transition, not a device power level. The current PM framework
> has big problems because it doesn't even recognize the curre
This is patch as384. It reverts some of our sanity checks on the GetMaxLUN
part of the Bulk-only protocol. Apparently, this is one area where vendors
can't even get close to correct. So, in the face of any sort of error, we
assume a single LUN.
We also include some comments so we don't make thi
This is patch as356, regenerated against a current tree.
This patch allows usb-storage to ignore the reported residue values when
required by some devices. A few devices are included... I know more are
waiting to be merged into unusual_devs.h
In case anyone is curious... yes, these are broken de
This patch started life as as366, got some modifications, and lives now as
as366b. It implements a delay in SCSI-layer device scanning for
usb-storage devices at insertion time.
Many devices work better with this delay. We believe we can remove several
US_FL_FIX_INQUIRY unusual_devs.h entries wi
Hi!
> > > > Yes, agreed. Feel free to submit a patch ;-).
> > >
> > > I would prefer to wait until there is some consensus on how selective
> > > suspend works as well as system-wide suspend. After all, the two ought to
> > > share a lot of code...
> >
> > Umm.. See past flamewars on linux-ke
Hi!
> > Specifying wakeup_enabled at suspend() time will mean one more
> > parameter to suspend() :-(. We already have enable_wake() function, I
> > do not think we want to change API.
>
> I worry about having too many callbacks. Adding an extra parameter to an
> existing callback doesn't seem
Hi!
> > > > > > The meaning of the power states is unclear, particularly for
> > > > > > buses that don't support all the PCI states.
> > > > >
> > > > > Well, in suspend I'm currently only using 0/3, where 0 is on, and 3 is
> > > > > suspended.
> > >
> > > You should be using PM_SUSPEND
On Sat, 25 Sep 2004, Phil Dibowitz wrote:
> Interestingly, my phone (Sony Ericsson T637) uses Obex. I connect to it
> using a USB cable that is in fact a USB->Serial Converter (which uses
> the pl2303 driver), and then using multisync (multisync.sf.net) which
> talks obex in userspace.
>
> So
Did this doubly-created-slab-cache bug get fixed?
Begin forwarded message:
Date: Sun, 26 Sep 2004 09:55:49 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 3466] New: Bug while connecting USB-HDD
http://bugme.osdl.org/show_bug.cgi?id=3466
Summary: Bug while connect
On Sat, 25 Sep 2004, Marcel Holtmann wrote:
> I don't buy your point. From what I know is that OBEX only needs bulk
> transfers and these can be used very easy through the USB library. The
> big advantage using the USB library is that you also support OBEX over
> USB for FreeBSD and MacOS X at the
1) 2.6.5 is old. Make sure the problem exists on something newer first.
2) You should add your e-mail address to the entry so we can contact you if
we ever want to remove it (which is very applicable here, as I'm working on
fixing the need for SINGLE_LUN with UFI devices).
3) You should be using t
On Sun, Sep 26, 2004 at 12:05:21PM -0400, Alan Stern wrote:
> On Sun, 26 Sep 2004, Joris van Rantwijk wrote:
>
> > Can we somehow make the max_sectors limit automatic for this device?
> > There is already a hack in scsiglue.c for Genesys devices; I could
> > easily add my device there. Or we could
Hi,
I have extended my driver to add support of the embedded USB port provided by
some new Texas Instruments' handhelds. Things are the same except for the
maximum packet size.
Comments are welcome... Otherwise, please apply.
Thanks, Romain.
[cut here]===
On Sunday 26 September 2004 9:43 am, Alan Stern wrote:
> On Sun, 26 Sep 2004, David Brownell wrote:
>
> > I think some of the definitions are system-specific, and all of the
> > relevant specifications are weasel-worded to support that. Key
> > point: if RAM is powered, some devices could be to
On Sun, 26 Sep 2004, David Brownell wrote:
> I think some of the definitions are system-specific, and all of the
> relevant specifications are weasel-worded to support that. Key
> point: if RAM is powered, some devices could be too; and the
> wakeup devices (USB, network, keyboard, etc) probabl
On Sunday 26 September 2004 9:04 am, Oliver Neukum wrote:
>
> >
> > ... when the system uses resume() on those [USB] devices then
> > no re-enumeration/probing is needed. ...
>
> USB-core will at least have to restore the configuration. Unfortunately
> that operation can fail for several re
On Sunday 26 September 2004 8:59 am, Alan Stern wrote:
> On Sun, 26 Sep 2004, David Brownell wrote:
>
> > > Unless I'm mistaken, suspend-to-RAM puts most PCI
> > > devices into D3cold.
> >
> > That'd be a bug. STR isn't supposed to discard state like that; it's
> > supposed to leave device
On Sun, 26 Sep 2004, David Brownell wrote:
> I'd hope the core would focus on system-wide PM policies, an extensible
> set that should "at the beginning" include roughly:
>
> - Everything always on. ACPI-friendly. "tune for fastest speeds".
> Fair to say this is today's Linux policy defau
Am Sonntag, 26. September 2004 17:44 schrieb Alan Stern:
> On Sun, 26 Sep 2004, Oliver Neukum wrote:
>
> > > Well, "may_wakeup", versus "must_not_wakeup", and also
> > > probably "must_wakeup". Autosuspend idle mice only when
> > > they can take themselves out of suspend ... ;)
> >
> > Question.
Hello everybody,
My name is Dirk, I just started doing a diploma thesis about "Connection
of an astronomical CCD camera to a linux computer via USB"
The CCD puts out the data in a given digital format at a given clock rate.
I'm asked to install a mircocontroller (with build in USB support) taking
On Sun, 26 Sep 2004, Joris van Rantwijk wrote:
> Can we somehow make the max_sectors limit automatic for this device?
> There is already a hack in scsiglue.c for Genesys devices; I could
> easily add my device there. Or we could generalise this hack by
> adding a max_sectors field to the UNUSUAL_D
On Saturday 25 September 2004 8:45 pm, Alan Stern wrote:
> On Sat, 25 Sep 2004, David Brownell wrote:
>
> > In general I think the PM core has to firmly accept the notion
> > of driver-specified device power states ... as things that are
> > distinct from system power states, and that drivers some
On Sun, 26 Sep 2004, Joris van Rantwijk wrote:
> The MusicDrive chip (used in some USB flash drive MP3 players)
> incorrectly reports residues on large (64k) data transfers.
> This patch adds an UNUSUAL_DEV entry for the device to make the Linux
> transport code ignore the residue count on reads f
> > > The caller -- perhaps sysadmin through sysfs -- had the option
> > > to choose a "suspend", and instead chose a "disconnect".
> > > It only makes sense to respect that choice.
> >
> > We may have no option. Unless I'm mistaken, suspend-to-RAM puts most PCI
> > devices into D3cold.
>
> T
Hello everybody,
My name is Dirk, I just started doing my diploma thesis about
"Connection of an astronomical CCD camera to a linux computer via USB"
The CCD puts out the data in a given digital format at a given clock
rate. I'm asked to install a mircocontroller (with build in USB support)
taki
On Sun, 26 Sep 2004, Pavel Machek wrote:
> Specifying wakeup_enabled at suspend() time will mean one more
> parameter to suspend() :-(. We already have enable_wake() function, I
> do not think we want to change API.
I worry about having too many callbacks. Adding an extra parameter to an
existi
On Sun, 26 Sep 2004, David Brownell wrote:
> > We may have no option. Unless I'm mistaken, suspend-to-RAM puts most PCI
> > devices into D3cold.
>
> That'd be a bug. STR isn't supposed to discard state like that; it's
> supposed to leave devices (low-)powered but able to resume
> quickly (give
On Sun, 26 Sep 2004, Oliver Neukum wrote:
> > Well, "may_wakeup", versus "must_not_wakeup", and also
> > probably "must_wakeup". Autosuspend idle mice only when
> > they can take themselves out of suspend ... ;)
>
> Question. Do you think that such interpretation should be left to
> drivers or s
On Saturday 25 September 2004 8:59 pm, Alan Stern wrote:
> > If it's powered off, just disconnect() to get rid of it. When
> > the user reconnects that disk tomorrow, let usermode code notice
> > that it's now morphed to reiser5, and sort out the details!
> >
> > And if it stayed suspended, it
On Sun, 26 Sep 2004, Alan Stern wrote:
> In fact there are three distinct but closely related concepts involved,
> and they all need to be handled simultaneously in some reasonably way.
> They are: power level, IRQ/DMA enabled (or activity level if you prefer),
> and wakeup enabled. These thing
On Saturday 25 September 2004 8:45 pm, Alan Stern wrote:
> On Sun, 26 Sep 2004, Pavel Machek wrote:
>
> > What is PME#?
>
> It's a special signal used by PCI power management. A device may generate
> this signal even when it is in a low-power or power-off state (unlike
> normal IRQs, which can o
G'Morning,
On Sunday 26 September 2004 2:15 am, Pavel Machek wrote:
> > > > I don't know
> > > > how closely people want to tie remote wakeup enable/disable with power
> > > > states, although they are related concepts.
> > >
> > > They're coupled in that wakeup makes no sense without some kind
Am Sonntag, 26. September 2004 16:06 schrieb Georg C. F. Greve:
> However, after using it once, the machine has to be turned off, since
> the drivers won't unload properly, and after removing and reinserting
> the card, it does not work anymore.
We need the dmesg of an unplug to debug this.
On Sunday 26 September 2004 2:10 am, Pavel Machek wrote:
> Hi!
>
> > > > > The meaning of the power states is unclear, particularly for
> > > > > buses that don't support all the PCI states.
> > > >
> > > > Well, in suspend I'm currently only using 0/3, where 0 is on, and 3 is
> > > >
I was unable to test this patch, yet.
The device shows 8 LUNs with our 2.6.5 kernel.
T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0409 ProdID=0040 Rev= 1.21
S: Manufacturer=NEC
S: Product=NEC USB UF00
Hi all,
I have one of these PCMCIA cards to connect to Vodafone UMTS/GPRS that
are apparently build by Qualcomm. There is no official support from
either Vodafone or Qualcomm. Requests to Vodafone only yielded "we
cannot help you" as an answer, Qualcomm did not even bother to
respond.
Thanks to t
On Fri, 24 Sep 2004 00:09:23 -0500, Dmitry Torokhov wrote:
> Jan Steinhoff wrote:
>
> > Hi,
> >
> > I'm working on a kernel 2.6 driver for Synaptics cPad. With kernel >=
> > 2.6.7 'rmmod cpad' hangs if called from xterm. This is because Synaptics
> > TouchPad driver for XFree86 holds the evdev d
David Brownell wrote:
> Bjorn Helgaas wrote:
>>
>> The attached patch (which applies on top of Rui's patch for
>> ALI M5237) fixes the problem for my DL360.
>
> Hmm, I'd rather avoid needing a quirk table ... especially
> when I've always suspected this is some subtle bug in the
> way Linux initial
Hi!
> > > Exactly. Furthermore, the suspend call is a logical place to specify
> > > whether wakeup should be enabled. Also note that once a device is
> > > suspended, it may not be possible to change whether wakeup is enabled or
> > > disabled without first resuming the device.
> >
> > Spec
The MusicDrive chip (used in some USB flash drive MP3 players)
incorrectly reports residues on large (64k) data transfers.
This patch adds an UNUSUAL_DEV entry for the device to make the Linux
transport code ignore the residue count on reads from the device.
Writes to the device will still fail an
Hello,
On Sat, 25 Sep 2004, Alan Stern wrote:
> Hmm... It sounds like your device isn't working all that great to begin
> with.
No it isn't. But for me that seems no reason to just "drop" all Linux
support for it.
> A workaround that might do the trick is for you to force all data
> transfers t
Am Sonntag, 26. September 2004 11:15 schrieb Pavel Machek:
> > Exactly. Furthermore, the suspend call is a logical place to specify
> > whether wakeup should be enabled. Also note that once a device is
> > suspended, it may not be possible to change whether wakeup is enabled or
> > disabled wi
Hi!
> > > > The meaning of the power states is unclear, particularly for
> > > > buses that don't support all the PCI states.
> > >
> > > Well, in suspend I'm currently only using 0/3, where 0 is on, and 3 is
> > > suspended.
>
> You should be using PM_SUSPEND_ON and PM_SUSPEND_D
Hi!
> > > S0 is the normal
> > > operational state. Selective suspend would use state S1. Suspend-to-RAM
> > > and suspend-to-disk would use S2 for devices that support PME#, otherwise
> > > S2'. Perhaps there's no need to distinguish between the two; I don't know
> > > how closely people want
Am Sonntag, 26. September 2004 05:22 schrieb Alan Stern:
> On Sat, 25 Sep 2004, David Brownell wrote:
>
> > > int suspend_subtree (struct device *top_dev, u32 level, int remote_wakeup);
>
> Is this supposed to be a replacement for or an addition to the existing
> "suspend-one-device" routine?
T
Am Sonntag, 26. September 2004 01:48 schrieb David Brownell:
> On Saturday 25 September 2004 3:16 pm, Oliver Neukum wrote:
> > Hi,
> >
> > just looking through drivers/base/power/runtime.c it seems to me
> > that the approach is basically unworkable and cannot be made to
> > work. A sane API shoul
48 matches
Mail list logo
