"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Tue Dec 19 07:05:36 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> Add support for AX88179A. From sc.dying on current-users.
>
>
> To generate a diff of this commit:
> cvs rdiff -u
> Module Name:src
> Committed By: mlelstv
> Date: Mon Apr 10 15:26:57 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: uvideo.c uvideoreg.h
>
> Log Message:
> Better descriptor parsing.
How is it better? What problems does it fix?
> Add sanity check if no default format
Hi,
On 2022/05/14 19:44, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Sat May 14 19:44:37 UTC 2022
>
> Modified Files:
> src/sys/dev/usb: xhci.c
>
> Log Message:
> xhci(4): Handle race between software abort and hardware stall.
xhci_abortx is
On 15/07/2021 04:25, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Thu Jul 15 03:25:50 UTC 2021
Modified Files:
src/sys/dev/usb: if_mue.c uchcom.c
Log Message:
explanation typo
To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61
On Wed, 27 May 2020, Taylor R Campbell wrote:
Not really, because we just need to know whether usb_once_init has
been run.
OK, great!
Now, should we use something other than RUN_ONCE, which can both set
up and tear down? Sure, that might be better in principle, but there
probably aren't
> Date: Wed, 27 May 2020 05:28:41 -0700 (PDT)
> From: Paul Goyette
>
> Do you also need to decrement the number of busses when one is
> detached?
Not really, because we just need to know whether usb_once_init has
been run.
Now, should we use something other than RUN_ONCE, which can both set
up
Do you also need to decrement the number of busses when one is
detached?
On Wed, 27 May 2020, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed May 27 07:17:45 UTC 2020
Modified Files:
src/sys/dev/usb: usb.c
Log Message:
Don't allow open of /dev/usb if
On Thu, Apr 2, 2020 at 8:37 PM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Thu Apr 2 11:37:23 UTC 2020
>
> Modified Files:
> src/sys/dev/usb: xhci.c xhcivar.h
>
> Log Message:
> Reduce the memory footprint by allocating a ring per endpoint/pipe on
Le 23/03/2020 à 04:07, Roy Marples a écrit :
> On 22/03/2020 08:30, Maxime Villard wrote:
>> Overall "From OpenBSD" is a redflag for buggy and vulnerable code..
>
> We should be above this, no software is perfect, not even ours.
>
> Roy
You seem to be confusing one-off defects and structural
On 22/03/2020 08:30, Maxime Villard wrote:
Overall "From OpenBSD" is a redflag for buggy and vulnerable code..
We should be above this, no software is perfect, not even ours.
Roy
Le 19/03/2020 à 08:49, Pierre Pronchery a écrit :
> Module Name: src
> Committed By: khorben
> Date: Thu Mar 19 07:49:29 UTC 2020
>
> Modified Files:
> src/sys/dev/usb: if_umb.c
>
> Log Message:
> When there is no network around the state timeout fires over and over again.
>
On 18/03/2020 11:33, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Wed Mar 18 11:33:32 UTC 2020
>
> Modified Files:
> src/sys/dev/usb: if_aue.c
>
> Log Message:
> This was still not correct,. USB_DEBUG is what mattered, not AUE_DEBUG,
> the two are orthogonal.
Date:Tue, 17 Mar 2020 22:58:24 -0400
From:"Christos Zoulas"
Message-ID: <20200318025824.93b28f...@cvs.netbsd.org>
| Log Message:
| define un (pointed out by kre@)
The reason I didn't suggest that change, is that now un is unused
when USB_DEBUG is not defined.
In article <20200314143238.gr5...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>How is is affected by the decision to change (or not) 0x%x to %#x?
>
This was in response to the statement:
... with a bit of patience might have been less drastic and as effective.
christos
On Sat, Mar 14, 2020 at 10:27:27 -0400, Christos Zoulas wrote:
> > I don't belive that "if". It's like claiming you got rid of a stain
> > on a wallpaper after you demolish a wall (not load-bearing,
> > fortunately) and have to put it back and put new wallpaper. :) Get rid
> > of the stain,
> I don't belive that "if". It's like claiming you got rid of a stain
> on a wallpaper after you demolish a wall (not load-bearing,
> fortunately) and have to put it back and put new wallpaper. :) Get rid
> of the stain, sure; but may be looking closely with a bit of patience
> might have been
On Sat, Mar 14, 2020 at 09:57:36 -0400, Christos Zoulas wrote:
> > Even for the ones without the widths specified. E.g. I personally
> > prefer zero printed as 0x0, not as 0, so I assume that when people
> > choose either one that reflects their preference. Why mess with it?
> > It's all so
> Even for the ones without the widths specified. E.g. I personally
> prefer zero printed as 0x0, not as 0, so I assume that when people
> choose either one that reflects their preference. Why mess with it?
> It's all so unnecessary.
Yes, now we are discussing cosmetics (if 0 should be printed
> As I wrote in a follow up email, it changes formatting b/c you didn't
> change field widths and IMO using %# with a field width is mostly
> trouble to begin with. It's not the first time someone tries to do
> this without actually understanding the consequences of the change.
> Please, can we
On Fri, Mar 13, 2020 at 22:26:05 -0400, Christos Zoulas wrote:
> > On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote:
> >
> > As I wrote in a follow up email, it changes formatting b/c you didn't
> > change field widths and IMO using %# with a field width is mostly
> > trouble to begin with.
> On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote:
>
> As I wrote in a follow up email, it changes formatting b/c you didn't
> change field widths and IMO using %# with a field width is mostly
> trouble to begin with. It's not the first time someone tries to do
> this without actually
On Fri, Mar 13, 2020 at 22:15:31 -0400, Christos Zoulas wrote:
> > This was not a part of the PR and is completely cosmetic (surely it
> > supports plain %x if it does support %#x). Why was this necessary?
> > (I know I would be quite miffed if someone made a change like that to
> > my code).
>
> This was not a part of the PR and is completely cosmetic (surely it
> supports plain %x if it does support %#x). Why was this necessary?
> (I know I would be quite miffed if someone made a change like that to
> my code).
Yes, that %x formatting change was not part of the PR, but I only
On Fri, Mar 13, 2020 at 17:09:14 -0700, Paul Goyette wrote:
> On Sat, 14 Mar 2020, Valery Ushakov wrote:
>
> > On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote:
> >
> > > Log Message:
> > > PR/55068: sc.dying: Fix printf formats:
> > [...]
> > > - 0x% -> %#
> >
> > This was not a
On Sat, 14 Mar 2020, Valery Ushakov wrote:
On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote:
Log Message:
PR/55068: sc.dying: Fix printf formats:
[...]
- 0x% -> %#
This was not a part of the PR and is completely cosmetic (surely it
supports plain %x if it does support %#x).
On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote:
> Log Message:
> PR/55068: sc.dying: Fix printf formats:
[...]
> - 0x% -> %#
This was not a part of the PR and is completely cosmetic (surely it
supports plain %x if it does support %#x). Why was this necessary?
(I know I would be
On Tue, Dec 03, 2019 at 05:01:45AM +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Tue Dec 3 05:01:45 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: usbnet.c
>
> Log Message:
> Fix order of nulling un->un_pri->unp_ec.ec_mii.
>
> Can't null
On Thu, Oct 31, 2019 at 11:59:40AM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Thu Oct 31 11:59:40 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_urndis.c
>
> Log Message:
> check if buf/bufsz are non-NULL before freeing.
>
> not all control
> To generate a diff of this commit:
> cvs rdiff -u -r1.118 -r1.119 src/sys/dev/usb/if_axe.c
FYI: this change included a fix for two problems identified by sc.debug.
On 08/08/2019 23:32, sc dying wrote:
On Wed, Aug 7, 2019 at 7:06 AM Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Aug 7 07:05:54 UTC 2019
Modified Files:
src/sys/dev/usb: if_smsc.c
Removed Files:
src/sys/dev/usb: if_smscvar.h
Log
On Wed, Aug 7, 2019 at 7:06 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Aug 7 07:05:54 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_smsc.c
> Removed Files:
> src/sys/dev/usb: if_smscvar.h
>
> Log Message:
> Convert smsc(4) to
Can you add printfs in these two functions to dump 'bLength'?
I've reverted the change for now. I found these bugs a week ago while
manually crafting incorrect USB packets in Qemu's USB driver. It caused
memory corruptions in the NetBSD guest, which were detected by KASAN.
Fixing the length
On Fri, Jun 28, 2019 at 1:57 AM matthew green wrote:
>
> Module Name:src
> Committed By: mrg
> Date: Fri Jun 28 01:57:43 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_axen.c if_cdce.c if_ure.c
>
> Log Message:
> more smp cleanup for ure(4)/axen(4)/cdce(4):
Thank you
Mmh no I see, the min descriptor length check we should add is 3 bytes, and my
check should be moved below in the idesc branch. I'll re-fix that next week.
Le 06/07/2019 à 10:04, Maxime Villard a écrit :
Can you add printfs in these two functions to dump 'bLength'?
I've reverted the change
It could be a coincidence, but with yesterday's kernel my
non-malicious USB keyboard (Cherry G230) worked and today it doesn't.
-uhidev0 at uhub5 port 1 configuration 1 interface 0
-uhidev0: vendor 046a (0x46a) product 0023 (0x23), rev 2.00/2.20, addr 1,
iclass 3/1
-ukbd0 at uhidev0: 8 Variable
On Tue, Jun 25, 2019 at 4:03 PM Nick Hudson wrote:
>
> On 24/06/2019 10:40, Ryota Ozaki wrote:
> > On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
> >>
> >>> Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> >>> now. Remaining splnets are for network drivers.
On 24/06/2019 10:40, Ryota Ozaki wrote:
On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
now. Remaining splnets are for network drivers. (softnet_lock is also required
in some cases but it's another story...)
On Mon, Jun 24, 2019 at 9:39 AM Ryota Ozaki wrote:
>
> On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
> >
> > > Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> > > now. Remaining splnets are for network drivers. (softnet_lock is also
> > > required
> > > in
On Mon, Jun 24, 2019 at 6:27 PM matthew green wrote:
>
> > Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> > now. Remaining splnets are for network drivers. (softnet_lock is also
> > required
> > in some cases but it's another story...)
>
> great! i studied the code
> Only KERNEL_LOCK (and some splsoftnet) is required for the network stack
> now. Remaining splnets are for network drivers. (softnet_lock is also
> required
> in some cases but it's another story...)
great! i studied the code and i couldn't find any issues
in any of the relevant paths, so
On Mon, Jun 24, 2019 at 5:26 PM Manuel Bouyer wrote:
>
> On Mon, Jun 24, 2019 at 08:39:08AM +0100, Nick Hudson wrote:
> >
> >
> > On 24/06/2019 04:30, matthew green wrote:
> > > > > splnet is obsolete in modern USB network drivers.
> > > > > all the code runs at softipl.
> > > > >
> > > > >
On Mon, Jun 24, 2019 at 08:39:08AM +0100, Nick Hudson wrote:
>
>
> On 24/06/2019 04:30, matthew green wrote:
> > > > splnet is obsolete in modern USB network drivers.
> > > > all the code runs at softipl.
> > > >
> > > > removing spl was done entirely on purpose.
> > >
> > > I saw the comment
On 24/06/2019 04:30, matthew green wrote:
splnet is obsolete in modern USB network drivers.
all the code runs at softipl.
removing spl was done entirely on purpose.
I saw the comment of ether_ioctl in sys/net/if_ethersubr.c
Note, we must be called at splnet().
so I asked.
that comment
On Mon, Jun 24, 2019 at 01:30:09PM +1000, matthew green wrote:
> > > splnet is obsolete in modern USB network drivers.
> > > all the code runs at softipl.
> > >
> > > removing spl was done entirely on purpose.
> >
> > I saw the comment of ether_ioctl in sys/net/if_ethersubr.c
> > > Note, we must
> > splnet is obsolete in modern USB network drivers.
> > all the code runs at softipl.
> >
> > removing spl was done entirely on purpose.
>
> I saw the comment of ether_ioctl in sys/net/if_ethersubr.c
> > Note, we must be called at splnet().
> so I asked.
that comment is true for old style
On Sun, Jun 23, 2019 at 10:40 PM matthew green wrote:
>
> sc dying writes:
> > hi,
> >
> > On Sat, Jun 22, 2019 at 9:54 AM matthew green wrote:
> > >
> > > Module Name:src
> > > Committed By: mrg
> > > Date: Sat Jun 22 09:53:56 UTC 2019
> > >
> > > Modified Files:
> > >
sc dying writes:
> hi,
>
> On Sat, Jun 22, 2019 at 9:54 AM matthew green wrote:
> >
> > Module Name:src
> > Committed By: mrg
> > Date: Sat Jun 22 09:53:56 UTC 2019
> >
> > Modified Files:
> > src/sys/dev/usb: if_axen.c
> >
> > Log Message:
> > mark this driver MPSAFE for
hi,
On Sun, Jun 23, 2019 at 2:14 AM matthew green wrote:
>
> Module Name:src
> Committed By: mrg
> Date: Sun Jun 23 02:14:15 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_cdce.c if_ure.c if_urevar.h
>
> Log Message:
> make cdce(4) and ure(4) usb and mpsafe:
>
> -
hi,
On Sat, Jun 22, 2019 at 9:54 AM matthew green wrote:
>
> Module Name:src
> Committed By: mrg
> Date: Sat Jun 22 09:53:56 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> mark this driver MPSAFE for usb tasks and pipes, if(4), and callouts.
Rin Okuyama wrote:
>I tested StarTech USB21000S2 with Pine A64+. It works well
>with multiple outstanding transfers. If I understand correctly,
>Pine A64+ and Pinebook have (almost?) same SoC. If so, there
>should be the problem elsewhere than host controller itself.
>
>Robert, could you please
Hi,
I tested StarTech USB21000S2 with Pine A64+. It works well
with multiple outstanding transfers. If I understand correctly,
Pine A64+ and Pinebook have (almost?) same SoC. If so, there
should be the problem elsewhere than host controller itself.
Robert, could you please test it with powered
On 2019/02/17 13:17, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Feb 17 04:17:31 UTC 2019
Modified Files:
src/sys/dev/usb: usbdi.c
Log Message:
Fix system freeze when USB NICs with multiple outstanding transfers
are detached from xhci(4) or ehci(4),
On 2019/02/15 23:37, Nick Hudson wrote:
On 15/02/2019 13:44, Rin Okuyama wrote:
On 2019/02/15 21:57, Jonathan A. Kollasch wrote:
On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
Hi,
On 2019/02/13 3:54, Nick Hudson wrote:
On 12/02/2019 16:02, Rin Okuyama wrote:
Hi,
The system
On 15/02/2019 13:44, Rin Okuyama wrote:
On 2019/02/15 21:57, Jonathan A. Kollasch wrote:
On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
Hi,
On 2019/02/13 3:54, Nick Hudson wrote:
On 12/02/2019 16:02, Rin Okuyama wrote:
Hi,
The system freezes indefinitely with xhci(4) or
On Fri, Feb 15, 2019 at 10:44:23PM +0900, Rin Okuyama wrote:
> On 2019/02/15 21:57, Jonathan A. Kollasch wrote:
> > On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
> > > Hi,
> > >
> > > On 2019/02/13 3:54, Nick Hudson wrote:
> > > > On 12/02/2019 16:02, Rin Okuyama wrote:
> > > > >
On 2019/02/15 21:57, Jonathan A. Kollasch wrote:
On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
Hi,
On 2019/02/13 3:54, Nick Hudson wrote:
On 12/02/2019 16:02, Rin Okuyama wrote:
Hi,
The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
multiple outstanding
On Wed, Feb 13, 2019 at 06:35:14PM +0900, Rin Okuyama wrote:
> Hi,
>
> On 2019/02/13 3:54, Nick Hudson wrote:
> > On 12/02/2019 16:02, Rin Okuyama wrote:
> > > Hi,
> > >
> > > The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
> > > multiple outstanding transfers [axen(4),
On 2019/02/13 21:13, Christos Zoulas wrote:
In article ,
Rin Okuyama wrote:
Hi,
On 2019/02/13 6:07, Paul Goyette wrote:
On Tue, 12 Feb 2019, Rin Okuyama wrote:
Hi,
As Martin pointed out, it is useful for debugging to turn on
DIAGNOSTIC for modules (for non-release branches).
Now, all
In article ,
Rin Okuyama wrote:
>Hi,
>
>On 2019/02/13 6:07, Paul Goyette wrote:
>> On Tue, 12 Feb 2019, Rin Okuyama wrote:
>>
>>> Hi,
>>>
>>> As Martin pointed out, it is useful for debugging to turn on
>>> DIAGNOSTIC for modules (for non-release branches).
>>>
>>> Now, all modules for amd64
On 2019/02/13 19:06, Paul Goyette wrote:
I would also wonder if we could increase the WARNS?= level from 3 to 5 (to
match the current WARNS?= level used for kernel builds). Has anyone tried to
see how many modules would fail with WARNS?=5 ??
Thank you for your comment.
Well, I examined
I would also wonder if we could increase the WARNS?= level from 3 to 5 (to
match the current WARNS?= level used for kernel builds). Has anyone tried
to see how many modules would fail with WARNS?=5 ??
Thank you for your comment.
Well, I examined that (both for GCC7 & clang). Among ~ 360
Hi,
On 2019/02/13 6:07, Paul Goyette wrote:
On Tue, 12 Feb 2019, Rin Okuyama wrote:
Hi,
As Martin pointed out, it is useful for debugging to turn on
DIAGNOSTIC for modules (for non-release branches).
Now, all modules for amd64 are successfully built with DIAGNOSTIC.
I'd like to commit the
Hi,
On 2019/02/13 3:54, Nick Hudson wrote:
On 12/02/2019 16:02, Rin Okuyama wrote:
Hi,
The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped
by "ifconfig down" or detached.
As discussed in the previous
On Tue, 12 Feb 2019, Rin Okuyama wrote:
Hi,
As Martin pointed out, it is useful for debugging to turn on
DIAGNOSTIC for modules (for non-release branches).
Now, all modules for amd64 are successfully built with DIAGNOSTIC.
I'd like to commit the patch below, if there's no objection.
This
On 12/02/2019 16:02, Rin Okuyama wrote:
Hi,
The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped
by "ifconfig down" or detached.
As discussed in the previous message, this is due to infinite loop in
Hi,
The system freezes indefinitely with xhci(4) or ehci(4), when NIC with
multiple outstanding transfers [axen(4), mue(4), and ure(4)] is stopped
by "ifconfig down" or detached.
As discussed in the previous message, this is due to infinite loop in
usbd_ar_pipe(); xfers with USBD_NOT_STARTED
Hi,
As Martin pointed out, it is useful for debugging to turn on
DIAGNOSTIC for modules (for non-release branches).
Now, all modules for amd64 are successfully built with DIAGNOSTIC.
I'd like to commit the patch below, if there's no objection.
Thanks,
rin
Index: sys/modules/Makefile.inc
On Sat, Feb 09, 2019 at 11:53:57AM +0100, Michael van Elst wrote:
> And that's why I see it for modules:
>
> Index: sys/modules/Makefile.inc
> ===
> RCS file: /cvsroot/src/sys/modules/Makefile.inc,v
> retrieving revision 1.6
> diff
On Sat, Feb 9, 2019 at 8:18 AM Rin Okuyama wrote:
>
> Hi,
>
> On 2019/02/08 23:16, sc dying wrote:
> > On 2019/01/31 05:51, Rin Okuyama wrote:
> >> By the way, I find that the system hangs silently by
> >> "ifconfig mueN down" or detaching LAN7500 from USB port when
> >> multiple outstanding
On Sat, Feb 09, 2019 at 05:18:13PM +0900, Rin Okuyama wrote:
> Hi,
>
> On 2019/02/08 23:16, sc dying wrote:
> > xhci_device_bulk_abort() at netbsd:xhci_device_bulk_abort+0x1c
> > usbd_ar_pipe() at netbsd:usbd_ar_pipe+0x1e9
> > usbd_abort_pipe() at netbsd:usbd_abort_pipe+0x27
> > axen_stop() at
On Sat, Feb 09, 2019 at 05:15:51PM +0900, Rin Okuyama wrote:
> On 2019/02/08 7:51, Michael van Elst wrote:
> > On Fri, Feb 08, 2019 at 07:12:28AM +0900, Rin Okuyama wrote:
> > > Hi,
> > >
> > > What compiler options (or version, architecture, etc.) do you use?
> > > I want to enable that
Hi,
On 2019/02/08 23:16, sc dying wrote:
On 2019/01/31 05:51, Rin Okuyama wrote:
By the way, I find that the system hangs silently by
"ifconfig mueN down" or detaching LAN7500 from USB port when
multiple outstanding requests are enabled. This does not occur
when MUE_TX_LIST_CNT =
On 2019/02/08 7:51, Michael van Elst wrote:
On Fri, Feb 08, 2019 at 07:12:28AM +0900, Rin Okuyama wrote:
Hi,
What compiler options (or version, architecture, etc.) do you use?
I want to enable that warnings, but I cannot even with WARNS=5.
The warnings came for assertions, so you need to
On 2019/01/31 05:51, Rin Okuyama wrote:
> By the way, I find that the system hangs silently by
> "ifconfig mueN down" or detaching LAN7500 from USB port when
> multiple outstanding requests are enabled. This does not occur
> when MUE_TX_LIST_CNT = MUE_RX_LIST_CNT = 1. Do you have any ideas
> to
On Fri, Feb 08, 2019 at 07:12:28AM +0900, Rin Okuyama wrote:
> Hi,
>
> What compiler options (or version, architecture, etc.) do you use?
> I want to enable that warnings, but I cannot even with WARNS=5.
The warnings came for assertions, so you need to build with DIAGNOSTIC,
which is default for
On Fri, Feb 08, 2019 at 07:12:28AM +0900, Rin Okuyama wrote:
> Hi,
>
> What compiler options (or version, architecture, etc.) do you use?
That was just default settings for amd64 (and same for evbarm).
> I want to enable that warnings, but I cannot even with WARNS=5.
I suspect most warnings
Hi,
What compiler options (or version, architecture, etc.) do you use?
I want to enable that warnings, but I cannot even with WARNS=5.
Thanks,
rin
On 2019/02/07 19:36, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Thu Feb 7 10:36:20 UTC 2019
Modified
On Wed, Feb 06, 2019 at 09:15:02AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Wed Feb 6 09:15:01 UTC 2019
>
> Modified Files:
> src/sys/dev/usb: if_mue.c
>
> Log Message:
> Fix sign compare.
>
>
> To generate a diff of this commit:
> cvs rdiff -u
Sorry for my long silence.
On 2019/01/31 23:20, Robert Swindells wrote:
...
The revision number of my device is "1".
Robert Swindells
Hmm, both of my adapters have same revision of "1":
* StarTech USB21000S2
mue1 at uhub3 port 2
mue1: WS (0x424) USB Gigabit LAN (0x7500), rev 2.00/1.00,
On 2019-01-31 06:54, Rin Okuyama wrote:
On 2019/01/30 22:21, Robert Swindells wrote:
On 2019-01-30 11:05, Rin Okuyama wrote:
I tested a StarTech USB21000S2 adapter. It works both on RPI3B and
amd64 box with ehci(4) (ThinkPad X60). Revision is same as Z-TEK
ZE582; both have product ID of 0x7500
On Thu, Jan 31, 2019 at 02:51:44PM +0900, Rin Okuyama wrote:
> On 2019/01/30 21:26, Michael van Elst wrote:
> > Do multiple outstanding requests show an advantage on your LAN7500
> > devices?
>
> Yes. There is significant improvement in receiving performance.
Then lets see if the chip revision
On 2019/01/30 22:21, Robert Swindells wrote:
On 2019-01-30 11:05, Rin Okuyama wrote:
I tested a StarTech USB21000S2 adapter. It works both on RPI3B and
amd64 box with ehci(4) (ThinkPad X60). Revision is same as Z-TEK
ZE582; both have product ID of 0x7500 (LAN7500).
We don't currently read the
On 2019/01/30 21:26, Michael van Elst wrote:
On Wed, Jan 30, 2019 at 08:05:56PM +0900, Rin Okuyama wrote:
I tested a StarTech USB21000S2 adapter. It works both on RPI3B and
amd64 box with ehci(4) (ThinkPad X60). Revision is same as Z-TEK
ZE582; both have product ID of 0x7500 (LAN7500).
There
On 2019-01-30 11:05, Rin Okuyama wrote:
I tested a StarTech USB21000S2 adapter. It works both on RPI3B and
amd64 box with ehci(4) (ThinkPad X60). Revision is same as Z-TEK
ZE582; both have product ID of 0x7500 (LAN7500).
We don't currently read the revision number, low 16 bits of the register
On Wed, Jan 30, 2019 at 08:05:56PM +0900, Rin Okuyama wrote:
>
> I tested a StarTech USB21000S2 adapter. It works both on RPI3B and
> amd64 box with ehci(4) (ThinkPad X60). Revision is same as Z-TEK
> ZE582; both have product ID of 0x7500 (LAN7500).
>
> There may be problem with the host
On 2019/01/29 7:46, Rin Okuyama wrote:
On 2019/01/28 19:52, Michael van Elst wrote:
On Mon, Jan 28, 2019 at 06:31:01PM +0900, Rin Okuyama wrote:
Hi,
On 2019/01/25 4:18, Michael van Elst wrote:
On Thu, Jan 24, 2019 at 03:51:02PM +0100, Robert Swindells wrote:
It doesn't work at all for me on
On 2019/01/28 19:52, Michael van Elst wrote:
On Mon, Jan 28, 2019 at 06:31:01PM +0900, Rin Okuyama wrote:
Hi,
On 2019/01/25 4:18, Michael van Elst wrote:
On Thu, Jan 24, 2019 at 03:51:02PM +0100, Robert Swindells wrote:
It doesn't work at all for me on a LAN7500.
Tested on an RPI3b+ which
On Mon, Jan 28, 2019 at 06:31:01PM +0900, Rin Okuyama wrote:
> Hi,
>
> On 2019/01/25 4:18, Michael van Elst wrote:
> > On Thu, Jan 24, 2019 at 03:51:02PM +0100, Robert Swindells wrote:
> > > It doesn't work at all for me on a LAN7500.
> > Tested on an RPI3b+ which is LAN7800.
> It works for me
Hi,
On 2019/01/25 4:18, Michael van Elst wrote:
On Thu, Jan 24, 2019 at 03:51:02PM +0100, Robert Swindells wrote:
"Michael van Elst" wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Jan 5 07:56:07 UTC 2019
Modified Files:
src/sys/dev/usb: if_mue.c if_muevar.h
On Thu, Jan 24, 2019 at 03:51:02PM +0100, Robert Swindells wrote:
> "Michael van Elst" wrote:
> > Module Name:src
> > Committed By: mlelstv
> > Date: Sat Jan 5 07:56:07 UTC 2019
> >
> > Modified Files:
> >src/sys/dev/usb: if_mue.c if_muevar.h
> >
> > Log Message:
> >
"Michael van Elst" wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Jan 5 07:56:07 UTC 2019
Modified Files:
src/sys/dev/usb: if_mue.c if_muevar.h
Log Message:
Enable multiple outstanding transfers.
iperf3 now shows 250MBit/s for sending and 225MBit/s for
On 2019/01/08 17:33, Nick Hudson wrote:
On 07/01/2019 10:22, Rin Okuyama wrote:
[snip]
This kind of problems cannot be handled in software unless we
(1) use cached memory (for which unaligned access is allowed), or
(2) forbid compiler to generate unaligned access.
This patch
On 07/01/2019 10:22, Rin Okuyama wrote:
[snip]
This kind of problems cannot be handled in software unless we
(1) use cached memory (for which unaligned access is allowed), or
(2) forbid compiler to generate unaligned access.
This patch
On 2019/01/07 10:59, matthew green wrote:
http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
i fixed the hdafg.c ones here. not sure about the hdaudio.c
ones, since they are already 1u << 31. leaving:
x86/pci/pci_machdep.c
ahcisata_core.c
amd64/kobj_machdep.c
netinet/tcp_input.c
> http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
i fixed the hdafg.c ones here. not sure about the hdaudio.c
ones, since they are already 1u << 31. leaving:
x86/pci/pci_machdep.c
ahcisata_core.c
amd64/kobj_machdep.c
netinet/tcp_input.c
beyond the xhci one, that actually doesn't
On Jan 6, 9:53am, nick.hud...@gmx.co.uk (Nick Hudson) wrote:
-- Subject: Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys
| I'm pretty sure this is the same as http://gnats.netbsd.org/50038
Yes, this looks like the same issue; we should not be patching individual
drivers like
On Jan 6, 3:59pm, nick.hud...@gmx.co.uk (Nick Hudson) wrote:
-- Subject: Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys
| > Isn't that orthogonal?
|
| Nope, because normal cached memory allows unaligned access (kernel and
| userland).
|
I did not realize that the i_axe
On 06/01/2019 15:31, Christos Zoulas wrote:
On Jan 6, 9:53am, nick.hud...@gmx.co.uk (Nick Hudson) wrote:
-- Subject: Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys
| I'm pretty sure this is the same as http://gnats.netbsd.org/50038
Yes, this looks like the same issue; we
On Jan 6, 5:46pm, rokuy...@rk.phys.keio.ac.jp (Rin Okuyama) wrote:
-- Subject: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev
| I guess other codes can be miscompiled if -mno-unaligned-access is
| not specified. Can I commit the patch?
I believe this is the right way to do
kUBSan detected a number of unaligned accesses in USB code:
http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
On 06.01.2019 09:46, Rin Okuyama wrote:
> (CC added to port-...@netbsd.org)
>
> Let me summarize the problem briefly. In axe(4), there is a code where
> memcpy() is carried
1 - 100 of 179 matches
Mail list logo
