:With this commit, my Kernel seems looping in doreti_ast
:(doreti_ast+0x15) (as seen by trace after Ctrl+Alt+Esc) after
:displaying "mounting root device" :)
:
:My kernel config is on http://www.hsc.fr/~thivillo/YOKO50
:
:i have rerun cvsup to be sure that all things are in sync, ipl.s shows:
:
On Tue, 28 Mar 2000 19:48:13 EST, Garance A Drosihn wrote:
my guess is that's easier said than done, but still it would be
nice if it WERE done... :-)
I don't think it's that difficult, and I like your idea. I'll have a
look at the sed/awk magic.
Ciao,
Sheldon.
To Unsubscribe: send mail
Hi everyone...
I got this error evrytime I try to make world no matter how often I
cvsup'ed. I don't know what it is, what is Error code 2 anyway? Is my cc
version is out-of-date? I'm using the GNU gcc-2.95.1. My box is running on
4.0-CURRENT. Any idea? Is it because I've cvsuped the wrong
Rev 1.35 of src/sys/i386/isa/ipl.s, which I just committed, should
fix the boot lockups.
Many thanks for Alain Thivillon who was able to catch it in the act
with DDB and narrow the problem down to doreti looping on astpending.
To anyone I asked to try backing out the recent
Brian Somers wrote:
Hi,
After upgrading my box to the 4.0-STABLE, I've discovered that ppp started
produce regular warnings I've never seen before:
Warning: nat_LayerPull: Dropped a packet
What does it mean and what implications may it have?
This is pretty
On 28 Mar, George Neville-Neil wrote:
1) How do I do development and not overwrite my work when cvsup'ing?
See 3).
3) Is there a guide on using CVS with CVSup (the man page is not particularly
helpful) so that I can have a CVS tree that is updated by cvsup?
See
Brian Somers wrote:
Ah, ok. This is incoming data that's being ignored by ppp - maybe
because you've got ``nat deny_incoming yes'' configured ?
Yes, I have ``nat deny_incoming yes''. Thanks for explaining.
Maybe it would be worth to add more meaningful warning message like "Dropped a
At 4:28 PM -0800 2000/3/28, Matthew Jacob wrote:
Yes, we very much has considered this. What's your issue about this, per se?
Right now there's no framework code to directly exploit or prohibit multiple
paths to the same disk, whether via Fibre Channel or SCSI.
Myself, I just need
At 9:51 PM -0800 2000/3/28, Matthew Jacob wrote:
What's harder is *how* to use it. There are no particular hooks in FFS to
handle the multiple paths simultaneously with any coherency (for performance
reasons, should you want to do so and could prove that it'd be worthwhile),
nor are
Hi
Who and when should update/fix subj. ?
Our parliament decided that estonia does not change to DST
anymore and forgot to mention it to MS and other OS
manufacturers :)
so info for Europe/Tallinn is wrong and our little state is full of
computers with wrong time :(
Help!
_
Brian Somers wrote:
Ah, ok. This is incoming data that's being ignored by ppp - maybe
because you've got ``nat deny_incoming yes'' configured ?
Yes, I have ``nat deny_incoming yes''. Thanks for explaining.
Maybe it would be worth to add more meaningful warning message like "Dropped
On Tue, 28 Mar 2000, Matthew Dillon wrote:
I found a couple of minor nits, but only one real bug. In i386/swtch.s
I forgot to change out a WANT_RESCHED for AST_RESCHED:
sw1a:
call_chooseproc /* trash ecx, edx, ret eax*/
testl %eax,%eax
Seems to be 100% now - I'm busy throwing a
make -j 8 buildworld
and a make -j 4 on the kernel,
plus taring my source tree and browsing the web a little to
see tha my console response is OK.
ALL LOOKS COOL
Thanks Matt!
-Original Message-
From: Matthew Dillon [mailto:[EMAIL
On Wed, 29 Mar 2000, Yoshinobu Inoue wrote:
sys/socket.h:
#ifdef _NO_NAME_SPACE_POLLUTION
#include machine/param.h
#else
#define _NO_NAME_SPACE_POLLUTION
#include machine/param.h
#undef _NO_NAME_SPACE_POLLUTION
#endif
I like this for a quick fix. Only define
Has anyone commited any changes to /usr/src/Makefile to fix the following
problem in make buildworld:-
=== lib/libipsec
make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libl.a. Stop
Is it worth manually removing this target from the Makefile?
--
Blair Sutton
Systems Administrator
* Jordan K. Hubbard ([EMAIL PROTECTED]) [000329 02:34]:
Temporarily down; "engineers are working on the problem." :)
Does anyone have a semi-recent 3.4-STABLE snapshot available for public
consumption ? The latest I have lying around is 2303.
Thanks.
Is this a transient situation, or
: I found a couple of minor nits, but only one real bug. In i386/swtch.s
: I forgot to change out a WANT_RESCHED for AST_RESCHED:
:
: sw1a:
: call_chooseproc /* trash ecx, edx, ret eax*/
: testl %eax,%eax
: CROSSJUMP(je, _idle, jne)
KAMIL MUHD wrote:
Hi everyone...
I got this error evrytime I try to make world no matter how often I
cvsup'ed. I don't know what it is, what is Error code 2 anyway? Is my cc
version is out-of-date? I'm using the GNU gcc-2.95.1. My box is running on
4.0-CURRENT. Any idea? Is it because
On Wed, 29 Mar 2000, Matthew Dillon wrote:
:Gas notices the problem for "movl $-FOO,%eax":
:z.s: Assembler messages:
:z.s:1: Error: Negative of non-absolute symbol FOO
:Similarly for the a.out case. Complementation is equivalent to negation
:on 2's complement machines, so gas
Meaning no offense, but I can't think of a single good reason to write a
device driver for one of these cards. (Unless you're trying to do
pattern generation, and an 8255 is a terrible choice for that.) Worse
than that though, there's _no_ standard for these cards' implementation,
On 29-Mar-00 Lauri Laupmaa wrote:
Hi
Who and when should update/fix subj. ?
Our parliament decided that estonia does not change to DST
anymore and forgot to mention it to MS and other OS
manufacturers :)
so info for Europe/Tallinn is wrong and our little state is full of
computers
Does anyone know if these changes have been made?
Thank you!
Vladimir
From [EMAIL PROTECTED] Thu Mar 16 18:50:34 2000
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: rpc.lockd and XDR 64bit
Is it just me or is anybody else seeing this as well with today's
kernel/world?
Thanks,
--
Jos Backus _/ _/_/_/ "Reliability means never
_/ _/ _/ having to say you're sorry."
_/ _/_/_/
Hi
New system FreeBSD 5.0, cvsup today.
System reboot in message:
panic: worklist_remove: not on list
syncing disks... panic: softdep_lock: locking against myself
watch is wrong ?
Mariusz
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 10889+4270io
For the single-process (1-fork) case, syscall overhead improved
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock inward somewhat (even for syscalls that aren't MP safe),
the
:
:You should be able to remove the splhigh() from sigprocmask and run it
:MPSAFE. At least, I can't find a reason not to (and it works here, yes).
:
:\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
:
Tentitively it looks like we will indeed be able to make sigprocmask()
For the single-process (1-fork) case, syscall overhead improved
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock inward somewhat (even for syscalls that aren't MP safe),
Hi,
Today I did a "make rerelease" in "/usr/src/release" and the kernels
were rebuilt, but the binaries weren't. I think the following patch
to "release/Makefile" fixes the problem.
Basically, this patch does a "make world" for target "release"
for target "rerelease" if "/tmp/.world_done"
On Wed, 29 Mar 2000, Jos Backus wrote:
Is it just me or is anybody else seeing this as well with today's
kernel/world?
Phew, I thought I was going insane. Yes, ipfw fwd is definitely broken
as of at least 3/28/2000.
jlemon has found the problem and is working on a fix.
Thanks,
--
Jos
Hello,
I am not sure if this exactly on topic,
but this is how I boot freeBSD partition that is installed
beyond cyl 1024
I use GRUB boot loader that understands LBA (www.gnu.org/grub)
Once GRUB boots from a floppy, go to GRUB's command prompt and
do the following:
root (hd0,3,a) # or
Hi,
At 01:14 -0800 29/3/00, Matthew Dillon wrote:
[...]
I am hoping that this will also fix Bob Bishop's reported boot lockup.
It does!
When I get a minute I'll rerun that timing test...
--
Bob Bishop (0118) 977 4017 international code +44 118
[EMAIL PROTECTED]fax
On Wed, 29 Mar 2000, Matthew Dillon wrote:
time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
4696.987u 1502.278s
In article local.mail.freebsd-current/[EMAIL PROTECTED]
you write:
Is it just me or is anybody else seeing this as well with today's
kernel/world?
Yes, green just brought this to my attention. I've committed a fix
that should solve the problem.
--
Jonathan
To Unsubscribe: send mail to [EMAIL
As at cvs-cur.6207
--
The views expressed above are not those of PGS Tensor.
"We've heard that a million monkeys at a million keyboards could produce
the Complete Works of Shakespeare; now, thanks to the Internet, we know
this is not true."Robert Wilensky, University
On Wed, 29 Mar 2000, Matthew Dillon wrote:
time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
4696.987u 1502.278s
* Mike Smith [EMAIL PROTECTED] [000329 17:03] wrote:
For the single-process (1-fork) case, syscall overhead improved
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock
Brian Fundakowski Feldman wrote:
Did you try "call setdumpdev(0xf00)" with the proper show disk/ yet?
It's probably worth documenting the procedure even if it will be later
be replaced with a loader functionality... however, we should still
support the way it is now for people who want to
On Wed, 29 Mar 2000 19:25:29 -0800, Alfred Perlstein [EMAIL PROTECTED] said:
What do you guys think about that? Am I totally missing something
that makes the Linux way right/ok? (no locking on a 64bit struct)
Generally, it's better to design an optimistic or non-blocking
algorithm rather
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
order that nothing has changed. For example, to read a
structure containing hours, minutes, seconds:
for (;;)
{ h =
Actually, I spoke too soon. That's an algorithm used
to read deglitched hardware counters or ISR counters on
a single processor machine. But it may not be safe in
a multiprocessor environment where one CPU can read the
structure while a second CPU can be updating the
structure. There may be a
* Allen Pulsifer [EMAIL PROTECTED] [000329 21:05] wrote:
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
order that nothing has changed. For example, to read a
structure
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
* Allen Pulsifer [EMAIL PROTECTED] [000329 21:05] wrote:
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
Chris,
Sorry, I didn't know what was needed. I have also located the
problem (well, sort of). I built a GENERIC kernel, and then made
incremental changes until I had my old working kernel back. The problem
appears to be in the code for one of the following options:
* Jonathan Lemon [EMAIL PROTECTED] [000329 21:52] wrote:
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
I'm aware of this, the problem is that tz may move in either
direction. Hence my question about using sizes that are machine
atomic for read/write. :)
I've got
: time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
:
: 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
:
: time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
:
: 4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k
: 4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 10889+4270io 1779pf+0w
:
:Can I ask why is there a huge difference in the number of io (251k vs 4k)?
:What is so different between 4.0 and 5.0 that causes this?
:
:--
:
:Andy Farkas
Ha! I found it. Kirk gets the credit ---
Matthew Dillon wrote:
: time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
:
: 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615p
f+0w
:
: time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
:
: 4696.987u 1502.278s
Yesterday I was looking at how Linux handles the gettimeofday stuff
without locking thier sys_tz variable, well it seems they don't care
or I'm missing something important.
They just don't lock it, not that settimeofday will be called all that
often but it leaves me wondering what we can
In message [EMAIL PROTECTED], Mike Smith writes:
Yesterday I was looking at how Linux handles the gettimeofday stuff
without locking thier sys_tz variable, well it seems they don't care
or I'm missing something important.
They just don't lock it, not that settimeofday will be called all
-On [2329 02:15], Brian Fundakowski Feldman ([EMAIL PROTECTED]) wrote:
On Tue, 28 Mar 2000, Jeroen Ruigrok van der Werven wrote:
Did you try "call setdumpdev(0xf00)" with the proper show disk/ yet?
I tried:
db show disk/ad0s1b
0xc0b65880
bd write dumpdev 0xc0b658
51 matches
Mail list logo
