freebsd-hackers Digest, Vol 365, Issue 8
freebsd-hac...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
or, via email, send a message with subject or body 'help' to
freebsd-hac...@freebsd.org
You can reach the person managing the list at
freebsd-ha...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-hackers digest..."
Today's Topics:
1. Re: periodically save current time to time-of-day hardware
(Peter Jeremy)
2. random FreeBSD panics (Masoom Shaikh)
3. Re: random FreeBSD panics (Masoom Shaikh)
4. Re: periodically save current time to time-of-day hardware
(Dag-Erling Sm?rgrav)
----------------------------------------------------------------------
Message: 1
Date: Sun, 28 Mar 2010 08:46:34 +1100
From: Peter Jeremy <peter...@acm.org>
Subject: Re: periodically save current time to time-of-day hardware
To: Dag-Erling Sm?rgrav <d...@des.no>
Cc: freebsd...@FreeBSD.org, Andriy Gapon <a...@icyb.net.ua>
Message-ID: <20100327214...@server.vk2pj.dyndns.org>
Content-Type: text/plain; charset="iso-8859-1"
On 2010-Mar-27 01:38:36 +0100, Dag-Erling Smørgrav <d...@des.no> wrote:
>Peter Jeremy <peter...@acm.org> writes:
>> It's not especially important how regularly the RTC is updated, just
>> that it _is_ updated. This suggests that an alternative approach
>> would be for adjtime() / ntp_adjtime() to directly call resettodr() if
>> it's more than P minutes since resettodr() was last called.
>
>It just occurred to me that resettodr() is very slow (it usually
>involves writing to NVRAM over an I2C bus), so it might not be a good
>idea to call it from adjtime().
Traditionally, the (PC) RTC is on the ISA bus (though it's possible it
might use I2C on other architectures or LPC on current PCs). I thought
about speed but only in terms of simulated ISA accesses and didn't
think that adjtime() / ntp_adjtime() were especially time critical
(resettodr() should occur after they have updated the kernel TOD
parameters). The alternative would be a kthread to update the RTC and
I didn't think that was worth it.
Note that resettodr() is currently called with Giant held so if it _is_
excesssively slow, it might be worthwhile reviewing the existing code
in kern_time.c::settime() and subr_clock.c::sysctl_machdep_adjkerntz().
>> As a general comment, whilst resettodr() needs to be serialised, there
>> is no need for it to block. If thread B wants to call resettodr()
>> whilst thread A is doing so, thread B can just skip the call because
>> calling resettodr() twice in quick succession has no benefit.
>
>It does if thread B set the system clock before calling resettodr()
>(think ntpd -gq).
Yes - I hadn't considered resettodr() taking a non-trivial time to
execute. This could allow the scenario: Thread A grabs the RTC update
lock and begin updating the RTC and, whilst it's doing so, thread B
updates the system clock and then calls resettodr() - which turns
into a no-op because the update lock is held.
> Actually, it might be a good idea to call resettodr()
>any time the clock is stepped.
This should occur now via kern_time.c::settime().
Given that:
- resettodr() needs to be serialised;
- resettodr() may take a significant amount of time; and
- resettodr() should ideally be synchronised to the second boundary;
maybe creating a kthread to manage the RTC updating is reasonable.
A rough outline of my idea would be:
A new kthread which sleeps on channel "update_rtc". When woken, it
checks to see if it's within (say) 50msec of a second boundary and so,
it does a trylock on the (new) RTC mutex. If it grabs the mutex then
it performs the update. If it was too far from the second boundary or
it fails to grab the mutex then it sleeps until the next second
boundary and tries again.
The existing resettodr() would then turn into a wakeup(update_rtc).
Or is this overkill?
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100327/03f0eadf/attachment-0001.pgp
------------------------------
Message: 2
Date: Sun, 28 Mar 2010 08:28:29 +0000
From: Masoom Shaikh <masoom...@gmail.com>
Subject: random FreeBSD panics
To: freebsd...@freebsd.org, freebsd-questions
<freebsd-...@freebsd.org>
Message-ID:
<b10011eb1003280128k40...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello List,
I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since
then, system randomly just freezes, and there is no option other than hard
boot. I guessed this will get solved in 8.0-RELEASE, but it was not :(
Many times I get vmcore files, not always. I have dumpdev set to AUTO in my
rc.conf. Almost every time it just fsck's the file-system on reboot. I have
not lost any files though. This is a Dell Inspiron 1525 Laptop with 1GB ram,
Intel Core2 Duo T5500 with ATI Radeon X1400 card. The installation in
question is KDE4 from ports, with radeon/ati driver.
I felt the problem is with wpi driver, then suspected dri driver of X. Then
I observed system freezes even if none of this is installed. e.g. if it is
under some load, like building a port and simultaneously fetching something
over network it hangs, and hangs hard. This persuaded me to think something
is wrong in kernel scheduling itself. May be it is lost in some deadlock,
etc... Thus last weekend I thought I would see how immediate previous
version i.e. FreeBSD-7.3-RELEASE would behave.
I reinstalled FreeBSD7.1 from iso images, svn up'ed FreeBSD7.3 source, did
the normal buildworld, buildkernel, installkernel, installworld cycle.
Unfortunatly this kernel is naughty as well ;-), it also freezes with same
stubbornness. But difference is this time I happen to catch something
interesting.
It panics on NMI, fatal trap 19 while in kernel mode. Loaded the vmcore file
in kgdb and got the backtrace. I obtained vmcore files on two occasions. I
have attached both the back traces. This error most likely suggests hardware
error in RAM, but Windox7 and XP boot just fine and never caused any errors.
To verify if I have errors in my RAM I let run sysutils/memtest86+
overnight, to double verify I also executed Windows Memory Diagnostic test
for four times. None of them reported errors. Can anyone here suggest any
solution.
Masoom Shaikh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmcore0.log
Type: application/octet-stream
Size: 3304 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100328/9757d8bb/vmcore0-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmcore1.log
Type: application/octet-stream
Size: 3346 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100328/9757d8bb/vmcore1-0001.obj
------------------------------
Message: 3
Date: Sun, 28 Mar 2010 11:18:59 +0000
From: Masoom Shaikh <masoom...@gmail.com>
Subject: Re: random FreeBSD panics
To: Ivan Voras <ivo...@freebsd.org>
Cc: freebsd...@freebsd.org, freebsd-...@freebsd.org
Message-ID:
<b10011eb1003280418l203...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Mar 28, 2010 at 10:32 AM, Ivan Voras <ivo...@freebsd.org> wrote:
> Masoom Shaikh wrote:
>>
>> Hello List,
>>
>> I was a happy FreeBSD user, just before I installed FreeBSD8.0-RC1. Since
>> then, system randomly just freezes, and there is no option other than hard
>> boot. I guessed this will get solved in 8.0-RELEASE, but it was not :(
>
> I wild shot - did you try disabling superpages?
>
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>
umm, how do I do that ?
------------------------------
Message: 4
Date: Sun, 28 Mar 2010 13:45:25 +0200
From: Dag-Erling Sm?rgrav <d...@des.no>
Subject: Re: periodically save current time to time-of-day hardware
To: Peter Jeremy <peter...@acm.org>
Cc: freebsd...@FreeBSD.org, Andriy Gapon <a...@icyb.net.ua>
Message-ID: <86fx3k7...@ds4.des.no>
Content-Type: text/plain; charset=utf-8
Peter Jeremy <peter...@acm.org> writes:
> Traditionally, the (PC) RTC is on the ISA bus (though it's possible it
> might use I2C on other architectures or LPC on current PCs).
AFAIK, it's usually on I2C on non-i386 platforms. I2C RTC chips are
dirt cheap and easy to integrate, especially if you already have I2C
temperature sensors and whatnot.
> > Actually, it might be a good idea to call resettodr() any time the
> > clock is stepped.
> This should occur now via kern_time.c::settime().
OK.
> Given that:
> - resettodr() needs to be serialised;
> - resettodr() may take a significant amount of time; and
> - resettodr() should ideally be synchronised to the second boundary;
> maybe creating a kthread to manage the RTC updating is reasonable.
If "synchronised to the second boundary" means what I think it means
(set the RTC at the exact top-of-the-second), don't go out of your way
to implement that. You don't get that kind of accuracy back when you
read it anyway - unless it's a calibrated RTC (I've written a Linux
driver for one, hence my familiarity with eleven-minute-mode etc.)
> A new kthread which sleeps on channel "update_rtc". When woken, it
> checks to see if it's within (say) 50msec of a second boundary and so,
> it does a trylock on the (new) RTC mutex. If it grabs the mutex then
> it performs the update. If it was too far from the second boundary or
> it fails to grab the mutex then it sleeps until the next second
> boundary and tries again.
>
> The existing resettodr() would then turn into a wakeup(update_rtc).
Sounds good to me, but if only that thread has access to the RTC, why
bother with a mutex?
DES
--
Dag-Erling Smørgrav - d...@des.no
------------------------------
End of freebsd-hackers Digest, Vol 365, Issue 8
***********************************************