On Sun, Aug 26, 2018 at 11:53 AM Denis wrote:
>
> After about a week of work axen0 has:
>
> Ierrs = 101 (patched by axen4.diff on 6.3 according to netstat -in)
Thank you for reporting.
I have to debug with privacy consideration.
>
> Denis
>
> On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote:
> >
On Sat, Aug 25, 2018 at 9:39 PM Remi Locherer wrote:
>
> On Fri, Aug 24, 2018 at 06:02:20AM +, sc.dy...@gmail.com wrote:
> > On 2018/08/19 09:40, Stefan Sperling wrote:
> > > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> > >> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi
After about a week of work axen0 has:
Ierrs = 101 (patched by axen4.diff on 6.3 according to netstat -in)
Denis
On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/08/18 07:37, Denis wrote:
>> Hi,
>>
>> checksum err (pkt#1) appears in dmesg output only.
>>
>> Right now (after 43
On Fri, Aug 24, 2018 at 06:02:20AM +, sc.dy...@gmail.com wrote:
> On 2018/08/19 09:40, Stefan Sperling wrote:
> > On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> >> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> >>> It would help if you could send a clean
On 2018/08/19 09:40, Stefan Sperling wrote:
> On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
>> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
>>> It would help if you could send a clean version that applies to -current.
>>
>> One of the attachments was in fact
On Sun, Aug 19, 2018 at 11:40:50AM +0200, Stefan Sperling wrote:
> On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> > On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> > > It would help if you could send a clean version that applies to -current.
> >
> > One of the
On 2018/08/18 08:38, Stefan Sperling wrote:
> Thank you for taking care of axen(4).
> The problems with this driver have been known for some time.
>
> On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote:
>> - header: fix comments
>> - header: fix unused L3 type mask definition
>>
On Sun, Aug 19, 2018 at 11:05:04AM +0200, Stefan Sperling wrote:
> On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> > It would help if you could send a clean version that applies to -current.
>
> One of the attachments was in fact clean but yes, this
> thread has been much too
On Sun, Aug 19, 2018 at 09:56:33AM +0200, Remi Locherer wrote:
> It would help if you could send a clean version that applies to -current.
One of the attachments was in fact clean but yes, this
thread has been much too noisy to follow easily.
Try this.
Index: if_axen.c
For last 14 hours there is no any checksum err (pkt#1) according to
netstat -in.
On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/08/18 07:37, Denis wrote:
>> Hi,
>>
>> checksum err (pkt#1) appears in dmesg output only.
>>
>> Right now (after 43 hours of testing) there are 15
On Sat, Aug 18, 2018 at 10:38:36AM +0200, Stefan Sperling wrote:
> Thank you for taking care of axen(4).
> The problems with this driver have been known for some time.
>
> On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote:
> > - header: fix comments
> > - header: fix unused L3
Yes, netstat -in on em(4), fxp(4), xl(4) Ierrs=0 / Oerrs=0 for months.
axen4.diff has been applied. Testing.
On 8/18/2018 4:32 PM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/08/18 07:37, Denis wrote:
>> Hi,
>>
>> checksum err (pkt#1) appears in dmesg output only.
>>
>> Right now (after 43
Hi,
On 2018/08/18 07:37, Denis wrote:
> Hi,
>
> checksum err (pkt#1) appears in dmesg output only.
>
> Right now (after 43 hours of testing) there are 15 rows with checksum
> err (pkt#1) message.
>
> Previously, that network segment was connected by em(4), fxp(4), xl(4)
> drivers w/o any
Thank you for taking care of axen(4).
The problems with this driver have been known for some time.
On Tue, Aug 07, 2018 at 02:04:24PM +, sc.dy...@gmail.com wrote:
> - header: fix comments
> - header: fix unused L3 type mask definition
> - rxeof: Avoid allocating mbuf if checksum errors are
Hi,
checksum err (pkt#1) appears in dmesg output only.
Right now (after 43 hours of testing) there are 15 rows with checksum
err (pkt#1) message.
Previously, that network segment was connected by em(4), fxp(4), xl(4)
drivers w/o any issues. So the error appears for axen(4) driver
exclusively.
Hi,
On 2018/08/17 07:40, Denis wrote:
> Hi,
>
> 24 hour full load testing shows positive results.
Good news.
>
> After axen3.diff has been implemented there is no TX/RX error present at
> all. But 'checksum err (pkt#1)' appears repeatedly like this:
>
> ...
> checksum err (pkt#1)
> checksum err
Hi,
24 hour full load testing shows positive results.
After axen3.diff has been implemented there is no TX/RX error present at
all. But 'checksum err (pkt#1)' appears repeatedly like this:
...
checksum err (pkt#1)
checksum err (pkt#1)
checksum err (pkt#1)
...
You're right DHCP client is
Hi,
On 2018/08/14 08:19, Denis wrote:
> I have 6.3 kernel compiled with option XHCI_debug and axen2.diff
> implemented.
>
> I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr
> each session for different Ehternet adapters.
>
> Here is debug output when axen is connected:
I have 6.3 kernel compiled with option XHCI_debug and axen2.diff
implemented.
I'm using lladdr option for /etc/hostname.axen0 to have the same IP addr
each session for different Ehternet adapters.
Here is debug output when axen is connected:
xhci0: port=2 change=0x04
xhci0: port=2 change=0x04
On August 9, 2018 1:39 PM, sc dying wrote:
> Hi,
>
> On Wed, Aug 8, 2018 at 9:24 AM, Denis den...@mindall.org wrote:
>
> > Hi,
> > Using second diff applied to 6.3 sources and rebuilt kernel.
> > The issue is persistent + new kernel error message:
> > checksum err (pkt#1)
> > axen0: usb errors on
Hi,
On Wed, Aug 8, 2018 at 9:24 AM, Denis wrote:
> Hi,
>
> Using second diff applied to 6.3 sources and rebuilt kernel.
>
> The issue is persistent + new kernel error message:
>
> checksum err (pkt#1)
>
> axen0: usb errors on rs: IOERROR
> axen0: usb errors on rx: IOERROR
> axen0: usb error on
Hi,
Using second diff applied to 6.3 sources and rebuilt kernel.
The issue is persistent + new kernel error message:
checksum err (pkt#1)
axen0: usb errors on rs: IOERROR
axen0: usb errors on rx: IOERROR
axen0: usb error on tx: IOERROR
axen0: watchdog timeout
axen0: usb error on tx: IOERROR
Hi,
On 2018/08/07 09:23, Denis wrote:
Hi,
axen.patch.1st has been applied to CURRENT src tree fetched from
official CVS with errors listed before.
Second patch has been applied to sources from official CVS -rOPENBSD_6_3
src. To test it one more time I've unpacked src.tar.gz and sys.tar.gz
Hi,
axen.patch.1st has been applied to CURRENT src tree fetched from
official CVS with errors listed before.
Second patch has been applied to sources from official CVS -rOPENBSD_6_3
src. To test it one more time I've unpacked src.tar.gz and sys.tar.gz
from 6.3amd64 distribution CD and try
Hi,
On 2018/08/05 15:31, Denis wrote:
Can not patch original files in /usr/src/sys/dev/usb/ despite that
if_axenreg.h and if_axen.c files fetched directly from current CVS repo.
Previous patch is for -current, but perhaps your source version is 6.3.
Please try the new patch below for 6.3.
Can not patch original files in /usr/src/sys/dev/usb/ despite that
if_axenreg.h and if_axen.c files fetched directly from current CVS repo.
# patch -p0 < axen.patch
Hmm.. Lookd like a unified diff to me...
The text leading up to this was:
-
|--- sys/dev/usb/if_axenreg.h
On Mon, Jul 30, 2018 at 12:11 AM, wrote:
> - Use DMA buffer aligned at 64KB boundary to avoid xhci bug.
In function xhci_event_xfer() xfer->actlen should be calculated
from sum of transferred TRB length, not xfer->length - remain,
when the transfer is splitted to multiple TRBs.
The xhci
Hello,
Thank you for patch. I can apply it a bit later in the trip currently.
On 7/30/2018 3:11 AM, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2018/07/27 09:14, Denis wrote:
>> Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
>> device reports:
>>
>> axen0: usb errors on rx:
Hi,
On 2018/07/27 09:14, Denis wrote:
Every time (after 2-3 minutes of work) ASIX Electronics USB-Ethernet
device reports:
axen0: usb errors on rx: IOERROR
axen0: usb errors on rx: IOERROR
axen0: usb errors on tx: IOERROR
axen0: watchdog timeout
axen0: usb errors on tx: IOERROR
The device
On July 28, 2018 1:21 AM, Tinker wrote:
> Hi Marcus,
>
> Thank you for following up.
>
> First re any XHCI bugs:
..
> Second, re superspeed mode:
>
> stsp@ pointed out about a year ago that the XHCI driver only supports,
> I think it is, 1gbps aggregate speed per USB hub presently, 5gbps aka
>
Hi Marcus,
Thank you for following up.
First re any XHCI bugs:
1.
The primary issue I have had is that when I evaluated XHCI around June
last year, when connected to a USB 3 (XHCI) port, on 20-30% of boots,
my USB NIC would not be automatically detected.
However, if after the boot completed I
t1...@protonmail.ch (Tinker), 2018.07.27 (Fri) 12:17 (CEST):
> (Also note that the USB 3 stack separately is unstable, and maybe
For the archives:
That statement is wrong, unless all the dozens of terabytes I've moved
over xhci(4) are broken now.
Do you mean the isochronous transfer thing? CVS
Denis,
That axen is broken is known from before. See
https://marc.info/?t=14960163472=1=2
https://marc.info/?t=14914106181=1=2
I requested Yojiro to fix the driver but afaik he has not done anything.
AFAIK the Axen hardware is stable so it's a driver problem indeed.
Overall I have a
33 matches
Mail list logo