Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: So, it looks like updating the kernel and world on ampere2 and enabling builds of main-armv7-default should no longer have main-armv7-default hang-up during graphviz installation (or analogous contexts). Hopefully, that means that main-armv7-default builds will then complete and be distributed. I've set the stop-builds flag on the ampere machines. I'll kick off a cluster build and upgrade them when they finish their current builds (or get stuck). Thanks for chasing this down. Philip
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]
On 2024-05-08 23:53:57 (+0800), Mark Millard wrote: On Apr 29, 2024, at 20:16, Mark Millard wrote: On Apr 29, 2024, at 20:11, Mark Millard wrote: On Apr 29, 2024, at 19:54, Mark Millard wrote: On Apr 28, 2024, at 18:06, Philip Paeps wrote: On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It gets stuck making no progress until manually forced to stop, which leads to huge elapsed times for the incomplete builds: [...] My guess is that FreeBSD has something that broken after bd45bbe440 that was broken as of f5f08e41aa and was still broken at 75464941dc . One thing of possible note: Failing . . . Host OSVERSION: 156 Jail OSVERSION: 1500014 I have finished a package builder refresh this morning. All our builder hosts (except PowerPC - I don't touch those) are now on main-n269671-feabaf8d5389 (OSVERSION 1500018). ampere1 successfully finished its 140releng-armv7-quarterly build, so it looks like the problem with stuck builds was limited to ampere2 building main-armv7. I'll keep a close eye on this one when it starts its next build. I see that main-armv7 started. It queued only 31935 instead of the prior 34528 (or more): it is doing an incremental build instead of a full build. For example, pkg was not built but instead the prior build is in use. Thus bad results from the prior build might be involved in this new build. I'd recommend forcing a full "poudriere bulk -c -a" that does a from-scratch build for the purposes of the main-armv7 test. Actually the test is not going to previde the information we are after as things are. giflib-5.2.2 failed to build, which leads to devel/doxygen being skipped. devel/doxygen was the first one to hang up in the prior 2 failing attempts, if I remember right. giflib-5.2.2 also causes graphics/graphviz to be skipped. graphics/graphviz was installed just before the hangup in all of the example hanups. So the context will not be replicated. We need graphics/giflib to build to actually do the test. Looks like: https://cgit.freebsd.org/ports/commit/graphics/giflib?id=5007109903fc271e3ef0ba01d78781c1fed99f3f is the fix for the graphic/giflib build failure. Well, main-armv7 is building again and things are still getting stuck. So much for my idea. For reference I list the over 10-hr-so-far ones: doxygen-1.9.6_1,2 build-depends 13:03:54 py39-pydot-2.0.0run-depends 12:24:04 py39-pygraphviz-1.6 lib-depends 12:10:38 "ps -alxdww" would likely be appropriate to get a copy of the otuput of. "procstat -k -k" usage and the like on stuck processes would probably be appropriate. Does anyone with appropriate investigative background have login access to ampere2 to take a look at what is getting stuck? This is unfortunate. I'm sure I have the appropriate background, but I'm spread very thin! I'll get as much information as I can about this machine while it's stuck, before I bounce it again. I think it may be worth a try building those ports in isolation on ref14-aarch64, and see what they're trying to do. I'll also set up a set of refX-armv7 jails on that machine. Hopefully we can get to the bottom of this soon. This is a very tedious failure mode. We could also try to put an older armv7 image on the builder jail on ampere2. Depending on whether we have a sufficiently old image, that will either be very straightforward, or a very deep rabbit hole. Thanks again for keeping an eye on this. We really should have better monitoring for stuck builds than "Mark will tell us". :-) Philip
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]
On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It gets stuck making no progress until manually forced to stop, which leads to huge elapsed times for the incomplete builds: [...] My guess is that FreeBSD has something that broken after bd45bbe440 that was broken as of f5f08e41aa and was still broken at 75464941dc . One thing of possible note: Failing . . . Host OSVERSION: 156 Jail OSVERSION: 1500014 I have finished a package builder refresh this morning. All our builder hosts (except PowerPC - I don't touch those) are now on main-n269671-feabaf8d5389 (OSVERSION 1500018). ampere1 successfully finished its 140releng-armv7-quarterly build, so it looks like the problem with stuck builds was limited to ampere2 building main-armv7. I'll keep a close eye on this one when it starts its next build. Philip
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]
On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It gets stuck making no progress until manually forced to stop, which leads to huge elapsed times for the incomplete builds: pd5512ae7b8c6_s75464941dc 34472 12282 (+9196) 107 (+77) 4753 (+2247) 1390 (+529) 15940 parallel_build: Fri, 22 Mar 2024 11:05:01 GMT 651:21:56 p43e3af5f5763_sf5f08e41aa 19809 5919 (+3126) 137 (+100) 5363 (+2741) 1395 (+522) 6995 parallel_build: Wed, 28 Feb 2024 15:46:14 GMT 359:42:14 ampere2 ampere2 alternates between trying to build main-arm64 and main-armv7, so main-armv7 being stuck blocks main-arm64 from building. One can see that all 13 job ID's show over 570 hours: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=pd5512ae7b8c6_s75464941dc It is not random which packages are building when this happens. Compare: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=p43e3af5f5763_sf5f08e41aa By contrast, the 19 Feb 2024 from-scratch (full) build worked: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=pe9c9c73181b5_sbd45bbe440 My guess is that FreeBSD has something that broken after bd45bbe440 that was broken as of f5f08e41aa and was still broken at 75464941dc . It looks like ampere2 is going to end up in this state again: https://pkg-status.freebsd.org/ampere2/build.html?mastername=main-armv7-default&build=p1c7a816cd0ad_s1bd4f769ca It's got a couple of things stuck in -depends already. I'll keep an eye on it for the next hour or two. If no progress is made, I'll kill this build and force an upgrade. The next build will start at 01:01 UTC Sunday. So we won't have long to wait before it tries again. ampere1 is chewing away at llvm, and doesn't look stuck. ampere3 has been upgraded. Philip
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]
On 2024-04-24 02:12:41 (+0800), Mark Millard wrote: On Apr 19, 2024, at 07:16, Philip Paeps wrote: On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It gets stuck making no progress until manually forced to stop, which leads to huge elapsed times for the incomplete builds: pd5512ae7b8c6_s75464941dc 34472 12282 (+9196) 107 (+77) 4753 (+2247) 1390 (+529) 15940 parallel_build: Fri, 22 Mar 2024 11:05:01 GMT 651:21:56 p43e3af5f5763_sf5f08e41aa 19809 5919 (+3126) 137 (+100) 5363 (+2741) 1395 (+522) 6995 parallel_build: Wed, 28 Feb 2024 15:46:14 GMT 359:42:14 ampere2 ampere2 alternates between trying to build main-arm64 and main-armv7, so main-armv7 being stuck blocks main-arm64 from building. One can see that all 13 job ID's show over 570 hours: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=pd5512ae7b8c6_s75464941dc It is not random which packages are building when this happens. Compare: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=p43e3af5f5763_sf5f08e41aa By contrast, the 19 Feb 2024 from-scratch (full) build worked: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=pe9c9c73181b5_sbd45bbe440 My guess is that FreeBSD has something that broken after bd45bbe440 that was broken as of f5f08e41aa and was still broken at 75464941dc . I'll kill the build on ampere2 again. Thanks for the nudge. We don't really have good monitoring for this. Also: builds should time out after 36 hours. The fact that this one does not is a bug in itself. Philip [hat: clusteradm] I'll note that I've never managed to replicate the problem for building for armv7 on aarch64. But my context never has the likes of: QUOTE Host OSVERSION: 156 Jail OSVERSION: 1500015 . . . !!! Jail is newer than host. (Jail: 1500015, Host: 156) !!! !!! This is not supported. !!! !!! Host kernel must be same or newer than jail. !!! !!! Expect build failures. !!! END QUOTE but always has the two OSVERSION's the same, such as: Host OSVERSION: 1500015 Jail OSVERSION: 1500015 or, recently, Host OSVERSION: 1500018 Jail OSVERSION: 1500018 My bulk runs do go through the sequence where the hangups have repeated for main-armv7 on ampere2. I wonder what would happen if "Host OSVERSION" was updated (modernized) to match the modern "Jail OSVERSION" that would be used? The package builders are due for a regular refresh to newer -CURRENT dogfood. I'll do the aarch64 builders first this time. I've set /root/stop-builds on them. I'll upgrade them when they go idle. Or I'll kill them if they take much longer to build what they're building. It annoys me that they do not stop building after 36 hours, like they're supposed to. They're currently running: n266879-6abee52e0d79 2023-12-09 01:06:28 jlduran strfmon: Silence scan-build warning Our current clusteradm build is: n269399-bbc6e6c5ec8c 2024-04-14 03:12:36 sigsys daemon: fix -R to enable supervision mode I may do a new build while waiting for them to go idle: - quarterly 140arm64 1b931669de11 parallel_build 28776 15299 33 588 985 0 11871 3D:01:08:29 https://pkg-status.freebsd.org/ampere1/build.html?mastername=140arm64-quarterly&build=1b931669de11 - default main-arm64 p1c7a816cd0ad_s1bd4f769caf parallel_build 34528 19888 65 669980 0 12926 4D:00:52:21 https://pkg-status.freebsd.org/ampere2/build.html?mastername=main-arm64-default&build=p1c7a816cd0ad_s1bd4f769caf - default 140releng-armv7 2910ff97e727 parallel_build 34543 14826 60 5539 1397 0 12721 1D:09:35:28 https://pkg-status.freebsd.org/ampere3/build.html?mastername=140releng-armv7-default&build=2910ff97e727 Philip
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, elapsed so far: 651:21:56]
On 2024-04-18 23:02:30 (+0800), Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It gets stuck making no progress until manually forced to stop, which leads to huge elapsed times for the incomplete builds: pd5512ae7b8c6_s75464941dc 34472 12282 (+9196) 107 (+77) 4753 (+2247) 1390 (+529) 15940 parallel_build: Fri, 22 Mar 2024 11:05:01 GMT 651:21:56 p43e3af5f5763_sf5f08e41aa 19809 5919 (+3126) 137 (+100) 5363 (+2741) 1395 (+522) 6995 parallel_build: Wed, 28 Feb 2024 15:46:14 GMT 359:42:14 ampere2 ampere2 alternates between trying to build main-arm64 and main-armv7, so main-armv7 being stuck blocks main-arm64 from building. One can see that all 13 job ID's show over 570 hours: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=pd5512ae7b8c6_s75464941dc It is not random which packages are building when this happens. Compare: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=p43e3af5f5763_sf5f08e41aa By contrast, the 19 Feb 2024 from-scratch (full) build worked: http://ampere2.nyi.freebsd.org/build.html?mastername=main-armv7-default&build=pe9c9c73181b5_sbd45bbe440 My guess is that FreeBSD has something that broken after bd45bbe440 that was broken as of f5f08e41aa and was still broken at 75464941dc . I'll kill the build on ampere2 again. Thanks for the nudge. We don't really have good monitoring for this. Also: builds should time out after 36 hours. The fact that this one does not is a bug in itself. Philip [hat: clusteradm]
freebsd-current@freebsd.org
On 2022-06-13 00:16:55 (+0800), Mark Millard wrote: ampere3's activity is not showing up on the page: https://pkg-status.freebsd.org/?all=1&type=package but: http://ampere3.nyi.freebsd.org/#latest_builds and: http://ampere3.nyi.freebsd.org/build.html?mastername=130arm64-default&build=b44e82e7d313 shows a currently active build (but with only 2 ports remaining). pkg-status.freebsd.org is maintained on GitHub, outside the clusteradm automation. I sent in this patch a couple of months ago, when I set up ampere3: https://github.com/bdrewery/pkg-status.freebsd.org/pull/12/files This was merged last week but it doesn't look like there's any automation to keep the running infrastructure in sync with that repository. There were some reassuring screams in a logfile after I chanted some incantations in a the jail running pkg-status.freebsd.org. Let me know if that fixed it. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: Spam mail being sent via the FreeBSD mailing lists
On 2021-05-26 22:50:57 (+0800), Julian H. Stacey wrote: Kurt Jaeger wrote: Hi! On May 25, 2021, at 8:53 PM, jake h wrote: I have recently received several pieces of spam mail, apparently sent via this mailing list. These pieces of mail are the usual spam formula; Your phone has a virus, Ads, Fake blackmail, so on and so forth. Has anyone else noticed these spam emails, or is it just me? I'm receiving these too. It looks like the servers are bouncing some of them just for me, even. And I'm receiving not just from this list; also from freebsd-hackers@ and ports@. postmaster@ is aware of the problem, we do not yet have a clear-cut solution and we're investigating. -- p...@opsec.eu+49 171 3101372Now what ? I'm on most lists & also seen much spam lately. Changing Mailman list configs to only allowing postings from subscribed addresses could dump nearly all spam; (I'm a Mailman admin elsewhere ). This was how the majority of FreeBSD mailing lists were configured. Most lists were set to discard postings from non-subscribers. Some were set to hold. A few were set to reject. But @freebsd.org has prefered open lists for near all lists. Best only for the initial fresh- after- install- questions@, IMO. This has not been true for a good while now. Historically, nearly all our lists were indeed open. In recent years, we've made most lists subscriber-only, with some exceptions and whitelists. List back end responses to eg isp@ & hackers@ have recently migrated from Mailman to Mlmmj, I guess that shouldn't directly affect spam protection ? but it'd be interesting to know what advantage the migration might bring @freebsd.org ? For one thing, running supported software means we can continue upgrading our mailservers with fewer worries. Mailman 2 relies on Python 2, which has unfortunately become abandonware. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: pkg for 14-current
On 2021-01-26 11:14:53 (+0800), Mark Millard wrote: Philip Paeps philip at freebsd.org wrote on Mon Jan 25 21:40:03 UTC 2021 : The first package build for 14-CURRENT is visible on the mirrors now (as of a couple of minutes ago). It has been a bit so I tried and it failed for what I tried so I looked at http://pkg.freebsd.org . It reported: QUOTE This is pkg0.tuk.FreeBSD.org - a West Coast, USA mirror for FreeBSD downloads. END QUOTE But nothing with FreeBSD:14 was listed on the page. So I explicitly tried: http://pkg.freebsd.org/FreeBSD:14:i386/ http://pkg.freebsd.org/FreeBSD:14:amd64/ http://pkg.freebsd.org/FreeBSD:14:aarch64/ http://pkg.freebsd.org/FreeBSD:14:powerpc64/ and only the first two were found. I've not updated the index.html pages on the mirrors yet. (Actually, I did update them, but I forgot to commit the change - I'll go and do that now.) So far, only the amd64 and i386 builds appear to have completed. I've not seen builds completed for the other archs. Builds should trickle in for the other archs when they complete. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg for 14-current
On 2021-01-24 18:18:29 (+0800), Yasuhiro Kimura wrote: From: Masachika ISHIZUKA Subject: pkg for 14-current Date: Sun, 24 Jan 2021 19:11:28 +0900 (JST) Hi. I updated to 14-current from 13-current and reinstalled ports-mgmt/pkg. I cannot get meta files for 14-current. How can I use pkg on 14-current ? # pkg update Updating FreeBSD repository catalogue... pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: Not Found repository FreeBSD has no meta file, using default settings pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: Not Found Unable to update repository FreeBSD Error updating repositories! All what you can do is to wait until build of offical packages for 14-CURRENT has completed unless you build them by yourself. The first package build for 14-CURRENT is visible on the mirrors now (as of a couple of minutes ago). Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Files in /usr/share/misc
On 2021-01-24 21:35:40 (+0800), mj-mailingl...@gmx.de wrote: - some FreeBSD project related files, like: bsd-family-tree.dot, committers-*.dot, organization.dot These would better be part of the documentation. BTW, on 12.x they are out of date: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251701 I think we've never bothered merging those to older stable branches because there's not really any point. It might be worth doing so just before a release or something but there's very little benefit. - development(?) related files, like: pci_vendors, scsi_modes, usb_hid_usages, usbdevs, windrv_stub.c I don't know if these files are used during build-/runtime E.g. pci_vendors is used by pciconf(8) and windrv_stub.c is used by ndiscvt(8). I'm sure the others are used by similar utilities that escape my memory. - some files which are used during (build-?/)runtime: magic, magic.mgc, termcap, termcap.db Shouldn't these be in a more specific place? They are pretty static, so the "var" part in /var/db does not fit, but services.db is located there, too. The magic* files are used by file(1). See termcap(5) for the others. - is the fonts folder in base, or did some port create it? I'm not sure. Hah. I like the comment in hier(7) about this directory. :-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Getting /usr/src to match specific git hash?
On 2021-01-25 10:57:19 (+0800), Thomas Mueller wrote: It is in the mini primer I wrote, along with how to bisect and other useful things. This will migrate into the handbook once the doc tree converts to asciidoc (happening this weekend). https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md I looked at your mini-primer webpage, but can't find the answer to my question? How cat one track multiple branches with git without keeping entirely separate trees? Does something like this do what you want: git worktree add ../13-stable remotes/freebsd/stable/13 I see there is a git worktree command, which can keep two or more branches in much diskspace than keeping the trees entirely separately (as I did with subversion and cvs). In my case, I would want to be able to choose between main and stable-13 when compiling; have given up on releng-12 because of problems with ethernet and wireless drivers. Worktrees should be able to do what you want in this case. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Beta Git repo for ports
On 2021-01-22 14:24:47 (+0800), Graham Perrin wrote: Via <https://www.freebsd.org/news/status/report-2020-10-2020-12.html#Git-Migration-Working-Group> : <https://cgit-dev.freebsd.org/ports/> Please: where to file enhancement requests (or bugs) for development of this cgit service for ports? Is there a GitHub repo where issues might be raised? Or, are group e-mails (all four of you) preferred? The g...@freebsd.org mailing list has been very responsive to suggestions. That's probably a good place for them. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RTC on ROCKPRO64
On 2021-01-22 23:16:29 (+0800), Henri Hennebert wrote: I have tested https://reviews.freebsd.org/D22692 on my ROCKPRO64 with a battery and it works. (After correcting the typo at line 516 of rk805.c) Is it possible to merge it for 13.0-RELEASE ? It looks like that revision needs some changes before it can be accepted. I'll see if I can make those changes. Thanks. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: what's going on with SVN ?
On 2020-11-21 00:27:52 (+0800), Claude Buisson wrote: On 2020-11-20 16 h 01, Philip Paeps wrote: On 2020-11-20 14:34:28 (+0100), Claude Buisson wrote: On 2020-11-20 12 h 38, David Wolfskill wrote: On Fri, Nov 20, 2020 at 11:51:32AM +0100, Claude Buisson wrote: Hello, $ svnsync sync file:///home/svnmirror/base svnsync: E170013: Unable to connect to a repository at URL 'https://svn.freebsd.org/base' svnsync: E65: Error running context: No route to host $ host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.freebsd.org has address 213.138.116.72 svnmir.geo.freebsd.org has IPv6 address 2001:41c8:112:8300::e6a:0 svnmir.geo.freebsd.org mail is handled by 0 . $ svnsync sync file:///home/svnmirror/base https://213.138.116.72:443/base Error validating server certificate for 'https://213.138.116.72:443': - The certificate hostname does not match. Certificate information: - Hostname: svn.freebsd.org - Valid: from Oct 17 20:29:49 2020 GMT until Jan 15 20:29:49 2021 GMT - Issuer: Let's Encrypt Authority X3, Let's Encrypt, US - Fingerprint: 0C:6D:4D:AF:97:EB:B4:EC:94:F3:8C:E2:BD:9F:E8:8C:C8:CF:15:81 (R)eject, accept (t)emporarily or accept (p)ermanently? t idem ports,doc CBu I don't see that; indeed, I just updated my local private mirrors without issue. DNS resolution from here: g1-48(12.2-S)[1] host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.freebsd.org has address 96.47.72.69 svnmir.geo.freebsd.org has IPv6 address 2610:1c1:1:606c::e6a:0 svnmir.geo.freebsd.org mail is handled by 0 . g1-48(12.2-S)[2] Peace, david It looks like the problem is linked to IPv6: $ svnsync sync file:///home/svnmirror/base https://[2001:41c8:112:8300::e6a:0]:443/base svnsync: E170013: Unable to connect to a repository at URL 'https://[2001:41c8:112:8300::e6a:0]/base' svnsync: E65: Error running context: No route to host Errr ... I upgraded the bme svn mirror recently. I checked that svn still worked but I'm not sure if I checked ipv6 and legacy ip individually. I'll go and double-check ipv6. Thanks for pointing this out. Sorry for breaking it. Dogfood so tasty. Philip [clusteradm pointy hat collector] It seems that the problem was the consequence of some bad IPv6 routing by my ISP. After many useless tests of my local gear, everything is back to normal. Thanks for your interest ! Good to hear I didn't botch it this time. ;-) Thanks for keeping my feet close to the fire! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: what's going on with SVN ?
On 2020-11-20 14:34:28 (+0100), Claude Buisson wrote: On 2020-11-20 12 h 38, David Wolfskill wrote: On Fri, Nov 20, 2020 at 11:51:32AM +0100, Claude Buisson wrote: Hello, $ svnsync sync file:///home/svnmirror/base svnsync: E170013: Unable to connect to a repository at URL 'https://svn.freebsd.org/base' svnsync: E65: Error running context: No route to host $ host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.freebsd.org has address 213.138.116.72 svnmir.geo.freebsd.org has IPv6 address 2001:41c8:112:8300::e6a:0 svnmir.geo.freebsd.org mail is handled by 0 . $ svnsync sync file:///home/svnmirror/base https://213.138.116.72:443/base Error validating server certificate for 'https://213.138.116.72:443': - The certificate hostname does not match. Certificate information: - Hostname: svn.freebsd.org - Valid: from Oct 17 20:29:49 2020 GMT until Jan 15 20:29:49 2021 GMT - Issuer: Let's Encrypt Authority X3, Let's Encrypt, US - Fingerprint: 0C:6D:4D:AF:97:EB:B4:EC:94:F3:8C:E2:BD:9F:E8:8C:C8:CF:15:81 (R)eject, accept (t)emporarily or accept (p)ermanently? t idem ports,doc CBu I don't see that; indeed, I just updated my local private mirrors without issue. DNS resolution from here: g1-48(12.2-S)[1] host svn.freebsd.org svn.freebsd.org is an alias for svnmir.geo.freebsd.org. svnmir.geo.freebsd.org has address 96.47.72.69 svnmir.geo.freebsd.org has IPv6 address 2610:1c1:1:606c::e6a:0 svnmir.geo.freebsd.org mail is handled by 0 . g1-48(12.2-S)[2] Peace, david It looks like the problem is linked to IPv6: $ svnsync sync file:///home/svnmirror/base https://[2001:41c8:112:8300::e6a:0]:443/base svnsync: E170013: Unable to connect to a repository at URL 'https://[2001:41c8:112:8300::e6a:0]/base' svnsync: E65: Error running context: No route to host Errr ... I upgraded the bme svn mirror recently. I checked that svn still worked but I'm not sure if I checked ipv6 and legacy ip individually. I'll go and double-check ipv6. Thanks for pointing this out. Sorry for breaking it. Dogfood so tasty. Philip [clusteradm pointy hat collector] -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn.freebsd.org
On 2020-11-11 10:20:55 (-0800), Cy Schubert wrote: I've noticed that svn.freebsd.org has been lagging with commits from repo.freebsd.org. Is this a change or is there something broken? (I use svn.freebsd.org as the source of truth at $JOB.) At the moment svn.freebsd.org is at r367589 while repo.freebsd.org is at r367596. clusteradm is aware that svn has lagged a few times this week. The problems started after I upgraded the main mirror the others pull from. We suspect an incompatibility somewhere. Li-Wen made a change last night that will hopefully fix it. If it didn't ... we'll try something else! Apologies for the inconvenience. We're looking into it. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Office Hours today @ 18:00 UTC - Core Candidates
On 2020-05-31 00:52:48 (+0800), Rodney W. Grimes wrote: > -- Start of PGP signed section. >> On 2020-05-27 22:01, Philip Paeps wrote: >>> On 2020-05-27 22:35:14 (+0800), Allan Jude wrote: >>>> Sorry for the late notice, I thought I sent this last week. >>>> >>>> After the slate of candidates was finalized last week, I invited all of >>>> them to join a live stream today at 18:00 UTC to answer questions from >>>> the FreeBSD Community. >>> >>> Do you ever plan to schedule one of these at a time that works for those >>> of us in the eastern hemisphere? >>> >>> 18:00 UTC is 02:00 in Hong Kong, Taiwan and China, 03:00 in Japan and >>> 04:00 in the east of Australia to name but a couple of places where we >>> have sizeable (or at least non-zero) populations of FreeBSD developers. >>> >>> I'm sure we can watch the recordings after the fact, but I'm sure some >>> of us would also welcome the opportunity to ask questions in real time. >> >> Philip: We did one at 02:00 UTC on April 16th. But attendance was only >> ~20, compared to ~65 for the 18:00 UTC slot. > > Since I have no idea on what our global proportions per time zone are > I can not tell if that is a good showing or a not so good. No single timeslot is going to be great for everyone. Alternating between times convenient for different groups of people gives a better chance of reaching everyone though. The reason for the low turnout at 02:00 UTC (mid-morning to early afternoon on this side of the world) might have been people working. With only one session scheduled during daylight in this hemisphere, it's difficult to draw any conclusions. > Do we have any data on the global distribution of @developers? Not a completely accurate one. :-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Office Hours today @ 18:00 UTC - Core Candidates
On 2020-05-30 22:53:42 (+0800), Allan Jude wrote: On 2020-05-27 22:01, Philip Paeps wrote: On 2020-05-27 22:35:14 (+0800), Allan Jude wrote: Sorry for the late notice, I thought I sent this last week. After the slate of candidates was finalized last week, I invited all of them to join a live stream today at 18:00 UTC to answer questions from the FreeBSD Community. Do you ever plan to schedule one of these at a time that works for those of us in the eastern hemisphere? 18:00 UTC is 02:00 in Hong Kong, Taiwan and China, 03:00 in Japan and 04:00 in the east of Australia to name but a couple of places where we have sizeable (or at least non-zero) populations of FreeBSD developers. I'm sure we can watch the recordings after the fact, but I'm sure some of us would also welcome the opportunity to ask questions in real time. Philip: We did one at 02:00 UTC on April 16th. But attendance was only ~20, compared to ~65 for the 18:00 UTC slot. https://wiki.freebsd.org/OfficeHours Would you be willing to help host/promote another attempt for a more Asia friendly time? I must have missed that announcement. All the other ones were at 18:00 UTC (02:00 Asia/Hong_Kong). Thanks for the pointer. I'm happy to join if it's not at crazy o'clock in the morning. :-) It would be good to alternate between "convenient for the far west" and "convenient for the far east". Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Office Hours today @ 18:00 UTC - Core Candidates
On 2020-05-27 22:35:14 (+0800), Allan Jude wrote: Sorry for the late notice, I thought I sent this last week. After the slate of candidates was finalized last week, I invited all of them to join a live stream today at 18:00 UTC to answer questions from the FreeBSD Community. Do you ever plan to schedule one of these at a time that works for those of us in the eastern hemisphere? 18:00 UTC is 02:00 in Hong Kong, Taiwan and China, 03:00 in Japan and 04:00 in the east of Australia to name but a couple of places where we have sizeable (or at least non-zero) populations of FreeBSD developers. I'm sure we can watch the recordings after the fact, but I'm sure some of us would also welcome the opportunity to ask questions in real time. Thank you. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] removing/conditionalising WERROR= in Makefiles
On 2011-12-26 10:10:40 (+), Alexander Best wrote: > i grep'ed through src/sys and found several places where WERROR= was set in > order to get rid of the default -Werror setting. i tried to remove those > WERROR= overrides from any Makefile, where doing so did not break tinderbox. > > in those cases, where it couldn't be completely removed, i added conditions to > only set WERROR= for the particular achitecture or compiler, where tinderbox > did not suceed without the WERROR=. Wouldn't it be better to set WARNS=x rather than WERROR=? WERROR= says "this code has bugs, it breaks tinderbox" whereas WARNS=x says "this code has the following kind of bugs which break tinderbox". Possibly wrapped in an architecture-test where appropriate. - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on arm/arm
ES >> TB --- 2011-11-17 19:46:26 - MAKEOBJDIRPREFIX=/obj >> TB --- 2011-11-17 19:46:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin >> TB --- 2011-11-17 19:46:26 - SRCCONF=/dev/null >> TB --- 2011-11-17 19:46:26 - TARGET=arm >> TB --- 2011-11-17 19:46:26 - TARGET_ARCH=arm >> TB --- 2011-11-17 19:46:26 - TZ=UTC >> TB --- 2011-11-17 19:46:26 - __MAKE_CONF=/dev/null >> TB --- 2011-11-17 19:46:26 - cd /src >> TB --- 2011-11-17 19:46:26 - /usr/bin/make -B buildkernel KERNCONF=KB920X >>>>> Kernel build for KB920X started on Thu Nov 17 19:46:27 UTC 2011 >>>>> stage 1: configuring the kernel >>>>> stage 2.1: cleaning up the object tree >>>>> stage 2.2: rebuilding the object tree >>>>> stage 2.3: build tools >>>>> stage 3.1: making dependencies >>>>> stage 3.2: building everything >> [...] >> objcopy --only-keep-debug if_sf.ko.debug if_sf.ko.symbols >> objcopy --strip-debug --add-gnu-debuglink=if_sf.ko.symbols if_sf.ko.debug >> if_sf.ko >> ===> sfxge (all) >> cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc >> -DHAVE_KERNEL_OPTION_HEADERS -include >> /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-common -g -DDEBUG=1 >> -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 >> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs >> -fdiagnostics-show-option -c /src/sys/modules/sfxge/../../dev/sfxge/sfxge.c >> cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc >> -DHAVE_KERNEL_OPTION_HEADERS -include >> /obj/arm.arm/src/sys/KB920X/opt_global.h -I. -I@ -I@/contrib/altq >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -fno-common -g -DDEBUG=1 >> -I/obj/arm.arm/src/sys/KB920X -mcpu=arm9 -ffreestanding -std=iso9899:1999 >> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs >> -fdiagnostics-show-option -c >> /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c >> cc1: warnings being treated as errors >> /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c: In function >> 'sfxge_dma_alloc': >> /src/sys/modules/sfxge/../../dev/sfxge/sfxge_dma.c:138: warning: large >> integer implicitly truncated to unsigned type [-Woverflow] >> *** Error code 1 > >I've already contacted philip about these build issues (all 32-bit > archs -- and I think ia64 -- currently fail to build via tinderbox > because of this error). Bottom line is that I think this driver should > be removed from all 32-bit builds.. was waiting for feedback from him > on that. I have just committed a change to modules/Makefile to limit the build to amd64. I see that Marius has committed changes to fix the build on other architectures, but I'd like to make sure the driver actually runs on them before adding the driver to them again. - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Synaptics PS/2 TouchPad
On 2003-11-14 11:24:07 (+1030), Daniel O'Connor <[EMAIL PROTECTED]> wrote: > On Thursday 13 November 2003 22:54, Philip Paeps wrote: > > I've recently started work on getting psm to support Synaptics TouchPads > > more fully: virtual scrollbars, up/down buttons, multiple finger > > detection, etc. I have the basics working, but my brain has been too > > fried lately to deal with the maths of translating absolute coordinates to > > sensibly accelerated motions. > > Ooh nice :) > Can you put it up somewhere so I can have a look? The idea is nice, the code is a little less nice. I'll clean it up today, and find a webserver to dump it on. Watch this space :-) - Philip -- Philip Paeps Please don't CC me, I am subscribed to the list. BOFH Excuse #41: interrupt configuration error ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Synaptics PS/2 TouchPad
On 2003-11-13 09:12:54 (+), Dave Smith <[EMAIL PROTECTED]> wrote: > Has anybody managed to get a Synaptics touchpad working on -current with > ACPI? It works just fine on my Asus L3500H, with or without ACPI. I've recently started work on getting psm to support Synaptics TouchPads more fully: virtual scrollbars, up/down buttons, multiple finger detection, etc. I have the basics working, but my brain has been too fried lately to deal with the maths of translating absolute coordinates to sensibly accelerated motions. > I have a Compaq Presario 2143 and the touchpad is not detected with ACPI > enabled. With ACPI disabled it appears and works perfectly. Which Synaptics TouchPad do you have? Does psm say anything useful when you tell it to be verbose? - Philip -- Philip Paeps Please don't CC me, I am subscribed to the list. A man should be greater than some of his parts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [acpi-jp 2705] Re: Odd ACPI behavior
On 2003-09-29 13:33:06 (-0700), Nate Lawson <[EMAIL PROTECTED]> wrote: > On Mon, 29 Sep 2003, Kevin Oberman wrote: > > > From: John Baldwin <[EMAIL PROTECTED]> > > > On 29-Sep-2003 Kevin Oberman wrote: > > > > I recently noticed that, when I boot with ACPI on my IBM T30, I get > > > > errors trying to probe the BIOS disabled sio1. This does not happen > > > > under apm and happens twice(?) when booting with ACPI and happens even > > > > though I have the line 'hint.sio.1.disabled="1"' in > > > > /boot/device.hints. > > > > > > Do you kldload a module at some point during your boot? If so, that > > > would explain the double probe. > > > > Yes, it would, but I am not loading any kernel modules except the slightly > > automatic loads of ACPI, itself and a few others which should not cause a > > probe: ntfs, linux, linprocfs, and daemon_saver. > > ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: There's a bit more weirdness in this regard. I think the ACPI attaching twice is part of the story, but it doesn't appear to be all. As far as I can tell, it's also to do with acpi attaching after something else is already attached. The really funny thing is that acpi tries to attach (twice?) every time the module is 'tickled' in some way. Using my acpi_asus driver as an example: Just booting the machine with acpi and my module loading after the kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc04fc000. [...] Preloaded elf module "/boot/kernel/acpi_asus.ko" at 0xc04fc374. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04fc424. For some reason, acpi always insists on being the last module loaded. That might be something in my configuration though? It's slightly annoying as acpi_asus depends on acpi. Then we get the first acpi attachment, which for some reason always fails on me: sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled A bit later, there's the second attachment, which works, but complains about a nonexistent sio: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled When I unload the acpi_asus module, nothing funny happens, when I reload it, however: sio4: configured irq 3 not in bitmap of probed irqs 0 sio4: port may not be enabled It appears as though 2 and 3 are skipped because they're marked as disabled in device.hints. Funny that it doesn't try a sio4 at boottime, only if it's loaded after acpi is already present. When I boot, acpi_asus loads before acpi, complaining that it needs acpi, and loads it, then acpi tries to load, complaining that it's already there. Then we get the mysterious sio1, which doesn't exist, popping up. Very odd stuff, I've been looking into this, but as it's not really a problem (everything works), I've not looked too hard yet :-) - Philip [of course, I might be very wrong :-)] -- Philip Paeps Please don't CC me, I am subscribed to the list. BOFH Excuse #166: /pub/lunch ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Tonight's current breaks IPFILTER
On 2003-09-26 21:56:08 (-0400), David Gilbert <[EMAIL PROTECTED]> wrote: > Tonight's current breaks compiling IPFILTER. It complains that it can't > find the 'PFIL_OUT' symbol. The top entry in UPDATING insists that you stick PFIL_HOOKS in your configuration. I've just rebuilt a kernel with that option and the IPFILTER bits and it works perfectly. Cheers, - Philip -- Philip Paeps Please don't CC me, I am subscribed to the list. If you have a difficult task give it to a lazy man, he will find an easier way to do it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: when should 5.x be stable enough for web servers
On 2003-08-16 18:10:38 (-0400), Eriq Lamar <[EMAIL PROTECTED]> wrote: > On i386 hardware and two processors amd mp. should I wait for 5.2. I've been running 5.1-current on a few servers, and I've not bumped into any serious problems. I have -stable machines nearby 'just in case' though, and my backups are fairly thorough :-) - Philip -- Philip Paeps Please don't CC me, I am subscribed to the list. BOFH Excuse #75: There isn't any problem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Plea for base system trim
On 2003-03-06 02:17:19 (+0100), Brad Knowles <[EMAIL PROTECTED]> wrote: > At 2:07 AM +0100 2003/03/06, Philip Paeps wrote: > > Speaking of ndc, I think that's a BIND8-ism. > > Indeed, it is. With BIND-9, ndc won't even work I discovered that the unpleasant way. Typing ndc gave me a long list of socket errors and other general unhappiness. Even after quite a while, I still find myself forgetting the 'r' in ndc. Good I have an alias :-) > > Could the port be convinced to symlink it to rndc when set to replace the > > base, or would that confuse other things? Currently, I'm just aliasing it > > in my shell, but that seems a bit hackish :-) > > That could potentially be done, but keep in mind that there are some things > that ndc can do that rndc can't -- "ndc start" being one of the big ones. Mmm, true. For all purposes, however, rndc is the ndc of BIND9, and I doubt I'm the only DNS-admin who's typed ndc so often it's become a nervous tic :-) I didn't realise the 'ndc start' bit though. Sounds a bit like a chicken/egg situation? Life's little existential mysteries, eh? - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #329: Server depressed, needs Prozac To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Plea for base system trim
On 2003-03-05 16:46:04 (-0800), Doug Barton <[EMAIL PROTECTED]> wrote: > On Thu, 6 Mar 2003, Philip Paeps wrote: > > Is it actually possible for one to build a custom release without the > > ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but > > what does 'NO_BIND=true' actually do? If I were to make a release like > > that, would that end me up without resolver as well? > > It's not as thorough as I think it should be. I plan to get cracking on this > now that I've got my ports more or less whipped into shape pre-freeze. Thanks! The possibility of having a way to completely erradicate the 'superfluous' bits of BIND sounds very appealing. I'd be happy to break some machines to help test this :-) > > Perhaps a NO_NSLOOKUP flag? ;-) > > Yeah, I'll add that along with the PIGS_WILL_FLY flag. *grin* > > Now my fiddling with the BIND port is reduced to making stuff live under > > /var/namedb instead of /etc/namedb as I like having / mounted read-only as > > much as possible. > > One way you can do this fairly easily with PORT_REPLACES_BASE is to have > your chroot tree look something like this: > > /var/named/ > /var/named/etc/namedb/named.conf (etc) > > Then have /etc/namedb be a symlink to /var/named/etc/namedb, with > 'directory "/etc/namedb";' in your named.conf file. That looks a lot cleaner than what I've got now. Good project for tomorrow morning. Also gets rid of the confusing (to some) "directory "/"' in the config, and allows those obsessed with editing /etc/namedb/named.conf to find themselves at home. > That way, both named and ndc "see" the same picture of the system, in and > out of the chroot tree. Speaking of ndc, I think that's a BIND8-ism. Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) > I already use this at work, and I plan to add a lot of this config to the > base itself here pretty soon. But you can easily get a head start on it now > using what I described above. Briliant! I'll have people congratulate me on the cleanliness of my nameserver by lunchtime tomorrow :-P - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. If you see a man approaching you with the obvious intent of doing you good, you should run for your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Plea for base system trim
On 2003-03-05 02:14:16 (-0800), Doug Barton <[EMAIL PROTECTED]> wrote: > On Wed, 5 Mar 2003, Subscriber wrote: > > Would the powers that be please consider removing sendmail, bind and > > openssl from the base system, as was done for perl with 5.0? > > For example, as BIND maintainer I actually _support_ the theory of removing > BIND, however the reality is a little different. There are three main > components of BIND; the named stuff (sbin/named, sbin/ndc, etc.), the > userland stuff (dig, host, etc.), and the resolver library. Of those three > things, we actually need the last two in order to include ourselves in a > useful definition of "Unix system" Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? Likewise, would building 'NO_SENDMAIL=true' build me a pristine system void of Sendmail bits, or will there always be some stuff left? If those two knobs do what they promise to do, it should be fairly trivial to compare a custom release tree with the installed base, and nuke the things one doesn't like from the base-system at will? Or am I missing something? :-) I'm pretty happy about having BIND and Sendmail in the base-system. Disk space costs nearly nothing these days, and as long as they're not running (and have their executable bits stripped, 'just in case'), I don't particularly mind them taking up a few bytes of room. > (although I'd LOVE to nuke nslookup, if I thought I could ever live down the > whining and crying it would cause). :-) Perhaps a NO_NSLOOKUP flag? ;-) > So keeping BIND in the base actually serves a purpose. Similar arguments can > be made for the other components you listed. Definitely! > Now that said, I've been working off and on to make it easier to replace > parts of the base with stuff from the ports. Both BIND ports have > PORT_REPLACES_BASE_ Makefile options, and I know that they are useful > because I use them at work. I just spotted those flags a few days ago. They're very useful. Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #193: Did you pay the new Support Fee? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SB Live goes silent after pcm commit
On 2003-02-26 01:49:14 (+0100), Olivier Houchard <[EMAIL PROTECTED]> wrote: > On Tue, Feb 25, 2003 at 11:13:23PM +0100, ?yvind Rakv?g wrote: > > I believe the commit Feb 20 17:31:11 2003 UTC on > > src/sys/dev/sound/pci/emu10k1.c broke something. > > > > With a kernel built from 17:00 sources sound works, from 19:00 there is > > only the sound of silence. Everything looks OK, xmms, mpg123 etc play, > > but no sound. > > > > The pcm driver is compiled into the kernel, i haven't tested loading as > > module. > > Could you please try the attached patch (to be applied in > /sys/dev/sound/pci). Patch seems to work. My sound appears to work again. I'm using the module though, and not the compiled-into-the-kernel version Øyvind is using. I don't suppose there's much difference between the two? - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. Never say "oops" after you have submitted a job. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VESA modes with i815?
Hi guys! I've recently had my Matrox VGA board die on me (don't know why, it just died), and since then I've been doomed to use the on-board i815 chip to get the phosphors in my monitor to light up. This works fine with 'small consoles', and even with VESA_800x600, but when I type 'vidcontrol VESA_132x60` or any other VESA mode, for that matter, the screen just goes blank. When I then type 'vidcontrol -g 100x37 VESA_800x600', or 'vidcontrol 80x25' my screen comes back. First I thought perhaps the prompt was hidden way off the visible area of my monitor, but fiddling with the knobs doesn't bring an answer. Is this a known problem with this chipset, or am I doing something silly? I'm running -CURRENT from a few days ago. Thanks! - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. The one thing that money can not buy is poverty. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: last KSE changes
On 2003-01-31 15:13:29 (+0100), Philip Paeps <[EMAIL PROTECTED]> wrote: > On 2003-01-28 11:24:41 (-0800), Julian Elischer <[EMAIL PROTECTED]> wrote: > > The rumour mill has been running wild on this but **AS FAR AS I KNOW** the > > breakages have been fixed, since no-one has told me directl of any current > > breakages. If you have any breakage from this commit, PLEASE TELL ME! [...] > Haven't been able to build a kernel for about two/three days, and your > commit looks like the one that might be the culprit... :-) ...and it wasn't :-) Sorry about that. > There's nothing particularly exciting in my config files, I don't think, but > I've attached them anyway, just in case. Sergey pointed out that I was missing a scheduler in my configs. Quick read through UPDATING shed light on the matter and the kernels build nicely again! False alarm, sorry :-o - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. As soon as the flight attendant serves the coffee, the airliner encounters turbulence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: last KSE changes
): undefined reference to `sched_runnable' | vm_pageout.o: In function `vm_pageout_scan': | vm_pageout.o(.text+0x199c): undefined reference to `sched_nice' | machdep.o: In function `cpu_idle': | machdep.o(.text+0x166e): undefined reference to `sched_runnable' | *** Error code 1 | | Stop in /usr/obj/usr/src/sys/JUNO. | *** Error code 1 | | Stop in /usr/src. | *** Error code 1 | | Stop in /usr/src. Haven't been able to build a kernel for about two/three days, and your commit looks like the one that might be the culprit... :-) There's nothing particularly exciting in my config files, I don't think, but I've attached them anyway, just in case. Any ideas, or am I barking up the wrong tree? - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. In a hierarchical system, the rate of pay varies inversely with the unpleasantness and difficulty of the task. # vim: tw=0 ts=8 # # PROSPERINA -- Kernel config for prosperina.home.paeps.cx (FreeBSD/alpha) # machine alpha cpu EV5 ident PROSPERINA maxusers64 # Platforms supported options DEC_ST550 # Personal Workstation 433, 500, 600 options INET#InterNETworking options INET6 options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores # Include config file options INCLUDE_CONFIG_FILE # Standard busses device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atapicam# ATAPI CAM subsystem device atapicd # ATAPI CDROM drives # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices device isp # Qlogic family # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc options SC_DISABLE_REBOOT options SC_DISABLE_DDBKEY options SC_KERNEL_CONS_ATTR=(FG_LIGHTGREEN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_WHITE|BG_GREEN) options SC_NORM_REV_ATTR=(FG_WHITE|BG_BLUE) options SC_PIXEL_MODE device mcclock # MC146818 real time clock device # Serial (COM) ports (required) device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device dc # DEC/Intel 21143 and workalikes # Pseudo devices - the number indicates how many units to allocated. device random # Entropy device device loop# Network loopback device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device snp # Snoop device # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf #Berkeley packet filter # vim: tw=0 ts=8 # # JUNO
Re: Current Breaks courier-imap and/or pam?
On 2003-01-10 19:06:18 (-0500), Jeff Utter <[EMAIL PROTECTED]> wrote: > Hi there, i was just wondering if anyone out there used Courier Imap on > current using authpam? ... Yeps... > In the last couple days i upgraded both my current installation (from about > 1 week old, to CURRENT current) and the courier-imap port. After this, i > noticed that my courier imap stopped working... i tried downgrading to the > last version 1.53 (i think) but that didnt' help one bit. the auth test > program that comes w/ courier imap, seems to work fine. However when i login > via telnet to the imap server, it acts as follows: Read the PR I submitted about this a few hours ago: <http://www.freebsd.org/cgi/query-pr.cgi?pr=46960> I remember noticing this behaviour a couple of weeks ago too, but being in a hurry then, I just fixed it and neglected to submit a PR :-/ > The only thing i think that could be goign wrong is something changed w/ PAM > in Current recently? is that so?.. however SSH still works, so i'm somewhat > confused. I'm SURE i'm using the correct password ect.. Nope, the port overwrites /etc/pam.d/imap and /etc/pam.d/pop3 with broken 'defaults'. Just copy src/etc/pam.d/imap and src/etc/pam.d/pop3 into their respective spots on /etc and you should be fine. > Anyone have a similar experiance, or any ideas? Me :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. In any organisation there will always be one person who knows what is going on. This person must be fired. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cordless Keyboard + Mouse
On 2003-01-06 15:22:21 (-0500), Daren Desjardins <[EMAIL PROTECTED]> wrote: > Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless > kb/mouse combos to work? Yes. I have a Logitech Cordless Desktop and a Cordless TrackMan. Both work very happily. I use the PS/2 plugs though, not the USB ones. Don't know why, just never occured to me to try the USB :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. It's always darkest before ... daylight saving time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh authentification broken, only public keys work
On 2002-12-20 08:27:53 (+0100), Martin Blapp <[EMAIL PROTECTED]> wrote: > Since yesterday I cannot login to my CURRENT machine anymore > after a world and reboot ... Same problem here (on Alpha and on i386, if it matters). Logging in with a public key works, without doesn't. > Then the connection times just out. The "ssh_msg_send: write" > message appears without debug mode. Yeps. Setting ChallengeResponse... to 'no' in the config file works, but I'm weary of local hacks. I can't seem to find the commit that caused this either. But perhaps I'm not awake enough to grep properly :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #376: Budget cuts forced us to sell all the power cords for the servers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-12-07 23:10:18 (+0100), Cliff Sarginson <[EMAIL PROTECTED]> wrote: > On Sat, Dec 07, 2002 at 08:41:35PM +0100, Philip Paeps wrote: > > On 2002-11-25 01:49:34 (+0100), Philip Paeps <[EMAIL PROTECTED]> wrote: > > Perhaps someone can make sense of this? I'm happy I can read my mail now, > > without having to kick the power button every so often, but I'd prefer to > > store my mail here and have the mailserver write over NFS. (Mainly for > > speed reasons). > > I suspect file locks across NFS as a possible source of this kind of > problem. Locking is always a problem over NFS :-/ It's one of the reasons I'm using maildirs instead of normal happy mboxes. Theoretically - correct me if I'm wrong - file locks shouldn't matter with maildirs as once a file is written, there's not much chance of it having to be written again, let alone by more than one process? How would one verify that NFS locking is causing pain? There's some NFS debugging stuff in NOTES... I'm willing to try anything to help fix this :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. If you see a man approaching you with the obvious intent of doing you good, you should run for your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 01:49:34 (+0100), Philip Paeps <[EMAIL PROTECTED]> wrote: > 2. This one's the most irritating. I use Mutt as my mailclient using > Maildirs for storage. It occasionally happens that Mutt just 'hangs' > reading a directory, and there's no way for me to kill it. Ps axl shows it > as being in state Ds or Ds+ and blocked by ufs. I've fiddled a bit with this one. I still can't reproduce it reliably, but I got it to go away :-) Before, I had my maildir living on this machine (running -current), and my mailserver (running stable) mounted it over NFS and wrote mails to it. Often, when reading things locally in the directory, it just hung. I haven't been able to pinpoint why it hung, but I suspect it could be that it didn't like mails being written into it? Problem with nfsd perhaps? I've now turned the system around. My maildir now lives on the mailserver, and I mount it here. Problem has gone away. Perhaps someone can make sense of this? I'm happy I can read my mail now, without having to kick the power button every so often, but I'd prefer to store my mail here and have the mailserver write over NFS. (Mainly for speed reasons). - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. The length of a marriage is inversely proportional to the amount spent on the wedding. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 20:11:01 (-0500), Jeff Roberson <[EMAIL PROTECTED]> wrote: > On Tue, 26 Nov 2002, Philip Paeps wrote: > > I was also starting to think in the NFS direction. It's one of the > > reasons I use Maildirs. My setup is a bit convoluted too. This machine > > (the one now running -current and hanging) plays NFS server. The > > mailserver mounts the maildir and writes mail into it. > > > > Now, the 'hangs' appear to be somewhat random, I can open a few > > mailfolders without issues, then suddenly I get a hang if I try another > > one. Also, I notice that when I send a mail when I'm in a folder which is > > set up to save mails in itself (what a ridiculous sentence), they don't > > get saved until a while later. > > > > I'm going to fiddle a bit with my setup and see if I can reliably > > reproduce hangs. 'Random' is very difficult to debug, I know :-/ > > If you do not have it compiled in already, please add DDB to your kernel > config. The next time it hangs type CTRL+ALT+ESC to enter the debugger. > Then please provide the output of 'ps' and 'show lockedvnods'. You may then > use 'call boot(0)' to reboot your system. Ps inside the debugger gives me the following about Mutt: 638 c2ea0938 da743000 1001 634 638 0004002 norm[SLPQ ufs c4cb68dc[SLP] mutt Show lockedvnods gave me no output at all. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #83: Support staff hung over, send aspirin and come back LATER. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-26 12:37:25 (+0100), Robert Drehmel <[EMAIL PROTECTED]> wrote: > On Mon, Nov 25, 2002 at 10:04:23PM +0100, Philip Paeps wrote: > > Before it is a few megs of the same. Basically Mutt reading my mailbox. > > Anything else I can do to help? > > You could give the attached patch a try. I'm afraid it doesn't solve the problem :-/ Still hung on me just now. It looked like it might have 'improved matters', though, but it might have been just a fluke. I'll keep testing and will try to find a way to reproduce it reliably, but it's being a pain to track down. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. The wrong quarterback is the one that's in there. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-26 12:37:25 (+0100), Robert Drehmel <[EMAIL PROTECTED]> wrote: > On Mon, Nov 25, 2002 at 10:04:23PM +0100, Philip Paeps wrote: > > Before it is a few megs of the same. Basically Mutt reading my mailbox. > > Anything else I can do to help? > > You could give the attached patch a try. Okay. I'll let you know if it helps :-) > Were you by any chance using truss(1) just before mutt started to hang? No. I used truss after it hung - and after I rebooted - to try and figure out why it hangs the next time it hung. I'll get back to you after my kernel is compiled. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. If at first you don't succeed, try something else. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 16:00:52 (-0800), Terry Lambert <[EMAIL PROTECTED]> wrote: > Philip Paeps wrote: > > > The "maildirs issue", I won't comment on, at this time. > > > > I hope I can provide enough information for someone to solve it though :-) > > It would be nice to be able to read my mail 'reliably' :-) > > The problem is not the amount, but the type of information. > > You need to characterize the problem well enough that you can write a little > program that can repeat it on someone else's machine, without them having to > create an installation identical to yours on a scratch box ...particularly > when it looks like if they tried that, it would work for them. That sounds like the first law of debugging to me :-) > Right now, there are other people using the same software that can't repeat > the problem. > > Without knowing whether or not you are both/neither/or-or-the-other using > NFS, etc., it's really impossible to even point you in the right direction > (NFS is my hunch, in this case; it's a common reason for use of "maildirs", > to try and side-step locking issues). I was also starting to think in the NFS direction. It's one of the reasons I use Maildirs. My setup is a bit convoluted too. This machine (the one now running -current and hanging) plays NFS server. The mailserver mounts the maildir and writes mail into it. Now, the 'hangs' appear to be somewhat random, I can open a few mailfolders without issues, then suddenly I get a hang if I try another one. Also, I notice that when I send a mail when I'm in a folder which is set up to save mails in itself (what a ridiculous sentence), they don't get saved until a while later. I'm going to fiddle a bit with my setup and see if I can reliably reproduce hangs. 'Random' is very difficult to debug, I know :-/ > You probably need to get together with the other person who said they were > *not* having a problem, and do a detailed compare on system configuration, > if all other things are equal. So who is this mysterious other person? :-) I'll get back with some more concrete information as soon as I have some. It's an intriguing challenge. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #2: solar flares To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 14:32:27 (-0800), Terry Lambert <[EMAIL PROTECTED]> wrote: > Philip Paeps wrote: > > On 2002-11-25 14:41:22 (-0500), Hiten Pandya wrote: > > > On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote: > > > > | unknown: can't assign resources (port) > > > > | unknown: can't assign resources (port) > > > > > > Can you try changing the hardware tunable, > > > hw.pci.allow_unsupported_io_range, to the value of 1 in your > > > loader.conf. I think this should do it. You can then check this value > > > after you booted by `sysctl hw.pci`. > > > > I'm afraid that doesn't cure the 'problem'. > > I think Hiten responded based on the "can't assign resource" messages, > without reading all the way through; I sometimes do "kneee-jerk" responses > to problem reports, as well. The reason his advice didn't help you suppress > the messages is that the failure is in port and IRQ assignments, not in > memory window assignments. Aha, okay. I've just learned something new. :-) > The problem is related to multiple claimants for the device: the BIOS, vs. > the OS. If you change the BIOS settings for "PnP OS", the messages should > "go away". Note that the messages are just warnings; they will not make > anything "not work", given your configuration. Thanks for the hint! I went fiddling with settings in my BIOS, and turned on ACPI (there was no 'PnP OS' setting, but someone else mentioned ACPI earlier), and the message is now gone. It's been replaced with a lot of messages telling me that ACPI is working and happy to serve me. > The "maildirs issue", I won't comment on, at this time. I hope I can provide enough information for someone to solve it though :-) It would be nice to be able to read my mail 'reliably' :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #299: The data on your hard drive is out of balance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 14:41:22 (-0500), Hiten Pandya <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote the words in effect of:
> > As I said, I'm happy to help analyse and debug these issues, but I don't know
> > where to look :-)
>
> Can you try using `ktrace`, like this:
>
> root# ktrace mutt (or the command which makes it hang)
> root# kdump -f ktrace.out (this is the output needed)
This is the last screenfull of kdump:
567 muttCALL stat(0xbfbfebb0,0xbfbfeb50)
567 muttNAMI "/home/philip/Maildir/lists/bsd/freebsd-current/cur"
567 muttRET stat 0
567 muttCALL stat(0xbfbfebb0,0xbfbfeb50)
567 muttNAMI "/home/philip/Maildir/lists/bsd/freebsd-current/new"
567 muttRET stat 0
567 muttCALL stat(0xbfbfebb0,0xbfbfeae0)
567 muttNAMI "/home/philip/Maildir/lists/bsd/freebsd-current/new"
567 muttRET stat 0
567 muttCALL open(0xbfbfebb0,0x4,0xbfbfe9e8)
567 muttNAMI "/home/philip/Maildir/lists/bsd/freebsd-current/new"
567 muttRET open 3
567 muttCALL fstat(0x3,0xbfbfeae0)
567 muttRET fstat 0
567 muttCALL fcntl(0x3,0x2,0x1)
567 muttRET fcntl 0
567 muttCALL fstatfs(0x3,0xbfbfe9e0)
567 muttRET fstatfs 0
567 muttCALL getdirentries(0x3,0x80f4000,0x1000,0x80f3054)
567 muttRET getdirentries 12/0x200
567 muttCALL write(0x1,0x80e2000,0x2)
567 muttGIO fd 1 wrote 2 bytes " 1"
567 muttRET write 2
567 muttCALL getdirentries(0x3,0x80f4000,0x1000,0x80f3054)
567 muttRET getdirentries 0
567 muttCALL lseek(0x3,0,0,0,0)
567 muttRET lseek 0
567 muttCALL close(0x3)
567 muttRET close 0
567 muttCALL open(0xbfbfebb0,0,0x1b6)
567 muttNAMI
"/home/philip/Maildir/lists/bsd/freebsd-current/new/1038256312.43736_1.fortuna.home.paeps.cx"
Before it is a few megs of the same. Basically Mutt reading my mailbox.
Anything else I can do to help?
- Philip
--
Philip Paeps Please don't CC me, I am
[EMAIL PROTECTED] subscribed to the list.
BOFH Excuse #225:
It's those computer people in X {city of world}. They keep stuffing
things up.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 14:41:22 (-0500), Hiten Pandya <[EMAIL PROTECTED]> wrote: > On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote the words in effect of: > > | unknown: can't assign resources (port) > > | unknown: can't assign resources (port) > > Can you try changing the hardware tunable, > hw.pci.allow_unsupported_io_range, to the value of 1 in your loader.conf. I > think this should do it. You can then check this value after you booted by > `sysctl hw.pci`. I'm afraid that doesn't cure the 'problem'. (juno:/home/philip)# sysctl hw.pci hw.pci.enable_io_modes: 1 hw.pci.allow_unsupported_io_range: 1 Exactly the same output as above. > > 2. This one's the most irritating. I use Mutt as my mailclient using > > Maildirs for storage. It occasionally happens that Mutt just 'hangs' > > reading a directory, and there's no way for me to kill it. Ps axl shows > > it as being in state Ds or Ds+ and blocked by ufs. > > Hmm, this also happens in the case of dd(1). If you invoke dd(1) as: > > # dd if=/dev/zero of=/tmp/somefile > > As you can see, it gets stuck when not provided with a count variable. It > hangs in the `ufs' state. I am currently looking into this. I am thinking, > this is because a 0 byte file is found disturbing. Mmm, this doesn't seem hang for me. It just keeps filling the file, but doesn't hang. (juno:/usr/src)# dd if=/dev/zero of=/tmp/somefile ^C980608+0 records in 980607+0 records out 502070784 bytes transferred in 32.172603 secs (15605538 bytes/sec) > Can you try using `ktrace`, like this: > > root# ktrace mutt (or the command which makes it hang) > root# kdump -f ktrace.out (this is the output needed) Will do. Just building a kernel with ktrace, as I accidently removed it. I'll get back with more info. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. (1) If the weather is extremely bad, church attendance will be down. (2) If the weather is extremely good, church attendance will be down. (3) If the bulletin covers are in short supply church attendance will exceed all expectations. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 17:23:50 (+0200), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Philip Paeps wrote: > > 1. When I boot my machine, it gives me the following messages: > > > > | [...] > > | vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > > | unknown: can't assign resources (port) > > | unknown: can't assign resources (irq) > > | unknown: can't assign resources (port) > > | unknown: can't assign resources (port) > > | unknown: can't assign resources (port) > > | unknown: can't assign resources (port) > > | unknown: can't assign resources (port) > > | Timecounters tick every 10.000 msec > > | ahc0: Someone reset channel A > > | [...] > > > > All my hardware (the stuff I've tested anyway) appears to work. Any idea > > which device is being unknown, or how I could find out? > > Do you also get an 'unable to initialize ACPI' message when your system > boots? Nope, I don't use ACPI. I didn't have it in my kernel, and don't load it dynamically either. > I stopped getting this message when I compiled ACPI support into the kernel: > > device acpi > options ACPI_DEBUG I tried that, I still get the same message as above, in addition to some new happy messages: | ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES | ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES | ACPI: table load failed: AE_NO_ACPI_TABLES I've probably turned ACPI off in the BIOS (haven't checked), if there's even ACPI stuff available on this machine. > Someone here will probably say that you don't need to compile it into the > kernel, you can use the kernel module and you can use loader.conf to do > this. See /usr/src/sys/boot/forth/loader.conf and loader.conf(5) for more > details. FWIW, this file should probably have been installed into > /boot/loader.conf.(default|sample|etc), then lazy people like me would have > noticed a significant difference in loader.conf from 4.7 to current and > investigated further. Loader.conf works nicely, but putting acpi in there, or in the kernel, gives exactly the same results as above: the PNP messages, plus the ACPI complaints. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #282: High altitude condensation from U.S.A.F prototype aircraft has contaminated the primary subnet mask. Turn off your computer for 9 days to avoid damaging it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 13:09:56 (+0100), Philip Paeps <[EMAIL PROTECTED]> wrote:
> On 2002-11-25 11:45:36 (+0100), Robert Drehmel <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote:
> > [reformatted]
> > > 2. This one's the most irritating. I use Mutt as my mailclient using
> > > Maildirs for storage. It occasionally happens that Mutt just 'hangs'
> > > reading a directory, and there's no way for me to kill it. Ps axl shows
> > > it as being in state Ds or Ds+ and blocked by ufs.
> >
> > do you use truss(1)?
>
> Frequently, but I hadn't thought about it in this case :-)
>
> Next time it just sits there, I'll try to find out what truss tells me. If
> nothing, I'll try to reproduce the problem running inside truss.
>
> I'll get with more info as soon as things die.
Mmm, truss doesn't give me anything particularly useful. The last few lines
when it hangs are:
| read(0x0,0xbfbfe19b,0x1) = 1 (0x1)
| write(1,0x80e1000,6) = 6 (0x6)
| write(1,0x80e1000,6) = 6 (0x6)
| stat("/etc/nsswitch.conf",0xbfbfd950) ERR#2 'No such file or
|directory'
| geteuid() = 1001 (0x3e9)
| stat("/etc/pwd.db",0xbfbfd860)= 0 (0x0)
| open("/etc/pwd.db",0x0,00)= 4 (0x4)
| fcntl(0x4,0x2,0x1)= 0 (0x0)
| read(0x4,0x8133a00,0x104) = 260 (0x104)
| lseek(4,0x5000,0) = 20480 (0x5000)
| read(0x4,0x8477000,0x1000)= 4096 (0x1000)
| lseek(4,0x4000,0) = 16384 (0x4000)
| read(0x4,0x8478000,0x1000)= 4096 (0x1000)
| lseek(4,0x6000,0) = 24576 (0x6000)
| read(0x4,0x8479000,0x1000)= 4096 (0x1000)
| lseek(4,0x7000,0) = 28672 (0x7000)
| read(0x4,0x847a000,0x1000)= 4096 (0x1000)
| ls
...and then it just sits there...
It doesn't even finish printing the line. Ps axl tells me it's waiting on
ufs, and there's no way to kill it, other than a reboot. When rebooting, it
tells me it gives up on one buffer, and then just stays hanging there.
Perhaps breaking into a debugger will provide some more useful information.
I'll try that next.
- Philip
--
Philip Paeps Please don't CC me, I am
[EMAIL PROTECTED] subscribed to the list.
Real programmers don't notch their desks for each
completed service request.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: I'm impressed, but ...
On 2002-11-25 11:45:36 (+0100), Robert Drehmel <[EMAIL PROTECTED]> wrote: > On Mon, Nov 25, 2002 at 01:49:34AM +0100, Philip Paeps wrote: > [reformatted] > > 2. This one's the most irritating. I use Mutt as my mailclient using > > Maildirs for storage. It occasionally happens that Mutt just 'hangs' > > reading a directory, and there's no way for me to kill it. Ps axl shows > > it as being in state Ds or Ds+ and blocked by ufs. > > do you use truss(1)? Frequently, but I hadn't thought about it in this case :-) Next time it just sits there, I'll try to find out what truss tells me. If nothing, I'll try to reproduce the problem running inside truss. I'll get with more info as soon as things die. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #101: Collapsed Backbone To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I'm impressed, but ...
Hi guys - I accidently upgraded my workstation to -CURRENT over the weekend (forgot a tag=RELENG_4 in my supfile and let it cook). It being a workstation and containing no critical data, I decided to just stick with it and give it a go. The machine's been running for a day and a bit now, and it appears to be quite stable, but there's a couple of things worrying me. I'd be happy to help analyse the problems further if someone tells me how :-) 1. When I boot my machine, it gives me the following messages: | [...] | vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 | unknown: can't assign resources (port) | unknown: can't assign resources (irq) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | unknown: can't assign resources (port) | Timecounters tick every 10.000 msec | ahc0: Someone reset channel A | [...] All my hardware (the stuff I've tested anyway) appears to work. Any idea which device is being unknown, or how I could find out? 2. This one's the most irritating. I use Mutt as my mailclient using Maildirs for storage. It occasionally happens that Mutt just 'hangs' reading a directory, and there's no way for me to kill it. Ps axl shows it as being in state Ds or Ds+ and blocked by ufs. 3. I can't seem to restart my machine properly. This might be related to the above, as the only reason for me to restart the machine is the fact that I can't kill Mutt however much I try, and really would like to read my mail. It will sync disks and say 'done', but then it just sits there doing nothing until I flip the power-switch. As I said, I'm happy to help analyse and debug these issues, but I don't know where to look :-) Thanks :-) - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. The only way to make up for being lost is to make record time while you are lost. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
