Bruno,You can mount at mountroot> promp, using command either 'help' or '?' and then <TAB> (->) for completion.But probably you can also use 'man fstab' to adjust file /etc/fstab with property "auto" to have your devices automounted.SY,EngelFrom: freebsd-current-request@freebsd.orgSubject: freebsd-current Digest, Vol 195, Issue 14To: freebsd-current@freebsd.orgDate: Sun, 13 May 2007 22:56:51 +0000Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-currentor, via email, send a message with subject or body 'help' to freebsd-current-request@freebsd.org You can reach the person managing the list at freebsd-current-owner@freebsd.org When replying, please edit your Subject line so it is more specificthan "Re: Contents of freebsd-current digest..."--Forwarded Message Attachment--From: delphij@delphij.netCC: kan@FreeBSD.org; freebsd-current@freebsd.org; obrien@FreeBSD.org; markir@paradise.net.nzTo: kris@obsecurity.orgDate: Sun, 13 May 2007 20:20:24 +0800Subject: Re: FreeBSD 7.0 using GCC 4?Kris Kennaway wrote:> On Sat, May 12, 2007 at 10:09:04PM +1200, Mark Kirkwood wrote:>> Hi,>>>> I just updated one of my 6.2-STABLE machines to 7.0-CURRENT and was >> (mistakenly I guess) expecting to see gcc 4.x as the default compiler... >> however I'm seeing 3.4.6 20060825. As far as I can tell I have performed >> the upgrade correctly (followed UPDATING) and everything works fine.... >> also src/contrib/gcc/version.c seems to agree that 3.4.6 is it.>>>> So... err - are we still intending to change to 4?> > Yes, real soon now <tm> Will we be using 4.1.x series or 4.2.x series for 7.0-RELEASE? Justcurious :-) Cheers,-- Xin LI <delphij@delphij.net> http://www.delphij.net/FreeBSD - The Power to Serve! --Forwarded Message Attachment--From: des@des.noCC: sos@freebsd.orgTo: current@freebsd.orgDate: Sun, 13 May 2007 14:35:01 +0200Subject: ata_alloc request failedI've started to get this on one of my machines: dma.des.no kernel log messages:+++ /tmp/security.207mhx7D Sun May 13 03:05:32 2007+DOH! ata_alloc_request failed!+FAILURE - out of memory in ata_raid_init_request+FAILURE - out of memory in ata_raid_init_request+FAILURE - out of memory in ata_raid_init_request+g_vfs_done():ar0s1h[WRITE(offset=18879152128, length=16384)]error = 5+g_vfs_done():ar0s1h[WRITE(offset=18879168512, length=16384)]error = 5+g_vfs_done():ar0s1h[WRITE(offset=18879184896, length=16384)]error = 5 It's an amd64 box with 1 GB RAM and a very light workload, but it'sinteresting to note that the failure happened about 90 seconds into'periodic weekly' (most likely while rebuilding the locate database) DES-- Dag-Erling Smørgrav - des@des.no --Forwarded Message Attachment--From: bzeeb-lists@lists.zabbadoz.netCC: current@freebsd.org; sos@freebsd.orgTo: des@des.noDate: Sun, 13 May 2007 13:16:03 +0000Subject: Re: ata_alloc request failedOn Sun, 13 May 2007, Dag-Erling Smørgrav wrote: Hi, > I've started to get this on one of my machines:>> dma.des.no kernel log messages:> +++ /tmp/security.207mhx7D Sun May 13 03:05:32 2007> +DOH! ata_alloc_request failed!> +FAILURE - out of memory in ata_raid_init_request> +FAILURE - out of memory in ata_raid_init_request> +FAILURE - out of memory in ata_raid_init_request> +g_vfs_done():ar0s1h[WRITE(offset=18879152128, length=16384)]error = 5> +g_vfs_done():ar0s1h[WRITE(offset=18879168512, length=16384)]error = 5> +g_vfs_done():ar0s1h[WRITE(offset=18879184896, length=16384)]error = 5>> It's an amd64 box with 1 GB RAM and a very light workload, but it's> interesting to note that the failure happened about 90 seconds into> 'periodic weekly' (most likely while rebuilding the locate database) It should be safe to ignore them though it's not a solution. I had seen those for about half a year on amd64/6 and sometimes it'snot only 3 lines but a few hundred. Also 1G RAM here. For me also my backup runs during the hours this sometimes happens.Was was not able to track it down to one specific event. I tried to capture memory usage during that time but could not findanything (maybe I haven't checked correctly). In case you find out the casue of this I'd be happy to test changes:) /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT--Forwarded Message Attachment--From: freebsd@ruomad.netCC: freebsd-fs@FreeBSD.org; se@FreeBSD.org; freebsd-current@FreeBSD.org; peter.schuller@infidyne.comTo: pjd@FreeBSD.orgDate: Sun, 13 May 2007 15:19:35 +0200Subject: Re: ZFS: amd64, devd, root file system.Pawel Jakub Dawidek wrote:> On Sun, Apr 22, 2007 at 10:26:21PM +0200, Peter Schuller wrote:> >>> Try zfs_load="YES". If this is what you had, send me full dmesg.>>> >> Sorry, I had zfs_load="YES". Typo on my part. No typo in loader.conf.>>>> Do you have any suggestion on how to best grab the dmesg, given that>> when triggering this the root fs cannot be mounted?>>>> Or do you just want a dmesg from my system in general, with a matching>> loader.conf minus the vfs.root.mountfromt?>>>> If the latter, it is available here:>>>> http://distfiles.scode.org/mlref/freebsd-dmesg-zfs-glabel-7current.txt>>>> In this dmesg the ZFS pool version output preceeds the glabel tasting. I>> was so sure this was not the case. Either I was misstaken or this was>> different then for some reason.>> >> And this is the problem... ZFS tries only ones. I'll think it over and> see what can be done. Unfortunately ZFS doesn't use GEOM tasting> mechanism and I'd prefer not to modify it to do so, because the changes> may be huge.>> Hello, Sorry about the noise, but I wonder if anyone saw my previous post aboutzfs root not being found at once (I have to input it manually atmountroot> prompt) ? Thanks Bruno --Forwarded Message Attachment--From: rpaulo@fnop.netCC: freebsd-current@freebsd.orgTo: Thomas.Sparrevohn@btinternet.comDate: Sun, 13 May 2007 15:18:40 +0100Subject: Re: MacBook patchesAt Sun, 13 May 2007 12:25:53 +0100,Thomas Sparrevohn wrote: > Nice - Have you looked at using the mwait deeper C-States rather> than halt? Nop. > I think the "msr" portion looks like it will handle the entire Micro> Core architecture that would be really nice - Judging from the> papers published by intel and from the general discussions on the> net - it seems like Are you refering to msrtemp driver? Yes, it only works on Intel's CoreArchitecture, at the moment. > Would it be possible to seperate the "ACPI" part from the other "Mac> patches" as I think its of more general use? Well, if someone really needs it (besides for MacBooks), we candiscuss what should be done. --Rui Paulo --Forwarded Message Attachment--From: kabaev@gmail.comCC: freebsd-current@freebsd.orgTo: delphij@delphij.netDate: Sun, 13 May 2007 10:39:41 -0400Subject: Re: FreeBSD 7.0 using GCC 4?On Sun, 13 May 2007 20:20:24 +0800LI Xin <delphij@delphij.net> wrote: > Will we be using 4.1.x series or 4.2.x series for 7.0-RELEASE? Just> curious :-)> > Cheers,> -- > Xin LI <delphij@delphij.net> http://www.delphij.net/> FreeBSD - The Power to Serve!> 4.2.0. This is the first compiler version in GCC history to actuallyshrink compiled boot2 code and that alone gave it many points in 4.1vs. 4.2 shootout. There are other advantages as well. 4.2 can buildunpatched firefox and have it working, while 4.1 builds binary withbroken relocations, etc. -- Alexander Kabaev--Forwarded Message Attachment--From: Thomas.Sparrevohn@btinternet.comTo: freebsd-current@freebsd.orgDate: Sun, 13 May 2007 16:17:55 +0100Subject: Re: MacBook patchesOn Sunday 13 May 2007 15:18:40 Rui Paulo wrote:> At Sun, 13 May 2007 12:25:53 +0100,> Thomas Sparrevohn wrote:> > > Nice - Have you looked at using the mwait deeper C-States rather> > than halt? > > Nop.> > > I think the "msr" portion looks like it will handle the entire Micro> > Core architecture that would be really nice - Judging from the> > papers published by intel and from the general discussions on the> > net - it seems like > > Are you refering to msrtemp driver? Yes, it only works on Intel's Core> Architecture, at the moment.> > > Would it be possible to seperate the "ACPI" part from the other "Mac> > patches" as I think its of more general use? > > Well, if someone really needs it (besides for MacBooks), we can> discuss what should be done. Using a quad-core - Desktop - I need it - Normally the cores runs at 45C -under freebsd it more like 51-55C and its giving me heat burns on my feet ;-) All the Core Micro architecture uses TM2 approach and ODCM as secondary.The Xeon's systems seems as a rule to have reasonable APCI implementations - however quite a lot of Desktop systems does not really and depends upon OSPMto give the information - Judging from the Linux implementation that is the approachthey have taken - eg. cstate.c etc - A quad core system are in idle wait quite a lot due to the way that portupgrade etc. worksbut I don't think that the system enters "C1 Auto Halt Stop Grant" which in it self would half the power used. From a linux presentation it looks like the Power Usage swings between 31Watt - down to 1.8Wattin DC4 state so there a lot of heat and power to be saved ;-) So I think there are good reasons to look at TM2 and Mwait etc > > --> Rui Paulo> _______________________________________________> freebsd-current@freebsd.org mailing list> http://lists.freebsd.org/mailman/listinfo/freebsd-current> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"> --Forwarded Message Attachment--From: delphij@delphij.netCC: freebsd-current@freebsd.orgTo: kabaev@gmail.comDate: Sun, 13 May 2007 23:27:24 +0800Subject: Re: FreeBSD 7.0 using GCC 4?Alexander Kabaev wrote:> On Sun, 13 May 2007 20:20:24 +0800> LI Xin <delphij@delphij.net> wrote:> >> Will we be using 4.1.x series or 4.2.x series for 7.0-RELEASE? Just>> curious :-)>>>> Cheers,>> -- >> Xin LI <delphij@delphij.net> http://www.delphij.net/>> FreeBSD - The Power to Serve!>>> > 4.2.0. This is the first compiler version in GCC history to actually> shrink compiled boot2 code and that alone gave it many points in 4.1> vs. 4.2 shootout. There are other advantages as well. 4.2 can build> unpatched firefox and have it working, while 4.1 builds binary with> broken relocations, etc. Wow, that's great, thanks for the work! Cheers,-- Xin LI <delphij@delphij.net> http://www.delphij.net/FreeBSD - The Power to Serve! --Forwarded Message Attachment--From: ohartman@mail.zedat.fu-berlin.deCC: freebsd-current@freebsd.orgTo: delphij@delphij.netDate: Sun, 13 May 2007 18:18:12 +0200Subject: Re: FreeBSD 7.0 using GCC 4?LI Xin wrote:> Alexander Kabaev wrote:> >> On Sun, 13 May 2007 20:20:24 +0800>> LI Xin <delphij@delphij.net> wrote:>>>> >>> Will we be using 4.1.x series or 4.2.x series for 7.0-RELEASE? Just>>> curious :-)>>>>>> Cheers,>>> -- >>> Xin LI <delphij@delphij.net> http://www.delphij.net/>>> FreeBSD - The Power to Serve!>>>>>> >> 4.2.0. This is the first compiler version in GCC history to actually>> shrink compiled boot2 code and that alone gave it many points in 4.1>> vs. 4.2 shootout. There are other advantages as well. 4.2 can build>> unpatched firefox and have it working, while 4.1 builds binary with>> broken relocations, etc.>> >> Wow, that's great, thanks for the work!>> Cheers,> A while ago a discussion herein was triggered about this subject and as I remember myself, the decission was made in favor of gcc 4.1. Watching Linux/Gentoo Forums for a while I was reading many suggestions not using gcc 4.1.1 as it is standard in newest branches/distributions, because of several serious misbehaviours/generating broken code. We will seeOliver --Forwarded Message Attachment--From: tinderbox@freebsd.orgCC: To: tinderbox@freebsd.org; current@freebsd.org; powerpc@freebsd.orgDate: Sun, 13 May 2007 13:28:39 -0400Subject: [head tinderbox] failure on powerpc/powerpcTB --- 2007-05-13 16:48:36 - tinderbox 2.3 running on freebsd-current.sentex.caTB --- 2007-05-13 16:48:36 - starting HEAD tinderbox run for powerpc/powerpcTB --- 2007-05-13 16:48:36 - cleaning the object treeTB --- 2007-05-13 16:49:02 - checking out the source treeTB --- 2007-05-13 16:49:02 - cd /tinderbox/HEAD/powerpc/powerpcTB --- 2007-05-13 16:49:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A srcTB --- 2007-05-13 16:56:13 - building world (CFLAGS=-O2 -pipe)TB --- 2007-05-13 16:56:13 - cd /srcTB --- 2007-05-13 16:56:13 - /usr/bin/make -B buildworld>>> World build started on Sun May 13 16:56:14 UTC 2007>>> Rebuilding the temporary build tree>>> stage 1.1: legacy release compatibility shims>>> stage 1.2: bootstrap tools>>> stage 2.1: cleaning up the object tree>>> stage 2.2: rebuilding the object tree>>> stage 2.3: build tools>>> stage 3: cross tools>>> stage 4.1: building includes>>> stage 4.2: building libraries>>> stage 4.3: make dependencies>>> stage 4.4: building everything[...]cc -O2 -pipe -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/comsat/comsat.ccc -O2 -pipe -Wformat=2 -Wno-format-extra-args -Werror -o comsat comsat.o gzip -cn /src/libexec/comsat/comsat.8 > comsat.8.gz===> libexec/fingerd (all)cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /src/libexec/fingerd/fingerd.ccc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o fingerd fingerd.o -lutilfingerd.o(.text+0x3ec): In function `main':: undefined reference to `vfork'*** Error code 1 Stop in /src/libexec/fingerd.*** Error code 1 Stop in /src/libexec.*** Error code 1 Stop in /src.*** Error code 1 Stop in /src.*** Error code 1 Stop in /src.TB --- 2007-05-13 17:28:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-05-13 17:28:39 - ERROR: failed to build worldTB --- 2007-05-13 17:28:39 - tinderbox abortedTB --- 0.74 user 2.38 system 2403.07 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full --Forwarded Message Attachment--From: sgk@troutmask.apl.washington.eduTo: freebsd-current@freebsd.orgDate: Sun, 13 May 2007 10:54:25 -0700Subject: Process for requesting reverting patch?What is the formal process to get a recent commit to -current reverted? Do I send email to core? For details see http://www.freebsd.org/cgi/query-pr.cgi?pr=112408 -- Steve --Forwarded Message Attachment--From: wb@freebie.xs4all.nlCC: freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 20:10:53 +0200Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 10:54:25AM -0700, Steve Kargl wrote..> What is the formal process to get a recent commit to > -current reverted? Do I send email to core? For How about asking the committer who put it in CVS? Be prepared to explain why you think the commit should bereverted. -- Wilko Bulte wilko@FreeBSD.org --Forwarded Message Attachment--From: sgk@troutmask.apl.washington.eduCC: freebsd-current@freebsd.orgTo: linimon@lonesome.comDate: Sun, 13 May 2007 11:09:12 -0700Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 01:05:06PM -0500, Mark Linimon wrote:> On Sun, May 13, 2007 at 10:54:25AM -0700, Steve Kargl wrote:> > http://www.freebsd.org/cgi/query-pr.cgi?pr=112408> > Well, you've done the right thing by sending a PR and having it assigned> to the maintainer. Have you not heard anything back from mp@?> Of course, not! Rendering the debugger useless with the default shell would seem to be a critical bug to me, but somehow/onedecided that the severity was non-critical. -- Steve --Forwarded Message Attachment--From: sgk@troutmask.apl.washington.eduCC: freebsd-current@freebsd.orgTo: wb@freebie.xs4all.nlDate: Sun, 13 May 2007 11:11:37 -0700Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 08:10:53PM +0200, Wilko Bulte wrote:> On Sun, May 13, 2007 at 10:54:25AM -0700, Steve Kargl wrote..> > What is the formal process to get a recent commit to > > -current reverted? Do I send email to core? For > > How about asking the committer who put it in CVS?> > Be prepared to explain why you think the commit should be> reverted. Did you read the PR? The details are there. gdb is broken with tcsh. Having a nonfunctioning debuggerwould seem to be a rather severe problem. -- Steve --Forwarded Message Attachment--From: wb@freebie.xs4all.nlCC: freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 20:17:40 +0200Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 11:11:37AM -0700, Steve Kargl wrote..> On Sun, May 13, 2007 at 08:10:53PM +0200, Wilko Bulte wrote:> > On Sun, May 13, 2007 at 10:54:25AM -0700, Steve Kargl wrote..> > > What is the formal process to get a recent commit to > > > -current reverted? Do I send email to core? For > > > > How about asking the committer who put it in CVS?> > > > Be prepared to explain why you think the commit should be> > reverted.> > Did you read the PR? The details are there. No. You asked about the process. There is no formal processin that sense. > gdb is broken with tcsh. Having a nonfunctioning debugger> would seem to be a rather severe problem. Use another shell for now. And wait for the committer torespond. -- Wilko Bulte wilko@FreeBSD.org --Forwarded Message Attachment--From: des@des.noCC: freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 20:23:43 +0200Subject: Re: Process for requesting reverting patch?Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> What is the formal process to get a recent commit to -current> reverted? Do I send email to core? You start by talking to the person who did the commit. That much shouldbe obvious. DES-- Dag-Erling Smørgrav - des@des.no --Forwarded Message Attachment--From: sgk@troutmask.apl.washington.eduCC: freebsd-current@freebsd.orgTo: des@des.noDate: Sun, 13 May 2007 11:30:09 -0700Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 08:23:43PM +0200, Dag-Erling Sm??rgrav wrote:> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> > What is the formal process to get a recent commit to -current> > reverted? Do I send email to core?> > You start by talking to the person who did the commit. That much should> be obvious.> I would expect a committer, who changes something as important asthe default shell in FreeBSD, to read the freebsd-current mailinglist and the PR database. -- Steve --Forwarded Message Attachment--From: peterjeremy@optushome.com.auCC: freebsd-current@freebsd.orgTo: dnelson@allantgroup.comDate: Mon, 14 May 2007 04:48:56 +1000Subject: Re: [PATCH] Fancy rc startup (revisited)On 2007-May-12 21:40:30 -0500, Dan Nelson <dnelson@allantgroup.com> wrote:>Taken to an extreme, you have Solaris 10, where you get the kernel's>copyright message, smf kicks off all the startup scripts in parallel>(subject to dependency rules) in the background, their output goes into>individual logfiles, and all you see is the login: prompt at the>console :) I haven't played with Solaris 10 but IMHO, Solaris 8 and Solaris 9take the quiet startup too far: You get a few lines of output thennothing (no obvious signs of activity) for what seems like hours...This can be very disconcerting when things have been changed andyou are not confident that it's going to work at all. I far preferat least some indication that things are proceeding. -- Peter Jeremy--Forwarded Message Attachment--From: des@des.noCC: freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 21:24:35 +0200Subject: Re: Process for requesting reverting patch?Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> On Sun, May 13, 2007 at 08:23:43PM +0200, Dag-Erling Sm??rgrav wrote:> > Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> > > What is the formal process to get a recent commit to -current> > > reverted? Do I send email to core?> > You start by talking to the person who did the commit. That much should> > be obvious.> I would expect a committer, who changes something as important as> the default shell in FreeBSD, to read the freebsd-current mailing> list and the PR database. I would expect a committer such as yourself to know that there arebetter ways to approach this than posting to -current and threatening totake the matter to core@. DES-- Dag-Erling Smørgrav - des@des.no --Forwarded Message Attachment--From: anderson@freebsd.orgCC: rwatson@freebsd.org; kian.mohageri@gmail.com; dnelson@allantgroup.com; freebsd-current@freebsd.orgTo: keramida@freebsd.orgDate: Sun, 13 May 2007 14:29:04 -0500Subject: Re: [PATCH] Fancy rc startup (revisited)On 05/12/07 22:18, Giorgos Keramidas wrote:> On 2007-05-12 21:40, Dan Nelson <dnelson@allantgroup.com> wrote:>> In the last episode (May 12), Robert Watson said:>>> Call me old-fashioned, but I actually preferred the much more>>> abbreviated rc output from before rc.d even. :-) We're not going back>>> to hardware devices where all the probed devices add up to fewer than>>> 25 lines, I'm sure, but when daemons generated 8-12 characters>>> without a carriage return each, there was a good chance you could>>> still see the end of the kernel messages by the time you got to>>> login:, and I miss that. I don't object to optional more complex>>> output as long as that complexity is hidden away neatly somewhere in>>> rc.subr, and isn't on by default as shipped. I'd love it if someone>>> could restore the even shorter output we had before.>> Taken to an extreme, you have Solaris 10, where you get the kernel's>> copyright message, smf kicks off all the startup scripts in parallel>> (subject to dependency rules) in the background, their output goes>> into individual logfiles, and all you see is the login: prompt at the>> console :)> > More like Solaris 10 "boot -v", where you still get the kernel messages,> but you have a point there. I am kind of old-fashioned in the Robert> way too, however. If there was a way to minimize the console output> when services are starting, i.e. to print something like:> > [last kernel message]> > Booting FreeBSD: dumpon initrandom fsck root hostid mountcritlocal> var cleanvar random adjkerntz hostname kldxref swap sysctl netif (lo0> fxp0) pflog pf routing devd nsswitch devfs syslogd ldconfig named> auditd tmp cleartmp dmesg virecover local motd ntpd powerd syscons> sshd sendmail cron securelevel power_profile inetd> > foo login:> > where each rc.d script would only print its name if it *was* enabled> with xxx_enable, optionally followed by a parenthesized list of> single-word status messages for each subscript/component), would be> really neat.> > Is there any easy way we can 'tune' the fancy script to support the> current output style, a very brief style like above, and then a fancy> colorful style, depending on an rc.conf setting? I think the rc_fancy patch could be pretty easily tweaked to do exactly what you say. I might give it a go, and add that as another option to it. Maybe then the variable should change to rc_style_* instead? Eric --Forwarded Message Attachment--From: sgk@troutmask.apl.washington.eduCC: freebsd-current@freebsd.orgTo: des@des.noDate: Sun, 13 May 2007 12:28:36 -0700Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 09:24:35PM +0200, Dag-Erling Sm??rgrav wrote:> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> > On Sun, May 13, 2007 at 08:23:43PM +0200, Dag-Erling Sm??rgrav wrote:> > > Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> > > > What is the formal process to get a recent commit to -current> > > > reverted? Do I send email to core?> > > You start by talking to the person who did the commit. That much should> > > be obvious.> > I would expect a committer, who changes something as important as> > the default shell in FreeBSD, to read the freebsd-current mailing> > list and the PR database.> > I would expect a committer such as yourself to know that there are> better ways to approach this than posting to -current and threatening to> take the matter to core@.> I'm not a committer to the FreeBSD repository. I either submit patches to fix problems or code for missing libraryroutines. In this particular case, reverting the tcshimport is the correct fix (IMHO). I also didn't threaten anyone or anything. I simply wanted to know what the procedure is for getting code reverted. -- Steve --Forwarded Message Attachment--From: attilio@freebsd.orgCC: freebsd-current@freebsd.org; andre@freebsd.orgTo: stb@lassitu.deDate: Sun, 13 May 2007 21:45:45 +0200Subject: Re: panic: mutex tcp owned at /usr/src/sys/netinet/tcp_input.c:24752007/5/11, Stefan Bethke <stb@lassitu.de>:>> Am 11.05.2007 um 22:33 schrieb Andre Oppermann:>> > Stefan Bethke wrote:> >> Got this reproducable panic on AMD64 on a couple of days old -> >> current when I try to copy a file off a ZFS dataset via> >> netatalk's afpd (via TCP, no actual AppleTalk involved).> >> > This is a recursive leak of the INP_INFO_LOCK() you've hit here.> > We don't> > know yet where it gets leaked but we're working on it.>> Hhm. I can trigger it very easily. I don't have a serial console on> this box, but I could try a few things in a debugger if anyone wants> me to look at anything in particular. Hello Stefan,can you please recompile your kernel with INVARIANTS, DDB and KTR support? Just add those lines:options INVARIANTSoptions INVARIANT_SUPPORToptions KDBoptions DDBoptions KTRoptions KTR_COMPILE=(KTR_LOCK)options KTR_ENTRIES=65534 and possibly remove kbdmux from your config file (not sure if it hasstill problems with our syscons, though). Then, when you hit that panic you should just be redirected to ddb.At that point please write 'show ktr' in the ddb prompt and reportwhat it shows. Thanks in advance,Attilio -- Peace can only be achieved by understanding - A. Einstein --Forwarded Message Attachment--From: keramida@freebsd.orgCC: rwatson@freebsd.org; kian.mohageri@gmail.com; dnelson@allantgroup.com; freebsd-current@freebsd.orgTo: anderson@freebsd.orgDate: Sun, 13 May 2007 23:14:03 +0300Subject: Re: [PATCH] Fancy rc startup (revisited)On 2007-05-13 14:29, Eric Anderson <anderson@freebsd.org> wrote:>On 05/12/07 22:18, Giorgos Keramidas wrote:>> I am kind of old-fashioned in the Robert>> way too, however. If there was a way to minimize the console output>> when services are starting, i.e. to print something like:>> >> [last kernel message]>> >> Booting FreeBSD: dumpon initrandom fsck root hostid mountcritlocal>> var cleanvar random adjkerntz hostname kldxref swap sysctl netif (lo0>> fxp0) pflog pf routing devd nsswitch devfs syslogd ldconfig named>> auditd tmp cleartmp dmesg virecover local motd ntpd powerd syscons>> sshd sendmail cron securelevel power_profile inetd>> >> foo login:>> >> where each rc.d script would only print its name if it *was* enabled>> with xxx_enable, optionally followed by a parenthesized list of>> single-word status messages for each subscript/component), would be>> really neat.>> >> Is there any easy way we can 'tune' the fancy script to support the>> current output style, a very brief style like above, and then a fancy>> colorful style, depending on an rc.conf setting?> > I think the rc_fancy patch could be pretty easily tweaked to do exactly > what you say. Yeah, that was my impression from skimming through the changes :) > I might give it a go, and add that as another option to it. Maybe> then the variable should change to rc_style_* instead? Can I help with testing or even writing the necessary changes? --Forwarded Message Attachment--From: lars.engels@0x20.netCC: rwatson@freebsd.org; kian.mohageri@gmail.com; dnelson@allantgroup.com; freebsd-current@freebsd.orgTo: keramida@freebsd.orgDate: Sun, 13 May 2007 23:15:15 +0200Subject: Re: [PATCH] Fancy rc startup (revisited)On Sun, May 13, 2007 at 06:18:08AM +0300, Giorgos Keramidas wrote:> > More like Solaris 10 "boot -v", where you still get the kernel messages,> but you have a point there. I am kind of old-fashioned in the Robert> way too, however. If there was a way to minimize the console output> when services are starting, i.e. to print something like:> > [last kernel message]> > Booting FreeBSD: dumpon initrandom fsck root hostid mountcritlocal> var cleanvar random adjkerntz hostname kldxref swap sysctl netif (lo0> fxp0) pflog pf routing devd nsswitch devfs syslogd ldconfig named> auditd tmp cleartmp dmesg virecover local motd ntpd powerd syscons> sshd sendmail cron securelevel power_profile inetd> > foo login:> > where each rc.d script would only print its name if it *was* enabled> with xxx_enable, optionally followed by a parenthesized list of> single-word status messages for each subscript/component), would be> really neat. I like this idea. Optionally the names could be printed in green and reddepending on whether the service started successfully or not.--Forwarded Message Attachment--From: mashtizadeh@gmail.comCC: freebsd-fs@freebsd.org; joao.barros@gmail.com; freebsd-current@freebsd.orgTo: pjd@freebsd.orgDate: Sun, 13 May 2007 13:31:30 -0400Subject: Re: ZFS: amd64, devd, root file system.Well can't we build a boot loader off of there specification document? Also,we probably need to improve the boot loader I think something to that effectwas in the suggested projects list. Thanks to everyone who helped make a ZFS root possible. It's not so badhaving a UFS boot file system. I'm switching today :-) -- Ali Mashtizadehعلی مشتی زاده On 4/9/07, Pawel Jakub Dawidek <pjd@freebsd.org> wrote:>> On Mon, Apr 09, 2007 at 04:08:26PM +0100, Joao Barros wrote:> > I was looking at how Solaris got support for booting off ZFS and the> > patch to GRUB to support it.> > Is it feasible for FreeBSD's boot loader? What would be the main> > issue: technical or licensing?>> I don't know if there are licensing issues, probably yes if we would> like to add ZFS support to our standard loader.>> The biggest problem I see is lack of motivation on my side. Really. Why> someone would like to keep kernel on ZFS so much? This would be a huge> amount of work, I expect, and what we get in turn? On Solaris you can> only boot from a single-disk pool or from a mirrored pool. Is it really> worth the effort for us? I much more prefer to spend the time working on> something more useful than that and keep my small /boot/ file system> protected by gmirror on UFS - with this approach there are no> limitations - we can keep our root file system on compressed RAID-Z> pool.>> Of course if someone is willing to try working on this, I'm happy to> help.>> --> Pawel Jakub Dawidek http://www.wheel.pl> pjd@FreeBSD.org http://www.FreeBSD.org> FreeBSD committer Am I Evil? Yes, I Am!>>--Forwarded Message Attachment--From: linimon@lonesome.comCC: freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 13:05:06 -0500Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 10:54:25AM -0700, Steve Kargl wrote:> http://www.freebsd.org/cgi/query-pr.cgi?pr=112408 Well, you've done the right thing by sending a PR and having it assignedto the maintainer. Have you not heard anything back from mp@? mcl --Forwarded Message Attachment--From: linimon@lonesome.comCC: linimon@lonesome.com; freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 16:10:36 -0500Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 11:09:12AM -0700, Steve Kargl wrote:> Rendering the debugger useless with the default shell > would seem to be a critical bug to me, but somehow/one> decided that the severity was non-critical. We really need to redefine what 'critical' is, since that field is sooften overused as to be meaningless. That may be on of the topics I tryto address at BSDCan when talking about PR workflow. mcl --Forwarded Message Attachment--From: mp@FreeBSD.orgCC: freebsd-current@freebsd.orgTo: sgk@troutmask.apl.washington.eduDate: Sun, 13 May 2007 14:41:58 -0700Subject: Re: Process for requesting reverting patch?On 5/13/07 12:28 PM, Steve Kargl wrote:> On Sun, May 13, 2007 at 09:24:35PM +0200, Dag-Erling Sm??rgrav wrote:>> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:>>> On Sun, May 13, 2007 at 08:23:43PM +0200, Dag-Erling Sm??rgrav wrote:>>>> Steve Kargl <sgk@troutmask.apl.washington.edu> writes:>>>>> What is the formal process to get a recent commit to -current>>>>> reverted? Do I send email to core?>>>> You start by talking to the person who did the commit. That much should>>>> be obvious.>>> I would expect a committer, who changes something as important as>>> the default shell in FreeBSD, to read the freebsd-current mailing>>> list and the PR database.>> I would expect a committer such as yourself to know that there are>> better ways to approach this than posting to -current and threatening to>> take the matter to core@.>>> > I'm not a committer to the FreeBSD repository. I either > submit patches to fix problems or code for missing library> routines. In this particular case, reverting the tcsh> import is the correct fix (IMHO).> > I also didn't threaten anyone or anything. I simply wanted > to know what the procedure is for getting code reverted.> As the owner of the PR and the person that committed the recent tcsh I take it seriously when someone brings it to my attention. After the PR was assigned to me, I sent Steve two private emails on 5/7/2007 but with no response back. Given that it "works for me" on two different systems, I don't know what I could have done different. Below is the text from the second one. Mark On 5/7/07 12:15 PM, Mark Peek wrote: > On 5/7/07 8:39 AM, Mark Peek wrote: >> Thank you for bringing this to my attention. I just got back from a >> long business trip. I tried a quick repro but it worked fine for me so >> I'm getting up to date sources (buildworld, etc.) and will try again. > > I did the full rebuild and it still works fine for me: > > current32# echo $version > tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options > wide,nls,dl,al,kan,rh,color,filec > current32# cat hello.c > #include <stdio.h> > > int main(void) { > printf("hello world\n"); > return 0; > } > current32# cc -o z -g hello.c > current32# which gdb > /usr/bin/gdb > current32# gdb z > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > (gdb) run > Starting program: /root/bug/z > hello world > > Program exited normally. > (gdb) quit > current32# > > Have you seen any other reports of this issue? Could there be something > different or environmental with your system? I'm logging in as root and > using the stock .cshrc file. > > Mark > --Forwarded Message Attachment--From: stb@lassitu.deCC: freebsd-current@freebsd.org; andre@freebsd.orgTo: attilio@freebsd.orgDate: Mon, 14 May 2007 00:17:28 +0200Subject: Re: panic: mutex tcp owned at /usr/src/sys/netinet/tcp_input.c:2475 Am 13.05.2007 um 21:45 schrieb Attilio Rao: > 2007/5/11, Stefan Bethke <stb@lassitu.de>:>>>> Am 11.05.2007 um 22:33 schrieb Andre Oppermann:>>>> > Stefan Bethke wrote:>> >> Got this reproducable panic on AMD64 on a couple of days old ->> >> current when I try to copy a file off a ZFS dataset via>> >> netatalk's afpd (via TCP, no actual AppleTalk involved).>> >>> > This is a recursive leak of the INP_INFO_LOCK() you've hit here.>> > We don't>> > know yet where it gets leaked but we're working on it.>>>> Hhm. I can trigger it very easily. I don't have a serial console on>> this box, but I could try a few things in a debugger if anyone wants>> me to look at anything in particular.>> Hello Stefan,> can you please recompile your kernel with INVARIANTS, DDB and KTR > support?>> Just add those lines:> options INVARIANTS> options INVARIANT_SUPPORT> options KDB> options DDB> options KTR> options KTR_COMPILE=(KTR_LOCK)> options KTR_ENTRIES=65534>> and possibly remove kbdmux from your config file (not sure if it has> still problems with our syscons, though).>> Then, when you hit that panic you should just be redirected to ddb.> At that point please write 'show ktr' in the ddb prompt and report> what it shows. Left kbdmux in for the moment. Hit the panic, and show ktr shows nothings: db> show ktr--- End of trace buffer ---db> If you think it's useful, I can remove kdbmux as well and try again. Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 170 346 0140 --Forwarded Message Attachment--From: kris@obsecurity.orgCC: attilio@freebsd.org; freebsd-current@freebsd.org; andre@freebsd.orgTo: stb@lassitu.deDate: Sun, 13 May 2007 18:21:14 -0400Subject: Re: panic: mutex tcp owned at /usr/src/sys/netinet/tcp_input.c:2475On Mon, May 14, 2007 at 12:17:28AM +0200, Stefan Bethke wrote:> > Am 13.05.2007 um 21:45 schrieb Attilio Rao:> > >2007/5/11, Stefan Bethke <stb@lassitu.de>:> >>> >>Am 11.05.2007 um 22:33 schrieb Andre Oppermann:> >>> >>> Stefan Bethke wrote:> >>>> Got this reproducable panic on AMD64 on a couple of days old -> >>>> current when I try to copy a file off a ZFS dataset via> >>>> netatalk's afpd (via TCP, no actual AppleTalk involved).> >>>> >>> This is a recursive leak of the INP_INFO_LOCK() you've hit here.> >>> We don't> >>> know yet where it gets leaked but we're working on it.> >>> >>Hhm. I can trigger it very easily. I don't have a serial console on> >>this box, but I could try a few things in a debugger if anyone wants> >>me to look at anything in particular.> >> >Hello Stefan,> >can you please recompile your kernel with INVARIANTS, DDB and KTR > >support?> >> >Just add those lines:> >options INVARIANTS> >options INVARIANT_SUPPORT> >options KDB> >options DDB> >options KTR> >options KTR_COMPILE=(KTR_LOCK)> >options KTR_ENTRIES=65534> >> >and possibly remove kbdmux from your config file (not sure if it has> >still problems with our syscons, though).> >> >Then, when you hit that panic you should just be redirected to ddb.> >At that point please write 'show ktr' in the ddb prompt and report> >what it shows.> > Left kbdmux in for the moment. Hit the panic, and show ktr shows > nothings:> > db> show ktr> --- End of trace buffer ---> db>> > If you think it's useful, I can remove kdbmux as well and try again. You also need KTR_MASK=(KTR_LOCK) (or set debug.ktr.mask at runtime),this filters the events that are logged. Kris --Forwarded Message Attachment--From: stb@lassitu.deCC: attilio@freebsd.org; freebsd-current@freebsd.org; andre@freebsd.orgTo: kris@obsecurity.orgDate: Mon, 14 May 2007 00:33:06 +0200Subject: Re: panic: mutex tcp owned at /usr/src/sys/netinet/tcp_input.c:2475Am 14.05.2007 um 00:21 schrieb Kris Kennaway: > On Mon, May 14, 2007 at 12:17:28AM +0200, Stefan Bethke wrote:>>>> Am 13.05.2007 um 21:45 schrieb Attilio Rao:>>>>> Just add those lines:>>> options INVARIANTS>>> options INVARIANT_SUPPORT>>> options KDB>>> options DDB>>> options KTR>>> options KTR_COMPILE=(KTR_LOCK)>>> options KTR_ENTRIES=65534> You also need KTR_MASK=(KTR_LOCK) (or set debug.ktr.mask at runtime),> this filters the events that are logged. I tried setting it with sysctl:root@little:~# sysctl debug.ktr.mask=9debug.ktr.mask: 1 -> 9 But show ktr still shows nothing. Do need to set this in the loader? Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 170 346 0140 --Forwarded Message Attachment--From: stb@lassitu.deCC: attilio@freebsd.org; freebsd-current@freebsd.org; andre@freebsd.orgTo: kris@obsecurity.orgDate: Mon, 14 May 2007 00:55:40 +0200Subject: Re: panic: mutex tcp owned at /usr/src/sys/netinet/tcp_input.c:2475 Am 14.05.2007 um 00:21 schrieb Kris Kennaway: > On Mon, May 14, 2007 at 12:17:28AM +0200, Stefan Bethke wrote:>>>> Am 13.05.2007 um 21:45 schrieb Attilio Rao:>>>>> 2007/5/11, Stefan Bethke <stb@lassitu.de>:>>>>>>>> Am 11.05.2007 um 22:33 schrieb Andre Oppermann:>>>>>>>>> Stefan Bethke wrote:>>>>>> Got this reproducable panic on AMD64 on a couple of days old ->>>>>> current when I try to copy a file off a ZFS dataset via>>>>>> netatalk's afpd (via TCP, no actual AppleTalk involved).>>>>>>>>>> This is a recursive leak of the INP_INFO_LOCK() you've hit here.>>>>> We don't>>>>> know yet where it gets leaked but we're working on it.>>>>>>>> Hhm. I can trigger it very easily. I don't have a serial >>>> console on>>>> this box, but I could try a few things in a debugger if anyone >>>> wants>>>> me to look at anything in particular.>>>>>> Hello Stefan,>>> can you please recompile your kernel with INVARIANTS, DDB and KTR>>> support?>>>>>> Just add those lines:>>> options INVARIANTS>>> options INVARIANT_SUPPORT>>> options KDB>>> options DDB>>> options KTR>>> options KTR_COMPILE=(KTR_LOCK)>>> options KTR_ENTRIES=65534>>>>>> and possibly remove kbdmux from your config file (not sure if it has>>> still problems with our syscons, though).>>>>>> Then, when you hit that panic you should just be redirected to ddb.>>> At that point please write 'show ktr' in the ddb prompt and report>>> what it shows.>>>> Left kbdmux in for the moment. Hit the panic, and show ktr shows>> nothings:>>>> db> show ktr>> --- End of trace buffer --->> db>>>>> If you think it's useful, I can remove kdbmux as well and try again.>> You also need KTR_MASK=(KTR_LOCK) (or set debug.ktr.mask at runtime),> this filters the events that are logged. Nothing still. -- Stefan Bethke <stb@lassitu.de> Fon +49 170 346 0140 --Forwarded Message Attachment--From: sgk@troutmask.apl.washington.eduCC: freebsd-current@FreeBSD.orgTo: mp@FreeBSD.orgDate: Sun, 13 May 2007 15:52:55 -0700Subject: Re: Process for requesting reverting patch?On Sun, May 13, 2007 at 02:41:58PM -0700, Mark Peek wrote:> On 5/13/07 12:28 PM, Steve Kargl wrote:> >On Sun, May 13, 2007 at 09:24:35PM +0200, Dag-Erling Sm??rgrav wrote:> >>Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> >>>On Sun, May 13, 2007 at 08:23:43PM +0200, Dag-Erling Sm??rgrav wrote:> >>>>Steve Kargl <sgk@troutmask.apl.washington.edu> writes:> >>>>>What is the formal process to get a recent commit to -current> >>>>>reverted? Do I send email to core?> >>>>You start by talking to the person who did the commit. That much should> >>>>be obvious.> >>>I would expect a committer, who changes something as important as> >>>the default shell in FreeBSD, to read the freebsd-current mailing> >>>list and the PR database.> >>I would expect a committer such as yourself to know that there are> >>better ways to approach this than posting to -current and threatening to> >>take the matter to core@.> >>> >> >I'm not a committer to the FreeBSD repository. I either > >submit patches to fix problems or code for missing library> >routines. In this particular case, reverting the tcsh> >import is the correct fix (IMHO).> >> >I also didn't threaten anyone or anything. I simply wanted > >to know what the procedure is for getting code reverted.> >> > As the owner of the PR and the person that committed the recent tcsh I take > it seriously when someone brings it to my attention. After the PR was > assigned to me, I sent Steve two private emails on 5/7/2007 but with no > response back. Given that it "works for me" on two different systems, I > don't know what I could have done different. Below is the text from the > second one. I have received zero emails from you (either in my inbox or backup folderwhere spam is redirected). It would have been helpful if you actually sent a followup to the PR. -- steve _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspxReceived on Tue May 15 2007 - 22:57:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:10 UTC