Re: CVS commit: src/sys/net

[Masanobu SAITOH]

On 2022/10/25 14:55, Masanobu SAITOH wrote:
> 
> 
> On 2022/10/25 14:51, matthew green wrote:
>> "SAITOH Masanobu" writes:
>>> Module Name:src
>>> Committed By:   msaitoh
>>> Date:   Mon Oct 24 07:45:44 UTC 2022
>>>
>>> Modified Files:
>>> src/sys/net: if_dl.h
>>>
>>> Log Message:
>>> Increase sdl_data so that more then IFNAMSIZ bytes are available.
>>>
>>>  - Increase the size of dl_data[] from 12 to 24.
>>>  - Same as OpenBSD.
>>
>> isn't this a binary compat issue?  eg, 'struct sockaddr_dl' changes,
>> and that, and things based upon it, are in user interfaces.  i had
>> a look and i believe it's a problem, but maybe i missed something.
>>
>> thanks.
>>
>>
>> .mrg.
> 
> struct dl_addr is at the end of struct sockaddr_dl.
> dl_data is at the end of struct dl_addr.
> So I think it's has no problem for old binaries.

I've roughly tested with old arp, ndp, ifconfig, ifmcstat and all /usr/tests
on a new kernel and I didn't saw any problem.

I think getifaddrs(3) has no problem. The routing message has no problem
because struct rtm_msglen has rtm_msglen and we can get the next message
using with it. I can't see any kernel data structure which has
struct sockaddr_dl foobadr[xxx] array.

One problem might be exist. An old userland program allocate buffer
with sizeof(struct sockaddr_dl), the size is smaller than the newer.
The old program might copy with memcpy(old_sized_buf, newdata, dla->sdl_len).

Should I backout the change until the COMPAT code is written?

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/net

[Masanobu SAITOH]

On 2022/10/25 14:51, matthew green wrote:
> "SAITOH Masanobu" writes:
>> Module Name: src
>> Committed By:msaitoh
>> Date:Mon Oct 24 07:45:44 UTC 2022
>>
>> Modified Files:
>>  src/sys/net: if_dl.h
>>
>> Log Message:
>> Increase sdl_data so that more then IFNAMSIZ bytes are available.
>>
>>  - Increase the size of dl_data[] from 12 to 24.
>>  - Same as OpenBSD.
> 
> isn't this a binary compat issue?  eg, 'struct sockaddr_dl' changes,
> and that, and things based upon it, are in user interfaces.  i had
> a look and i believe it's a problem, but maybe i missed something.
> 
> thanks.
> 
> 
> .mrg.

struct dl_addr is at the end of struct sockaddr_dl.
dl_data is at the end of struct dl_addr.
So I think it's has no problem for old binaries.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev

[Masanobu SAITOH]

On 2022/10/04 19:22, Taylor R Campbell wrote:
>> Date: Tue, 4 Oct 2022 17:16:35 +0900
>> From: Masanobu SAITOH 
>>
>> Before reverting changes, one of my machine which use serial console
>> didn't print the Copyright message.
>>
>> Revert two revert commit, i.e.
>> http://mail-index.netbsd.org/source-changes/2022/10/04/msg141389.html
>> http://mail-index.netbsd.org/source-changes/2022/10/04/msg141388.html
>> and applied consokfix.patch.
>> [...]
>> The boot message is not printed and I can see messages after /sbin/init.
>> dmesg(1) shows the kernel messages.
> 
> Can you please try with consokfix.patch _and_ consprintfix.patch?
> 
> consprintfix.patch should restore the kernel messages on the console.

It worked!

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev

[Masanobu SAITOH]

Hi.

On 2022/10/04 16:24, Ryo ONODERA wrote:
> Hi,
> 
> Taylor R Campbell  writes:
> 
>>> Date: Tue, 04 Oct 2022 15:53:58 +0900
>>> From: Ryo ONODERA 
>>>
>>> With this patch, it works fine for me.
>>> There is no stall after genfb(4).
>>> And I do not find any other problem so far.
>>
>> Thanks!  There probably is another problem which is that kernel
>> console printfs might stop appearing after a certain point, which the
>> following patch might fix too -- I inadvertently reversed the sense
>> of a conditional in the subr_prf.c changes.
> 
> I have not encountered another problem yet. However with your
> consprintfix.patch, it works fine for me too.

Before reverting changes, one of my machine which use serial console
didn't print the Copyright message.

Revert two revert commit, i.e.
http://mail-index.netbsd.org/source-changes/2022/10/04/msg141389.html
http://mail-index.netbsd.org/source-changes/2022/10/04/msg141388.html
and applied consokfix.patch.

> NetBSD MBR boot
> 
> NetBSD/x86 ffsv2 Primary Bootstrap
> 
> 0 seconds.
> booting hd0a:netbsd (howto 0xa)
> 72567816+35522344+2226392 [945568+1555416+1162803]=0x6d7f2a8
> Loading /var/db/entropy-file
> Tue Oct  4 17:07:44 JST 2022
> Starting root file system check:
> /dev/rwd0a: file system is clean; not checking
> Setting sysctl variables:
...

The boot message is not printed and I can see messages after /sbin/init.
dmesg(1) shows the kernel messages.

 Regards.


> Thank you.
> 
>> From 0f058a0e89e3f545a9020a2fb79dadd7ad89029a Mon Sep 17 00:00:00 2001
>> From: Taylor R Campbell 
>> Date: Tue, 4 Oct 2022 05:48:39 +
>> Subject: [PATCH] squash! constty(4): Make MP-safe.
>>
>> - Fix reversed sense of conditional.
>> ---
>>  sys/kern/subr_prf.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/sys/kern/subr_prf.c b/sys/kern/subr_prf.c
>> index e87e6efc8501..53fb20c1d393 100644
>> --- a/sys/kern/subr_prf.c
>> +++ b/sys/kern/subr_prf.c
>> @@ -425,7 +425,7 @@ putone(int c, int flags, struct tty *tp)
>>  if ((flags & TOLOG) &&
>>  c != '\0' && c != '\r' && c != 0177)
>>  logputchar(c);
>> -if ((flags & TOCONS) && ctp != NULL && c != '\0')
>> +if ((flags & TOCONS) && ctp == NULL && c != '\0')
>>  (*v_putc)(c);
>>  
>>  pserialize_read_exit(s);
> 

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 statistics countes.
>>
>> - Add many statics counters that the chip has.
> 
> Shouldn't you say which "the chip" you're talking about since wm seems
> to handle so many?

The current implementation is based on the FreeBSD and Linux.
All counters I added to NetBSD are also counted on both FreeBSD
and Linux. There are some difference between those two.
I also noticed that some code are doubtful and wrote them the
different way. To make the implementation perfect, I have to
read (almost) all datasheets and test on some chips. It's not
good to write only based on the datasheets. One of the reason is
that, for example, a register is not listed in the statistics
counters' table but the detail of the register is described later
in the chapter. It's not clear whether the register is exist
or not. The current implementation may not count some useful
counters.

The current implementation is not the final form but it's worth
to have. I could have written the details of the current
implementation when I committed, but I didn't really feel the
need to write the details of the implementation in its half-way
state. My apologies.

 Thanks.

> I suppose this isn't git so you can't fix this easily.
> 
>> - Attach event counters only if available.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.745 -r1.746 src/sys/dev/pci/if_wm.c
>> cvs rdiff -u -r1.126 -r1.127 src/sys/dev/pci/if_wmreg.h
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>>
>>
> 

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2020/02/27 15:17, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Thu Feb 27 06:17:28 UTC 2020
> 
> Modified Files:
>   src/sys/dev/mii: miidevs
> 
> Log Message:
>  Use xxVIA instead of VIA.
> 
>  0x004063 is VIA's official OUI but VT6103 use 0x0002c6.
> 0x0002c6 is non-bitreversed value of 0x004063. Reported by Andrius

It was PR kern/55016.

> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.163 -r1.164 src/sys/dev/mii/miidevs
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys [freeze on boot]

[Masanobu SAITOH]

Hi.

On 2020/01/21 2:06, Patrick Welche wrote:
> On Mon, Jan 20, 2020 at 04:12:45PM +, Patrick Welche wrote:
>> On Mon, Jan 20, 2020 at 12:51:00PM +, Andrew Doran wrote:
>>> This also happened the last time I touched rw_downgrade(), and I backed out
>>> the change then, but both times I don't see the bug.  I have some questions:
>>>
>>> - Are you running DIAGNOSTIC and/or LOCKDEBUG?  I would be very interested
>>>   to see what happens with a LOCKDEBUG kernel here.
>>
>> One worked with the addition of LOCKDEBUG. The other didn't, but it seems
>> to be unrelated:
>>
>> db{0}> show panic
>> Panic string: mutex_vector_enter,510: uninitialized lock 
>> (lock=0xbd012366609
>> 0, from=8033dc9d)
>> bt
>> breakpoint() at netbsd:breakpoint+0x5
>> vpanic() at netbsd:vpanic+0x178
>> snprintf() at netbsd:snprintf
>> lockdebug_wantlock() at netbsd:lockdebug_wantlock+0x166
>> mutex_enter() at netbsd:mutex_enter+0x37c
>> ixgbe_getext() at netbsd:ixgbe_getext+0x1d
> 
> ixgbe_getext does mutex_enter(>eh_mtx) but...


I suspect the location of your panic is after the following message
(because of ixgbe_allocate_msix()'s failure):

> aprint_normal(" ETrackID %08x\n", ((uint32_t)high << 16) | low);

If so, could you try the following diff?

--
 Fix the freeing code for some error paths. Found by Patrick Welche.

Index: ix_txrx.c
===
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ix_txrx.c,v
retrieving revision 1.59
diff -u -p -r1.59 ix_txrx.c
--- ix_txrx.c   20 Jan 2020 07:19:04 -  1.59
+++ ix_txrx.c   21 Jan 2020 06:24:16 -
@@ -2353,3 +2353,24 @@ err_tx_desc:
free(adapter->queues, M_DEVBUF);
return (error);
 } /* ixgbe_allocate_queues */
+
+/
+ * ixgbe_free_queues
+ *
+ *   Free descriptors for the transmit and receive rings, and then
+ *   the memory associated with each.
+ /
+void
+ixgbe_free_queues(struct adapter *adapter)
+{
+   struct ix_queue *que;
+   int i;
+
+   ixgbe_free_transmit_structures(adapter);
+   ixgbe_free_receive_structures(adapter);
+   for (i = 0; i < adapter->num_queues; i++) {
+   que = >queues[i];
+   mutex_destroy(>dc_mtx);
+   }
+   free(adapter->queues, M_DEVBUF);
+} /* ixgbe_free_queues */
Index: ixgbe.c
===
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.c,v
retrieving revision 1.220
diff -u -p -r1.220 ixgbe.c
--- ixgbe.c 3 Jan 2020 12:59:46 -   1.220
+++ ixgbe.c 21 Jan 2020 06:24:16 -
@@ -1059,9 +1059,7 @@ ixgbe_attach(device_t parent, device_t d
error = ixgbe_allocate_msix(adapter, pa);
if (error) {
/* Free allocated queue structures first */
-   ixgbe_free_transmit_structures(adapter);
-   ixgbe_free_receive_structures(adapter);
-   free(adapter->queues, M_DEVBUF);
+   ixgbe_free_queues(adapter);
 
/* Fallback to legacy interrupt */
adapter->feat_en &= ~IXGBE_FEATURE_MSIX;
@@ -1236,9 +1234,7 @@ ixgbe_attach(device_t parent, device_t d
return;
 
 err_late:
-   ixgbe_free_transmit_structures(adapter);
-   ixgbe_free_receive_structures(adapter);
-   free(adapter->queues, M_DEVBUF);
+   ixgbe_free_queues(adapter);
 err_out:
ctrl_ext = IXGBE_READ_REG(>hw, IXGBE_CTRL_EXT);
ctrl_ext &= ~IXGBE_CTRL_EXT_DRV_LOAD;
@@ -3712,13 +3708,7 @@ ixgbe_detach(device_t dev, int flags)
evcnt_detach(>ptc1023);
evcnt_detach(>ptc1522);
 
-   ixgbe_free_transmit_structures(adapter);
-   ixgbe_free_receive_structures(adapter);
-   for (i = 0; i < adapter->num_queues; i++) {
-   struct ix_queue * que = >queues[i];
-   mutex_destroy(>dc_mtx);
-   }
-   free(adapter->queues, M_DEVBUF);
+   ixgbe_free_queues(adapter);
free(adapter->mta, M_DEVBUF);
 
IXGBE_CORE_LOCK_DESTROY(adapter);
Index: ixgbe.h
===
RCS file: /cvsroot/src/sys/dev/pci/ixgbe/ixgbe.h,v
retrieving revision 1.61
diff -u -p -r1.61 ixgbe.h
--- ixgbe.h 20 Jan 2020 07:19:04 -  1.61
+++ ixgbe.h 21 Jan 2020 06:24:16 -
@@ -768,6 +768,7 @@ void ixgbe_deferred_mq_start_work(struct
 void ixgbe_drain_all(struct adapter *);
 
 int  ixgbe_allocate_queues(struct adapter *);
+void ixgbe_free_queues(struct adapter *);
 int  ixgbe_setup_transmit_structures(struct adapter *);
 void ixgbe_free_transmit_structures(struct adapter *);
 int  ixgbe_setup_receive_structures(struct adapter *);
Index: ixgbe_netbsd.c
===
RCS file: 

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

[Masanobu SAITOH]

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 with if_stge.c and ipgphy.c.
> 
> That seems fine.  Although it might be preferable to set a property on the 
> parent dev_t and then query that from ipgphy,

I've changed by this way. If it use if_stgevar.h and it includes pci related
header file, some archs' kernel which use ipgphy and not use PCI can't be
compiled. Some other MII PHY drivers do so.

 Thanks.

> rather than accessing the softc.
> 
> -- thorpej
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 
> originally, so it must have been moved there at some point.
 Oh, it was me :)

http://mail-index.netbsd.org/source-changes/2019/10/07/msg109768.html

>  In any case, moving it into if_stgereg.h was also an error.
> 
>>
>>> Please move them back to if_stge.c.  Doing incorrect things simply to 
>>> reduce the diff against someone else's copy of the code is not something we 
>>> should be undertaking.
>> Two options:
>>
>> a) Move some structs (including struct stge_softc) and defines
>>to if_stge.c
> 
> There is no reason to have if_stgevar.h, because no other modules need these 
> definitions, so it should all move to if_stge.c.

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.

> Thanks!
> 
>>
>> b) Move them to new if_stgevar.h
>>
>> Which one is prefer?
> 
> -- thorpej
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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:
>> Reduce diff against OpenBSD. No functional change.
>>
>> - USE CSR_{READ,WRITE}_*() macro.
>> - Move some macros from if_stge.c to if_stgereg.h
> 
> This diff is incorrect.

Yes. You're right.

>  The macros that were moved to if_stgereg.h are not related to hardware / 
> register definitions, but are purely software constructs.

Before my change, struct stge_softc is already in if_stgereg.h,
so I had thought it would be OK to move to it.

>  Please move them back to if_stge.c.  Doing incorrect things simply to reduce 
> the diff against someone else's copy of the code is not something we should 
> be undertaking.
 Two options:

 a) Move some structs (including struct stge_softc) and defines
to if_stge.c

 b) Move them to new if_stgevar.h

Which one is prefer?

> -- thorpej
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/amd64

[Masanobu SAITOH]

