headers
Sean Chittenden | 1 Nov 2003 02:02
Gravatar

Re: 5.1 suddenly reboots (new user)

> Hello, I just installed version 5.1 for the first time.

You may want to update your sources to something more recent than 5.1
release if you're going to use 5.X.  So much has been fixed, updated
since 5.1, it's very likely that this bug has been fixed.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html

-sc

--

-- 
Sean Chittenden
_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Helge Oldach | 1 Nov 2003 13:36

CPU1 never used despite HTT?

Hi,

I am running a Xeon with hyperthreading support. Until last week's HTT
modifications, according to ps(1) and top(1) both logicals CPUs were in
use. (Processes in CPU0 and CPU1 state; "C" column showing "0" or "1".)

This has changed with a recent -STABLE kernel which includes last week's
changes to HTT (removing "options HTT"). I am only seeing processes
on CPU0 and in "0" state in the "C" column. I am not sure whether
the second logical CPU is indeed unused, but concluding from rough
performance indicators that might be the case: "make -j2 buildworld"
takes as long as "make -j1 buildworld".

According to dmesg, the second CPU is indeed launched (see below).

Note that this is virtually a GENERIC kernel. The only differences to
the shipping GENERIC are:

21,22c21,22
< cpu           I386_CPU
< cpu           I486_CPU
---
> #cpu          I386_CPU
> #cpu          I486_CPU
64,65c64,65
< #options      SMP                     # Symmetric MultiProcessor Kernel
< #options      APIC_IO                 # Symmetric (APIC) I/O
---
> options       SMP                     # Symmetric MultiProcessor Kernel
> options       APIC_IO                 # Symmetric (APIC) I/O
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simon L. Nielsen | 1 Nov 2003 14:02
Picon
Favicon

Re: CPU1 never used despite HTT?

On 2003.11.01 13:36:42 +0100, Helge Oldach wrote:
> Hi,
> 
> I am running a Xeon with hyperthreading support. Until last week's HTT
> modifications, according to ps(1) and top(1) both logicals CPUs were in
> use. (Processes in CPU0 and CPU1 state; "C" column showing "0" or "1".)

From UPDATING:

20031022:
        Support for HyperThread logical CPUs has now been enabled by
        default.  As a result, the HTT kernel option no longer exists.
        Instead, the logical CPUs are always started so that they can
        handle interrupts.  However, the extra logical CPUs are prevented
        from executing user processes by default.  To enable the logical
        CPUs, change the value of the machdep.hlt_logical_cpus from 1 to
        0.  This value can also be set from the loader as a tunable of
        the same name.

I would guess that's your problem.

--

-- 
Simon L. Nielsen
FreeBSD Documentation Team
Permalink | Reply | 0 comments |
headers
Harald Schmalzbauer | 1 Nov 2003 16:32
Picon

Re: Updating 5.1 sources

On Thursday 19 June 2003 03:39, westcoastlew <at> earthlink.net wrote:
> wondering how I would go about updating my sources in 5.1.
> I don't have local access to the server it's self, So I cannot "shutdown
> now" Last time I had upgraded sources, ruined everything.. Anyone have any
> good documentation on upgrading kernel / sources? I run 5.1 - RELEASE #0
> I'd like to run FreeBSD 5.1-CURRENT.  westcoastlew <at> earthlink.net

Fist, correct your date.
Next I'd suggest cvsup and a careful look at http://www.freebsd.org/doc/
en_US.ISO8859-1/books/handbook/current-stable.html and following.
Updating sources would never ruin anything!
And FreeBSD is not only a kernel but a complete operating system so just 
building a new kernel can lead you into trouble.

Good luck,

-Harry

P.S: Why do you state a reply in the subject (Re:) when it isn't one?

>
>
>
> Regards
> _______________________________________________
> freebsd-stable <at> freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Kent Hauser | 1 Nov 2003 23:14
Picon

version number bump missed

In release/Makefile, the "BASE" variable still reads 4.8

Cheers, Kent

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 4 comments |
headers
Colin Percival | 1 Nov 2003 23:27
Picon
Picon

Re: version number bump missed

At 12:14 01/11/2003 -1000, Kent Hauser wrote:
>In release/Makefile, the "BASE" variable still reads 4.8

   It usually takes a couple weeks before the someone remembers to bump the 
-STABLE version number.  Maybe "don't forget to bump the -STABLE branch 
numbers as well" should be added to 
doc/en_US.ISO8859-1/articles/releng/article.sgml?

Colin Percival

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 2 comments |
headers
Darren Henderson | 2 Nov 2003 03:28
Favicon

syscon cursor change in 4.9-STABLE?


