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
/usr/obj/usr/src/tmp/u
On Wed, Sep 22, 1999, Thomas D. Dean wrote:
> <<< 550 service unavailable; [207.93.148.150] blocked using \
> dul.maps.vix.com
It's rather obvious that your IP address, which is a dial-up,
is blocked via the MAPS Dialup Users List (DUL).
Please configure your MTA to use Netcom's SMTP rel
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)
For some reason, after cvsupping about 5 minutes ago, and rebuilding a
kernel, the sb0 device no longer works. it gives me this error:
dscheck(#wd/0x20002): b_blkno 32256 is not on a sector boundary (ssize 1)
Kenneth Culver
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
In message <[EMAIL PROTECTED]> "Chris D. Faulhaber"
writes:
: If I reverse the above, the card seems to work fine again. I'm just
: wondering if this was intentional and/or if the driver will be reenabled
: again [soon].
Doug Rabson sent me patches to make aha work with the new pnp code.
Howeve
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:
--
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 PLL
> 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.
> Gu
> 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.
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.
...
> > 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 brea
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
In reply:
> On Tue, 21 Sep 1999, Luoqi Chen wrote:
>
> > This reminds me about the usage of TSC counter on SMP. First even though
> > we don't use TSC for time keeping on SMP, the TSC frequency from calibration
> > is still valid (at least for BSP), and we can show it in the cpu identification
>
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 (whi
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
> >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 a
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
> This is a request for a review. This patch fixes a bug in specfs
> relating to dealing with the EOF condition of a block device.
>
> If the EOF occurs in the middle of a block, specfs was not
> properly calculating the truncation for the I/O.
I didn't have time to review this
18 matches
Mail list logo
