On 2023/10/12 14:50, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Oct 12 05:50:56 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixgbe.c
>
> Log Message:
> ixg(4): Don't print wrong error message about ixgbe_num_queues.
>
> Don't override
On 2023-10-15 17.06, Joerg Sonnenberger wrote:
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
Module Name:src
Committed By: oster
Date: Sun Oct 15 22:36:53 UTC 2023
Modified Files:
src/sys/dev/pci/igc: if_igc.c
Log Message:
Fix build of the MODULAR
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
> Module Name: src
> Committed By: oster
> Date: Sun Oct 15 22:36:53 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/igc: if_igc.c
>
> Log Message:
> Fix build of the MODULAR kernel, which explicitly excludes vlans.
> Date: Thu, 10 Aug 2023 17:42:35 +0900
> From: Kengo NAKAHARA
>
> Could you tell me how you test this fix for future reference?
I asked skrll@ to boot a VM with vmxnet3 and hammer on it with a
combination of:
1. dhcp
2. host$ nc -l 54321 /dev/null
guest$ nc host 54321 /dev/null
3. for i in
Hi,
On 2023/08/10 18:07, Nick Hudson wrote:
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor suggested
host$ nc -l 54321 /dev/null
guest$ nc
Hi,
Could you tell me how you test this fix for future reference?
Thanks,
On 2023/08/10 17:24, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Thu Aug 10 08:24:45 UTC 2023
Modified Files:
src/sys/dev/pci: if_vmx.c
Log Message:
vmxnet(4): Fix
Hi,
On 21/09/2022 08:56, matthew green wrote:
this asserts for me. perhaps ryo@ didn't have LOCKDEBUG?
I had LOCKDEBUG on, but not DEBUG.
https://nxr.netbsd.org/xref/src/sys/sys/systm.h#760
I see that adding options DEBUG does indeed cause a panic with
ASSERT_SLEEPABLE()...
ah! that
> >this asserts for me. perhaps ryo@ didn't have LOCKDEBUG?
>
> I had LOCKDEBUG on, but not DEBUG.
> https://nxr.netbsd.org/xref/src/sys/sys/systm.h#760
> I see that adding options DEBUG does indeed cause a panic with
> ASSERT_SLEEPABLE()...
ah! that would explain it. nick asked me to test
>> Module Name: src
>> Committed By:skrll
>> Date:Fri Sep 16 03:55:53 UTC 2022
>>
>> Modified Files:
>> src/sys/dev/pci: if_aq.c
>>
>> Log Message:
>> Some MP improvements
>>
>> - Remove use of IFF_OACTIVE
>>
>> - Remove use of if_timer and provide an MP safe
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Fri Sep 16 03:55:53 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: if_aq.c
>
> Log Message:
> Some MP improvements
>
> - Remove use of IFF_OACTIVE
>
> - Remove use of if_timer and provide an MP safe multiqueue
On 03/08/2022 07:26, Kengo NAKAHARA wrote:
Hi,
On 2022/08/03 14:23, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Aug 3 05:23:30 UTC 2022
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Add some KASSERTs around the locking protocol.
Discussed
Hi,
On 2022/08/03 14:23, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Aug 3 05:23:30 UTC 2022
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Add some KASSERTs around the locking protocol.
Discussed with msaitoh@, knakahara@ and riastradh@
Hi.
On 2022/07/22 23:22, Hisashi T Fujinaka wrote:
> On Fri, 22 Jul 2022, SAITOH Masanobu wrote:
>
>> Module Name: src
>> Committed By: msaitoh
>> Date: Fri Jul 22 05:23:50 UTC 2022
>>
>> Modified Files:
>> src/sys/dev/pci: if_wm.c if_wmreg.h
>>
>> Log Message:
>> Add more
On Fri, 22 Jul 2022, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Jul 22 05:23:50 UTC 2022
Modified Files:
src/sys/dev/pci: if_wm.c if_wmreg.h
Log Message:
Add more statistics countes.
- Add many statics counters that the chip has.
On Sat, 9 Jul 2022, matthew green wrote:
"Paul Goyette" writes:
Module Name:src
Committed By: pgoyette
Date: Fri Jul 8 17:32:19 UTC 2022
Modified Files:
src/sys/dev/pci: nvme_pci.c
Log Message:
devsw_ok needs to survive across invocations of nvme_modcmd() so
allocate
"Paul Goyette" writes:
> Module Name: src
> Committed By: pgoyette
> Date: Fri Jul 8 17:32:19 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: nvme_pci.c
>
> Log Message:
> devsw_ok needs to survive across invocations of nvme_modcmd() so
> allocate it statically.
>
> Should address
On Sun, Feb 27, 2022 at 11:50:15AM +0100, Martin Husemann wrote:
> On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> > Personally, I prefer the use of the C extension in cases like this. The
> > "portable" version is less readable...
>
> I would prefer the type correct C++
On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> Personally, I prefer the use of the C extension in cases like this. The
> "portable" version is less readable...
I would prefer the type correct C++ style variant (and making lint deal
with it, if it doesn't yet). At least gcc
Am Sat, Feb 26, 2022 at 03:04:40PM + schrieb Roland Illig:
> Module Name: src
> Committed By: rillig
> Date: Sat Feb 26 15:04:40 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: if_wm.c
>
> Log Message:
> if_wm.c: fix value return from void function
>
> lint complained:
>
On 23/12/2021 17:05, Juergen Hannken-Illjes wrote:
Module Name:src
Committed By: hannken
Date: Thu Dec 23 17:05:49 UTC 2021
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Keep constants 32 bit, why does __BIT() return uintmax_t?
PRIxBIT is available
Nick
On Thu, Oct 21, 2021 at 05:32:28AM +, Shoichi YAMAGUCHI wrote:
> Module Name: src
> Committed By: yamaguchi
> Date: Thu Oct 21 05:32:27 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio.c virtio_pci.c virtiovar.h
>
> Log Message:
> divide setup routine of virtio
Hi,
Thank you for your quick commit!
Thanks,
On 2021/10/18 17:15, Juergen Hannken-Illjes wrote:
Module Name:src
Committed By: hannken
Date: Mon Oct 18 08:15:00 UTC 2021
Modified Files:
src/sys/dev/pci: xmm7360.c
Log Message:
Use a local static variable to hold
> On 12. Jul 2020, at 21:05, Jaromir Dolecek wrote:
>
> Module Name: src
> Committed By: jdolecek
> Date: Sun Jul 12 19:05:32 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_bnx.c if_bnxvar.h
>
> Log Message:
> enable MSI/MSI-X if supported by adapter
>
> tested MSI-X with
On Tue, Jan 26, 2021 at 05:51:42PM +0900, Rin Okuyama wrote:
> Hi,
> This seems not correct for me. Is the attached patch OK with you?
Well you spotted a bug indeed int he freeing section. I'll fix and commit it.
Thanks for reporting.
Reinoud
signature.asc
Description: PGP signature
Hi,
On 2021/01/25 0:33, Reinoud Zandijk wrote:
Module Name:src
Committed By: reinoud
Date: Sun Jan 24 15:33:02 UTC 2021
Modified Files:
src/sys/dev/pci: virtio_pci.c
Log Message:
On error unmap the pci_mapreg_map()d regions using bus_space_unmap() as
suggested by jak@
> On Jan 24, 2021, at 10:20 PM, Martin Husemann wrote:
>
>> I kept getting a ?static after non-static declaration? error when building
>> for aarch64.
>
> I guess that was with outdated arm/include/bus_funcs.h and
> sys/bus_proto.h (or where was the previous declaration)?
I did a “cvs
On Sun, Jan 24, 2021 at 09:45:14PM -0800, Jason Thorpe wrote:
>
> > On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote:
> >
> > While I don't care for names, I would like to understand fallout in
> > details before hiding it - what exactly did not compile correctly?
> > At least the affected
> On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote:
>
> While I don't care for names, I would like to understand fallout in
> details before hiding it - what exactly did not compile correctly?
> At least the affected arm kernels worked for me in the state directly
> before your commit.
I
On Sun, Jan 24, 2021 at 03:34:08PM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sun Jan 24 15:34:08 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Redefining bus_space functions in drivers is a bad idea, and we
> On Jan 23, 2021, at 5:40 PM, Christos Zoulas wrote:
>
>> it's a bad example. someone might copy it into another
>> driver that _doesn't_ work with this version, but may seem
>> to fix a build error.
>>
>> that's why i wanted to wrap the usage to make it clear if
>> someone were to copy it
In article <17141.1611452...@splode.eterna.com.au>,
matthew green wrote:
>Christos Zoulas writes:
>> In article <20210123230600.52be160...@jupiter.mumble.net>,
>> Taylor R Campbell wrote:
>> >
>> >Conversely, how do you know whether this hacked-up implementation
>> >which tears the write into
Christos Zoulas writes:
> In article <20210123230600.52be160...@jupiter.mumble.net>,
> Taylor R Campbell wrote:
> >
> >Conversely, how do you know whether this hacked-up implementation
> >which tears the write into two will actually work? Maybe it works for
> >virtio but there are likely other
In article <20210123230600.52be160...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>
>Conversely, how do you know whether this hacked-up implementation
>which tears the write into two will actually work? Maybe it works for
>virtio but there are likely other devices out there for which it will
> Date: Sat, 23 Jan 2021 22:59:22 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article <23974.1611441...@splode.eterna.com.au>,
> matthew green wrote:
> >this seems dangerous to me. we don't define it on
> >some platforms because we can't, so having it faked
> >out here
In article <23974.1611441...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jan 23 20:00:19 UTC 2021
>>
>> Modified Files:
>> src/sys/dev/pci: virtio_pci.c
>>
>> Log Message:
>> Provide
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 23 20:00:19 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Provide a generic bus_space_write_8 function that is bi-endian.
this seems dangerous to me. we don't
In article ,
Reinoud Zandijk wrote:
>On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote:
>> > +#ifndef _LP64
>>
>> _LP64 is a terrible way to make this choice.
>>
>> heaps of our 32 bit platforms implement the _8 variants.
>
>Can't we then just make sure they have the 8 bit variant?
In article ,
Nick Hudson wrote:
>On 22/01/2021 04:48, Christos Zoulas wrote:
>> +#if _QUAD_HIGHWORD
>> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
>> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
>> +#else
>> +bus_space_write_4(iot, ioh,
On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote:
> > +#ifndef _LP64
>
> _LP64 is a terrible way to make this choice.
>
> heaps of our 32 bit platforms implement the _8 variants.
Can't we then just make sure they have the 8 bit variant? and set a define if
its atomic or not?
This
On 22/01/2021 04:48, Christos Zoulas wrote:
+#if _QUAD_HIGHWORD
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
+#else
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
+
In article <27744.1611294...@splode.eterna.com.au>,
matthew green wrote:
>> +#ifndef _LP64
>
>_LP64 is a terrible way to make this choice.
>
>heaps of our 32 bit platforms implement the _8 variants.
Let's add a _HAVE_ variable then?
christos
> +#ifndef _LP64
_LP64 is a terrible way to make this choice.
heaps of our 32 bit platforms implement the _8 variants.
.mrg.
In article <20210121204833.9ebcff...@cvs.netbsd.org>,
Reinoud Zandijk wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: reinoud
>Date: Thu Jan 21 20:48:33 UTC 2021
>
>Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
>Log Message:
>Remove dependency on bus_space_write_8()
On 2020/12/11 14:01, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Dec 11 05:01:19 UTC 2020
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c ixgbe_type.h
Log Message:
Don't use EIMC_OTHER bit because it's read only other than 82598.
Documents
On 2020/10/16 14:53, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Oct 16 05:53:40 UTC 2020
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Fixes a problem that the attach function reported
"wm_gmii_setup_phytype: Unknown PHY model.
Hello,
On Sun, 11 Oct 2020 21:41:57 +
"Julian Coleman" wrote:
> Module Name: src
> Committed By: jdc
> Date: Sun Oct 11 21:41:57 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: radeonfb.c
>
> Log Message:
...
> don't ignore the bottom 200 lines of the display (for no
One of the things which need to be done is calling the if_ioctl always
with the IFNET_LOCK() held. Right now it sometimes is, and other times
it is not, so it's not possible to rely on it and KASSERT().
As for bnx(4) I did just some basic fixes around making it work with
MSI(-X), since I don't
> On Jul 17, 2020, at 3:50 PM, matthew green wrote:
>
> any chance you can look at NET_MPSAFE here etc? :)
I have a bunch of local changes for this in one of my trees, and I hope to get
back to it after netbsd-10 branches.
-- thorpej
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Fri Jul 17 09:48:21 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_bnx.c
>
> Log Message:
> re-enable MSI/MSI-X, the TX timeouts were caused by the IFF_OACTIVE handling,
> which was fixed in previous
Le 01/06/2020 à 03:23, Shoichi Yamaguchi a écrit :
Hi,
On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote:
I modified virtio(4) not to allocate unused memory.
I guess it fixes the issue.
Could you check this?
I confirmed your closing the report on syzbot.
Hi,
On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote:
>
> I modified virtio(4) not to allocate unused memory.
> I guess it fixes the issue.
>
> Could you check this?
I confirmed your closing the report on syzbot.
Hi,
On Wed, May 27, 2020 at 2:20 AM Maxime Villard wrote:
>
> Hi,
> I don't know if this is related to your changes, but kMSan detected one uninit
> variable in virtio 3h ago:
>
> https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610
>
> [ 153.4370851] panic: MSan:
Hi,
I don't know if this is related to your changes, but kMSan detected one uninit
variable in virtio 3h ago:
https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610
[ 153.4370851] panic: MSan: Uninitialized Kmem Memory From
virtio_pci_setup_interrupts()
[
On 20/05/2020 21:18, Sevan Janiyan wrote:
> Bump rcs tag which was missed in r1.9
That should've been r1.10
Sevan
On 2020/01/10 15:59, Jason Thorpe wrote:
>
>
>> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote:
>>
>> The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c
>> required to check stge's chip revision. So, if there is no any objection,
>> I'll make new if_stgevar.h and share it
> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote:
>
> The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c
> required to check stge's chip revision. So, if there is no any objection,
> I'll make new if_stgevar.h and share it with if_stge.c and ipgphy.c.
That seems fine.
On 2020/01/10 13:13, Jason Thorpe wrote:
>
>
>> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote:
>>
>>
>> Before my change, struct stge_softc is already in if_stgereg.h,
>> so I had thought it would be OK to move to it.
>
> Ah, I don't think I would have put it there when I wrote the driver
> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote:
>
>
> Before my change, struct stge_softc is already in if_stgereg.h,
> so I had thought it would be OK to move to it.
Ah, I don't think I would have put it there when I wrote the driver originally,
so it must have been moved there at
> Two options:
>
> a) Move some structs (including struct stge_softc) and defines
> to if_stge.c
>
> b) Move them to new if_stgevar.h
i've always preferred:
- fooreg.h and foovar.h exist only when more than 1
file use them
- fooreg.h ONLY has hardware constructs
- foovar.h
On 2020/01/09 23:08, Jason Thorpe wrote:
>
>
>> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote:
>>
>> Module Name: src
>> Committed By:msaitoh
>> Date:Thu Jan 9 10:54:16 UTC 2020
>>
>> Modified Files:
>> src/sys/dev/pci: if_stge.c if_stgereg.h
>>
>> Log Message:
> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote:
>
> Module Name: src
> Committed By: msaitoh
> Date: Thu Jan 9 10:54:16 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_stge.c if_stgereg.h
>
> Log Message:
> Reduce diff against OpenBSD. No functional change.
>
> -
It only prevent null pointer dereference.
On Mon, Nov 18, 2019 at 3:18 PM wrote:
>
> On Mon, Nov 18, 2019 at 06:15:27AM +, m...@netbsd.org wrote:
> > > Modified files:
> > >
> > > Index: src/sys/dev/pci/if_mcx.c
> > > diff -u src/sys/dev/pci/if_mcx.c:1.5 src/sys/dev/pci/if_mcx.c:1.6
> > >
> Modified files:
>
> Index: src/sys/dev/pci/if_mcx.c
> diff -u src/sys/dev/pci/if_mcx.c:1.5 src/sys/dev/pci/if_mcx.c:1.6
> --- src/sys/dev/pci/if_mcx.c:1.5 Thu Oct 17 15:57:56 2019
> +++ src/sys/dev/pci/if_mcx.c Mon Nov 18 04:40:05 2019
> @@ -1,4 +1,4 @@
> -/* $NetBSD: if_mcx.c,v 1.5
Tobias Nygren writes:
> Yep, MSI works now. According to the PCI Express Base Specification,
> Revision 3.0, table 7-3, having the bus master bit set to 0 disables
> MSI. Asmedia chip seems to have a bug which makes DMA work regardless ...
Yup - it works just fine! Well done! :)
ahcisata0:
On Fri, 18 Oct 2019 20:32:53 +0200
Tom Ivar Helbekkmo wrote:
> Tobias Nygren writes:
>
> > Module Name:src
> > Committed By: tnn
> > Date: Fri Oct 18 17:16:50 UTC 2019
> >
> > Modified Files:
> > src/sys/dev/pci: ahcisata_pci.c
> >
> > Log Message:
> > ahcisata:
Tobias Nygren writes:
> Module Name: src
> Committed By: tnn
> Date: Fri Oct 18 17:16:50 UTC 2019
>
> Modified Files:
> src/sys/dev/pci: ahcisata_pci.c
>
> Log Message:
> ahcisata: make sure bus mastering and memory space are actually enabled
>
> This makes the "ROCKPro64 PCI-e to
On 2019/06/27 18:56, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Jun 27 09:56:39 UTC 2019
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixv.c
>
> Log Message:
> Don't call set_vfta() if any VLAN is attached.
s/is/is not/
> XXX pullup-8.
>
>
>
Hi,
Has there been any progress on this since 2017-12-03?
I've noticed that ips(4) is missing the man-page, only has
a single revision on ips.c, and is not connected to the build
(neither to ALL nor GENERIC).
Is it intentional for this driver to remain in tree?
(Does it even still
Hello,
On Fri, 22 Mar 2019 17:07:10 +
m...@netbsd.org wrote:
> On Fri, Mar 22, 2019 at 07:41:41AM +, Martin Husemann wrote:
> > @@ -1402,6 +1402,9 @@ radeonfb_loadbios(struct radeonfb_softc
> > pci_find_rom(pa, romt, romh, romsz, PCI_ROM_CODE_TYPE_X86, ,
> > >sc_biossz);
> >
On Fri, Mar 22, 2019 at 07:41:41AM +, Martin Husemann wrote:
> @@ -1402,6 +1402,9 @@ radeonfb_loadbios(struct radeonfb_softc
> pci_find_rom(pa, romt, romh, romsz, PCI_ROM_CODE_TYPE_X86, ,
> >sc_biossz);
>
> + if (sc->sc_biossz == 0 || sc->sc_bios == NULL)
> +
"Michael Lorenz" writes:
> Module Name: src
> Committed By: macallan
> Date: Wed Mar 20 23:05:19 UTC 2019
>
> Modified Files:
> src/sys/dev/pci: radeonfb.c
>
> Log Message:
> add code to read disabled ROMs, adapted from xf86-video-radeon
> With this radeonfb does The Right
On 2019/03/13 19:02, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Wed Mar 13 10:02:13 UTC 2019
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c
Log Message:
- Fix a bug that the VLAN HW filter function is not correctly disabled
s/VLAN HW
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 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 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
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
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
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
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 {}
On 30/11/2018 17:47, Jaromir Dolecek wrote:
Module Name:src
Committed By: jdolecek
Date: Fri Nov 30 17:47:54 UTC 2018
Modified Files:
src/sys/dev/pci: ahcisata_pci.c xhci_pci.c
Log Message:
simplify intr establish code - rely on pci_intr_alloc() to allow
also MSI-X, and
On 2018/11/02 17:16, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Nov 2 08:16:49 UTC 2018
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
- Add missing wm_gate_hw_phy_config_ich8lan(false) in wm_phy_post_reset()
on PCH2.
On 2018/11/02 17:04, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Nov 2 08:04:42 UTC 2018
Modified Files:
src/sys/dev/pci: if_wm.c
Log Message:
Fix a PCH2 specific bug that wrong register value can be read when boot.
When a wrong value is
On 2018/11/01 1:11, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Wed Oct 31 16:11:29 UTC 2018
Modified Files:
src/sys/dev/pci: xhci_pci.c
Log Message:
Add MSI-X support.
Some xHCI chips support multi-vector MSI or MSI-X. Each
vector can be
On Fri, Sep 14, 2018 at 06:46:47PM +, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Fri Sep 14 18:46:47 UTC 2018
>
> Modified Files:
> src/sys/dev/pci: if_msk.c if_mskvar.h if_skreg.h
>
> Log Message:
> msk(4): add 64-bit DMA support
>
>
>
On 2018/07/03 13:02, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Tue Jul 3 04:02:07 UTC 2018
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c
Log Message:
Remove nmbclusters check.
A big problem is that the number of RX descriptor unexpectedly
Hi,
From: Kengo NAKAHARA , Date: Fri, 8 Jun 2018 20:20:03
+0900
> Hi,
>
> Sorry, I checked it fixed panic only. iwm.c:r1.81 and r1.82 fix this problem
> at my environment.
>
> Could you try latest kernel with these commits?
Thank you very much for your quick fix.
It works fine now.
>
Hi,
Sorry, I checked it fixed panic only. iwm.c:r1.81 and r1.82 fix this problem
at my environment.
Could you try latest kernel with these commits?
Thanks,
On 2018/06/09 3:14, Ryo ONODERA wrote:
> Hi,
>
> This change causes the following error and I cannot use iwm(4) device
> anymore.
>
On 2018/05/07 16:56, Masanobu SAITOH wrote:
Hi.
On 2018/05/03 17:38, Frank Kardel wrote:
Hi,
I am now seeing that packet reception stops. tcpdump will only show outgoing
packets and no incoming packets.
ifconfig ixgX down
ifconfig ixgX up
gets things going again.
Code from 2018-02-24 was
Hi.
On 2018/05/03 17:38, Frank Kardel wrote:
Hi,
I am now seeing that packet reception stops. tcpdump will only show outgoing
packets and no incoming packets.
ifconfig ixgX down
ifconfig ixgX up
gets things going again.
Code from 2018-02-24 was fine and I think even code shortly before
Hi,
I am now seeing that packet reception stops. tcpdump will only show
outgoing packets and no incoming packets.
ifconfig ixgX down
ifconfig ixgX up
gets things going again.
Code from 2018-02-24 was fine and I think even code shortly before this
commit was fine, but there was the mbuf
Hi,
I am now seeing that packet reception stops. tcpdump will only show
outgoing packets and no incoming packets.
ifconfig ixgX down
ifconfig ixgX up
gets things going again.
Code from 2018-02-24 was fine and I think even code shortly before this
commit was fine, but there was the mbuf
On 2018/04/04 17:13, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Wed Apr 4 08:13:07 UTC 2018
Modified Files:
src/sys/dev/pci/ixgbe: if_bypass.c if_fdir.c if_sriov.c ix_txrx.c
ixgbe.c ixgbe.h ixgbe_82598.c ixgbe_82598.h ixgbe_82599.c
1 - 100 of 253 matches
Mail list logo