On 2019/12/27 1:55, Emmanuel Dreyfus wrote:
> On Wed, Dec 25, 2019 at 05:05:11PM +0900, Masanobu SAITOH wrote:
>>>> After this change, amd64 kernel does not boot on my HP Spectre x360
>>>> 13-inch ae019TU laptop with pure UEFI boot mode.
>>  I have a UEFI boot machine and it also doesn't boot well.
> 
> Please try the attached patch.
> 
> It adds the -n flag to ld, which disable auto-alignment of sections
> in the file. I undestand alignement is highly desirable for userland
> programs that may be mapped from file, but useless for the kernel,
> which is just readen once by the bootloader.
> 
> Without auto-alignement, the .text segment starts right after the
> ELF headers. This means the multiboot header can go in .text and
> stay below 32k (as required by the multiboot specification). There
> is no need for a multiboot section for that, and therefore no 
> need to modify the linker script.
> 
> A side effect is that the kernel file shrinks of 2 MB, because there
> is not an alignement hole between ELF headers and the .text section
> anymore.
> 
> My patch also enable the MULTIBOOT option so that we can check
> nothing gets broken with it. You can also try with the option
> disabled, of course.
> 

Both with and without MULTIBOOT works fine. No any hangup/panic.

 Thanks.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/amd64

[Masanobu SAITOH]

On 2019/12/25 17:05, Masanobu SAITOH wrote:
> On 2019/12/24 23:47, Emmanuel Dreyfus wrote:
>> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>>> After this change, amd64 kernel does not boot on my HP Spectre x360
>>> 13-inch ae019TU laptop with pure UEFI boot mode.
> 
>  I have a UEFI boot machine and it also doesn't boot well.
> 
>  - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
>The possibility is about 65%
>  - It sometimes panic in acpi_attach(), acpimcfg_probe or something else.
>The possibility is about 10%
>  - It sometimes boot up.
>The possibility is about 25%
> 
>> Hello
>>
>> Does the attached patch (crafted for port-amd64/54775) fix the
>> problem?
> 
>  I tried your patch(It can't apply cleanly, so a applied it by hand).
> I can't see any improvement.
> 
>  It seems for me that ACPI table can't decode correctly when it couldn't
> boot up.
> 

Boot:
http://mail-index.netbsd.org/source-changes/2019/12/15/msg111926.html

Hang or panic:
http://mail-index.netbsd.org/source-changes/2019/12/15/msg111928.html

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/amd64

[Masanobu SAITOH]

On 2019/12/24 23:47, Emmanuel Dreyfus wrote:
> On Tue, Dec 24, 2019 at 05:50:00PM +0900, Ryo ONODERA wrote:
>> After this change, amd64 kernel does not boot on my HP Spectre x360
>> 13-inch ae019TU laptop with pure UEFI boot mode.

 I have a UEFI boot machine and it also doesn't boot well.

 - It hangs after attaching ioapic0, cpu0 or acpi0 (or something else).
   The possibility is about 65%
 - It sometimes panic in acpi_attach(), acpimcfg_probe or something else.
   The possibility is about 10%
 - It sometimes boot up.
   The possibility is about 25%

> Hello
> 
> Does the attached patch (crafted for port-amd64/54775) fix the
> problem?

 I tried your patch(It can't apply cleanly, so a applied it by hand).
I can't see any improvement.

 It seems for me that ACPI table can't decode correctly when it couldn't
boot up.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/net

[Masanobu SAITOH]

On 2019/12/05 14:29, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Thu Dec  5 05:29:28 UTC 2019
> 
> Modified Files:
>   src/sys/net: if_media.h
> 
> Log Message:
> Fix previous comment change for ifm_media. It was correct.
> 
>  The real problem is that some driver misuse ifm_media as the current active
> media. struct mii_data has the current active media(mii_media_active). If a
> driver use mii(4), it can be use mii->mii_media_active for this purpose.
> struct ifmedia has no entry for this purpose. Some drivers have an entry

s/Some drivers/Some drivers not using mii(4)/

> in their own softc to keep the value, but some other's don't have it and
> they mistakenly use ifm_media.
> 
>  We might add a new entry to struct ifmedia in future to avoid this confusion
> and for simplify.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.67 -r1.68 src/sys/net/if_media.h
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys

[Masanobu SAITOH]

On 2019/11/27 19:19, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Wed Nov 27 10:19:21 UTC 2019
> 
> Modified Files:
>   src/sys/arch/arm/amlogic: gxlphy.c
>   src/sys/dev/mii: acphy.c amhphy.c atphy.c bmtphy.c brgphy.c ciphy.c
>   dmphy.c etphy.c exphy.c gentbi.c glxtphy.c gphyter.c icsphy.c
>   igphy.c ihphy.c ikphy.c inphy.c iophy.c ipgphy.c jmphy.c lxtphy.c
>   makphy.c micphy.c mii_physubr.c mvphy.c nsphy.c nsphyter.c pnaphy.c
>   qsphy.c rdcphy.c rgephy.c rlphy.c smscphy.c sqphy.c tlphy.c tqphy.c
>   ukphy.c urlphy.c
> 
> Log Message:
> - Simplify sc->mii_anegticks setting. Same as FreeBSD.
> 
>Don't set the default value not in the attach function. Instead, set the

s/not in the/in the/

>   default value (MII_ANEGTICKS) first in the beginning of the
>   mii_phy_add_media(). The function already has the code to change the value 
> to
>   MII_ANEGTICKS_GIGE if it's gigabit capable.
> 
> - Remove extra pmf_device_register() call. It's done in mii_phy_add_media().
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1 -r1.2 src/sys/arch/arm/amlogic/gxlphy.c
> cvs rdiff -u -r1.28 -r1.29 src/sys/dev/mii/acphy.c
> cvs rdiff -u -r1.24 -r1.25 src/sys/dev/mii/amhphy.c src/sys/dev/mii/pnaphy.c
> cvs rdiff -u -r1.25 -r1.26 src/sys/dev/mii/atphy.c
> cvs rdiff -u -r1.35 -r1.36 src/sys/dev/mii/bmtphy.c src/sys/dev/mii/gphyter.c
> cvs rdiff -u -r1.85 -r1.86 src/sys/dev/mii/brgphy.c
> cvs rdiff -u -r1.37 -r1.38 src/sys/dev/mii/ciphy.c src/sys/dev/mii/rlphy.c
> cvs rdiff -u -r1.43 -r1.44 src/sys/dev/mii/dmphy.c src/sys/dev/mii/nsphyter.c 
> \
> src/sys/dev/mii/tqphy.c
> cvs rdiff -u -r1.6 -r1.7 src/sys/dev/mii/etphy.c
> cvs rdiff -u -r1.56 -r1.57 src/sys/dev/mii/exphy.c
> cvs rdiff -u -r1.29 -r1.30 src/sys/dev/mii/gentbi.c
> cvs rdiff -u -r1.30 -r1.31 src/sys/dev/mii/glxtphy.c
> cvs rdiff -u -r1.54 -r1.55 src/sys/dev/mii/icsphy.c src/sys/dev/mii/sqphy.c
> cvs rdiff -u -r1.31 -r1.32 src/sys/dev/mii/igphy.c
> cvs rdiff -u -r1.15 -r1.16 src/sys/dev/mii/ihphy.c
> cvs rdiff -u -r1.17 -r1.18 src/sys/dev/mii/ikphy.c
> cvs rdiff -u -r1.58 -r1.59 src/sys/dev/mii/inphy.c
> cvs rdiff -u -r1.41 -r1.42 src/sys/dev/mii/iophy.c
> cvs rdiff -u -r1.7 -r1.8 src/sys/dev/mii/ipgphy.c
> cvs rdiff -u -r1.2 -r1.3 src/sys/dev/mii/jmphy.c
> cvs rdiff -u -r1.53 -r1.54 src/sys/dev/mii/lxtphy.c src/sys/dev/mii/qsphy.c
> cvs rdiff -u -r1.61 -r1.62 src/sys/dev/mii/makphy.c
> cvs rdiff -u -r1.9 -r1.10 src/sys/dev/mii/micphy.c
> cvs rdiff -u -r1.88 -r1.89 src/sys/dev/mii/mii_physubr.c
> cvs rdiff -u -r1.13 -r1.14 src/sys/dev/mii/mvphy.c
> cvs rdiff -u -r1.64 -r1.65 src/sys/dev/mii/nsphy.c
> cvs rdiff -u -r1.4 -r1.5 src/sys/dev/mii/rdcphy.c
> cvs rdiff -u -r1.57 -r1.58 src/sys/dev/mii/rgephy.c
> cvs rdiff -u -r1.1 -r1.2 src/sys/dev/mii/smscphy.c
> cvs rdiff -u -r1.66 -r1.67 src/sys/dev/mii/tlphy.c
> cvs rdiff -u -r1.51 -r1.52 src/sys/dev/mii/ukphy.c
> cvs rdiff -u -r1.34 -r1.35 src/sys/dev/mii/urlphy.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src

[Masanobu SAITOH]

On 2019/09/02 16:53, Masanobu SAITOH wrote:
> Background:
> 
>  In August 2014, lower-cased filename's files are added in the following
> commit:
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/radeon?id=f333bd435c0b6745cbc4fae3326725d77bf57c82
> 
> This commit says those files use the new header format. The radeon's drmkms
> driver basically try to use lower case's file first and then try the upper
> case's one. [*1]
> 
> After the above commit, usually lower-case's files have been added and 
> updated.
> Two exceptions:
> 
> TAHITI_vce.bin (only uppercase exists)
> BONAIRE_uvd.bin (both upper and lowe exist and both updated)
> 
> Some old (upper-case'd) firmware might be maintained anymore.
> 
> Now:
> Number of upper-cased filename's files: 158
> Number of lower-cased filename's files: 66
> Both lower-cased and upper-cased: 65
> 
> kaveri_mec2.bin has only lowercase one.
> (see also:
> http://mail-index.netbsd.org/tech-x11/2019/04/07/msg001953.html)
> 
> [*1] For _mc*.bin:
> 1st try: lower-case _mc.bin
> 2nd try: upper-case _mc2.bin
> 3rd try: upper-case _mc.bin
> 
> So, options are:
> 
> a) Remove duplicated upper-cased files.
> 
>pros: Simple. It's not required to modify radeon driver itself.
>  It also works with new kernel with old filesysysm.
>cons: If the driver failed to load the lower cased firmware,
>  driver can't read the upper-cased firmware.
> 
> b) Rename upper-case'd file to another name e.g.: foo_bar_old.bin
> 
>pros: It can be keep the driver's behavior the same as linux's.
>cons: We have to modify many files and lines.
>  If we support new kernel + old filesystem, we should modify
>  the driver to load FOO_BAR.bin first and then 
> FOO_BAR_old.bin.
> 
> c) keep the current status as it is.
> 
>pros: Any additional work is not required.
>cons: have trouble on case-insensitive file system.
> 
> d) Any other options.

I prefer option A.


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src

[Masanobu SAITOH]

Background:

 In August 2014, lower-cased filename's files are added in the following
commit:


https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/radeon?id=f333bd435c0b6745cbc4fae3326725d77bf57c82

This commit says those files use the new header format. The radeon's drmkms
driver basically try to use lower case's file first and then try the upper
case's one. [*1]

After the above commit, usually lower-case's files have been added and updated.
Two exceptions:

TAHITI_vce.bin (only uppercase exists)
BONAIRE_uvd.bin (both upper and lowe exist and both updated)

Some old (upper-case'd) firmware might be maintained anymore.

Now:
Number of upper-cased filename's files: 158
Number of lower-cased filename's files: 66
Both lower-cased and upper-cased: 65

kaveri_mec2.bin has only lowercase one.
(see also:
http://mail-index.netbsd.org/tech-x11/2019/04/07/msg001953.html)

[*1] For _mc*.bin:
1st try: lower-case _mc.bin
2nd try: upper-case _mc2.bin
3rd try: upper-case _mc.bin

So, options are:

a) Remove duplicated upper-cased files.

   pros: Simple. It's not required to modify radeon driver itself.
 It also works with new kernel with old filesysysm.
   cons: If the driver failed to load the lower cased firmware,
 driver can't read the upper-cased firmware.

b) Rename upper-case'd file to another name e.g.: foo_bar_old.bin

   pros: It can be keep the driver's behavior the same as linux's.
   cons: We have to modify many files and lines.
 If we support new kernel + old filesystem, we should modify
 the driver to load FOO_BAR.bin first and then FOO_BAR_old.bin.

c) keep the current status as it is.

   pros: Any additional work is not required.
   cons: have trouble on case-insensitive file system.

d) Any other options.



-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2019/08/05 23:06, Joerg Sonnenberger wrote:
> On Mon, Aug 05, 2019 at 10:12:04AM +, SAITOH Masanobu wrote:
>> Module Name: src
>> Committed By:msaitoh
>> Date:Mon Aug  5 10:12:04 UTC 2019
>>
>> Modified Files:
>>  src/sys/dev/acpi: acpi_ec.c
>>
>> Log Message:
>> - Fix a bug that acpiec_space_handler() doesn't access more than 64bit
>>   correctly. Found by kUBSan on Thinkpad X220. acpiec0 accessed 128bits from
>>   address 0xa0. The error message was:
>>
>>  UBSan: Undefined Behavior in ../../../../dev/acpi/acpi_ec.c:672:32, 
>> shift exponent 64 is too large for 64-bit type 'long unsigned int'
> 
> Ignore all the gracious changes that make the diff harder to read than
> necessary, doesn't this break the case of width == 0?

Oh, you're correct. When I noticed our code didn't increment the address,
I read FreeBSD's acpi_ec.c and did the same way. It seems old NetBSD,
OpenBSD and linux do the same way but FreeBSD doesn't.

 I committed the change to keep the old behavior.

Thanks.

> Joerg
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src

[Masanobu SAITOH]

On 2019/07/17 12:26, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Wed Jul 17 03:26:24 UTC 2019
> 
> Modified Files:
>   src/sbin/ifconfig: ether.c
>   src/sys/dev/pci/ixgbe: ixgbe.c ixgbe.h ixv.c
>   src/sys/net: if_ether.h if_ethersubr.c if_vlan.c
> 
> Log Message:
>  Implement VLAN hardware filter function(ETHERCAP_VLAN_HWFILTER).
> First proposed by jmcneill in 2017 and modified by me.
> 
> How to use:
> 
>  - Set callback function:
> 
>   ether_set_vlan_cb(struct ethercom *, ether_vlancb_t)
> 
>  - Callback. This function is called when a vlan is attached/detached to the
>parent interface:
> 
>   int (*ether_vlancb_t)(struct ethercom *ec, uint16_t vlanid, bool set);
> 
>  - ifconfig(8)
> 
>   ifconfig ixg0 [-]vlan-hwfilter
> 
>  Note that ETHERCAP_VLAN_HWFILTER is set by default on ixg(4) because

s/ixg/ixv/

> the PF driver usually enable "all block" filter by default.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 src/sbin/ifconfig/ether.c
> cvs rdiff -u -r1.192 -r1.193 src/sys/dev/pci/ixgbe/ixgbe.c
> cvs rdiff -u -r1.55 -r1.56 src/sys/dev/pci/ixgbe/ixgbe.h
> cvs rdiff -u -r1.119 -r1.120 src/sys/dev/pci/ixgbe/ixv.c
> cvs rdiff -u -r1.80 -r1.81 src/sys/net/if_ether.h
> cvs rdiff -u -r1.275 -r1.276 src/sys/net/if_ethersubr.c
> cvs rdiff -u -r1.140 -r1.141 src/sys/net/if_vlan.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/distrib/sets/lists/base

[Masanobu SAITOH]

On 2019/07/01 13:08, Masanobu SAITOH wrote:
> Hi.
> 
> On 2019/07/01 7:15, Brett Lymn wrote:
>> Module Name: src
>> Committed By:blymn
>> Date:Sun Jun 30 22:15:06 UTC 2019
>>
>> Modified Files:
>>  src/distrib/sets/lists/base: shl.mi
>>
>> Log Message:
>> Bump libcurses major and all dependent libraries.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.865 -r1.866 src/distrib/sets/lists/base/shl.mi
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
>>
> 
> This changed libcurses.so from 7.2 to 8.2.
> Is that a mistake of 8.0?
> 

And also please add new libraries to distrib/sets/lists/debug/shl.mi

See:
http://releng.netbsd.org/cgi-bin/builds.cgi

