Re: 1131 unneeded includes in the kernel...

[Brandon D. Valentine]

On Tue, 19 Sep 2000, Matthew Jacob wrote:

>
>Oh- don't get me wrong. Valuable info. Thanks.

What would be very cool is to feed this into another script which strips
these unnecesary includes out.  Then do a test build of LINT in your
local tree and if it succeeds commit a mass removal of them.  The same
concept could be applied to the greater source tree.

Brandon D. Valentine
-- 
bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
"Truth suffers from too much analysis." -- Ancient Fremen Saying



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew J
acob writes:
>
>How did you manage to generate this list. You're smoking
>crack on this one
>
>> dev/isp/isp_target.c
>>  
>> 
>
>as the isp_OS_PLATFORM.h includes is the only include this file has.

Well,

According to src/tools/tools/kerninclude that include is not even
needed.

I'm not claiming that every single line is dogmatically true, but
at least it merits some amount of investigation...

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: 1131 unneeded includes in the kernel...

[Kris Kennaway]

On Wed, 20 Sep 2000, Brandon D. Valentine wrote:

> On Tue, 19 Sep 2000, Matthew Jacob wrote:
> 
> >
> >Oh- don't get me wrong. Valuable info. Thanks.
> 
> What would be very cool is to feed this into another script which strips
> these unnecesary includes out.  Then do a test build of LINT in your
> local tree and if it succeeds commit a mass removal of them.  The same
> concept could be applied to the greater source tree.

...except to the KAME bits, where we don't make gratuitous changes.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew J
acob writes:
>
>How did you manage to generate this list. You're smoking
>crack on this one
>
>> dev/isp/isp_target.c
>>  
>> 
>
>as the isp_OS_PLATFORM.h includes is the only include this file has.

Oh, forgot to say: it could also be indicative of options not
excercised by NOTES/LINT...

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: 1131 unneeded includes in the kernel...

[Matthew Jacob]

Yes, but no. Let the MAINTAINERS shoot their own lines. A script with nag mail
is good though.



On Wed, 20 Sep 2000, Brandon D. Valentine wrote:

> On Tue, 19 Sep 2000, Matthew Jacob wrote:
> 
> >
> >Oh- don't get me wrong. Valuable info. Thanks.
> 
> What would be very cool is to feed this into another script which strips
> these unnecesary includes out.  Then do a test build of LINT in your
> local tree and if it succeeds commit a mass removal of them.  The same
> concept could be applied to the greater source tree.
> 
> Brandon D. Valentine
> -- 
> bandix at looksharp.net  |  bandix at structbio.vanderbilt.edu
> "Truth suffers from too much analysis." -- Ancient Fremen Saying
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Br
andon D. Valentine" writes:
>On Tue, 19 Sep 2000, Matthew Jacob wrote:
>
>>
>>Oh- don't get me wrong. Valuable info. Thanks.
>
>What would be very cool is to feed this into another script which strips
>these unnecesary includes out.  Then do a test build of LINT in your
>local tree and if it succeeds commit a mass removal of them.  The same
>concept could be applied to the greater source tree.

This is found by compiling i386/conf/GENERIC, i386/conf/NOTES, 
pc98/conf/GENERIC and all modules, but I cannot test on alpha
and there are various bogosities which can give false positives
on this list.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: 1131 unneeded includes in the kernel...

[Matthew Jacob]

On Wed, 20 Sep 2000, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Matthew J
> acob writes:
> >
> >How did you manage to generate this list. You're smoking
> >crack on this one
> >
> >> dev/isp/isp_target.c
> >>
> >> 
> >
> >as the isp_OS_PLATFORM.h includes is the only include this file has.
> 
> Well,
> 
> According to src/tools/tools/kerninclude that include is not even
> needed.
> 
> I'm not claiming that every single line is dogmatically true, but
> at least it merits some amount of investigation...

Sure.

But your tool did not try the ISP_TARGET_MODE kernel option, which is what
would then cause this file to even be compiled. The compile would fail, since
99% of all defined values, as in CT_SENDSTATUS and so on, are in files brought
in by that header.

