On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
> Modified Files:
> src/sys/netinet: sctp_asconf.h
>
> Log Message:
> Appease GCC7 in sctp_asconf.h
>
> Do not declare types inside function parameter list.
> Add decklarations of types before these function
Thanks!
christos
> On Feb 20, 2019, at 8:38 AM, Rin Okuyama wrote:
>
>> On 2019/02/20 21:45, Christos Zoulas wrote:
>> In article <20190220051132.53c81f...@cvs.netbsd.org>,
>> Rin Okuyama wrote:
> ...
>>> Log Message:
>>> WARNS=3 for compat_netbsd32_* in order to appease sign-compare warnings
On 2019/02/20 21:45, Christos Zoulas wrote:
In article <20190220051132.53c81f...@cvs.netbsd.org>,
Rin Okuyama wrote:
...
Log Message:
WARNS=3 for compat_netbsd32_* in order to appease sign-compare warnings
for mips64, where NETBSD32_POINTER_TYPE is signed.
Let's limit it to mips64 then?
In article <20190220051132.53c81f...@cvs.netbsd.org>,
Rin Okuyama wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rin
>Date: Wed Feb 20 05:11:32 UTC 2019
>
>Modified Files:
> src/sys/modules/compat_netbsd32_09: Makefile
> src/sys/modules/compat_netbsd32_12: Makefile
In article <27327.1550539...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Feb 19 00:30:16 UTC 2019
>>
>> Modified Files:
>> src/sys/external/bsd/drm2/dist/drm/i915: intel_ddi.c
In article <21181.1550538...@splode.eterna.com.au>,
matthew green wrote:
>Christos Zoulas writes:
>> In article <20190219003451.093b2f...@cvs.netbsd.org>,
>> matthew green wrote:
>> >-=-=-=-=-=-
>>
>> >+ memcpy(intrnames, inames, MAX_INAME_LENGTH);
>>
>> That should be:
>>
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Tue Feb 19 00:30:16 UTC 2019
>
> Modified Files:
> src/sys/external/bsd/drm2/dist/drm/i915: intel_ddi.c intel_display.c
> intel_sdvo.c
> src/sys/external/bsd/drm2/dist/drm/nouveau:
Christos Zoulas writes:
> In article <20190219003451.093b2f...@cvs.netbsd.org>,
> matthew green wrote:
> >-=-=-=-=-=-
>
> >+memcpy(intrnames, inames, MAX_INAME_LENGTH);
>
> That should be:
> memcpy(intrnames, inames, sizeof(intrnames));
well.
maybe. but it's not really any better.
In article <20190219003451.093b2f...@cvs.netbsd.org>,
matthew green wrote:
>-=-=-=-=-=-
>+ memcpy(intrnames, inames, MAX_INAME_LENGTH);
That should be:
memcpy(intrnames, inames, sizeof(intrnames));
christos
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon Feb 18 23:13:14 UTC 2019
>
> Modified Files:
> src/sys/net: zlib.c
>
> Log Message:
> add fallthrough's
i specific avoided changing upstream code where possible by adding
the relevant cflags.
where
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 Fri, Feb 15, 2019 at 11:21:51PM +, Mindaugas Rasiukevicius wrote:
> Well, I did run libnv tests as well as NPF tests and they both passed,
> just not on NetBSD. :) Turns out NetBSD libnv and Github libnv code
> bases deviated a little bit, causing a bug in NetBSD (but not upstream).
>
Martin Husemann wrote:
> Can you try this patch?
>
> rmind: can you *please* run the tests before commiting such changes?
> That would have immediately caught this.
Well, I did run libnv tests as well as NPF tests and they both passed,
just not on NetBSD. :) Turns out NetBSD libnv and Github
Rin Okuyama wrote:
>Ping? Can I insert "break" here?
Sorry, yes you are correct that it should be a break.
Will commit it now.
Robert Swindells
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 2019/02/15 23:04, Robert Swindells wrote:
Rin Okuyama wrote:
Ping? Can I insert "break" here?
Sorry, yes you are correct that it should be a break.
Will commit it now.
Robert Swindells
Thanks!
rin
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:
> > > > >
Ping? Can I insert "break" here?
Thanks,
rin
On 2019/02/12 23:59, Rin Okuyama wrote:
Hi,
On 2019/02/12 23:40, Robert Swindells wrote:
Module Name: src
Committed By: rjs
Date: Tue Feb 12 14:40:38 UTC 2019
Modified Files:
src/sys/netinet: sctp_input.c sctp_usrreq.c
Log
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),
> Can you try this patch?
With the patch I get a different panic:
| # npfctl reload
| panic: kernel diagnostic assertion "(nvp) != ((void *)0)" failed: file
"/home/fstd/qemutest/src/sys/external/bsd/libnv/dist/nvpair.c", line 2140
| cpu0: Begin traceback...
|
Can you try this patch?
rmind: can you *please* run the tests before commiting such changes?
That would have immediately caught this.
Martin
Index: nvlist.c
===
RCS file: /cvsroot/src/sys/external/bsd/libnv/dist/nvlist.c,v
This commit (or the following one) gives me the following
panic on 'npfctl reload':
| # npfctl reload
| [ 169.6257771] panic: kmem_free(0xc1fd76a0, 46) != allocated size 4294967295
| [ 169.6361202] cpu0: Begin traceback...
| [ 169.6361202]
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
Le 13/02/2019 à 10:08, Cherry G.Mathew a écrit :
(resent to source-changes-d@)
"Maxime Villard" writes:
- There is no recursive slot possible, so we can't use pmap_map_ptes().
Rather, we walk down the EPT trees via the direct map, and that's
actually a lot simpler (and probably
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
(resent to source-changes-d@)
"Maxime Villard" writes:
[...]
>
> Contrary to AMD-SVM, Intel-VMX uses a different set of PTE bits from
> native, and this has three important consequences:
>
> - We can't use the native PTE bits, so each time we want to modify the
>page tables, we need to
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,
On 2019/02/12 23:40, Robert Swindells wrote:
Module Name:src
Committed By: rjs
Date: Tue Feb 12 14:40:38 UTC 2019
Modified Files:
src/sys/netinet: sctp_input.c sctp_usrreq.c
Log Message:
Add some fallthrough annotations.
...
Index: src/sys/netinet/sctp_usrreq.c
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/02/09 16:48, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Feb 9 07:48:39 UTC 2019
Modified Files:
src/sys/dev/mii: rlphy.c
Log Message:
Support RTL8152. Tested on ure(4) (RTL8152).
---> Support RTL8201E. Tested on ure(4) (RTL8152).
Sorry
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 2019/02/07 13:03, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Thu Feb 7 04:03:25 UTC 2019
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Fix a bug that WOL didn't work on some chips since if_wm.c rev. 1.60.
s/1.60/1.610/
Set
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,
In article ,
Paul Goyette wrote:
>> Module Name:src
>> Committed By: mrg
>> Date: Tue Feb 5 09:28:00 UTC 2019
>>
>> Modified Files:
>> src/sys/dev/raidframe: rf_netbsdkintf.c
>>
>> Log Message:
>> fix the previous:
>>
>> rf_netbsd32 is only relevant on _LP64 as all the
Joerg Sonnenberger writes:
> On Mon, Feb 04, 2019 at 09:54:47AM +, matthew green wrote:
> > Module Name:src
> > Committed By: mrg
> > Date: Mon Feb 4 09:54:47 UTC 2019
> >
> > Modified Files:
> > src/sys/kern: kern_veriexec.c
> > src/sys/lib/libunwind:
On Mon, Feb 04, 2019 at 09:54:47AM +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Mon Feb 4 09:54:47 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_veriexec.c
> src/sys/lib/libunwind: libunwind.cxx
>
> Log Message:
> use
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
"Paul Goyette" writes:
> Module Name: src
> Committed By: pgoyette
> Date: Wed Jan 30 02:00:02 UTC 2019
>
> Modified Files:
> src/sys/compat/netbsd32: netbsd32_compat_80.c
>
> Log Message:
> Remove #ifdef COMPAT_80
>
> The file will only be selected if "options COMPAT_80" is
On Tue, Jan 29, 2019 at 04:16:30PM +0900, Masanobu SAITOH wrote:
> On 2019/01/29 2:51, Christoph Badura wrote:
> >Wouldn't it be better to prevent this kind of bug in the future by putting
> >the decision which method to use into a switch-statement and have the
> >compiler worry about ordering?
On 2019/01/28 15:33, Jason Thorpe wrote:
On Jan 28, 2019, at 8:11 AM, Masanobu SAITOH wrote:
On 2019/01/28 15:07, Jason Thorpe wrote:
Doesn’t it seem a little dangerous to just blindly enable?
You mean it should be enable only when the secondary bridge is configured
correctly?
Both
On 2019/01/29 2:51, Christoph Badura wrote:
On Fri, Jan 25, 2019 at 08:04:07AM +, SAITOH Masanobu wrote:
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
80003's SERDES is not the same as 82575's but the same as legacy devices.
Use the old methods on 80003.
XXX The reason
On Mon, 28 Jan 2019, bch wrote:
I take it back. Your email seemed to beat the repo commit, but my latest
update built a working kernel. Thx.
Oh, thank goodness! I was just about to ask you to run the failing
command under ktrace...
I'm so very glad it is (or appears to be) fixed.
-bch
I take it back. Your email seemed to beat the repo commit, but my latest
update built a working kernel. Thx.
-bch
On Mon, Jan 28, 2019 at 8:57 PM bch wrote:
> This still doesn’t seem to be working... up-to-the-minute src here.
>
> -bch
>
> On Mon, Jan 28, 2019 at 8:01 PM Paul Goyette wrote:
>
This still doesn’t seem to be working... up-to-the-minute src here.
-bch
On Mon, Jan 28, 2019 at 8:01 PM Paul Goyette wrote:
> Module Name:src
> Committed By: pgoyette
> Date: Tue Jan 29 04:01:45 UTC 2019
>
> Modified Files:
> src/sys/compat/common: if_43.c
>
> Log
On Tue, 29 Jan 2019, matthew green wrote:
Naming: Should the names of the hooks be:
___hook_t
or:
___hook_t
the latter. matches our naming style for eg syscalls.
I also prefer this. I thought I'd cleaned up most of the "wrong"
ones, but I guess I missed some. :(
> Naming: Should the names of the hooks be:
> ___hook_t
> or:
> ___hook_t
the latter. matches our naming style for eg syscalls.
.mrg.
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 Fri, Jan 25, 2019 at 08:04:07AM +, SAITOH Masanobu wrote:
> Modified Files:
> src/sys/dev/pci: if_wm.c
>
> Log Message:
> 80003's SERDES is not the same as 82575's but the same as legacy devices.
> Use the old methods on 80003.
>
> XXX The reason why this bug existed is that our
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
Hi!
Great, that did it - no more immediately visible device deficiencies.
com* work
wm1 works
radeon still spits errors
[10.941427] kern error:
[drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:345)uvd_v1_0_start]
*ERROR* UVD not responding, trying to
> On Jan 28, 2019, at 8:11 AM, Masanobu SAITOH wrote:
>
> On 2019/01/28 15:07, Jason Thorpe wrote:
>> Doesn’t it seem a little dangerous to just blindly enable?
>
> You mean it should be enable only when the secondary bridge is configured
> correctly?
>
> Both FreeBSD and OpenBSD blindly
Le 28/01/2019 à 03:36, David Holland a écrit :
On Sun, Jan 27, 2019 at 07:10:24PM +0100, Maxime Villard wrote:
> > Restore satlink's majors entries commented out and marked obsolete.
> > Otherwise they might accidentally get reused later and cause a
> > security problem.
>
> This is
On 2019/01/28 15:07, Jason Thorpe wrote:
Doesn’t it seem a little dangerous to just blindly enable?
You mean it should be enable only when the secondary bridge is configured
correctly?
Both FreeBSD and OpenBSD blindly enabled it. One of the difference between
NetBSD and others is that they
Doesn’t it seem a little dangerous to just blindly enable?
-- thorpej
Sent from my iPhone.
> On Jan 28, 2019, at 6:09 AM, SAITOH Masanobu wrote:
>
> Module Name:src
> Committed By:msaitoh
> Date:Mon Jan 28 04:09:51 UTC 2019
>
> Modified Files:
>src/sys/dev/pci: ppb.c
>
>
Hi.
On 2019/01/28 4:05, Frank Kardel wrote:
Hi,
that made all devices being recognized during boot with UEFI - good.
We seem closer, but not there yet (for my main board at least).
There is still an issue with interrupts (or dma - see missing bus master in pci
differences).
It seems
On Sun, Jan 27, 2019 at 07:10:24PM +0100, Maxime Villard wrote:
> > Restore satlink's majors entries commented out and marked obsolete.
> > Otherwise they might accidentally get reused later and cause a
> > security problem.
>
> This is completely useless, please revert. You are re-adding
Le 27/01/2019 à 18:59, David A. Holland a écrit :
Module Name:src
Committed By: dholland
Date: Sun Jan 27 17:59:23 UTC 2019
Modified Files:
src/sys/arch/algor/conf: majors.algor
src/sys/arch/alpha/conf: majors.alpha
src/sys/arch/amd64/conf: majors.amd64
Hi,
that made all devices being recognized during boot with UEFI - good.
We seem closer, but not there yet (for my main board at least).
There is still an issue with interrupts (or dma - see missing bus master
in pci differences).
It seems device interrupts via ioapic don't get
In article ,
Masanobu SAITOH wrote:
>
> I didn't know it! I've changed with it now.
>
> Thanks.
Thank you!
christos
On 2019/01/25 3:08, Christos Zoulas wrote:
In article <20190124045004.c9f48f...@cvs.netbsd.org>,
SAITOH Masanobu wrote:
-=-=-=-=-=-
Module Name:src
Committed By: msaitoh
Date: Thu Jan 24 04:50:04 UTC 2019
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
No
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:
> >
In article <20190124045004.c9f48f...@cvs.netbsd.org>,
SAITOH Masanobu wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: msaitoh
>Date: Thu Jan 24 04:50:04 UTC 2019
>
>Modified Files:
> src/sys/dev/pci: if_wm.c
>
>Log Message:
>No functional change intended:
>- Use "do {}
"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
> Module Name: src
> Committed By: alnsn
> Date: Tue Jan 22 01:25:53 UTC 2019
>
> Modified Files:
> src/sys/rump/kern/lib/libsljit/arch/mips: cache.c
>
> Log Message:
> Cast register_t to uintptr_t before casting to void *.
>
> Not sure what's going on here but evbmips64-el build
On Fri, Jan 11, 2019 at 08:22:23PM +0100, Christoph Badura wrote:
>
> What exactly did your change do to improve the awareness of these side
> effects? I'm at a loss when it comes to that.
You noticed that some side effects were already removed.
> Here's more defects and functionality
On Fri, Jan 11, 2019 at 12:41:36AM +0100, Michael van Elst wrote:
> On Thu, Jan 10, 2019 at 05:50:30PM +0100, Christoph Badura wrote:
> >
> > If you hadn't reversed the order of
> >
> > tftproot_dhcpboot()
> > if (md_is_root) ...
> > rootspec = bootspec
> >
> > that would wouldn't have need
On Thu, Jan 10, 2019 at 05:50:30PM +0100, Christoph Badura wrote:
>
> If you hadn't reversed the order of
>
> tftproot_dhcpboot()
> if (md_is_root) ...
> rootspec = bootspec
>
> that would wouldn't have need fixing because tftproot_dhcpboot() sets
> md_is_root.
It needed fixing because:
- md0
On Sat, Jan 05, 2019 at 06:03:41PM +, Michael van Elst wrote:
> Modified Files:
> src/sys/kern: kern_subr.c
> Log Message:
> Restore code to create md0, this fixes booting an INSTALL kernel.
This still does not restore the original functionality that was removed
without explanation or
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 Tue, Jan 08, 2019 at 04:03:14PM +0100, Manuel Bouyer wrote:
> On Tue, Jan 08, 2019 at 03:40:23PM +0100, Christoph Badura wrote:
> > On Mon, Jan 07, 2019 at 03:08:38PM +0100, Manuel Bouyer wrote:
> > > it looks like this broke Xen domU:
> > > http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
On Tue, Jan 08, 2019 at 03:40:23PM +0100, Christoph Badura wrote:
> On Mon, Jan 07, 2019 at 03:08:38PM +0100, Manuel Bouyer wrote:
> > it looks like this broke Xen domU:
> > http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
> >
> > [ 1.0800662] boot device: xbd0
> > [ 1.0800662] xenbus:
On Mon, Jan 07, 2019 at 03:08:38PM +0100, Manuel Bouyer wrote:
> it looks like this broke Xen domU:
> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
>
> [ 1.0800662] boot device: xbd0
> [ 1.0800662] xenbus: can't get state for device/suspend/event-channel (2)
> [ 1.0800662] unknown
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 Sat, Jan 05, 2019 at 09:39:56AM +, Michael van Elst wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Sat Jan 5 09:39:56 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_subr.c
>
> Log Message:
> Refactor setroot, no functional change intended.
>
> setroot
> -
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
1301 - 1400 of 5583 matches
Mail list logo
