Hi Alan,
Thanks for your fast reply!
Alan Stern wrote:
On Thu, 6 Jan 2005, Vladimir Trukhin wrote:
Due to mkdosfs does not work with USB directly (it failed with " unable
to get drive geometry for '/dev/uba1' "),
It probably would have worked better if you had used usb-storage instead
of
On Tue, Jan 04, 2005 at 10:19:02PM +0100, Oliver Neukum wrote:
> Hi,
>
> there are a lot of buggy modems.
Applied, thanks.
greg k-h
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t
On Thu, Jan 06, 2005 at 12:34:14PM -0800, David Brownell wrote:
> This is a trivial fix for this oops; there might
> be a better one.
Applied, thanks.
greg k-h
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limite
On Wed, Jan 05, 2005 at 03:49:12PM -0800, David Brownell wrote:
> Sometimes chip evaluation samples are packaged onto
> PCI card with a bridge (e.g. from PLX). In production
> systems the bridge is never used, and the chip sits on
> a platform bus.
>
> This patch lets drivers for such chips be wr
Am Donnerstag, 6. Januar 2005 21:12 schrieb Ð:
> I use 2.6.10 kernel and pppd-2.4.3 on Fedora Core 3 distr.
> I configure my pppd to connect to internet via 3Com 56k Business Modem (USB).
> Everything is fine.
> But when i want disconnect from internet i do: 'killall pppd'.
> Dialup connection
Am Donnerstag, 6. Januar 2005 23:27 schrieb Alan Stern:
> Do you have Legacy USB support enabled in your BIOS?
Without legacy support:
Jan 7 00:35:15 macbeth kernel: Stopping tasks:
===|
Jan 7 00:35:15 macbeth kernel: Freeing memory...
^H-^H\^H|^H/^H-^H\^
On Thu, Jan 06, 2005 at 12:35:22PM -0800, Jesse Barnes wrote:
> On Thursday, January 6, 2005 12:25 pm, Jesse Barnes wrote:
> > [Sorry about the bogus reply, I don't have the original message.]
> >
> > That shouldn't happen. Maybe you were running an old version of the tree
> > or an old version of
On Thu, 2005-01-06 at 13:10 -0800, David Brownell wrote:
> But surely it'd be better to have one arch-neutral call in
> the chip's driver; nobody else needs to know how that
> hardware signal works.
I don't know that you have a choice on all architectures. e.g. an ISA
IRQ is always rising edge. (
Am Donnerstag, 6. Januar 2005 22:01 schrieb Alan Stern:
> On Thu, 6 Jan 2005, Oliver Neukum wrote:
>
> > Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > > It's also possible that the flip-flop is changed during the suspend
> > > operation rather than the resume operation. ÂPerhaps Oliv
On Thursday 06 January 2005 3:05 pm, Ian Campbell wrote:
> On Thu, 2005-01-06 at 13:10 -0800, David Brownell wrote:
>
> > But surely it'd be better to have one arch-neutral call in
> > the chip's driver; nobody else needs to know how that
> > hardware signal works.
>
> I don't know that you have
On Thu, 6 Jan 2005, David Brownell wrote:
> On Thursday 06 January 2005 1:01 pm, Alan Stern wrote:
> >
> > If the power was shut off entirely, upon resume the controller would have
> > seen a connect change event. No such event shows up in the system logs
> > you posted with ehci-hcd unloaded.
On Thu, 6 Jan 2005, David Brownell wrote:
> This suggests that the problem is in UHCI. A key difference
> between having /sys/power/disk be "platform" vs "shutdown"
> is basically that BIOS treats the shutdown path as a reboot,
> while the "platform" path is a real resume.
>
> Reboot probably me
> It's worth checking this out. Oliver, after resuming with both uhci-hcd
> and ehci-hcd loaded, try doing lspci -xxx for the UHCI controller. The
> two bytes at offset 0xc0 are of interest.
>
> Do you have Legacy USB support enabled in your BIOS?
Legacy support was on.
I've swit
Alan,
Things do quiet down after I rmmod ehci and uhci and
insert them again, but not until that.
And yes, it is a problem of coexistence between uhci
and ehci, because taken separately they behave nice.
Paul
> It's surprising that things don't quiet
> down and start working
> again.
>
> Alan
On Thursday 06 January 2005 1:49 pm, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 22:31 schrieb David Brownell:
> > But an honest-to-gosh resume acts different. The BIOS
> > won't touch the controllers there.
> >
> > Now, the HCD resume() method has to handle at least
> > three different
On Thursday 06 January 2005 1:54 pm, Pavel Machek wrote:
> > Does swsusp behave correctly in the "shutdown" case?
> > That's roughly the difference between an ACPI S4bios
> > and an ACPI S4 suspend sequence. Both need testing.
>
> "platform" is swsusp followed by S4 powerdown.
>
> S4bios is "fir
On Thursday 06 January 2005 1:24 pm, Greg KH wrote:
> > P.S.: When designing new API, please do not make it unnecessary
> > complicated.
> > USB video needs rather large bandwidth and low latency, so please no ASCII
> > strings, and scatter-gather aware API helps a bit...
>
> In measurements pub
Hi!
> > In any case this isn't under our control.
> > Devices are resumed in the same order they were detected initially. I
> > think the only way to solve this problem is to find a workaround for EHCI
> > controllers that act weird when they resume.
>
> The problem could well be in UHCI inst
Am Donnerstag, 6. Januar 2005 22:31 schrieb David Brownell:
> But an honest-to-gosh resume acts different. The BIOS
> won't touch the controllers there.
>
> Now, the HCD resume() method has to handle at least
> three different states:
>
> - Honest-to-gosh resume (which worked in this case)
>
Am Donnerstag, 6. Januar 2005 22:01 schrieb Alan Stern:
> On Thu, 6 Jan 2005, Oliver Neukum wrote:
>
> > Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > > It's also possible that the flip-flop is changed during the suspend
> > > operation rather than the resume operation. Perhaps Oliv
On Thu, Jan 06, 2005 at 01:59:25PM -0800, David Brownell wrote:
> On Thursday 06 January 2005 1:24 pm, Greg KH wrote:
> > > P.S.: ?When designing new API, please do not make it unnecessary
> > > complicated.
> > > USB video needs rather large bandwidth and low latency, so please no ASCII
> > > str
On Thursday 06 January 2005 11:40 am, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> > The problem could well be in UHCI instead, or BIOS.
> > There are at least several dozen different configurations
> > to test here, after all ... ;)
>
> I am developing rebo
On Thu, 6 Jan 2005, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> > It's also possible that the flip-flop is changed during the suspend
> > operation rather than the resume operation. Perhaps Oliver can add some
> > debugging lines to print the values of the reg
On Thu, 2005-01-06 at 19:31 +0200, Olav Kongas wrote:
> Hi,
>
> On Thu, 6 Jan 2005, Ian Campbell wrote:
> > When I tried it I found that DEFAULT_FMINTERVAL wasn't defined anywhere,
> > I tried setting FI=11999,FSMPS=0 as that was what the docs said the
> > default was but that didn't work.
>
> FI
This is a trivial fix for this oops; there might
be a better one.
- Dave
This prevents the serial gadget driver from oopsing during enumeration
when spinlocks are configured, and slab poisoning is active...
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- 1.21/drivers/usb/gadget/serial.c 20
On Thursday 06 January 2005 11:11 am, Alan Stern wrote:
> > The only thing that a quick scan of the ehci resume
> > code suggested might be a problem is the line of code
> > in ehci-hub.c::ehci_resume() that checks for whether
> > the PORT_SUSPEND bit is set. Maybe that should be
> > checking for
On Thursday 06 January 2005 1:01 pm, Alan Stern wrote:
>
> If the power was shut off entirely, upon resume the controller would have
> seen a connect change event. No such event shows up in the system logs
> you posted with ehci-hcd unloaded. But it does show up in the logs with
> ehci-hcd load
Hello, linux-usb-devel.
I use 2.6.10 kernel and pppd-2.4.3 on Fedora Core 3 distr.
I configure my pppd to connect to internet via 3Com 56k Business Modem (USB).
Everything is fine.
But when i want disconnect from internet i do: 'killall pppd'.
Dialup connection broken and i use my telephone line t
On Thu, Jan 06, 2005 at 10:09:21PM +0100, Petr Vandrovec wrote:
> On Thu, Jan 06, 2005 at 09:44:31PM +0100, Andi Kleen wrote:
> > On Thu, Jan 06, 2005 at 11:59:59AM -0800, David S. Miller wrote:
> > > On Thu, 6 Jan 2005 20:51:44 +0100
> > > Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
> > > > DaveM
Am Donnerstag, 6. Januar 2005 20:11 schrieb Alan Stern:
> It's also possible that the flip-flop is changed during the suspend
> operation rather than the resume operation. Perhaps Oliver can add some
> debugging lines to print the values of the regs->port_status[] entries in
> those three loops (o
Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> The problem could well be in UHCI instead, or BIOS.
> There are at least several dozen different configurations
> to test here, after all ... ;)
I am developing reboot psychosis ;-)
Anyway, using platform makes a difference. The box do
[Removed acpi-devel from the CC: line, since this has turned out to be a
USB problem]
On Thu, 6 Jan 2005, David Brownell wrote:
> This would be a case where the root hub timer isn't
> getting shut down "properly" during suspend ... right
> now the OHCI and EHCI code test for HCD_IS_RUNNING()
> i
On Thursday 06 January 2005 12:52 pm, Ian Campbell wrote:
> in viper_init_irq():
> set_irq_type(VIPER_USB_IRQ, IRQT_RISING);
Just out of curiousity ... does anyone know what the story
is on getting an arch-neutral set_irq_type() call?
Sure, all the board support code can do that stuff. Or
On Thu, 2005-01-06 at 19:11 +0100, [EMAIL PROTECTED] wrote:
> May be my arch interrupt setup or timing broken?
I guess if other peripherals are OK then the basic code is right, but it
sounds as if the configuration for the particular USB IRQ isn't correct.
I don't know the i.MX stuff at all but FW
Hi Oliver,
Yes, it works better without ehci_hcd.
I still have some minor issues, it is not flawless,
but
definitely better than before.
Please note, that for me it works the other way too:
If I rmmod uhci_hcd before suspend and I insert it
after resume, I have a happy system.
So it seems that the
On Thu, 6 Jan 2005, David Brownell wrote:
> > In any case this isn't under our control.
> > Devices are resumed in the same order they were detected initially. I
> > think the only way to solve this problem is to find a workaround for EHCI
> > controllers that act weird when they resume.
>
>
On Thu, Jan 06, 2005 at 11:59:59AM -0800, David S. Miller wrote:
> On Thu, 6 Jan 2005 20:51:44 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > DaveM can probably give you more details since he tried unsucessfully
> > to make it work. I think the problem is that there is no enough
> > informati
On Thursday, January 6, 2005 12:25 pm, Jesse Barnes wrote:
> [Sorry about the bogus reply, I don't have the original message.]
>
> That shouldn't happen. Maybe you were running an old version of the tree
> or an old version of my sysfs mmap patch? When I do a 'bk pull' of
> gregkh's latest usb tr
Crap. Folks, I must apologize for wasting your time. The issue seems
to be that the USB ports on the case look to be connected to the
motherboard improperly. I started plugging things into the ports on
the back of the motherboard and everything seems to work just fine.
It's kind of odd that it
[Sorry about the bogus reply, I don't have the original message.]
akpm wrote:
> OK. With Greg's tree:
>
> linux:/home/akpm# l /sys/devices/pci:00/:00:1d.0/
> total 0
> -r--r--r-- 1 root root 4096 2004-12-29 18:36 class
> -rw-r--r-- 1 root root 256 2004-12-29 18:36 config
> -r
On Thu, 6 Jan 2005 20:51:44 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> DaveM can probably give you more details since he tried unsucessfully
> to make it work. I think the problem is that there is no enough
> information for the compat layer to convert everything.
When the usbfs async stuff wr
> > Agree that's a problem. We just need an alternative interface here
> > or I try to come up with an x86-64 specific hack (I think it's possible
> > to do the compatibility x86-64 specific, just not in compat code for
> > all architectures who have truly separated user/kernel address spaces)
> >
* Ian Campbell <[EMAIL PROTECTED]> [Thu, Jan 06, 2005 at 03:57:18PM +]:
> When I tried it I found that DEFAULT_FMINTERVAL wasn't defined anywhere,
Did you try to get the driver running on 2.6.10?
DEFAULT_FMINTERVAL dissappeared from 2.6.9 to 2.6.10...
> I also copied the sw reset logic from
On Thu, 6 Jan 2005, Paul Ionescu wrote:
> Hi Alan,
>
> Now after a suspend/resume cycle, I see the devices
> with lsusb, but they are not working (I tried a
> mouse), and I get in logs a lot of:
> Jan 6 20:04:14 r50p kernel:
> drivers/usb/input/hid-core.c: input irq status -84
> received
> Jan
On Thu, Jan 06, 2005 at 06:53:42PM +0100, Andi Kleen wrote:
> [cc list trimmed]
>
> On Thu, Jan 06, 2005 at 06:26:13PM +0100, Petr Vandrovec wrote:
> > > Why are you issuing 64bit ioctls from 32bit applications?
> >
> > There are three reasons (main reason is that vmware is 32bit app, but it is
> "DB" == David Brownell <[EMAIL PROTECTED]> writes:
DB> I'd be interested in knowing if the following patch makes much of
DB> a difference ...
I applied it and rebuilt. (I need to learn how to do this properly;
tweaking the spec file and rebuilding takes way too long.)
Anyway, the messages
Hi Alan,
Now after a suspend/resume cycle, I see the devices
with lsusb, but they are not working (I tried a
mouse), and I get in logs a lot of:
Jan 6 20:04:14 r50p kernel:
drivers/usb/input/hid-core.c: input irq status -84
received
Jan 6 20:04:14 r50p kernel:
drivers/usb/input/hid-core.c: input
Hi Alan,
Yes, I think it works as you expected.
I have CONFIG_USB_SUSPEND and CONFIG_USB_DEBUG, and
the behaviour is:
If ehci-hcd is not loaded but only uhci-hcd, suspend
and resume works just fine with and without USB
devices plugged in.
If ehci-hcd and uhci-hcd is loaded , suspend and
resume w
Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> We saw the /proc/debug/uhci/:00:1d:0 output; what
> does the corresponding /sys/class/usb_host/.../registers
> information (for EHCI) show, before and after suspend?
After:
bus pci, device :00:1d.7 (driver 26 Oct 2004)
EHCI 1.00
> > After an ACPI S3 suspend it fails to see any USB
> > device plugged in.
Just for the record: I've seen that work with
EHCI and OHCI, for S1 suspend (which works much
like S3 from the USB perspective) and swsusp in
poweredown "S4-ish" suspend. At least, I've seen
that work for code that went
On Thursday 06 January 2005 7:48 am, Alan Stern wrote:
> I think you've run across another indication that the suspend/resume
> support in the USB drivers is not yet ready for prime time. Does the
> patch below help? (Note: this is meant for use with CONFIG_USB_SUSPEND
> not set.)
This would
Hi,
On Thu, 6 Jan 2005, Ian Campbell wrote:
> When I tried it I found that DEFAULT_FMINTERVAL wasn't defined anywhere,
> I tried setting FI=11999,FSMPS=0 as that was what the docs said the
> default was but that didn't work.
FI is the number of bit times in a frame, i.e., 11999 bit
times in 1 ms
Am Donnerstag, 6. Januar 2005 19:28 schrieb Paul Ionescu:
> Hi Oliver,
>
> Yes, it works if rmmod ehci_hcd before suspending, but
> it was a time when there was no need to rmmod anything
> before suspending ( for me was something like 2.6.7 or
> around ).
> In 2.6.9 you cannot suspend anymore with
On Thu, 6 Jan 2005, David Brownell wrote:
> > Your patch changes the initial descriptor read from 64 bytes to 18 bytes,
> > right? I'm almost certain that will break with some devices (although it
> > may help others).
>
> I think it'd work better with _most_ devices, considering that
> bugs h
Hi Alan,
After some more testing, I noticed that if I suspend
with only UHCI loaded, it works fine.
If I suspend with only EHCI loaded, it works fine.
If I suspend with both UHCI and EHCI loaded, I run in
the problems we talked about.
When I say "works fine" that means that
suspends/resumes
with
I sent this back on 2004-12-02 and saw no discussion. I'm hoping to
get this in soon. The patch is unchanged, but still applies cleanly
to 2.6.10-mm1 and linux-2.6 bk-current.
Thanks,
-Dale
This patch adds support for two PPC processors with embedded
OHCI implementations, the Freescale MPC5200
Hi Oliver,
Yes, it works if rmmod ehci_hcd before suspending, but
it was a time when there was no need to rmmod anything
before suspending ( for me was something like 2.6.7 or
around ).
In 2.6.9 you cannot suspend anymore with ehci-hcd
loaded, in 2.6.10 you can but you screw your uhci and
sometime
> "AS" == Alan Stern <[EMAIL PROTECTED]> writes:
AS> I don't know about that low speed "Unlink after no-IRQ" message,
AS> but you may be able to fix the other problems by using the
AS> "old_scheme_first=y" module parameter for usbcore.
I booted with "usbcore.old_scheme_first=y" on the kernel
Am Donnerstag, 6. Januar 2005 18:19 schrieb David Brownell:
> On Thursday 06 January 2005 6:54 am, Alan Stern wrote:
> > On Wed, 5 Jan 2005, David Brownell wrote:
> >
> > > > > Is EHCI being resumed before UHCI -- or afterwards?
> > > >
> > > > EHCI was resumed after UHCI.
> > >
> > > I suspect
Am Donnerstag, 6. Januar 2005 18:17 schrieb David Brownell:
> On Thursday 06 January 2005 8:43 am, Oliver Neukum wrote:
> > Am Donnerstag, 6. Januar 2005 17:30 schrieb David Brownell:
> > > So far so good, but this next chunk is a bug in "lsusb";
> > > it should dump one descriptor per line! And i
On Thursday 06 January 2005 6:54 am, Alan Stern wrote:
> On Wed, 5 Jan 2005, David Brownell wrote:
>
> > > > Is EHCI being resumed before UHCI -- or afterwards?
> > >
> > > EHCI was resumed after UHCI.
> >
> > I suspect it'd work better the other way around.
>
> Maybe it would, maybe not.
I'd
On Thursday 06 January 2005 8:43 am, Oliver Neukum wrote:
> Am Donnerstag, 6. Januar 2005 17:30 schrieb David Brownell:
> > So far so good, but this next chunk is a bug in "lsusb";
> > it should dump one descriptor per line! And it'd be
> > nice if it actually interpreted them ... but the modem
>
Am Donnerstag, 6. Januar 2005 15:39 schrieb [EMAIL PROTECTED]:
> I think this is what you're asking for:
>
> Here's the section of /var/log/syslog showing 2.6.10 booting, as well
> as an attempt to use the modem with the command 'pon'
Yes, it is. EBUSY is a very unusual error under these ciurcums
Am Donnerstag, 6. Januar 2005 16:40 schrieb Alan Stern:
> On Wed, 5 Jan 2005, Paul Ionescu wrote:
>
> > Hi Alan,
> >
> > I just compiled a new kernel with both
> > CONFIG_USB_SUSPEND and CONFIG_USB_DEBUG, and now it
> > works if nothing is plugged in USB when I suspend the
> > machine.
> > If I h
Am Donnerstag, 6. Januar 2005 17:30 schrieb David Brownell:
> So far so good, but this next chunk is a bug in "lsusb";
> it should dump one descriptor per line! And it'd be
> nice if it actually interpreted them ... but the modem
> put these in a nonstandard location. Currently it only
> interpre
On Wed, 5 Jan 2005, Paul Ionescu wrote:
> Hi Alan,
>
> I just compiled a new kernel with both
> CONFIG_USB_SUSPEND and CONFIG_USB_DEBUG, and now it
> works if nothing is plugged in USB when I suspend the
> machine.
> If I have something plugged in at suspend time, after
> resume it is not there a
On Wednesday 05 January 2005 4:56 pm, [EMAIL PROTECTED] wrote:
>
> Bus 001 Device 002: ID 0572:1280 Conexant Systems (Rockwell), Inc.
> Device Descriptor:
> bLength18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass2 Communications
> bDe
On Thursday 06 January 2005 7:03 am, Alan Stern wrote:
> On Wed, 5 Jan 2005, David Brownell wrote:
>
> > I'd be interested in knowing if the following patch makes much
> > of a difference ... I suspect it'd help other cases a bit better,
> > where the "-EPROTO" error suggests that the oversized re
Hi Olav,
On Mon, 2005-01-03 at 19:26 +0200, Olav Kongas wrote:
> Here comes a new isp116x driver.
When I tried it I found that DEFAULT_FMINTERVAL wasn't defined anywhere,
I tried setting FI=11999,FSMPS=0 as that was what the docs said the
default was but that didn't work.
I found that the old 2.
On Wed, 5 Jan 2005, Paul Ionescu wrote:
> The dmesg from a kernel 2.6.10 with CONFIG_USB_DEBUG
> is bellow:
> suspended without any device plugged, resumed, plugged
> a device in.
>
> uhci_hcd :00:1d.1: suspend_hc
> PM: Preparing system for suspend
> ehci_hcd :00:1d.7: --> PCI D3hot
> uhc
On Thu, 6 Jan 2005, Hou Xiang ZHU wrote:
> I think for just unlock the stick using a few extra command, this approach
> is ok, but
> what if I also want to encrypt every single byte of data on this stick(using
> some encrypt algorithm)?
> I think I have to write a special driver for it . Even if I
On Wed, 5 Jan 2005, David Brownell wrote:
> > Incidentally, if anyone can suggest why some devices like this one fail
> > with the new initialization scheme while (presumably) working correctly
> > with Windows, I would like to here it. The intent of the new scheme was
> > to duplicate exactly
On Thu, 6 Jan 2005, Vladimir Trukhin wrote:
> Hi all!
>
> And Happy New Year to everyone!
>
> 3 days ago I faced the problem which I could not solve using Google.
>
> Currently I work on board with PXA255, kernel 2.6.10, and I need the
> ability to access the
> board through USB from both Linu
On Thu, 6 Jan 2005 12:04:05 +0100, "Oliver Neukum" <[EMAIL PROTECTED]>
said:
> Am Donnerstag, 6. Januar 2005 01:56 schrieb [EMAIL PROTECTED]:
> > Hi.
> >
> > I have tried kernels 2.6.8 and 2.6.9 and now 2.6.10 all with the same
> > results. My Zoom 2985 USB modem works perfectly with 2.6.7 but no
On Wed, 5 Jan 2005, David Brownell wrote:
> > > Is EHCI being resumed before UHCI -- or afterwards?
> >
> > EHCI was resumed after UHCI.
>
> I suspect it'd work better the other way around.
Maybe it would, maybe not. In any case this isn't under our control.
Devices are resumed in the same o
Hallo,
If a programm set CRTSCTS to enable hardware-handschaking in the PL2303-device
this stays until the device is unplugged.
This is because CLOCAL is not supported in the driver.
Following works for me:
--
*** pl2303.c.orgThu Jan 6 12:29:34 2005
--- pl2303.cThu Jan 6 12:31:2
Am Donnerstag, 6. Januar 2005 01:56 schrieb [EMAIL PROTECTED]:
> Hi.
>
> I have tried kernels 2.6.8 and 2.6.9 and now 2.6.10 all with the same
> results. My Zoom 2985 USB modem works perfectly with 2.6.7 but not
> with any kernel since then.
>
> Below is some information that I think is relevant
On Thursday 06 January 2005 02:50, Alan Stern wrote:
> ...
> Srihari, can you try reproducing this after rebuilding the usb-storage
> driver with CONFIG_USB_STORAGE_DEBUG=y?
Alan,
Sure, I shall try to trigger this bug with the debug option.
(But I am afraid it would take a couple of days, as tha
Hi all!
And Happy New Year to everyone!
3 days ago I faced the problem which I could not solve using Google.
Currently I work on board with PXA255, kernel 2.6.10, and I need the ability to
access the
board through USB from both Linux and Windows hosts.
I built the kernel with USB Gadget support
Hi all!
And Happy New Year to everyone!
3 days ago I faced the problem which I could not solve using Google.
Currently I work on board with PXA255, kernel 2.6.10, and I need the
ability to access the
board through USB from both Linux and Windows hosts.
I built the kernel with USB Gadget support fo
80 matches
Mail list logo