I think I see what it is. The includes are outside the

#ifdef ISP_TARGET_MODE

but still

As you say- merited investigation. Thanks.




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Matthew Jacob]

On Wed, 20 Sep 2000, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Matthew J
> acob writes:
> >
> >How did you manage to generate this list. You're smoking
> >crack on this one
> >
> >> dev/isp/isp_target.c
> >>
> >> 
> >
> >as the isp_OS_PLATFORM.h includes is the only include this file has.
> 
> Oh, forgot to say: it could also be indicative of options not
> excercised by NOTES/LINT...

Yup.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: 1131 unneeded includes in the kernel...

[John Baldwin]

On 20-Sep-00 Poul-Henning Kamp wrote:
> 
> UNNEEDED #includes in the FreeBSD kernel

Err, how exactly are you generating these?

> i386/i386/db_interface.c
>   

If you compile a kernel with KTR and DDB. *bewm*
If you are using LINT for these tests, then it probably
means that the KTR #define's aren't in NOTES, which I'll
put on the todo list.
 
> i386/i386/synch_machdep.c
>   

Err, if DDB is defined, this file looks at db_active, which
is declared in 

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ssh and scp fail connecting to a root account

[Udo Schweigert]

On Wed, Sep 20, 2000 at 04:06:24 +0100, Brian Somers wrote:
> > On 17 Sep 2000, Jason Evans wrote:
> > 
> > > On Fri, Sep 15, 2000 at 03:40:12PM +0100, Konstantin Chuguev wrote:
> > > > Udo Schweigert wrote:
> > > > 
> > > > > after a fresh build of -current openssh does not work if connecting to the
> > > > > root-user. For example (tested from a -stable machine, but the same from
> > > > > 4.1-RELEASE):
> > > > 
> > > > Yes, I've been seeing the same thing since the checkout of the SMPng stuff...
> > > > No idea why it's happening.
> > > 
> > > I've seen similar things intermittently over the past 10 days, and
> > > specifically the same problem for the past three days or so.  I'm pretty
> > > sure that the problems have been associated with the random device rather
> > > than the SMP work specifically.
> > 
> > Well, the crash is apparently due to malloc flags - remove the
> > /etc/malloc.conf link and it may work better. I've only seen this once,
> > and when I tried to run sshd under gdb it went away, and now I can't
> > reproduce it again. :-(
> 
> Got it !
> 
> See version 1.6 of src/lib/libc/stdlib/setenv.c.  This took me all 
> night - Up for work in two hours !!! :-(
> 

Perfect! Now it also works for me. Thank you very much, Brian.

Best regards.
-- 
Udo Schweigert, Siemens AG   | Voice  : +49 89 636 42170
ZT IK 3, Siemens CERT| Fax: +49 89 636 41166
D-81730 Muenchen / Germany   | email  : [EMAIL PROTECTED]
PGP-2/5 fingerprint  | D8 A5 DF 34 EC 87 E8 C6  E2 26 C4 D0 EE 80 36 B2


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[Sheldon Hearn]

On Tue, 19 Sep 2000 18:40:43 +0400, "Andrey A. Chernov" wrote:

> With very latest kernel I got lots of
> 
> microuptime() went backwards (1.3624050 -> 1.998840)
> 
> messages just before

I've also seen them for the first time with today's kernel.
Interestingly, today's kernel also seems to attribute more than 99% of
CPU to system, in spite of some CPU-bound userland processes running.

If that's already been noted on this list, my apologies.  I certainly
haven't seen it mentioned, but I may have been reading too fast.

Ciao,
Sheldon.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Alfred Perlstein]

* Poul-Henning Kamp <[EMAIL PROTECTED]> [000919 23:51] wrote:
> 
> UNNEEDED #includes in the FreeBSD kernel
> 
> agp_if.c
>   
> 

[snip]

These reports would be a lot more useful if you included the last person
to touch these files along with the first line of the Copyright.

-Alfred


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Current periodic change

[Manfred Antar]

periodic is broken in current

# /usr/sbin/periodic daily
/usr/sbin/periodic: 43: Syntax error: ")" unexpected (expecting ";;")

==
||  [EMAIL PROTECTED]   ||
||  Ph. (415) 681-6235  ||
==



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

5.0-20000917 Snapshot and Gericom Notebook -> bad crash

[Oliver Schonefeld]

Hello freebsd-current!

The loader or the kernel crashed badly on my Gericom Overdose II notebook.

I was trying to boot from the bootdisk-set. The mfsroot image is successfuly
loaded and the "bootcountdown" ist displayed.

After that it looks like there are some cpu-registers dumped.
unfortunalty everything scrolls too fast, i cannot really read anything.

It any aditional information is needed, please contact me.

Regards,
Oliver
-- 

And remember: "To Infinity And Far Beyond ... Somehow?!"

email: [EMAIL PROTECTED]
   [EMAIL PROTECTED]

Hi! I'm a .signature virus! Copy me in your ~/.signature
to help me spread! <- Save this lifeform ;-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[Bruce Evans]

On Wed, 20 Sep 2000, John Baldwin wrote:

> On 19-Sep-00 Bruce Evans wrote:
> > It really does go backwards.  This is caused by the giant lock preventing
> > the clock interrupt task from running soon enough.  The giant lock can
> > also prevent the clock interrupt task from running often enough even
> > after booting.  E.g., "dd if=/dev/random of=/dev/null bs=large" does
> > several bad things.
> 
> It's not the Giant lock that is at fault.  We give up Giant during mi_switch().
>  Then scheduling problem is in the way that the top-level scheduler runs.

Then the scheduler is more broken than I thought :-).

