acquiring duplicate lock of same type
I have seen these messages on my slow 266MHz dual Pentium II machine with a kernel build with source from after Matt and Jake's commits. Is there anyone interrested in it? It happened while doing a cvs -q update -PAd. acquiring duplicate lock of same type: "PCPU KNOTE" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU PIPE" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU NAMEI" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU Files" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 65536" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 32768" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 16384" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 8192" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 4096" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 2048" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 1024" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 512" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 256" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 128" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 64" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 32" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU 16" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 acquiring duplicate lock of same type: "PCPU MAP ENTRY" 1st @ ../../../vm/uma_core.c:455 2nd @ ../../../vm/uma_core.c:455 John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] 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: Alpha Build
On Wed, Mar 27, 2002 at 03:15:14AM +0200, Giorgos Keramidas wrote: > On 2002-03-26 12:00, Terry Lambert wrote: > > Wilko Bulte wrote: > > > On Tue, Mar 26, 2002 at 07:56:39AM -0500, Michael Lucas wrote: > > > > Each day, I try to build -current. (Hey, it's good for a laugh. :-) > > > > > > You will gain saint-like patience as a bonus.. > > > > > > ;) > > > > Remind me again of the value of saint-like patience, in the larger > > scheme of things... > > It's the extra warmth and fuzziness one feels, as the horns on top of one's > head start turning into a brilliant, blazing circle of light... at least > this is what happens for i386 users. The Alpha users are less easy to turn > into saints. They tend to twist and shout "that's not a 64-bit wing, get > it away from me" when one tries to remove their devil horns and tail :))) Right. And that is not evening mentioning those who want MI fine-grained wings :-P Hmm, come to think of it, saint-like is Not Done(TM) in their neighbourhood. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands We are FreeBSD. Resistance is futile. Prepare to be committed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fixit.flp full again
> > A make release breaks because the fixit floppy is too big again. So what > > can we do to get it smaller? Anybody got any ideas or shall we just choose > > a random utility and delete it? > > I think that we really should move to using new loader(8) feature for > loading kernels/modules split across several physical medias. See cvs > logs for src/lib/libstand/splitfs.c for details. Uhm, but splitting kernels and modules won't help the fixit floppy? Or am I missing something? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fixit.flp full again
On Wed, 2002-03-27 at 07:44, John Hay wrote: > A make release breaks because the fixit floppy is too big again. So what > can we do to get it smaller? Anybody got any ideas or shall we just choose > a random utility and delete it? I think that we really should move to using new loader(8) feature for loading kernels/modules split across several physical medias. See cvs logs for src/lib/libstand/splitfs.c for details. -Maxim signature.asc Description: This is a digitally signed message part
fixit.flp full again
A make release breaks because the fixit floppy is too big again. So what can we do to get it smaller? Anybody got any ideas or shall we just choose a random utility and delete it? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare2 was broken in recent -current (seems OK now)
On Tue, Mar 26, 2002 at 07:38:38PM -0500, Garance A Drosihn wrote: > At 6:36 AM +0100 3/26/02, Mark Santcroos wrote: > >Currently rebuilding with latest sources, will look into > >it after that. > > Whatever the problem had been, it looks like it was fixed > between March 23 and today (the 26th). I did a buildworld > as of 4pm or so, and vmware2 is up and running OK on the > most recent snapshot of current. > > Thanks for offering to look into it. Hopefully there'll be > nothing that you have to do... :-) Very strange... I tracked it down to the following commits by alfred: (to make select/poll mpsafe, 2002/03/13) Revision ChangesPath 1.28 +1 -3 src/sys/dev/kbd/kbd.c 1.82 +1 -1 src/sys/dev/sound/pcm/channel.c 1.45 +0 -2 src/sys/isa/psm.c 1.93 +112 -114 src/sys/kern/sys_generic.c 1.167 +2 -2 src/sys/kern/tty.c 1.207 +3 -0 src/sys/sys/proc.h 1.13 +8 -3 src/sys/sys/selinfo.h 1.163 +2 -0 src/sys/sys/systm.h 1.87 +0 -2 src/sys/net/bpf.c I tracked this down starting with a source tree of this morning (Tuesday). The weird thing is that I don't see the (obvious) fix committed today. (None of those files is touched) Alfred, can you shine a light on this maybe? Anyway, I can acknowledge that it works again. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Alpha cross build b0rked by Perl.
===> gnu/usr.bin/perl/perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Args must match #! line at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 1. *** Error code 2 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
At Tue, 26 Mar 2002 07:40:10 -0700, Kyle Butt wrote: > > At Tue, 26 Mar 2002 09:59:29 +0100, > Poul-Henning Kamp wrote: > > > > > > This is an interesting machine: A K6 wiht ACPI, havn't seen that > > before. > > > > Could you please try to boot -v and give me the ACPI timecounter > > probe lines ? (about ten lines which talk about it being GOOD or > > BAD). > > > > 1 kernel compile later, I get different output as far as the apci timers are concerned, notably that one of the timers is marked good this time. Here are the added options: options HZ=333 options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable mutex checks to detects deadlocks and cycles And this is the updated dmesg from boot -v acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 2, max = 16777203, width = 16777202 ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 0, max = 16777176, width = 16777177 ACPI timer looks BAD min = 1, max = 5, width = 5 ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 0, max = 16777213, width = 16777214 ACPI timer looks BAD min = 0, max = 16777215, width = 16777216 ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks GOOD min = 2, max = 3, width = 2 ACPI timer looks BAD min = 0, max = 16777215, width = 16777216 Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 acpi_cpu0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha Build
On 2002-03-26 12:00, Terry Lambert wrote: > Wilko Bulte wrote: > > On Tue, Mar 26, 2002 at 07:56:39AM -0500, Michael Lucas wrote: > > > Each day, I try to build -current. (Hey, it's good for a laugh. :-) > > > > You will gain saint-like patience as a bonus.. > > > > ;) > > Remind me again of the value of saint-like patience, in the larger > scheme of things... It's the extra warmth and fuzziness one feels, as the horns on top of one's head start turning into a brilliant, blazing circle of light... at least this is what happens for i386 users. The Alpha users are less easy to turn into saints. They tend to twist and shout "that's not a 64-bit wing, get it away from me" when one tries to remove their devil horns and tail :))) Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversals in sys_pipe.c
On Tue, Mar 26, 2002 at 02:43:07PM -0800, Alfred Perlstein wrote: > * Kris Kennaway <[EMAIL PROTECTED]> [020324 14:26] wrote: > > The bento cluster is now running with WITNESS enabled to try and track > > down some odd UMA lock corruption panics. Instead, it found the > > following lock order reversal in sys_pipe.c overnight: > > > > Mar 24 07:31:44 gohan17 kernel: lock order reversal > > Mar 24 07:31:44 gohan17 kernel: 1st 0xcf51aa80 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > > Mar 24 07:31:44 gohan17 kernel: 2nd 0xcf88dadc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > Mar 24 07:32:12 gohan10 kernel: lock order reversal > > Mar 24 07:32:12 gohan10 kernel: 1st 0xd9a29dc0 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > > Mar 24 07:32:12 gohan10 kernel: 2nd 0xd961addc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > Mar 24 07:32:57 gohan12 kernel: lock order reversal > > Mar 24 07:32:57 gohan12 kernel: 1st 0xd9423080 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > > Mar 24 07:32:57 gohan12 kernel: 2nd 0xdaa704dc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > Mar 24 09:02:29 gohan13 kernel: lock order reversal > > Mar 24 09:02:29 gohan13 kernel: 1st 0xd99d6500 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > > Mar 24 09:02:29 gohan13 kernel: 2nd 0xd971cddc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > > > Those source references are from a -current kernel from last night. > > Are you %100 on that? How did you get this to happen? Yes. I wasn't doing anything special, unless you count building 5-10 packages simultaneously for a period of 24 hours counts as special ;-) I had to increase the witness limits in order to stop getting the following: witness_get: witness exhausted Well, I eventually got it anyway on all of the machines, but it didn't happen instantly like it did with the default values ;-) I haven't seen any more witness warnings, but it's probably only because it ran out of resources. I expect I'll see it again when I reboot the cluster. Kris msg36603/pgp0.pgp Description: PGP signature
Re: VMWare2 was broken in recent -current (seems OK now)
At 6:36 AM +0100 3/26/02, Mark Santcroos wrote: >Currently rebuilding with latest sources, will look into >it after that. Whatever the problem had been, it looks like it was fixed between March 23 and today (the 26th). I did a buildworld as of 4pm or so, and vmware2 is up and running OK on the most recent snapshot of current. Thanks for offering to look into it. Hopefully there'll be nothing that you have to do... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
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... FreeBSD 5.0-CURRENT #162: Sat Mar 23 19:49:09 CET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/DES Preloaded elf kernel "/boot/kernel/kernel" at 0xc041c000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 350796334 Hz CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 671072256 (655344K bytes) avail memory = 647180288 (632012K bytes) K6-family MTRR support enabled (2 registers) Using $PIR table, 8 entries at 0xc00f0d00 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_cpu0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 IOW identical CPU, nearly identical board. I worked around it by disabling the ACPI timer by adding this to /boot/loader.conf: debug.acpi.disable="timer" DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld error in pam-ssh
Hello: I'm using 4 stable and i'want to upgrade to current. When I do make buildworld, I get the next error: ... ... libpam/modules/pam-ssh make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libssh.a Stop Error code 2 1 error Erro code 2 1 error What can I do to fix it. Thanks in advance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI documentation?
I've scanned the email list archive but I can't see any overview or example/suggested ACPI interactions. Is there a brief document somewhere which summarizes how to interact with an ACPI enabled kernel? Which clarifies what to do with stub apm_ references in configs? (upgrading from 4.5. So far, 5.0-CURRENT runs like a dream on a Dell L400) cheers -George To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For review: Revised sendmail startup settings
Gregory Neil Shapiro wrote: > > keramida> I am not sure if duplicating the code of etc/rc in > keramida> etc/mail/Makefile is something I am really happy about though. > keramida> This means that anyone who wants to make changes to etc/rc should > keramida> remember to update etc/mail/Makefile too. > > Yes, I really hope the /etc/rc.d work in -CURRENT picks up again so > /etc/mail/Makefile can just call that. Alternatively, I could just > go ahead and create /etc/rc.sendmail but I might get some flack for doing > that. > If it would let you delay sendmail startup until the milter daemons kick in, I'd vote for it. AFAICT you're on you own if you need to do this at present. >From our unsubtle hint department: Now it's in the base system I'm seriously considering hacking /etc/rc to accept sendmail_enable="DELAY" BTW I just upgraded (was using 12.2 port). I included the milter patch and SASL. No problems so far. Three cheers for GNS... -- ian j hart To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For review: Revised sendmail startup settings
On 2002-03-26 15:02, Gregory Neil Shapiro wrote:
> keramida> Aye. Until there is a more NetBSD'ish way of calling sendmail in
> keramida> /etc, we can probably get away with a note in /etc/rc that says
> keramida> "If you make changes related to Sendmail in this file, please
> keramida> update *that* file too." Can we put something like this in
> keramida> /etc/rc?
>
> Sure, I'll add it when I commit the revised /etc/rc.
It's a compromise, since the best thing would be to be able to call /etc/rc
from the Makefile, but thank you for doing a great job maintaining Sendmail
on FreeBSD :)
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: For review: Revised sendmail startup settings
keramida> Aye. Until there is a more NetBSD'ish way of calling sendmail in keramida> /etc, we can probably get away with a note in /etc/rc that says keramida> "If you make changes related to Sendmail in this file, please keramida> update *that* file too." Can we put something like this in keramida> /etc/rc? Sure, I'll add it when I commit the revised /etc/rc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversals in sys_pipe.c
* Alfred Perlstein <[EMAIL PROTECTED]> [020326 14:43] wrote: > * Kris Kennaway <[EMAIL PROTECTED]> [020324 14:26] wrote: > > The bento cluster is now running with WITNESS enabled to try and track > > down some odd UMA lock corruption panics. Instead, it found the > > following lock order reversal in sys_pipe.c overnight: > > > > Mar 24 09:02:29 gohan13 kernel: lock order reversal > > Mar 24 09:02:29 gohan13 kernel: 1st 0xd99d6500 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > > Mar 24 09:02:29 gohan13 kernel: 2nd 0xd971cddc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > > > Those source references are from a -current kernel from last night. > > Are you %100 on that? How did you get this to happen? > > I can see where I hold the pipe lock, then try to get a proc lock, > but not the other way around... > > Any ideas? Note that I can pretty trivially fix this by dropping the pipe lock while calling pgsigio in pipeselwakeup(), however I will then have to make sure the callers of pipeselwakeup() can deal with someone else mucking with the pipe during the call. Anyhow, wtf doesn't witness print out at least one instance of the old locking? Basically let me know where locking is happening in the other direction? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lock order reversals in sys_pipe.c
* Kris Kennaway <[EMAIL PROTECTED]> [020324 14:26] wrote: > The bento cluster is now running with WITNESS enabled to try and track > down some odd UMA lock corruption panics. Instead, it found the > following lock order reversal in sys_pipe.c overnight: > > Mar 24 07:31:44 gohan17 kernel: lock order reversal > Mar 24 07:31:44 gohan17 kernel: 1st 0xcf51aa80 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > Mar 24 07:31:44 gohan17 kernel: 2nd 0xcf88dadc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > Mar 24 07:32:12 gohan10 kernel: lock order reversal > Mar 24 07:32:12 gohan10 kernel: 1st 0xd9a29dc0 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > Mar 24 07:32:12 gohan10 kernel: 2nd 0xd961addc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > Mar 24 07:32:57 gohan12 kernel: lock order reversal > Mar 24 07:32:57 gohan12 kernel: 1st 0xd9423080 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > Mar 24 07:32:57 gohan12 kernel: 2nd 0xdaa704dc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > Mar 24 09:02:29 gohan13 kernel: lock order reversal > Mar 24 09:02:29 gohan13 kernel: 1st 0xd99d6500 pipe mutex @ >/local0/scratch/usr/src/sys/kern/sys_pipe.c:450 > Mar 24 09:02:29 gohan13 kernel: 2nd 0xd971cddc process lock @ >/local0/scratch/usr/src/sys/kern/kern_sig.c:2093 > > Those source references are from a -current kernel from last night. Are you %100 on that? How did you get this to happen? I can see where I hold the pipe lock, then try to get a proc lock, but not the other way around... Any ideas? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For review: Revised sendmail startup settings
On 2002-03-26 12:51, Gregory Neil Shapiro wrote: > keramida> I am not sure if duplicating the code of etc/rc in > keramida> etc/mail/Makefile is something I am really happy about though. > keramida> This means that anyone who wants to make changes to etc/rc should > keramida> remember to update etc/mail/Makefile too. > > Yes, I really hope the /etc/rc.d work in -CURRENT picks up again so > /etc/mail/Makefile can just call that. Alternatively, I could just > go ahead and create /etc/rc.sendmail but I might get some flack for doing > that. Aye. Until there is a more NetBSD'ish way of calling sendmail in /etc, we can probably get away with a note in /etc/rc that says "If you make changes related to Sendmail in this file, please update *that* file too." Can we put something like this in /etc/rc? Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For review: Revised sendmail startup settings
keramida> I am not sure if duplicating the code of etc/rc in keramida> etc/mail/Makefile is something I am really happy about though. keramida> This means that anyone who wants to make changes to etc/rc should keramida> remember to update etc/mail/Makefile too. Yes, I really hope the /etc/rc.d work in -CURRENT picks up again so /etc/mail/Makefile can just call that. Alternatively, I could just go ahead and create /etc/rc.sendmail but I might get some flack for doing that. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For review: Revised sendmail startup settings
On 2002-03-25 23:58, Gregory Neil Shapiro wrote:
>
> FreeBSD 4.5-STABLE: http://people.freebsd.org/~gshapiro/smstart-STABLE
> FreeBSD 5.0-CURRENT: http://people.freebsd.org/~gshapiro/smstart-CURRENT
I don't have STABLE around, so I've only looked at smstart-CURRENT.
It's nice, if you ask me.
--- etc/defaults/rc.conf12 Mar 2002 21:47:31 - 1.140
+++ etc/defaults/rc.conf26 Mar 2002 07:31:02 -
+ # If sendmail_enable=NO, then try:
...
+ # Else if sendmail_submit_enable=NO, then try:
...
+ # Endif
If you ask me, these If/Else/Endif comments are not really necessary.
As long as the relationship and dependencies of the various
sendmail_xxx_enable flags is clearly explained in rc.conf.5, there is no
need to duplicate the documentation in comments within rc.conf, IMHO.
--- etc/defaults/rc.conf12 Mar 2002 21:47:31 - 1.140
+++ etc/defaults/rc.conf26 Mar 2002 07:31:02 -
- # Flags for localhost-only MTA
+ # Flags for sendmail_msp_queue daemon.
Good one!
By all means make this change, regardless of what you do with the rest.
I am not sure if duplicating the code of etc/rc in etc/mail/Makefile is
something I am really happy about though. This means that anyone who wants
to make changes to etc/rc should remember to update etc/mail/Makefile too.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Alpha Build
Wilko Bulte wrote: > On Tue, Mar 26, 2002 at 07:56:39AM -0500, Michael Lucas wrote: > > Each day, I try to build -current. (Hey, it's good for a laugh. :-) > > You will gain saint-like patience as a bonus.. > > ;) Remind me again of the value of saint-like patience, in the larger scheme of things... ;) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
At Tue, 26 Mar 2002 09:59:29 +0100, Poul-Henning Kamp wrote: > > > This is an interesting machine: A K6 wiht ACPI, havn't seen that > before. > > Could you please try to boot -v and give me the ACPI timecounter > probe lines ? (about ten lines which talk about it being GOOD or > BAD). > Here you go: (I thought the processor clock messages might be helpful as well) 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 #4: Tue Mar 26 09:03:23 MST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOMEBAKED Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b2000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04b20b4. Calibrating clock(s) ... TSC clock: 350790875 Hz, i8254 clock: 1193167 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 350796013 Hz CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 2, max = 16777208, width = 16777207 ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 0, max = 16777215, width = 16777216 ACPI timer looks BAD min = 0, max = 16777215, width = 16777216 ACPI timer looks BAD min = 0, max = 16777203, width = 16777204 ACPI timer looks BAD min = 1, max = 16777215, width = 16777215 ACPI timer looks BAD min = 0, max = 5, width = 6 ACPI timer looks BAD min = 2, max = 16777187, width = 16777186 Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 acpi_cpu0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ports broken by OpenPAM
On 25 Mar 2002, Dag-Erling Smorgrav wrote: > Joe Clarke <[EMAIL PROTECTED]> writes: > > Really? I never received it. Please send it again. Thanks. > > Here's an updated (but untested) version. The patch applies cleanly, and pam_ldap builds. Howvever, every service I try to authenticate with it fails with a core dump of some kind. I'm currently analyzing ftpd which dies on a SIGILL. As soon as I have a backtrace, I'll send it out. Joe > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_dc broken in -current
On Monday, 25th March 2002, Robert Watson wrote: >I think I have an identical problem involving a Linksys ethernet card >using if_dc. I have to force it to negotiate 10mbps, since it fails to >negotiate anything higher with my 10/100 switch. No idea why at all. > >dc0: port 0xe800-0xe8ff mem >0xfebfff00-0xfebf irq 10 at device 19.0 on pci0 >dc0: Ethernet address: 00:a0:cc:35:3e:56 >miibus0: on dc0 >dcphy0: on miibus0 >dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >dc0: flags=8843 mtu 1500 >inet6 fe80::2a0:ccff:fe35:3e56%dc0 prefixlen 64 scopeid 0x1 >inet 192.168.11.150 netmask 0xff00 broadcast 192.168.11.255 >ether 00:a0:cc:35:3e:56 >media: Ethernet 10baseT/UTP >status: active > >If I set it to auto-negotiate or hard-set to 100mbps, no packets go back >or forth. I've had this problem for at least a year, if not longer. I >have the same problem with 4.4-STABLE using an identical card on different >hardware: if it tries to negotiate 100mbps, then it simply doesn't work. >If I force it to 10, it's fine. After careful consideration, I think this has to be a different problem. My problem is that auto-negotiation doesn't start at boot (when an address is assigned to dc0). If I explicitly set a speed, that speed works. Most bizarrely, if I misspell the media option, that causes a successful autonegotation! I mean, I type "ifconfig dc0 media 10baset" immediately after boot, and autonegotiation takes over. (If I spell it "10baset/utp" it goes into 10Mbit half-duplex mode, like you expect.) So it's just a hair's breadth away from working properly, and reverting rev 1.56 is enough for full operation to be restored. Since you explicitly set 100Mbit half-duplex and it doesn't work, then that must be something else. We could have a go at finding that bug too, but it will be harder, since I don't have a PNIC II here. I do have some info on the Macronix 98715A, which Bill Paul says is almost the same. Maybe we can get lucky. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_dc broken in -current
On Monday, 25th March 2002, "Ilmar S. Habibulin" wrote: >On Mon, 25 Mar 2002, Stephen McKay wrote: > >> What sort of card do you have? The output of dmesg would help. Have you >> tried 4.5 on this machine? >I have some noname nic with Intel 21143 chip. dmesg attached. I'm using >only trustedbsd_mac branch on my ws. Yours seems to be the same as mine (from a chip and phy point of view) although mine has a DEC assigned ethernet address and yours is from Telebit. I don't think that difference matters. >> Of course the dc driver should autonegotiate (and does so when I revert >> rev 1.56). Your info could help trace this problem. >Well, i don't think this is the problem. Hardware became too much >inteligent now a days, so one have to use his own hands to make this >hardware work like user wants it to work. Maybe just put some FAQ about >dc(4) and autoconfigurable hubs/switches? Some things can be blamed on attempted intelligence gone wrong. But not this one. This is a simple bug. My card works perfectly under 4.5.0 on the same machine. It fails with -current. But with one change reverted, it works again. Now all I have to do is work out what is the real underlying cause, since the current code looks right at first glance. At least I have the old DEC datasheets, and some info on some of the clones. Stephen. 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: Alpha Build
On Tue, Mar 26, 2002 at 07:56:39AM -0500, Michael Lucas wrote: > Either would work. > > I have an Alpha Multia-166 that I use to play with -current on. As it > has a TGA card, it's running via serial console. This machine feels > like the equivalent of, say, a 50MHz 486. > > Each day, I try to build -current. (Hey, it's good for a laugh. :-) You will gain saint-like patience as a bonus.. ;) -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alpha Build
Either would work. I have an Alpha Multia-166 that I use to play with -current on. As it has a TGA card, it's running via serial console. This machine feels like the equivalent of, say, a 50MHz 486. Each day, I try to build -current. (Hey, it's good for a laugh. :-) I'd grab one with a normal graphics card, in your case. On Mon, Mar 25, 2002 at 04:00:29PM -0500, Scott Sipe wrote: > > Hi, I have a chance to pick up an Alpha machine which I would use for FreeBSD > testing. > > There are 4 AlphaStation 600's from which I could pick, 2 of them have 'TGA > graphics cards', 2 have "normal" graphics cards and "can run X." Seeing as > right now I know next to nothing about Alpha's, would it be better to pick > one or the other, or, would one or the other be better for freeBSD testing? > > thanks much, > Scott > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Michael Lucas [EMAIL PROTECTED], [EMAIL PROTECTED] my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BTX halted
On Mon, Mar 25, 2002 at 01:14:57PM -0500, John Baldwin wrote: Hi again, > > I don't have a debug kernel, those are the boot floppies downloaded from > > current.freebsd.org. If it helps, the snapshot floppies from 11th of > > March work, every floppy made after that date fails with the same error. > > I'm going to install that snapshot, upgrade the system and try to > > reproduce the error with a debug kernel. > > Ok. If you can figure out what kernel commit broke things that would be very > helpful. Thanks! As someone else pointed out, it seems to be a problem with corrupted floppy images. I've succesfully built kernels from the 20th and 21st of March (using those ssys tarballs), and they boot fine. There seems to be a problem with the floppy images generated after the 11th of March. I'm not sure what can be causing this, but the kernel problem can be discarded, those kernels boot fine from harddisk. I'm going to build a floppy image when I get some time and report my results here. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg36589/pgp0.pgp Description: PGP signature
Re: Superfast clock on current.
I too have experienced this problem with -current. I'm running on a Thinkpad A21p, but with a fairly out-of-date build (September 1, 2001). This happens, I believe. because the kernel thinks the processor is running at one speed and then that speed changes to reflect different power management settings. For example, if I configure BIOS APM to clockdown the processor on battery and run full-throttle on AC power. My clock runs smoothly on battery (the condition I booted in), but when I engage the AC the clock runs a few times faster than normal. I can control this condition simply adding and removing AC power and having the BIOS APM react. It is clear: the processor speed is not held constant and this produces the behavior you mention. Some data points: Right after boot ntptimeset reports: Your clock is off by -4.4654581 seconds. (131.215.225.254) [48/47] Some minutes later: Your clock is off by -1710.9709441 seconds. (131.215.225.254) [37/36] Anyways, my dmesg is attached. -Jon Copyright (c) 1992-2001 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: Sat Sep 1 01:18:52 PDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PHILEMON Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 846865184 Hz CPU: Pentium III/Pentium III Xeon/Celeron (846.87-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 134152192 (131008K bytes) avail memory = 125894656 (122944K bytes) Preloaded elf kernel "kernel" at 0xc049. Preloaded userconfig_script "/boot/kernel.conf" at 0xc049009c. Pentium Pro MTRR support enabled Using $PIR table, 11 entries at 0xc00fdee0 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 0.0 (no driver attached) pcic0: mem 0x5000-0x5fff irq 11 at device 2.0 on pci0 pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] pccard0: on pcic0 pcic1: mem 0x5010-0x50100fff irq 11 at device 2.1 on pci0 pcic1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] pccard1: on pcic1 fxp0: port 0x1800-0x183f mem 0xf010-0xf011,0xf012-0xf0120fff irq 11 at device 3.0 on pci0 fxp0: Ethernet address 00:10:a4:8e:87:33 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at 3.1 (no driver attached) csa0: mem 0xf000-0xf00f,0xf0122000-0xf0122fff irq 11 at device 5.0 on pci0 csa: card is Thinkpad 600X/A20/T20 pcm0: on csa0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1850-0x185f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x1860-0x187f irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at 7.3 (no driver attached) orm0: at iomem 0xc-0xc,0xd-0xd17ff,0xe-0xe on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 sio1: configured irq 3 not in bitmap of probed irqs 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default IP Filter: v3.4.20 initialized. Default = block all, Logging = enabled ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed ad0: 30520MB [66144/15/63] at ata0-master UDMA33 acd0: DVD-ROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a lock order reversal 1st 0xc8d1621c process lock @ /usr/src/sys/vm/vm_glue.c:469 2nd 0xc0b30ec0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239
Re: Superfast clock on current.
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. (I still have the machine, but it is running 4.5 now). David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Superfast clock on current.
This is an interesting machine: A K6 wiht ACPI, havn't seen that before. Could you please try to boot -v and give me the ACPI timecounter probe lines ? (about ten lines which talk about it being GOOD or BAD). Poul-Henning In message <[EMAIL PROTECTED]>, Kyle Butt writes: >My system clock is running twice as fast as it should be, >but it doesn't affect timing functions. Ex: > >bash-2.04$ date ; sleep 5 ; date >Tue Mar 26 01:48:45 MST 2002 >Tue Mar 26 01:48:55 MST 2002 >bash-2.04$ > >Has anyone else experienced this problem? I'm running X4.2.0 but >not from the ports. (I upgraded and X didn't work with opieaccess, >but this was before the port for 420 was moved over) It's been >going on for approximately a month now. > >Here's my dmesg, and kernel config file, if they help. > >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 #4: Tue Mar 26 09:03:23 MST 2002 >[EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOMEBAKED >Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b2000. >Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04b20a8. >Timecounter "i8254" frequency 1193182 Hz >Timecounter "TSC" frequency 350796711 Hz >CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 > Features=0x8021bf > AMD Features=0x8800 >real memory = 134201344 (131056K bytes) >avail memory = 125476864 (122536K bytes) >K6-family MTRR support enabled (2 registers) >Using $PIR table, 5 entries at 0xc00f0b40 >npx0: on motherboard >npx0: INT 16 interface >acpi0: on motherboard >acpi0: power button is handled as a fixed feature programming model. >Timecounter "ACPI-safe" frequency 3579545 Hz >acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 >acpi_cpu0: on acpi0 >acpi_pcib0: port 0xcf8-0xcff on acpi0 >pci0: on acpi_pcib0 >pcib1: at device 1.0 on pci0 >pci1: on pcib1 >pci1: at device 0.0 (no driver attached) >pci0: at device 3.0 (no driver attached) >isab0: at device 7.0 on pci0 >isa0: on isab0 >pcm0: port 0xb800-0xb83f irq 9 at device 9.0 on pci0 >pci0: at device 10.0 (no driver attached) >rl0: port 0xa800-0xa8ff mem 0xde00-0xdeff irq 10 >at device 11.0 on pci0 >rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode >rl0: Ethernet address: 00:4f:4e:03:38:9c >miibus0: on rl0 >rlphy0: on miibus0 >rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >atapci0: port 0xa400-0xa40f irq 0 at device 15.0 >on pci0 >ata0: at 0x1f0 irq 14 on atapci0 >ata1: at 0x170 irq 15 on atapci0 >fdc0: port 0x3f7,0x3f2-0x3f5 >irq 6 on acpi0 >fdc0: FIFO enabled, 8 bytes threshold >fd0: <1440-KB 3.5" drive> on fdc0 drive 0 >ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 >ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode >ppc0: FIFO with 16/16/7 bytes threshold >plip0: on ppbus0 >lpt0: on ppbus0 >lpt0: Interrupt-driven port >ppi0: on ppbus0 >sio0 port 0x3f8-0x3ff irq 4 on acpi0 >sio0: type 16550A >sio1 port 0x2f8-0x2ff irq 3 on acpi0 >sio1: type 16550A >atkbdc0: port 0x64,0x60 irq 1 on acpi0 >atkbd0: flags 0x1 irq 1 on atkbdc0 >kbd0 at atkbd0 >psm0: irq 12 on atkbdc0 >psm0: model IntelliMouse, device ID 3 >orm0: at iomem 0xc-0xc7fff on isa0 >pmtimer0 on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x300> >vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 >IPv6 packet filtering initialized, default to accept, logging limited to 100 >packets/entry >IP packet filtering initialized, divert enabled, rule-based forwarding enabled, >default to accept, logging limited to 100 packets/entry by default >IPsec: Initialized Security Association Processing. >IP Filter: v3.4.25 initialized. Default = block all, Logging = enabled >ad0: 5495MB [11166/16/63] at ata0-master UDMA33 >ad2: 9765MB [19841/16/63] at ata1-master UDMA33 >ad3: 1916MB [3893/16/63] at ata1-slave WDMA2 >acd0: CDROM at ata0-slave PIO4 >Mounting root from ufs:/dev/ad2s1a >pid 297 (emacs), uid 1000: exited on signal 11 (core dumped) > >kernel config file (mostly just a hackup of GENERIC) > ># ># GENERIC -- Generic kernel configuration file for FreeBSD/i386 ># ># For more information on this file, please read the handbook section on ># Kernel Configuration Files: ># >#http://www.FreeBSD.org/handbook/kernelconfig-config.html ># ># The handbook is also available locally in /usr/share/doc/handbook ># if you've installed the doc distribution, otherwise always see the ># FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the ># latest information. ># ># An exhaustive list of options and more detailed explanations of the ># device lines is also present in the NOTES configuration file. If you are ># in doubt as to the purpose or necessity of a line, check first in NOTES. ># ># $FreeBSD: src/sys/i386/conf/GENERIC,v 1.335 2002/02
Superfast clock on current.
My system clock is running twice as fast as it should be, but it doesn't affect timing functions. Ex: bash-2.04$ date ; sleep 5 ; date Tue Mar 26 01:48:45 MST 2002 Tue Mar 26 01:48:55 MST 2002 bash-2.04$ Has anyone else experienced this problem? I'm running X4.2.0 but not from the ports. (I upgraded and X didn't work with opieaccess, but this was before the port for 420 was moved over) It's been going on for approximately a month now. Here's my dmesg, and kernel config file, if they help. 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 #4: Tue Mar 26 09:03:23 MST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOMEBAKED Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b2000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04b20a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 350796711 Hz CPU: AMD-K6(tm) 3D processor (350.80-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 real memory = 134201344 (131056K bytes) avail memory = 125476864 (122536K bytes) K6-family MTRR support enabled (2 registers) Using $PIR table, 5 entries at 0xc00f0b40 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xec08-0xec0b on acpi0 acpi_cpu0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 3.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pcm0: port 0xb800-0xb83f irq 9 at device 9.0 on pci0 pci0: at device 10.0 (no driver attached) rl0: port 0xa800-0xa8ff mem 0xde00-0xdeff irq 10 at device 11.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:4f:4e:03:38:9c miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci0: port 0xa400-0xa40f irq 0 at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default IPsec: Initialized Security Association Processing. IP Filter: v3.4.25 initialized. Default = block all, Logging = enabled ad0: 5495MB [11166/16/63] at ata0-master UDMA33 ad2: 9765MB [19841/16/63] at ata1-master UDMA33 ad3: 1916MB [3893/16/63] at ata1-slave WDMA2 acd0: CDROM at ata0-slave PIO4 Mounting root from ufs:/dev/ad2s1a pid 297 (emacs), uid 1000: exited on signal 11 (core dumped) kernel config file (mostly just a hackup of GENERIC) # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.335 2002/02/13 18:47:50 alfred Exp $ machine i386 #cpuI486_CPU cpu I586_CPU cpu I686_CPU ident HOMEBAKED maxusers0 options CPU_FASTER_5X86_FPU options CPU_SUSP_HLT options CPU_UPGRADE_HW_CACHE options CPU_WT_ALLOC options GPL_MATH_EMULATE#Support for x87 emulation options NO_F00
Re: is 'device ether' mandatory now?
i'd rather fix the change so that ether is not mandatory. Let me think/experiment a bit about it. cheers luigi On Tue, Mar 26, 2002 at 11:16:49AM +0300, Maxim Konovalov wrote: > > Hello Luigi, > > On 05:20-0800, Mar 24, 2002, Luigi Rizzo wrote: > > > Do you have a suggestion for an #ifdef /#endif to > > remove the problem you mention ? > > Frankly speaking, I have no solution atm. But IMHO we should fix LINT > and warn our -stable users at least. > > Something like that: > > Index: sys/i386/conf/LINT > === > RCS file: /home/ncvs/src/sys/i386/conf/Attic/LINT,v > retrieving revision 1.749.2.106 > diff -u -r1.749.2.106 LINT > --- sys/i386/conf/LINT2002/03/11 01:23:05 1.749.2.106 > +++ sys/i386/conf/LINT2002/03/26 08:06:56 > @@ -468,8 +468,8 @@ > # Network interfaces: > # The `loop' pseudo-device is MANDATORY when networking is enabled. > # The `ether' pseudo-device provides generic code to handle > -# Ethernets; it is MANDATORY when a Ethernet device driver is > -# configured or token-ring is enabled. > +# Ethernets; it is MANDATORY when the Internet communication > +# protocols family (INET) is configured. > # The 'fddi' pseudo-device provides generic code to support FDDI. > # The `arcnet' pseudo-device provides generic code to support Arcnet. > # The `sppp' pseudo-device serves a similar role for certain types > Index: NOTES > === > RCS file: /home/ncvs/src/sys/i386/conf/NOTES,v > retrieving revision 1.1011 > diff -u -r1.1011 NOTES > --- NOTES 2002/03/23 18:39:54 1.1011 > +++ NOTES 2002/03/26 08:08:48 > @@ -521,8 +521,8 @@ > # Network interfaces: > # The `loop' device is MANDATORY when networking is enabled. > # The `ether' device provides generic code to handle > -# Ethernets; it is MANDATORY when a Ethernet device driver is > -# configured or token-ring is enabled. > +# Ethernets; it is MANDATORY when the Internet communication > +# protocols family (INET) is configured. > # The `fddi' device provides generic code to support FDDI. > # The `arcnet' device provides generic code to support Arcnet. > # The `sppp' device serves a similar role for certain types > > %%% > > I believe handbook is affected too. > > > cheers > > luigi > > > > On Sat, Mar 23, 2002 at 08:50:19PM +0300, Maxim Konovalov wrote: > > > > > > Hello, > > > > > > After this commit 'device ether' is mandatory if ever there is no any > > > ethernet or token-ring devices. > > > > > > | luigi 2002/02/18 14:50:13 PST > > > | > > > | Modified files: > > > |sys/net if.c > > > | Log: > > > | When the local link address is changed, send out gratuitous ARPs > > > | to notify other nodes about the address change. Otherwise, they > > > | might try and keep using the old address until their arp table > > > | entry times out and the address is refreshed. > > > | > > > | Maybe this ought to be done for INET6 addresses as well but i have > > > | no idea how to do it. It should be pretty straightforward though. > > > | > > > | MFC-after: 10 days > > > | > > > | Revision ChangesPath > > > | 1.128 +11 -0 src/sys/net/if.c > > > > > > -- > > > Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer > > > phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > > -- > Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer > phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
