Re: lm0 at isa reboot
Hi, Patrick On 2017/07/27 18:28, Patrick Welche wrote: On Fri, Jul 21, 2017 at 10:59:51PM +0100, Patrick Welche wrote: On Fri, Jul 21, 2017 at 08:17:44AM +0100, Patrick Welche wrote: On Fri, Jul 21, 2017 at 07:53:09AM +0100, Patrick Welche wrote: On Thu, Jul 20, 2017 at 09:06:16PM +, co...@sdf.org wrote: On Thu, Jul 13, 2017 at 09:49:32AM +0100, Patrick Welche wrote: or "new" reboot: just updated a working 3rd July amd64 kernel with this morning's source, and the computer reboots after printing nouveau, but before drm. Haven't had a chance to dig (won't until tonight) - any first guesses? Must be unrelated to nouveau. no changes in sys/external/bsd/drm2 since June 1. In the meantime it is getting even more confusing: I bisected to http://mail-index.netbsd.org/source-changes/2017/07/11/msg086253.html lm(4): Add suport for NCT5174D, NCT6775F, NCT6779D and NCT679[1235]D. wbsio(4): Add support for NCT6795D. but then rebooting with disable wbsio (which didn't switch anything off) and disable lm still failed. Now moving the modules which I haven't kept in synch during the bisection away. Moving the modules out of the way now gets consistent results: - unsuccessful boot with the above patch - successful boot with the above patch and "disable lm" I have no idea what chip is in this box(!) End conclusion: if I comment out #lm0at isa? port 0x290 flags 0x0# other common ports: 0x280, 0x310 i.e., have it the way it is in GENERIC, the kernel boots. (With it in, I get a reboot with nothing printed on the serial console.) Leaving lm*at wbsio? is fine. Adding DEBUG, DIAGNOSTIC, LOCKDEBUG, and leaving lm0 at isa? also appears to be fine (?!) (and the locking I had in earlier posts also doesn't seem to tie up with lm, but I did have to have it uncommented.) Turns out that on 0x290, this Ryzen box has an ITE IT8665E. Driver for ITE's super I/O is itesio(4) Why the bisection hit that commit remains a mystery, as that chip won't have attached to the driver. Default I/O port of ITE's super I/O and Winbond(Nuvoton)'s super I/O the same. Only one or two byte ID of super I/O makes hard to identify. For our Winbond support, it checks only 8 bits instead of real 12 bits, so it can be improved. Another problem is that nslm7x.c's xxx_match() is not match function but attach function, so it also should be improved. Until above problems will be solved, don't enable "lm* at wbsio?" on your machine. Cheers, Patrick -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
daily CVS update output
Updating src tree: cvs update: `src/external/gpl3/gcc/lib/libgcc/Makefile.wrapper' is no longer in the repository P src/external/gpl3/gcc/lib/libgcc/libgcc/Makefile P src/external/gpl3/gcc/usr.bin/Makefile.backend P src/external/gpl3/gcc/usr.bin/Makefile.inc cvs update: `src/external/gpl3/gcc.old/lib/libgcc/Makefile.wrapper' is no longer in the repository P src/external/gpl3/gcc.old/lib/libgcc/libgcc/Makefile P src/external/gpl3/gcc.old/usr.bin/Makefile.backend P src/external/gpl3/gcc.old/usr.bin/Makefile.inc P src/external/mit/lua/dist/src/ldebug.c P src/lib/libc/gen/vis.3 P src/sbin/gpt/gpt.8 P src/sys/arch/evbarm/conf/std.marvell P src/sys/arch/sandpoint/stand/altboot/brdsetup.c P src/sys/arch/sandpoint/stand/altboot/siisata.c P src/sys/arch/sandpoint/stand/altboot/skg.c P src/sys/arch/sandpoint/stand/altboot/version P src/sys/dev/audio.c P src/sys/dev/hdaudio/hdafg.c P src/sys/dev/hdaudio/hdafg_dd.c P src/sys/netinet/tcp_input.c P src/sys/netinet/tcp_output.c P src/sys/netipsec/ipsec.c P src/sys/netipsec/ipsec_input.c P src/sys/netipsec/ipsec_netbsd.c P src/sys/netipsec/ipsec_output.c P src/sys/netipsec/key.c P src/sys/netipsec/key.h P src/sys/netipsec/keydb.h P src/sys/netipsec/xform_ah.c P src/sys/netipsec/xform_esp.c P src/sys/netipsec/xform_ipcomp.c P src/tests/net/carp/t_basic.sh P src/tests/net/if_gif/t_gif.sh P src/tests/net/if_l2tp/t_l2tp.sh P src/tests/net/ipsec/t_ipsec_ah_keys.sh P src/tests/net/ipsec/t_ipsec_esp_keys.sh P src/tests/net/ipsec/t_ipsec_gif.sh P src/tests/net/ipsec/t_ipsec_l2tp.sh P src/tests/net/ipsec/t_ipsec_misc.sh P src/tests/net/ipsec/t_ipsec_sockopt.sh P src/tests/net/ipsec/t_ipsec_tcp.sh P src/tests/net/ipsec/t_ipsec_transport.sh P src/tests/net/ipsec/t_ipsec_tunnel.sh P src/tests/net/ipsec/t_ipsec_tunnel_ipcomp.sh P src/tests/net/ipsec/t_ipsec_tunnel_odd.sh P src/tests/net/mcast/t_mcast.sh P src/tests/net/net/t_ipaddress.sh P src/tests/net/npf/t_npf.sh P src/tests/net/route/t_flags.sh P src/tests/net/route/t_flags6.sh P src/usr.sbin/acpitools/acpidump/acpi_user.c P src/usr.sbin/traceroute6/traceroute6.8 Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 62652110 Aug 4 03:03 ls-lRA.gz
Re: How to run X11 on ATI Radeon 9000?
>> vga0 at pci1 dev 0 function 0: vendor 1002 product 4c66 (rev. 0x02)
>> drm at vga0 not configured
>
> Did you take a look at the pcidevs file in the kernel to see if vendor 1002
> product 4c66 was supported? If not, that'd be the first problem and the fix
> (if indeed it's simply just a Radeon 9000) is to edit the file and add the
> IDs to the appropriate driver section.
>
> However, I suspect it's a conflict with the various DRM subsystems that are
> out there.
>
> -Swift
src/sys/external/bsd/drm2/dist/include/drm/drm_pciids.h contains:
{0x1002, 0x4C66, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_RV250|RADEON_IS_MOBILITY}
so it should be detected… no? :)
Adam
aac / ld interaction
Hi, this afternoon I attempted to upgrade NetBSD from 7.1_STABLE to 8.0_BETA on an amd64-running machine in our lab. It has an aac controller, probed like so: aac0 at pci6 dev 0 function 0: IBM ServeRAID 8k aac0: interrupting at ioapic0 pin 17 aac0: Enabling 64-bit address support aac0: Enable 64-bit array support aac0: New comm. interface enabled aac0: MIPS 5KC at 250MHz, 32MB mem (16MB cache), optional battery not installed ld0 at aac0 unit 0: RAID 1 (Mirror) ld0: 232 GB, 30378 cyl, 255 head, 63 sec, 512 bytes/sect x 488036352 sectors ld1 at aac0 unit 1: RAID 10 ld1: 465 GB, 60757 cyl, 255 head, 63 sec, 512 bytes/sect x 976072704 sectors Apparently, somewhere between those two kernel versions, the 'ld' driver was MPified, while the aac driver was not. The symptom I noticed this with was that I managed to unpack the 'base' set from the 8.0_BETA build, but 29% into the 'comp' set, the machine decided to panic with a rather mysterious null pointer de-reference inside the aac driver, pointing (by the looks of it) to the SIMPLEQ_FIRST macro use inside aac_ccb_enqueue(). By this time I had a machine with an 8-based user-land but with a brittle 8 kernel, and of course the 7-based kernel doesn't want anything to do with the 8-based ifconfig, so by the looks of it, the machine is going to need me to physically visit it to rescue it out of this bind, even though I have remote serial console. I don't know the MPify-state for the other sub-drivers under 'ld' (I see aac, cac, icp, mlx and nvme), but this should probably get some proper attention before 8.0 is released... And, I have it on good authority that simply replacing splbio() / splx() with mutex_enter() / mutex_exit() isn't going to work, because there are a number of things which are not permitted in a mutex-based critical section which are perfectly fine in an splbio()-protected section, such as doing malloc(), using bus_* functions etc. etc. So the conversion is decidedly not trivial, and certainly above my current skill level. So, "Help!" Regards, - Håvard
Re: Fixing swap1_stop
On Thu, 3 Aug 2017 10:54:30 + (UTC) chris...@astron.com (Christos Zoulas) wrote: > In article <20170802215811.02ff2faba38001ebe4f53...@fastmail.fm>, > Ian D. Leroux wrote: > >The patches stop swap1_stop from blindly unmounting > >a tmpfs-mounted /dev/while the system is still running multi-user. > > [...] > > Why not just skip /dev? > > echo -n "Forcibly unmounting tmpfs filesystems:" > mount -t tmpfs | while read tmpfs on dir rest; do > case "$dir" in > /dev) > echo -n " [skipping $dir]" > ;; > *) > echo -n " $dir" > umount -f "$dir" > esac > done > echo "." A couple of not-very-convincing reasons: 1- That loop isn't, as far as I can see, robust to pathnames with spaces in them. "/dev" has no space, but some other directory with a tmpfs mount might, and the attempt to unmount will then (at best) fail noisily. 2- Hard-coding a single special directory smells wrong. There might be device nodes elsewhere than in /dev. In general, I think that having swap1 unmount filesystems in the hope of ensuring that the remaining contents of virtual memory fit into RAM is several ugly modularity violations rolled into one. I suspect, but haven't proved, that any heuristic we come up with for choosing the filesystems (not) to unmount will get it wrong in at least some cases. That's why the consensus last year was that there should be a documented mechanism to override the defaults and let an administrator explicitly specify which, if any, filesystems swap1 is allowed to unmount. I don't actually much care what the default is (whether "/tmp and /var/shm" , "everything but /dev" or "all tmpfs that contain no device nodes" as I currently have it). I mostly want a documented way to override it. -- IDL
Re: Fixing swap1_stop
In article <20170802215811.02ff2faba38001ebe4f53...@fastmail.fm>, Ian D. Leroux wrote: >For the last year or so I've been carrying a set of local patches >to /etc/rc.d/swap1, /etc/defaults/rc.conf and the attendant >documentation. The patches stop swap1_stop from blindly unmounting >a tmpfs-mounted /dev/while the system is still running multi-user. I >was about to submit a PR to try to get the patches into the tree (so >that I don't have to tip-toe around them every time I update my base >system) when I discovered that ... I already did: bin/51019. > >The development of the patches is discussed in the thread starting at: >https://mail-index.netbsd.org/current-users/2016/03/13/msg029029.html > >Could someone take a look and let me know what still needs to be >improved before they can be committed? I'd like to get this sorted out >before I go looking for more windmills at which to tilt ... > Why not just skip /dev? echo -n "Forcibly unmounting tmpfs filesystems:" mount -t tmpfs | while read tmpfs on dir rest; do case "$dir" in /dev) echo -n " [skipping $dir]" ;; *) echo -n " $dir" umount -f "$dir" esac done echo "." christos
Re: problems with vlan interface counters (NetBSD 8.0_BETA)
Hi, Uwe
The problem was happened in vlan mp-ify.
I fixed this problem by the following patch in my environment.
Could you apply the patch and check it?
Regards,
s-yamaguchi@IIJ
patch
diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c
index 531a2f5..a4ea6e1 100644
--- a/sys/net/if_vlan.c
+++ b/sys/net/if_vlan.c
@@ -1451,10 +1451,13 @@ vlan_transmit(struct ifnet *ifp, struct mbuf *m)
/* mbuf is already freed */
ifp->if_oerrors++;
} else {
+ size_t pktlen = m->m_pkthdr.len;
+ bool mcast = (m->m_flags & M_MCAST) != 0;
+
ifp->if_opackets++;
- /*
-* obytes is incremented at ether_output() or bridge_enqueue().
-*/
+ ifp->if_obytes += pktlen;
+ if (mcast)
+ ifp->if_omcasts++;
}
out:
2017-07-28 17:10 GMT+09:00 <6b...@6bone.informatik.uni-leipzig.de>:
> Hello,
>
> The interface counters of vlan interface do not count:
>
> bash-4.4# ifconfig -v vlan8
> vlan8: flags=0x8843 mtu 1500
> capabilities=7ff80
> capabilities=7ff80
> capabilities=7ff80
> enabled=0
> vlan: 8 parent: ixg0
> address: a0:36:9f:d4:3c:08
> input: 1966263 packets, 273676300 bytes, 66058 multicasts
> output: 1238957 packets, 0 bytes
> inet6 fe80::a236:9fff:fed4:3c08%vlan8/64 flags 0x0 scopeid 0x1a
> inet6 ::::::: flags 0x0
>
> The output byte counter shows 0. With netbsd-7 all worked fine.
>
> So it is not longer possible to record traffic data via snmp.
>
>
> Regards
> Uwe