"Currently building tag: HEAD started at Sun Jun 30 23:35:01 UTC 2019 
65 failed so far "

On amd64:
> ===  8 extra files in DESTDIR  =
> Files in DESTDIR but missing from flist.
> File is obsolete or flist is out of date ?
> --
> ./usr/libdata/debug/usr/lib/i386/libcurses.so.8.2.debug
> ./usr/libdata/debug/usr/lib/i386/libform.so.7.0.debug
> ./usr/libdata/debug/usr/lib/i386/libmenu.so.7.0.debug
> ./usr/libdata/debug/usr/lib/i386/libpanel.so.2.0.debug
> ./usr/libdata/debug/usr/lib/libcurses.so.8.2.debug
> ./usr/libdata/debug/usr/lib/libform.so.7.0.debug
> ./usr/libdata/debug/usr/lib/libmenu.so.7.0.debug
> ./usr/libdata/debug/usr/lib/libpanel.so.2.0.debug
> =  end of 8 extra files  ===
> ==  8 missing files in DESTDIR  
> Files in flist but missing from DESTDIR.
> File wasn't installed ?
> --
> ./usr/libdata/debug/usr/lib/i386/libcurses.so.7.2.debug
> ./usr/libdata/debug/usr/lib/i386/libform.so.6.0.debug
> ./usr/libdata/debug/usr/lib/i386/libmenu.so.6.0.debug
> ./usr/libdata/debug/usr/lib/i386/libpanel.so.1.0.debug
> ./usr/libdata/debug/usr/lib/libcurses.so.7.2.debug
> ./usr/libdata/debug/usr/lib/libform.so.6.0.debug
> ./usr/libdata/debug/usr/lib/libmenu.so.6.0.debug
> ./usr/libdata/debug/usr/lib/libpanel.so.1.0.debug
>   end of 8 missing files  ==


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/distrib/sets/lists/base

[Masanobu SAITOH]

Hi.

On 2019/07/01 7:15, Brett Lymn wrote:
> Module Name:  src
> Committed By: blymn
> Date: Sun Jun 30 22:15:06 UTC 2019
> 
> Modified Files:
>   src/distrib/sets/lists/base: shl.mi
> 
> Log Message:
> Bump libcurses major and all dependent libraries.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.865 -r1.866 src/distrib/sets/lists/base/shl.mi
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

This changed libcurses.so from 7.2 to 8.2.
Is that a mistake of 8.0?

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

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.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.115 -r1.116 src/sys/dev/pci/ixgbe/ixv.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

On 2019/05/16 13:20, Jason Thorpe wrote:
> 
> 
>> On May 15, 2019, at 9:19 PM, Maxime Villard  wrote:
>>
>> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
>>> Module Name:src
>>> Committed By:   msaitoh
>>> Date:   Thu May 16 02:36:30 UTC 2019
>>> Modified Files:
>>> src/sys/arch/x86/x86: procfs_machdep.c
>>> Log Message:
>>>  Use ci_feat_val[7] instead of directly getting cpuid 7 edx.
>>> To generate a diff of this commit:
>>> cvs rdiff -u -r1.28 -r1.29 src/sys/arch/x86/x86/procfs_machdep.c
>>> Please note that diffs are not public domain; they are subject to the
>>> copyright notices on the relevant files.
>>
>> The microcode updates CPUID7, if you read ci_feat_val you have the
>> initial value, not the updated value. So reading CPUID7 was the right
>> thing to do.
> 
> Should the microcode update procedure fix up the cached copy?

I think so, but our code doesn't do it.

 There are some code which copy a cpuid value to ci_feat_val[] and
modify some bits for workaround and use the copy. ci_feat_val[]
is better than trusting current cpuid values for consistency.

We should provide user an interface to know the current behavior
of the kernel. I think ci_feat_val[] is the data to explain the
behavior. If so, we should use ci_feat_val[] in x86/procfs_machdep.c.
But, sadly, ci_feat_val[] is not updated, so it might better to
use real cpuid value than ci_feat_val[]. The latest x86/procfs_machdep.c
(rev. 1.31) refers ci_feat_val[0..6] and not refer ci_feat_val[7].
It's inconsistent.

 If we update ci_feat_val, we should have callback function to
reflect the change. Callback is not required for many bits but
it's required for some others.

 I have a code locally to know which bit is changed after updating
microcode:

--
Index: x86/cpu_ucode_intel.c
===
RCS file: /cvsroot/src/sys/arch/x86/x86/cpu_ucode_intel.c,v
retrieving revision 1.17
diff -u -p -r1.17 cpu_ucode_intel.c
--- x86/cpu_ucode_intel.c   10 May 2019 18:21:01 -  1.17
+++ x86/cpu_ucode_intel.c   16 May 2019 04:28:13 -
@@ -178,9 +178,14 @@ cpu_ucode_intel_apply(struct cpu_ucode_s
 {
uint32_t ucodetarget, oucodeversion, nucodeversion;
struct intel1_ucode_header *uh;
+   struct cpu_info *ci;
+   struct cpu_info oldci;
+   int i;
int platformid, cpuid, error;
size_t newbufsize = 0;
void *uha;
+   uint64_t msr = 0;
+   u_int descs[4];
 
if (sc->loader_version != CPU_UCODE_LOADER_INTEL1 ||
cpuno != CPU_UCODE_CURRENT_CPU)
@@ -221,15 +226,62 @@ cpu_ucode_intel_apply(struct cpu_ucode_s
intel_getcurrentucode(, );
cpuid = curcpu()->ci_index;
 
-   kpreempt_enable();
-
if (nucodeversion != ucodetarget) {
+   kpreempt_enable();
error = EIO;
goto out;
}
 
-   printf("cpu %d: ucode 0x%x->0x%x\n", cpuid, oucodeversion,
-   nucodeversion);
+   ci = curcpu();
+   oldci = *ci;
+#if 1
+   /*
+* Update cpu_info.
+*
+* XXX cpu_probe() is currently not intended to call multiple time
+* on a cpu.
+*/
+   cpu_probe(curcpu());
+#endif
+   if (ci->ci_max_cpuid >= 7) {
+   x86_cpuid(7, descs);
+   if (descs[3] & CPUID_SEF_ARCH_CAP)
+   msr = rdmsr(MSR_IA32_ARCH_CAPABILITIES);
+   }
+   kpreempt_enable();
+
+   if ((ci->ci_max_cpuid >= 7) && (descs[3] & CPUID_SEF_ARCH_CAP))
+   printf("cpu%d: MSR_IA32_ARCH_CAPABILITIES=0x%lx\n", cpuid,
+   msr);
+   printf("cpu%d: ucode 0x%x->0x%x\n", cpuid,
+  oucodeversion, nucodeversion);
+   for (i = 0; i < __arraycount(ci->ci_feat_val); i++) {
+   uint32_t old, new, dif, set, unset;
+
+   old = oldci.ci_feat_val[i];
+   new = ci->ci_feat_val[i];
+   if (old != new) {
+   printf("cpu%d: ci_feat_val[%d] changed from %08x to "
+   "%08x\n", cpuid, i, old, new);
+   dif = old ^ new;
+   set = new & dif;
+   unset = old & dif;
+
+   if (set != 0)
+   printf("cpu%d:   set: %08x\n", cpuid, set);
+   if (unset != 0)
+   printf("cpu%d: unset: %08x\n", cpuid, unset);
+
+   /*
+* Call hook if you want to do something.
+*
+* WARNING. If HyperThreading is enabled and the
+* microcode is updated to new one, another CPU's
+* feature bits also be changed and we cannot hook
+* for the CPU here.
+*/
+   }
+   }
 
 out:
if (newbufsize != 0)
--

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

On 2019/05/16 13:19, Maxime Villard wrote:
> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit :
>> Module Name:    src
>> Committed By:    msaitoh
>> Date:    Thu May 16 02:36:30 UTC 2019
>>
>> Modified Files:
>> src/sys/arch/x86/x86: procfs_machdep.c
>>
>> Log Message:
>>   Use ci_feat_val[7] instead of directly getting cpuid 7 edx.
>>
>>
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.28 -r1.29 src/sys/arch/x86/x86/procfs_machdep.c
>>
>> Please note that diffs are not public domain; they are subject to the
>> copyright notices on the relevant files.
> 
> The microcode updates CPUID7, if you read ci_feat_val you have the
> initial value, not the updated value. So reading CPUID7 was the right
> thing to do.

 We have no callback or something like it to reflect the change
to ci_feat_val, so you're right.

I'll revert it.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys

[Masanobu SAITOH]

On 2019/04/24 20:18, SAITOH Masanobu wrote:
> Module Name:  src
> Committed By: msaitoh
> Date: Wed Apr 24 11:18:21 UTC 2019
> 
> Modified Files:
>   src/sys/arch/arm/imx: if_enet.c
>   src/sys/dev/pci: if_wm.c
> 
> Log Message:
> SIOCS is 'S'et function and the ioctl argument is ifreq.
> SIOCG is 'G'et function and the ioctl armument is ifmediareq.
> Before this change, SIOCG modify sc->sc_flowflags unexpectedly.
> Don't hook SIOCGIFMEDIA becauise this driver uses MII(4) and ether_ioctl has
> the hook(if_ethersubr.c rev. 1.160).

The following line is garbage(copy mistatke):
> real bug because the modification is overriden in ifmedia_ioctl().

>  This driver might require some additional fixes for SIOCSIFMTU and other
> ioctl()s.
> 
> XXX pullup-[78].
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.18 -r1.19 src/sys/arch/arm/imx/if_enet.c
> cvs rdiff -u -r1.633 -r1.634 src/sys/dev/pci/if_wm.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

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 filter/VLAN HW tagging/


   when all vlan is detached.
- Fix a bug that VLAN HW filter function is not correctly controlled on 82598.


s/VLAN HW filter/VLAN HW tagging/


- Control VLAN HW filter function correctly.
- Don't clear IXGBE_VLNCTRL_CFIEN bit When ETHERCAP_VLAN_HWFILTER is set.
   I think it's not required (and Linux doesn't do it). This change has no
   effect to NetBSD because ETHERCAP_VLAN_HWFILTER is not supported yet.


To generate a diff of this commit:
cvs rdiff -u -r1.176 -r1.177 src/sys/dev/pci/ixgbe/ixgbe.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 WUC_APME bit older than PCH. Will fixes PR kern/53945 reported by kardel@.
Tested with my own 82574 card.


To generate a diff of this commit:
cvs rdiff -u -r1.624 -r1.625 src/sys/dev/pci/if_wm.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 FreeBSD and OpenBSD blindly enabled it. One of the difference between
NetBSD and others is that they configure unconfigured bridge.


Right, if the address decoders aren't programmed properly, it seems like you 
could get into all sorts of trouble.


done:

Module Name:src
Committed By:   msaitoh
Date:   Tue Jan 29 09:25:52 UTC 2019

Modified Files:
src/sys/dev/pci: ppb.c

Log Message:
 If the secondary bus is configured and the bus mastering is not enabled,
enable it. Suggested by thorpej@.





I really feel like the correct way to solve the problem is to fully configure 
the bus using information from ACPI.


 For ACPI, I'm not familiar with ACPI's PCI stuff, so please someone...
Even if it's implemented, some BIOS/UEFI don't configure add-in PCI bridge
behind bridge...

 And also please someone to write hotplug code (especially for hot insertion)...


-- thorpej




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 why this bug existed is that our order of WM_T_* was little
different from FreeBSD's enum e1000_mac_type. From 80003 to PCH_CNP and from
82575 to I211 are swapped.


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? (And duplicates and omissions.)


I think so and I'm going to simplify such type of checks (I have unfinished code
in locally). The reason why I committed the above change only is to make
the change understandable by separating from other changes.


--chris



 Thanks.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 configure unconfigured bridge.


-- 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

Log Message:
Explicitly enable bus masterling in case BIOS, UEFI or firmware don't enable
it. Might fix PR kern/53811.


To generate a diff of this commit:
cvs rdiff -u -r1.65 -r1.66 src/sys/dev/pci/ppb.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.






--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 device interrupts via ioapic don't get interrupts/data at all or not 
reliably. This affects following devices AFAICS on my system:
 com*
 wm1 (PCIe network card)
     radeon (see errors below)

MSI/X using devices seem to do fine.

Interrupt allocation is the same in both environments:

UEFI & CSM
interrupt id    device name(s)
ioapic0 pin 9   acpi SCI
ioapic0 pin 1   pckbc1 kbd
msix0 vec 0 nvme0 adminq
msix0 vec 1 nvme0 ioq1
msix0 vec 2 nvme0 ioq2
msix0 vec 3 nvme0 ioq3
msix0 vec 4 nvme0 ioq4
msix0 vec 5 nvme0 ioq5
msix0 vec 6 nvme0 ioq6
msix0 vec 7 nvme0 ioq7
msi1 vec 0  xhci0
msi2 vec 0  ahcisata0
msix3 vec 0 wm0TXRX0
msix3 vec 1 wm0TXRX1
msix3 vec 2 wm0LINK
ioapic1 pin 10  wm1, com5
ioapic1 pin 11  com2, ahd0
ioapic1 pin 8   com3
ioapic1 pin 9   com4
msi4 vec 0  hdaudio0
msi5 vec 0  mpii0
msi6 vec 0  xhci1
msi7 vec 0  ahcisata1
msi8 vec 0  hdaudio1
ioapic0 pin 4   com0
ioapic1 pin 30  radeon0

Other hickups seen:
   keyboard input (PS/2) is sometimes repeated
   glxgears regularly stalls for a seconds and does not really run smoothly.
   llinfo entries for wm1 fail, arp resolution on wm1 fail
   wm1 seems completely broken - no packets are received there

dmesg differences are from efi presence, minor difference memory size, 
different usb detection sequence. nothing critical.

The main difference is the radeon* fails to properly initialize giving these 
diagnostics:
  kern info: [drm] radeon: irq initialized.
kern info: [drm] ring test on 0 succeeded in 0 usecs
kern info: [drm] ring test on 3 succeeded in 3 usecs
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
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 reset the VCPU!!!
kern error: 
[drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_uvd_v1_0.c:354)uvd_v1_0_start]
 *ERROR* UVD not responding, giving up!!!
kern error: 
[drm:(/src/NetBSD/cur/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_evergreen.c:5688)evergreen_startup]
 *ERROR* radeon: error initializing UVD (-1).
kern info: [drm] ib test on ring 0 succeeded in 0 usecs
kern info: [drm] ib test on ring 3 succeeded in 0 usecs

Differences between pci configs (lspic -v)
--- lspci-csm-20190127    2019-01-27 14:42:57.454117956 +0100
+++ lspci-uefi-20190127    2019-01-27 14:51:27.003880544 +0100
@@ -4,7 +4,7 @@

  00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Device 1451
  Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1451
-    Flags: bus master, fast devsel, latency 0, IRQ 255
+    Flags: fast devsel, IRQ 255
  Capabilities: [40] Secure device 
  Capabilities: [64] MSI: Enable- Count=1/4 Maskable- 64bit+
  Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+
@@ -213,7 +213,7 @@
  Capabilities: [100] Advanced Error Reporting

  1d:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b4 (rev 02) 
(prog-if 00 [Normal decode])
-    Flags: bus master, fast devsel, latency 0, IRQ 11
+    Flags: fast devsel, IRQ 11
  Bus: primary=1d, secondary=1e, subordinate=1e, sec-latency=0
  

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

[Masanobu SAITOH]

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 functional change intended:
- Use "do {} while (/*CONSTCOND*/false)" for null DPRINTF().
- Reduce indent level of wm_linkintr_gmii().


There is __nothing

christos


 I didn't know it! I've changed with it now.

 Thanks.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2018/12/15 23:41, Jason Thorpe wrote:




On Dec 15, 2018, at 2:30 AM, SAITOH Masanobu  wrote:

Module Name:src
Committed By:   msaitoh
Date:   Sat Dec 15 10:30:58 UTC 2018

