Hi. This is the qmail-send program at tsi-gmbh.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
Sorry, no mailbox here by that name. vpopmail (#5.1.1)
--- Below this line is a
VIRUS ALERT
Our virus checker found
virus: Worm.SomeFool.P
banned filename: information_cwhuang.exe
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
ACADEMIA WALL STREET FITNESS
Fone: 3335-7227 3291-6590
Clientes
e funcionários das empresas abaixo.
Pagam
apenas R$ 58,00 para fazer ginástica e musculação todos os dias horários livres e R$
70.00 para spinning, ginástica e
musculação.
TELEMIG
CELULAR - TIM M
On Wed, 24 Mar 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > (2) Change the strategy used by as163a; make it do lazy checking.
> > Rather than waiting for all the interfaces to be released when
> > their configuration is removed, wait for all the interfaces to
> > be
Hi. This is the qmail-send program at kibo.cam.equator.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>:
10.0.0.15 failed after I sent the message.
Remote host said: 554 5.7.1 V
On Wed, 24 Mar 2004, David Brownell wrote:
> Alan Stern wrote:
>
> > The real question is, how should this best be handled? I can see several
> > possible approaches:
> >
> > (1) Leave the temporary fix in place and don't worry about it.
>
> For the 2.6.5 kernel, I'd encourage merging
On Wed, 24 Mar 2004, Pat LaVarre wrote:
> > the sizeable benefit David was
> > talking about really applies only to high-speed devices. Full-speed
> > devices won't notice the difference nearly as much.
>
> Loosely paraphrased, I see you saying we feel 80% of the pain in HS, so
> naturally I as
Paulo Marques wrote:
Oliver Neukum wrote:
On Wednesday 24 March 2004 19:52, Paulo Marques wrote:
Ok, done.
The EINVAL is being returned from the usb_submit_urb in urb.c because
urb->hcpriv is not NULL.
OK. This means that the URB is not unlinked.
Possibly unlinking in close() is failing.
Coul
Ari Pollak wrote:
I used to (a couple of kernel versions ago) be able to
run gphoto2 as a normal user, since my /proc/bus/usb was mounted with
devmode=666. however, now I can only run gphoto2 as root or else it gives me
this error:
It's almost as if you're seeing
http://bugme.osdl.org/s
Alan Stern wrote:
The real question is, how should this best be handled? I can see several
possible approaches:
(1) Leave the temporary fix in place and don't worry about it.
For the 2.6.5 kernel, I'd encourage merging the temporary fix ASAP ...
and decide later whether some better solution
Oliver Neukum wrote:
On Wednesday 24 March 2004 19:52, Paulo Marques wrote:
Ok, done.
The EINVAL is being returned from the usb_submit_urb in urb.c because
urb->hcpriv is not NULL.
OK. This means that the URB is not unlinked.
Possibly unlinking in close() is failing.
Could you go to static void
On Wednesday 24 March 2004 19:52, Paulo Marques wrote:
> Oliver Neukum wrote:
>
> >
> >
> >>One thing that caught my attention was the "ftdi_read_bulk_callback" *after* the
> >>first "ftdi_close".
> >>
> >>I'll continue the bug hunt. If you have any suggestions, please let me know.
> >>
> >
>
Your message was refused by recipient's server filtering program.
Reason given was as follows:
Disallowed attach type
Reporting-MTA: dns; smtp5.libero.it
Received-from-MTA: dns; libero.it (81.74.46.146)
Arrival-Date: Wed, 24 Mar 2004 17:37:36 +0100
Final-Recipient: rfc822; [EMAIL PROTECTED]
Actio
Oliver Neukum wrote:
One thing that caught my attention was the "ftdi_read_bulk_callback" *after* the
first "ftdi_close".
I'll continue the bug hunt. If you have any suggestions, please let me know.
It is normal that there is at least one call to the completion handler
after close, because c
Pat LaVarre wrote:
David B:
Thanks for your interest.
In practice, I haven't yet proven that any of my devices actually do
benefit from a max GB/cdb greater than 0.65536 while an fs is
mounted ...
You mean, 64 KByte/request?
Probably yes. Sorry I don't know what a "request" is. Do you
David B:
Thanks for your interest.
In practice, I haven't yet proven that any of my devices actually do
benefit from a max GB/cdb greater than 0.65536 while an fs is
mounted ...
You mean, 64 KByte/request?
Probably yes. Sorry I don't know what a "request" is. Do you already
know what a "
the sizeable benefit David was
talking about really applies only to high-speed devices. Full-speed
devices won't notice the difference nearly as much.
Loosely paraphrased, I see you saying we feel 80% of the pain in HS, so
naturally I ask:
Do we get 80% of the interop benefit if we choke off byt
On Wed, 24 Mar 2004 16:05:53 +
Paulo Marques <[EMAIL PROTECTED]> wrote:
> "while true; do ftditest /dev/usb/tts/0; done"
>
> it starts printing "open: No such device" and you get on the system log:
> > drivers/usb/serial/ftdi_sio.c: ftdi_open - failed submitting read urb, error -22
> > FTD
> One thing that caught my attention was the "ftdi_read_bulk_callback" *after* the
> first "ftdi_close".
>
> I'll continue the bug hunt. If you have any suggestions, please let me know.
It is normal that there is at least one call to the completion handler
after close, because close unlinks th
> With only this patch applied, gphoto2 operates correctly, lsusb no
> longer lists the camera after disconnection, and I see only a single
> suspend_hc message after disconnection.
I am seeing the same correct-ish behavior with my USB mouse -it now works both
when connected at startup and after c
On Wed, 24 Mar 2004, David Brownell wrote:
> Pat LaVarre wrote:
>
> > In practice, I haven't yet proven that any of my devices actually do
> > benefit from a max GB/cdb greater than 0.65536 while an fs is
> > mounted ...
>
> You mean, 64 KByte/request? I'm curious what the relevant number
Oliver Neukum wrote:
On Wednesday 24 March 2004 17:05, Paulo Marques wrote:
Hi,
There is some race condition on the ftdi_sio.c usb serial driver.
I was having problems with an application, so I did the smallest test program
that would trigger the bug:
int main(int argc,char *argv[])
{
int ha
Everybody:
As we all know now, the strategy used by my patch as163a doesn't work
well. Here's the background:
The first development was a patch introduced by Greg in ChangeSet
1.7.3.186 2003/12/16. That patch changed lib/kobject.c, making it so that
a kobject doesn't decrement its parent's r
Alan Stern <[EMAIL PROTECTED]> writes:
> Apparently all of you are suffering from the same problem, caused by a
> change that I made not long ago. Oddly enough, it worked perfectly on my
> system -- but I don't have a USB scanner, printer, or mouse!
>
> The patch below is not a permanent fix (at
On Wednesday 24 March 2004 17:05, Paulo Marques wrote:
>
> Hi,
>
> There is some race condition on the ftdi_sio.c usb serial driver.
>
> I was having problems with an application, so I did the smallest test program
> that would trigger the bug:
>
> > int main(int argc,char *argv[])
> > {
> >
Pat LaVarre wrote:
In practice, I haven't yet proven that any of my devices actually do
benefit from a max GB/cdb greater than 0.65536 while an fs is
mounted ...
You mean, 64 KByte/request? I'm curious what the relevant number
is for IDE or SATA... and how disk and page caching affect it.
T
Hi,
Pavel Roskin wrote:
Try enabling CONFIG_USB_DEBUG and then forward the entire dmesg
output for USB enumeration (initial), removing a device (flag
where that was in the log), and re-inserting a new one (also flag
that point).
If it doesn't show anything for the removal, then make sure
to includ
Mark McPherson wrote:
Not sure whether this is a kernel, hotplug, or usb question.
Beginning somewhere in the 2.6.5-rc1-mmX series, all my usb devices are
apparently disconnected during the boot process -- they are detected but
subsequently made inactive. Post-boot lsusb output shows them still
at
Hi,
There is some race condition on the ftdi_sio.c usb serial driver.
I was having problems with an application, so I did the smallest test program
that would trigger the bug:
int main(int argc,char *argv[])
{
int handle;
handle=open(argv[1],O_RDWR);
if(handle==-1)
perror("open");
else
Alan Stern wrote:
On Mon, 22 Mar 2004, David Brownell wrote:
Alan Stern wrote:
Perhaps even worse, if there are interfaces claimed by usbfs then calling
usb_set_configuration() will result in deadlock.
This makes me think that if _any_ interfaces are claimed,
then this call should be rejected.
On Wed, 24 Mar 2004, Matthias Andree wrote:
> I have skipped your previous patch; the patch you sent on Friday (with
> proc_setconfig) seems to have improved the situation already, and showed
> that iscan used proc_setconfig. The patch of this mail you sent (quoted
> for reference below) seems to
On Wed, 24 Mar 2004, Malcolm Blaney wrote:
> Alan Stern wrote:
> > Interesting. This weighs against the hypothesis of a hardware problem
> > (device monopolizing the PCI bus, for example). Even 3 ms after FSBR was
> > turned on the system was still operational.
>
> This might be a stupid ques
The original message was received at Wed, 24 Mar 2004 10:47:56 -0500 (EST)
from localhost [127.0.0.1]
- The following addresses had permanent fatal errors -
<[EMAIL PROTECTED]>
- Transcript of session follows -
No directory entries found similar to '[EMAIL PROTECTED]'
Please
Apparently all of you are suffering from the same problem, caused by a
change that I made not long ago. Oddly enough, it worked perfectly on my
system -- but I don't have a USB scanner, printer, or mouse!
The patch below is not a permanent fix (at least, I hope it isn't), but it
should take care
On Sun, Mar 21, David Brownell wrote:
> Olaf Hering wrote:
> >
> >the mouse will not disappear from /proc/bus/usb/devices, even if I
> >unplug the mouse. Same for the keyspan device, it seems the ports are
> >dead for some reason.
>
> Sounds more like "khubd" is wedged. It's annoying, but that'
V I R U S A L E R T
Our viruschecker found the
virus(es) in your email to the following recipient(s):
-> <[EMAIL PROTECTED]>
Delivery of the email was stopped!
Please check your system for viruses, or ask your system administrator
to do so.
For your refer
* * * * * * * * * * * * * * * AntiVir ALERT * * * * * * * * * * * * * * *
This version of AntiVir is licensed and full featured.
AntiVir has detected the following in a mail from your address:
Worm/NetSky.P worm
The mail was not delivered.
Please remove any potential malicious sof
Your message
To: [EMAIL PROTECTED]
Subject: fake
Sent:Wed, 24 Mar 2004 07:32:44 -0500
did not reach the following recipient(s):
[EMAIL PROTECTED] on Wed, 24 Mar 2004 07:30:13 -0500
The recipient name is not recognized
The MTS-ID of the original message is: c=us;a= ;p=m
Akkana Peck wrote:
> In 2.6.4,on a machine with a VIA chipset (uhci) and an additional
> ehci usb2/ieee1394 card, I get an endless stream of:
>
> hub 1-0:1.0: over-current change on port %d (where %d is 3, 4, and 5).
>
> I also got this message in 2.6.1, though I don't think it was quite
> so in
Alan Stern <[EMAIL PROTECTED]> writes:
> On Tue, 23 Mar 2004, Sean Neakums wrote:
>
>> gphoto2 is not too happy with this. Below is the output.
>>
>> Also attached is an strace log, in case it is of interest.
>>
>>
40 matches
Mail list logo
