cross-buildworld from i386 to alpha börked...
I tried "make buildworld TARGET_ARCH=alpha" and it croaked. Is this expected breakage for a cross-build or genuine breakage ? Poul-Henning ===> usr.sbin/pstat cc -O -pipe -mcpu=ev4-c /flat/src/usr.sbin/pstat/pstat.c /flat/src/usr.sbin/pstat/pstat.c: In function `nfs_print': /flat/src/usr.sbin/pstat/pstat.c:546: `NLOCKED' undeclared (first use in this fu nction) /flat/src/usr.sbin/pstat/pstat.c:546: (Each undeclared identifier is reported on ly once /flat/src/usr.sbin/pstat/pstat.c:546: for each function it appears in.) /flat/src/usr.sbin/pstat/pstat.c:548: `NWANTED' undeclared (first use in this fu nction) *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
In message <[EMAIL PROTECTED]>, Will Andrews writes : >On Thu, May 02, 2002 at 03:30:40PM -0700, Brooks Davis wrote: >> I haven't tryed backing the commits out yet, but I'm seeing similar behavior >> on my HP Omnibook 500. In my case, it's actually not quite hung. What >> appears to be happening is that nothing is causing the console buffer to >> actually flush. The system is up (sort of), but the only way to see the >> console output is to cause a kernel printf, say be breaking in to the >> debugger. The system is basicaly useless at that point and you can't >> shutdown cleanly. > >Similar behavior manifests itself on my -current laptop dated >before April 27. I.O.W. it appears to freeze but will flush the >console if you break to the debugger then hit 'c'. > >I believe this was caused by an earlier change to the timecounter >code. Unfortunately I didn't have time to investigate further. Do you see this with up to date -current ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of USB subsystem.
In message <[EMAIL PROTECTED]>, Josef Karthauser writes: >I'm prepared to back everything out if required, but my feeling is >that we're a stone's throw away from solving these problems; it's >just I'm throwing stones slower than a seasoned kernel hacker would. Don't even think about it! I am very impressed that you have managed to make your way through the diff between FreeBSD and NetBSD, and I would expect that everybody with USB devices recognize the advantage of having a new USB-stuckee in FreeBSD totally balances out any inconvenience the current problems might cause. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: clock drift in -CURRENT
In message <[EMAIL PROTECTED]>, Daniel Rock writes: >Poul-Henning Kamp schrieb: >> >> When was your source tree from on that kernel ? >> >> I'm not too confident in your diagnosis, mostly because we don't >> have a counter like you describe :-) >> >> My guess is that ntpd get confused. >> >> Please try a newer kernel, a number of bug(lets) have been fixed >> since march. >> >> If it happens again, please email me the output of: >> ntpdc -c peer >> ntpdc -c loopi >> ntpdc -c kerni >> dmesg >> >[...] > >My kernel war relatively recent at the time of last boot - build >around March 2nd from -CURRENT sources a few hours before. Right, but look at a cvs log src/sys/kern/kern_tc.c... I've fixed at least one bug in the NTP steering since then. >If someone runs -CURRENT with default HZ of 100 and moans 247 days >later, his -CURRENT cannot be called -CURRENT any more... :-) >I am now running an up-to-date -CURRENT. I have set HZ=1, so >I don't have to wait another 50 days. Hope this high HZ value has >no negative impact on the test. > >I will inform you in 3 days if anything strange happens again. Cool. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PHY patch, please test.
In message <[EMAIL PROTECTED]>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> >> This patch simplifies the auto-negotiation in the MII/PHY code, but >> I don't have enough weird ethernet cards to test it out. >> >> Please test and if it doesn't work send me dmesg -v output and info >> on what netcard it breaks. >> >> http://phk.freebsd.dk/patch/phy00.patch >> >> I hope to commit it this weekend. > >So, in a nutshell, you removed the ability for the card driver to request >the phy driver to wait for negotiation to complete, and removed the >interlock that prevents duplicate negotiation requests when the negotiation >took longer than the allotted time? yes and yes. The wait for negotiation to complete does not make sense, and in particular the 500ms worth of DELAY() calls is totally bogus. If a driver wants to wait 500msec and see if it got link, it should wait 500msec for and query status or better yet: just react to the events coming back up to it about like and state changes. There is no such thing as duplicate autoneg requests, if you send a new one (like we do after the 5 or 10 sec timeout) the negotiation starts over. The 5 seconds for 10/100 is probably a couple of seconds too short but we don't notice because 10/100 negotiation is very fast (sub second). The 10 seconds for gigE _is_ too short, since cisco switches may hold carrier down for several seconds, and it may take a couple of tries of a couple (of a couple of seconds each) to get the line equalization right. (I'm still experimenting with this bit.) In general, I think we need a much more capable state engine for the autoneg stuff. Right now we start our timeout when we start autonegotiation, but carrier from the remote end may not appear for another N seconds, so our timeout must be long enough for that AND the basic negotiation timeout. We should probably have a short timeout (maybe 5 seconds) when we receive no carrier, from we see carrier we until we abort 10/100 autoneg should probably be a 10 sec delay and for gigE autoneg more like 30 seconds. Things are compounded by driver mistakes like the if_nge driver calling mii_tick() for every MII/PHY interrupt in addition to every second, this makes any timeout shorter by about 3 seconds in practice since the PHY typically sends 3 interrupts per autonegotiation. And as you said yourself: there is additional NEWBUS'ing to be done in this area. I've sent email to a couple of strategig NetBSD'ers, but received no replies. I don't have time to go all the way through this area, but I have a need to get NetGear622 solid and working and I'll do what it takes to get that done at least. Volounteers welcome. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: clock drift in -CURRENT
When was your source tree from on that kernel ? I'm not too confident in your diagnosis, mostly because we don't have a counter like you describe :-) My guess is that ntpd get confused. Please try a newer kernel, a number of bug(lets) have been fixed since march. If it happens again, please email me the output of: ntpdc -c peer ntpdc -c loopi ntpdc -c kerni dmesg Thanks! Poul-Henning In message <[EMAIL PROTECTED]>, Daniel Rock writes: >Hi, > >after almost 50 days of uptime I suddenly noticed an extreme clock drift >in current. Here is an excerpt from my /var/log/messages (March 8th was my >last reboot time): > >Mar 8 18:38:07 gate syslogd: kernel boot file is /boot/kernel/kernel >Mar 8 18:38:07 gate kernel: Copyright (c) 1992-2002 The FreeBSD Project. >[...] >Apr 27 20:03:10 gate ntpd[157]: time reset -0.250532 s >Apr 27 20:18:14 gate ntpd[157]: time reset 0.446208 s >Apr 27 20:39:57 gate ntpd[157]: time reset -0.820100 s >Apr 27 21:11:19 gate ntpd[157]: time reset 0.887949 s >Apr 27 21:25:33 gate ntpd[157]: time reset -0.228488 s >Apr 27 21:54:35 gate ntpd[157]: time reset -0.395676 s >Apr 28 12:59:15 gate ntpd[157]: time reset -0.381327 s >Apr 28 13:19:52 gate ntpd[157]: time reset 0.815323 s >Apr 28 13:31:50 gate ntpd[157]: time reset 0.844171 s >Apr 28 13:58:52 gate ntpd[157]: time reset 1.447538 s >Apr 28 14:14:58 gate ntpd[157]: time reset 0.915263 s >Apr 28 14:36:38 gate ntpd[157]: time reset 0.860966 s >Apr 28 14:47:29 gate ntpd[157]: time reset 0.984839 s >Apr 28 15:06:59 gate ntpd[157]: time reset 1.025584 s >Apr 28 15:27:32 gate ntpd[157]: time reset 1.156623 s >Apr 28 15:48:59 gate ntpd[157]: time reset 0.896726 s >Apr 28 16:00:52 gate ntpd[157]: time reset 0.973291 s >Apr 28 16:24:24 gate ntpd[157]: time reset 1.212415 s >Apr 28 16:37:19 gate ntpd[157]: time reset 0.859379 s >Apr 28 16:56:49 gate ntpd[157]: time reset 0.914863 s >Apr 28 17:13:05 gate ntpd[157]: time reset 1.100234 s >Apr 28 17:35:59 gate ntpd[157]: time reset 1.231416 s >Apr 28 17:59:53 gate ntpd[157]: time reset 1.026558 s >Apr 28 18:11:59 gate ntpd[157]: time reset 0.995554 s >Apr 28 18:34:45 gate ntpd[157]: time reset 1.140261 s >Apr 28 18:54:19 gate ntpd[157]: time reset 0.856611 s >Apr 28 19:07:15 gate ntpd[157]: time reset 1.094226 s >Apr 28 19:22:30 gate ntpd[157]: time reset 0.879816 s >Apr 28 19:47:25 gate ntpd[157]: time reset 1.332108 s >Apr 28 20:06:56 gate ntpd[157]: time reset 0.949128 s >Apr 28 20:28:27 gate ntpd[157]: time reset 0.906657 s >Apr 28 20:41:37 gate ntpd[157]: time reset 0.877976 s >Apr 28 20:57:57 gate ntpd[157]: time reset 1.103012 s >Apr 28 21:28:19 gate ntpd[157]: time reset 1.607870 s >Apr 28 21:59:43 gate ntpd[157]: time reset 1.253603 s >Apr 28 22:14:46 gate ntpd[157]: time reset 1.181729 s >Apr 28 22:47:13 gate ntpd[157]: time reset 1.573263 s >Apr 28 23:07:47 gate ntpd[157]: time reset 0.836291 s >Apr 28 23:20:52 gate ntpd[157]: time reset 1.105955 s >Apr 28 23:35:59 gate ntpd[157]: time reset 0.839469 s >[...] > >So the machine is losing a second every 20 minutes. After a reboot everything >was OK again. > >The drift began exactly at the moment the counter for clock interrupts got >past the 2^31 mark (I have HZ=500 in the kernel): >500 ticks/s * 49.7 days ~ 2^31 ticks > >After a reboot everything went ok again. > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PHY patch, please test.
This patch simplifies the auto-negotiation in the MII/PHY code, but I don't have enough weird ethernet cards to test it out. Please test and if it doesn't work send me dmesg -v output and info on what netcard it breaks. http://phk.freebsd.dk/patch/phy00.patch I hope to commit it this weekend. I am also interested to hear from people using the NetGear 622 or other if_nge based gigabit cards. Thanks in advance! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vinum out of commission?
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey" w rites: >> This is a non-GEOM kernel - GEOM wouldn't even let me disklabel the >> drives. > >That doesn't surprise me. You might ask phk how he proposes to >address that issue. This is ongoing work in GEOM. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern kern_tc.c src/sys/sys timepps.h timetc.h
Please let me know if you see any changes in timekeeping behaviour as a result of this series of commits. >phk 2002/04/26 14:51:08 PDT > > Modified files: >sys/kern kern_tc.c >sys/sys timepps.h timetc.h > Log: > Now that the private parts of timecounters are no longer being fingered > by other bits of code, split struct timecounter into two. > > struct timecounter contains just the bits which pertains to the hardware > counter and the reading of it. > > struct timehands (as in "the hands on a clock") contains all the ugly bit > fidling stuff. Statically compile ten timehands. > > This commit is the functional part. A later cosmetic patch will rename > various variables and fieldnames. > > Revision ChangesPath > 1.126 +109 -143 src/sys/kern/kern_tc.c > 1.15 +3 -1 src/sys/sys/timepps.h > 1.51 +1 -12 src/sys/sys/timetc.h > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Memory overwrite problem in the -current kernel ??
In message <[EMAIL PROTECTED]>, Brian Dean writes: >On Tue, Apr 23, 2002 at 01:54:17PM +0200, Poul-Henning Kamp wrote: >> This commit detects a memory overwrite problem in the kernel which >> happens before we ever get into userland for the first time. > >Do you know the address being corrupted? If so, try breaking into ddb >early on and set a hardware watchpoint. It was a modified pointer being returned to free(9), it's solved now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Memory overwrite problem in the -current kernel ??
This commit detects a memory overwrite problem in the kernel which
happens before we ever get into userland for the first time.
The commit which causes the problem to appear is my own commit to
subr_disklabel.c (1.65).
If the block below is put back in subr_disklabel.c the memory overwrite
problem goes away (or at least doesn't happen in GEOM).
My testbox is a single-cpu machine.
Something is screwed somewhere...
Poul-Henning
] #ifdef notquite
] /*
] * Mutex to use when delaying niced I/O bound processes in bioqdisksort().
] */
] static struct mtx dksort_mtx;
] static void
] dksort_init(void)
] {
]
] mtx_init(&dksort_mtx, "dksort", NULL, MTX_DEF);
] }
] SYSINIT(dksort, SI_SUB_DRIVERS, SI_ORDER_MIDDLE, dksort_init, NULL)
] #endif
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp
writes:
>phk 2002/04/23 04:48:45 PDT
>
> Modified files:
>sys/geom geom.h geom_dump.c geom_enc.c
> geom_slice.c geom_subr.c
> Log:
> Introduce some serious paranoia to try to catch a memory overwrite problem
> as early as possible.
>
> Sponsored by: DARPA & NAI Labs
>
> Revision ChangesPath
> 1.13 +13 -4 src/sys/geom/geom.h
> 1.7 +1 -0 src/sys/geom/geom_dump.c
> 1.3 +1 -0 src/sys/geom/geom_enc.c
> 1.11 +2 -0 src/sys/geom/geom_slice.c
> 1.8 +46 -2 src/sys/geom/geom_subr.c
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
In message <[EMAIL PROTECTED]>, Robe rt Watson writes: >> rc.devfs > >Unfortunately, this works poorly for cloned devices. At various meetings, >there has been discussion of a devfsd and/or devd; that's probably the >vehicle for doing that kind of administrative change. Unfortunately, it >doesn't exist yet, although I think Warner had done some prototyping. Dima is actually working on this problem right now, and he has sent me a prototype which shows great promise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i386 tinderbox failure
Allerede fixet. In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes: >===> nge >===> nmdm >===> ntfs >===> nullfs >===> pcn >===> plip >===> portalfs >===> ppbus >===> ppi >===> pps >===> procfs >===> pseudofs >===> random >===> rl >===> rp >===> sf >===> sis >===> sk >===> sn >===> snp >===> sound >===> sound/pcm >===> sound/driver >===> sound/driver/als4000 >===> sound/driver/ad1816 >===> sound/driver/cmi >===> sound/driver/cs4281 >===> sound/driver/csa >===> sound/driver/ds1 >===> sound/driver/emu10k1 >===> sound/driver/es137x >===> sound/driver/ess >===> sound/driver/fm801 >===> sound/driver/ich >===> sound/driver/maestro >===> sound/driver/maestro3 >===> sound/driver/mss >===> sound/driver/neomagic >===> sound/driver/sb16 >===> sound/driver/sb8 >===> sound/driver/sbc >===> sound/driver/solo >===> sound/driver/t4dwave >===> sound/driver/via82c686 >===> sound/driver/vibes >===> sound/driver/driver >===> sppp >===> ste >===> sym >===> syscons >===> syscons/blank >===> syscons/daemon >===> syscons/dragon >===> syscons/fade >===> syscons/fire >===> syscons/green >===> syscons/logo >===> syscons/rain >===> syscons/snake >===> syscons/star >===> syscons/warp >===> syscons/apm >===> sysvipc >===> sysvipc/sysvmsg >===> sysvipc/sysvsem >===> sysvipc/sysvshm >===> ti >===> tl >===> twe >===> tx >===> txp >===> ucom >===> udbp >===> ufm >===> ugen >===> uhid >===> ukbd >===> ulpt >===> umapfs >===> umass >===> umodem >===> ums >===> unionfs >/d/home/des/tinderbox/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:58: >vm/vm_zone.h: No such file or directory >mkdep: compile failed >*** Error code 1 > >Stop in /d/home/des/tinderbox/src/sys/modules/unionfs. >*** Error code 1 > >Stop in /d/home/des/tinderbox/src/sys/modules. >*** Error code 1 > >Stop in /tmp/des/obj/i386/d/home/des/tinderbox/src/sys/GENERIC. >*** Error code 1 > >Stop in /d/home/des/tinderbox/src. >*** Error code 1 > >Stop in /d/home/des/tinderbox/src. > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usb lpt borked?
This does not solve the "usbsyn" hang for me. Poul-Henning In message <[EMAIL PROTECTED]>, Josef Karthauser writes: > >Try this which Scott Long submitted a few days ago: > >Index: uhci.c >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >RCS file: /usr/home/ncvs/src/sys/dev/usb/uhci.c,v >retrieving revision 1.104 >diff -u -r1.104 uhci.c >--- uhci.c 1 Apr 2002 22:03:37 - 1.104 >+++ uhci.c 5 Apr 2002 08:17:03 - >@@ -2051,6 +2051,7 @@ > xfer->pipe->intrxfer =3D 0; > } = > =20 > uhci_abort_xfer(xfer, USBD_CANCELLED); >+ usb_transfer_complete(xfer); > } = > =20 > > /* Close a device interrupt pipe. */ > > > >Joe > >--5mCyUwZo2JvN/JJP >Content-Type: application/pgp-signature >Content-Disposition: inline > >-BEGIN PGP SIGNATURE- >Version: GnuPG v1.0.6 (FreeBSD) >Comment: For info see http://www.gnupg.org > >iEYEARECAAYFAjyu3KcACgkQXVIcjOaxUBZIagCdHKJRbLmQsWMMptnp6fpU+oMA >ri4AoMlMKEWJcJyo1N45a78glGOjiZQa >=y8rs >-END PGP SIGNATURE- > >--5mCyUwZo2JvN/JJP-- > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch: make syslog stop spamming any root it finds...
I have always hated the three lines in /etc/syslog.conf which spams root with far too many and far too irrellevant syslog messages, in some cases even with several copies of them. For the life of me I cannot understand why we feel the need to whine like that at any root which crosses our way, so unless somebody can explain to me why this is vital, I'll commit the following patch. Poul-Henning Index: syslog.conf === RCS file: /home/ncvs/src/etc/syslog.conf,v retrieving revision 1.20 diff -u -r1.20 syslog.conf --- syslog.conf 11 Mar 2002 19:34:57 - 1.20 +++ syslog.conf 5 Apr 2002 21:24:07 - @@ -12,9 +12,6 @@ mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/log/cron -*.err root -*.notice;news.err root -*.alertroot *.emerg* # uncomment this to log all writes to /dev/console to /var/log/console.log #console.info /var/log/console.log -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"ccache" and FreeBSD kernels...
Just for fun I tried compiling some kernels with "ccache". It cuts the time it takes to compile LINT in half. And that is on a dual-athlon-1800 system with 2GB RAM and 15kRPM scsi disks, slower systems will see larger improvements. There about 100 files overlab between kernels, probably mostly stuff in libkern. Conclusion: Most people can probably benefit from using ccache. It's actually a pretty neat idea, which (despite what O'brien will yell at me) I would suggest should be put in the compiler itself. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: comparing executables
In message <[EMAIL PROTECTED]>, Ju lian Elischer writes: > > >On Wed, 3 Apr 2002, Poul-Henning Kamp wrote: > >> >> >How can I find out which binaries have changed? >> >they are all different according to cksum so I assume >> >that there is a timestamp or something in them. >> >Is there a way to compare only the text segments? >> >> You can do wonders with objdump(1) and diff. > >hmmm ok.. >what about libraries? .a you take apart with ar(1), .so you're stuck as far as my knowledge goes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: comparing executables
>How can I find out which binaries have changed? >they are all different according to cksum so I assume >that there is a timestamp or something in them. >Is there a way to compare only the text segments? You can do wonders with objdump(1) and diff. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LINT compile error...
bang# make cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue ../../../dev/usb/ohci.c cc1: warnings being treated as errors ../../../dev/usb/ohci.c: In function `ohci_dump_ed': ../../../dev/usb/ohci.c:1840: warning: bitmap is not type int (arg 4) *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB printing broken?
In message <[EMAIL PROTECTED]>, Alexander Leidi nger writes: >On 30 Mär, I wrote: > >> I've a kernel from Mar 27 which isn't able to print with my USB printer. > >A kernel from today isn't able to print too, but at least usbdevs >doesn't hang anymore. go back about 3 weeks in sys/dev/usb and it works. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
In message <[EMAIL PROTECTED]>, Kyle Butt writes: >> I've stared at the data file and I'll be damned if I can find anything >> which would case the clock to double its speed :-( > >Perhaps something else is causing the clock to run twice as fast? >Maybe two things that are working properly are both incrementing >the clock? Well, obviously something causes it, but I have no idea what at this moment. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current:LINT broken...
bang# make LINT perl5 makeLINT.pl < NOTES > LINT bang# config LINT LINT: unknown option "CV_DEBUG" If one stubbornly fixes that, the next roadblock becomes: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue ../../../dev/pdq/pdq.c cc1: warnings being treated as errors ../../../dev/pdq/pdq.c: In function `pdq_initialize': ../../../dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes: >In message <[EMAIL PROTECTED]>, David Malone writes: >>On Tue, Mar 26, 2002 at 09:59:29AM +0100, Poul-Henning Kamp wrote: >>> This is an interesting machine: A K6 wiht ACPI, havn't seen that >>> before. >> >>I had one of these machines and concluded that the ACPI time counter >>was busted. I dunno if it is possible to sanity check the time >>counter before using it? I just switched to using the TSC early in >>boot and forgot about it. > >That is what I try to do, and I recently rewrote the code in current >for that exact reason, so I'm very interested in seeing the diagnostic >output (boot -v) from a -current kernel on these motherboards. I've stared at the data file and I'll be damned if I can find anything which would case the clock to double its speed :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Time counter broken?
In message <[EMAIL PROTECTED]>, Ollivier Robert wri tes: >According to Poul-Henning Kamp: >> I think I found a mistake I made, can you try this patch please ? > >Rev. 1.118 of kern_tc.c fixed the problem, thanks. Great. Sorry for the trouble. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Who's working on the dump to disk code ?
Somebody recently mentioned working on the dump-to-disk code, could that person please contact me ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Time counter broken?
>This patch is broken because it doesn't fix the comment, which should >read > ... 4398 / 2048 is very close to ideal. The commited version is better :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Surefire -current panic...
On a diskless machine:
ktrace ntpdate -d $someserver
gives an sure-fire panic:
../../../kern/kern_synch.c:429: sleeping with "process lock" locked from ../../.
./kern/subr_trap.c:76
Debugger("witness_sleep")
Stopped at Debugger+0x40: xorl%eax,%eax
db> trace
Debugger(c02f20c0) at Debugger+0x40
witness_sleep(0,0,c02eeef8,1ad) at witness_sleep+0xfb
msleep(ccdfd2d8,0,4d,c02fbfce,0) at msleep+0x72
nfs_flush(ccdfd294,cce37980,1,cce25700,1) at nfs_flush+0x663
nfs_fsync(cce5cab4) at nfs_fsync+0x19
vinvalbuf(ccdfd294,1,cce37980,cce25700,0,0) at vinvalbuf+0x9f
nfs_vinvalbuf(ccdfd294,1,cce37980,cce25700,1) at nfs_vinvalbuf+0x114
nfs_write(cce5cbec,ccde6a40,cce25600,cce25888,cce5cbec) at nfs_write+0x120
ktrwrite(ccdfd294,ccde6a40,0,5) at ktrwrite+0x101
ktrpsig(ccdfd294,e,804a6b4,cce25888,0) at ktrpsig+0x78
postsig(e) at postsig+0xaa
userret(cce25700,cce5cd48,11,0,0) at userret+0x4a
syscall(2f,2f,2f,0,0) at syscall+0x2b4
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (4, FreeBSD ELF, write), eip = 0x280aac83, esp = 0xbfbffb50, ebp = 0
xbfbffb9c ---
db>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Time counter broken?
I think I found a mistake I made, can you try this patch please ? Index: kern_tc.c === RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v retrieving revision 1.117 diff -u -r1.117 kern_tc.c --- kern_tc.c 19 Mar 2002 21:24:06 - 1.117 +++ kern_tc.c 28 Mar 2002 12:00:13 - @@ -241,7 +241,7 @@ * The range is +/- 500PPM so we can multiply by about 8500 * without overflowing. 4398/1024 = is very close to ideal. */ - scale += (tc->tc_adjustment * 4398) >> 10; + scale += (tc->tc_adjustment * 4398) >> 11; scale /= tc->tc_tweak->tc_frequency; tc->tc_scale = scale * 2; } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Time counter broken?
Hmm, I'll look closer at this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Time counter broken?
My best guess would be that your bios plays power-management tricks with your CPU frequency... Alternatively, since this is -current: that something is truly and utterly dysfunctional right now. Poul-Henning In message <[EMAIL PROTECTED]>, Ollivier Robert wr ites: >According to Poul-Henning Kamp: >> output from >> dmesg > >Copyright (c) 1992-2002 The FreeBSD Project. >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. >FreeBSD 5.0-CURRENT #13: Tue Mar 26 17:48:00 CET 2002 >[EMAIL PROTECTED]:/src/src/sys/i386/compile/nCAERDONN >Preloaded elf kernel "/boot/kernel.new/kernel" at 0xc0379000. >Preloaded elf module "/boot/kernel.new/vesa.ko" at 0xc03790ac. >Preloaded elf module "/boot/kernel.new/linux.ko" at 0xc037915c. >Preloaded elf module "/boot/kernel.new/sysvshm.ko" at 0xc037920c. >Preloaded elf module "/boot/kernel.new/sysvsem.ko" at 0xc03792bc. >Preloaded elf module "/boot/kernel.new/sysvmsg.ko" at 0xc037936c. >Preloaded elf module "/boot/kernel.new/snd_ad1816.ko" at 0xc037941c. >Preloaded elf module "/boot/kernel.new/snd_pcm.ko" at 0xc03794d0. >Preloaded elf module "/boot/kernel.new/random.ko" at 0xc0379580. >Timecounter "i8254" frequency 1193182 Hz >Timecounter "TSC" frequency 498744847 Hz >CPU: Pentium III/Pentium III Xeon/Celeron (498.74-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > >Features=0x383fbff >real memory = 268435456 (262144K bytes) >avail memory = 257261568 (251232K bytes) >Pentium Pro MTRR support enabled >VESA: v2.0, 512k memory, flags:0x1, mode table:0xc0317282 (122) >VESA: ELSA GLoria Synergy >Using $PIR table, 9 entries at 0xc00fdf30 >npx0: on motherboard >npx0: INT 16 interface >pcib0: at pcibus 0 on motherboard >pci0: on pcib0 >pcib1: at device 1.0 on pci0 >pci1: on pcib1 >pci1: at device 0.0 (no driver attached) >isab0: at device 7.0 on pci0 >isa0: on isab0 >atapci0: port 0xfcb0-0xfcbf at device 7.1 on pci0 >ata0: at 0x1f0 irq 14 on atapci0 >ata1: at 0x170 irq 15 on atapci0 >pci0: at device 7.2 (no driver attached) >pci0: at device 7.3 (no driver attached) >pci0: at device 17.0 (no driver attached) >ahc0: port 0xf800-0xf8ff mem 0xfecff000-0xfecf >irq 9 at device 18.0 on pci0 >aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs >orm0: at iomem 0xc8000-0xcc7ff,0xc-0xc7fff on isa0 >sc0: on isa0 >sc0: VGA <16 virtual consoles, flags=0x200> >vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 >atkbdc0: at port 0x64,0x60 on isa0 >atkbd0: irq 1 on atkbdc0 >psm0: irq 12 on atkbdc0 >psm0: model Generic PS/2 mouse, device ID 0 >fdc0: at port >0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 >fdc0: FIFO enabled, 8 bytes threshold >fd0: <1440-KB 3.5" drive> on fdc0 drive 0 >sio0 at port 0x3f8-0x3ff irq 4 on isa0 >sio0: type 16550A >sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A >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) >pcm0: at port 0x530-0x53f,0x388-0x38b,0x220-0x22f irq 5 drq 3,1 on isa0 >IPsec: Initialized Security Association Processing. >acd0: CDROM at ata1-master PIO4 >(noperiph:atapi1:0:-1:-1): Registered SIM for ata1 >Waiting 2 seconds for SCSI devices to settle >Ignoring 0x5b bytes of additional inq info. >atapicam0: unknown CMD (0x12) - ILLEGAL REQUEST asc=0x24 ascq=0x00 error=0x04 >Ignoring 0x5b bytes of additional inq info. >Ignoring 0x8f bytes of additional inq info. >da0 at ahc0 bus 0 target 0 lun 0 >da0: Fixed Direct Access SCSI-3 device >da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled >da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) >da1 at ahc0 bus 0 target 1 lun 0 >da1: Fixed Direct Access SCSI-2 device >da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled >da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) >Mounting root from ufs:/dev/da0s1a >cd0 at atapi1 bus 0 target 0 lun 0 >cd0: Removable CD-ROM SCSI-0 device >cd0: 3.300MB/s transfers >cd0: Attempt to query device size failed: NOT READY, Medium not present > >> sysctl kern.timecounter > >kern.timecounter.nbintime: 8693386 >kern.timecounter.nbinuptime: 87686706 >kern.timecounter.nmicrotime: 8670228 >kern.timecounter.nnanotime: 23160 >kern.timecounter.nmicrouptime: 280 >kern.timecounter.nnanouptime: 135 >kern.timecounter.nge
Re: Time counter broken?
In message <[EMAIL PROTECTED]>, Ollivier Robert wr ites: >Since I upgraded to my CURRENT machine into two days ago sources, I'm >getting this from ntpd. > >Mar 28 07:37:03 caerdonn ntpd[171]: time reset -1.151848 s >Mar 28 08:00:47 caerdonn ntpd[171]: time reset -1.222628 s output from dmesg sysctl kern.timecounter Please ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current. (1/8)
Can you put the file a place where I can fetch it ? my antique mailer cannot seem to extract it from your emails... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
In message <[EMAIL PROTECTED]>, Kyle Butt writes:
>At Wed, 27 Mar 2002 10:49:15 +0100,
>Poul-Henning Kamp wrote:
>>
>>
>> Uhm, I just whacked the code into my editor, you may need
>> more #includes like or
>
>Thanks. That did the trick. Now how do I go about finding that
>port? Is that something I can glean from the dmesg, or do I have
>to look somewhere else for that?
You should have a line like this in your dmesg:
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
in that case 0xe408 is the port.
>
>>
>> In message <[EMAIL PROTECTED]>, Kyle Butt writes:
>> >At Wed, 27 Mar 2002 08:42:49 +0100,
>> >
>> >bash-2.04$ gcc -o apci apci.c
>> >In file included from apci.c:2:
>> >/usr/include/machine/cpufunc.h:72: syntax error before `bsfl'
>> >/usr/include/machine/cpufunc.h:72: syntax error before `mask'
>> >/usr/include/machine/cpufunc.h: In function `bsfl':
>> >/usr/include/machine/cpufunc.h:74: syntax error before `result'
>> >...
>> >
>> >I looked, apparently it doesn't like u_int. I don't know why.
>> >
>> >Poul-Henning Kamp wrote:
>> >>
>> >> In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>> >> >Kyle Butt <[EMAIL PROTECTED]> writes:
>> >> >> My system clock is running twice as fast as it should be,
>> >> >> but it doesn't affect timing functions. Ex:
>> >> >> [...]
>> >> >> Has anyone else experienced this problem?
>> >> >
>> >> >I'm seeing the exact same problem on, guess what...
>> >>
>> >> Can I get one of you to collect a hund-thousand samples of the ACPI
>> >> timer for me ?
>> >>
>> >> You need to find the exact I/O port it lives on, and then run
>> >> the following program and send me the uuencoded stdout ?
>> >>
>> >> #include
>> >> #include
>> >>
>> >> #define PORT 0x1008
>> >> #define N 10
>> >> uint32_t h[N];
>> >>
>> >> main()
>> >> {
>> >> FILE *f;
>> >>
>> >> f = fopen("/dev/io", "r");
>> >>
>> >> memset(h, 0, sizeof h);
>> >> insl(PORT, h, N);
>> >> write (1, h, sizeof h);
>> >> }
>> >>
>> >>
>> >>
>> >> --
>> >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>> >> [EMAIL PROTECTED] | TCP/IP since RFC 956
>> >> FreeBSD committer | BSD since 4.3-tahoe
>> >> Never attribute to malice what can adequately be explained by incompetence.
>> >>
>> >
>>
>> --
>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>> [EMAIL PROTECTED] | TCP/IP since RFC 956
>> FreeBSD committer | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by incompetence.
>>
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
Uhm, I just whacked the code into my editor, you may need
more #includes like or
In message <[EMAIL PROTECTED]>, Kyle Butt writes:
>At Wed, 27 Mar 2002 08:42:49 +0100,
>
>bash-2.04$ gcc -o apci apci.c
>In file included from apci.c:2:
>/usr/include/machine/cpufunc.h:72: syntax error before `bsfl'
>/usr/include/machine/cpufunc.h:72: syntax error before `mask'
>/usr/include/machine/cpufunc.h: In function `bsfl':
>/usr/include/machine/cpufunc.h:74: syntax error before `result'
>...
>
>I looked, apparently it doesn't like u_int. I don't know why.
>
>Poul-Henning Kamp wrote:
>>
>> In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>> >Kyle Butt <[EMAIL PROTECTED]> writes:
>> >> My system clock is running twice as fast as it should be,
>> >> but it doesn't affect timing functions. Ex:
>> >> [...]
>> >> Has anyone else experienced this problem?
>> >
>> >I'm seeing the exact same problem on, guess what...
>>
>> Can I get one of you to collect a hund-thousand samples of the ACPI
>> timer for me ?
>>
>> You need to find the exact I/O port it lives on, and then run
>> the following program and send me the uuencoded stdout ?
>>
>> #include
>> #include
>>
>> #define PORT 0x1008
>> #define N 10
>> uint32_t h[N];
>>
>> main()
>> {
>> FILE *f;
>>
>> f = fopen("/dev/io", "r");
>>
>> memset(h, 0, sizeof h);
>> insl(PORT, h, N);
>> write (1, h, sizeof h);
>> }
>>
>>
>>
>> --
>> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>> [EMAIL PROTECTED] | TCP/IP since RFC 956
>> FreeBSD committer | BSD since 4.3-tahoe
>> Never attribute to malice what can adequately be explained by incompetence.
>>
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
>Kyle Butt <[EMAIL PROTECTED]> writes:
>> My system clock is running twice as fast as it should be,
>> but it doesn't affect timing functions. Ex:
>> [...]
>> Has anyone else experienced this problem?
>
>I'm seeing the exact same problem on, guess what...
Can I get one of you to collect a hund-thousand samples of the ACPI
timer for me ?
You need to find the exact I/O port it lives on, and then run
the following program and send me the uuencoded stdout ?
#include
#include
#define PORT 0x1008
#define N 10
uint32_t h[N];
main()
{
FILE *f;
f = fopen("/dev/io", "r");
memset(h, 0, sizeof h);
insl(PORT, h, N);
write (1, h, sizeof h);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
In message <[EMAIL PROTECTED]>, David Malone writes: >On Tue, Mar 26, 2002 at 09:59:29AM +0100, Poul-Henning Kamp wrote: >> This is an interesting machine: A K6 wiht ACPI, havn't seen that >> before. > >I had one of these machines and concluded that the ACPI time counter >was busted. I dunno if it is possible to sanity check the time >counter before using it? I just switched to using the TSC early in >boot and forgot about it. That is what I try to do, and I recently rewrote the code in current for that exact reason, so I'm very interested in seeing the diagnostic output (boot -v) from a -current kernel on these motherboards. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
;#devicewb # Winbond W89C840F >#devicexl # 3Com 3c90x (``Boomerang'', ``Cyclone'') > >device ef # Multiple ethernet frames support >optionsETHER_II# enable Ethernet_II frame >optionsETHER_8023 # enable Ethernet_802.3 (Novell) frame >optionsETHER_8022 # enable Ethernet_802.2 frame >optionsETHER_SNAP # enable Ethernet_802.2/SNAP frame > ># ISA Ethernet NICs. pccard nics included. >#devicecs # Crystal Semiconductor CS89x0 NIC ># 'device ed' requires 'device miibus' >#deviceed # NE[12]000, SMC Ultra, 3c503, DS8390 cards >#deviceex # Intel EtherExpress Pro/10 and Pro/10+ >#deviceep # Etherlink III based cards >#devicefe # Fujitsu MB8696x based cards >#devicelnc # NE2100, NE32-VL Lance Ethernet cards >#devicesn # SMC's 9000 series of ethernet chips >#devicexe # Xircom pccard ethernet > ># ISA devices that use the old ISA shims >#devicele > ># Wireless NIC cards >#devicean # Aironet 4500/4800 802.11 wireless NICs. >#deviceawi # BayStack 660 and others >#devicewi # WaveLAN/IEEE 802.11 wireless NICs. >#devicewl # Older non 802.11 Wavelan wireless NIC. > ># Pseudo devices - the number indicates how many units to allocate. >device random # Entropy device >device loop# Network loopback >device ether # Ethernet support >device sl # Kernel SLIP >device ppp 1 # Kernel PPP >device tun # Packet tunnel. >device pty # Pseudo-ttys (telnet etc) >device md # Memory "disks" >device gif # IPv6 and IPv4 tunneling >device faith # IPv6-to-IPv4 relaying (translation) >optionsXBONEHACK >device stf #6to4 IPv6 over IPv4 encapsulation > ># The `bpf' device enables the Berkeley Packet Filter. ># Be aware of the administrative consequences of enabling this! >device bpf # Berkeley packet filter > >optionsMROUTING# Multicast routing >optionsIPFIREWALL #firewall >optionsIPFIREWALL_VERBOSE #enable logging to syslogd(8) >optionsIPFIREWALL_FORWARD #enable transparent proxy support >optionsIPFIREWALL_VERBOSE_LIMIT=100#limit verbosity >optionsIPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default >optionsIPV6FIREWALL#firewall for IPv6 >optionsIPV6FIREWALL_VERBOSE >optionsIPV6FIREWALL_VERBOSE_LIMIT=100 >optionsIPV6FIREWALL_DEFAULT_TO_ACCEPT >optionsIPDIVERT#divert sockets >optionsIPFILTER#ipfilter support >optionsIPFILTER_LOG#ipfilter logging >optionsIPFILTER_DEFAULT_BLOCK #block all packets by default >optionsIPSTEALTH #support for stealth forwarding >optionsTCPDEBUG > ># RANDOM_IP_ID causes the ID field in IP packets to be randomized ># instead of incremented by 1 with each packet generated. This ># option closes a minor information leak which allows remote ># observers to determine the rate of packet generation on the ># machine by watching the counter. >optionsRANDOM_IP_ID > ># USB support >#deviceuhci# UHCI PCI->USB interface >#deviceohci# OHCI PCI->USB interface >#deviceusb # USB Bus (required) >#deviceudbp# USB Double Bulk Pipe devices >#deviceugen# Generic >#deviceuhid# "Human Interface Devices" >#deviceukbd# Keyboard >#deviceulpt# Printer >#deviceumass # Disks/Mass storage - Requires scbus and da >#deviceums # Mouse >#deviceurio# Diamond Rio 500 MP3 player >#deviceuscanner# Scanners ># USB Ethernet, requires mii >#deviceaue # ADMtek USB ethernet >#devicecue # CATC USB ethernet >#devicekue # Kawasaki LSI USB ethernet > >device pcm >device midi >device seq > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Cross architecture disklabels...
I belive GEOM will now correctly identify the following label formats on all platforms: MSDOS MBR MSDOS MBR extended partitions FreeBSD/i386 disklabel FreeBSD/alpha disklabel Solaris/disklabel This in practice means that one can move a disk from one architecture to another and get at the slices/partitions etc. This also means that I belive GEOM will DTRT for -current users for a long stretch of the road, and would therefore encourage more people to please test it out. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
In message <[EMAIL PROTECTED]>, Robe rt Watson writes: >Something that phk and I have discussed out-of-band is the idea of keying >phkmalloc behavior to kernel selection. I.e., exposing a policy sysctl >from the kernel, keyed to the kernel identity/option, causing phkmalloc to >behave different based on the kernel selection. This would allow DEBUG to >turn on maximal debugging, but GENERIC to have phkmalloc behave "like a >release". I said this as possible with a sysctl, I still think it is moderately disgusting though. You can do the same thing more visible by having /etc/rc* fiddle /etc/malloc.conf based on uname(1). >We will actually be offering at least three seperate kernels on the DP cd: > >- GENERIC, which resembles a normal release GENERIC >- DEBUG, which has uber-debugging features >- NEWCARD, which offers the NEWCARD feature set I would expect the three planned DP's to have these properties: One DEBUG kernel with: INVARIANTS WITNESS DDB One GENERIC kernel with: INVARIANTS DDB Userland: DP1 + DP2: malloc AJ DP3: malloc A Now, I also have to say that I'm not going to do any of this, so this will be my last email on the topic: Do whatever you think is the right thing to do. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
In message <[EMAIL PROTECTED]>, Robe rt Watson writes: >A few weeks ago, I would have believed you. Except that using -J was a >workaround recommended in a recent security advisory--prior to >recommending it, I ran it on a server of mine for a few days. You'd be >surprised how many random applications keel over, and the performance >impact it has for some specific types of applications. No, I will not be surprised no matter what you tell me. I used to keep save all emails I got about phkmalloc nailing bugs, now I only track "significant" ones. But let me turn it around, what would it take for you to accept AJ in the developer release ? Better diagnostics ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
In message <[EMAIL PROTECTED]>, Robe rt Watson writes: >With new userland code coming into -CURRENT at a rapid rate, it may be >useful in -CURRENT for developers. For DPs, probably not. I don't have to tell you what the 'D' in 'DP' means, right ? :-) Robert, I can only say that I disagree 100% with you. In principle because I think only -RELEASE should not have J, and I think even -RELEASE should have A. In practice I think this is completely l00ney, considering what we have done in the kernel, worrying about AJ related false hits is sooo totally down in the noise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LINT börked...
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes - Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../../.. -I../. ./../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -DGPROF -DG PROF4 -DGUPROF -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 - fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue ../../../dev/bktr/bktr_i2c. c ../../../dev/bktr/bktr_i2c.c: In function `bt848_i2c_attach': ../../../dev/bktr/bktr_i2c.c:87: structure has no member named `i2c_sc' ../../../dev/bktr/bktr_i2c.c:92: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:93: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:95: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:101: dereferencing pointer to incomplete type ../../../dev/bktr/bktr_i2c.c:103: dereferencing pointer to incomplete type -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: turning off malloc's AJ by default
In message <[EMAIL PROTECTED]>, "David O'Brien" writes: >The RE's are wanting to ship 5.0 DP#1 w/this patch applied. >If having 'AJ' by default is deemed not useful (by being removed from the >DP), it sounds like we should just turn it off. > >Unless there is strong objection, I plan on committing this. I firmly belive that only things which ship as FreeBSD-%d.%d-RELEASE should have the AJ options turned off. We want both our own code and 3rd party code to find the bugs in a DP release rather than in a RELEASE. Put a prominent notice in the release note, put a pointer to the recent libz scare if you feel like, and say that since this is about trying out and testing, we have set these options to help people flush out bugs. The steady trickle of emails I receive about things exposed by AJ is a clear indication that we need it on as much as possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UFS2, GEOM & DARPA - don't get all excited, OK ?
--- Begin Message --- Ok, Kirk and I thought it would stirr a buzz once we even mentioned "UFS2" so let me set the record straight, (or at least firmly crooked): UFS2 is UFS Extended Attributes in the inodes. That's it. No more, no less. In particular that means: No journaling. No Btree-directories, no in-directory inodes. Because we need to increase the size of the inode we chose to "run a revision" and call it UFS2, and obviously, we will make sure all relevant fields get the space they need, or at reserve space for their growth as part of this. Specifically inode numbers, block numbers and time_t will have 64 bit available. We may attempt a couple of neat tricks at the same time: per inode blocksize and lazy inode initializtion. The former might improve I/O performance down the road, the latter speed up newfs and fsck. We will try to avoid forking sys/ufs/ufs if we can, we may have to push some stuff from ufs to ffs to make that happen. In practice this also means a sweep through all the userland stuff to make it work with UFS2: newfs, fsck, tunefs, quotactl, sysinstall etc (that's largely going to be my problem). Incidently there is a not insignificant crossover between UFS and disklabels and from there into GEOM, so some of the things I will be doing in that corner will be hard to attribute only to one or the other of these two DARPA funded projects. The one thing we RSN will cry to have is endian/wordsize agnostic UFS. That is not part of the DARPA project description and it is unlikely to "sneak" into it. We have it in mind though. (The NETBSD work is not uninteresting, but both Kirk and I feel that there might be a better and even more general solution.) And this is yet a problem with significant crossover to the issues I have in GEOM with reading labeling data structures of disks in alien formats so some of the technology I plan for GEOM might be applicable to UFS as well. Finally, If you are in the US and you think it is a good thing that DARPA sponsors stuff like this, don't forget to say so to people who might, directly or indirectly, provide feedback to DARPA. I hope this answers the FAQ on UFS2, GEOM and all that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. --- End Message ---
Re: "Unexpected Soft Update Inconsistency"
Sounds like your disklabel is smaller than your filesystem ? In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes : >I've got a -CURRENT system that is seriously resisting attempts to >revive it. No matter how many times I run fsck(8), it tells me, > >** /dev/ad0s1a >** Last Mounted on / >** Root file system >** Phase 1 - Check Blocks and Sizes > >CANNOT READ BLK: 8407744 >UNEXPECTED SOFT UPDATE INCONSISTENCY > >CONTINUE? yes > >THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8407744, 8407745, 8407746, 8407747, >8407748, 8407749, 8407750, 8407751, 8407752, 8407753, 8407754, 8407755, 8407756, >8407757, 8407758, 8407759, >** Phase 2 - Check Pathnames >** Phase 3 - Check Connectivity >** Phase 4 - Check Reference Counts >** Phase 5 - Check Cyl groups >133720 files, 1429523 used, 2651122 free (34074 frags, 327131 blocks, 0.8% >fragmentation) > >* FILE SYSTEM STILL DIRTY * > >* PLEASE RERUN FSCK * > >There are no reports of hard errors, so I believe this is purely a >"soft" error. Any advice on how to fix? >-- >Crist J. Clark | [EMAIL PROTECTED] > | [EMAIL PROTECTED] >http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fla LINT breakage.
You're welcome to commit it :-)
Poul-Henning
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>Fixes format warnings. Since there was so much... bitching about my
>last commit to something contrib/* I'm posting the fix here.
>
>Index: fla.c
>===
>RCS file: /home/ncvs/src/sys/contrib/dev/fla/fla.c,v
>retrieving revision 1.29
>diff -u -r1.29 fla.c
>--- fla.c 12 Sep 2001 08:36:59 - 1.29
>+++ fla.c 19 Mar 2002 20:22:51 -
>@@ -181,8 +181,9 @@
> enum doc2k_work what;
>
> if (fla_debug > 1)
>- printf("flastrategy(%p) %s %x, %d, %ld, %p)\n",
>- bp, devtoname(bp->bio_dev), bp->bio_flags, bp->bio_blkno,
>+ printf("flastrategy(%p) %s %x, %lld, %ld, %p)\n",
>+ bp, devtoname(bp->bio_dev), bp->bio_flags,
>+ (long long)bp->bio_blkno,
> bp->bio_bcount / DEV_BSIZE, bp->bio_data);
>
> sc = bp->bio_dev->si_drv1;
>@@ -225,8 +226,9 @@
> ENTER();
>
> if (fla_debug > 1 || error) {
>- printf("fla%d: %d = rwe(%p, %d, %d, %d, %ld, %p)\n",
>- unit, error, bp, unit, what, bp->bio_pblkno,
>+ printf("fla%d: %d = rwe(%p, %d, %d, %lld, %ld, %p)\n",
>+ unit, error, bp, unit, what,
>+ (long long)bp->bio_pblkno,
> bp->bio_bcount / DEV_BSIZE, bp->bio_data);
> }
> if (error) {
>
>
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Current::LINT not happy about Ipfilter
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica - I../../../contrib/ipfilter -I../../../../include -DGPROF -DGPROF4 -DGUPROF -D_KE RNEL -ffreestanding -include opt_global.h -fno-common -elf -malign-functions=4 - fno-builtin -mpreferred-stack-boundary=2 -Werror -pg -mprofiler-epilogue ../../. ./contrib/ipfilter/netinet/ip_fil.c ../../../contrib/ipfilter/netinet/ip_fil.c: In function `iplattach': ../../../contrib/ipfilter/netinet/ip_fil.c:412: `inet6sw' undeclared (first use in this function) ../../../contrib/ipfilter/netinet/ip_fil.c:412: (Each undeclared identifier is r eported only once ../../../contrib/ipfilter/netinet/ip_fil.c:412: for each function it appears in. ) ../../../contrib/ipfilter/netinet/ip_fil.c:412: `ip6_protox' undeclared (first u se in this function) ../../../contrib/ipfilter/netinet/ip_fil.c: In function `ipldetach': ../../../contrib/ipfilter/netinet/ip_fil.c:562: `inet6sw' undeclared (first use in this function) ../../../contrib/ipfilter/netinet/ip_fil.c:562: `ip6_protox' undeclared (first u se in this function) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: -CURRENT Feature Slush is OVER
In message <p05101511b8bab342dc49@[128.113.24.47]>, Garance A Drosihn writes: >At 8:35 AM -0800 3/17/02, David O'Brien wrote: >>My earlier concerns about the use of Perforce were when a developers >>expected other developers to use Perforce for _shared_ development. >>Or that tried to claim that their code was "published" if it was >>in the Perforce depot on Freefall. > >Exactly my concerns, too. I have just started two days ago using P4 to track the sparc64 stuff and confidently say that contrary to the ill effects I hear people complain about I have yet to see any signs of hair-loss, lack of sleep, early aging, republicanism or uncontrollable urges to go to Tenerife. I can think of many things wrong with P4 and with having a parallel environment to our CVS tree. But I also think having a P4 tree where people can colaborate beats not having it by a large margin. So could I suggest that the people who are so much against P4 tell us what the alternative they want us to use is ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing CSRG libm?
In message <[EMAIL PROTECTED]>, Steve Kargl wr ites: >A long time ago I submitted PR misc/17848 which >removes CSRG libm sources. The audit trail shows >some commentary, but AFAICT nothing much has been >done based on that commentary. With the upcoming >release of of 5.0, I think we should consider the >removal od CSRG libm and the repo copying of msun >to libm; otherwise we'll drag CSRG libm around >until 6.0. Good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current lock warning...
In message <[EMAIL PROTECTED]>, Hiten Pandya w rites: >I haven't seen this. I built a kernel today, and I have a dual processor >machine. Are you using any special kernel options, such as VFS_BIO_DEBUG >or something, or am I talking nuts? :) Well, I have. On a single CPU net-booting -current. No. Yes :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current lock warning...
I get this one on every single boot. We're not shipping the snapshot
with that in place, right ?
real memory = 268423168 (262132K bytes)
avail memory = 257003520 (250980K bytes)
acquiring duplicate lock of same type: "thrd_sleep"
1st @ ../../../vm/vm_map.c:2288
2nd @ ../../../vm/vm_kern.c:172
Debugger("witness_lock")
Stopped at Debugger+0x40: xorl%eax,%eax
db> trace
Debugger(c02e9ace) at Debugger+0x40
witness_lock(c038afe4,8,c02f8440,ac,c038afb4) at witness_lock+0x546
_sx_xlock(c038afe4,c02f8440,ac,bfc0,c0435c5c) at _sx_xlock+0xa1
_vm_map_lock(c038afb4,c02f8440,ac,c034a840,1) at _vm_map_lock+0x16
kmem_alloc(c038afb4,3000,c0e41a00,0,c02fa434) at kmem_alloc+0x41
_zget(c0e41a00,bfc0,0,c0435cd0,c0281769) at _zget+0xfa
zalloc(c0e41a00,c034a840,1,c02f8630,a7) at zalloc+0x3b
vmspace_alloc(0,bfc0,c035c940,c02f8630,8f0) at vmspace_alloc+0x2d
vmspace_fork(c035c940,cbb9ad24,c0331f84,cbb9ab00,c0331d60) at vmspace_fork+0x4d
vm_forkproc(c0332080,cbb9ab00,cbb9ac00,20014) at vm_forkproc+0xc6
fork1(c0332080,20014,c0332130) at fork1+0xd58
create_init(0,432c00,432000,0,c012368c) at create_init+0x17
mi_startup() at mi_startup+0x90
begin() at begin+0x43
db>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes:
>> It would be much more valuable to add a
>> mremap(void *from, void *to, size_t length);
>>
>> since that can _solve_ the problem in _all_ cases, rather than
>> add more or less byzantine workarounds for silly benchmarks.
>
>You're right that it would be a better optimization, however it's
>much more code to write than simply passing a flag down to the code
>responsible for the allocation especially when you _know_ you'll
>need it.
Since when has going that extra mile to do it right been the wrong
thing to do in FreeBSD ? :-)
And everybody with VM clue I've asked says it would be trivial to
flip two page-table entries, so for all I care it can be
mexchangemapping(void *from, void *to, size_t length)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >* Poul-Henning Kamp <[EMAIL PROTECTED]> [020313 22:43] wrote: >> >> But if somebody wants to try to code this optimization, I'll be more >> than happy to review the result. I just don't expect it to do much >> in "real-life" as opposed to "silly benchmark" situations. > >Have you thought about issuing a madvise(MADV_WILLNEED) after the >brk/mmap call in malloc, at least doing it when it's called via >realloc, this might get rid of the superfolous (sp?) page faults >that David Greenman reported. It would be much more valuable to add a mremap(void *from, void *to, size_t length); since that can _solve_ the problem in _all_ cases, rather than add more or less byzantine workarounds for silly benchmarks. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
In message <[EMAIL PROTECTED]>, David Greenman writes:
>>The above perl program results in a loop more or less like:
>>
>> n = 2
>> for (i = 0; i < 100; i++)
>> realloc(n++);
>>
>>Now, if you read _any_ malloc(3) man page, they will tell you that there
>>is no way it can be guaranteed that this does not result in a lot of
>>copying.
>
> Um, except that copying isn't what is causing the problem. The performance
>problem is apparantly caused by tens of thousands of page faults per second as
>the memory is freed and immediately reallocated again from the kernel. Doesn't
>phkmalloc keep a small pool of allocations around to avoid problems like
>this?
Yes it does, but it doesn't help here. Basically what happens is
that relloc() is called on to extend a string of one megabyte by
another page, so it allocates 1M+1p and copies the contents over.
Now, in this very particular cornercase, we might be able to optimize
for just being able to allocate the next page, but in all real-world
scenarioes I've seen, real usage is more like:
long loop {
realloc(n++);
do some other stuff involving malloc/free/realloc
}
which negates that optimization.
But if somebody wants to try to code this optimization, I'll be more
than happy to review the result. I just don't expect it to do much
in "real-life" as opposed to "silly benchmark" situations.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
In message <[EMAIL PROTECTED]>, John Indra writes:
>Dear all...
>
>This morning I found a very interesting mail. All of you can see it from:
>
>http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1669241+0+current/freebsd-questions
>
>As stated in the mail, a simple Perl script like this:
>
>-- Begin --
>
>#!/usr/bin/perl
>
>$temp = "";
>$begin = time;
>for ($i = 0; $i < 100; $i++) {
>$result .= "$i\n";
>}
>print "Exec time: ", time - $begin, " secs\n";
>
>-- End --
>
>can show that there PROBABLY is something wrong with malloc() in -CURRENT
>and -STABLE.
No, there is nothing wrong as such, it is a deliberate design-choice
in phkmalloc() which conflicts with perls use of realloc().
Basically I profiled a lot of programs and found that very few programs
used realloc() and decided that consequently it was the least important
of the entries from a performance point of view.
The above perl program results in a loop more or less like:
n = 2
for (i = 0; i < 100; i++)
realloc(n++);
Now, if you read _any_ malloc(3) man page, they will tell you that there
is no way it can be guaranteed that this does not result in a lot of
copying.
(insert bikeshed discussion about wisdom of the above code, assume
I maintain the opinion throughout that it is braindamaged to be
that stupid in a so central program as perl)
At the cost of considerable complexity (a mremap(2) implementation amongst
other things), realloc in phkmalloc(3) can be optimised but it is not
on my plate right now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: GEOM code ready for testing
In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes: >> > >Would GEOM support accessing a device via multiple paths? (ie could we >> > >write a method that would do that?) >> > >> > Yes, that would be possible. > >FWIW, Justin and I have been thinking about (for years, actually) doing >multipath support inside CAM. You know, thinking about it, I actually think it is a stronger model to do it in GEOM, since that will be able to cover more cases than CAM will be able to. That said, since I am not on the hook to implement either so I will not impose my opinion one one way or the other :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM code ready for testing
In message <[EMAIL PROTECTED]>, Rasmus Skaarup writes: >> Well, the recognition/configuration issue is not one GEOM magically can >> solve for you, but GEOM promises that if you can recognize it and >> configure it, GEOM will not get in your way for doing what you want. > >But what if the name of the device somehow depended on the ID on the >device? So you could recognize the same disk on multiple hosts, and having >the same name for the device on each host. > >But this should maybe be left up to the method to assign? The methods decide the names of their g_geom and g_providers. If you look in the BSD and MBR modules, you can see how they simply tack a letter or "s%d" onto the name from below. There is nothing to prevent you from creating an entirely new name if you want to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM code ready for testing
In message <[EMAIL PROTECTED]>, Rasmus Skaarup writes: >> Basically when a new "g_provider" is created it is offered to each method >> in turn and if that method likes it, it can stick g_geom on top of it. > >Ahh.. But do you rule out the possibility that two methods could apply to >a g_provider? Or is this even a problem? the relationships in geom are: g_method --- 1 : N --- g_geom Each method can have multiple instances. g_geom --- 1 : N --- g_consumer An instance can attach to multiple providers (striping, mirroring, raid5) g_geom --- 1 : N --- g_provider An instance can split into more providers. (BSD/disklabel, MBR) g_provider --- 1 : N --- g_consumer Multiple consumers can attach to one provider. >> How you would recognize the same disk on thre different paths is a good >> question. We could implement (if we don't already have it) an >> ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice >> and you could query that. > >Hmm, but I'm not sure all kinds of storage devices have serialnumbers that >could be fetched (tape devices for instance?) and can we rely on the >hardware manufacturers to provide unique serialnumbers? Well, the recognition/configuration issue is not one GEOM magically can solve for you, but GEOM promises that if you can recognize it and configure it, GEOM will not get in your way for doing what you want. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM code ready for testing
In message <[EMAIL PROTECTED]>, Rasmus Skaarup writes: > >On Tue, 12 Mar 2002, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, Carl Makin writes: > >> >On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote: >> > >> >> The GEOM code is now ready for early testing: >> > >> >Would GEOM support accessing a device via multiple paths? (ie could we >> >write a method that would do that?) >> >> Yes, that would be possible. > >Have you given any thought to how that might be implemented? If somekind >of ID is required to identify the same disk via multiple paths, in which >part of GEOM will this be implemented? > >I can't figure out from your documentation whether you have somekind of >"Master GEOM" instance that initiates the device recognition, or otherwise >how is this initiated? Basically when a new "g_provider" is created it is offered to each method in turn and if that method likes it, it can stick g_geom on top of it. How you would recognize the same disk on thre different paths is a good question. We could implement (if we don't already have it) an ioctl/BIO_GETATTR which returns the serial number(s) of the diskdevice and you could query that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GEOM code ready for testing
In message <[EMAIL PROTECTED]>, Carl Makin writes: >Hi, > >On Mon, 2002-03-11 at 06:34, Poul-Henning Kamp wrote: > >> The GEOM code is now ready for early testing: > >Would GEOM support accessing a device via multiple paths? (ie could we >write a method that would do that?) Yes, that would be possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
the zlib double free bug: Belived harmless with phkmalloc
--- Begin Message ---
I just sent this to security-officer.
Please notice that if you have ports or applications linked with
other allocators than the libc malloc from FreeBSD this statement
does not apply.
Poul-Henning
--- Forwarded Message
To: [EMAIL PROTECTED]
Subject: the zlib double free bug
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Date: Mon, 11 Mar 2002 23:13:57 +0100
Message-ID: <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
As author of our malloc(3) it is my opinion that we are not vulnerable to
this (kind of) bug.
Most mallocs keep their housekeeping data right next to the allocated
range. This gives rise to all sorts of unpleassant situations if
programs stray outside the dotted line, free(3) things twice or
free(3) modified pointers.
phkmalloc(3) does not store housekeeping next to allocated data,
and in particular it has code that detects and complains about
exactly the kind of double free this advisory talks about:
critter phk> cat a.c
main()
{
char *p;
p = malloc(256);
p = malloc(256);
free(p);
free(p);
}
critter phk> make a
cc -O -pipe a.c -o a
a.c: In function `main':
a.c:7: warning: assignment makes pointer from integer without a cast
a.c:8: warning: assignment makes pointer from integer without a cast
critter phk> ./a
a in free(): error: chunk is already free
Abort (core dumped)
critter phk>
The malloc flag 'A' determines if the situation is just warned about
or if the program should call abort(3).
- --
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
--- End of Forwarded Message
--- End Message ---
GEOM code ready for testing
The GEOM code is now ready for early testing: http://phk.freebsd.dk/geom There is a known timing issue with ATA controllers with both a master and a slave disk, sos@ and I are looking into it. Apart from that it "should just work". Email all reports to me and don't annoy the lists yet. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Won't boot after the commits to timecounter code
The only thing I know off right now is this thing from BDE which I havn't been able to verify yet: From:Bruce Evans <[EMAIL PROTECTED]> Subject: dummy_timecounter broken; breaks booting with -d To: <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> Date:Tue, 05 Mar 2002 08:09:26 +1100 %%% Index: kern_tc.c === RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v retrieving revision 1.116 diff -u -2 -r1.116 kern_tc.c --- kern_tc.c 26 Feb 2002 09:16:27 - 1.116 +++ kern_tc.c 4 Mar 2002 21:08:03 - @@ -192,4 +252,14 @@ gen = tc->tc_generation; bintime2timeval(&tc->tc_offset, tvp); + /* +* XXX dummy_timecounter is now broken. Its tc_get_timecount +* needs to be called before it works, and that doesn't +* always happen naturally. In particular, we spin forever +* here after booting with -d unless we do an unnatural call +* here, since the screen timeout code is always run on entry +* to ddb, and it calls here. +*/ + if (gen == 0 && timecounter == &dummy_timecounter) + (void)tc->tc_get_timecount(tc); } while (gen == 0 || gen != tc->tc_generation); } %%% Bruce In message <20020306054514.GA395@gzl>, [EMAIL PROTECTED] writes: >Hello. >After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped >booting just after the message: > >Timecounter "i8254" frequency 1193182 Hz > >With some debugging printf()'s inserted, I found it was tc->tc_get_timecount() >called from tco_delta() called just after the bcopy() in tc_windup(). >So maybe the next place I have to look at is i8254_get_timecount(), which is in >/sys/i386/isa/clock.c, but the last (effective) commit to this file is >revision 1.180(at the end of January). > >I couldn't even drop into DDB; no response other than to power button. >The last bootable(and stable so far) kernel is from 2002-02-24. >I don't think this is caused by some leftover in the work directory >since I always build kernels in a new empty directory under /usr/obj. > >Any (clue|fix)\? > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >That's the crux of the situation, John. I do not believe you have >the right to hold this work off, at least not based on any of the >explanations you have given so far. Why don't you for a change, just stop being so ego-centered and instead head to the page at http://www.freebsd.org/smp/ and find yourself a task which is free for grabs, rather than insist that you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. One could point at such a gem as: "add locking to NFS" which I am sure John and the rest of us would love to see you tackle... Give us peace Matt... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, David Malone writes: >On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: >> >I presume you'd push the rules in using sysclt or did you have >> >something more filesystem like in mind? >> >> Nope, just a sysctl. > >I guess then you just need a sysctl which lets you read the rules >for a given devfs mount point and another which lets you set the >rules for a given defvs mount point. I don't know if we also need >a global ruleset which is applied if the mount point speficic rules >fail to match. True, forgot that. In that case lets make them a mount option using mux@ new nmount(2) systemcall. >The rules should be able to chmod and chown the nodes. Should it >also be able to prevent the creation matching nodes also? Yes. >You mentioned matching on the names drivers and nodes. Are there >any other sorts of matching we are likely to need? Ideally I would want to match on names, driver names and types, ie: name=="ttyd0", driver=="sio" and type=="tty", but I think the important thing here is to make it exensible in the future. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, David Malone writes: >> Not really, the basic idea is just a linked list of rules: > >> name=="/dev/uscanner*" -> chmod 0644 >> driver=="bpf" -> chown user > >> It's not too much work, I just havn't had the time for it yet. >> (Junior Kernel Hackers can apply here :-) > >OK - I thought you had something much more complex in mind after >your example: "plugging the nuclear reactor into the serial port >where you had a a modem plugged in yesterday". No, that was to show why "persistence" is a bad idea. >I presume you'd push the rules in using sysclt or did you have >something more filesystem like in mind? Nope, just a sysctl. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, David Malone writes: >On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes >> : >> >I've checked the manpages, the files in /etc, and Googled, and I can't >> >find the answer. I am begining to worry there isn't one. How does one >> >change the permissions on dynamically created devices? That is, when >> >the node comes into existence, it has the permissions I want, and not >> >necessarily the defaults. >> >> The overall plan is that it will be possible to push a ruleset into >> the kernel which changes the defaults. ETA: this summer (If I have to >> do it, if somebody wants to help code it it can probably be done faster). > >I have a very similar problem trying to sync my Handspring Visor >as a regular user 'cos the devices only come into existance when >you press the sync button. > >Do you have any designs for this ruleset stuff? From what you said >at BSDconEurope it will have to be fairly complicated to achieve >the your aim of being better than a static permission for a given >device. Not really, the basic idea is just a linked list of rules: name=="/dev/uscanner*" -> chmod 0644 driver=="bpf" -> chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) >Otherwise, one option would just be to have devfs check for a file >in the /dev directory it is mounted over and then use that files >permissions as a default. That would at least get us back the >features of the old /dev which we're missing now. This is much harder than you think... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs(5) Permissions
In message <[EMAIL PROTECTED]>, "Crist J. Clark" writes : >I've checked the manpages, the files in /etc, and Googled, and I can't >find the answer. I am begining to worry there isn't one. How does one >change the permissions on dynamically created devices? That is, when >the node comes into existence, it has the permissions I want, and not >necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current broken in lukemftpd
/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar ray `remotehost' has non-integer type /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err or before `transflag' /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: warning: d ata definition has no type or storage class ls-unmain.c: In function `ls_main': ls-unmain.c:370: `revnamecmp' undeclared (first use in this function) ls-unmain.c:370: (Each undeclared identifier is reported only once ls-unmain.c:370: for each function it appears in.) ls-unmain.c:372: `revacccmp' undeclared (first use in this function) ls-unmain.c:374: `revstatcmp' undeclared (first use in this function) ls-unmain.c:376: `revmodcmp' undeclared (first use in this function) ls-unmain.c:379: `namecmp' undeclared (first use in this function) ls-unmain.c:381: `acccmp' undeclared (first use in this function) ls-unmain.c:383: `statcmp' undeclared (first use in this function) ls-unmain.c:385: `modcmp' undeclared (first use in this function) ls-unmain.c:390: `printscol' undeclared (first use in this function) ls-unmain.c:392: `printlong' undeclared (first use in this function) ls-unmain.c:394: `printcol' undeclared (first use in this function) ls-unmain.c: In function `mastercmp': ls-unmain.c:750: `namecmp' used prior to declaration *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >:> >:>I strongly disagree. I have yet to see any technical description of >:>this so-called overall design that shows any incompatibility, and what >:>I decide to do with my time is my business. >: >:Matt, >: >:That particular protest is rather hollow, considering that you were >:one of the first people to not show up for the SMPng work whereas >:John has been consistently chugging along on the job all the way. >:At this point in time, until he is officially unseated John is our >:designated SMPng architect and his word is pretty final. >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > >Oooh... so you mean that since I was working full time and unable >to contribute, somehow this disqualifies me now? No, but it does make you, like the rest of us, underlings to John architectural direction. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >:Because the critical_* changes you are doing don't match up to the overall >:design. See my mail to -arch for more on that though. At some point in the >:future I think that this work can fit in rather well to the cpu_critical_foo >:stuff (which can be split out from critical_enter/exit now). However, at this >:stage I would rather avoid complex optimizations of APIs that may change in the >:future. There is more to be gained from locking subsystems. >:... >:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ >:"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > >I strongly disagree. I have yet to see any technical description of >this so-called overall design that shows any incompatibility, and what >I decide to do with my time is my business. Matt, That particular protest is rather hollow, considering that you were one of the first people to not show up for the SMPng work whereas John has been consistently chugging along on the job all the way. At this point in time, until he is officially unseated John is our designated SMPng architect and his word is pretty final. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Updated ATAPI/CAM patches
In message <[EMAIL PROTECTED]>, Jul ian Elischer writes: >I think it's better to commit it now and have it fixed in situ. >It's new functionality so committing it with bugs will not break anyone. >it will however get more work done on it and more testing. > > [...] > >Well you are one of the main CAM peopel.. we are relying on you and >Soeren. Hmm, let me try that line of logic for a moment: I think we should have an Amdahl 6600 port of FreeBSD and we should commit it right now. [...] Well, you (Julian) you seem to have nothing to do.. we are relying on you and some other random people we can think of. Sounds weird, doesn't it ? I don't know what axe you are grinding Julian, but if you are not the one to do the work, I don't think you are in a position to ask for "commit it now and have it fixed in situ". Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes: >In message: <[EMAIL PROTECTED]> >"George V. Neville-Neil" <[EMAIL PROTECTED]> writes: >: The problem here is process. The FreeBSD project now has more than >: 12 core members and more than 12 committers. With any number larger >: than 12 it is VERY HARD to reach consensus on anything. Without a >: process by which we agree to reach consensus it is impossible. > >There are only only 8 core team members, unless you mean something >different by "core" here than [EMAIL PROTECTED] > >Otherwise, I tend to agree with your basic premise that it is process >and not tools at the heart of this problem. In addition to process it might be attitude. Core@ was not elected to be ornamental. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: calcru: negative time of XXX
>FreeBSD 5.0-CURRENT #1: Sun Feb 24 22:06:53 CET 2002 This is not a -current kernel when we talk about ACPI timecounters, you want a kernel with this commit in it: phk 2002/02/25 01:51:18 PST Modified files: sys/dev/acpica acpi_timer.c Log: Add a new test_counter() function which tries to determine the width of the inter-value histogram for 2000 samples. If the width is 3 or less for 10 consequtive samples, we trust the counter to be good, otherwise we use the *_safe() method. [...] Poul-Henning In message <[EMAIL PROTECTED]>, Frode Nordahl writes: >On Tue, 26 Feb 2002, Poul-Henning Kamp wrote: > >> please send me /var/run/dmesg.boot from a "boot -v" on a current kernel >> and output from "sysctl kern.timecounter" please ? > >$ sysctl kern.timecounter >kern.timecounter.nmicrotime: 3838 >kern.timecounter.nnanotime: 3 >kern.timecounter.nmicrouptime: 1 >kern.timecounter.nnanouptime: 4 >kern.timecounter.ngetmicrotime: 13562 >kern.timecounter.ngetnanotime: 1 >kern.timecounter.ngetmicrouptime: 25811 >kern.timecounter.ngetnanouptime: 19 >kern.timecounter.hardware: ACPI > > >$ cat /var/run/dmesg.boot >Copyright (c) 1992-2002 The FreeBSD Project. >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. >FreeBSD 5.0-CURRENT #1: Sun Feb 24 22:06:53 CET 2002 >[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC >Preloaded elf kernel "/boot/kernel/kernel" at 0xc0535000. >Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05350b4. >Calibrating clock(s) ... TSC clock: 400916162 Hz, i8254 clock: 1193202 Hz >CLK_USE_I8254_CALIBRATION not specified - using default frequency >Timecounter "i8254" frequency 1193182 Hz >CLK_USE_TSC_CALIBRATION not specified - using old calibration method >Timecounter "TSC" frequency 400911616 Hz >CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x652 Stepping = 2 > >Features=0x183f9ff >real memory = 134152192 (131008K bytes) >Physical memory chunk(s): >0x1000 - 0x0009efff, 647168 bytes (158 pages) >0x0055c000 - 0x07fe7fff, 128499712 bytes (31372 pages) >avail memory = 125100032 (122168K bytes) >bios32: Found BIOS32 Service Directory header at 0xc00fad90 >bios32: Entry = 0xfb200 (c00fb200) Rev = 0 Len = 1 >pcibios: PCI BIOS entry at 0xf+0xb230 >pnpbios: Found PnP BIOS data at 0xc00fbe90 >pnpbios: Entry = f:bec0 Rev = 1.0 >Other BIOS signatures found: >null: >random: >mem: >Pentium Pro MTRR support enabled >pci_open(1): mode 1 addr port (0x0cf8) is 0x805c >pci_open(1a): mode1res=0x8000 (0x8000) >pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) >Using $PIR table, 7 entries at 0xc00fdf00 >npx0: on motherboard >npx0: INT 16 interface >acpi0: on motherboard >acpi0: power button is handled as a fixed feature programming model. >Timecounter "ACPI" frequency 3579545 Hz >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >acpi_cpu0: on acpi0 >acpi_button0: on acpi0 >acpi_pcib0: port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 >pci0: physical bus=0 > map[10]: type 3, range 32, base e000, size 26, enabled >found->vendor=0x8086, dev=0x7190, revid=0x03 > bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 >found->vendor=0x8086, dev=0x7191, revid=0x03 > bus=0, slot=1, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > map[10]: type 1, range 32, base e8102000, size 12, enabled > map[14]: type 1, range 32, base e800, size 20, enabled >found->vendor=0x1013, dev=0x6003, revid=0x01 > bus=0, slot=4, func=0 > class=04-01-00, hdrtype=0x00, mfdev=0 > intpin=a, irq=9 > powerspec 2 supports D0 D1 D2 D3 current D0 >found->vendor=0x8086, dev=0x7110, revid=0x02 > bus=0, slot=7, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > map[20]: type 4, range 32, base f000, size 4, enabled >found->vendor=0x8086, dev=0x7111, revid=0x01 > bus=0, slot=7, func=1 > class=01-01-80, hdrtype=0x00, mfdev=0 > map[20]: type 4, range 32, base e000, size 5, enabled >found->vendor=0x8086, dev=0x7112, revid=0x01 > bus=0, slot=7, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > intpin=d, irq=3 > map[90]: type 4, range 32, base 5000, size 4, enabled >found->vendor=0x8086, dev=0x7113, revid=0x02 > bus=0, slot=7, func=3 > class=06-80-00, hdrtype=0x00, mfdev=0 >
you broke current in some weird way...
My machine panics somewhere inside the BIOS after your commit today. Tree checked out "2002/02/25 15:45:52 PST" boots fine, one from "2002/02/25 16:05:52 PST" tanks like this: ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it pcm: pcm0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it orm0: at iomem 0xc8000-0xcbfff,0xc-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 Fatal trap 12: page fault while in vm86 mode fault virtual address = 0xfffe fault code = user read, page not present instruction pointer = 0xf000:0xf961 stack pointer = 0x0:0xff8 frame pointer = 0x0:0x0 code segment= base 0x80808080, limit 0x8080, type 0x0 = DPL 0, pres 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, vm86, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at 0xf961: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf961 fault code = supervisor read, page not present instruction pointer = 0x8:0xc029ce44 stack pointer = 0x10:0xc042be58 frame pointer = 0x10:0xc042be5c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 db> -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ddb panics ( getdiskbyname() issue)
In message <67E0BE167008D31185F60008C7289DA0E1313F@MCHH218E>, Reifenberger Mich
ael EXT writes:
>Hi,
>while searching the cause why "set vfs.root.mountfrom=cd9660:acd0c"
>fails I found that when I do a "show disk/ad0" (when /dev/ad0* exists)
>causes a panic: ( repeated make_dev("ad0")...)
>while "show disk/acd0" doesn't.
>
>So we have two unrelated problems here:
>1.) getdiskbyname() panics the system if the device exists.
>2.) getdiskbyname() doesn't work for acd0c.
>
>Any clues how to fix?
No trivial fixes. New code ("GEOM") will replace this entire mess
soon.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: calcru: negative time of XXX
please send me /var/run/dmesg.boot from a "boot -v" on a current kernel and output from "sysctl kern.timecounter" please ? In message <[EMAIL PROTECTED]>, Frode Nordahl writ es: >Hey, > >I've had the microuptime problem some time, and I have somewhat followed >the discussion about this on -current. > >It seems like the patch committed removed the messages, but they are now >replaced by messages like: >Feb 24 17:28:26 gandalf kernel: calcru: negative time of -680109 usec >for pid 92704 (sed) >Feb 25 10:25:05 gandalf kernel: calcru: negative time of -487 usec for >pid 59222 (rm) >Feb 25 19:42:23 gandalf kernel: calcru: negative time of -680904 usec >for pid 48076 (sed) >Feb 26 00:26:45 gandalf kernel: calcru: negative time of -666072 usec >for pid 438 (gmake) > > >Also, I have seen strange things reported by PS. Crond had negative CPU >usage time. > >I am also unable to compile libgtop at the moment, (which makes it >impossible to compile the GNOME port w/o changes). > >proctime.c: In function `calcru': >proctime.c:88: aggregate value used where an integer was expected >proctime.c:69: warning: unused variable `tv' >proctime.c: In function `glibtop_get_proc_time_p': >proctime.c:130: warning: unused variable `pstats' >proctime.c:128: warning: unused variable `u_addr' >proctime.c: At top level: >proctime.c:62: warning: `calcru' defined but not used >gmake[3]: *** [proctime.lo] Error 1 > ># uname -a >FreeBSD gandalf.xu.nordahl.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun >Feb 24 15:58:24 CET 2002 >[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > >Last make world: Feb 24 20:00 > >Cheers! > >Regds, >Frode Nordahl > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI timecounter help needed!
In message <[EMAIL PROTECTED]>, Yann Berthier writes: > > FYI, the increase from 15 to 31 in acpi_timer.c was needed for me to > have my kernel boot with acpi loaded (ie no hang during boot). Thanks, this was the kind of info I needed! > Anyway, my system died after 2 hours or so of use, after a bunch of: > > Feb 25 18:05:34 ogoun kernel: ACPI-0954: *** Error: AcpiEvGpeDispatch: Unable to >queue handler for GPE[0], disabling event The ACPI code was updated a few days ago, these problems are probably caused by that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Future of HARP ATM stack in freebsd...
--- Begin Message --- The two hardware drivers for the HARP ATM stack has been broken in -current for a LNG time now. If nobody are have sufficient interest in the HARP ATM stack to actually fix these two drivers, we should retire the entire thing from -current. So consider this a "last call", if the drivers are not fixed by may 1st the HARP ATM stack will be put in the attic. If anybody is interested in actively maintaining this code, I may be able to find a donor for some ATM cards. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. --- End Message ---
ACPI timecounter help needed!
Machines with ACPI timecounters will now print 10 lines at boot when the timer is tested. If you are lucky you will see ten times something like: ACPI timer looks GOOD min = 3, max = 3, width = 1 That means that you have well implemented ACPI timer. If you are unlucky, one, several or all 10 lines will be marked as "BAD". Please send me an email with these 10 lines and the output of "pciconf -l -v" for your machine. I'm am interested in reports both from good and bad machines. If your machine starts to mysteriously hang after this commit, try to increase the 15 to 31 in this line: } while (u1 > u2 || u2 > u3 || (u3 - u1) > 15); Hopefully this commit fixes the "timecounter backwards" problem with broken ACPI timers, if not, let me know. Enjoy, Poul-Henning In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes: >phk 2002/02/25 01:51:18 PST > > Modified files: >sys/dev/acpica acpi_timer.c > Log: > Add a new test_counter() function which tries to determine the width of > the inter-value histogram for 2000 samples. If the width is 3 or less > for 10 consequtive samples, we trust the counter to be good, otherwise > we use the *_safe() method. > > This method may be too strict, but the worst which can happen is that > we take the performance hit of the *_safe() method when we should not. > > Make the *_safe() method more discriminating by mandating that the three > samples do not span more than 15 ticks on the counter. > > Disable the PCI-ident based probing as a means to recognize good > counters. > > Inspiration from: dillon and msmith > > Revision ChangesPath > 1.14 +46 -17src/sys/dev/acpica/acpi_timer.c > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Discussion of guidelines for additional version control mechanisms
In message <[EMAIL PROTECTED]>, Robe rt Watson writes: >Question 1: How should the presence of on-going work in an external >repository be announced to the broader community? On the project.freebsd.org web-page and the regular status emails generated from the contents of that web-page. >Question 2: How should the status of on-going work be announced to the >broader community? > >Suggestion: Bi-monthly developer status report >Suggestion: Status web page for the project >Suggestion: Regular status reports on work to relevant mailing lists All of the above with a s/Regular/As warranted/ on the third line. >Question 3: How should the results of the on-going work be made available >to the broader community? > >Suggestion: cvsup10 export of the Perforce tree >Suggestion: patchsets sent to appropriate mailing lists with status >Suggestion: patchsets generated automatically and posted to the mailing >list Whichever fits the particular project but it would be wonderful if a patch file for all projects could be accessed via the web-page. >Question 4: How agressively should on-going work be pushed back into the >base tree? > >Suggestion: For work requiring large source tree sweeps, API changes, etc, >only when the work is ready to commit. Panic: recursion: "commit only when ready to commit" Doesn't this one hinge on the stability/compilability goal of current and only that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with buildworld: what is "major" really supposed to be?
Ok, found it:
This is the culprit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/file.h.diff?r1=1.39&r2=1.40
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>
>Yeah, I'm chasing that one right now.
>
>I'm not yet quite sure which commit has broken this, nor what the right
>fix is...
>
>Poul-Henning
>
>In message <[EMAIL PROTECTED]>, David Wolfskill w
>rites:
>>Trying to "make buildworld" for today's -CURRENT, I get:
>>
>>>>> stage 4: building libraries
>>--
>>...
>>===> doc
>>cc -fpic -DPIC -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
>/usr/src/lib/libkvm/kvm_file.c -o kvm_file.So
>>In file included from /usr/obj/usr/src/i386/usr/include/sys/file.h:40,
>> from /usr/src/lib/libkvm/kvm_file.c:54:
>>/usr/obj/usr/src/i386/usr/include/sys/systm.h:305: syntax error before `int'
>>/usr/obj/usr/src/i386/usr/include/sys/systm.h:306: syntax error before `int'
>>/usr/obj/usr/src/i386/usr/include/sys/systm.h:307: syntax error before `('
>>*** Error code 1
>>
>>
>>After enough tinkering with copies of the files to demonstrate to
>>my satisfaction that my C skills are pretty rusty, I noticed that:
>>
>>* The lines in systm.h look like (starting at line 301):
>>
>>/*
>> * Common `dev_t' stuff are declared here to avoid #include poisoning
>> */
>>
>>int major(dev_t x);
>>int minor(dev_t x);
>>dev_t makedev(int x, int y);
>>udev_t dev2udev(dev_t x);
>>dev_t udev2dev(udev_t x, int b);
>>int uminor(udev_t dev);
>>int umajor(udev_t dev);
>>udev_t makeudev(int x, int y);
>>
>>
>> so it looks as if we're declaring "major" as a function returning int.
>>
>>* But sys/sys/file.h, starting at line 49 reads:
>>
>>#ifdef _KERNEL
>>#include
>>#include
>>#include
>>#include
>>
>> which is OK, except that sys/sys/types.h, starting at line 113 reads:
>>
>>/*
>> * minor() gives a cookie instead of an index since we don't want to
>> * change the meanings of bits 0-15 or waste time and space shifting
>> * bits 16-31 for devices that don't use them.
>> */
>>#define major(x)((int)(((u_int)(x) >> 8)&0xff)) /* major number */
>>#define minor(x)((int)((x)&0x00ff)) /* minor number */
>>#define makedev(x,y)((dev_t)(((x) << 8) | (y))) /* create dev_t */
>>
>>
>> and this appears to be a bit of a problem, because by the time the C
>> compiler gets to the "int major(dev_t x);" line in sys/sys/systm.h,
>> "major" has been replaced, so the line looks like:
>>
>>int ((int)(((u_int)( dev_t x ) >> 8)&0xff)) ;
>>
>> which is pretty non-ideal, any way you look at it.
>>
>>
>>In case it's of interest/value, recent CVSup history is:
>>freebeast(5.0-C)[44] tail /var/log/cvsup-history.log
>>CVSup begin from cvsup14.freebsd.org at Tue Feb 19 03:47:02 PST 2002
>>CVSup ended from cvsup14.freebsd.org at Tue Feb 19 03:53:36 PST 2002
>>CVSup begin from cvsup14.freebsd.org at Wed Feb 20 03:47:02 PST 2002
>>CVSup ended from cvsup14.freebsd.org at Wed Feb 20 04:00:08 PST 2002
>>CVSup begin from cvsup14.freebsd.org at Thu Feb 21 03:47:03 PST 2002
>>CVSup ended from cvsup14.freebsd.org at Thu Feb 21 03:53:29 PST 2002
>>CVSup begin from cvsup14.freebsd.org at Fri Feb 22 03:47:02 PST 2002
>>CVSup ended from cvsup14.freebsd.org at Fri Feb 22 03:54:26 PST 2002
>>CVSup begin from cvsup14.freebsd.org at Sat Feb 23 04:35:13 PST 2002
>>CVSup ended from cvsup14.freebsd.org at Sat Feb 23 04:42:37 PST 2002
>>freebeast(5.0-C)[45]
>>
>>
>>So: how should this be resolved? Or am I just confused (again)?
>>
>>
>>Thanks,
>>david
>>--
>>David H. Wolfskill[EMAIL PROTECTED]
>>I believe it would be irresponsible (and thus, unethical) for me to advise,
>>recommend, or support the use of any product that is or depends on any
>>Microsoft product for any purpose other than personal amusement.
>>
>>To Unsubscribe: send mail to [EMAIL PROTECTED]
>>with "unsubscribe freebsd-current" in the body of the message
>>
>
>--
>Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>[EMAIL PROTECTED] | TCP/IP since RFC 956
>FreeBSD committer | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Problem with buildworld: what is "major" really supposed to be?
Yeah, I'm chasing that one right now.
I'm not yet quite sure which commit has broken this, nor what the right
fix is...
Poul-Henning
In message <[EMAIL PROTECTED]>, David Wolfskill w
rites:
>Trying to "make buildworld" for today's -CURRENT, I get:
>
>>>> stage 4: building libraries
>--
>...
>===> doc
>cc -fpic -DPIC -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
>/usr/src/lib/libkvm/kvm_file.c -o kvm_file.So
>In file included from /usr/obj/usr/src/i386/usr/include/sys/file.h:40,
> from /usr/src/lib/libkvm/kvm_file.c:54:
>/usr/obj/usr/src/i386/usr/include/sys/systm.h:305: syntax error before `int'
>/usr/obj/usr/src/i386/usr/include/sys/systm.h:306: syntax error before `int'
>/usr/obj/usr/src/i386/usr/include/sys/systm.h:307: syntax error before `('
>*** Error code 1
>
>
>After enough tinkering with copies of the files to demonstrate to
>my satisfaction that my C skills are pretty rusty, I noticed that:
>
>* The lines in systm.h look like (starting at line 301):
>
>/*
> * Common `dev_t' stuff are declared here to avoid #include poisoning
> */
>
>int major(dev_t x);
>int minor(dev_t x);
>dev_t makedev(int x, int y);
>udev_t dev2udev(dev_t x);
>dev_t udev2dev(udev_t x, int b);
>int uminor(udev_t dev);
>int umajor(udev_t dev);
>udev_t makeudev(int x, int y);
>
>
> so it looks as if we're declaring "major" as a function returning int.
>
>* But sys/sys/file.h, starting at line 49 reads:
>
>#ifdef _KERNEL
>#include
>#include
>#include
>#include
>
> which is OK, except that sys/sys/types.h, starting at line 113 reads:
>
>/*
> * minor() gives a cookie instead of an index since we don't want to
> * change the meanings of bits 0-15 or waste time and space shifting
> * bits 16-31 for devices that don't use them.
> */
>#define major(x)((int)(((u_int)(x) >> 8)&0xff)) /* major number */
>#define minor(x)((int)((x)&0x00ff)) /* minor number */
>#define makedev(x,y)((dev_t)(((x) << 8) | (y))) /* create dev_t */
>
>
> and this appears to be a bit of a problem, because by the time the C
> compiler gets to the "int major(dev_t x);" line in sys/sys/systm.h,
> "major" has been replaced, so the line looks like:
>
>int ((int)(((u_int)( dev_t x ) >> 8)&0xff)) ;
>
> which is pretty non-ideal, any way you look at it.
>
>
>In case it's of interest/value, recent CVSup history is:
>freebeast(5.0-C)[44] tail /var/log/cvsup-history.log
>CVSup begin from cvsup14.freebsd.org at Tue Feb 19 03:47:02 PST 2002
>CVSup ended from cvsup14.freebsd.org at Tue Feb 19 03:53:36 PST 2002
>CVSup begin from cvsup14.freebsd.org at Wed Feb 20 03:47:02 PST 2002
>CVSup ended from cvsup14.freebsd.org at Wed Feb 20 04:00:08 PST 2002
>CVSup begin from cvsup14.freebsd.org at Thu Feb 21 03:47:03 PST 2002
>CVSup ended from cvsup14.freebsd.org at Thu Feb 21 03:53:29 PST 2002
>CVSup begin from cvsup14.freebsd.org at Fri Feb 22 03:47:02 PST 2002
>CVSup ended from cvsup14.freebsd.org at Fri Feb 22 03:54:26 PST 2002
>CVSup begin from cvsup14.freebsd.org at Sat Feb 23 04:35:13 PST 2002
>CVSup ended from cvsup14.freebsd.org at Sat Feb 23 04:42:37 PST 2002
>freebeast(5.0-C)[45]
>
>
>So: how should this be resolved? Or am I just confused (again)?
>
>
>Thanks,
>david
>--
>David H. Wolfskill [EMAIL PROTECTED]
>I believe it would be irresponsible (and thus, unethical) for me to advise,
>recommend, or support the use of any product that is or depends on any
>Microsoft product for any purpose other than personal amusement.
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI timer is screwed... (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: > >:I would like to see "the PIIX problem" caught on camera, personally. >:We're aware of one errata for it already, and we work around it. If >:there's another problem, or ideally if someone has some relatively quick >:code to test it, that would be much better. > >Holy shit. We are screwed. It's a free-running counter with NO >synchronization whatsoever. None. Zip. Zero. Yes, there is an errata for just that on early chipsets. Does the ..._slow patch I sent work for you ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
Matt, Easy now, there is more depth to it than that... I have promised myself to get the timecounter paper written and I'll probably present it at BSDcon-euro-2002 in Amsterdam if they want to listen to me. For now, lets concentrate on the PIIX hardware because that's where the problem seems to be... Poul-Henning In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >Ok, I've looked at the code more carefully and I understand how this >works now. However, it is not enough in an SMP environment. You >need a generation count in the timecounter structure and you also need >a synchronization point when you switch time counters or a process >running on a different cpu may wind up using a time counter that is being >actively updated. > >I'm experimenting with your patch now. I'll send email when I have >some test results. > > -Matt > >: >:I just wrote the following fix for some of the overflow problems. >: >:%%% >:Index: kern_tc.c >:=== >:RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v >:retrieving revision 1.113 >:diff -c -2 -r1.113 kern_tc.c >:... > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message <[EMAIL PROTECTED]>, Matthew Dillon wri
tes:
>Whoop! I take it back. I'm still getting the errors:
>
>microuptime() went backwards (458.168990 -> 458.168882)
>microuptime() went backwards (578.609995 -> 577.929801)
>microuptime() went backwards (748.912755 -> 748.237402)
>microuptime() went backwards (775.159625 -> 775.159612)
>
>I also think this retry loop has to be done everywhere where the
>timecounter structure is accessed directly.
No, only where the timecounter hardware is read and the math
done. As far as I know, this is the only place.
As I said, I am far from convinced this is the solution to the problem
we are looking at with the PIIX timecounter.
Msmith has some magic code in sys/dev/acpi/acpi_timer.c which tries
to identify if the PIIX counter is broken or OK and I notice that
the mask seems to always be set to 24 bits even if the hardware
is 32 bits.
I am not sure I read his code right, but he seems to default to the
unsafe method, can you try this copy&pasted patch ?
Index: acpi_timer.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v
retrieving revision 1.11
diff -u -r1.11 acpi_timer.c
--- acpi_timer.c8 Jan 2002 06:45:56 - 1.11
+++ acpi_timer.c17 Feb 2002 20:48:23 -
@@ -138,7 +138,7 @@
if (getenv("debug.acpi.timer_test") != NULL)
acpi_timer_test();
-acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount;
+acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount_safe;
acpi_timer_timecounter.tc_frequency = acpi_timer_frequency;
tc_init(&acpi_timer_timecounter);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message <[EMAIL PROTECTED]>, Matthew Dillon wri
tes:
>However, I think to be complete we need to make it even less elegant.
>The TC module is only flip-flopping between two time counters, which
>means that it can flip-flop twice and the test will not work. We need
>a generation count on the timecounter as well:
>
>do {
>tc = timecounter;
>gen = tc->tc_generation;
>*bt = tc->tc_offset;
>bintime_addx(bt, tc->tc_scale * tco_delta(tc));
>} while (tc != timecounter || tc->tc_generation != gen);
No, more like:
do {
tc = timecounter;
gen = tc->gen;
...
} while (gen != tc->gen);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
In message <[EMAIL PROTECTED]>, Matthew Dillon wri tes: >:I just wrote the following fix for some of the overflow problems. > >I don't understand how this code is supposed to handle overflows. >You seem only to be checking to see if the master timecounter has >changed to a different type. Bruce's patch amounts to a retry if the current timecounter was updated while we were calculating time. It is a bit more defensive than it needs to be and generally pessimizes the timecounters elegant lockless design a fair bit, but it is still much better than slamming a mutex around the entire clock code. If this patch cures the PIIX problem, something I'm not at all convinced about, it should go in, if not only the comment should go in. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible?
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >> This occurs both with and without the gettimeofday Giant-removal patch, so >> I am fairly sure it has nothing to do with any of my current work. This is >> running -current on a DELL2550 (2xCPUs), compiled with the SMP option. The Gian removal doesn't come anywhere near this. >The fact that the timecounter usually goes backwards by about 0.68 seconds >is probably significant, but I can't quite explain it. >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Well: 2^32 / 3579545 = 1199.86 seconds. 2^24 / 3579545 =4.68 seconds. So even assuming that ACPI reported a wrong width, four seconds should still be enough to prevent a wraparound even though we cycle through the timecounter ring in one second. >I just wrote the following fix for some of the overflow problems. It is true that if a process is not running for arbitrary long time the timecounter may be modified underneat it, and bruce's patch is actually a pretty elegant solution for that case. By all means try it. I have had one other report of a similar problem, with the added information that changing to the TSC or i8254 instead of PIXX made it go away so I am not entirely convinced this is really what we are looking for in this case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: time breakage.
In message <[EMAIL PROTECTED]>, Ju lian Elischer writes: >phk, is this you? >/usr/include/sys/time.h:137: integer constant out of range >/usr/include/sys/time.h:137: warning: decimal integer constant is so large >that it is unsigned Yes, that was me, seems like I did my "buildworld" test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: bdwrite: buffer is not busy
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Sat, 9 Feb 2002, Julian Elischer wrote: > >> On Sun, 10 Feb 2002, Bruce Evans wrote: >> >> > >> > This is a well known bug in the device layer. I reported it on 2001/12/26 >> > and fixed it locally a little later. See the thread in -current about >> > "panic during fdisk'ing a md(4) device" for patches. >> > >> Can you commit the fix? > >The maintainer should be able to it better. I rarely test the devfs parts, >but the bulk of the patch is to help devfs. My patch needs some cleanups >(mainly non-hacked interfaces) anyway. The maintainer is busy rewriting that entire area of the code which will help immensely :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: time breakage.
In message <[EMAIL PROTECTED]>, Ju lian Elischer writes: >phk, is this you? >/usr/include/sys/time.h:137: integer constant out of range >/usr/include/sys/time.h:137: warning: decimal integer constant is so large >that it is unsigned Yes, that was me, seems like I did my "buildworld" test in the wrong source tree here. Thanks to peter for fixing this, and sorry for the trouble! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: making a large RAMdisk?
In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes: >Is there a way, under -current or -stable, to make a true RAMdisk that is >around 2GB in size? Possibly. If you take the detour around a preloaded image for the md(4) driver it should be possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic during fdisk'ing a md(4) device
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >This seems to be just another null pointer panic caused by the dk macros >creating half-baked devices with null devswitches. I sent the following >quick fixes for this to the devfs maintainer a couple of weeks ago. They >also fix the non-creation of all minor devices on the disk when the first >one is opened. Yeah, I admit I've been sitting on these patches for a bit too long, I'll try to get through my pile and get to them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker Task: ccdinit stack usage.
In message <[EMAIL PROTECTED]>, Maxim Konovalov wr ites: Ohh and I forgot: Thanks for the patch! Tested & Committed :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker Task: ccdinit stack usage.
In message <[EMAIL PROTECTED]>, Maxim Konovalov wr ites: >> > tmppath is a rather big one but I can't find the second item. What >> > about this patch: >> >> I think the others are the partinfo and ccdgeom structures. > >struct partinfo holds only two pointers, ccg is a pointer too. I meant partinfo, but I hadn't looked at it in enough detail to notice how small it actually was. My fault. >> As an aside, what's the undocumented M_DEVBUF flag for? It's a catch-all malloc bucket for things in drivers which are not worth allocating their own bucket for. M_TEMP is a similar catch-all bucket for which I belive the rule-of-thumb is that nothing should remain allocated by the time we return to userland. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Junior Kernel Hacker Task: ccdinit stack usage.
sys/dev/ccd/ccd.c:ccdinit() has a couple of very large items on the stack. Rewrite ccdinit() to allocate them with MALLOC(9) instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: reboot -p
In message <[EMAIL PROTECTED]>, Thomas Quinot wri tes: >Currently, when reboot is invoked with the '-p' command line flag >(powerdown), it performs a shutdown with RB_HALT|RB_POWEROFF. >In some situations, it can be useful to try to perform a poweroff, >but reboot if it fails (e.g. when you are shutting down the system >as a result of a power failure, you want the system to reboot, >*not* stay down, if power was restored after the start of the shutdown >procedure). It would be nice if reboot was changed to pass only >RB_POWEROFF (without RB_HALT) when invoked with '-p'. Of course halt(8) >whould be unaffected and still pass RB_HALT|RB_POWEROFF when invoked >as halt -p. > >What do others think of this change: Sounds reasonable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can we use this ? Linux Interrupt Latency benchmark
In message <[EMAIL PROTECTED]>, Martin Blapp writes: > >Hi all, > >ftp://ftp.suse.com/pub/people/andrea/lil > >Maybe we can port this and use it to see where the >latency actually happens ? Doing something like that wouldn't be a bad idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel hacker task: Floppy driver mode handling.
In message <[EMAIL PROTECTED]>, Martin Heller writes: >Hello! >After a quick glance thru the TUHS.org archives, I found a quick & dirty >hack for 4.0-Stable by Jason T. Miller <[EMAIL PROTECTED]> >The README for this thing is as follows: That is where I got the inspiration to clean up our floppy driver. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