Modified Files:
src/sys/dev/usb: if_urtwn.c

Log Message:
Make IODATA WN-G150UMW work:
- Increase delay to prevent "could not send firmware command". The value
  is taken from FreeBSD.
-Increase delay to prevent "timeout waiting for firmware readiness". The
  vaule is taken from Linux.


This is worth a pull-up to netbsd-8, I think.  I get that firmware readiness 
error a lot on one of the urtwn devices I have on a RPI (I don't have I handy, 
so I can't tell you the exact model right now).

-- thorpej



I've sent the pullup request now!

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/external/bsd/file/lib

[Masanobu SAITOH]

Oops, sorry. Wrong mail address.

On 2018/12/13 20:54, Masanobu SAITOH wrote:

  Please pullup the following change to netbsd-8 branch.

On 2018/12/12 15:36, SAITOH Masanobu wrote:

Module Name:    src
Committed By:    msaitoh
Date:    Wed Dec 12 06:36:13 UTC 2018

Modified Files:
src/external/bsd/file/lib: Makefile

Log Message:
  Use DPSRCS for magic.h. OK'd by Christos.


To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 src/external/bsd/file/lib/Makefile

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



  This change can't apply cleanly to netbsd-8, so use the following diff:

Index: Makefile
===
RCS file: /cvsroot/src/external/bsd/file/lib/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile    10 Feb 2017 18:11:18 -    1.8
+++ Makefile    13 Dec 2018 11:53:40 -
@@ -20,6 +20,7 @@ CPPFLAGS+=-I.
  SRCS=    magic.c apprentice.c softmagic.c ascmagic.c compress.c    \
  is_tar.c readelf.c print.c fsmagic.c apptype.c funcs.c \
  cdf.c readcdf.c cdf_time.c encoding.c der.c
+DPSRCS=    magic.h
  MAN=    libmagic.3
  MLINKS+=    libmagic.3 magic_open.3 \
  libmagic.3 magic_close.3 \
@@ -41,5 +42,3 @@ magic.h:    magic.h.in
  CLEANFILES+=    magic.h

  .include 
-
-${ALLOBJS}:    magic.h





--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/external/bsd/file/lib

[Masanobu SAITOH]

 Please pullup the following change to netbsd-8 branch.

On 2018/12/12 15:36, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Wed Dec 12 06:36:13 UTC 2018

Modified Files:
src/external/bsd/file/lib: Makefile

Log Message:
  Use DPSRCS for magic.h. OK'd by Christos.


To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.11 src/external/bsd/file/lib/Makefile

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



 This change can't apply cleanly to netbsd-8, so use the following diff:

Index: Makefile
===
RCS file: /cvsroot/src/external/bsd/file/lib/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile10 Feb 2017 18:11:18 -  1.8
+++ Makefile13 Dec 2018 11:53:40 -
@@ -20,6 +20,7 @@ CPPFLAGS+=-I.
 SRCS=  magic.c apprentice.c softmagic.c ascmagic.c compress.c  \
is_tar.c readelf.c print.c fsmagic.c apptype.c funcs.c \
cdf.c readcdf.c cdf_time.c encoding.c der.c
+DPSRCS=magic.h
 MAN=   libmagic.3
 MLINKS+=   libmagic.3 magic_open.3 \
libmagic.3 magic_close.3 \
@@ -41,5 +42,3 @@ magic.h:magic.h.in
 CLEANFILES+=   magic.h
 
 .include 

-
-${ALLOBJS}:magic.h


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/arm/acpi

[Masanobu SAITOH]

Hi.

On 2018/11/28 3:29, Jared D. McNeill wrote:

Module Name:src
Committed By:   jmcneill
Date:   Tue Nov 27 18:29:17 UTC 2018

Modified Files:
src/sys/arch/arm/acpi: acpi_platform.c

Log Message:
Add support for SPCR 16550 and 16450 interface types


To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/arm/acpi/acpi_platform.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


 SPCR's interface type is the same as DBG's PortType.
src/sys/external/bsd/acpica/dist/include/actbl1.h defines DBG's
port type, so it would be good to use actbl1.h's definitions and
remove duplicated definitions in acpi_platform.c. It also seems
that ACPI_DBG2_ARM_DCC (0x000f) is not treated in acpi_platform.c

See also:

https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/acpitools/acpidump/acpi.c.diff?r1=1.33=1.34=h

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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. wm_gate_hw_phy_config_ich8lan(true) is called in wm_reset(), so
   wm_phy_post_reset(false) should be called after reset.


s/wm_phy_post_reset(false) should be called after 
reset/wm_gate_hw_phy_config_ich8lan(false) should be called after reset in 
wm_phy_post_reset()/


- On PCH2, set the phy config counter to 50msec after (PHY) reset.


To generate a diff of this commit:
cvs rdiff -u -r1.593 -r1.594 src/sys/dev/pci/if_wm.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 read when boot, the read device ID was incorrect and
ukphy(3) is attached instead of ihphy(4). The bug might also result in
MDIC read/write error.

  How to reproduce:

   0) Boot Windows.
   1) Leave some minutes.
   2) Reboot to NetBSD.


 To reproduce this problem, the PHY link should be down
