- регистрацию отчета об итогах выпуска эмиссионных ценных бумаг.
что, ежели заметят? -- подумал Бакланов с тайной дрожью. -- Не уйти нам на
бывший студент, столкнулся однажды c необходимостью поднять дух y
Морозки с Варей "ничего не вышло" и причиной этому -- он, Мечик. Неловкая
Andreas Hirstius wrote:
Hi David,
Sorry for the confusion of deadlock and Oops. I'm not that familiar with
the terms...
No prob.
here is the disassemble output of gdb:
if you're sure this was from the same kernel that caused the oops ...
then this bit looks to be the operative part of spin_unlo
The problem is that the prism2's single interface is number 1, but
according to the USB standard interfaces are supposed to be
numbered starting at 0. This is a fairly common error among USB devices.
The patch below will cause the kernel to accept the device; please let us
know how it works out.
I
> riddled with races of this kind. The simplest solution is to
> systematically take ps->dev->serialize when entering the usbfs routines,
> which is what my patches do. This should be regarded as a first step: it
What is the alternative?
> gives correctness, but at the cost of a probable perfo
Am Samstag, 17. April 2004 22:13 schrieb Alan Stern:
> On Sat, 17 Apr 2004, David Brownell wrote:
> > > Oh, I've rewritten the usb-skeleton driver so that it contains no locks
> > > now (with the exception of the BKL to protect on disconnect.) It's a
> > > world simpler, but I've probably forgotte
On Wednesday 14 April 2004 12:29, Duncan Sands wrote:
> Hi Greg, this is the first of a series of patches that replace the
> per-file semaphore ps->devsem with the per-device semaphore
> ps->dev->serialize. The role of devsem was to protect against
> device disconnection. This can be done equally
On Sat, 17 Apr 2004, David Brownell wrote:
> > Oh, I've rewritten the usb-skeleton driver so that it contains no locks
> > now (with the exception of the BKL to protect on disconnect.) It's a
> > world simpler, but I've probably forgotten something here. I've
> > attached it below if anyone want
On Sat, 17 Apr 2004, Duncan Sands wrote:
> On Saturday 17 April 2004 20:31, Duncan Sands wrote:
> > Alan, do you have a suggestion for how best to go from
> > a struct usb_interface to an index?
The only way is by searching the interface list. That was part of the
reason I left findintfif() alo
On Saturday 17 April 2004 20:31, Duncan Sands wrote:
> Alan, do you have a suggestion for how best to go from
> a struct usb_interface to an index?
(though probably usbfs shouldn't use indices at all,
just interface numbers and struct usb_interface).
-
Am Samstag, 17. April 2004 20:33 schrieb Duncan Sands:
> Hi Oliver, so something like this?
Yes.
Regards
Oliver
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins
Although when disconnect() happens because of physical device
disconnect (instead of config change, or other disconnect/rebind
cases), such requests can/do fail cleanly.
[ which is a new-in-2.6 feature I'm glad we could get... ]
Yeah, I hate the "rebind" nonsense... bleah.
That's where it fails
Hi Oliver, so something like this?
--- gregkh-2.6/drivers/usb/core/devio.c.orig2004-04-17 20:12:11.0 +0200
+++ gregkh-2.6/drivers/usb/core/devio.c 2004-04-17 20:31:48.0 +0200
@@ -335,6 +335,7 @@
static void driver_disconnect(struct usb_interface *intf)
{
struct dev_st
Alan, do you have a suggestion for how best to go from
a struct usb_interface to an index?
Thanks,
Duncan.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo
Robert Schwebel wrote:
Unfortunately, the Hynix docs [1] are not very, hmmm, let's say detailed
Right ... but the config descriptor on p. 91 strongly suggests that
the only configuration number supported is "2". It also suggests:
- idProduct and idVendor are settable
- bDevice{Class,SubClass,
> So, if you really want to give an interface to another driver, we need
> to just unregister it and create a new one. That way it will all "just
> work" properly.
>
> The reason I created those functions is we never completed the usb
> device -> usb interface conversion fully during 2.5. Drivers
> > Um no. It should fail. It will happen, and is allowed. This works
> > correctly today, and we can not break this.
>
> That's where we disagree: I'm saying it FAILS today (as in 2.4).
> Except in the main case, so maybe we don't disagree that much.
Either it works always or it doesn't work
Greg KH wrote:
Yes, but we can't guarantee that the driver is done with the device, or
the interface after disconnect() is over. And we don't want to do that
either, otherwise it makes the driver's lives a big pain.
That doesn't seem quite right. Here's what I thought the (new) story was
going t
[EMAIL PROTECTED] wrote:
it's lastest firmware version.
it's possible determine what it is - linux-related problem, firmware
problem or any hradware prolem?
The symptom you gave is of a firmware bug. The vendor should
of course fix such bugs, because they warrantied that their
product would work.
Oliver Neukum wrote:
But unless you're interested in finishing a much-needed rewrite
of that cdc-acm probe() code, this might be a good place to stop.
(Or at least pause!)
Hi,
just to make sure. You are talking about evaluating the descriptor
described in chapter 5.2.3.8 "Union Functional Descr
TAIWAN FU KUNG INDUSTRIAL CO., LTD.
18 Tong Kuan Street, San Min Dist., Kaohsiung, Taiwan, R.O.C.
PO. Box 728, Kaohsiung, Taiwan
FAX:886-7-3126142 TEL: (07)3126136 Email: [EMAIL PROTECTED]
===
TO: [EMAIL PROTECTED]
APR. 17, 2004
RE: AUTO/SCOOTER/MOTOR
Am Freitag, 16. April 2004 20:44 schrieb David Brownell:
> Hi Colin,
>
> > Here's another patch, which fixes the leak. It also fixes the
> > FIXME, by looking at all interfaces to find the data one. Is it correct ?
>
> It's looking better, but what I'd rather see is code scanning the
> CDC descript
Dave,
On Fri, Apr 16, 2004 at 10:47:09AM -0700, David Brownell wrote:
> >I'm working on support for a chip which handles EP0 trafic almost
> >completely in hardware (Hynix H7202). As you don't get things like Set
> >Configuration Requests the usual state machines do not work, so I fake
> >the call
>> i use zyxel uno modem (usb 56k cdc-acm modem, i think it present only
>> on russian market). after two or more hours of connection this modem
>> can hang-up - all leds are on and modem don't respond. i need do power
>> off to reset modem.
DB> Sounds like a firmware bug. Can you get updated fir
Hi David,
Sorry for the confusion of deadlock and Oops. I'm not that familiar with
the terms...
here is the disassemble output of gdb:
.
0x0f95 :lock addl $0x0,0x0(%esp,1)
0x0f9b :mov0x8(%esi),%ebx
0x0f9e :test %bl,%bl
0x0fa0 :js 0x1
On 16 Apr 2004 at 23h04, Colin Leroy wrote:
Hi,
> Ok, here is the cosmetic patch following the previous one, then :)
Uhm, previous patch is broken.
Here are the two again.
--
Colin
1_cdc-acm.patch
Description: Binary data
2_cdc-acm-cosmetic.patch
Description: Binary data
VIRUS ALERT
Our virus checker found
virus: Worm/NetSky.P
banned filename: message.scr
in your email to the following recipient:
-> [EMAIL PROTECTED]
Delivery of the email was stopped!
Please check your system for viruses,
or ask your system administrator to do so.
For your reference, he
> > And the current story for trying to talk to the device after disconnect()
> > wouldn't change: it's not allowed.
>
> Um no. It should fail. It will happen, and is allowed. This works
> correctly today, and we can not break this.
No, it works iff there was a physical disconnect. Else it do
27 matches
Mail list logo