Initially there may be a locking problem as well as a scheduling problem.
Giving up Giant in the first mi_switch() is a bit late.  mi_switch() uses
microuptime(), and the clock task needs to be run before then to finish
initialization of the timecounter.

> We
> decide to schedule another process due to the timeslice ending during the clk
> interrupt thread.

How can this work?  The timeslice accounting stuff doesn't get updated until
the clock task runs.

> In the past, this was not run as a thread, so it ran, set
> the AST_* constant for needing a resched and then exited.  During doreti, we
> notice an AST is pending and call ast(). ast() calls userret() which notices
> that a resched is needed and calls mi_switch().  In the New World Order, when
> the clock interrupt occurs, we set the AST_* constant for every interrupt
> before returning from sched_ithd().  This results in the actual interrupt
> threads being schedule from ast().

What should happen is for ast() to normally schedule the clock interrupt
(and other interrupts) immediately (unless they are blocked).  This doesn't
seem to be working, and I can't see how it can work, since there is nothing
except the giant lock to tell us whether interrupts are blocked, and the
giant lock is held most of the time in system mode.  Previously, cpl told
us, but cpl is no longer maintained.


> However, when the clk ithread finishes, it
> simply calls mi_switch() to enter the next process in ithd_loop().  The
> need_resched() that it sets isn't handled until the next call to userret()
> either via a hardware interrupt or a syscall return.  Thus, the problem isn't
> due to Giant, but rather to interrupt threads.

I think this is a different problem.  It is similar to a problem for
scheduling netisrs from non-interrupt context.  schednetisr() sets the
AST flag and some other flags.  Nothing looks at these flags until an
interrupt occurs or the process sleeps.  Previously, this was handled in
splx():

s = splnet();   /* s == 0 in process context. */
queue_net_output(...);
schednetisr(...);
splx(s);/* Since s == 0, the netisr gets run here. */