(don't connect Ethernet cable).


  To fix this problem, adding extra 100us delay at the end of
wm_gmii_mdic_{read,write}reg() on PCH2. Same as FreeBSD and linux.

  Reported by David Brownlee a few days ago and also reported by jmcneill
a half year ago. Tested with my own Thinkpad X220.

XXX pullup-[78]


To generate a diff of this commit:
cvs rdiff -u -r1.591 -r1.592 src/sys/dev/pci/if_wm.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

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 assigned to different port. Please someone(TM) wrote
the code to get the benefit.




To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 src/sys/dev/pci/xhci_pci.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/kern

[Masanobu SAITOH]

On 2018/08/02 18:10, Kamil Rytarowski wrote:

On 02.08.2018 06:33, Masanobu SAITOH wrote:

On 2018/08/02 13:28, SAITOH Masanobu wrote:

Module Name:    src
Committed By:    msaitoh
Date:    Thu Aug  2 04:28:56 UTC 2018

Modified Files:
 src/sys/kern: uipc_mbuf2.c

Log Message:
Adjust alignment in m_pulldown().

   IP6_EXTHDR_GET() and M_REGION_GET() do m_pulldown(). When
m_pulldown() copies
data into M_TRAILINGSPACE, the alignment might be changed. There are a
lot of
IP6_EXTHDR_GET() calls, so I think it's not good to check the
alignment after
every IP6_EXTHDR_GET() call. This change fixes this problem in
m_pulldown().
In this commit, the next mbuf are 4 byte aligned. For networking, I've
never
heard that 64bit alignment is required, so I think it would be OK.

   I don't know this is the best solution, but it's better than nothing.

   OK'd by maxv@.

   After committing this change, the workaround code for PR#50776 can
be removed.


Not PR#50776 but PR#50766
(panic in tcp_input.c on the banana pi (earm7hf) when trying to connect
an ipv6 address through a gif ipv6 in ipv4 tunnel)



I've identified various similar misalignment in the kernel.

I will land the utility (micro-UBSan) to the sources soon (this week?).
It got delayed few days because rebase to HEAD with newer clang
introduced new checks and I needed to cover them with handlers and tests.


 The problem is that many people (include me) didn't know
IP6_EXTHDR_GET() and M_REGION_GET() (and m_pulldown()) might change
the next mbuf's alignment. It's not documented.


Currently,

grep _ALIGNED_P */*.h
netinet/icmp_private.h:#define  ICMP_HDR_ALIGNED_P(ic)  1
netinet/icmp_private.h:#define  ICMP_HDR_ALIGNED_P(ic)  vaddr_t) (ic)) & 3) 
== 0)
netinet/igmp_var.h:#define  IGMP_HDR_ALIGNED_P(ig)  1
netinet/igmp_var.h:#define  IGMP_HDR_ALIGNED_P(ig)  vaddr_t) (ig)) & 3) 
== 0)
netinet/ip_private.h:#defineIP_HDR_ALIGNED_P(ip)1
netinet/ip_private.h:#defineIP_HDR_ALIGNED_P(ip)vaddr_t) (ip)) & 3) 
== 0)
netinet/tcp_private.h:#define   TCP_HDR_ALIGNED_P(th)   1
netinet/tcp_private.h:#define   TCP_HDR_ALIGNED_P(th)   vaddr_t)(th)) & 3) 
== 0)
netinet/udp_private.h:#define   UDP_HDR_ALIGNED_P(uh)   1
netinet/udp_private.h:#define   UDP_HDR_ALIGNED_P(uh)   vaddr_t) (uh)) & 3) 
== 0)
netinet6/ip6_private.h:#define  IP6_HDR_ALIGNED_P(ip)   1
netinet6/ip6_private.h:#define  IP6_HDR_ALIGNED_P(ip)   vaddr_t) (ip)) & 3) 
== 0)


so 4 byte alignment is OK. I heard that OpenFlow's packet has uint64_t values,
so this solution might not work in future.

 Correct solution is to check all code around IP6_EXTHDR_GET(),
M_REGION_GET() and  m_pulldown(). If a code before those call expects
the mbuf is aligned, (re-)check the alignment with xxx_HDR_ALIGNED_P().
If it's not aligned, (re-)align with m_copyup().


28 IP6_EXTHDR_GET()s:
https://nxr.netbsd.org/search?q=IP6_EXTHDR_GET=src

12 M_REGION_GET()s:
https://nxr.netbsd.org/search?q=M_REGION_GET=src

21 m_pulldown()s:
https://nxr.netbsd.org/search?q=m_pulldown=src

Not so much?

 Let me know if my understanding is incorrect.






To generate a diff of this commit:
cvs rdiff -u -r1.32 -r1.33 src/sys/kern/uipc_mbuf2.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.











--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/kern

[Masanobu SAITOH]

On 2018/08/02 13:28, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Thu Aug  2 04:28:56 UTC 2018

Modified Files:
src/sys/kern: uipc_mbuf2.c

Log Message:
Adjust alignment in m_pulldown().

  IP6_EXTHDR_GET() and M_REGION_GET() do m_pulldown(). When m_pulldown() copies
data into M_TRAILINGSPACE, the alignment might be changed. There are a lot of
IP6_EXTHDR_GET() calls, so I think it's not good to check the alignment after
every IP6_EXTHDR_GET() call. This change fixes this problem in m_pulldown().
In this commit, the next mbuf are 4 byte aligned. For networking, I've never
heard that 64bit alignment is required, so I think it would be OK.

  I don't know this is the best solution, but it's better than nothing.

  OK'd by maxv@.

  After committing this change, the workaround code for PR#50776 can be removed.


Not PR#50776 but PR#50766
(panic in tcp_input.c on the banana pi (earm7hf) when trying to connect an ipv6 
address through a gif ipv6 in ipv4 tunnel)




To generate a diff of this commit:
cvs rdiff -u -r1.32 -r1.33 src/sys/kern/uipc_mbuf2.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.





--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

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
decreased from 2048 to 1024 if the number of port and/or the number
of CPU is high.


a2sdihtp4f: sysctl -a | grep ixg | grep rx_desc
hw.ixg0.num_rx_desc = 2048
hw.ixg1.num_rx_desc = 2048
hw.ixg2.num_rx_desc = 2048
hw.ixg3.num_rx_desc = 1024




We don't use the mbuf cluster. The old code also had
a bug that ixgbe_total_ports adds two every port and never decrement in
the detach path. Found by hikaru@.

  The code was removed in FreeBSD when it switched to use iflib and OpenBSD
removed the code 8 years ago.


To generate a diff of this commit:
cvs rdiff -u -r1.161 -r1.162 src/sys/dev/pci/ixgbe/ixgbe.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2018/06/17 2:44, Jaromir Dolecek wrote:

Module Name:src
Committed By:   jdolecek
Date:   Sat Jun 16 17:44:53 UTC 2018

Modified Files:
src/sys/dev/mii: makphy.c
Added Files:
src/sys/dev/mii: e1000phyreg.h
Removed Files:
src/sys/dev/mii: makphyreg.h

Log Message:
switch to using OpenBSD eehpy(4) code to drive maphy(4), synchronizing support
for several special PHY conditions, particularly:
- Properly re-initialise the PHY upon resume
- Store next page in the Link Partner Next Page register for compatibility
   with 802.3ab on 88E3016 PHYs.  Fixes some autonegotiation problems on msk(4)
- Make 88E3016 actually work
- Make sure page 0 is selected when we initialize the PHY.  Fixes problems
   with the eephy(4) that attaches to nfe(4) on machines like the Sun Ultra 40.
   (we had condition for this, now the page 0 is selected for any PHY type)
- Disable fiber/copper auto-selection on the 88E if it is in RGMII mode, to
   work around the fact that the onboard PHYs attached to nfe(4) on the Sun
   X4100 M2 have fiber/copper auto-selection enabled even though the interfaces
   are clearly copper-only

make sure to also add appropriate licenses, since basically nothing
really significant remains out of previous code

use FreeBSD  for register definitions as a base instead
of OpenBSD , since it has some extra definitions for some
3016 bits, but add the several extra bits from OpenBSD needed by the code;
removed no longed used 


 IMHO, I would be better having discussion before committing this change.
At least, all of Marvell PHY's registers from addr 0x0 to 0xf conforms
IEEE 802.3 specification, so those register definitions are not required.




tested with PHY 88E, there no particular change observed - the
link status works as it did before, just now it does media nego
even before the interface is up

should however fix 88E3016 support and hence PR kern/49270 and PR kern/53301


To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/sys/dev/mii/e1000phyreg.h
cvs rdiff -u -r1.43 -r1.44 src/sys/dev/mii/makphy.c
cvs rdiff -u -r1.6 -r0 src/sys/dev/mii/makphyreg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-8] src

[Masanobu SAITOH]

On 2018/06/15 10:52, David H. Gutteridge wrote:

Module Name:src
Committed By:   martin
Date:   Thu Jun 14 19:57:24 UTC 2018

Modified Files:
src/share/man/man4 [netbsd-8]: rtsx.4
src/sys/dev/ic [netbsd-8]: rtsx.c rtsxreg.h rtsxvar.h
src/sys/dev/pci [netbsd-8]: pcidevs rtsx_pci.c

Log Message:
Pull up following revision(s) (requested by maya in ticket #878):

share/man/man4/rtsx.4: revision 1.5
sys/dev/pci/pcidevs: revision 1.1331
sys/dev/ic/rtsxreg.h: revision 1.3
sys/dev/ic/rtsxvar.h: revision 1.3
sys/dev/pci/rtsx_pci.c: revision 1.7
sys/dev/ic/rtsx.c: revision 1.3

add realtek RT525A PCI-E card reader
found in my Dell XPS 15 9550.

rtsx(4): Add support for RT525A, from openbsd.
ok rkujawa

Denote RTS525A, bump date


Hello,

This has broken the build for me, presumably because the pcidevs
regeneration process didn't happen. I'm getting:


 Updated. Please retry.

 

--- rtsx_pci.o ---
/home/disciple/netbsd-8/src/sys/dev/pci/rtsx_pci.c: In function
'rtsx_pci_match':
/home/disciple/netbsd-8/src/sys/dev/pci/rtsx_pci.c:82:7: error:
'PCI_PRODUCT_REALTEK_RTS525A' undeclared (first use in this function)
   case PCI_PRODUCT_REALTEK_RTS525A:
^
/home/disciple/netbsd-8/src/sys/dev/pci/rtsx_pci.c:82:7: note: each
undeclared identifier is reported only once for each function it appears
in
/home/disciple/netbsd-8/src/sys/dev/pci/rtsx_pci.c: In function
'rtsx_pci_attach':
/home/disciple/netbsd-8/src/sys/dev/pci/rtsx_pci.c:121:7: error:
'PCI_PRODUCT_REALTEK_RTS525A' undeclared (first use in this function)
   case PCI_PRODUCT_REALTEK_RTS525A:
^
*** [rtsx_pci.o] Error code 1

Regards,

Dave




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

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 fine and I think even code shortly before this commit 
was fine, but there was the mbuf used-after-free issue that hit me pretty hard. 
So the system wasn't running for too long anyway.

Does that ring a bell ?

Frank


  IMHO, this change doesn't cause such type of problem...

  Could you show me the following information?

  0) dmesg

 This is required to know which chip is used and what type of
 interrupt is used and configured (INTX, MSI or MSI-X).

  1) ifconfig -v ixg0

 It's required to know offload status, the MTU size and some
 error count.

  2) sysctl hw.ixg0 (or sysctl hw |grep ixg (for all ixg(4)s))

 This output has some information of TX/RX ring.

  3) vmstat -e[v]

     Only for ixg(4):
     vmstat -e[v] |grep ixg

 ixg(4) has a lot of counters. I added error counters at
 all of error paths. (If you found a error path which has
 no counter, it's my fault.)

     Only to check checksum counters:

     options INET_CSUM_COUNTERS (for ip_input())
     options TCP_CSUM_COUNTERS  (for tcp_input())
     options UDP_CSUM_COUNTERS  (for udp_input())
     options WM_EVENT_COUNTERS  (only for wm(4))
     options BGE_EVENT_COUNTERS (only for bge(4))
     (No special options for ixg(4) because those counters are enabled by 
default)

     vmstat -e[v] |grep csum

  4) If you use a virtual interface like vlan(4) or age(4). Please


s/age/agr/



     show the configuration.



5) Whether you use options NET_MPSAFE or not.


Thanks.



  Regards.


On 04/25/18 10:46, SAITOH Masanobu wrote:

Module Name:    src
Committed By:    msaitoh
Date:    Wed Apr 25 08:46:19 UTC 2018

Modified Files:
src/sys/dev/pci/ixgbe: ix_txrx.c ixgbe.h ixgbe_netbsd.c ixgbe_netbsd.h
    ixgbe_osdep.h

Log Message:
  Don't free and reallocate bus_dmamem when it's not required. Currently,
the watchdog timer is completely broken and never fire (it's from FreeBSD
(pre iflib)). If the problem is fixed and watchdog fired, ixgbe_init() always
calls ixgbe_jcl_reinit() and it causes panic. The reason is that
ixgbe_local_timer1(it includes watchdog function) is softint and
xgbe_jcl_reinit() calls bus_dmamem*() functions. bus_dmamem*() can't be called
from interrupt context.

  One of the way to prevent panic is use worqueue for the timer, but it's
not a small change. (I'll do it in future).

  Another way is not reallocate dmamem if it's not required. If both the MTU
(rx_mbuf_sz in reality) and the number of RX descriptors are not changed, it's
not required to call bus_dmamem_{unmap,free}(). Even if we use workque, this
change save time of ixgbe_init().

  I have a code to fix broken watchdog timer but it sometime causes watchdog
timeout, so I don't commit it yet.


To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/sys/dev/pci/ixgbe/ix_txrx.c
cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe.h
cvs rdiff -u -r1.6 -r1.7 src/sys/dev/pci/ixgbe/ixgbe_netbsd.c
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/pci/ixgbe/ixgbe_netbsd.h
cvs rdiff -u -r1.21 -r1.22 src/sys/dev/pci/ixgbe/ixgbe_osdep.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.







--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

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 this commit 
was fine, but there was the mbuf used-after-free issue that hit me pretty hard. 
So the system wasn't running for too long anyway.

Does that ring a bell ?

Frank


 IMHO, this change doesn't cause such type of problem...

 Could you show me the following information?

 0) dmesg

This is required to know which chip is used and what type of
interrupt is used and configured (INTX, MSI or MSI-X).

 1) ifconfig -v ixg0

It's required to know offload status, the MTU size and some
error count.

 2) sysctl hw.ixg0 (or sysctl hw |grep ixg (for all ixg(4)s))

This output has some information of TX/RX ring.

 3) vmstat -e[v]

Only for ixg(4):
vmstat -e[v] |grep ixg

ixg(4) has a lot of counters. I added error counters at
all of error paths. (If you found a error path which has
no counter, it's my fault.)

Only to check checksum counters:

options INET_CSUM_COUNTERS (for ip_input())
options TCP_CSUM_COUNTERS  (for tcp_input())
options UDP_CSUM_COUNTERS  (for udp_input())
options WM_EVENT_COUNTERS  (only for wm(4))
options BGE_EVENT_COUNTERS (only for bge(4))
(No special options for ixg(4) because those counters are enabled by 
default)

vmstat -e[v] |grep csum

 4) If you use a virtual interface like vlan(4) or age(4). Please
show the configuration.


 Regards.


On 04/25/18 10:46, SAITOH Masanobu wrote:

Module Name:    src
Committed By:    msaitoh
Date:    Wed Apr 25 08:46:19 UTC 2018

Modified Files:
src/sys/dev/pci/ixgbe: ix_txrx.c ixgbe.h ixgbe_netbsd.c ixgbe_netbsd.h
    ixgbe_osdep.h

Log Message:
  Don't free and reallocate bus_dmamem when it's not required. Currently,
the watchdog timer is completely broken and never fire (it's from FreeBSD
(pre iflib)). If the problem is fixed and watchdog fired, ixgbe_init() always
calls ixgbe_jcl_reinit() and it causes panic. The reason is that
ixgbe_local_timer1(it includes watchdog function) is softint and
xgbe_jcl_reinit() calls bus_dmamem*() functions. bus_dmamem*() can't be called
from interrupt context.

  One of the way to prevent panic is use worqueue for the timer, but it's
not a small change. (I'll do it in future).

  Another way is not reallocate dmamem if it's not required. If both the MTU
(rx_mbuf_sz in reality) and the number of RX descriptors are not changed, it's
not required to call bus_dmamem_{unmap,free}(). Even if we use workque, this
change save time of ixgbe_init().

  I have a code to fix broken watchdog timer but it sometime causes watchdog
timeout, so I don't commit it yet.


To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/sys/dev/pci/ixgbe/ix_txrx.c
cvs rdiff -u -r1.45 -r1.46 src/sys/dev/pci/ixgbe/ixgbe.h
cvs rdiff -u -r1.6 -r1.7 src/sys/dev/pci/ixgbe/ixgbe_netbsd.c
cvs rdiff -u -r1.7 -r1.8 src/sys/dev/pci/ixgbe/ixgbe_netbsd.h
cvs rdiff -u -r1.21 -r1.22 src/sys/dev/pci/ixgbe/ixgbe_osdep.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

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
ixgbe_82599.h ixgbe_api.c ixgbe_api.h ixgbe_common.c ixgbe_common.h
ixgbe_dcb.c ixgbe_dcb.h ixgbe_dcb_82598.c ixgbe_dcb_82598.h
ixgbe_dcb_82599.c ixgbe_dcb_82599.h ixgbe_fdir.h ixgbe_mbx.c
ixgbe_mbx.h ixgbe_osdep.c ixgbe_osdep.h ixgbe_phy.c ixgbe_phy.h
ixgbe_rss.h ixgbe_sriov.h ixgbe_type.h ixgbe_vf.c ixgbe_vf.h
ixgbe_x540.c ixgbe_x540.h ixv.c

Log Message:
Sync with the remaining part of FreeBSD r328265 except sfp_reinit stuff:
  - Always schedule module intterrupt in ixgbe_config_link() when a device is
SFP+ based.
  - Use not loop index but txr->me in ixv_initialize_{transmit,receive}_units().
It's required for VMDQ but NetBSD doesn't use it, so it's not a bug in
NetBSD.
  - Simplify ixgbe_bp_wd_set(). No functional change.
  - Whitespace.


+ Call ixgbe_set_phy_power() in ixgbe_init_locked() to
make sure we are not in power save mode.


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev

[Masanobu SAITOH]

On 2018/03/01 14:04, m...@netbsd.org wrote:

On Wed, Feb 28, 2018 at 05:50:06AM +, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Wed Feb 28 05:50:06 UTC 2018

Modified Files:
src/sys/dev/acpi: acpi_mcfg.c
src/sys/dev/pci: pci_quirks.c pcivar.h

Log Message:
- Add new PCI quirk PCI_QUIRK_HASEXTCNF and PCI_QUIRK_NOEXTCNF. Some devices'
   extended configuration area may be broken or violate spec. If an extended
   configuration space is strange but it really exist, use PCI_QUIRK_HASEXTCNF.
   If an extended configuration space is plausible to exist but it really
   doesn't exist, use PCI_QUIRK_NOEXTCNF.
- Add PCI_PRODUCT_INTEL_XEOND_MEM_0_TTR_1(0x6fa8) and
   PCI_PRODUCT_INTEL_COREI76K_IMC_0(0x6f68) with PCI_QUIRK_HASEXTCNF. The
   document clearly states they violate spec and it support the extended
   configuration space.




this is causing ia64 builds to fail. they have acpi, but not pci
defined. then, pci_quirks.c is not built, and we get an undefined
reference:

http://releng.netbsd.org/builds/HEAD/201802282130Z/ia64.build.failed

acpi_mcfg.c sounds like a very pci-only thing, from commit history.
the following patch makes it explicitly a pci only thing, although I
haven't tried to boot it. Is this the right thing?


 IMHO, it would be OK.


With this change, I can build amd64 and ia64 kernels.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

On 2018/01/11 18:18, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Thu Jan 11 09:18:16 UTC 2018

Modified Files:
src/sys/arch/x86/x86: cpu.c

Log Message:
  Changing CR4 register may change cpuid values. For example, setting
CR4_OSXSAVE sets CPUID2_OSXSAVE. The CPUID2_OSXSAVE is in ci_feat_val[1],
so update it after changing CR4.


To generate a diff of this commit:
cvs rdiff -u -r1.144 -r1.145 src/sys/arch/x86/x86/cpu.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



XXX:
 - Other than ci_feat_val[1] might be changed.
 - Updating microcode may also changes cpuid values.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2017/11/30 12:53, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Thu Nov 30 03:53:24 UTC 2017

Modified Files:
src/sys/dev/pci: if_wm.c

Log Message:
  Don't allocate MSI-X interrupt on 82583. 82583 chip has a MSI-X capability in
the PCI configuration space but it doesn't support it. At least the document
doesn't say anything about MSI-X. Fixes PR#57262 reported by


s/57262/52767/


Shinichi Doyashiki.

XXX pullup-8.


To generate a diff of this commit:
cvs rdiff -u -r1.544 -r1.545 src/sys/dev/pci/if_wm.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

On 2017/11/23 0:15, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Wed Nov 22 15:15:09 UTC 2017

Modified Files:
src/sys/dev/pci/ixgbe: if_bypass.c ixgbe.c ixgbe.h

Log Message:
Fix a bug that bypass adapter's sysctls aren't set. Tested with non-genuine
X550-T2 bypass adapter:


 s/X550/X540/


- Call ixgbe_sysctl_instance() in ixgbe_bypass_init() to get sysctl's top node
   correctly.
- ixgbe_init_device_features() refers adapter->hw.bus.func for bypass adapter.
   Call set_lan_id() to set adapter->hw.bus.func before calling
   ixgbe_init_device_features(). Without this, bypass sysctl's are added to
   both the first and second port.
- Initalize node.sysctl_data before calling sysctl_lookup() to read correct
   value.


To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.2 src/sys/dev/pci/ixgbe/if_bypass.c
cvs rdiff -u -r1.112 -r1.113 src/sys/dev/pci/ixgbe/ixgbe.c
cvs rdiff -u -r1.27 -r1.28 src/sys/dev/pci/ixgbe/ixgbe.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/net

[Masanobu SAITOH]

On 2017/11/22 14:40, Robert Elz wrote:

 Date:Wed, 22 Nov 2017 04:56:52 +
 From:"SAITOH Masanobu" 
 Message-ID:  <20171122045652.2ee75f...@cvs.netbsd.org>

   |  Return EINVAL in vlan_config() when a VLAN ID is 0 or 65535.
   |  The spec states 0 and 65535 are reserved.

Tags are 12 bigs, so 0..4095 (65535 won't fit).   The code that was
added in this commit looks correct (0xfff - it would be better as a
named const defined somewhere) but the comment that accompanies it
(and this commit log entry) are not.


Yes, you're correct. I fixed the comment.

 Thanks.


kre




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/sys

[Masanobu SAITOH]

On 2017/10/23 18:35, SAITOH Masanobu wrote:

Welcome to 8.99.4


s/8.99.4/8.99.5/

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev - lm(4)

[Masanobu SAITOH]

Hi.

On 2017/07/16 9:44, Paul Goyette wrote:

Module Name:src
Committed By:   msaitoh
Date:   Tue Jul 11 10:10:51 UTC 2017

Modified Files:
src/sys/dev/ic: nslm7x.c nslm7xvar.h
src/sys/dev/isa: wbsio.c wbsioreg.h

Log Message:
lm(4): Add suport for NCT5174D, NCT6775F, NCT6779D and NCT679[1235]D.
wbsio(4): Add support for NCT6795D.



Are you sure about the various RFACT values?


Tested only on two machines. One is NCT6779D and another is NCT6792D.
And, only 5V, 3.3V(,SB) and VBAT were tested. Nuvoton's voltage I/O is for
+-2.0V, It's required to use appropriate pullup/pulldown registers to
get correct vaules. There is no way to get the register factors by
software. I think we can change the "default" register factors better
than now.




 I'm getting some very
strange voltage readings from this device, as well as some odd fan
speeds.  Interestingly, most of the reported temperature values seem
reasonable, although there may be one entry missing (the BIOS reports
on seven temperatures, but envstat shows only six).

 From dmesg we see:

...
wbsio0 at isa0 port 0x2e-0x2f: Nuvoton LPC Super I/O NCT6791D rev 0x03
...
lm0 at wbsio0 port 0x290-0x297
lm0: Using default temp sensors
lm0: Nuvoton NCT6791D Hardware monitor
...


And here is what envstat reports on my system:

# envstat -d lm0
Current  CritMax  WarnMax  WarnMin  CritMin  Unit
   VCore: 0.888 V
VIN1: 6.653 V
AVCC: 3.328 V
   +3.3V: 3.328 V
VIN0:11.814 V
VIN8:   N/A
VIN4: 0.784 V
 +3.3VSB: 3.456 V
VBAT: 3.392 V
 VTT: 2.096 V
VIN5: 1.440 V
VIN6: 0.624 V
VIN2: 0.592 V
VIN3: 1.602 V
VIN7: 0.744 V
  MB Temperature:35.000  degC
CPU Temperature:43.000  degC
   Aux Temp0:80.000  degC
   Aux Temp1:42.000  degC
   Aux Temp2:82.000  degC
   Aux Temp3:40.000  degC
  System Fan: 14088   RPM
 CPU Fan: 11030   RPM
Aux Fan0:   N/A
Aux Fan1:   N/A
Aux Fan2:   N/A


According to the Motherboard/BIOS monitoring page,

CoreV  =   1.021V
 3.3V  =   3.328V   You got this one right!
   5V  =   5.040V   This might be VIN1?
  12V  =  12.096V   And this might be VIN0?
  DRAMV/AB =   1.199V
  DRAMV/CD =   1.198V

 MoBo Temp =  37C
  CPU Temp =  44C
 PCIE16_1 Temp =  42C   (perhaps these are the Aux Temps?
 PCIE16_2 Temp =  41C   At least two out of three values
 PCIE16_3 Temp =  41C   are reasonable.)
  VRM Temp =  47C
  PCH Temp =  48C

   CPU Fan = 1035 RPM   (1K, not 10K!)


 Before my commit, only NCT6776F was supported. I don't know
that code was correct or not. It would be good to see linux's
drivers/hwmon/nct6775.c. I've not read whole of the code yet...


   CPU Opt Fan = 1363 RPM
 Chassis-1 Fan =  785 RPM

(It's not clear whether envstat's "System Fan" corresponds to the "CPU Opt Fan" or to 
"Chassis-1 Fan"; the BIOS reports three fan values but envstat only has two valid values.)


+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++



--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/dev/pci/ixgbe

[Masanobu SAITOH]

On 2017/06/27 19:33, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Tue Jun 27 10:33:09 UTC 2017

Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c

Log Message:
  Fix a bug of ixg(4)'s media setting.

Before:
  ifconfig ixg0 media 100baseTX -> advertise 100Mbps only
  ifconfig ixg0 media 1000baseT -> advertise 1Gbps and 1000Mbps (NG)


s/1000Mbps/100Mbps/


  ifconfig ixg0 media 10Gbase-T -> advertise all (NG)
  ifconfig ixg0 media auto  -> advertise all

After:
  ifconfig ixg0 media 100baseTX -> advertise 100Mbps only
  ifconfig ixg0 media 1000baseT -> advertise 1Gbps only
  ifconfig ixg0 media 10Gbase-T -> advertise 10Gbps only
  ifconfig ixg0 media auto  -> advertise all


To generate a diff of this commit:
cvs rdiff -u -r1.93 -r1.94 src/sys/dev/pci/ixgbe/ixgbe.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2016/11/28 11:23, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Mon Nov 28 02:23:33 UTC 2016

Modified Files:
src/sys/dev/pci: files.pci
src/sys/dev/pci/ixgbe: ixgbe.c ixgbe.h
Added Files:
src/sys/dev/pci/ixgbe: ix_txrx.c

Log Message:
 FreeBSD r280181 made new file ix_txrx.c and moved ixgbe.c and ixv's common


s/r280181/r280182/


code into it. Before sync with whole of them, just move ixgbe.c and ixv.c's
common code into ix_txrx.c from ixgbe.c. In this commit, only ixgbe.c is split
into the device dependent part and the common part. ixv.c isn't change to make
this commit no functional change. To use ixv.c with ix_txrx.c, it's required
to modify the common part's API and functions themselves.

 This commit is done to make the next change easy to understand.


To generate a diff of this commit:
cvs rdiff -u -r1.382 -r1.383 src/sys/dev/pci/files.pci
cvs rdiff -u -r0 -r1.1 src/sys/dev/pci/ixgbe/ix_txrx.c
cvs rdiff -u -r1.41 -r1.42 src/sys/dev/pci/ixgbe/ixgbe.c
cvs rdiff -u -r1.9 -r1.10 src/sys/dev/pci/ixgbe/ixgbe.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch

[Masanobu SAITOH]

Hi!

On 2016/11/19 18:22, Maxime Villard wrote:

Module Name:src
Committed By:   maxv
Date:   Sat Nov 19 09:22:04 UTC 2016

Modified Files:
src/sys/arch/amd64/include: vmparam.h
src/sys/arch/i386/include: vmparam.h

Log Message:
Put a one-page redzone between userland and the PTE space on amd64 and
i386.

The PTE space is a critical region that maps the page tree, and bugs have
been found in both amd64 and i386 where the kernel would wrongly overflow
userland data on this area. This kind of bug is terrible, since it allows
userland to overwrite some entries of the page tree, which makes it easy
to patch the kernel text and get ring0 privileges.


To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/sys/arch/amd64/include/vmparam.h
cvs rdiff -u -r1.82 -r1.83 src/sys/arch/i386/include/vmparam.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


My emacs dumps core with change.

What should we do?

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2016/09/19 11:00, Ryo ONODERA wrote:

Hi,

With this change, the following wm(4) device links in 10BASE-T when it
is connected to 100BASE or 1000BASE hub.


Could you show me the dmesg of wm and *phy?

Thanks in advance.





From: "SAITOH Masanobu" , Date: Fri, 9 Sep 2016 06:34:10 
+


Module Name:src
Committed By:   msaitoh
Date:   Fri Sep  9 06:34:10 UTC 2016

Modified Files:
src/sys/dev/mii: inbmphyreg.h

Log Message:
 HV_OEM_BITS is not page 0 but page 768.


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/sys/dev/mii/inbmphyreg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



--
Ryo ONODERA // ryo...@yk.rim.or.jp
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-7] src/sys/sys

[Masanobu SAITOH]

Hi.

On 2016/03/07 17:59, Takeshi Nakayama wrote:

"SAITOH Masanobu"  wrote



Module Name:src
Committed By:   msaitoh
Date:   Mon Mar  7 08:08:52 UTC 2016

Modified Files:
src/sys/sys [netbsd-7]: exec_elf.h

Log Message:
Pullup the following revision (requested by htodd in ticket #1132):

sys/sys/exec_elf.h  1.143

Add definition of EM_IAMCU. This change fixes build break caused by
ticket 1126.


Wrong commit message?  This is for 1.153 not 1.143.


Sorry. Yo're right. I'll fix the commit message and doc/CHANGES-7.1



-- Takeshi Nakayama




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

On 2015/10/06 6:10, Jean-Yves Migeon wrote:

Le 04/10/2015 19:52, matthew green a écrit :

Module Name:src
Committed By:   mrg
Date:   Sun Oct  4 17:52:50 UTC 2015

Modified Files:
src/sys/arch/x86/x86: cpu_ucode_intel.c

Log Message:
kmem_free() the address returned by kmem_alloc().  found by Brainy.
use the newly aligned location if we needed it.  found by kre.


To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/sys/arch/x86/x86/cpu_ucode_intel.c


IMHO this should be pulled-up to -6 and -7.

Any argument against? If the old code worked, it's pure luck.


 netbsd-6 doesn't support the microcode update function for Intel
CPU. That bug should be pulled up to netbsd-7 (and netbsd-7-1) branch.


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/pci

[Masanobu SAITOH]

On 2015/08/13 13:52, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Thu Aug 13 04:52:40 UTC 2015

Modified Files:
src/sys/arch/x86/pci: msipic.c

Log Message:
  Add workaround for PCI prefetchable bit in msipic_construct_msix_pic().
Some chips (e.g. Intel 82599) report SERR and MSI-X interrupt doesn't work.
This problem might not be the driver's bug but our PCI common part or VMs'
bug. See fxp(4), ixgbe(4) and ixgbe(4). All of them has the same workaround


s/ixgbe(4) and ixgbe(4)/bge(4) and ixgbe(4)/


related to prefetchable bit. For the MSI-X table area, it should not have side
effect by prefetching. Until we find a real reason, we ignore the prefetchable
bit.


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/sys/arch/x86/pci/msipic.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2015/06/14 5:42, Christos Zoulas wrote:
 In article 20150613154758.6971...@cvs.netbsd.org,
 SAITOH Masanobu source-changes-d@NetBSD.org wrote:
 -=-=-=-=-=-

 Module Name: src
 Committed By:msaitoh
 Date:Sat Jun 13 15:47:58 UTC 2015

 Modified Files:
  src/sys/dev/pci: if_wm.c if_wmreg.h

 Log Message:
 Add MSI/MSI-X support written by Kengo Nakahara. Some old devices' support
 is written by me. It's disabled by default. If you'd like to use, define
 WM_MSI_MSIX.

 Tested with:
  8254[3405617] (INTx even if it has MSI CAP because of a errata)
  8257[12], 82583 ICH8, ICH10, PCH2, PCH_LPT(I21[78]) (MSI)
  8257[456], 82580, I35[04], I21[01] (MSI-X)

 Not tested:
  82542, 82573, 80003, ICH9, PCH,

 
 I had raised quite a few issues about calcifying this interrupt API,
 also copying the code 3 times...
 
 christos

 I thought it's not required to wait API was fixed and committed.

 To support only MSI is easy, but MSI-X is not. This commit includes not
only pci_intr_establish() stuff but also include other MSI-X stuff to setup
MSI-X vector table and interrupt related functions. And, it'll take time
to check regression or stability to make it enable by default, so it's
important other people to test with it.

 The same work will be required for RAID controllders' drviers.

 Thanks.

-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

On 2015/05/18 22:09, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Mon May 18 13:09:55 UTC 2015

Modified Files:
src/sys/arch/x86/x86: cpu.c

Log Message:
  PS. Revert previous.


To generate a diff of this commit:
cvs rdiff -u -r1.114 -r1.115 src/sys/arch/x86/x86/cpu.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


 Sorry. I accidentally committed my test implementation to support
Intel rdrand instruction for rnd(4). That feasture should be attached
as a driver via cpufeature bus.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

On 2015/05/01 1:09, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Thu Apr 30 16:09:06 UTC 2015

Modified Files:
src/sys/dev/pci: if_bge.c if_bgereg.h

Log Message:
  Use another firmware command in bge_asf_driver_up(). This change fixes
a bug that watchdog timeout occurs every 20-30 minutes on HP ML110 G6
reported enami@ in PR#49657.


 The value of this command is the same as Linux.
I've cvs admin-ed now.



To generate a diff of this commit:
cvs rdiff -u -r1.284 -r1.285 src/sys/dev/pci/if_bge.c
cvs rdiff -u -r1.89 -r1.90 src/sys/dev/pci/if_bgereg.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

Hi, Martin.

On 2015/04/06 16:38, Martin Husemann wrote:

Module Name:src
Committed By:   martin
Date:   Mon Apr  6 07:38:17 UTC 2015

Modified Files:
src/sys/dev/pci: if_bge.c

Log Message:
Make sure to halt (not just stop) the bge_tick callout during detach.


To generate a diff of this commit:
cvs rdiff -u -r1.280 -r1.281 src/sys/dev/pci/if_bge.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


What does this change fix? To prevent panic on shutdown?

Almost all drviers have the same code. Should we fix all of them
like this?

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/kern

[Masanobu SAITOH]

Hi

On 2015/02/08 23:46, Michael van Elst wrote:

Module Name:src
Committed By:   mlelstv
Date:   Sun Feb  8 14:46:30 UTC 2015

Modified Files:
src/sys/kern: uipc_mbuf.c

Log Message:
Correct m_len calculation for m_dup() with mbuf clusters.
Fixes kern/49650.


To generate a diff of this commit:
cvs rdiff -u -r1.160 -r1.161 src/sys/kern/uipc_mbuf.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


It restored only one of four deletion of m_len = 0

The original was rev. 1.153:


http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_mbuf.c.diff?r1=1.152r2=1.153f=h

Other three were also used after MGET() or MCLGET().
Should we restore them, too?


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/kern

[Masanobu SAITOH]

On 2015/02/09 13:27, Masanobu SAITOH wrote:

Hi

On 2015/02/08 23:46, Michael van Elst wrote:

Module Name:src
Committed By:mlelstv
Date:Sun Feb  8 14:46:30 UTC 2015

Modified Files:
src/sys/kern: uipc_mbuf.c

Log Message:
Correct m_len calculation for m_dup() with mbuf clusters.
Fixes kern/49650.


To generate a diff of this commit:
cvs rdiff -u -r1.160 -r1.161 src/sys/kern/uipc_mbuf.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


It restored only one of four deletion of m_len = 0

The original was rev. 1.153:

 
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_mbuf.c.diff?r1=1.152r2=1.153f=h

Other three were also used after MGET() or MCLGET().
Should we restore them, too?


 Oh, sorry. I understood that m-m_len = 0 is done in m_get().

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-6] src/lib/libperfuse

[Masanobu SAITOH]

On 2014/11/04 10:27, Takahiro Kambe wrote:

Hi,

In message 20141103194010.711b...@cvs.netbsd.org
on Mon, 3 Nov 2014 19:40:10 +,
SAITOH Masanobu msai...@netbsd.org wrote:

Module Name:src
Committed By:   msaitoh
Date:   Mon Nov  3 19:40:10 UTC 2014

Modified Files:
src/lib/libperfuse [netbsd-6]: ops.c

Log Message:
Pull up following revision(s) (requested by manu in ticket #1148):
lib/libperfuse/ops.c: revision 1.73
rmdir dir/.. must return an error. Use ENOTEMPTY like FFS does.


To generate a diff of this commit:
cvs rdiff -u -r1.50.2.10 -r1.50.2.11 src/lib/libperfuse/ops.c

I need to changes to build successfully.


Yes. It's ticket #1153. I'm now verifying the fix.

Please wait a little.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-6] src/lib/libperfuse

[Masanobu SAITOH]

On 2014/11/04 10:46, Takahiro Kambe wrote:

In message 54582cea.5060...@execsw.org
on Tue, 04 Nov 2014 10:33:30 +0900,
Masanobu SAITOH msai...@execsw.org wrote:

I need to changes to build successfully.


Yes. It's ticket #1153. I'm now verifying the fix.

Ah, I see and thanks!


Fixed now!

Thanks.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/usr.sbin/sysinst

[Masanobu SAITOH]

 Hi, Martin.

On 2014/08/04 1:09, Martin Husemann wrote:

Module Name:src
Committed By:   martin
Date:   Sun Aug  3 16:09:41 UTC 2014

Modified Files:
src/usr.sbin/sysinst: Makefile.inc bsddisklabel.c configmenu.c defs.h
disks.c install.c label.c main.c mbr.c menus.mi msg.mbr.de


 This change breaks build on some archs.

http://releng.netbsd.org/builds/HEAD/201408032310Z/

For amigappc:
http://releng.netbsd.org/builds/HEAD/201408032310Z/amigappc.build.failed


/home/source/ab/HEAD/src/usr.sbin/sysinst/arch/dummy/../../disks.c: In function 
'make_fstab':
/home/source/ab/HEAD/src/usr.sbin/sysinst/arch/dummy/../../disks.c:826:13: 
error: 'pm_with_swap' may be used uninitialized in this function
--- disks.o ---
*** [disks.o] Error code 1


 HAVE_TMPFS isn't set on some archs.

 Could you fix this problem?



msg.mbr.en msg.mbr.es msg.mbr.fr msg.mbr.pl msg.mi.de msg.mi.en
msg.mi.es msg.mi.fr msg.mi.pl net.c run.c savenewlabel.c
sizemultname.c target.c upgrade.c util.c
src/usr.sbin/sysinst/arch/acorn32: md.c
src/usr.sbin/sysinst/arch/alpha: md.c
src/usr.sbin/sysinst/arch/amiga: md.c
src/usr.sbin/sysinst/arch/arc: md.c
src/usr.sbin/sysinst/arch/atari: md.c
src/usr.sbin/sysinst/arch/bebox: md.c
src/usr.sbin/sysinst/arch/cats: md.c
src/usr.sbin/sysinst/arch/cobalt: md.c
src/usr.sbin/sysinst/arch/emips: md.c
src/usr.sbin/sysinst/arch/evbarm: md.c
src/usr.sbin/sysinst/arch/evbmips: md.c
src/usr.sbin/sysinst/arch/evbppc: md.c
src/usr.sbin/sysinst/arch/evbsh3: md.c
src/usr.sbin/sysinst/arch/ews4800mips: md.c
src/usr.sbin/sysinst/arch/hp300: md.c
src/usr.sbin/sysinst/arch/hpcarm: md.c
src/usr.sbin/sysinst/arch/hpcmips: md.c
src/usr.sbin/sysinst/arch/hpcsh: md.c
src/usr.sbin/sysinst/arch/hppa: md.c
src/usr.sbin/sysinst/arch/i386: md.c
src/usr.sbin/sysinst/arch/landisk: md.c
src/usr.sbin/sysinst/arch/luna68k: md.c
src/usr.sbin/sysinst/arch/mac68k: md.c menus.md.de menus.md.en
menus.md.es menus.md.pl
src/usr.sbin/sysinst/arch/macppc: md.c
src/usr.sbin/sysinst/arch/mipsco: md.c
src/usr.sbin/sysinst/arch/mvme68k: md.c
src/usr.sbin/sysinst/arch/news68k: md.c
src/usr.sbin/sysinst/arch/newsmips: md.c
src/usr.sbin/sysinst/arch/ofppc: md.c
src/usr.sbin/sysinst/arch/playstation2: md.c msg.md.de msg.md.en
msg.md.es msg.md.fr msg.md.pl
src/usr.sbin/sysinst/arch/pmax: md.c
src/usr.sbin/sysinst/arch/prep: md.c
src/usr.sbin/sysinst/arch/sandpoint: md.c
src/usr.sbin/sysinst/arch/sgimips: md.c
src/usr.sbin/sysinst/arch/shark: md.c
src/usr.sbin/sysinst/arch/sparc: md.c
src/usr.sbin/sysinst/arch/sparc64: md.c
src/usr.sbin/sysinst/arch/vax: md.c
src/usr.sbin/sysinst/arch/x68k: md.c
src/usr.sbin/sysinst/arch/zaurus: md.c
Added Files:
src/usr.sbin/sysinst: partman.c

Log Message:
(Finally) merge a slightly modified version of the 2012 GSoC results
from Eugene Lozovoy: add extended partitioning options to sysinst.
Still needs some testing and polishing, but it now is possible to use GPT
or to create a RAID set from scratch and install onto it.


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/usr.sbin/sysinst/Makefile.inc
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/bsddisklabel.c \
 src/usr.sbin/sysinst/configmenu.c src/usr.sbin/sysinst/defs.h \
 src/usr.sbin/sysinst/disks.c src/usr.sbin/sysinst/install.c \
 src/usr.sbin/sysinst/label.c src/usr.sbin/sysinst/main.c \
 src/usr.sbin/sysinst/mbr.c src/usr.sbin/sysinst/menus.mi \
 src/usr.sbin/sysinst/msg.mbr.de src/usr.sbin/sysinst/msg.mbr.en \
 src/usr.sbin/sysinst/msg.mbr.es src/usr.sbin/sysinst/msg.mbr.fr \
 src/usr.sbin/sysinst/msg.mbr.pl src/usr.sbin/sysinst/msg.mi.de \
 src/usr.sbin/sysinst/msg.mi.en src/usr.sbin/sysinst/msg.mi.es \
 src/usr.sbin/sysinst/msg.mi.fr src/usr.sbin/sysinst/msg.mi.pl \
 src/usr.sbin/sysinst/net.c src/usr.sbin/sysinst/run.c \
 src/usr.sbin/sysinst/savenewlabel.c src/usr.sbin/sysinst/sizemultname.c \
 src/usr.sbin/sysinst/target.c src/usr.sbin/sysinst/upgrade.c \
 src/usr.sbin/sysinst/util.c
cvs rdiff -u -r0 -r1.1 src/usr.sbin/sysinst/partman.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/acorn32/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/alpha/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/amiga/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/arc/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/atari/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/bebox/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/cats/md.c
cvs rdiff -u -r1.1 -r1.2 src/usr.sbin/sysinst/arch/cobalt/md.c
cvs rdiff -u -r1.1 -r1.2 

Re: CVS commit: [netbsd-6-0] src/sys

[Masanobu SAITOH]

Hi, Erik.

(2014/06/23 7:15), Manuel Bouyer wrote:

On Sun, Jun 22, 2014 at 02:30:42PM -0700, Erik Fair wrote:

It appears that these changes were applied to netbsd-6-0 and netbsd-6-1 but not to 
netbsd-6 (which is a problem for those of us following netbsd-6).



AFAIK it was pulled up on Jun 3 on -6. As it's a bit invasive I suggested
to wait a bit before pulling up to 6-0 and 6-1.


 Right. I used netbsd-6 kernel with that patch for two
weeks and I had not gotten any problem, so I pulled up
the change to netbsd-6-1 and netbsd-6-0.

You can see the discussion in:

 http://releng.netbsd.org/cgi-bin/req-6.cgi?show=1067

 Thanks.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-5] xsrc

[Masanobu SAITOH]

(2014/05/14 14:24), SAITOH Masanobu wrote:

Module Name:xsrc
Committed By:   msaitoh
Date:   Wed May 14 05:24:26 UTC 2014

Modified Files:
xsrc/external/mit/libXfont/dist/src/fc [netbsd-5]: fsconvert.c fserve.c
xsrc/external/mit/libXfont/dist/src/fontfile [netbsd-5]: dirfile.c
xsrc/xfree/xc/lib/font/fc [netbsd-5]: fsconvert.c fserve.c
xsrc/xfree/xc/lib/font/fontfile [netbsd-5]: dirfile.c

Log Message:
Pull up following revision(s) (requested by maxv in ticket #1905):
src/sys/compat/linux/common/linux_exec_elf32.c  1.91 via patch

A specially-crafted binary could easily control a kernel array index.
Add some checks to ensure that nothing will be read outside the allocated
area. Rewrite the code so that we don't need to allocate the whole section.

Spotted by several developers, patch from chs@/enami@


To generate a diff of this commit:
cvs rdiff -u -r1.1.1.1.2.1 -r1.1.1.1.2.2 \
 xsrc/external/mit/libXfont/dist/src/fc/fsconvert.c \
 xsrc/external/mit/libXfont/dist/src/fc/fserve.c
cvs rdiff -u -r1.1.1.1.2.1 -r1.1.1.1.2.2 \
 xsrc/external/mit/libXfont/dist/src/fontfile/dirfile.c
cvs rdiff -u -r1.4 -r1.4.20.1 xsrc/xfree/xc/lib/font/fc/fsconvert.c \
 xsrc/xfree/xc/lib/font/fc/fserve.c
cvs rdiff -u -r1.4 -r1.4.8.1 xsrc/xfree/xc/lib/font/fontfile/dirfile.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


 Sorry, this commit message was wrong. I fixed the message
with cvs admin -m.


Pull up following revision(s) (requested by spz in ticket #1905):
xsrc/external/mit/libXfont/dist/src/fc/fsconvert.c  1.2
xsrc/external/mit/libXfont/dist/src/fc/fserve.c 1.2
xsrc/external/mit/libXfont/dist/src/fontfile/dirfile.c  1.2
xsrc/xfree/xc/lib/font/fc/fsconvert.c   1.5
xsrc/xfree/xc/lib/font/fc/fserve.c  1.5
xsrc/xfree/xc/lib/font/fontfile/dirfile.c   1.5

Fix multiple vulnerabilities in libXfont:

- CVE-2014-0209: integer overflow of allocations in font metadata file parsing

 When a local user who is already authenticated to the X server adds
 a new directory to the font path, the X server calls libXfont to open
 the fonts.dir and fonts.alias files in that directory and add entries
 to the font tables for every line in it.  A large file (~2-4 gb) could
 cause the allocations to overflow, and allow the remaining data read
 from the file to overwrite other memory in the heap.

 Affected functions: FontFileAddEntry(), lexAlias()

- CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies

 When parsing replies received from the font server, these calls do not
 check that the lengths and/or indexes returned by the font server are
 within the size of the reply or the bounds of the memory allocated to
 store the data, so could write past the bounds of allocated memory when
 storing the returned data.

 Affected functions: _fs_recv_conn_setup(), fs_read_open_font(),
 fs_read_query_info(), fs_read_extent_info(), fs_read_glyphs(),
 fs_read_list(), fs_read_list_info()

- CVE-2014-0211: integer overflows calculating memory needs for xfs replies

 These calls do not check that their calculations for how much memory
 is needed to handle the returned data have not overflowed, so can

 result in allocating too little memory and then writing the returned
 data past the end of the allocated buffer.

 Affected functions: fs_get_reply(), fs_alloc_glyphs(),
 fs_read_extent_info()

See also: http://lists.x.org/archives/xorg-announce/2014-May/002431.html



--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-5-1] xsrc

[Masanobu SAITOH]

(2014/05/14 14:26), SAITOH Masanobu wrote:

Module Name:xsrc
Committed By:   msaitoh
Date:   Wed May 14 05:26:15 UTC 2014

Modified Files:
xsrc/external/mit/libXfont/dist/src/fc [netbsd-5-1]: fsconvert.c
fserve.c
xsrc/external/mit/libXfont/dist/src/fontfile [netbsd-5-1]: dirfile.c
xsrc/xfree/xc/lib/font/fc [netbsd-5-1]: fsconvert.c fserve.c
xsrc/xfree/xc/lib/font/fontfile [netbsd-5-1]: dirfile.c

Log Message:
Pull up following revision(s) (requested by maxv in ticket #1905):
src/sys/compat/linux/common/linux_exec_elf32.c  1.91 via patch

A specially-crafted binary could easily control a kernel array index.
Add some checks to ensure that nothing will be read outside the allocated
area. Rewrite the code so that we don't need to allocate the whole section.

Spotted by several developers, patch from chs@/enami@


To generate a diff of this commit:
cvs rdiff -u -r1.1.1.1.2.1 -r1.1.1.1.2.1.2.1 \
 xsrc/external/mit/libXfont/dist/src/fc/fsconvert.c \
 xsrc/external/mit/libXfont/dist/src/fc/fserve.c
cvs rdiff -u -r1.1.1.1.2.1 -r1.1.1.1.2.1.2.1 \
 xsrc/external/mit/libXfont/dist/src/fontfile/dirfile.c
cvs rdiff -u -r1.4 -r1.4.24.1 xsrc/xfree/xc/lib/font/fc/fsconvert.c \
 xsrc/xfree/xc/lib/font/fc/fserve.c
cvs rdiff -u -r1.4 -r1.4.12.1 xsrc/xfree/xc/lib/font/fontfile/dirfile.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



The same as netbsd-5, this commit message was wrong. I fixed the message
with cvs admin -m.


Pull up following revision(s) (requested by spz in ticket #1905):
xsrc/external/mit/libXfont/dist/src/fc/fsconvert.c  1.2
xsrc/external/mit/libXfont/dist/src/fc/fserve.c 1.2
xsrc/external/mit/libXfont/dist/src/fontfile/dirfile.c  1.2
xsrc/xfree/xc/lib/font/fc/fsconvert.c   1.5
xsrc/xfree/xc/lib/font/fc/fserve.c  1.5
xsrc/xfree/xc/lib/font/fontfile/dirfile.c   1.5

Fix multiple vulnerabilities in libXfont:

- CVE-2014-0209: integer overflow of allocations in font metadata file parsing

 When a local user who is already authenticated to the X server adds
 a new directory to the font path, the X server calls libXfont to open
 the fonts.dir and fonts.alias files in that directory and add entries
 to the font tables for every line in it.  A large file (~2-4 gb) could
 cause the allocations to overflow, and allow the remaining data read
 from the file to overwrite other memory in the heap.

 Affected functions: FontFileAddEntry(), lexAlias()

- CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies

 When parsing replies received from the font server, these calls do not
 check that the lengths and/or indexes returned by the font server are
 within the size of the reply or the bounds of the memory allocated to
 store the data, so could write past the bounds of allocated memory when
 storing the returned data.

 Affected functions: _fs_recv_conn_setup(), fs_read_open_font(),
 fs_read_query_info(), fs_read_extent_info(), fs_read_glyphs(),
 fs_read_list(), fs_read_list_info()

- CVE-2014-0211: integer overflows calculating memory needs for xfs replies

 These calls do not check that their calculations for how much memory
 is needed to handle the returned data have not overflowed, so can

 result in allocating too little memory and then writing the returned
 data past the end of the allocated buffer.

 Affected functions: fs_get_reply(), fs_alloc_glyphs(),
 fs_read_extent_info()

See also: http://lists.x.org/archives/xorg-announce/2014-May/002431.html


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: [netbsd-5-2] xsrc

[Masanobu SAITOH]

(2014/05/14 14:27), SAITOH Masanobu wrote:

Module Name:xsrc
Committed By:   msaitoh
Date:   Wed May 14 05:27:33 UTC 2014

Modified Files:
xsrc/external/mit/libXfont/dist/src/fc [netbsd-5-2]: fsconvert.c
fserve.c
xsrc/external/mit/libXfont/dist/src/fontfile [netbsd-5-2]: dirfile.c
xsrc/xfree/xc/lib/font/fc [netbsd-5-2]: fsconvert.c fserve.c
xsrc/xfree/xc/lib/font/fontfile [netbsd-5-2]: dirfile.c

Log Message:
Pull up following revision(s) (requested by maxv in ticket #1905):
src/sys/compat/linux/common/linux_exec_elf32.c  1.91 via patch

A specially-crafted binary could easily control a kernel array index.
Add some checks to ensure that nothing will be read outside the allocated
area. Rewrite the code so that we don't need to allocate the whole section.

Spotted by several developers, patch from chs@/enami@


To generate a diff of this commit:
cvs rdiff -u -r1.1.1.1.2.1 -r1.1.1.1.2.1.4.1 \
 xsrc/external/mit/libXfont/dist/src/fc/fsconvert.c \
 xsrc/external/mit/libXfont/dist/src/fc/fserve.c
cvs rdiff -u -r1.1.1.1.2.1 -r1.1.1.1.2.1.4.1 \
 xsrc/external/mit/libXfont/dist/src/fontfile/dirfile.c
cvs rdiff -u -r1.4 -r1.4.30.1 xsrc/xfree/xc/lib/font/fc/fsconvert.c \
 xsrc/xfree/xc/lib/font/fc/fserve.c
cvs rdiff -u -r1.4 -r1.4.18.1 xsrc/xfree/xc/lib/font/fontfile/dirfile.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



The same as netbsd-5, this commit message was wrong. I fixed the message
with cvs admin -m.


Pull up following revision(s) (requested by spz in ticket #1905):
xsrc/external/mit/libXfont/dist/src/fc/fsconvert.c  1.2
xsrc/external/mit/libXfont/dist/src/fc/fserve.c 1.2
xsrc/external/mit/libXfont/dist/src/fontfile/dirfile.c  1.2
xsrc/xfree/xc/lib/font/fc/fsconvert.c   1.5
xsrc/xfree/xc/lib/font/fc/fserve.c  1.5
xsrc/xfree/xc/lib/font/fontfile/dirfile.c   1.5

Fix multiple vulnerabilities in libXfont:

- CVE-2014-0209: integer overflow of allocations in font metadata file parsing

 When a local user who is already authenticated to the X server adds
 a new directory to the font path, the X server calls libXfont to open
 the fonts.dir and fonts.alias files in that directory and add entries
 to the font tables for every line in it.  A large file (~2-4 gb) could
 cause the allocations to overflow, and allow the remaining data read
 from the file to overwrite other memory in the heap.

 Affected functions: FontFileAddEntry(), lexAlias()

- CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies

 When parsing replies received from the font server, these calls do not
 check that the lengths and/or indexes returned by the font server are
 within the size of the reply or the bounds of the memory allocated to
 store the data, so could write past the bounds of allocated memory when
 storing the returned data.

 Affected functions: _fs_recv_conn_setup(), fs_read_open_font(),
 fs_read_query_info(), fs_read_extent_info(), fs_read_glyphs(),
 fs_read_list(), fs_read_list_info()

- CVE-2014-0211: integer overflows calculating memory needs for xfs replies

 These calls do not check that their calculations for how much memory
 is needed to handle the returned data have not overflowed, so can

 result in allocating too little memory and then writing the returned
 data past the end of the allocated buffer.

 Affected functions: fs_get_reply(), fs_alloc_glyphs(),
 fs_read_extent_info()

See also: http://lists.x.org/archives/xorg-announce/2014-May/002431.html



--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/evbarm/conf

[Masanobu SAITOH]

Hi.

(2014/04/05 7:09), matthew green wrote:
 SAITOH Masanobu writes:
 Module Name: src
 Committed By:msaitoh
 Date:Fri Apr  4 07:55:25 UTC 2014

 Modified Files:
  src/sys/arch/evbarm/conf: OPENRD

 Log Message:
 Delete COMPAT_NETBSD32 option
 
 hmm, why?  this makes old-arm and eabi userlands both possible with
 the same kernel.

 Is the problem same as the following mail?

http://mail-index.netbsd.org/port-arm/2014/04/02/msg002317.html

 I had not known that problem. I had thought that the option was added
for 64bit ARM support.

 Before I committed the change, only evbarm/conf/OPENRD set COMPAT_NETBSD32.
Now, all configuration files of evbarm don't set COMPAT_NETBSD32.

 Feel free to fix it :)

 .mrg.


-- 
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

  * 英語 - 自動検出
  * 英語
  * 日本語

  * 英語
  * 日本語

 javascript:void(0); #

Re: CVS commit: src/sys

[Masanobu SAITOH]

(2014/01/26 19:54), SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Sun Jan 26 10:54:24 UTC 2014

Modified Files:
src/sys/arch/x86/pci: pci_machdep.c
src/sys/arch/x86/x86: consinit.c
src/sys/dev/pci: files.pci puccn.c puccn.h

Log Message:
PUCCN improvements:
  - Fix a bug that the puc cn mechanism doesn't use the UART's frequency
in pucdata.c's table.

  - Add a new option PUC_CNAUTO. If this option is set, consinit() in
x86/x86/consinit.c checks puc com device to use it as console.
Without this option, the behavior is the same as before.

  - Add a new config parameter PUC_CNBUS. The old code scans bus #0 only.
If PUC_CNBUS is set, the specified number's bus will be scanned.

  - Rename comcnprobe() to puc_cnprobe() to make it clear.

  - Rename comcninit() to puc_cninit() to make it clear.

  - Add code for a device that a device's com register is MMIO (#if0 ed).


To generate a diff of this commit:
cvs rdiff -u -r1.63 -r1.64 src/sys/arch/x86/pci/pci_machdep.c
cvs rdiff -u -r1.24 -r1.25 src/sys/arch/x86/x86/consinit.c
cvs rdiff -u -r1.368 -r1.369 src/sys/dev/pci/files.pci
cvs rdiff -u -r1.12 -r1.13 src/sys/dev/pci/puccn.c
cvs rdiff -u -r1.5 -r1.6 src/sys/dev/pci/puccn.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


This change includes a part of PR#48016


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

(2013/12/10 19:15), Jukka Ruohonen wrote:

On Tue, Dec 10, 2013 at 02:02:41PM +0900, Masanobu SAITOH wrote:

  How about the following patch? Is it ok to commit?


Looks good to me!


 Committed!

 Thanks.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

(2013/12/09 0:24), SAITOH Masanobu wrote:

(2013/12/08 19:21), Jukka Ruohonen wrote:

On Sun, Dec 08, 2013 at 04:07:38AM +, SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Sun Dec  8 04:07:38 UTC 2013

Modified Files:
src/sys/arch/x86/x86: tsc.c

Log Message:
  Update invariant TSC detect code from both Intel and AMD documents.
The best way to check whether the TSC counter is invariant or not is to check
CPUID 8007.


It might be worth to refactor this as a function, given that the code is
replicated in arch/x86/acpi/acpi_cpu_md.c.

- Jukkal.


  Yes, the code can be shared. I'm new to x86 and I'm not familiar
with acpi, so please do it if you can :)

  For last few months, I have been reading documents and code around
CPUID and MSR registers. While reading the code, I knew I had to check
ACPI stuff, but I've not done it yet :-



 How about the following patch? Is it ok to commit?

Index: sys/arch/x86/acpi/acpi_cpu_md.c
===
RCS file: /cvsroot/src/sys/arch/x86/acpi/acpi_cpu_md.c,v
retrieving revision 1.74
diff -u -r1.74 acpi_cpu_md.c
--- sys/arch/x86/acpi/acpi_cpu_md.c 20 Nov 2013 13:52:30 -  1.74
+++ sys/arch/x86/acpi/acpi_cpu_md.c 10 Dec 2013 04:55:11 -
@@ -43,6 +43,7 @@
 #include x86/cpuvar.h
 #include x86/cpu_msr.h
 #include x86/machdep.h
+#include x86/x86/tsc.h
 
 #include dev/acpi/acpica.h

 #include dev/acpi/acpi_cpu.h
@@ -162,6 +163,16 @@
 */
val |= ACPICPU_FLAG_C_APIC | ACPICPU_FLAG_C_TSC;
 
+	/*

+* Detect whether TSC is invariant. If it is not, we keep the flag to
+* note that TSC will not run at constant rate. Depending on the CPU,
+* this may affect P- and T-state changes, but especially relevant
+* are C-states; with variant TSC, states larger than C1 may
+* completely stop the counter.
+*/
+   if (tsc_is_invariant())
+   val = ~ACPICPU_FLAG_C_TSC;
+
switch (cpu_vendor) {
 
 	case CPUVENDOR_IDT:

@@ -214,24 +225,6 @@
val = ~ACPICPU_FLAG_C_APIC;
}
 
-		/*

-* Detect whether TSC is invariant. If it is not,
-* we keep the flag to note that TSC will not run
-* at constant rate. Depending on the CPU, this may
-* affect P- and T-state changes, but especially
-* relevant are C-states; with variant TSC, states
-* larger than C1 may completely stop the counter.
-*/
-   x86_cpuid(0x8000, regs);
-
-   if (regs[0] = 0x8007) {
-
-   x86_cpuid(0x8007, regs);
-
-   if ((regs[3]  __BIT(8)) != 0)
-   val = ~ACPICPU_FLAG_C_TSC;
-   }
-
break;
 
 	case CPUVENDOR_AMD:

@@ -284,13 +277,10 @@
case 0x15: /* AMD Bulldozer */
 
 			/*

-* Like with Intel, detect invariant TSC,
-* MSR-based P-states, and AMD's turbo
-* (Core Performance Boost), respectively.
+* Like with Intel, detect MSR-based P-states,
+* and AMD's turbo (Core Performance Boost),
+* respectively.
 */
-   if ((regs[3]  CPUID_APM_TSC) != 0)
-   val = ~ACPICPU_FLAG_C_TSC;
-
if ((regs[3]  CPUID_APM_HWP) != 0)
val |= ACPICPU_FLAG_P_FFH;
 
Index: sys/arch/x86/x86/tsc.c

===
RCS file: /cvsroot/src/sys/arch/x86/x86/tsc.c,v
retrieving revision 1.34
diff -u -r1.34 tsc.c
--- sys/arch/x86/x86/tsc.c  8 Dec 2013 04:07:38 -   1.34
+++ sys/arch/x86/x86/tsc.c  10 Dec 2013 04:55:11 -
@@ -63,23 +63,19 @@
.tc_quality = 3000,
 };
 
