Re: RPI kernels in -current expected to work?
On 04/06/14 13:01, Frank Kardel wrote: Hi, I see a long stream of fixup: pd fixup: pde ... nothing to do lines scrolling (forever?) after the initial boot kernel messages. The boot process does not seem to make any reasonably observable progress at that point. This happens with self compiled kernels (as of 2014-04-06) and kernels fetched from nyftp for 20140403 and 20140406. The following older kernel works: NetBSD rpi 6.99.38 NetBSD 6.99.38 (RPI) #0: Sat Mar 29 06:14:39 UTC 2014 bui...@b44.netbsd.org:/home/builds/ab/HEAD/evbarm-earmhf/201403290440Z-obj/home/builds/ab/HEAD/src/sys/arch/evbarm/compile/RPI evbarm Best regards, Frank cvs update :) Nick
Re: RPI kernels in -current expected to work?
Great ! Thanks - works again. Frank On 04/06/14 14:43, Nick Hudson wrote: On 04/06/14 13:01, Frank Kardel wrote: Hi, I see a long stream of fixup: pd fixup: pde ... nothing to do lines scrolling (forever?) after the initial boot kernel messages. The boot process does not seem to make any reasonably observable progress at that point. This happens with self compiled kernels (as of 2014-04-06) and kernels fetched from nyftp for 20140403 and 20140406. The following older kernel works: NetBSD rpi 6.99.38 NetBSD 6.99.38 (RPI) #0: Sat Mar 29 06:14:39 UTC 2014 bui...@b44.netbsd.org:/home/builds/ab/HEAD/evbarm-earmhf/201403290440Z-obj/home/builds/ab/HEAD/src/sys/arch/evbarm/compile/RPI evbarm Best regards, Frank cvs update :) Nick
Re: MBuf clusters - what uses them?
On Sat, 5 Apr 2014, Greg Troxel wrote: snip I see no fails counted. Why do you think you are out of clusters? Are you seeing that in dmesg? Or is it just a possible lockup explanation? The mbuf/mbufcluster explanation was offered when I first reported this several months ago. Please describe the lockup symptoms more precisely. Most obvious symptom is sudden lack of network connectivity. A ping to another host on the local network fails with a no buffer space error. Also, look in vmstat -m for anything with fail != 0. No failures ever appear. However, I have tracked mbuf usage via netstat and vmstat, and shortly before the lockup, both numbers showed a sudden increase in utilization. you might also save vmstat -m to a file every 5 minutes, and look before/after the next lockup. Yeah, I was doing this every 1 minute... Someone at that time suggested that bit-torrent could have been doing something nasty, so I stopped my transmission server. The frequency of lockup has dropped dramatically, but not to zero. Another symptom is with postfix... It receives incoming mail from the network, but fails to forward the mail through my local dspam - mailq shows lots of messages in the deferred state due to resources temporarily unavailable errors. (As near as I can tell, postfix uses unix-family sockets for this...) - | 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 | -
Re: HEADS UP: riastradh-drm2 branch merged
On 2014-03-23, at 6:06 PM, David H. Gutteridge wrote: On 2014-03-20, at 6:27 PM, David H. Gutteridge wrote: On Tue, 18 Mar 2014 at 19:17:01, Taylor R Campbell wrote: I merged the riastradh-drm2 branch to HEAD today. This shouldn't cause any problems for anyone, because it touched very little outside sys/external/bsd/drm2 -- it's not hooked into any kernels other than the new amd64/DRMKMS one. But let me know if you observe any fallout. Update to userland X.org should be coming soon, so that userlands can take advantage of the new DRM/KMS drivers. Hello, I doubt I'm telling you anything you don't already know, but I tried compiling a DRMKMS kernel for both amd64 and i386 to test, and neither compiled. With i386, I hit this first: In file included from /usr/builds/netbsd-current/src/sys/external/bsd/drm2/dist/include/drm/drmP.h:52:0, from /usr/builds/netbsd-current/src/sys/external/bsd/drm2/dist/drm/drm_agpsupport.c:34: /usr/builds/netbsd-current/src/sys/external/bsd/drm2/include/linux/pci.h: In function 'pci_bus_alloc_resource': /usr/builds/netbsd-current/src/sys/external/bsd/drm2/include/linux/pci.h:255:6: error: large integer implicitly truncated to unsigned type *** [drm_agpsupport.o] Error code 1 I realize you only provided an amd64 kernel, the implication being i386 might not yet be supported, but I tried it anyway, as the machine I'd test with isn't capable of running 64-bit code. From looking at the code, it's clear you're already aware of the issue, given your XXX notation. error = bus_space_alloc(bst, start, 0xULL /* XXX */, size, align, 0, 0, resource-start, resource-r_bsh); If this is of interest to anyone, I opened a PR detailing some issues that prevent this code from being used on i386. (The PR is 48676.) Dave Recent changes by riastradh@ have made i386 kernels with drm2 enabled buildable, so I've now tested on my somewhat aged machine with an i945GME chipset. Details follow for the curious. With is_console=1 set in src/sys/external/bsd/drm2/i915drm/i915_pci.c the kernel tries to probe/attach to the graphics chipset (I'm not sure exactly how far it gets, the messages flash by too fast) and then fails, causing an apparent kernel panic (or at least a freeze). I'm not able to get any dmesg output saved from it, and the screen simply goes black. The machine doesn't respond to network activity. With is_console=0 set, the kernel boots successfully, but the console is unusable. (A small, fixed white cursor appears in the top left of the screen, and I cannot switch VTs to other text consoles.) The machine does boot multi-user, though, and responds to network activity, so I've gleaned the following dmesg details. Regards, Dave : vendor 0x8086 product 0x27ac (rev. 0x03) agp0 at pchb0: detected 7932k stolen memory agp0: aperture at 0xc000, size 0x1000 i915drmkms0 at pci0 dev 2 function 0 : vendor 0x8086 product 0x27ae (rev. 0x03) drmkms0 at i915drmkms0 drm: Memory usable by graphics device = 256M drm: MTRR allocation failed. Graphics performance may suffer. drm: Supports vblank timestamp caching Rev 1 (10.10.2010). drm: Driver supports precise vblank timestamp query. i915drmkms0: unable to map ROM drm: failed to find VBIOS tables i915drmkms0: unable to map VGA registersdrm kern warning: composite sync not supported drm: initialized overlay support drmkms0: interrupting at ioapic0 pin 16 (i915) snip drm kern warning: composite sync not supported render error detected, EIR: 0x0010 page table error PGTBL_ER: 0x0100 DRM error in i915_report_and_clear_eir: EIR stuck: 0x0010, masking render error detected, EIR: 0x0010 page table error PGTBL_ER: 0x0100 i915drmkms0: framebuffer at 0xda82b000, size 1024x600, depth 32, stride 4096 wsdisplay1 at i915drmkms0 kbdmux 1 wsmux1: connecting to wsdisplay1 fixme: max PWM is zero drmkms0: info: registered panic notifier
Re: RPI kernels in -current expected to work?
On Sun, 06 Apr 2014 at 18:19:19, Frank Kardel wrote: Great ! Thanks - works again. Frank On 04/06/14 14:43, Nick Hudson wrote: On 04/06/14 13:01, Frank Kardel wrote: Hi, I see a long stream of fixup: pd fixup: pde ... nothing to do lines scrolling (forever?) after the initial boot kernel messages. The boot process does not seem to make any reasonably observable progress at that point. This happens with self compiled kernels (as of 2014-04-06) and kernels fetched from nyftp for 20140403 and 20140406. The following older kernel works: NetBSD rpi 6.99.38 NetBSD 6.99.38 (RPI) #0: Sat Mar 29 06:14:39 UTC 2014 builds%b44.netbsd.org@localhost:/home/builds/ab/HEAD/evbarm-earmhf/201403290440Z-obj/home/builds/ab/HEAD/src/sys/arch/evbarm/compile/RPI evbarm Best regards, Frank cvs update :) Nick I was seeing the same thing, and now have a working kernel again too, though I've noticed userland tools that report kernel memory use seem a bit confused after recent commits. (Not that that's a big deal to me, I'm just mentioning it in case it's unexpected.) ps(1) gives: USER PID %CPU %MEM VSZ RSS TTY STAT STARTEDTIME COMMAND root 0 0.0 -10.0 0 4148560 ? DKl 8:28PM 0:04.66 [system] top(1) gives: PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 0 root 960 0K -47808K mmctaskq 0:27 0.00% 0.00% [system] Regards, Dave
lib/libc/ssp/h_stpncpy.c breaks multiple builds
With up-to-date sources, I'm seeing the following error on multiple ports (including evbcf, evbppc, mac68k, sun2, vax) cc1: warnings being treated as errors /build/netbsd-local/src/tests/lib/libc/ssp/h_stpncpy.c: In function 'main': /build/netbsd-local/src/tests/lib/libc/ssp/h_stpncpy.c:44: warning: pointer/integer type mismatch in conditional expression - | 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 | -
daily CVS update output
Updating src tree: P src/crypto/external/bsd/heimdal/heimdal2netbsd P src/crypto/external/bsd/heimdal/dist/lib/roken/resolve.c P src/distrib/sets/lists/debug/mi P src/distrib/sets/lists/man/mi P src/distrib/sets/lists/tests/mi U src/doc/CHANGES P src/etc/rc.d/dhcpcd P src/external/bsd/libpcap/include/config.h P src/include/ssp/string.h P src/lib/libc/ssp/Makefile.inc P src/lib/libc/ssp/stpcpy_chk.c P src/share/man/man4/Makefile U src/share/man/man4/mcp23s17gpio.4 P src/sys/arch/arm/arm32/bus_dma.c P src/sys/arch/evbarm/conf/MIRABOX P src/sys/arch/evbarm/conf/RPI P src/sys/arch/evbarm/conf/std.rpi P src/sys/arch/evbarm/rpi/rpi.h P src/sys/arch/evbarm/rpi/rpi_machdep.c P src/sys/arch/i386/stand/lib/bootmenu.c P src/sys/arch/i386/stand/lib/exec.c P src/sys/arch/i386/stand/lib/menuutils.c P src/sys/arch/powerpc/powerpc/procfs_machdep.c P src/sys/arch/x86/include/loadfile_machdep.h P src/sys/dev/ic/com.c P src/sys/dev/spi/files.spi U src/sys/dev/spi/mcp23s17.c U src/sys/dev/spi/mcp23s17.h P src/sys/dev/usb/usbdevs P src/sys/dev/usb/usbdevs.h P src/sys/dev/usb/usbdevs_data.h P src/sys/external/bsd/drm2/i915drm/i915_pci.c P src/sys/fs/unicode.h P src/sys/net80211/ieee80211_netbsd.c P src/sys/net80211/ieee80211_netbsd.h P src/sys/net80211/ieee80211_rssadapt.c P src/sys/rump/dev/Makefile.rumpdevcomp U src/sys/rump/dev/lib/libpci_if_iwn/Makefile U src/sys/rump/dev/lib/libpci_if_iwn/PCI_IF_IWN.ioconf U src/sys/rump/dev/lib/libpci_if_iwn/iwn_at_pci.c U src/sys/rump/dev/lib/libpci_if_iwn/shlib_version P src/tests/lib/libc/ssp/Makefile U src/tests/lib/libc/ssp/h_stpcpy.c U src/tests/lib/libc/ssp/h_stpncpy.c P src/tests/lib/libc/ssp/t_ssp.sh Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Apr 7 03:05:17 2014 SUP Scan for current completed at Mon Apr 7 03:06:14 2014 SUP Scan for mirror starting at Mon Apr 7 03:06:14 2014 SUP Scan for mirror completed at Mon Apr 7 03:08:32 2014 Updating release-5 src tree (netbsd-5): Updating release-5 xsrc tree (netbsd-5): Running the SUP scanner: SUP Scan for release-5 starting at Mon Apr 7 03:13:27 2014 SUP Scan for release-5 completed at Mon Apr 7 03:13:37 2014 Updating release-6 src tree (netbsd-6): Updating release-6 xsrc tree (netbsd-6): Running the SUP scanner: SUP Scan for release-6 starting at Mon Apr 7 03:22:17 2014 SUP Scan for release-6 completed at Mon Apr 7 03:22:30 2014 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 35966694 Apr 7 03:25 ls-lRA.gz