Will this work again as soom as splx() is replaced by mtx_exit(), etc?
We only have a few thousand spls to change :(.

> As for the micruptime()
> messages on boot, they only occur here on a UP kernel.  On an SMP kernel I
> don't get them.  Also, they always occur during mi_switch() when an interrupt
> thread is finishing and going back to sleep.  The first such thread to be run
> to generate thet error message is the irq0: clk ithread, so the clk ithread is
> running fine.

They are very timing dependent, and probably also very task-mix
dependent.  The primary cause of microuptime() going backwards is
tv_nsec overflowing if the system takes longer than 2^32 nsec (about
4 seconds) between the initialization of the timecounter and the
timecounter maintenance for the first clock interrupt.  On one of my
systems, the first thread to call mi_switch() is the generic thread
(proc0?) that executes run_interrupt_driven_hooks().  mi_switch() is
called for the first time when the ata hook goes to sleep.  Things
would be a little different for SMP.  Hopefully another cpu handles
the clock interrupt.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, John Baldwin writes:

>As for the micruptime()
>messages on boot, they only occur here on a UP kernel.  On an SMP kernel I
>don't get them.  Also, they always occur during mi_switch() when an interrupt
>thread is finishing and going back to sleep.  The first such thread to be run
>to generate thet error message is the irq0: clk ithread, so the clk ithread is
>running fine.

The microuptime() messages occur because the timecounters expect the
i8254 clock interrupt to run "hz" times per second, and it doesn't.

In particular it doesn't during then 10-20 seconds we probe/attach
devices.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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

Floppy does not work now

[Szilveszter Adam]

Hello everybody!

I have upgraded to this morning's (CEST) -CURRENT (must have been around
07:00 UTC). Build and installworld went fine, kernel built succesfully. I
did not change anything in the kernel config from the previous run 
(which was on 15th September) but when I rebooted with the new kernel, the 
floppy drive was not probed, and the fdc simply said:

fdc0: cannot reserve I/O port range

Now, this is funny, I have never experienced anything like this on
FreeBSD:-) I do not know if this is a known issue (if so, tell me to RTFM)
but if not, maybe someone may have an idea... I certainly have 

device   fdc

in my kernel config and the appropriate hints in my hints file.

Output of 'boot -v', kernel config and hints file are available and I shall
be happy to include all info you might need but simply I am at a loss
here...

Datapoint: No other issues have been sighted here recently, certainly none
of the 'microuptime() went back...' stuff.

Thanks for your time!
-- 
Regards:

Szilveszter ADAM
Szeged University
Szeged Hungary


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[Siobhan Patricia Lynch]

John,
I get these on an SMP kernel, which locks up the box, I can't even
figure out where exactly its happening. Maybe I'm just missing something
in my kernel config file? I assumed (from UPDATING) that no real change
was
needed to the SMP options?

The hardware is an Intel N440BX motherboard with two PII333 procs.

I'm not opposed to the option that this is *my* error and not SMPNG's

