On Wed, Sep 22, 1999 at 10:40:22AM +0800, Peter Wemm wrote:
No, it's better to remove "device ep0 at isa ? port foo irq blah ..." etc
and just have "device ep0" *only*. If the pnp code finds it, let it use
pnp to configure it.
Does it do that by now? About two or three months ago it didn't
TSC is initialized to 0 at hardware reset, which should happen to all CPUs
at the same time (invalid assumption?), in another words, all TSCs should be
automatically synchronized.
They are not. The PLL is local to each cpu and every single
clock-stop/start event has then inching away from
Hi,
How does one go about dumping the stack trace for the other cpu
while in ddb or gdb?
This is on current.
Thanks,
Lars
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message [EMAIL PROTECTED], Luoqi Chen writes:
people have found sufficiently many cases where the counters are
not in sync after the BIOS is done.
I would really like to know how they managed to read the TSCs simultaneously,
or they resorted to some kind of statistical means (which I
I'm getting 100's of these messages and then a failure of 'make
release':
/usr/local/bin/jade:/usr/doc/ru_RU.KOI8-R/books/faq/book.sgml:9161:12:E: unexpected
element name: QUESTION
/usr/local/bin/jade:/usr/doc/ru_RU.KOI8-R/books/faq/book.sgml:9162:75:E: unexpected
element name: ANSWER
I tried
...
One question comes to mind: is there a way that the TSCs could become
desynchronized somehow? Even though all CPUs run at the same frequency,
isn't there a strong possibility for slight frequency deviation since
we use crystal oscillation instead of a more accurate atomic breakdown
On Wed, 22 Sep 1999, Bruce Evans wrote:
This is a request for a review. This patch fixes a bug in specfs
It is a bit over-commented, and returns wrong error codes for EOF.
This is certainly not over commented in my opinion.
I wish more people would comment as much as Matt does.
I think David was joking with you, hence the \begin{wpaul} statement. Bill
Paul is of course our resident Ethernet driver guy, and he is not known
for his patience with people who do not supply enough information. :)
Only 1/2 joking. This seems to be my month for content free bug reports.
I
Actually I don't really care what you do with this. I did say "more later"
but you chopped that part out. I was only trying to give a heads up.
Then way waste people's time with content-free messages? Just to lower
the signal-to-noise ratio? We all could have waited for this email.
In message [EMAIL PROTECTED], Jim Bryant writes:
since there is only a single master clock oscillator, there really
should be no frequency difference between CPUs.
As long it runs constantly: yes. As soon as you have clock-stop
events you will have different resync times for the on-chip PLLs.
After cvsupping yesterday (last cvsup was at the beginning of the month),
I found that my AHA-1542CP was no longer being seen/probed. I've traced
it down to the following:
RCS file: /home/ncvs/src/sys/i386/isa/isa_compat.h,v
Working file: src/sys/i386/isa/isa_compat.h
head: 1.12
description:
This may be off subject.
I am seeing bounced mail from -current since this evening.
The message is:
550 service unavailable; [207.93.148.150] blocked using \
dul.maps.vix.com
I tried disconnecting from my ISP and redialing to change the IP. Same
results.
My ISP, netcom (now mindspring)
cvsup this evening. make world failed. /usr/src/crypto does not exist.
tomdean
= make world output ==
cd /usr/src/gnu/lib/libdialog; /usr/obj/usr/src/tmp/usr/bin/make beforeinstall
install -C -o root -g wheel -m 444 /usr/src/gnu/lib/libdialog/dialog.h
13 matches
Mail list logo
