Re: default ipv6 route?
On Apr 24, 2015, at 9:55 AM, Christos Zoulas chris...@astron.com wrote: One of my ISProviders is TWC. If you don't use DHCPv6, what you end up is the link-local address for each interface (which you get anyway), and a default route to the link-local address of the TWC router (through RA's), which is not useful if you don't have a real IPv6 address on any of your interfaces. This made things work very slowly, because everything tried IPv6 first because of the default route (until it timed-out). Shouldn't the link-local address fail source address selection? It might be interesting to try to figure out exactly how this is happening. It seems like a fail to try to use an IPv6 default route when you have no valid source address candidates.
7.0_BETA and 7.99.10 fail to find USB devices
Hi, I've recently had occasion to try to install NetBSD on a new Lenovo RD350 1U server. I've tried the following versions and boot device combinations: 7.0_BETA from USB flash disk 7.0_BETA from a USB CD-ROM 7.99.10 from a USB CD-ROM 6.1.3 from a USB CD-ROM I've also hooked up a Dell USB keyboard to the host to be able to interact with the boot loader, but all the bootups were done with a serial console. (That the RAID device finds a disk in some of the latter ones is me figuring out how to configure it via the firmware.) The problem I'm seeing is that neither of 7.0_BETA nor 7.99.10 manage to probe either the USB flash disk (when booted via that), the USB CD-ROM, or the USB keyboard, and ends up prompting root device: after loading and running the OS. 6.1.3 on the other hand manages to find the USB CD-ROM and the keyboard. The kernel boot messages from the last three combinations mentioned above follow attached below. Anyone have any idea what the problem might be? Should I send-pr this problem? Regards, - Håvard Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.0_BETA (GENERIC.201504240620Z) total memory = 32610 MB avail memory = 31647 MB kern.module.path=/stand/amd64/7.0/modules mainbus0 (root) ACPI: RSDP 0xf0530 24 (v02 LENOVO) ACPI: XSDT 0x766c80b0 E4 (v01 LENOVO SV-INT 0126 AMI 00010013) ACPI: FACP 0x766f56b0 00010C (v05 LENOVO SV-INT 0126 AMI 00010013) ACPI: DSDT 0x766c8228 02D486 (v02 LENOVO SV-INT 0126 INTL 20091013) ACPI: FACS 0x7764bf80 40 ACPI: APIC 0x766f57c0 000138 (v03 LENOVO SV-INT 0126 AMI 00010013) ACPI: FPDT 0x766f58f8 44 (v01 LENOVO SV-INT 0126 AMI 00010013) ACPI: FIDT 0x766f5940 9C (v01 LENOVO SV-INT 0126 AMI 00010013) ACPI: SPMI 0x766f59e0 40 (v05 LENOVO SV-INT 0126 AMI. ) ACPI: MCFG 0x766f5a20 3C (v01 LENOVO SV-INT 0126 MSFT 0097) ACPI: UEFI 0x766f5a60 42 (v01 LENOVO SV-INT 0126 ) ACPI: BDAT 0x766f5aa8 30 (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: HPET 0x766f5ad8 38 (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: MSCT 0x766f5b10 90 (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: PMCT 0x766f5ba0 64 (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: SLIT 0x766f5c08 2D (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: SRAT 0x766f5c38 000E58 (v03 LENOVO SV-INT 0126 INTL 20091013) ACPI: WDDT 0x766f6a90 40 (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: SSDT 0x766f6ad0 00EE25 (v01 LENOVOPmMgt 0126 INTL 20120913) ACPI: SLIC 0x767058f8 000176 (v01 ?? 0126 AMI 00010013) ACPI: SSDT 0x76705a70 001BAF (v02 LENOVO SpsNm0126 INTL 20120913) ACPI: SSDT 0x76707620 64 (v02 LENOVO SpsNvs 0126 INTL 20120913) ACPI: PRAD 0x76707688 000102 (v02 LENOVO SV-INT 0126 INTL 20120913) ACPI: DMAR 0x76707790 E6 (v01 LENOVO SV-INT 0126 INTL 20091013) ACPI: HEST 0x76707878 0002BC (v01 LENOVO SV-INT 0126 INTL 0001) ACPI: BERT 0x76707b38 30 (v01 LENOVO SV-INT 0126 INTL 0001) ACPI: ERST 0x76707b68 000230 (v01 LENOVO SV-INT 0126 INTL 0001) ACPI: EINJ 0x76707d98 000150 (v01 LENOVO SV-INT 0126 INTL 0001) ACPI: All ACPI Tables successfully acquired cpu0 at mainbus0 apid 0: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu1 at mainbus0 apid 2: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu2 at mainbus0 apid 4: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu3 at mainbus0 apid 6: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu4 at mainbus0 apid 8: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu5 at mainbus0 apid 10: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu6 at mainbus0 apid 12: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu7 at mainbus0 apid 14: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu8 at mainbus0 apid 1: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu9 at mainbus0 apid 3: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu10 at mainbus0 apid 5: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu11 at mainbus0 apid 7: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu12 at mainbus0 apid 9: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu13 at mainbus0 apid 11: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu14 at mainbus0 apid 13: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 cpu15 at mainbus0 apid 15: Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, id 0x306f2 ioapic0 at mainbus0 apid 1 ioapic1 at mainbus0 apid 2 acpi0 at mainbus0: Intel ACPICA 20131218 hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400) SCK0 (ACPI0004) at acpi0 not
Re: default ipv6 route?
In article d2de8ada-ca2d-4e57-b50c-ccac8d27d...@3am-software.com, Matt Thomas m...@3am-software.com wrote: On Apr 23, 2015, at 8:40 PM, Brett Lymn bl...@internode.on.net wrote: inet6 fe80::76d0:2bff:fe2b:89bc%wm0 prefixlen 64 scopeid 0x1 That is a link local address is only good for communicating with other machines accesible from that interface. If you had ârealâ IPv6 youâd see something other than fe80:: One of my ISProviders is TWC. If you don't use DHCPv6, what you end up is the link-local address for each interface (which you get anyway), and a default route to the link-local address of the TWC router (through RA's), which is not useful if you don't have a real IPv6 address on any of your interfaces. This made things work very slowly, because everything tried IPv6 first because of the default route (until it timed-out). On the bright side everything works if you run dhcpcd, and you get a delegated /64 too for your internal network. christos
Re: 7.0_BETA and 7.99.10 fail to find USB devices
h...@netbsd.org (Havard Eidnes) writes: I've recently had occasion to try to install NetBSD on a new Lenovo RD350 1U server. I've tried the following versions and boot device combinations: 7.0_BETA from USB flash disk 7.0_BETA from a USB CD-ROM 7.99.10 from a USB CD-ROM 6.1.3 from a USB CD-ROM Looks like the netbsd-7 USB stack doesn't recognize an already plugged in device in uhub2. Do you know if the device is recognized when it is plugged in later? If not, then it's probably some interrupt related problem. Do you know how the USB flash disk attaches under 6.1.3 ? Should I send-pr this problem? Yes please. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: default ipv6 route?
On 27/04/2015 12:16, Ted Lemon wrote: On Apr 24, 2015, at 9:55 AM, Christos Zoulas chris...@astron.com wrote: One of my ISProviders is TWC. If you don't use DHCPv6, what you end up is the link-local address for each interface (which you get anyway), and a default route to the link-local address of the TWC router (through RA's), which is not useful if you don't have a real IPv6 address on any of your interfaces. This made things work very slowly, because everything tried IPv6 first because of the default route (until it timed-out). Shouldn't the link-local address fail source address selection? It might be interesting to try to figure out exactly how this is happening. It seems like a fail to try to use an IPv6 default route when you have no valid source address candidates. This is a good idea and would also fix a similar issue I reported here: http://mail-index.netbsd.org/tech-net/2015/04/02/msg005025.html Roy
Re: default ipv6 route?
On Apr 27, 7:16am, mel...@fugue.com (Ted Lemon) wrote: -- Subject: Re: default ipv6 route? | On Apr 24, 2015, at 9:55 AM, Christos Zoulas chris...@astron.com wrote: | One of my ISProviders is TWC. If you don't use DHCPv6, what you | end up is the link-local address for each interface (which you get | anyway), and a default route to the link-local address of the TWC | router (through RA's), which is not useful if you don't have a real | IPv6 address on any of your interfaces. | =20 | This made things work very slowly, because everything tried IPv6 | first because of the default route (until it timed-out). | | Shouldn't the link-local address fail source address selection? It might = | be interesting to try to figure out exactly how this is happening. It see= | ms like a fail to try to use an IPv6 default route when you have no valid s= | ource address candidates. Perhaps that's a good idea, and I think other OS's do that. I've added debugging and it is easy enough to reproduce it... christos
incorrect super block w recent changes
With the recent changes (yesterday and today) that allow current to boot again, I can't mount some drives: NetBSD 7.99.13 (GENERIC) #2: Mon Apr 27 14:11:26 EDT 2015 wd0 at atabus3 drive 0 wd0: ST1000DM003-1ER162 wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 931 GB, 1938021 cyl, 16 head, 63 sec, 512 bytes/sect x 1953525168 sectors wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) wd0(ahcisata1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA) wd1 at atabus4 drive 0 wd1: ST500DM002-1BC142 wd1: drive supports 16-sector PIO transfers, LBA48 addressing wd1: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) wd1(ahcisata1:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA) mount_ffs: /dev/wd1f on /opt2: incorrect super block fsck can't find anything wrong with the drive and it doesn't appear there is. Earlier kernels have no trouble mounting this drive. Also, shutdown hangs now and never completes.
Re: incorrect super block w recent changes
In article 20150427235050.8ea6712...@chopper.goathill.org, MLH m...@goathill.org wrote: Which is the last working kernel? Can you try reverting the latest change (ffs_vfsops.c,v 1.330) and see if that works for you? ffs_vfsops.c,v 1.329 2015/04/22 07:27:09 mounts wd1 fine. Can you put a printf to print the two values 1.330 is comparing? christos
Re: incorrect super block w recent changes
Which is the last working kernel? Can you try reverting the latest change (ffs_vfsops.c,v 1.330) and see if that works for you? ffs_vfsops.c,v 1.329 2015/04/22 07:27:09 mounts wd1 fine.
Re: incorrect super block w recent changes
Which is the last working kernel? Can you try reverting the latest change (ffs_vfsops.c,v 1.330) and see if that works for you? ffs_vfsops.c,v 1.329 2015/04/22 07:27:09 mounts wd1 fine. Can you put a printf to print the two values 1.330 is comparing? fs-fs_cgsize: 0x4000, fs_cgsize : 0x4800 - incorrect superblock So is this a valid error? This drive was partitioned using the NetBSD installer a while back so maybe things have changed?
Re: incorrect super block w recent changes
In article 20150428005329.298e312...@chopper.goathill.org, MLH m...@goathill.org wrote: Which is the last working kernel? Can you try reverting the latest change (ffs_vfsops.c,v 1.330) and see if that works for you? ffs_vfsops.c,v 1.329 2015/04/22 07:27:09 mounts wd1 fine. Can you put a printf to print the two values 1.330 is comparing? fs-fs_cgsize: 0x4000, fs_cgsize : 0x4800 - incorrect superblock So is this a valid error? This drive was partitioned using the NetBSD installer a while back so maybe things have changed? I don't know, can you run dumpfs on it and post the results? If wd0 is the same, do it for both... christos
Kernel RNG
Haven't see this in a while, so, fyi: Kernel RNG 22663 3552 13 runs test FAILURE: too many runs of 3 0s (737 723) cprng 22663 3552 13: failed statistical RNG test $ uname -a NetBSD kamloops 7.99.13 NetBSD 7.99.13 (GENERIC) #1186: Mon Apr 27 11:29:33 PDT 2015 root@kamloops:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
Re: incorrect super block w recent changes
In article 20150428012808.225ff12...@chopper.goathill.org, MLH m...@goathill.org wrote: So is this a valid error? This drive was partitioned using the NetBSD installer a while back so maybe things have changed? I don't know, can you run dumpfs on it and post the results? If wd0 is the same, do it for both... wd0 is FFSv2 and I thought wd1 is FFSv1. Not sure what you are looking for. wd0e mounts fine : fs-fs_cgsize: 0x4000, fs_cgsize : 0x4000 wd0f mounts fine : fs-fs_cgsize: 0x8000, fs_cgsize : 0x8000 wd1e mounts fine : fs-fs_cgsize: 0x4000, fs_cgsize : 0x4000 wd1f fails: fs-fs_cgsize: 0x4000, fs_cgsize : 0x4800 I think that the best way to fix this is to backup the data, newfs it and restore it... I am not sure how this could have happened, because fsck is supposed to recompute and store this when it converts the filesystem. Another thing to do is to check the values in the alternate superblocks, but even then probably the best thing to do is to rebuild it. christos
Re: default ipv6 route?
On Sun, Apr 26, 2015 at 10:10:36AM +0100, Roy Marples wrote: It sounds like accept_ra is disabled in the kernel (sysctl net.inet6.ip6.accept_rtadv, or on the interface (ndp -i jme0 | grep accept_rtadv). You can either enable them (ip6mode=autohost in rc.conf) or let dhcpcd manage the routing and addressing by removing the T option above. Yes, that was it. Thanks. I added ip6mode=autohost to rc.conf and put this in my ifconfig.wm0: siren netmask 255.255.255.0 broadcast 192.168.3.255 inet6 2001:44b8:25e:2d00::1 prefixlen 64 alias; dhcpcd -dB6T --nodhcp6 and now I can ping6 ftp.netbsd.org. -- Brett Lymn
Re: incorrect super block w recent changes
So is this a valid error? This drive was partitioned using the NetBSD installer a while back so maybe things have changed? I don't know, can you run dumpfs on it and post the results? If wd0 is the same, do it for both... wd0 is FFSv2 and I thought wd1 is FFSv1. Not sure what you are looking for. wd0e mounts fine : fs-fs_cgsize: 0x4000, fs_cgsize : 0x4000 wd0f mounts fine : fs-fs_cgsize: 0x8000, fs_cgsize : 0x8000 wd1e mounts fine : fs-fs_cgsize: 0x4000, fs_cgsize : 0x4000 wd1f fails: fs-fs_cgsize: 0x4000, fs_cgsize : 0x4800 file system: /dev/rwd1e format FFSv1 endian little-endian magic 11954 timeMon Apr 27 21:15:48 2015 superblock location 8192id [ 4f0f5203 4cbba5a3 ] cylgrp dynamic inodes 4.4BSD sblock FFSv2 fslevel 4 nbfree 2976641 ndir71728 nifree 8584892 nffree 196963 file system: /dev/rwd1f format FFSv1 endian little-endian magic 11954 timeMon Apr 27 20:44:07 2015 superblock location 8192id [ 4f11f067 131b65e8 ] cylgrp dynamic inodes 4.4BSD sblock FFSv2 fslevel 4 nbfree 18042732ndir48773 nifree 50365910nffree 36713 as compared with wd0e which mounts fine on all partitions file system: /dev/rwd0e format FFSv2 endian little-endian location 65536 (-b 128) magic 19540119timeMon Apr 27 21:12:01 2015 superblock location 65536 id [ 54875a10 36aa1af2 ] cylgrp dynamic inodes FFSv2 sblock FFSv2 fslevel 5 nbfree 507082 ndir2179nifree 1194404 nffree 1658 file system: /dev/rwd0f format FFSv2 endian little-endian location 65536 (-b 128) magic 19540119timeMon Apr 27 21:11:57 2015 superblock location 65536 id [ 54875a12 1b3d7e20 ] cylgrp dynamic inodes FFSv2 sblock FFSv2 fslevel 5 nbfree 26614256ndir292235 nifree 55388136nffree 148247
daily CVS update output
Updating src tree: P src/distrib/notes/common/main P src/distrib/sets/lists/comp/mi P src/sbin/disklabel/main.c P src/share/man/man9/Makefile U src/share/man/man9/pci_intr_distribute.9 U src/share/man/man9/pci_msi.9 P src/sys/arch/aarch64/include/armreg.h P src/sys/arch/amd64/amd64/mainbus.c P src/sys/arch/amd64/include/types.h P src/sys/arch/arm/arm/core_machdep.c P src/sys/arch/arm/arm/cpu_exec.c P src/sys/arch/arm/cortex/a9_mpsubr.S P src/sys/arch/arm/imx/if_enet.c P src/sys/arch/arm/include/armreg.h P src/sys/arch/evbarm/conf/JETSONTK1 P src/sys/arch/i386/eisa/eisa_machdep.c P src/sys/arch/i386/i386/mainbus.c P src/sys/arch/i386/include/eisa_machdep.h P src/sys/arch/i386/include/types.h P src/sys/arch/sparc64/dev/lom.c P src/sys/arch/sparc64/dev/tda.c P src/sys/arch/x86/conf/files.x86 P src/sys/arch/x86/include/i82093var.h P src/sys/arch/x86/include/intr.h U src/sys/arch/x86/include/intr_distribute.h P src/sys/arch/x86/include/mpconfig.h P src/sys/arch/x86/include/pci_machdep.h P src/sys/arch/x86/include/pci_machdep_common.h P src/sys/arch/x86/include/pic.h P src/sys/arch/x86/isa/isa_machdep.c U src/sys/arch/x86/pci/msipic.c U src/sys/arch/x86/pci/msipic.h P src/sys/arch/x86/pci/pci_intr_machdep.c P src/sys/arch/x86/pci/pci_machdep.c U src/sys/arch/x86/pci/pci_msi_machdep.c P src/sys/arch/x86/pci/pciide_machdep.c P src/sys/arch/x86/x86/intr.c P src/sys/arch/x86/x86/ioapic.c P src/sys/arch/xen/include/intr.h P src/sys/dev/bluetooth/bcsp.c P src/sys/dev/pci/hifn7751.c P src/sys/dev/pci/if_bge.c P src/sys/dev/pci/if_pcn.c P src/sys/dev/pci/if_ti.c P src/sys/dev/pci/pci.c P src/sys/dev/pci/pcireg.h P src/sys/dev/pci/pcivar.h P src/sys/dev/sysmon/sysmon_taskq.c P src/sys/dev/sysmon/sysmon_taskq.h P src/sys/kern/exec_elf.c P src/sys/kern/init_main.c P src/sys/kern/kern_stub.c P src/sys/kern/kern_veriexec.c P src/sys/net/route.c P src/sys/netinet/ip_output.c P src/sys/netinet/tcp_output.c P src/sys/netinet6/in6_pcb.c P src/sys/netinet6/ip6_output.c P src/sys/netinet6/nd6_nbr.c P src/sys/sys/intr.h Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue Apr 28 03:05:25 2015 SUP Scan for current completed at Tue Apr 28 03:07:21 2015 SUP Scan for mirror starting at Tue Apr 28 03:07:21 2015 SUP Scan for mirror completed at Tue Apr 28 03:09:54 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 46478703 Apr 28 03:20 ls-lRA.gz
Re: incorrect super block w recent changes
In article 20150427222335.4cc8c12...@chopper.goathill.org, MLH mlh@goathill With the recent changes (yesterday and today) that allow current to boot again, I can't mount some drives: NetBSD 7.99.13 (GENERIC) #2: Mon Apr 27 14:11:26 EDT 2015 ... mount_ffs: /dev/wd1f on /opt2: incorrect super block fsck can't find anything wrong with the drive and it doesn't appear there is. Earlier kernels have no trouble mounting this drive. Also, shutdown hangs now and never completes. Which is the last working kernel? Can you try reverting the latest change (ffs_vfsops.c,v 1.330) and see if that works for you? Can you also print the cgsizes? christos The last kernel that would compile and boot was on Apr 7, which is what I'm running on it now : NetBSD tiamat 7.99.9 NetBSD 7.99.9 (GENERIC) #0: Tue Apr 7 16:06:41 EDT 2015 The next one that would compile and run was sources from Apr 26. It had the incorrect super block problem as well as sources from today. BTW, with the most recent sources I just tried, shutdown works again so drop that issue. wd0: type: unknown disk: ST1000DM003-1ER label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 1938021 total sectors: 1953525168 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 wd1: type: unknown disk: ST500DM002-1BC1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 969021 total sectors: 976773168 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0