-void

-tsc_tc_init(void)
+bool
+tsc_is_invariant(void)
 {
struct cpu_info *ci;
uint32_t descs[4];
uint32_t family;
bool invariant;
 
-	if (!cpu_hascounter()) {

-   return;
-   }
+   if (!cpu_hascounter())
+   return false;
 
 	ci = curcpu();

invariant = false;
-   tsc_freq = ci-ci_data.cpu_cc_freq;
-   tsc_good = (cpu_feature[0]  CPUID_MSR) != 0 
-   (rdmsr(MSR_TSC) != 0 || rdmsr(MSR_TSC) != 0);
 
 	if (cpu_vendor == CPUVENDOR_INTEL) {

/*
@@ -140,6 +136,24 @@
}
}
 
+	return invariant;

+}
+
+void
+tsc_tc_init(void)
+{
+   struct cpu_info *ci;
+   bool invariant;
+
+   if (!cpu_hascounter())
+   return;
+
+   ci = curcpu();
+   tsc_freq = ci-ci_data.cpu_cc_freq;
+   tsc_good = (cpu_feature[0]  CPUID_MSR) != 0 
+   (rdmsr(MSR_TSC) != 0 || rdmsr(MSR_TSC) != 0);
+
+   invariant = 

Re: CVS commit: src/sys/arch/x86/x86

[Masanobu SAITOH]

 Hi, Christos.

(2013/11/12 2:02), Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Mon Nov 11 17:02:53 UTC 2013

Modified Files:
src/sys/arch/x86/x86: intel_busclock.c

Log Message:
CID 1128377: Comment out unreachable code; model is only 4 bits wide, so
none of these constants can ever match.


To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 src/sys/arch/x86/x86/intel_busclock.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


 Thank you for the change. I was wrong and our code is little
bad about using (extended) cpu family and (extended) cpu model.
I'll write the change to fix the problem and to reduce the code
duplication.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys

[Masanobu SAITOH]

(2013/06/30 6:06), Mindaugas Rasiukevicius wrote:

Module Name:src
Committed By:   rmind
Date:   Sat Jun 29 21:06:58 UTC 2013

Modified Files:
src/sys/conf: files
src/sys/external/bsd/ipf/netinet: ip_fil.h ip_fil_netbsd.c
src/sys/net: if.c if.h if_bridge.c if_ecosubr.c if_ethersubr.c
if_pppoe.c if_spppsubr.c pfil.c pfil.h
src/sys/net/npf: npf_handler.c
src/sys/netinet: in.c ip_input.c ip_output.c
src/sys/netinet6: in6.c ip6_forward.c ip6_input.c ip6_output.c

Log Message:
- Rewrite parts of pfil(9): use array to store hooks and thus be more cache
   friendly (there are only few hooks in the system).  Make the structures
   opaque and the interface more strict.
- Remove PFIL_HOOKS option by making pfil(9) mandatory.


To generate a diff of this commit:
cvs rdiff -u -r1.1076 -r1.1077 src/sys/conf/files
cvs rdiff -u -r1.4 -r1.5 src/sys/external/bsd/ipf/netinet/ip_fil.h \
 src/sys/external/bsd/ipf/netinet/ip_fil_netbsd.c
cvs rdiff -u -r1.264 -r1.265 src/sys/net/if.c
cvs rdiff -u -r1.155 -r1.156 src/sys/net/if.h
cvs rdiff -u -r1.76 -r1.77 src/sys/net/if_bridge.c
cvs rdiff -u -r1.36 -r1.37 src/sys/net/if_ecosubr.c
cvs rdiff -u -r1.194 -r1.195 src/sys/net/if_ethersubr.c
cvs rdiff -u -r1.98 -r1.99 src/sys/net/if_pppoe.c
cvs rdiff -u -r1.126 -r1.127 src/sys/net/if_spppsubr.c
cvs rdiff -u -r1.27 -r1.28 src/sys/net/pfil.c
cvs rdiff -u -r1.30 -r1.31 src/sys/net/pfil.h
cvs rdiff -u -r1.26 -r1.27 src/sys/net/npf/npf_handler.c
cvs rdiff -u -r1.143 -r1.144 src/sys/netinet/in.c
cvs rdiff -u -r1.307 -r1.308 src/sys/netinet/ip_input.c
cvs rdiff -u -r1.223 -r1.224 src/sys/netinet/ip_output.c
cvs rdiff -u -r1.165 -r1.166 src/sys/netinet6/in6.c
cvs rdiff -u -r1.71 -r1.72 src/sys/netinet6/ip6_forward.c
cvs rdiff -u -r1.142 -r1.143 src/sys/netinet6/ip6_input.c
cvs rdiff -u -r1.153 -r1.154 src/sys/netinet6/ip6_output.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


The following files still refer opt_pfil_hooks.h:


amd64(msaitoh)% grep -r opt_pfil_hooks.h .
./dist/pf/net/pf_if.c:#include opt_pfil_hooks.h
./dist/pf/net/pf_ioctl.c:#include opt_pfil_hooks.h


And rump/net/lib/libnet/opt/opt_pfil_hooks.h still exists.


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

(2013/06/11 16:22), SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Tue Jun 11 07:22:08 UTC 2013

Modified Files:
src/sys/dev/mii: ciphy.c ihphy.c tlphy.c

Log Message:
Update link status quickly. This change is a part of mii_physubr.c rev.
1.77-1.78.


To generate a diff of this commit:
cvs rdiff -u -r1.23 -r1.24 src/sys/dev/mii/ciphy.c
cvs rdiff -u -r1.5 -r1.6 src/sys/dev/mii/ihphy.c
cvs rdiff -u -r1.60 -r1.61 src/sys/dev/mii/tlphy.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Sorry, I'm accidentally committed ihphy.c and tlphy. The commit message
was modified as follows using cvs admin -m.


 Remove duplicated code. The code to check IFF_UP and autonegotiation
is in mii_phy_tick(), too.


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[Masanobu SAITOH]

(2013/04/15 20:48), SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Mon Apr 15 11:48:27 UTC 2013

Added Files:
src/sys/dev/mii: mdio.h

Log Message:
Add new file mii/mdio.h which contain IEEE 802.3 Clause 45 register
definitions. From:
  - IEEE 802.3 2008


 s/2008/2009/

I've fixed using cvs admin.



  - IEEE 802.3at
  - IEEE 802.3av
  - IEEE 802.3az
Currently, only device addresses and register number are written.


To generate a diff of this commit:
cvs rdiff -u -r0 -r1.1 src/sys/dev/mii/mdio.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/arm/arm

[Masanobu SAITOH]

Hi, matt.

(2012/12/28 14:10), Matt Thomas wrote:


On Dec 27, 2012, at 7:48 PM, SAITOH Masanobu wrote:


Module Name:src
Committed By:   msaitoh
Date:   Fri Dec 28 03:48:00 UTC 2012

Modified Files:
src/sys/arch/arm/arm: cpufunc.c

Log Message:
Enable DCache Streaming Switch and Write Allocate.
This change improve system performance significantly.


How does this affect L2 and DMA?


Both are not affected.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/arm/include

[Masanobu SAITOH]

(2012/09/01 8:56), Matt Thomas wrote:

Module Name:src
Committed By:   matt
Date:   Fri Aug 31 23:56:15 UTC 2012

Modified Files:
src/sys/arch/arm/include: mutex.h

Log Message:
Move the __cpu_simple_lock to the last byte so it's easier to read in dumps


To generate a diff of this commit:
cvs rdiff -u -r1.11 -r1.12 src/sys/arch/arm/include/mutex.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


 This change makes panic on big endian.

--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

Re: CVS commit: src/sys/arch/arm/marvell

[Masanobu SAITOH]

(2012/09/10 17:50), SAITOH Masanobu wrote:

Module Name:src
Committed By:   msaitoh
Date:   Mon Sep 10 08:50:38 UTC 2012

Modified Files:
src/sys/arch/arm/marvell: mvsocgpp.c

Log Message:
Fix a bug that the irq_masks of GPIO are set on Marvell SoCs.


s/are set/are incorrectly set/





To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/sys/arch/arm/marvell/mvsocgpp.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

 * 英語 - 自動検出
 * 英語
 * 日本語

 * 英語
 * 日本語

 javascript:void(0);

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

[Masanobu SAITOH]

Hi.

(2012/08/30 7:06), Paul Goyette wrote:

On Wed, 29 Aug 2012, Paul Goyette wrote:


On Wed, 29 Aug 2012, Manuel Bouyer wrote:


Module Name:src
Committed By:bouyer
Date:Wed Aug 29 20:39:24 UTC 2012

Modified Files:
src/sys/dev/pci: if_wm.c if_wmreg.h

Log Message:
Make vlan and all ip/ip6 checksum offload work for the I350.

On newer devices, when using the legacy TX descriptors, vlan-related
flags
that were set on the last descriptor of a packet have to be set on the
first one.
For tso/checksum offloads, a new advanced descriptor format has to be
used.


snip


Tested on a I350, and a i80003 (which use the old format), both with and
without vlans, with and without checksum offloads.


Is there an easy way to identify which wm I have?  Does the following
device need this commit in order to use offload?  Or will this one
work with an earlier rev of the driver?

# dmesg | grep wm
wm0 at pci2 dev 0 function 0: Intel i82574L (rev. 0x00)
wm0: interrupting at ioapic1 pin 24
wm0: PCI-Express bus
wm0: 256 word (8 address bits) SPI EEPROM
wm0: Ethernet address bc:ae:c5:30:d9:8a
ukphy0 at wm0 phy 1: OUI 0x000ac2, model 0x000b, rev. 1


BTW, reason I am asking is that I had previously (about a year or so
ago) needed to disable the offload functions on the 82574 because it
wasn't working.  This commit seems to imply that it fixes only the I350
so I was wondering if some other change that I had missed might have
already fixed the 82574.



-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-


82575, 82576, 82580(ER) and I350 use the new queue mechanism.


--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)