Re: CVS commit: src/sys/dev/usb

2020-05-27 Thread Paul Goyette
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

Re: CVS commit: src/sys/dev/usb

2020-05-27 Thread Taylor R Campbell
> 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

Re: CVS commit: src/sys/dev/usb

2020-05-27 Thread Paul Goyette
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

Re: CVS commit: src/sys/dev/usb

2020-04-02 Thread sc dying
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

Re: CVS commit: src/sys/dev/usb

2020-03-23 Thread Maxime Villard
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

Re: CVS commit: src/sys/dev/usb

2020-03-22 Thread Roy Marples
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

Re: CVS commit: src/sys/dev/usb

2020-03-22 Thread Maxime Villard
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. >

Re: CVS commit: src/sys/dev/usb

2020-03-18 Thread Nick Hudson
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.

Re: CVS commit: src/sys/dev/usb

2020-03-17 Thread Robert Elz
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.

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
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

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Valery Ushakov
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,

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
> 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

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Valery Ushakov
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

Re: CVS commit: src/sys/dev/usb

2020-03-14 Thread Christos Zoulas
> 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

re: CVS commit: src/sys/dev/usb

2020-03-14 Thread matthew green
> 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

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
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.

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Christos Zoulas
> 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

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
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). >

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Christos Zoulas
> 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

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
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

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Paul Goyette
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).

Re: CVS commit: src/sys/dev/usb

2020-03-13 Thread Valery Ushakov
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

Re: CVS commit: src/sys/dev/usb

2019-12-14 Thread maya
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

Re: CVS commit: src/sys/dev/usb

2019-10-31 Thread maya
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

re: CVS commit: src/sys/dev/usb

2019-08-22 Thread matthew green
> 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.

Re: CVS commit: src/sys/dev/usb

2019-08-09 Thread Nick Hudson
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

Re: CVS commit: src/sys/dev/usb

2019-08-08 Thread sc dying
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

Re: CVS commit: src/sys/dev/usb

2019-07-06 Thread Maxime Villard
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

Re: CVS commit: src/sys/dev/usb

2019-07-06 Thread sc dying
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

Re: CVS commit: src/sys/dev/usb

2019-07-06 Thread Maxime Villard
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

Re: CVS commit: src/sys/dev/usb

2019-07-06 Thread Thomas Klausner
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

Re: CVS commit: src/sys/dev/usb

2019-06-25 Thread Ryota Ozaki
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.

Re: CVS commit: src/sys/dev/usb

2019-06-25 Thread Nick Hudson
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...)

Re: CVS commit: src/sys/dev/usb

2019-06-24 Thread sc dying
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

Re: CVS commit: src/sys/dev/usb

2019-06-24 Thread Ryota Ozaki
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

re: CVS commit: src/sys/dev/usb

2019-06-24 Thread matthew green
> 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

Re: CVS commit: src/sys/dev/usb

2019-06-24 Thread Ryota Ozaki
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. > > > > > > > > > >

Re: CVS commit: src/sys/dev/usb

2019-06-24 Thread Manuel Bouyer
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

Re: CVS commit: src/sys/dev/usb

2019-06-24 Thread Nick Hudson
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

Re: CVS commit: src/sys/dev/usb

2019-06-24 Thread Manuel Bouyer
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

re: CVS commit: src/sys/dev/usb

2019-06-23 Thread matthew green
> > 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

Re: CVS commit: src/sys/dev/usb

2019-06-23 Thread sc dying
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: > > >

re: CVS commit: src/sys/dev/usb

2019-06-23 Thread matthew green
> Should not ure_init_locked check ure_stopping? > If ure_stopping == true, no one clear it. > (But, it works anyway because ure_stop_locked does not set ure_stopping.) good points. thanks! i'll commit a fix after testing. .mrg.

re: CVS commit: src/sys/dev/usb

2019-06-23 Thread matthew green
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

Re: CVS commit: src/sys/dev/usb

2019-06-23 Thread sc dying
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: > > -

Re: CVS commit: src/sys/dev/usb

2019-06-23 Thread sc dying
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.

Re: CVS commit: src/sys/dev/usb

2019-02-26 Thread Robert Swindells
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

Re: CVS commit: src/sys/dev/usb

2019-02-26 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-02-16 Thread Rin Okuyama
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),

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-15 Thread Rin Okuyama
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

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-15 Thread Nick Hudson
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

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-15 Thread Jonathan A. Kollasch
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: > > > > >

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-15 Thread Rin Okuyama
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

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-15 Thread Jonathan A. Kollasch
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),

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-13 Thread Rin Okuyama
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

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-13 Thread Christos Zoulas
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

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-13 Thread Rin Okuyama
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

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-13 Thread Paul Goyette
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

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-13 Thread Rin Okuyama
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

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-13 Thread Rin Okuyama
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

Re: DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-12 Thread Paul Goyette
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

Re: Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-12 Thread Nick Hudson
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

Multiple outstanding transfer vs xhci / ehci (Re: CVS commit: src/sys/dev/usb)

2019-02-12 Thread Rin Okuyama
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

DIAGNOSTIC for modules (Re: CVS commit: src/sys/dev/usb)

2019-02-12 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-02-09 Thread Martin Husemann
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

Re: CVS commit: src/sys/dev/usb

2019-02-09 Thread sc dying
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

Re: CVS commit: src/sys/dev/usb

2019-02-09 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-02-09 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-02-09 Thread Rin Okuyama
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 =

Re: CVS commit: src/sys/dev/usb

2019-02-09 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-02-08 Thread sc dying
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

Re: CVS commit: src/sys/dev/usb

2019-02-07 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-02-07 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-02-07 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-02-06 Thread Joerg Sonnenberger
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

Re: CVS commit: src/sys/dev/usb

2019-02-06 Thread Rin Okuyama
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,

Re: CVS commit: src/sys/dev/usb

2019-01-31 Thread Robert Swindells
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

Re: CVS commit: src/sys/dev/usb

2019-01-31 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-01-30 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-01-30 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-01-30 Thread Robert Swindells
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

Re: CVS commit: src/sys/dev/usb

2019-01-30 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-01-30 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-01-28 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-01-28 Thread Michael van Elst
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

Re: CVS commit: src/sys/dev/usb

2019-01-28 Thread Rin Okuyama
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

Re: CVS commit: src/sys/dev/usb

2019-01-24 Thread Michael van Elst
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: > >

Re: CVS commit: src/sys/dev/usb

2019-01-24 Thread Robert Swindells
"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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-08 Thread Rin Okuyama
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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-08 Thread Nick Hudson
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    

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-07 Thread Rin Okuyama
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

re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread matthew green
> 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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Christos Zoulas
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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Christos Zoulas
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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Nick Hudson
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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Christos Zoulas
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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Kamil Rytarowski
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

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Martin Husemann
On Sun, Jan 06, 2019 at 05:52:55AM -0800, Jason Thorpe wrote: > That's probably a good idea in any case, because there will almost > certainly be a performance benefit, but I still think ensuring that > drivers don't perform unaligned accesses is desirable. It is a bit tricky. We do this only

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Jason Thorpe
> On Jan 6, 2019, at 5:36 AM, Martin Husemann wrote: > > On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote: >> Why do we generate code with unaligned access in user space? That seems >> surprising, if the processor isn't happy about it. > > The processor is happy with it, both in

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

2019-01-06 Thread Martin Husemann
On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote: > Why do we generate code with unaligned access in user space? That seems > surprising, if the processor isn't happy about it. The processor is happy with it, both in user- and kernel space. Only special memory regions mapped uncached

  1   2   >