re: CVS commit: src/distrib/sets/lists/modules
> > Probably. but Jaromir only set it up for i386/amd64, and I was just > > following his lead. > > Fair enough. So, who wants to be the first to connect an nvme to their > vax? :-) actually, martin@ already tried an nvme card on his sparc64 but it appears to require PCIe 2.x at a minimum, and his box was PCIe 1.x. or so i recall.. the card didn't even appear vaguely. but maybe a more modern sparc64 box with PCIe 2.x or newer works better.. .mrg.
re: CVS commit: src/sys/kern
"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Sat Sep 17 12:00:35 UTC 2016 > > Modified Files: > src/sys/kern: kern_proc.c > > Log Message: > Use VM_MAXUSER_ADDRESS for proc0, not VM_MAX_ADDRESS. It normally does not > change anything, since kernel processes use the shared kernel map instead > of the one they are given here. For consistency though, it is better to > make sure UVM will not be tempted to access machine-dependent reserved > areas (e.g., the PTE space on x86). can you explain why this is right on platforms without shared user/kernel address spaces? this change seems specific to platforms that are forced or choose to merge them. thanks .mrg.
re: CVS commit: src/distrib/sets/lists/modules
"Paul Goyette" writes: > Module Name: src > Committed By: pgoyette > Date: Sat Sep 17 02:27:19 UTC 2016 > > Modified Files: > src/distrib/sets/lists/modules: md.amd64 md.i386 mi > > Log Message: > Fix sets lists for nvme module. Since it is being built only for the > i386 and amd64 platforms, the entries belong in the md.xxx lists, not > in the mi list. shouldn't we build it for anything with PCI? .mrg.
re: CVS commit: src/sys/dev
"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Fri Sep 16 15:20:50 UTC 2016 > > Modified Files: > src/sys/dev: ld.c ldvar.h > src/sys/dev/ata: ld_ataraid.c > src/sys/dev/i2o: ld_iop.c > src/sys/dev/ic: ld_aac.c ld_cac.c ld_icp.c ld_mlx.c ld_nvme.c > src/sys/dev/pci: ld_amr.c ld_twa.c ld_twe.c ld_virtio.c > src/sys/dev/sdmmc: ld_sdmmc.c > > Log Message: > modify ldattach() to have default strategy as a parameter i don't see a kernel bump for this change which will break any module that uses these interfaces. you seemed to add at least one of them recently ;) .mrg.
Re: CVS commit: src/sys/dev/mii
Hi, From: Masanobu SAITOH , Date: Tue, 20 Sep 2016 14:02:37 +0900 > 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? Here is wm0 and ihphy0 from dmesg with inbmphyreg.h rev. 1.5: wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x03) wm0: interrupting at msi1 vec 0 wm0: PCI-Express bus wm0: 2048 words FLASH wm0: Ethernet address b8:6b:23:86:df:bb ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5 ihphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Thank you. > 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)