PRE_SMPNG is VERY stable on this box, however the constant crashes (mostly
during high I/O periods, such as make world) have made it impossible to
use the machine for any type of real development under SMPNG. (which if I
had time since the promotion, I'd be a bit crazy right now)

If theres is anything I can do to help debug this, let me know, you can
email me privately.

-Trish


__

Trish Lynch
FreeBSD - The Power to Serve[EMAIL PROTECTED]
Rush Networking [EMAIL PROTECTED]
VA Linux Systems[EMAIL PROTECTED]
O|S|D|N [EMAIL PROTECTED]
---

"So if you ask me how do I fell inside I could honestly
 Tell you we've been taken on a very long ride
 And if my owners let me have some free time some day
 With all good intention I would probably run away
 Clutching the short straw"
-Marillion, That Time of the Night



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[Siobhan Patricia Lynch]

more info,
the N440BX has a symbios scsi card on board and an fxp card onboard.
I'm using relatively old scsi drives (4500 RPM seagates and HP drives)
I have softupdates on, and I'm now using COMPAT_OLDPCI for now, although I
only turned it back on after seeing that was the only real change I made
to my kernel config pre and post SMPNG.

-Trish

__

Trish Lynch
FreeBSD - The Power to Serve[EMAIL PROTECTED]
Rush Networking [EMAIL PROTECTED]
VA Linux Systems[EMAIL PROTECTED]
O|S|D|N [EMAIL PROTECTED]
---

"what makes me think i could start clean slated
 the hardest to learn was the least complicated"
-Indigo Girls, Least Complicated



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Breakage in SYSV emulation?

[bofh]

Hi,

since this morning, the SysVR4 modules appear to be broken:

[...]

===> streams
make: don't know how to make @/svr4/svr4_types.h. Stop
*** Error code 2
 
Stop in /usr/src/sys/modules.
*** Error code 1
 
Stop in /usr/src/sys/compile/BOFH.

Anyone know how to fix this?

TIA,
s. 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Floppy does not work now

[Visigoth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 20 Sep 2000, Szilveszter Adam wrote:
> floppy drive was not probed, and the fdc simply said:
> 
> fdc0: cannot reserve I/O port range

You don't happen to have a DPT raid card in that do you?  Just
wondering if on the off chance it is related to my PR kern/21378.  If not,
oh well, just shootin in the dark...

Visigoth


Damieon Stark
Sr. Unix Systems Administrator
[EMAIL PROTECTED]

PGP Public Key: www.telemere.net/~visigoth/visigoth.asc


|
M$ -Where do you want to go today?  |
Linux -Where do you want to go tomorrow?|   FreeBSD - The POWER to serve
Freebsd -Are you guys coming or what?   |   http://www.freebsd.org
|
|
- 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1i

iQA/AwUBOcjK+jnmC/+RTnGeEQKslgCeOLgbvRtx8fOPV0icc5SG43SwOa4AoJI5
gElU9WYtQKptpTQR1g6AcWZg
=6f7y
-END PGP SIGNATURE-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Floppy does not work now

[Adam Szilveszter]

On Wed, Sep 20, 2000 at 10:34:31AM -0500, Visigoth wrote:
> On Wed, 20 Sep 2000, Szilveszter Adam wrote:
> > floppy drive was not probed, and the fdc simply said:
> > 
> > fdc0: cannot reserve I/O port range
> 
>   You don't happen to have a DPT raid card in that do you?  Just
> wondering if on the off chance it is related to my PR kern/21378.  If not,
> oh well, just shootin in the dark...

Uhm, no:-) This is a simple workstation with only an IDE disk and an ATAPI
CD-ROM both as masters. And the floppy has *always* worked up till today,
including with a kernel & world after the SMPng commit (they were from 
Sept 15th.) 

That's why I thought I'd bring it up... maybe it rings a bell with somebody.
The drive seems to be okay and is probed by the BIOS on startup, so I could
boot from it, but is not usable on FreeBSD for the time being:-(

-- 
Regards:

Szilveszter ADAM
Szeged University
Szeged Hungary


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Floppy does not work now

[Visigoth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 20 Sep 2000, Adam Szilveszter wrote:
> 
> Uhm, no:-)

Oh well... *sigh* no end in sight...  
It was worth a try ;)

Visigoth

Damieon Stark
Sr. Unix Systems Administrator
[EMAIL PROTECTED]

PGP Public Key: www.telemere.net/~visigoth/visigoth.asc


|
M$ -Where do you want to go today?  |
Linux -Where do you want to go tomorrow?|   FreeBSD - The POWER to serve
Freebsd -Are you guys coming or what?   |   http://www.freebsd.org
|
|
- 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1i

iQA/AwUBOcjRJDnmC/+RTnGeEQIDYgCfbe01rm7/lrkZIQLUrjsPB4vx4iwAoMM5
bg9A/5CG7bj4u/6Ou+oXysXx
=+5wJ
-END PGP SIGNATURE-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ssh and scp fail connecting to a root account

[Nate Williams]

[ OpenSSH failure with particular malloc.conf flags ]

> Got it !
> 
> See version 1.6 of src/lib/libc/stdlib/setenv.c.  This took me all 
> night - Up for work in two hours !!! :-(

Good catch!


Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Congrats on the SMPng work!

[Matt Dillon]

Sniff!  I feel so left out, I have so little time to play these days.

You guys are all doing really exciting work, congratulations!

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[John Baldwin]

On 20-Sep-00 Siobhan Patricia Lynch wrote:
> John,
>   I get these on an SMP kernel, which locks up the box, I can't even
> figure out where exactly its happening. Maybe I'm just missing something
> in my kernel config file? I assumed (from UPDATING) that no real change
> was
> needed to the SMP options?

No, it is probably a bug in the code with this scheduling mess.  On the
quad xeon here, very recent kernels are spinning during the acd0
probe with interrupts disabled, so there may be a few places where
interrupts aren't being handled properly.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Warner Losh]

In message <94952.969433843@critter> Poul-Henning Kamp writes:
: Oh, forgot to say: it could also be indicative of options not
: excercised by NOTES/LINT...

There are a few NEWCARD/OLDCARD issues that you catch here  I'll
fix the rest.  Thanks!

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <94952.969433843@critter> Poul-Henning Kamp writes:
>: Oh, forgot to say: it could also be indicative of options not
>: excercised by NOTES/LINT...
>
>There are a few NEWCARD/OLDCARD issues that you catch here  I'll
>fix the rest.  Thanks!

Yeah, from time to time we have mutually exclusive options, it may
be an idea to introduce an LINT2 kernel to contain the options
which cannot co-exist in LINT.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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: 1131 unneeded includes in the kernel...

[Warner Losh]

In message <98558.969478759@critter> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Warner Losh writes:
: >In message <94952.969433843@critter> Poul-Henning Kamp writes:
: >: Oh, forgot to say: it could also be indicative of options not
: >: excercised by NOTES/LINT...
: >
: >There are a few NEWCARD/OLDCARD issues that you catch here  I'll
: >fix the rest.  Thanks!
: 
: Yeah, from time to time we have mutually exclusive options, it may
: be an idea to introduce an LINT2 kernel to contain the options
: which cannot co-exist in LINT.

I'd planned on doing that when I had a working NEWCARD.  That should
happen fairly soon, if I can ever thread the knot on the legacy
interface.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Initial installation console

[Forrest Aldrich]

Can the configuration for bootup and initial installation be configured to 
detect (and configure) a serial console.  This would be very useful for 
rackmount systems.  Yes, I know it can be done manually after the 
installation is completed with a monitor; but this would save some time.

If I'm missing something obvious, please let me know.  I just tested it 
with a 2u system, booted up with a serial console, and it wasn't detected.


Thanks.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Initial installation console

[Alfred Perlstein]

* Forrest Aldrich <[EMAIL PROTECTED]> [000920 12:46] wrote:
> Can the configuration for bootup and initial installation be configured to 
> detect (and configure) a serial console.  This would be very useful for 
> rackmount systems.  Yes, I know it can be done manually after the 
> installation is completed with a monitor; but this would save some time.
> 
> If I'm missing something obvious, please let me know.  I just tested it 
> with a 2u system, booted up with a serial console, and it wasn't detected.

If you boot without a keyboard attached and make sure you're using
"Com1" then it should work.

-Alfred


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: periodic no longer usable by users?

[Brian Somers]

> It seems that recent (the last two weeks?) changes to periodic have
> changed things so that non-root users of it no longer get any output.
> 
> A simple fix would be to change the default output to $USER (not yet
> tested). However, having a user-specific periodic.conf would be a lot
> more useful. But I wanted to see what others thought of it before
> trying it.

I've tweaked things so that the default is to send output to stdout 
again, and so that it uses ${TMPDIR:-/tmp} for it's temporary files.

Let me know if there are any further problems.

>   
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Initial installation console

[Mike Smith]

> Can the configuration for bootup and initial installation be configured to 
> detect (and configure) a serial console.  This would be very useful for 
> rackmount systems.  Yes, I know it can be done manually after the 
> installation is completed with a monitor; but this would save some time.

Not at the moment, unfortunately.  Due to some stupidity in modern BIOS 
code, the automatic keyboard detection that we used to do no longer works 
and had to be removed.

If you can deal with booting from floppies, you can create /boot.config
on the first floppy containing just '-h' and you'll get a serial console. 

If you're building a CDROM install distribution, vnconfig/mount the 
boot.flp image and do the same there.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Current periodic change

[Brian Somers]

> periodic is broken in current
> 
> # /usr/sbin/periodic daily
> /usr/sbin/periodic: 43: Syntax error: ")" unexpected (expecting ";;")

Oops, fixed.  Thanks.

> ==
> ||  [EMAIL PROTECTED]   ||
> ||  Ph. (415) 681-6235  ||
> ==

-- 
Brian <[EMAIL PROTECTED]>
     
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Initial installation console

[Jordan Hubbard]

> Can the configuration for bootup and initial installation be configured to 
> detect (and configure) a serial console.  This would be very useful for 

The current installation "detects" serial console situations if you
have a BIOS capable of properly instructing the loader about this or
if you explicitly boot with -P at the first-stage loader.  After that,
sysinstall should properly fail to open /dev/ttyv0 and trundle on
using the serial console instead of a graphics card.

My question is simply what you mean by "configure" in this context.
You want it to write an /etc/ttys entry out for a specific serial
device?  I suppose we could also just turn the console entry on as a
wimp-out in such scenarios and get away with it.

That's assuming, of course, I am clear on what you mean.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 1131 unneeded includes in the kernel...

[Mark Murray]

> UNNEEDED #includes in the FreeBSD kernel
:
:
> dev/randomdev/harvest.c
>   
>   
>   
> 
> dev/randomdev/hash.c
>   
>   
> 
> dev/randomdev/randomdev.c
>   
>   
> 
> dev/randomdev/yarrow.c
>   
>   
...

Thanks! Dealt with.

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: rpc.lockd

[Scot W. Hetzel]

From: "Roman Shterenzon" <[EMAIL PROTECTED]>
> On Tue, 19 Sep 2000 [EMAIL PROTECTED] wrote:
> > Yeah probably should...perhaps suggest it to -docs. Someone (from
> > something.edu, perhaps rpi.edu) posted a URL to one of the lists of a
> > working but untested rpc.lockd. You might like to try it...if it gets
> > enough testing it should make it in for 4.2 (one hopes).
> > 
> > Andrew
> > 
> Thanks, I'm ready to give it a try, does anyone the URL?
> I'll search the archives meanwhile.
> (Was it ported from NetBSD?)
> 
I kind of remember reading about it on the current mailing list.


Current-Users:

Has a working rpc.lockd been imported into CURRENT.

If it has, is there a possibility of getting it MFC'd to STABLE.

Thanks,

Scot



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: recent kernel, microuptime went backwards

[John Baldwin]

On 19-Sep-00 Bruce Evans wrote:
> On Tue, 19 Sep 2000, Andrey A. Chernov wrote:
> 
>> With very latest kernel I got lots of
>> 
>> microuptime() went backwards (1.3624050 -> 1.998840)
>> 
>> messages just before
>> 
>> Mounting root from ufs:/dev/da0s1a
> 
> It really does go backwards.  This is caused by the giant lock preventing
> the clock interrupt task from running soon enough.  The giant lock can
> also prevent the clock interrupt task from running often enough even
> after booting.  E.g., "dd if=/dev/random of=/dev/null bs=large" does
> several bad things.

It's not the Giant lock that is at fault.  We give up Giant during mi_switch().
 Then scheduling problem is in the way that the top-level scheduler runs.  We
decide to schedule another process due to the timeslice ending during the clk
interrupt thread.  In the past, this was not run as a thread, so it ran, set
the AST_* constant for needing a resched and then exited.  During doreti, we
notice an AST is pending and call ast(). ast() calls userret() which notices
that a resched is needed and calls mi_switch().  In the New World Order, when
the clock interrupt occurs, we set the AST_* constant for every interrupt
before returning from sched_ithd().  This results in the actual interrupt
threads being schedule from ast().  However, when the clk ithread finishes, it
simply calls mi_switch() to enter the next process in ithd_loop().  The
need_resched() that it sets isn't handled until the next call to userret()
either via a hardware interrupt or a syscall return.  Thus, the problem isn't
due to Giant, but rather to interrupt threads.  As for the micruptime()
messages on boot, they only occur here on a UP kernel.  On an SMP kernel I
don't get them.  Also, they always occur during mi_switch() when an interrupt
thread is finishing and going back to sleep.  The first such thread to be run
to generate thet error message is the irq0: clk ithread, so the clk ithread is
running fine.

> Bruce

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message