The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
Hi,
Here are 4 small fixes for some USB serial driver issues. They have
all been in the 2.6 tree for some while now. Pete suggested I send
these directly to you, instead of having to go through him.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/usb-2.4
The individual patches
The original message was received at Wed, 16 Jun 2004 03:27:26 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:27 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:26 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
ChangeSet 1.1449, 2004/06/14 16:08:48-07:00, [EMAIL PROTECTED]
USB: fix empty write issue in pl2303 driver.
Patch originally from Christian Groessler [EMAIL PROTECTED] but cleaned up
by me.
drivers/usb/serial/pl2303.c |3 +++
1 files changed, 3 insertions(+)
diff -Nru
ChangeSet 1.1448, 2004/06/14 16:07:03-07:00, [EMAIL PROTECTED]
[PATCH] USB ftdi device ids for 2.4
drivers/usb/serial/ftdi_sio.c |7 +++
drivers/usb/serial/ftdi_sio.h |5 +
2 files changed, 12 insertions(+)
diff -Nru a/drivers/usb/serial/ftdi_sio.c
ChangeSet 1.1451, 2004/06/14 16:19:17-07:00, [EMAIL PROTECTED]
[PATCH] USB: pl2303 input overruns
Backport the 2.6 fixes for handing overruns and other status reports
from the device.
drivers/usb/serial/pl2303.c |8 +++-
1 files changed, 7 insertions(+), 1 deletion(-)
diff -Nru
On Tue, Jun 15, 2004, Duncan Sands [EMAIL PROTECTED] wrote:
On Tuesday 15 June 2004 18:01, David Brownell wrote:
Duncan Sands wrote:
Are there plans to replace usbfs with sysfs, or increase sysfs's
functionality (e.g. I/O with device endpoints)?
I have a plan to rewrite usbfs
Hello,
Can anyone give pointers where to start looking for more information
about the problem below? My little experience so far is with nic
drivers and I don't have time to start reading on usb guts,
unfortunately.
- Forwarded message from Jaakko Niemi [EMAIL PROTECTED] -
From:
On Tue, Jun 15, 2004 at 10:46:15AM -0700, Johannes Erdfelt wrote:
Would anyone accept a patch to increase the maximum buffer size in the
existing usbfs?
For 2.6, yes, I would.
thanks,
greg k-h
---
This SF.Net email is sponsored by The 2004
This patch fixes the USB hub module to process events in the order that they
are received. It fixes the case where multi-port devices have multiple
hubs in them--while they are detected in the correct order, they are
initialized in reverse. It is required for the Sealink 8-port USB-serial hubs
to
Alan Stern wrote:
On Thu, 15 Jan 2004, Greg KH wrote:
We really
need to start over and make usbfs2. It should look something like the
gadgetfs interface.
What about backward compatibility?
How much is needed? Remember that usbfs1 and usbfs2 need to
coexist for a while. What usbfs1
Duncan Sands wrote:
I have some notes about what I think usbfs2 should
probably do. With more questions than answers, to be
honest! Because more like gadgetfs only gets part
way into the problem. Would it help if I posted that?
Please do.
Just done ... please follow up on that usbfs2 thread.
-
On Tue, 15 Jun 2004, David Brownell wrote:
Alan Stern wrote:
On Mon, 14 Jun 2004, David Brownell wrote:
Seems like the dma_alloc_coherent() API spec can't be
implemented on such machines then, since it's defined
to return memory(*) such that:
... a write by either the device or
Richard Curnow wrote:
One problem I'm hitting is in EHCI, I was wondering if you had any ideas
as to what I could start looking at, annotating etc to debug this. The
problem seems to be here:
static inline void list_del(struct list_head *entry)
{
__list_del(entry-prev, entry-next);
Nicolas DET wrote:
Another possibilitie would be that the UHCI chipset likely access to the
memory on 4 64-bit words burst access as it requieres 16-byte boundary
alignement. If the chip write the value to the QH in burst mode it can
likely overwrite the software field. Cache coherency would not
On Tue, Jun 15, 2004 at 02:26:49PM -0400, Byron Stanoszek wrote:
This patch fixes the USB hub module to process events in the order that they
are received. It fixes the case where multi-port devices have multiple
hubs in them--while they are detected in the correct order, they are
initialized
That text strikes me as rather ambiguous. ...
... It doesn't specify what happens to the other data
bytes in the same cache line which _weren't_ written -- maybe they'll be
messed up.
Actually I thought it was quite explicit: without having
to worry about caching effects. What you described
David:
This patch fixes the bug you ran across in the scatter-gather library.
(It includes my earlier change to suppress incorrect error messages as
well).
The problem turned out to be the way io-count was handled. I'm assuming
that field was meant to be a count of outstanding URBs. If it
David Brownell wrote:
Except that the UHCI spec is clear that in a given QH (or TD),
only one word is modified and the others are read-only. So
I see no way that real UHCI would ever write more than one
32-bit word at a time. Whose UHCI silicon is this, and do you
know for a fact that something
Greg:
This patch adds a bit-array to the hub driver's private data structure,
used for storing the contents of the hub's interrupt status message. That
message indicates which ports have events pending (and whether the hub
itself has events pending). By only polling the status of the ports
Jaakko Niemi wrote:
I have couple different problems with two different Edgeport boxes,
which are hooked into a Dell PowerEdge 1750 with ServerWorks OSB4/CSB5
ohci usb controller, running 2.4.26 without any patches.
First, with older Edgeport/8, if I try to access any of /dev/ttyUSBx
devices,
On Tue, 15 Jun 2004, Alan Stern wrote:
On Mon, 14 Jun 2004, David Brownell wrote:
Seems like the dma_alloc_coherent() API spec can't be
implemented on such machines then, since it's defined
to return memory(*) such that:
... a write by either the device or the processor
can immediately be
I've developed a custom I/O control board for haptics and robotics using
an Atmel AVR and a Cypress USB 2.0 IC.
(http://www-brl.ee.washington.edu/~jdosher/Pictures/Thumbnails/BoardTH.html)
We've been having some trouble getting our USB (interrupt based) driver
working at anything faster than a
On Tue, Jun 15, 2004, Al Borchers [EMAIL PROTECTED] wrote:
Skimming through the usb-ohci.c code quickly, it seems that OHCI
calls the interrupt urb completion handlers for periodic interrupt
urbs with its ohci_t ohci_lock spin lock held. (See hc_interrupt,
dl_done_list, and sohci_return_urb.)
I sent this message off a week ago (June 8th) and received no reply. Looks like
the mailing list is being spammed, so I suppose it could've been missed.
My concern is: What happens when a user process has a USB serial device (e.g.
/dev/ttyUSB0) open and the USB cable is unplugged. Right now, the
On Tue, Jun 15, 2004, David Brownell [EMAIL PROTECTED] wrote:
Alan Stern wrote:
On Thu, 15 Jan 2004, Greg KH wrote:
We really
need to start over and make usbfs2. It should look something like the
gadgetfs interface.
What about backward compatibility?
How much is needed?
On Tue, Jun 15, 2004 at 03:04:30PM -0700, J. Dosher wrote:
I've developed a custom I/O control board for haptics and robotics using
an Atmel AVR and a Cypress USB 2.0 IC.
(http://www-brl.ee.washington.edu/~jdosher/Pictures/Thumbnails/BoardTH.html)
We've been having some trouble getting our
I'm getting about 1000 lines of output, so I'll try to just include just
what looks important. First off, here's my Makefile (just in case that's
the problem).
KERNELDIR = /usr/src/linux #aliased as /usr/src/linux -
/usr/src/linux-2.6.5-1.358/
include $(KERNELDIR)/.config
CFLAGS = -D__KERNEL__
On Tue, Jun 15, 2004 at 03:48:59PM -0700, J. Dosher wrote:
I'm getting about 1000 lines of output, so I'll try to just include just
what looks important. First off, here's my Makefile (just in case that's
the problem).
That is the problem. Please read the documentation on how to build
kernel
On Tue, 15 Jun 2004, Al Borchers wrote:
I will make this change and try to test it out on OHCI.
Ok, if you have a patch, I can test it. Sorry, that
I cannot do anything more atm.
--j
---
This SF.Net email is sponsored by
Johannes Erdfelt wrote:
UHCI had a similar problem. We just created a list of completions and
added the URB to that list and then called the completions later in the
interrupt with no locks held.
And it looks like OHCI does something similar for bulk, control, and
one-shot interrupt urbs. But
John Carlson wrote:
While developing a gadget driver for the 2.4 kernel, I
discovered this error in the gadget driver. This bug
has been present since the gadget driver was back
ported from the 2.6 kernel.
Actually, it's just that one source file (config.c),
and the fix is in the gadget-2.4 tree
Al Borchers wrote:
Johannes Erdfelt wrote:
UHCI had a similar problem. We just created a list of completions and
added the URB to that list and then called the completions later in the
interrupt with no locks held.
And it looks like OHCI does something similar for bulk, control, and
one-shot
David Brownell wrote:
And 2.6 cleans up that locking wierdness, as well as others.
Though to be honest, I don't remember this as a 2.4 issue; is
that from those recent OHCI changes?
I don't know the history, but these changes (the ohci_lock spin
lock and postponing the callback or not until after
Hello everyone,
I am trying to develop a Wireless USB stack similar to the USB stack. The
Wireless USB will be on IEEE 802.15.3.
One confession at this stage. I am not much acquainted with USB programming.
However, I more than willing to put the requisite effort.
Okay, now the major problem
On Mon, 24 May 2004 01:00:44 +1000
Ben Low [EMAIL PROTECTED] wrote:
Hello Greg, (Andrej,)
Fantastic - the patched driver works a treat.
I'll keep it around in my tree in case Greg forgets.
-- Pete
---
This SF.Net email is sponsored by
On Mon, 14 Jun 2004, Nicolas DET wrote:
Hello !
I'm Nicolas DET. And I've a patch for the Linux 2.6.6 UHCI driver.
Some users complain that our computers (Pegasos II
http://www.pegasosppc.com/) are instable (systems hangs) when stressing
the USB (we use a VIA-8231 SouthBridge) on Linux
The original message was received at Tue, 15 Jun 2004 16:35:46 +0900 (JST)
from host251-194.pool8173.interbusiness.it [81.73.194.251]
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
(reason: 554 [EMAIL PROTECTED]... User not found on database --- Message
The original message was received at Tue, 15 Jun 2004 17:44:49 +0900 (JST)
from host251-194.pool8173.interbusiness.it [81.73.194.251]
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
(reason: 554 [EMAIL PROTECTED]... User not found on database --- Message
The original message was received at Tue, 15 Jun 2004 18:43:25 +1000
from host251-194.pool8173.interbusiness.it [81.73.194.251]
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL
The original message was received at Tue, 15 Jun 2004 17:54:08 +0900 (JST)
from host251-194.pool8173.interbusiness.it [81.73.194.251]
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
(reason: 554 [EMAIL PROTECTED]... User not found on database --- Message
Alan Cox wrote:
This requires a lot of care to do right. Remember that on PC systems
interrupts can be substantially posted. A stop_interrupt may prevent
IRQ issue but if an IRQ is already on the PC APIC bus it will kill you
later on because the IRQ delivery and PCI bus access on the PC class
David Brownell wrote:
I'm reading it as: on the PPC boxes in question,
dma_alloc_coherent() -- used indirectly to allocate
the memory in question -- is returning memory that
doesn't work as required by the text I quoted.
Specifically, caching effects DO exist, ones where
the CPU's L1
Hi.
Im attempting to get the USB function on the TC6393XB (Toshiba multi-io chip) working.
This chip is used in their PDAs, including the e740, e750, and e800.
I have register documentation for the chip but it is very sparse, however I can bring
up the USB and have OHCI registers in memory
x86 systems are supposed to be cache coherent in this situation. The
bridge will untangle the mess as neccessary. The PC is the unusual one
here - most other platforms (eg mips) behave like the PPC
Okay. So we do need to put the parts written by the hardware and the
parts used by the
If the QH memory were truly coherent, that patch could never
matter. Someone who knows that CPU better should probably
answer more detailed questions. For example, I'd think that
using uncached mappings for that memory should ensure that the
accesses are coherent enough.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Dienstag, 15. Juni 2004 00:08 schrieb Duncan Sands:
x86 systems are supposed to be cache coherent in this situation. The
bridge will untangle the mess as neccessary. The PC is the unusual one
here - most other platforms (eg mips) behave
Hi. This is the qmail-send program at relay01.ipcare.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]:
194.195.64.36 does not like recipient.
Remote host said: 550 That e-mail
On Maw, 2004-06-15 at 10:08, Nicolas DET wrote:
For this specific case, the interrupt handler should manage it:
if ( (!(status ~USBSTS_HCH)) /* shared interrupt, not mine */
|| (!uhci-IntEnableReg_SW) )
{
retval = IRQ_NONE;
goto end;
}
Alan Cox wrote:
It makes me nervous. The first thing I see is the question about
ordering between posted writes to the IntEnable reg in PCI space and the
software register. The second thing is returning IRQ_NONE causing the
screaming interrupt warning.
outw() takes care of the ordering. by the
[EMAIL PROTECTED] wrote:
Stuart Hayes here at Dell has identified this or/and mix-up in the
ehci-hcd driver. Because of this, ehci-hcd is not properly released by
BIOSes supporting full 2.0 and port behavior can then become erratic.
Good patch, it should be merged. That handoff code actually
Are there plans to replace usbfs with sysfs, or increase sysfs's
functionality (e.g. I/O with device endpoints)?
--
Dan Streetman
[EMAIL PROTECTED]
-
186,272 miles per second:
It isn't just a good idea, it's the law!
---
Are there plans to replace usbfs with sysfs, or increase sysfs's
functionality (e.g. I/O with device endpoints)?
I have a plan to rewrite usbfs along the lines of gadgetfs.
Ciao,
Duncan.
---
This SF.Net email is sponsored by The 2004
Duncan Sands wrote:
Are there plans to replace usbfs with sysfs, or increase sysfs's
functionality (e.g. I/O with device endpoints)?
I have a plan to rewrite usbfs along the lines of gadgetfs.
How much of a plan? :)
I have some notes about what I think usbfs2 should
probably do. With more
The original message was received at Wed, 16 Jun 2004 01:10:50 +0900 (JST)
from host251-194.pool8173.interbusiness.it [81.73.194.251]
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
(reason: 554 [EMAIL PROTECTED]... User not found on database --- Message
On Mon, 14 Jun 2004, Oliver Neukum wrote:
Am Montag, 14. Juni 2004 23:05 schrieb Alan Stern:
Is there an easy way to do this without also paying the alignment penalty
on platforms that don't require it (or even just on x86)? Or should we
simply accept the wasted space?
A
On Mon, 14 Jun 2004, David Brownell wrote:
Seems like the dma_alloc_coherent() API spec can't be
implemented on such machines then, since it's defined
to return memory(*) such that:
... a write by either the device or the processor
can immediately be read by the processor or device
On Tuesday 15 June 2004 18:01, David Brownell wrote:
Duncan Sands wrote:
Are there plans to replace usbfs with sysfs, or increase sysfs's
functionality (e.g. I/O with device endpoints)?
I have a plan to rewrite usbfs along the lines of gadgetfs.
How much of a plan? :)
More of a
Nicolas DET wrote:
David Brownell wrote:
I'm reading it as: on the PPC boxes in question,
dma_alloc_coherent() -- used indirectly to allocate
the memory in question -- is returning memory that
doesn't work as required by the text I quoted.
Specifically, caching effects DO exist,
Ian Molton wrote:
Hi.
Hi back ... your linewrap setting is broken, please
force line ends at the 72-character column or so.
is there a way to provoke interrupts from an OHCI chiip? I need to be able to generate interrupts reliably so that I can work out how to set up the chips interrupt masking /
David Brownell wrote:
I think most of the PowerPC machine works just like the x86.
About this one (Pegasos II), it does support cache coherency/bus
snooping.
So, IMO, dma_alloc_coherent is correct (otherwise, nothing would work,
and we would need to rewrote each Linux driver ...)
But you DID
Alan Stern wrote:
On Mon, 14 Jun 2004, David Brownell wrote:
Seems like the dma_alloc_coherent() API spec can't be
implemented on such machines then, since it's defined
to return memory(*) such that:
... a write by either the device or the processor
can immediately be read by the processor or
Actually I thought it was quite explicit: without having
to worry about caching effects. What you described is
clearly a caching effect: caused by caching.
Is it really a cache effect? Isn't it caused by the hc writing
more bytes to memory than you expected? Now, it so
happens that the
On Tue, Jun 15, 2004 at 11:18:34AM -0400, Dan Streetman wrote:
Are there plans to replace usbfs with sysfs,
No.
or increase sysfs's functionality (e.g. I/O with device endpoints)?
Nope, please see the _many_ threads about trying to add such a thing to
sysfs on lkml over the past 3 years.
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:24 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:24 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:22 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:24 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:24 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:27 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:26 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:27 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:23 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
The original message was received at Wed, 16 Jun 2004 03:27:25 +1000
from mail.bne003m.webmetrix.com.au [210.9.95.7] (may be forged)
- The following addresses had permanent fatal errors -
[EMAIL PROTECTED]
- Transcript of session follows -
550 5.1.1 [EMAIL PROTECTED]...
99 matches
Mail list logo