Ok, potentially silly observation time - may just be a sign of my brain
ossifying ... have upgraded three systems to 4.9-STABLE with a cvsup from
10/31. Two from 4.9 pre-releases and one from 4.8-STABLE.

The cursor behavior in the console (and rxvt and xterm) seems to have
changed. I seem to recall it having always been a slow blinking block. Now
its a non-blinking block. Can't seem to get it to go back to what I
remember. vidcontrol -c blink causes to the cursor to blink in syscons but
at a very rapid rate. Not sure I see how the behavior of syscons and the X
terminals could be related.

Only things in rc.conf are 'saver="warp"', 'blanktime="300"' and
'keyrate="fast"'.

So, on the basis of this, am I imagining things?

Everything else seems fine (with one exception, installing via an NFS
mount of /usr/src with values for SENDMAIL_MC and SENDMAIL_SUBMIT_MC set
in /etc/make.conf causes installworld to fail while installing sendmail.mc
complaining about the file not being found even though it is present but
that is a different story).

-Darren

______________________________________________________________________
Darren Henderson                                  darren <at> nighttide.net

                   Help fight junk e-mail, visit http://www.cauce.org/
_______________________________________________
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Lehey | 2 Nov 2003 03:25
Favicon

Re: vinum question: how could one correctly delete vinum module?

On Friday, 31 October 2003 at 15:41:42 +0300, Dmitry Morozovsky wrote:
> Dear colleagues,
>
> [I'm under 4-STABLE]
>
> What is the correct sequence to delete existing vinum module (for example,
> raid10) and do *not* use -f flags for vinum?

I think your terminology is incorrect.  To delete an existing Vinum
module under release 4, you would normally do:

  # rm /modules/vinum.ko 

To unload the module from the kernel, you would first quiesce the
Vinum system and then do:

  # vinum stop

But I'd guess that this isn't what you want to do.

> in my case t is raid10 vovume:
>
> vinum -> l -r t
> V t                     State: up       Plexes:       2 Size:       8191 MB
> P t.p0                S State: up       Subdisks:     2 Size:       8191 MB
> P t.p1                S State: up       Subdisks:     2 Size:       8191 MB
> S t.d0                  State: up       PO:        0  B Size:       4095 MB
> S t.d8                  State: up       PO:      260 kB Size:       4095 MB
> S t.d2                  State: up       PO:        0  B Size:       4095 MB
> S t.d10                 State: up       PO:      260 kB Size:       4095 MB
(Continue reading)

Permalink | Reply | 1 comment |
headers
Malcolm Kay | 2 Nov 2003 05:51
Favicon

Re: syscon cursor change in 4.9-STABLE?

On Sun, 2 Nov 2003 12:58, Darren Henderson wrote:
> Ok, potentially silly observation time - may just be a sign of my brain
> ossifying ... have upgraded three systems to 4.9-STABLE with a cvsup from
> 10/31. Two from 4.9 pre-releases and one from 4.8-STABLE.
>
> The cursor behavior in the console (and rxvt and xterm) seems to have
> changed. I seem to recall it having always been a slow blinking block. Now
> its a non-blinking block. Can't seem to get it to go back to what I
> remember. vidcontrol -c blink causes to the cursor to blink in syscons but
> at a very rapid rate. Not sure I see how the behavior of syscons and the X
> terminals could be related.
>
> Only things in rc.conf are 'saver="warp"', 'blanktime="300"' and
> 'keyrate="fast"'.
>
> So, on the basis of this, am I imagining things?
>

I'm running 4.7-STABLE and I have steady block cursors both in console and
xterm -- I haven't taken any specific action to set them this way. Nor do I 
recall having blinking cursors on earlier versions. It could be you found 
some way of setting this up earlier that has now got lost. May be I am
missing something -- I would hate to suggest your brain really is ossifying;-)

More likely you are just mis-remembering which happens to most of us some of 
the time (even me).

Malcolm Kay

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zoran Kolic | 2 Nov 2003 07:11
Picon

ipfw2 logging


Dear list!
I have a little problem, trying
to enable logging of deny rule.
I have enabled it via kernel:

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=3

It is ipfw2. After that, my inten-
tion was to use syslogd and

!ipfw
*.*       /var/log/ipfw.log

and newsyslog with

/var/log/ipfw.log  600 3 100   *   J

In rc.conf I have

firewall_enable="YES"
firewall_logging="YES"

Well! Firewall works, I have data
with "ipfw show", but there is no
log. My intentioned rule is

add 65535 deny log all from any to any
(Continue reading)

Permalink | Reply | 0 comments |

Gmane