Re: GPS heads up

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:The SA can be averaged out, but you need to have another source of
>:time as well as GPS.  GPS alone will give you a grid square you are
>:in, but the nature of the pseudorandom noise is such that you don't
>:get a nice sine wave (collapsing for a moment to 1 dimention).  It is
>:much more distorted than that.
>:
>:Warner
>
> SA can *not* be averaged out.  People... SA is NOT NOISE.

SA *can* be averaged out, it has an average value of zero.  But it
takes several days or even weeks to get into the centimeter range,
depending on the satelite coverage where you are.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: MAKE MONEY FOR DOING NOTHING!!!!!!!!! PROMISE

[Jim Roland]

I don't mean to be demeaning, but can we all please not comment and run an
off-topic thread on something that should be deleted and ignored?  Please
stick to the list topic and leave spam alone, ignoring it like it should
be.

Simply report to the abuse mail addresses of the originating or carrying
ISPs, and delete the message.  


-=>Jim Roland
 
"Never settle with words what you can settle with a flamethrower."
--Anonymous
 

On Wed, 3 May 2000, David Benfell wrote:

> Date: Wed, 3 May 2000 14:20:35 -0700
> From: David Benfell <[EMAIL PROTECTED]>
> To: Dave West <[EMAIL PROTECTED]>
> Cc: Dhar <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED]
> Subject: Re: MAKE MONEY FOR DOING NOTHING!  PROMISE
> 
> On Wed, May 03, 2000 at 06:27:32PM +0100, Dave West wrote:
> > 
> > Actually it's better to just tell AllAdvantage.com and they will cancell
> > his account and bar him for life.
> > 
> So he can use another false name with another ISP.
> 
> -- 
> David Benfell
> ICQ 59438240 [e-mail first for access]
> ---
> "I am ready to meet my Maker.  Whether my Maker is prepared for the
> great ordeal of meeting me is another matter."
> -- Winston Churchill
>   [from fortune]
> 
>
> --------------------------------
>  to unsubscribe email "unsubscribe linux-admin" to [EMAIL PROTECTED]
>  See the linux-admin FAQ: http://www.kalug.lug.net/linux-admin-FAQ/
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Matthew Dillon]

:If you watch a system that is measuring this, you'll see that one
:second you are 65ns slow.  The next you are 64 ns slow, the next you
:are 68ns slow the next you are 65ns slow.  Come back an hour later and
:you'll find you are 135ns fast, then 130ns fast, then 140ns fast.
:After lunch it might be 12ns slow, then 10 ns slow then 8ns fast.
:Just before leavinvg for the day, you might be back up to 165ns fast.
:All of this is relative to an independent, high accuracy time source
:like an atomic clock.  That's why you can't take the average of 20
:readings in a row.  You'll just be factoring out a very small part of
:the SA sequence.  There's some jitter in the SA, but its biggest
:impact is the long period error that it introduced.
:
:Put another way, it takes days for the drunk to complete his random
:walk. :-)  Averaging over a few minutes will only tell you where the
:drunk is at the moment and not his true center.
:
:Which is what I think Matt is trying to say.
:
:Warner

Yes, pretty much.  The timing information is what makes GPS
work.  Since you are moving, you expect the timing information
to change (that's how you detect the fact that you are moving!),
so averaging it wouldn't help much even if you had your own 
personal atomic clock.

SA modifies *each* satellite's timing information independantly,
in a way that moves the *entire* volume of space calculated
by the GPS unit rather then simply stretching it (which is what
random noise would do).If it simply stretched it the GPS unit
would be able to calculate the center and thus provide an accurate fix.
But it doesn't, so the GPS unit can't.

Since the whole volume moves the GPS unit believes you are moving even
if you are standing still.  

The correction algorithm only works if there is a second GPS unit 
at a fixed point (i.e. NOT moving).  This second unit makes the
assumption that it is standing still and broadcasts the 'error'
it sees from the satellites.  The first GPS unit receives the
error information for each satellite from the second unit and
is able to correct the timing information it sees from each
satellite before applying its algorithms.

It's ironic, but GPS wasn't accurate enough for marine use so
the Coast Guard set up coastal beacon sites to transmit the
corrections.  Thus marine GPS units with beacon receivers
could correct for the error and produce much more accurate results.
Just about the entire coast of the U.S. has beacon transmitters.
So ever since GPS was first deployed for civvy use, one government
agency has been broadcasting corrections to the intentional errors
introduced by another government agency.  (I expect the coastal sites
will be turned down now that they are no longer needed).

There is a way to get extremely accurate GPS measurements with or 
without SA and that is to detect phase changes in the incoming signal.  
This only works if you are not moving or moving very slowly (for example, 
to measure plate movement for earthquake and seismic purposes).  It
does not help you calculate your position, it simply helps you 
calculate tiny changes in your position.  It would not be useful to 
a moving object (the noise causes you to lose track of 360 degree
phase changes), but it works great for really slow slow movement.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Warner Losh]

In message <[EMAIL PROTECTED]> Matthew Dillon writes:
:  SA can *not* be averaged out.  People... SA is NOT NOISE.  I will
:  repeat that.  SA is NOT NOISE.  SA is an intentional error 
:  introduced by the satellites that looks like a drunk walking around
:  the town.  It takes a lot of readings over a long period of time
:  (read: at least a couple of days) for any sort of averaging to
:  yield a worthwhile result.

What I was trying to say was that SA is caused by the satellites
reporting times that have a small offset added to or subtracted from
them.  Knowing where you are requires that you know what time it is to
a very precise degree.  Once you know what time it is, you can know
where you are.  That's why SA injects a pseudo random noise factor
into the timing information that the satellites report.  If you have
an atomic clock and a GPS clock, you can measure the offset between
the two fairly easily and graph the results.  That is what I mean when
I say you can compensate for the SA if you have a good atomic clock.

If you watch a system that is measuring this, you'll see that one
second you are 65ns slow.  The next you are 64 ns slow, the next you
are 68ns slow the next you are 65ns slow.  Come back an hour later and
you'll find you are 135ns fast, then 130ns fast, then 140ns fast.
After lunch it might be 12ns slow, then 10 ns slow then 8ns fast.
Just before leavinvg for the day, you might be back up to 165ns fast.
All of this is relative to an independent, high accuracy time source
like an atomic clock.  That's why you can't take the average of 20
readings in a row.  You'll just be factoring out a very small part of
the SA sequence.  There's some jitter in the SA, but its biggest
impact is the long period error that it introduced.

Put another way, it takes days for the drunk to complete his random
walk. :-)  Averaging over a few minutes will only tell you where the
drunk is at the moment and not his true center.

Which is what I think Matt is trying to say.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Matthew Dillon]

:#14 0xc0227c57 in trap (frame={tf_fs = 24, tf_es = -675545072, 
:  tf_ds = -1058602992, tf_edi = -1059013248, tf_esi = 28, 
:  tf_ebp = -8360071, tf_isp = -8360160, tf_ebx = -1058670080, 
:  tf_edx = -1059008325, tf_ecx = 0, tf_eax = -1059168256, tf_trapno = 12, 
:  tf_err = 2, tf_eip = -1072225173, tf_cs = 8, tf_eflags = 66178, 
:  tf_esp = -1071902645, tf_ss = -1059168256}) at ../../i386/i386/trap.c:423
:#15 0xc017246b in bpfioctl (dev=0xc0c0de60, cmd=12639866, 
:addr=0xff400800 , flags=16777215, 
:p=0xacc0de60) at ../../net/bpf.c:683
:#16 0xc01c19 in ?? ()
:cannot read proc at 0
:(kgdb)
:
:
:Is this more help?  (shame I don't actually understand it..)
:
:Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net

A hah!  Yes, I think I see what is happening.

The kernel ioctl() system call is using a stack based
char buffer to hold the temporary data, and this buffer is not 
aligned.

Please try the following patch.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>
Index: kern/sys_generic.c
===
RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v
retrieving revision 1.55
diff -u -r1.55 sys_generic.c
--- kern/sys_generic.c  2000/02/20 13:36:26 1.55
+++ kern/sys_generic.c  2000/05/04 03:18:02
@@ -496,7 +496,10 @@
caddr_t data, memp;
int tmp;
 #define STK_PARAMS 128
-   char stkbuf[STK_PARAMS];
+   union {
+   char stkbuf[STK_PARAMS];
+   long align;
+   } ubuf;
 
fdp = p->p_fd;
if ((u_int)uap->fd >= fdp->fd_nfiles ||
@@ -523,11 +526,11 @@
if (size > IOCPARM_MAX)
return (ENOTTY);
memp = NULL;
-   if (size > sizeof (stkbuf)) {
+   if (size > sizeof (ubuf.stkbuf)) {
memp = (caddr_t)malloc((u_long)size, M_IOCTLOPS, M_WAITOK);
data = memp;
} else
-   data = stkbuf;
+   data = ubuf.stkbuf;
if (com&IOC_IN) {
if (size) {
error = copyin(uap->data, data, (u_int)size);


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Matthew Dillon]

:The SA can be averaged out, but you need to have another source of
:time as well as GPS.  GPS alone will give you a grid square you are
:in, but the nature of the pseudorandom noise is such that you don't
:get a nice sine wave (collapsing for a moment to 1 dimention).  It is
:much more distorted than that.
:
:Warner

 SA can *not* be averaged out.  People... SA is NOT NOISE.  I will
 repeat that.  SA is NOT NOISE.  SA is an intentional error 
 introduced by the satellites that looks like a drunk walking around
 the town.  It takes a lot of readings over a long period of time
 (read: at least a couple of days) for any sort of averaging to
 yield a worthwhile result.

 I know this for a fact, because NextBus has a dozen or two busses
 in SF with GPS units on them reporting their position on two minute
 intervals and they've built up over a years worth of data.

 The only way to factor out SA is to have a secondary transmitter
 at a fixed location which transmits the error coming from EACH
 satellite to the GPS units, which then correct each satellite's
 signal before running it through the positional algorithms.

 With SA on, your GPS fix winds up moving at around a mile an hour
 (the rate changes as well) in odd directions.  It is *NOT* random.  
 You can't average it out and expect to get the real position 'in the 
 middle'.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Howard Leadmon]

 Old trace deleted.. :)

> >> Interesting.  That explains the splbio, anyway.  The real problem is
> >> at frame 15, in bpfioctl, but the system trapped while trying to sync
> >> before dumping.
> >>
> >> As mentioned in the handbook, you need symbols in your kernel in order
> >> to find out any more information.  Build a kernel with the -g option
> >> and try again.
> >
> >  Umm, the kernel was built with the -g option, as I knew I needed to be
> > able to debug it when it crashed.  I looked at the handbook, but I don't
> > personally see a clear direction as to where I need to go from here.  If
> > you can tell me what to look for I am more than willing to go digging..
> 
> Ah, then you're in better shape.  I assume you installed the stripped
> version of the kernel (it's default, despite my protests), so that's
> what savecore saved for you.  You'll have the original still in
> /usr/src/sys/compile//kernel.debug.  Copy it to /var/crash,
> overwriting your kernel.2 or whatever, and the backtrace will be much
> more verbose.
> 
> Greg


OK, I did as you requested, and here is the info I got using the kernel.debug
file found in the compile directory.  I do agree, it would have made sense to
copy the debugging kernel vs the stripped one.. 


# gdb -k kernel.0 vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD 3112960
initial pcb at 2815e0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0002; cpuid = 0; lapic.id = 
fault virtual address   = 0x261e930
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc017246b
stack pointer   = 0x10:0xff806f34
frame pointer   = 0x10:0xff806f79
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = net  <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0002; cpuid = 0; lapic.id = 
boot() called on cpu#0

syncing disks... 

Fatal trap 12: page fault while in kernel mode
mp_lock = 0003; cpuid = 0; lapic.id = 
fault virtual address   = 0x30
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01cdca5
stack pointer   = 0x10:0xff806d5c
frame pointer   = 0x10:0xff806d60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = net bio cam  <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0003; cpuid = 0; lapic.id = 
boot() called on cpu#0
Uptime: 4m48s

dumping to dev #ad/0x20001, offset 128
dump ata0: resetting devices .. done
383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 
362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 
341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 
320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 
299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 
278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 
257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 
236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 
215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 
194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 
173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 
152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 
131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 
85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 
56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 
27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---
#0  boot (howto=260) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
(kgdb) back 
#0  boot (howto=260) at ../../kern/kern_shutdown.c:304
#1  0xc013af94 in poweroff_wait (junk=0xc025922f, howto=0)
at ../../kern/kern_shutdown.c:554
#2  0xc02283c

Re: Debugging Kernel/System Crashes, can anyone help??

[Matthew Dillon]

I, for one, think that installing the stripped kernel is the correct
solution.  I often have several kernels lying around in / (e.g. a
kernel.bak along with the kernel and kernel.old the system maintains),
and my poor root partition would run out of space fairly quickly
if they all had symbols.

There's al earning curve to everything.  As things go, this
one isn't a big deal.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Warner Losh]

In message <[EMAIL PROTECTED]> Matthew Dillon writes:
: No, you can't just average several measurements w/ SA on and expect
: to get any improvement.  SA isn't just 'noise', it's like a 
: drunken walker.  All you get when you average several measurements
: is the location of the drunk.

The SA can be averaged out, but you need to have another source of
time as well as GPS.  GPS alone will give you a grid square you are
in, but the nature of the pseudorandom noise is such that you don't
get a nice sine wave (collapsing for a moment to 1 dimention).  It is
much more distorted than that.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: MAKE MONEY FOR DOING NOTHING!!!!!!!!! PROMISE

[David Benfell]

On Wed, May 03, 2000 at 06:27:32PM +0100, Dave West wrote:
> 
> Actually it's better to just tell AllAdvantage.com and they will cancell
> his account and bar him for life.
> 
So he can use another false name with another ISP.

-- 
David Benfell
ICQ 59438240 [e-mail first for access]
---
"I am ready to meet my Maker.  Whether my Maker is prepared for the
great ordeal of meeting me is another matter."
-- Winston Churchill
[from fortune]

 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Greg Lehey]

On Wednesday,  3 May 2000 at 18:59:36 -0700, Jan Koum wrote:
> On Thu, May 04, 2000 at 11:11:36AM +0930, Greg Lehey <[EMAIL PROTECTED]> wrote:
>>
>> Ah, then you're in better shape.  I assume you installed the stripped
>> version of the kernel (it's default, despite my protests)
>
> what are some pro's and con's in this case?

I assume you had intended to copy the others, so I've put them back.

Pro having only one (debug) kernel:

1.  If space is tight, you can save overall space.  You need to keep
the kernel.debug somewhere.  If you make it the boot kernel, you
use a total of 10 MB.  Otherwise, even if you make clean, you end
up having a 10 MB kernel.debug somewhere and a 2.5 MB kernel in
the root file system.
2.  savecore always saves the correct kernel.  If you have to move it
manually from wherever you keep it, there's a big chance for
making mistakes.  I've done it often enough.

Con:

1.  If you're short of space on the root file system, the additional
7.5 MB can hurt.  You can plan against this, of course, by
installing larger root file systems.

There's a separate issue about whether to build kernels with debug
symbols by default.  That takes a lot more space (30 MB as compared to
about 8).  But if you have a debug kernel, I don't see any reason to
install a stripped version.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Greg Lehey]

On Wednesday,  3 May 2000 at 21:24:47 -0400, Howard Leadmon wrote:
>
>>> OK, well as I don't remember what options had been in what kernel
>>> from the old crashes, I just setup the machine to generate more
>>> crash dumps and sure enough it was willing to give me one
>>> quickly.. :)
>>>
>>> Here is a backtrace done on the dump I got only a few minutes ago,
>>> also please note that currently I am using a DEC based network card
>>> instead of the EEpro adapter as I had both sitting around.  If it
>>> would be better to try and get the dumps with the EEpro I am sure it
>>> can be arranged. Also note that I am currently running SMP, but did
>>> remove one CPU and built a non-SMP kernel to see what happened, and
>>> still the machine dies..
>>
>>> ---
>>> #0  0xc013abd1 in boot ()
>>> (kgdb) back
>>> #0  0xc013abd1 in boot ()
>>> #1  0xc013af94 in poweroff_wait ()
>>> #2  0xc02283cc in trap_fatal ()
>>> #3  0xc022805d in trap_pfault ()
>>> #4  0xc0227c57 in trap ()
>>> #5  0xc01cdca5 in acquire_lock ()
>>> #6  0xc01d2f7c in softdep_count_dependencies ()
>>> #7  0xc01d624c in ffs_fsync ()
>>> #8  0xc01d4d66 in ffs_sync ()
>>> #9  0xc01673ef in sync ()
>>> #10 0xc013a9b3 in boot ()
>>> #11 0xc013af94 in poweroff_wait ()
>>> #12 0xc02283cc in trap_fatal ()
>>> #13 0xc022805d in trap_pfault ()
>>> #14 0xc0227c57 in trap ()
>>> #15 0xc017246b in bpfioctl ()
>>> #16 0xc01c19 in ?? ()
>>> cannot read proc at 0
>>> (kgdb)
>>
>> Interesting.  That explains the splbio, anyway.  The real problem is
>> at frame 15, in bpfioctl, but the system trapped while trying to sync
>> before dumping.
>>
>> As mentioned in the handbook, you need symbols in your kernel in order
>> to find out any more information.  Build a kernel with the -g option
>> and try again.
>
>  Umm, the kernel was built with the -g option, as I knew I needed to be
> able to debug it when it crashed.  I looked at the handbook, but I don't
> personally see a clear direction as to where I need to go from here.  If
> you can tell me what to look for I am more than willing to go digging..

Ah, then you're in better shape.  I assume you installed the stripped
version of the kernel (it's default, despite my protests), so that's
what savecore saved for you.  You'll have the original still in
/usr/src/sys/compile//kernel.debug.  Copy it to /var/crash,
overwriting your kernel.2 or whatever, and the backtrace will be much
more verbose.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Howard Leadmon]

> > OK, well as I don't remember what options had been in what kernel
> > from the old crashes, I just setup the machine to generate more
> > crash dumps and sure enough it was willing to give me one
> > quickly.. :)
> >
> > Here is a backtrace done on the dump I got only a few minutes ago,
> > also please note that currently I am using a DEC based network card
> > instead of the EEpro adapter as I had both sitting around.  If it
> > would be better to try and get the dumps with the EEpro I am sure it
> > can be arranged. Also note that I am currently running SMP, but did
> > remove one CPU and built a non-SMP kernel to see what happened, and
> > still the machine dies..
> 
> > ---
> > #0  0xc013abd1 in boot ()
> > (kgdb) back
> > #0  0xc013abd1 in boot ()
> > #1  0xc013af94 in poweroff_wait ()
> > #2  0xc02283cc in trap_fatal ()
> > #3  0xc022805d in trap_pfault ()
> > #4  0xc0227c57 in trap ()
> > #5  0xc01cdca5 in acquire_lock ()
> > #6  0xc01d2f7c in softdep_count_dependencies ()
> > #7  0xc01d624c in ffs_fsync ()
> > #8  0xc01d4d66 in ffs_sync ()
> > #9  0xc01673ef in sync ()
> > #10 0xc013a9b3 in boot ()
> > #11 0xc013af94 in poweroff_wait ()
> > #12 0xc02283cc in trap_fatal ()
> > #13 0xc022805d in trap_pfault ()
> > #14 0xc0227c57 in trap ()
> > #15 0xc017246b in bpfioctl ()
> > #16 0xc01c19 in ?? ()
> > cannot read proc at 0
> > (kgdb)
> 
> Interesting.  That explains the splbio, anyway.  The real problem is
> at frame 15, in bpfioctl, but the system trapped while trying to sync
> before dumping.
> 
> As mentioned in the handbook, you need symbols in your kernel in order
> to find out any more information.  Build a kernel with the -g option
> and try again.
> 
> Greg


 Umm, the kernel was built with the -g option, as I knew I needed to be
able to debug it when it crashed.  I looked at the handbook, but I don't
personally see a clear direction as to where I need to go from here.  If
you can tell me what to look for I am more than willing to go digging..



---
Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Upgrade from 3.4 to 4.0 with ida driver

[Matthew N. Dodd]

On Wed, 3 May 2000, Christopher T. Griffiths wrote:
> Would you mind letting me know when this is done? I appreciate the
> response.

jlemon has committed the fix.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

solicit hardware and/or testers for newbusified drivers

[Jake Burkholder]

I'm working on converting some of the older drivers to newbus and
need hardware or testers to verify that this stuff still works.

If you have any of the hardware listed below and are willing to
either loan it to me or be a guinea pig, please let me know.
I have patches for some of them on my web page: http://io.yi.org

These compile with LINT and a kernel with no compat shims; they should
apply cleanly to a recent -current.  I've booted a kernel with all these
drivers compiled in to verify they were correctly not detected and didn't
panic my machine.

If you use other drivers that still require compatibility shims you'll
have to remove the entries for the drivers you are patching from
sys/i386/isa/isa_compat.h or I believe the kernel will not link.
This applies to LINT.

Hardware or Testers Needed:

ctx:Cortex-I frame grabber.
spigot: Creative Labs Video Spigot video-acquisition board.
meteor: Matrox Meteor video capture board.
asc:GI1904-based hand scanners, e.g. the Trust Amiscan Grey.
gsc:Genius GS-4500 hand scanner.
el: 3Com 3C501 ethernet card.
le: Digital Equipment EtherWorks 2 and EtherWorks 3 (DEPCA, DE100,
DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422).
alpm:   Acer Aladdin-IV/V/Pro2 based motherboard.

Especially Wierd/Don't Know What To Do About:

gp: National Instruments AT-GPIB and AT-GPIB/TNT board.
labpc:  National Instrument's Lab-PC and Lab-PC+.
loran:  Loran Receiver. (phk?)
xrpu:   HOT1 Xilinx 6200 FPGA card.

Thank you

Jake



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Volanomark numbers for FreeBSD

[Arun Sharma]

Numbers for JDK-1.1.8 (ignore the version below - it's the client version)

java.vendor= Sun Microsystems Inc.
java.vendor.url= http://java.sun.com/
java.version   = 1.2.2
java.class.version = 46.0
java.compiler  = OpenJIT
os.name= FreeBSD
os.version = 4.0-STABLE
os.arch= i386

VolanoMark version = 2.1.2
Messages sent  = 2
Messages received  = 38
Total messages = 40
Elapsed time   = 691.682 seconds
Average throughput = 578 messages per second


Numbers for JDK-1.2.2:

java.vendor= Sun Microsystems Inc.
java.vendor.url= http://java.sun.com/
java.version   = 1.2.2
java.class.version = 46.0
java.compiler  = OpenJIT
os.name= FreeBSD
os.version = 4.0-STABLE
os.arch= i386

VolanoMark version = 2.1.2
Messages sent  = 2
Messages received  = 38
Total messages = 40
Elapsed time   = 366.007 seconds
Average throughput = 1093 messages per second

These numbers are on a Dual Celeron 366 MHz box with OpenJIT.
They're far better than the 173 that we're seeing at:

http://www.volano.com/report.html

I observed that vmstat showed 50% system time when the benchmark
was running.  So some kernel optimizations might help this. Feel
free to trim -hackers if it is deemed irrelevant. The benchmark
basically does parallel socket I/O on a loop back device.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Greg Lehey]

On Wednesday,  3 May 2000 at 19:53:11 -0400, Howard Leadmon wrote:
>

> OK, well as I don't remember what options had been in what kernel
> from the old crashes, I just setup the machine to generate more
> crash dumps and sure enough it was willing to give me one
> quickly.. :)
>
> Here is a backtrace done on the dump I got only a few minutes ago,
> also please note that currently I am using a DEC based network card
> instead of the EEpro adapter as I had both sitting around.  If it
> would be better to try and get the dumps with the EEpro I am sure it
> can be arranged. Also note that I am currently running SMP, but did
> remove one CPU and built a non-SMP kernel to see what happened, and
> still the machine dies..

> ---
> #0  0xc013abd1 in boot ()
> (kgdb) back
> #0  0xc013abd1 in boot ()
> #1  0xc013af94 in poweroff_wait ()
> #2  0xc02283cc in trap_fatal ()
> #3  0xc022805d in trap_pfault ()
> #4  0xc0227c57 in trap ()
> #5  0xc01cdca5 in acquire_lock ()
> #6  0xc01d2f7c in softdep_count_dependencies ()
> #7  0xc01d624c in ffs_fsync ()
> #8  0xc01d4d66 in ffs_sync ()
> #9  0xc01673ef in sync ()
> #10 0xc013a9b3 in boot ()
> #11 0xc013af94 in poweroff_wait ()
> #12 0xc02283cc in trap_fatal ()
> #13 0xc022805d in trap_pfault ()
> #14 0xc0227c57 in trap ()
> #15 0xc017246b in bpfioctl ()
> #16 0xc01c19 in ?? ()
> cannot read proc at 0
> (kgdb)

Interesting.  That explains the splbio, anyway.  The real problem is
at frame 15, in bpfioctl, but the system trapped while trying to sync
before dumping.

As mentioned in the handbook, you need symbols in your kernel in order
to find out any more information.  Build a kernel with the -g option
and try again.

Greg

--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Howard Leadmon]

OK, well as I don't remember what options had been in what kernel from the
old crashes, I just setup the machine to generate more crash dumps and sure
enough it was willing to give me one quickly.. :)

Here is a backtrace done on the dump I got only a few minutes ago, also please
note that currently I am using a DEC based network card instead of the EEpro
adapter as I had both sitting around.  If it would be better to try and get
the dumps with the EEpro I am sure it can be arranged. Also note that I am
currently running SMP, but did remove one CPU and built a non-SMP kernel to
see what happened, and still the machine dies..


Here is the gdb info:

# gdb -k kernel.0 vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
(no debugging symbols found)...
SMP 2 cpus
IdlePTD 3112960
initial pcb at 2815e0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0002; cpuid = 0; lapic.id = 
fault virtual address   = 0x261e930
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc017246b
stack pointer   = 0x10:0xff806f34
frame pointer   = 0x10:0xff806f79
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = net  <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0002; cpuid = 0; lapic.id = 
boot() called on cpu#0

syncing disks... 

Fatal trap 12: page fault while in kernel mode
mp_lock = 0003; cpuid = 0; lapic.id = 
fault virtual address   = 0x30
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01cdca5
stack pointer   = 0x10:0xff806d5c
frame pointer   = 0x10:0xff806d60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  = net bio cam  <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0003; cpuid = 0; lapic.id = 
boot() called on cpu#0
Uptime: 4m48s

dumping to dev #ad/0x20001, offset 128
dump ata0: resetting devices .. done
383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 
362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 
341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 
320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 
299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 
278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 
257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 
236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 
215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 
194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 
173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 
152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 
131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 
85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 
56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 
27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---
#0  0xc013abd1 in boot ()
(kgdb) back
#0  0xc013abd1 in boot ()
#1  0xc013af94 in poweroff_wait ()
#2  0xc02283cc in trap_fatal ()
#3  0xc022805d in trap_pfault ()
#4  0xc0227c57 in trap ()
#5  0xc01cdca5 in acquire_lock ()
#6  0xc01d2f7c in softdep_count_dependencies ()
#7  0xc01d624c in ffs_fsync ()
#8  0xc01d4d66 in ffs_sync ()
#9  0xc01673ef in sync ()
#10 0xc013a9b3 in boot ()
#11 0xc013af94 in poweroff_wait ()
#12 0xc02283cc in trap_fatal ()
#13 0xc022805d in trap_pfault ()
#14 0xc0227c57 in trap ()
#15 0xc017246b in bpfioctl ()
#16 0xc01c19 in ?? ()
cannot read proc at 0
(kgdb) 



> Judging by your original bug report, Howard, it seems likely that either
> the machine or the network the machine is sitting on is being attacked
> and the machine is running out of some resource (probably network mbufs).
> Increasing the N

Re: Debugging Kernel/System Crashes, can anyone help??

[Greg Lehey]

On Wednesday,  3 May 2000 at 10:24:36 -0700, Matthew Dillon wrote:
> Judging by your original bug report, Howard, it seems likely that either
> the machine or the network the machine is sitting on is being attacked
> and the machine is running out of some resource (probably network mbufs).
> Increasing the NMBCLUSTERS any more will probably not help.

How do you explain the splbio priority?

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Upgrade from 3.4 to 4.0 with ida driver

[Christopher T. Griffiths]

Excellent,

Would you mind letting me know when this is done? I appreciate the
response.

Thanks a whole bunch.

Chris

On Wed, 3 May 2000, Matthew N. Dodd wrote:

> On Wed, 3 May 2000, Christopher T. Griffiths wrote:
> > I sent this to freebsd-questions with no luck.  I am desperately
> > trying to figure out this problem.
> 
> I'll MFC the fix for this later this week.
> 
> > Christopher T. Griffiths
> > Engineering Department
> > Quansoo Group Inc.
> > [EMAIL PROTECTED]
> > Hello everyone,
> > 
> > I have been working for a good part of the day trying to get my compaq
> > system upgraded from 3.4 -stable to 4.0 -stable.
> > 
> > I am using the following hardware:
> > 
> > Compaq Proliant 1850R Server
> > Smart Array 3200 Controller
> > 1 Raid 1 array
> > 
> > I have been running 3.4 for several months on this system with zero
> > problems.
> > 
> > I have followed all of the Instructions in the Updating file and setup a
> > custom kernel configured to use the ata and ida drivers (attached).
> > 
> > There is only one problem:
> > 
> > I am getting the following on bootup when the kernel boots and tries to
> > change to the root device I get the following:
> > 
> > ta0-slave: ata_command: timeout waiting for intr
> > ata0-slave: identify failed
> > acd0: CDROM  at ata0-master using PIO4
> > no devsw (majdev=0 bootdev=0xa020)
> > Mounting root from ufs:/dev/idad0a
> > no such device 'idad'
> > setrootbyname failed
> > ffs_mountroot: can't find rootvp
> > Root mount failed: 6
> > 
> > Manual root filesystem specification:
> >   :  Mount  using filesystem 
> >eg. ufs:/dev/da0s1a
> >   ?  List valid disk boot devices
> >  Abort manual input
> >   
> > mountroot> ufs:/dev/id0a /
> > Mounting root from ufs:/dev/id0a /
> > 
> > My /etc/fstab contains the following:
> > 
> > # DeviceMountpoint  FStype  Options Dump
> > Pass#
> > /dev/idad0b noneswapsw  0   0
> > /dev/idad0a /   ufs rw  1   1
> > /dev/idad0f /usrufs rw  2   2
> > /dev/idad0e /varufs rw  2   2
> > proc/proc   procfs  rw  0   0
> > 
> > 
> > I have tried rebuilding the bootloader but no luck.
> > 
> > It seems that when I imput /dev/id0a into mountroot prompt it then mounts
> > root and changes over to /dev/idad0a which is in my fstab.
> > 
> > The funny thing is that there is no /dev/id0a in /dev and it will not
> > allow me to build it either.
> > 
> > I also posted a much more crazy post earlier but have since fixed most of
> > the problems except this one.
> > 
> > Any help would be appreciated.
> > 
> > Thanks
> > 
> > Chris
> > ---
> > Christopher T. Griffiths
> > Engineering Department
> > Quansoo Group Inc.
> > [EMAIL PROTECTED]
> > 
> 
> -- 
> | Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
> | [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
> | http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |
> 
> 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Matthew Dillon]

:Even with SA, much more accurate numbers could be obtained by averaging
:several measurements.  I think that the speed at which the earth's
:plates move is slow enough to get a good average measurement (except
:during an earthquake, of course!).
:
:-brian
:
:-- 
:Brian O'Shea

No, you can't just average several measurements w/ SA on and expect
to get any improvement.  SA isn't just 'noise', it's like a 
drunken walker.  All you get when you average several measurements
is the location of the drunk.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Marc Nicholas]

Acool :-)

On Wed, 3 May 2000, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> Marc 
>Nicholas writes:
> : Isn't that the idea behind Differential-GPS?
> 
> Not quite.  The Differential GPS has GPS receievers at locations that
> have been surveyed down to the millimeter.  The DGPS software then
> calculates the offset from the current GPS signal and sends that
> information to the DGPS clients.
> 
> Warner
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Warner Losh]

In message <[EMAIL PROTECTED]> Marc 
Nicholas writes:
: Isn't that the idea behind Differential-GPS?

Not quite.  The Differential GPS has GPS receievers at locations that
have been surveyed down to the millimeter.  The DGPS software then
calculates the offset from the current GPS signal and sends that
information to the DGPS clients.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Marc Nicholas]

On Wed, 3 May 2000, Brian O'Shea wrote:

> Even with SA, much more accurate numbers could be obtained by averaging
> several measurements.  I think that the speed at which the earth's
> plates move is slow enough to get a good average measurement (except
> during an earthquake, of course!).

Isn't that the idea behind Differential-GPS?


-marc



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Brian O'Shea]

On Wed, May 03, 2000 at 10:15:28PM +0200, Alexander Langer wrote:
> Thus spake Brooks Davis ([EMAIL PROTECTED]):
> 
> > feature.  He mounts them on buildings around SoCal with dataloggers to
> > determine building movement due to earthquakes and general plate
> > movement.
> 
> 2-3 mm is exact enough for this?

Even with SA, much more accurate numbers could be obtained by averaging
several measurements.  I think that the speed at which the earth's
plates move is slow enough to get a good average measurement (except
during an earthquake, of course!).

-brian

-- 
Brian O'Shea
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

What Matt is doing now & Opportunities with Backplane

[Matthew Dillon]

This is both a heads up and a, well, ok, and a solicitation.  I'll admit
it!

As many of you know I was a founder of BEST Internet, an ISP which was 
eventually sold to Verio at the end of 1998.  I've also been extremely 
active in the FreeBSD community.  Throughout 1999 I've been unwinding 
from the BEST experience and starting in late 1999 my brother Ben
and I began looking for a new startup opportunity... that is, an idea 
which we could build a company around.  For the last few years Ben 
had been a high muckity-muck at Macromedia doing business development 
for their Flash! and other internet-related products.  Between us 
we believe we have the necessary experience to build a new company.

We came up with an idea and for the last several months have been working
on funding.  We have started hiring.  The idea may seem mundane at first,
but believe me it should be quite an interesting job from a programmer's
perspective.  In a nutshell we will be doing a business-to-business
ASP-based billing solution.  That is, handling the billing operations
for client companies.  While we expect competition to grow in this area
as time progresses much of the current potential competition is using
a different focus then the approach we intend to take, and we think we 
will do well in this area.  I have plenty of experience in this area 
as I was the one who wrote the provisioning and billing system for BEST.
The idea here is to create an ASP (i.e. web-based) solution that caters
to small and mid-sized companies - other ASPs, ISPs, or any company
which has a regular customer base.

As I am sure many Bay Area technology startups are doing, we are at the
point now where we need to flesh-out our engineering team.  Programmers
are the most critical part of the team and at the moment we have two
(Me, and a guy named Matt Titus) ((pps if your name doesn't begin with
'Matt' it will not be held against you!).  While I consider myself a 
very good programmer, this project is just a tad bigger then two people
can handle.

So we are starting to look for C programmers to help build the support
libraries, CGI infrastructure for the web servers, database, and backend
programs (e.g. such as generating and printing invoices).

We will be using FreeBSD-4.x as the base platform for both the web and
database servers, backend servers, and so forth.

We will be based in EMERYVILLE (in between Berkeley and Oakland, just
over the Bay Bridge from SF) and any interested parties would need to
commute to Emeryville daily.  Medium-level pay, good options, medical
benefits, and (I hope!) a good work environment are part of the deal.
We are looking to fill several full-time programming slots.

If anyone here is interested in exploring this opportunity, please
contact:

[EMAIL PROTECTED]

(which will get to my brother Ben, who is handling the search for new 
employees).  If you have any technical questions, email me directly
( [EMAIL PROTECTED] ).  If you want to scream about me posting a
solicitation to -hackers, then scream at me ( [EMAIL PROTECTED] ).

We are also looking for a good web page designer -- taking one look at
what used to be my personal home page ( www.backplane.com ) should make
that fairly obvious :-).

This is a formal, professional employment opportunity -- a true 
'silicon valley' startup (except not based in silicon valley).

Thanks Everyone!

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Upgrade from 3.4 to 4.0 with ida driver

[Matthew N. Dodd]

On Wed, 3 May 2000, Christopher T. Griffiths wrote:
> I sent this to freebsd-questions with no luck.  I am desperately
> trying to figure out this problem.

I'll MFC the fix for this later this week.

> Christopher T. Griffiths  
> Engineering Department
> Quansoo Group Inc.
> [EMAIL PROTECTED]
> Hello everyone,
> 
> I have been working for a good part of the day trying to get my compaq
> system upgraded from 3.4 -stable to 4.0 -stable.
> 
> I am using the following hardware:
> 
> Compaq Proliant 1850R Server
> Smart Array 3200 Controller
> 1 Raid 1 array
> 
> I have been running 3.4 for several months on this system with zero
> problems.
> 
> I have followed all of the Instructions in the Updating file and setup a
> custom kernel configured to use the ata and ida drivers (attached).
> 
> There is only one problem:
> 
> I am getting the following on bootup when the kernel boots and tries to
> change to the root device I get the following:
> 
> ta0-slave: ata_command: timeout waiting for intr
> ata0-slave: identify failed
> acd0: CDROM  at ata0-master using PIO4
> no devsw (majdev=0 bootdev=0xa020)
> Mounting root from ufs:/dev/idad0a
> no such device 'idad'
> setrootbyname failed
> ffs_mountroot: can't find rootvp
> Root mount failed: 6
> 
> Manual root filesystem specification:
>   :  Mount  using filesystem 
>eg. ufs:/dev/da0s1a
>   ?  List valid disk boot devices
>  Abort manual input
>   
> mountroot> ufs:/dev/id0a /
> Mounting root from ufs:/dev/id0a /
> 
> My /etc/fstab contains the following:
> 
> # DeviceMountpoint  FStype  Options Dump
> Pass#
> /dev/idad0b noneswapsw  0   0
> /dev/idad0a /   ufs rw  1   1
> /dev/idad0f /usrufs rw  2   2
> /dev/idad0e /varufs rw  2   2
> proc/proc   procfs  rw  0   0
> 
> 
> I have tried rebuilding the bootloader but no luck.
> 
> It seems that when I imput /dev/id0a into mountroot prompt it then mounts
> root and changes over to /dev/idad0a which is in my fstab.
> 
> The funny thing is that there is no /dev/id0a in /dev and it will not
> allow me to build it either.
> 
> I also posted a much more crazy post earlier but have since fixed most of
> the problems except this one.
> 
> Any help would be appreciated.
> 
> Thanks
> 
> Chris
> ---
> Christopher T. Griffiths  
> Engineering Department
> Quansoo Group Inc.
> [EMAIL PROTECTED]
> 

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Joerg Micheel]

Howard,

I'm facing the same problem. I am running 4.0-current / 4.0-stable
on a Dual-PIII-733, 1GB RAM, 2 Adaptec, 300GB disk. I have had
sudden crashes/reboots as bad as not even producing core dumps or
dropping into kernel debugger.

I had several guesses, one of which was the 64K block size on some
of the disks I use. This proved to be wrong as I had a crash 2 days
ago (again in UFS) from a chgrp -R across a large number of files
(around 2GB of small stuff). Another guess that it is SMP related
proved to be wrong when I compiled a uniprocessor kernel and the
problem did not go away, it just occured an order of magnitude
less frequently.

The error pattern has changed since, I do get core dumps again.
What is common to all of them is that they occur in UFS. My guess
is that there is some sort of locking problem or locking race, but
thats very vague. As for you, my knowlegde about the intrinsics of
the file system is very limited. I repeat my offer to make the crashes
I've got available to -hackers so they can have a more detailed look.

Joerg
-- 
Joerg B. MicheelEmail: <[EMAIL PROTECTED]>
Waikato Applied Network DynamicsPhone: +64 7 8384794
The University of Waikato, CompScience  Fax:   +64 7 8585095
Private Bag 3105Pager: +64 868 38222
Hamilton, New Zealand   Plan:  TINE and the DAG's


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unisys Patent vs Compress

[Matthew Jacob]

No, I'm afraid I can't quite agree. A major distinguishing feature of *BSD vs.
GPL'd systems is that they can ship unencumbered. The article in the URL does
not specifically show that *BSD, or products derived and containing, could
*not* be so encumbered.

So, yes, I'd still have some concerns.


On Wed, 3 May 2000, Warner Losh wrote:

> phk pointed me at
>   http://mordor.lpt.fi/doc/ncompress/copyright
> 
> which says that we're as safe as one can be.  So forget that I
> mentioned it.
> 
> Warner
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unisys Patent vs Compress

[Matthew Jacob]

Concern over LZW caused Legato to invent their own compression, so, I'd say,
yes, there's concern.


On Wed, 3 May 2000, Warner Losh wrote:

> It was my understanding that compress was covered by the unisys lzw
> patents.  Are there issues with including it in the tree?  Is there
> some license from Unisys that I'm unaware of that allows its use?  Are 
> we going to be a target of the Unisys legal department if we keep it
> in the tree.  They are going after web sites with GIF right now.  Is
> there anything that we need to worry about?
> 
> Warner
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Unisys Patent vs Compress

[Warner Losh]

phk pointed me at
http://mordor.lpt.fi/doc/ncompress/copyright

which says that we're as safe as one can be.  So forget that I
mentioned it.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Brooks Davis]

[Redirected to -chat where it belongs.]

On Wed, May 03, 2000 at 10:25:55PM +0200, Alexander Langer wrote:
> Thus spake David Holloway ([EMAIL PROTECTED]):
> 
> > You are associating one persons accuracy numbers with
> > someone elses experiments.
> 
> Ah. So what are the prof's accuracy numbers?

I don't actually know.  In any case, mm accuracy catches enough stuff to
be intresting.  The San Andreas fault moves about an inch a year IIRC.
You can see a little bit about the research at:

http://www.physics.hmc.edu/research/geo/gps_project.html

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Alexander Langer]

Thus spake David Holloway ([EMAIL PROTECTED]):

> You are associating one persons accuracy numbers with
> someone elses experiments.

Ah. So what are the prof's accuracy numbers?

Alex
-- 
I need a new ~/.sig.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Unisys Patent vs Compress

[Warner Losh]

It was my understanding that compress was covered by the unisys lzw
patents.  Are there issues with including it in the tree?  Is there
some license from Unisys that I'm unaware of that allows its use?  Are 
we going to be a target of the Unisys legal department if we keep it
in the tree.  They are going after web sites with GIF right now.  Is
there anything that we need to worry about?

Warner



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[David Holloway]

You are associating one persons accuracy numbers with
someone elses experiments.

In message <[EMAIL PROTECTED]>, Alexander Langer writ
es:
>Thus spake Brooks Davis ([EMAIL PROTECTED]):
>
>> feature.  He mounts them on buildings around SoCal with dataloggers to
>> determine building movement due to earthquakes and general plate
>> movement.
>
>2-3 mm is exact enough for this?
>
>Alex
>
>-- 
>I need a new ~/.sig.
>
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Alexander Langer]

Thus spake Brooks Davis ([EMAIL PROTECTED]):

> feature.  He mounts them on buildings around SoCal with dataloggers to
> determine building movement due to earthquakes and general plate
> movement.

2-3 mm is exact enough for this?

Alex

-- 
I need a new ~/.sig.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Brooks Davis]

On Wed, May 03, 2000 at 01:57:08PM -0600, Nate Williams wrote:
> My former employer (SRI) has done lots of research, and have gotten a
> receiver good to 1cm, but it takes about 24 hours for it to
> 'synchronize' to that accuracy.  With dual receivers, you can get 2-3 mm
> accuracy by comparing the wavelength offsets, but it's really, really,
> really expensive to build the hardware, and there's very little
> practical use for that kind of accuracy.

Actually, there's a physics professor any my old college does use that
feature.  He mounts them on buildings around SoCal with dataloggers to
determine building movement due to earthquakes and general plate
movement.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Nate Williams]

> > satellites sitting thousands of miles away in the sky.  It's even more
> > impressive to see the government do something right for a change!
> 
> It's much more idiotic that the government prevented it before.
> 
> That just means that military use is even better already, i.e. I just
> imagine they are at 1m or less already.

Actually, it's *REALLY* hard to get less than 1m accuracy using the
frequencies that are currently in use.  And, it's *really* easy to get
better than standard if you're willing to spend a bit of $$, so I
suspect the reason they turned it off is because anyone truly motivated
can get better accuracy, so the only losers with SA are the consumers.

My former employer (SRI) has done lots of research, and have gotten a
receiver good to 1cm, but it takes about 24 hours for it to
'synchronize' to that accuracy.  With dual receivers, you can get 2-3 mm
accuracy by comparing the wavelength offsets, but it's really, really,
really expensive to build the hardware, and there's very little
practical use for that kind of accuracy.



Nate


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Kent Stewart]

Poul-Henning Kamp wrote:
> 
> In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
> >Ok, this has nothing to do with FreeBSD, but I just had to post
> >something since nobody else has.
> >
> >By presidential order, on May 1 the error introduced into the GPS
> >system, called 'SA', was turned off.
> >
> >This means that your GPS receivers are now around 5-10 times more accurate
> >then they were before May 1st.
> 
> This has nothing to do with FreeBSD unless you count NTP servers,
> but actual data can be found on:
> 
> http://212.242.40.185/cgi-bin/ppsoffset.cgi
> 

It may not have anything to do with the OS FreeBSD but it has a lot to
do with what we can do easily and for a really modest price. The
techno-farms need to know where they are at in a field when they
record data. The old offset error made it such that the operator knew
where they were but the computer couldn't tell which field they were
in. A simple differential was expensive. Now, you don't have the wild
swings and two computers recording data using the GPS derived time may
be close enough to record which plant they are taking data for.

Kent

> This is "gps.freebsd.dk" one of, if not the, most precise NTP stratum 1
> servers in the world: +/- 20nsec.
> 
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD coreteam member | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
Kent Stewart
Richland, WA

mailto:[EMAIL PROTECTED]
http://www.3-cities.com/~kstewart/index.html
FreeBSD News http://daily.daemonnews.org/

SETI(Search for Extraterrestrial Intelligence) @ HOME
http://setiathome.ssl.berkeley.edu/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Matthew Dillon]

:
:In message <[EMAIL PROTECTED]>, Alexander Langer writ
:es:
:>Thus spake Matthew Dillon ([EMAIL PROTECTED]):
:>
:>> satellites sitting thousands of miles away in the sky.  It's even more
:>> impressive to see the government do something right for a change!
:>
:>It's much more idiotic that the government prevented it before.
:
:Well, they have added a new feature (which I can't talk about because I'm
:not supposed to know about how it works) which gives them an even more
:interesting and powerful DOS on the GPS system.  I doesn't quite work
:by postal code, but it comes *very* close.

That's public knowledge.  That is, if you are talking about the 
military's experiments with regional DOS on the GPS system.  In 
fact, it's one of the reasons cited by the president for turning 
off SA.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Alan Clegg]

Out of the ether, Matthew Dillon spewed forth the following bitstream:

> That's what my brother Ben told me, though he used the example of 
> an 18 wheeler plowing into my (airbagless) Subaru.  I think he's going
> to force me to buy a new car :-)

Seeing his input to the FreeBSD community, I think we should take up
a collection and buy Matt a new car with safety devices.  Or, at least
a bicycle helmet. 

AlanC
-- 
  \ Alan B. Clegg
 Just because I can\  [EMAIL PROTECTED]
does not mean I will.   \ 
 \


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Alexander Langer]

Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):

> >> not supposed to know about how it works) which gives them an even more
> >> interesting and powerful DOS on the GPS system.  I doesn't quite work
> >> by postal code, but it comes *very* close.
> >what is a DOS?-)
> Denial Of Service.

Oh. DOS you mean :-)
Well, that sounds bad.

Alex

-- 
I need a new ~/.sig.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Dragos Ruiu]

On Wed, 03 May 2000, Matthew Dillon wrote:
> Ok, this has nothing to do with FreeBSD, but I just had to post 
> something since nobody else has.
> 
Actually this is pretty relevant to network applications

Here is some more info from a mailing list I maintain 
of tech clippings and other such geek stuff
This has big implications for network applications
as GPS is now sufficiently accurate to time even 
high speed ATM (I believe you need 14ns accuracy
to sychronize to 53 byte cells on an OC3).

cheers,
--dr

--  Forwarded Message  --
Subject: kyxspam: GPS descrambled
Date: Wed, 3 May 2000 10:55:47 -0700
From: Dragos Ruiu <[EMAIL PROTECTED]>

(Ok, I'm a network guy, why should I give a flying donut
about GPS descrambling?  Well one of the big blocks to
using GPS receivers to synchronizing clocks on sniffers
for high speed networks was the timing uncertainty they
injected to allow military units to be more accurate than 
consumer ones.  It was possible to use consumer GPS 
for high-speed capture synchronization before IF you 
bought expensive $3-10K differential GPS units that 
linked to multiple satellites and made multiple measurements
to remove inaccuracies - making it unfeasible for 
distributed systems on cost.  The impact of this new
decision means that a whole bunch of new applications 
are now possible with consumer stuff with costs in the 
hundreds of dollars and not thousands. This now becomes
a perfect method for synchronizing those distributed 
gigabit net appliances.  Cool...   --dr)

url: http://geography.about.com/education/geography/library/weekly/aa050400a.htm

President Turns Off GPS Selective Availability

Dateline: 05/02/00

In plain English, we are unscrambling the GPS signal. It's rare that someone can press 
a button and make something you own instantly more valuable, but that's exactly what's 
going to happen today. All the people who bought a GPS receiver for a boat or a car, 
or their riding lawn mower or whatever, to use in business and in recreation, are 
going to find that they're suddenly 10 times more accurate as of midnight tonight. - 
Dr. Neal Lane, Director of the Office of Science and Technology.

With SA activated, you really only know if you are on the field or in the stands at 
that football stadium; with SA switched off, you know which yard marker you are 
standing on. - Comparison of Positions With and Without Selective Availability.

If you take a look at your handheld or automobile Global Positioning System (GPS) unit 
today, you'll notice that it's much, much more accurate now than it was on May 1. The 
reason? U.S. President Bill Clinton ordered Selective Availability (SA) turned off at 
midnight May 1 (Coordinated Universal Time). Now, civilian GPS users around the world 
will no longer experience the up to 100 meter (approximate 300 feet) random errors 
that SA added to keep GPS a more powerful tool for the military. Today, GPS units are 
accurate to within 20 meters (approximately 60 feet); although in good conditions, 
units should display an error of less than 10 meters.

In 1998, President Clinton directed that SA should be turned off between 2000 and 
2006. Fortunately, it happened early in that range of years. The U.S. military was 
able to quickly develop and test their ability to selectively block accurate GPS 
transmissions in areas of conflict or where U.S. security was at risk. When the U.S. 
Air Force Space Command turned off SA last night, GPS became incredibly accurate for 
the entire planet.

GPS operates through the use of 24 satellites, paid for by the U.S. government but 
free for the world to use, that are orbiting the earth. The satellites broadcast 
extremely accurate time signals (accurate to within 40 billionths of a second) using 
their onboard atomic clocks. GPS units on the earth triangulate the time signals from 
the satellites to provide location, velocity, and elevation of the units themselves. 
When Selective Availability was on, GPS units received a scrambled signal from the 
satellites, which hindered private and commercial use of GPS.

The current worldwide GPS industry is estimated to be approximately U.S. $8 billion 
and there are about four million GPS users worldwide. Now, experts expect that the 
demand and use of GPS will skyrocket, leading to $16 billion industry within three 
years. Use of GPS in a variety of areas has automatically been vastly improved. For 
example, automobile GPS units and mapping software under SA would often place the car 
one to two blocks from its actual location; today, GPS can tell which side of the 
freeway a car is on.

GPS is actually now more accurate than the accuracy standard for United States 
Geological Survey topographic maps so outdoor enthusiasts should truly appreciate the 
new accuracy of their GPS units. Soon, the U.S. Federal Communications Commission will 
require location determination technology in cellular phones for use in emergencies as 
part of

Re: GPS heads up

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Alexander Langer writ
es:
>Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
>
>> not supposed to know about how it works) which gives them an even more
>> interesting and powerful DOS on the GPS system.  I doesn't quite work
>> by postal code, but it comes *very* close.
>
>what is a DOS?-)

Denial Of Service.

>> >That just means that military use is even better already, i.e. I just
>> >imagine they are at 1m or less already.
>> Not quite, the military system is only better because it has two 
>> frequencies, and that doesn't improve things *that* much.
>
>That's the official version :)

No, that's the measurement data.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Alexander Langer]

Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):

> not supposed to know about how it works) which gives them an even more
> interesting and powerful DOS on the GPS system.  I doesn't quite work
> by postal code, but it comes *very* close.

what is a DOS?-)

> >That just means that military use is even better already, i.e. I just
> >imagine they are at 1m or less already.
> Not quite, the military system is only better because it has two 
> frequencies, and that doesn't improve things *that* much.

That's the official version :)

Alex

-- 
I need a new ~/.sig.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests

[Chris Dillon]

On Wed, 3 May 2000, Garance A Drosihn wrote:

> With the update I made, the sort will be stable because the two
> filenames will not be equal.  Please try the update at:
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=18361
>   [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq
> 
> or pick up the update from:
> ftp://freefour.acs.rpi.edu/pub/bsdlpr/lpr_qfix.diff

This is excellent.  I beat on it with my test-case and it works fine.  
Could someone please commit this to 5-CURRENT, 4-STABLE and even
3-STABLE?  I imagine even 2.2-STABLE users wouldn't mind.


-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
   FreeBSD: The fastest and most stable server OS on the planet.
   For Intel x86 and Alpha architectures. ( http://www.freebsd.org )




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Alexander Langer writ
es:
>Thus spake Matthew Dillon ([EMAIL PROTECTED]):
>
>> satellites sitting thousands of miles away in the sky.  It's even more
>> impressive to see the government do something right for a change!
>
>It's much more idiotic that the government prevented it before.

Well, they have added a new feature (which I can't talk about because I'm
not supposed to know about how it works) which gives them an even more
interesting and powerful DOS on the GPS system.  I doesn't quite work
by postal code, but it comes *very* close.

>That just means that military use is even better already, i.e. I just
>imagine they are at 1m or less already.

Not quite, the military system is only better because it has two 
frequencies, and that doesn't improve things *that* much.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Alexander Langer]

Thus spake Matthew Dillon ([EMAIL PROTECTED]):

> satellites sitting thousands of miles away in the sky.  It's even more
> impressive to see the government do something right for a change!

It's much more idiotic that the government prevented it before.

That just means that military use is even better already, i.e. I just
imagine they are at 1m or less already.

Alex

-- 
I need a new ~/.sig.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Matthew Dillon]

:Just don't be so amazed and bump into the nearest McD recycling truck ;-)
:
:But yes: this is cool..
:
:-- 
:Wilko BultePowered by FreeBSD  http://www.freebsd.org

That's what my brother Ben told me, though he used the example of 
an 18 wheeler plowing into my (airbagless) Subaru.  I think he's going
to force me to buy a new car :-)

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Wilko Bulte]

On Wed, May 03, 2000 at 10:44:50AM -0700, Matthew Dillon wrote:
> Ok, this has nothing to do with FreeBSD, but I just had to post 
> something since nobody else has.
> 
> By presidential order, on May 1 the error introduced into the GPS
> system, called 'SA', was turned off.
> 
> This means that your GPS receivers are now around 5-10 times more accurate
> then they were before May 1st.
> 
> And I have to say, I am totally amazed!  My handheld Garmin now
> tells me that it is accurate to 14 feet, rather then 100 ft.  It is
> so accurate now that I can tell which side of the street I'm on! 

Just don't be so amazed and bump into the nearest McD recycling truck ;-)

But yes: this is cool..

-- 
Wilko Bulte Powered by FreeBSD  http://www.freebsd.org
http://www.tcja.nl


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: GPS heads up

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>Ok, this has nothing to do with FreeBSD, but I just had to post 
>something since nobody else has.
>
>By presidential order, on May 1 the error introduced into the GPS
>system, called 'SA', was turned off.
>
>This means that your GPS receivers are now around 5-10 times more accurate
>then they were before May 1st.

This has nothing to do with FreeBSD unless you count NTP servers,
but actual data can be found on:

http://212.242.40.185/cgi-bin/ppsoffset.cgi

This is "gps.freebsd.dk" one of, if not the, most precise NTP stratum 1
servers in the world: +/- 20nsec.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

GPS heads up

[Matthew Dillon]

Ok, this has nothing to do with FreeBSD, but I just had to post 
something since nobody else has.

By presidential order, on May 1 the error introduced into the GPS
system, called 'SA', was turned off.

This means that your GPS receivers are now around 5-10 times more accurate
then they were before May 1st.

And I have to say, I am totally amazed!  My handheld Garmin now
tells me that it is accurate to 14 feet, rather then 100 ft.  It is
so accurate now that I can tell which side of the street I'm on! 

I had to drive from Berkeley to Sunnyvale yesterday... drove down in
the morning, drove back in the evening.

The tracks on my GPS (one going down 880 in the morning, the other
going back up 880 in the evening) are perfectly parallel to each other,
whereas before they would have been wildly different.  Tracks for roads
I travel now overlap almost exactly whereas before they were wildly
different (sometimes up to half a mile off!).

I am well and truely amazed.  It's impressive to see the thing recognize
when I take a few steps in one direction or another using a bunch of
satellites sitting thousands of miles away in the sky.  It's even more
impressive to see the government do something right for a change!

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Articles on Programming C (fwd)

[Chris Coleman]

I am looking for someone to write a column/series on programming in C on
BSD unix.

The series would be aimed at beginners, in hopes of getting more people
started in developing BSD code.  It should contain some methodology behind
the commit process and code correctness.

Please respond to me directly.

Chris Coleman
Daemon News  
http://www.daemonnews.org
Bringing BSD together




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: MAKE MONEY FOR DOING NOTHING!!!!!!!!! PROMISE

[Dave West]

On Wed, 3 May 2000, Dhar wrote:

> > Join now (there's no survey to fill out) at 
> > http://www.alladvantage.com/home.asp?refid=LZG150 and please 
> > use my membership ID (LZG-150) when asked if you were referred 
> > by someone. And http://cheetahtech.cjb.net
> 
> Darling, here is what you get for spamming us. I guess others on the
> mailing list will also do this. I will do exactly what u say, but when it
> comes to the person who referred me I will give LZG-149 instead of what
> you said. I guess it will serve you right for all this junk you have been
> sending. 
> 

Actually it's better to just tell AllAdvantage.com and they will cancell
his account and bar him for life.


Dave West E-Mail: [EMAIL PROTECTED]
Semiras Projects Ltd. PGP public key available on request.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Matthew Dillon]

Judging by your original bug report, Howard, it seems likely that either
the machine or the network the machine is sitting on is being attacked
and the machine is running out of some resource (probably network mbufs).
Increasing the NMBCLUSTERS any more will probably not help.

What you need to do is figure out what kind of attack it is and start
experimenting with the various kernel config (see LINT) and sysctl
features to try to stem the attack.

Now, of course the kernel should not be crashing... if you can obtain
a backtrace from some of your core's it might help us locate the 
problem.

gunzip vmcore.*.gz kernel.*.gz

gdb -k kernel.0 vmcore.0
back

gdb -k kernel.1 vmcore.1
back

I do not think this is vinum or fxp related.  If fxp is getting device
timeouts its probably due to the machine or network being attacked.

It's also possible that bad network cabling or a bad switch port 
is to blame.

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: why JDK 1.1.8 on FreeBFS is so slow ?

[Arun Sharma]

In muc.lists.freebsd.hackers, you wrote:
> 
> As it stands, however, 1.2.2 will not have a JIT either, unless someone
> finds a way to persuade Sun to help us out on this one.
> 
> There are a number of JIT's available in the ports collection. Install and
> use those. I have a description that Fuyuhiko Maruyama has written on how to
> do that for the JDK 1.2.2 port, but I am sure you can figure out how to do
> that for 1.1.8 too.

What is not in the ports collection and has great performance is 
http://www.openjit.org/

I have it working on both jdk-1.1.8 and jdk-1.2.2 (Greg Lewis port) on
FreeBSD. Very unscientific benchmarks show it to be about as fast as
sunwjit. I'll try to post the results of some standard benchmarks as I
find time.

-Arun


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

The wrong way to deal with SPAM (was "Re: Spammage: I Surf, YOU GET PAID!!!!!! Promise")

[Brian O'Shea]

(excessive cross-posts removed from CC list)

On Tue, May 02, 2000 at 10:01:41PM -0700, Dragos Ruiu wrote:
> I would recommend that everyone who received this forward it back to
> Mr. Pio at [EMAIL PROTECTED] to make the point that this is
> unacceptable behaviour.

That's assuming that <[EMAIL PROTECTED]> actually sent the spam.
You know as well as anybody else that return addresses on e-mail are
easy to fake.  The message did come from worldnet.att.net, but the
alias "hspio" could be a non-existant mailbox, or worse, an innocent
third party.

I sent a politely worded complaint to the postmaster at worldnet.att.net
including the spam messages with all headers.  They responded confirming
that they received my complaint and told me to send future complaints to
<[EMAIL PROTECTED]>.  They also said that they would "take
appropriate action".

We should stop posting about this now (I know how hypocritical this
sounds coming from a posting!).  But seriously, let's put this behind
us and get back to hacking.

Regards,
-brian

> 
> Just once each should suffice, and not contravene any usage policies :-).
> 
> I did...  Call it distributed spam negative reinforcement.  :-) :-) :-}
> Let's hope this will be sufficient to reinforce the lesson
> about what not to do on public technical mailing lists.
> 
> cheers,
> --dr
> 
> -- 
> dursec.com / kyx.net - we're from the future  
>http://www.dursec.com
> learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver 
> 
> Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld,
>  Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD
>Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message

-- 
Brian O'Shea
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /usr/share/examples/cvsup -> /usr/local/share/examples/cvsup

[Bill Fumerola]

On Wed, May 03, 2000 at 01:32:56PM +0100, Koster, K.J. wrote:

>  $ fetch ftp://ftp.freebsd.org/.../cvsup.tgz
>  $ pkg_add cvsup.tgz

$ pkg_add -r cvsup-bin

-r figures out the ... magic for you.

>  $ vi ...

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
Office: 800-252-2421 x128 / Cell: 248-761-7272





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Upgrade from 3.4 to 4.0 with ida driver

[James Housley]

"Christopher T. Griffiths" wrote:
> 
> I sent this to freebsd-questions with no luck.  I am desperately trying to
> figure out this problem.
> 
> Any help would be appreciated.
> 
Have you looked at this article on DaemonNews ? 

http://www.daemonnews.org/23/cpqraid.html

Jim
-- 
Do not meddle in the affairs of dragons, for you are crunchy and taste
good with ketchup.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Upgrade from 3.4 to 4.0 with ida driver

[Christopher T. Griffiths]

I sent this to freebsd-questions with no luck.  I am desperately trying to
figure out this problem.

Any help would be appreciated.

Thanks

Chris

---
Christopher T. Griffiths
Engineering Department
Quansoo Group Inc.
[EMAIL PROTECTED]
Hello everyone,

I have been working for a good part of the day trying to get my compaq
system upgraded from 3.4 -stable to 4.0 -stable.

I am using the following hardware:

Compaq Proliant 1850R Server
Smart Array 3200 Controller
1 Raid 1 array

I have been running 3.4 for several months on this system with zero
problems.

I have followed all of the Instructions in the Updating file and setup a
custom kernel configured to use the ata and ida drivers (attached).

There is only one problem:

I am getting the following on bootup when the kernel boots and tries to
change to the root device I get the following:

ta0-slave: ata_command: timeout waiting for intr
ata0-slave: identify failed
acd0: CDROM  at ata0-master using PIO4
no devsw (majdev=0 bootdev=0xa020)
Mounting root from ufs:/dev/idad0a
no such device 'idad'
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6

Manual root filesystem specification:
  :  Mount  using filesystem 
   eg. ufs:/dev/da0s1a
  ?  List valid disk boot devices
 Abort manual input
  
mountroot> ufs:/dev/id0a /
Mounting root from ufs:/dev/id0a /

My /etc/fstab contains the following:

# DeviceMountpoint  FStype  Options Dump
Pass#
/dev/idad0b noneswapsw  0   0
/dev/idad0a /   ufs rw  1   1
/dev/idad0f /usrufs rw  2   2
/dev/idad0e /varufs rw  2   2
proc/proc   procfs  rw  0   0


I have tried rebuilding the bootloader but no luck.

It seems that when I imput /dev/id0a into mountroot prompt it then mounts
root and changes over to /dev/idad0a which is in my fstab.

The funny thing is that there is no /dev/id0a in /dev and it will not
allow me to build it either.

I also posted a much more crazy post earlier but have since fixed most of
the problems except this one.

Any help would be appreciated.

Thanks

Chris
---
Christopher T. Griffiths
Engineering Department
Quansoo Group Inc.
[EMAIL PROTECTED]


# machine definitions
machine i386
cpu I686_CPU
ident   EXCALIBUR
maxusers100

# kernel options
options MATH_EMULATE#Support for x87 emulation
options DIAGNOSTIC
options UCONSOLE
options USERCONFIG
options KTRACE  #kernel tracing
options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN
options TCP_RESTRICT_RST#restrict emission of TCP RST
options ICMP_BANDLIM
options MD5

# compatibility options
options COMPAT_43
options IBCS2

# sysv options
options USER_LDT
options SYSVSHM
options SYSVSEM
options SYSVMSG

# network options
options INET
options INET6   

# filesystem options
options FFS
options FFS_ROOT
options MFS
options SOFTUPDATES
options NFS
options NFS_NOSERVER
options PROCFS
options CD9660
options CD9660_ROOT
options MSDOSFS

# Video Options
options VESA

# posix options
options P1003_1B
options _KPOSIX_PRIORITY_SCHEDULING
options _KPOSIX_VERSION=199309L

#System bus
device  isa
device  eisa
device  pci
options AUTO_EOI_1

#keyboard and mouse
device  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1
device  psm0at atkbdc? irq 12

#Console
device  vga0at isa?
device  sc0 at isa?

# Floating point support - do not disable.
device  npx0at nexus? port IO_NPX irq 13

# Power management support 
device  apm0

# apm/psm options
options PSM_HOOKRESUME
options PSM_RESETAFTERSUSPEND

# ata/atapi controllers/devices
device  ata0at isa? port IO_WD1 irq 14
device  ata1at isa? port IO_WD2 irq 15
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
device  atapifd # ATAPI floppy drives
device  atapist # ATAPI tape drives

# atapi options
options ATA_STATIC_ID   #Static device numbering
#options ATA_ENABLE_ATAPI_DMA

#
# Standard floppy disk controllers and floppy 
device  fdc0at isa? port IO_FD1 irq 6 drq 2
device  fd0 at fdc0 drive 0

# Parallel port
de

Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests

[Garance A Drosihn]

At 7:56 AM -0500 5/3/00, Chris Dillon wrote:
>That isn't the problem.  You can sleep as much as you want between
>submitting the print jobs and the job order still gets munged.
>Even a job that at one time had #1 rank gets inverted and ends up
>with the lowest rank.

He's saying that you could work around the problem if the EARLIER
jobs had used a sleep between them, ie, so they do not have the
same last-mod time.  If they do not match, then the order will
not get confused when later jobs arrive.  What he is saying is
correct, even though it is not very useful in practice...  (his
work-around would have helped Lorenzo, but it is not practical
for your samba-server example).

>It appears that qsort() is the culprit.  In fact, here is an
>excerpt from the manpage:
>
>The functions qsort() and heapsort() are not stable, that is,
>if two members compare as equal, their order in the sorted
>array is undefined.  The function mergesort() is stable. 
>

With the update I made, the sort will be stable because the two
filenames will not be equal.  Please try the update at:

http://www.freebsd.org/cgi/query-pr.cgi?pr=18361
  [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq

or pick up the update from:
ftp://freefour.acs.rpi.edu/pub/bsdlpr/lpr_qfix.diff


---
Garance Alistair Drosehn   =   [EMAIL PROTECTED]
Senior Systems Programmer  or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests

[Dan Nelson]

In the last episode (May 03), Chris Dillon said:
> On Tue, 2 May 2000, Dan Nelson wrote:
> > Aha.  Yes, it _does_ do FIFO, but if you look at the source, the
> > queue sorting routine simply sorts on stat(mtime) of the queue
> > file, so jobs submitted in the same second will sort randomly.  A
> > quick fix would be to sleep for 1 second between "lpr" calls.
> 
> That isn't the problem.  You can sleep as much as you want between
> submitting the print jobs and the job order still gets munged.  Even

If this is the case, then using mtime at all is wrong.  You sure
waiting 1 second between submissions doesn't work?

> a job that at one time had #1 rank gets inverted and ends up with the
> lowest rank.  I even modified common.c (a shot in the dark, I had no
> idea what I was doing, really) to check for modtime with
> st_mtimespec.tv_nsec for nsec modtime resolution, and that didn't
> change the behaviour any.

I checked, and fstat() always puts zeros in the nsec fields, either
because ffs doesn't store them, or for some other reason.
 
> It appears that qsort() is the culprit.  In fact, here is an excerpt
> from the manpage:
> 
> The functions qsort() and heapsort() are not stable, that is, if
> two mem- bers compare as equal, their order in the sorted array
> is undefined.  The function mergesort() is stable.

This doesn't help, since you can't guarantee that the files are in
order in the directory, either.  I think someone posted a better
solution, which would be sorting by mtime, and when mtime is identical,
sort by job number in the filename.

You can't simply sort by filename because that would break "lpc topq".
 
-- 
Dan Nelson
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Toshiba 4260 screen problem

[Andrzej Bialecki]

On Tue, 2 May 2000, Eric D. Futch wrote:

> I recall someone on the freebsd-mobile mailing list having a similar
> problem.  What I told them to try was using options VESA in their
> kernel config or use the vesa.ko kernel module.  I looked at it a little
> more closely and it appears that you might also need the SC_PIXEL_MODE
> option in your kernel config to get raster text mode to work.
> 
> After you have that in your kernel then you can use vidcontrol to change
> the video mode to VESA_800x600 for 800x600 raster text mode.  They seemed
> to be happy with the results.
> 
> Try it out and let me know wether or not it was helpful.

I have Portege 7020CT. The problem you describe (if I read it correctly)
might be related to the display setting in BIOS (Stretch enabled).
However, the stretching is implemented in very weird way - the screen font
in normal 80x25 mode is a bit ugly, so I use 80x43 with small font all the
time. It looks ok, and gives you additional lines as well.. :-)

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Epox Dual MB...

[Stefan Lindgren]

Hello,
 
Does anybody have experience with this Epox 
MB?
http://www.epox.com/html/english/products/motherboard/ep-bxb-s.htm
 
1 GB Ram
2 Pentium III Slot 1 650 MHz
Matrox Mill G400 360 Ramdac
UW SCSI
 
I'm planning to run 4.0-RELEASE.
 
Also, if anybody have experience with FBSD and a 
Raid(HW) solution for
300 - 500 GB I should be delighted to share 
his/hers toughts e t c.
 
It's going to run a Web hotel with *all* fancy 
stuff...
 
 
Regards
 
 
/Stefan

Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests

[Chris Dillon]

On Tue, 2 May 2000, Dan Nelson wrote:

> In the last episode (May 02), Chris Dillon said:
> > On Tue, 2 May 2000, Konrad Heuer wrote:
> > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO.
> > > Could you give some more infos about your environment (os release,
> > > input filter program, printer type)?
> 
> Aha.  Yes, it _does_ do FIFO, but if you look at the source, the queue
> sorting routine simply sorts on stat(mtime) of the queue file, so jobs
> submitted in the same second will sort randomly.  A quick fix would be
> to sleep for 1 second between "lpr" calls.

That isn't the problem.  You can sleep as much as you want between
submitting the print jobs and the job order still gets munged.  Even a
job that at one time had #1 rank gets inverted and ends up with the
lowest rank.  I even modified common.c (a shot in the dark, I had no
idea what I was doing, really) to check for modtime with
st_mtimespec.tv_nsec for nsec modtime resolution, and that didn't
change the behaviour any.

It appears that qsort() is the culprit.  In fact, here is an excerpt
from the manpage:

The functions qsort() and heapsort() are not stable, that is, if two mem-
bers compare as equal, their order in the sorted array is undefined.  The
function mergesort() is stable.

You would think that with nsec modtime resolution, the chance of two
jobs having equal sort criteria is slim to none, so most likely I
didn't do the modtime change correctly.

I wonder if we can work mergesort() in there somehow.  I also notice
that the job numbers assigned to the jobs are sequential, so maybe
that can be a sort criteria as well.  I'm just being a detective, but
I'm not a C programmer, so don't look at me. :-)


-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
   FreeBSD: The fastest and most stable server OS on the planet.
   For Intel x86 and Alpha architectures. ( http://www.freebsd.org )




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: why JDK 1.1.8 on FreeBFS is so slow ?

[Koster, K.J.]

Hi guys,

We're in the process of porting JDK 1.2.2. Sun has not released their JIT
under the SCSL, unfortunately. If we're lucky, Sun will give us a break and
give us access to that code under a special license. They did that for the
Blackdown porting team.

As it stands, however, 1.2.2 will not have a JIT either, unless someone
finds a way to persuade Sun to help us out on this one.

There are a number of JIT's available in the ports collection. Install and
use those. I have a description that Fuyuhiko Maruyama has written on how to
do that for the JDK 1.2.2 port, but I am sure you can figure out how to do
that for 1.1.8 too.

http://web.inter.nl.net/users/kjkoster/java/content/howto.html#hd03

Kees Jan

==
 You are only young once,
  but you can stay immature all your life


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: /usr/share/examples/cvsup -> /usr/local/share/examples/cvsup

[Koster, K.J.]

What's wrong with:

 $ fetch ftp://ftp.freebsd.org/.../cvsup.tgz
 $ pkg_add cvsup.tgz
 $ vi ...

?

Kees Jan

==
 You are only young once,
  but you can stay immature all your life


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Fw: bin/18361: [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq

[Lorenzo Iania]

- Original Message -
From: "Lorenzo Iania" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 03, 2000 12:46 PM
Subject: Re: bin/18361: [PATCH] Fix for queue-ordering problem in
lpr/lpd/lpq


> Yes I think it works fine now.
>
> Do you think that the limit of 1000 requests is adeguate?
>
> Best regards
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: why JDK 1.1.8 on FreeBFS is so slow ?

[Max Khon]

hi, there!

On Wed, 3 May 2000, Alexander Voropay wrote:

>  see
> http://www.volano.com/report.html
> for details

(quoting from their page)
JDK 1.1.8 FreeBSD 
 JDK 1.1.8 for FreeBSD 
 FreeBSD 3.2-RELEASE 
 Java version "jdk1.1.8-FreeBSD:1999/7/19" 
 Installed from jdk1.1.8_ELF.V99-7-19.tar.gz (11,337,773 bytes). 
 Uses user-level threads and no just-in-time compiler. 
 
 Increased the per-process file descriptor limit to 4096 (from
1064) and the system-wide file descriptor limit to 8192 (from
 1064) by using sysctl to modify the kern.maxfilesperproc and
kern.maxfiles variables in /etc/rc.local. See our
 FreeBSD Support page for details. 

Blackdown JDK 1.1.7 for Linux does not have JIT too and shows nearly the
same bad performance. The are several third-party JIT's you can to try
(tya, openjit).

/fjoe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Howard Leadmon]

 Well I actually have two prior crashes that I did save before I turned off
the dumpsaves to avoid running out of drive space, and as I am by no means 
a gdb user if you could tell me what your looking for I'll be happy to fire
up gdb and send you the info.

Here is what I grabbed out of the /var/crash directory (hopefully this is
useful), and I'll set the system to grab a clean dump next time around..

-rw-r--r--  1 howardl  wheel 31 Apr  8 15:44 bounds.0.gz
-rw-r--r--  1 howardl  wheel 31 Apr  9 13:39 bounds.1.gz
-rw-r--r--  1 howardl  wheel 825413 Apr  8 15:46 kernel.0.gz
-rw-r--r--  1 howardl  wheel 825413 Apr  9 13:40 kernel.1.gz
-rw-rw-r--  1 howardl  wheel  5 Feb 14 19:08 minfree
-rw-r--r--  1 howardl  wheel  111631734 Apr  8 15:46 vmcore.0.gz
-rw-r--r--  1 howardl  wheel  110971933 Apr  9 13:40 vmcore.1.gz

NOTE - I gzipped the dumps to save space, as with 384M RAM it was leaving
   some rather large files...


Also, thanks for the quick response..


> >  I know I posted a few messages here in the past, but maybe someone who is
> > good at tracking kernel problems can step up and lend a hand.
> >
> >  I have a machine running FBSD 4.0-STABLE, and have been experiencing almost
> > daily kernel panics or reboots on the machine.  I have replaced ALL of the
> > hardware, and reloaded the OS, but still having troubles.  I am at a bit of
> > a loss as to what is going on.  From one panic, I thought well maybe this
> > is an SMP issue, but removed one of the CPU's and still the box crashes. As
> > I have basically replaced everything, I am at a loss as to where to go from
> > here, so looking for some type of pointers or help with this..
> 
> Indeed.  We need to address this issue in some detail.  We need both
> documentation and tools.
> 
> >  The other day I was there, and got the following from one of the
> > crashes, as many times I am gone and luckally in some ways the box
> > will just panicboot and go on it's way.  Here is what I was able to
> > copy down:
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > mp_lock=0102; cpuid=1; lapic.id=0100
> > fault virtual address= 0x30
> > fault code= supervisor read, page not present
> > instruction pointer= 0x8:0xC01CAF71
> > stack pointer= 0x10:0xFF80DE48
> > frame pointer= 0x10:0xFF80DE4C
> > code segment= base 0x0, limit 0xF, type 0x1B
> > = DPL 0, pres 1, def 32, gran 1
> > processor eflags= interrupt enabled, resume, IOPL=0
> > current process = idle
> > interupt mask= bio <- SMP: XXX
> > trap number= 12
> > panic: page fault
> >
> > The formatting of it may not be perfect, but the information should be
> > accurate, as I tried to be precise on what I wrote down.  Also here are
> > a few previous messages I had posted a while back when I thought this
> > might be network related, but after trying several different NIC's I still
> > have the same issues.  I will include the info below, as maybe it will
> > have some value in trying to debunk this problem.
> 
> The sad thing is that this information is that most of this
> information is almost useless.  I'm thinking of printing out a stack
> trace instead (comments, anybody?).  Without tedious comparison with
> your kernel namelist, all we can say here is that you died somewhere
> in the kernel, that you have an SMP machine, and that the block I/O
> subsystem is probably involved.  If this is happening daily, you
> should build a kernel with debugging symbols enabled and take a dump
> of the next crash.  We can then use gdb to analyse the dump.
> 
> >   Hello, I am running a 4.0-STABLE machine which is being used to host an
> > Undernet IRC server, and the machine keeps dying at times, or should I say
> > the networking side of it is at least dying.  At first I thought it might
> > have been related to the dc (DEC Chip) based drivers, so I replaced it with
> > a EEpro board using the fxp driver, but the same results.
> >
> > 
> 
> If all your dumps have the interrupt mask set to bio, I don't think
> it's a networking problem.  With one possible exception...
> 
> > Mar 27 12:39:00 u2 /kernel: fxp0: device timeout
> 
> S_ren and I are trying to find out what is causing some weird Vinum
> problems.  He stated that the problem happened more frequently when
> an fxp board was in the system.  I don't believe him, and I've found
> at least one bug in Vinum that has nothing to do with networking (but
> does have to do with the bio mask); possibly, however, there's some
> other problem with the fxp driver.
> 
> It's possible that the other information will be of use, but I think
> we first need to look at a dump.
> 
> Greg
> --
> Finger [EMAIL PROTECTED] for PGP public key
> See complete headers for address and phone numbers


---
Howard Leadmon - [EMAIL PROTECTED] - http://www.abs.net
ABSnet Internet Services - Phone: 410-361-8160 - FAX: 410-361-8162



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in th

why JDK 1.1.8 on FreeBFS is so slow ?

[Alexander Voropay]

Hi!

 see
http://www.volano.com/report.html
for details


--
-=AV=-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Debugging Kernel/System Crashes, can anyone help??

[Greg Lehey]

On Wednesday,  3 May 2000 at  3:48:42 -0400, Howard Leadmon wrote:
>
>Hello,
>
>  I know I posted a few messages here in the past, but maybe someone who is
> good at tracking kernel problems can step up and lend a hand.
>
>  I have a machine running FBSD 4.0-STABLE, and have been experiencing almost
> daily kernel panics or reboots on the machine.  I have replaced ALL of the
> hardware, and reloaded the OS, but still having troubles.  I am at a bit of
> a loss as to what is going on.  From one panic, I thought well maybe this
> is an SMP issue, but removed one of the CPU's and still the box crashes. As
> I have basically replaced everything, I am at a loss as to where to go from
> here, so looking for some type of pointers or help with this..

Indeed.  We need to address this issue in some detail.  We need both
documentation and tools.

>  The other day I was there, and got the following from one of the
> crashes, as many times I am gone and luckally in some ways the box
> will just panicboot and go on it's way.  Here is what I was able to
> copy down:
>
>
> Fatal trap 12: page fault while in kernel mode
> mp_lock=0102; cpuid=1; lapic.id=0100
> fault virtual address= 0x30
> fault code= supervisor read, page not present
> instruction pointer= 0x8:0xC01CAF71
> stack pointer= 0x10:0xFF80DE48
> frame pointer= 0x10:0xFF80DE4C
> code segment= base 0x0, limit 0xF, type 0x1B
> = DPL 0, pres 1, def 32, gran 1
> processor eflags= interrupt enabled, resume, IOPL=0
> current process = idle
> interupt mask= bio <- SMP: XXX
> trap number= 12
> panic: page fault
>
> The formatting of it may not be perfect, but the information should be
> accurate, as I tried to be precise on what I wrote down.  Also here are
> a few previous messages I had posted a while back when I thought this
> might be network related, but after trying several different NIC's I still
> have the same issues.  I will include the info below, as maybe it will
> have some value in trying to debunk this problem.

The sad thing is that this information is that most of this
information is almost useless.  I'm thinking of printing out a stack
trace instead (comments, anybody?).  Without tedious comparison with
your kernel namelist, all we can say here is that you died somewhere
in the kernel, that you have an SMP machine, and that the block I/O
subsystem is probably involved.  If this is happening daily, you
should build a kernel with debugging symbols enabled and take a dump
of the next crash.  We can then use gdb to analyse the dump.

>   Hello, I am running a 4.0-STABLE machine which is being used to host an
> Undernet IRC server, and the machine keeps dying at times, or should I say
> the networking side of it is at least dying.  At first I thought it might
> have been related to the dc (DEC Chip) based drivers, so I replaced it with
> a EEpro board using the fxp driver, but the same results.
>
> 

If all your dumps have the interrupt mask set to bio, I don't think
it's a networking problem.  With one possible exception...

> Mar 27 12:39:00 u2 /kernel: fxp0: device timeout

Søren and I are trying to find out what is causing some weird Vinum
problems.  He stated that the problem happened more frequently when
an fxp board was in the system.  I don't believe him, and I've found
at least one bug in Vinum that has nothing to do with networking (but
does have to do with the bio mask); possibly, however, there's some
other problem with the fxp driver.

It's possible that the other information will be of use, but I think
we first need to look at a dump.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /usr/share/examples/cvsup -> /usr/local/share/examples/cvsup

[Matthew Dillon]

:
:i agree with peter. first thing i do after a fresh OS install is ftp over
:binary from ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/binaries/
:
:the next thing is do is:
:$ cp /usr/share/examples/cvsup/ .
:$ vi 
:$ ./cvsup -g -L 2 
:
:so your change won't be the end of the day, but it will just extra step.
:[or i just get to learn cvsup command line options ;]
:
:-- yan

Actually you don't have to change the example cvsup file at all usually.
Just specify the appropriate override options when you run the cvsup
binary (e.g. the -h HOSTNAME option to set the cvsup server to connect
to).

-Matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Debugging Kernel/System Crashes, can anyone help??

[Howard Leadmon]

   Hello,

 I know I posted a few messages here in the past, but maybe someone who is
good at tracking kernel problems can step up and lend a hand.

 I have a machine running FBSD 4.0-STABLE, and have been experiencing almost
daily kernel panics or reboots on the machine.  I have replaced ALL of the 
hardware, and reloaded the OS, but still having troubles.  I am at a bit of
a loss as to what is going on.  From one panic, I thought well maybe this
is an SMP issue, but removed one of the CPU's and still the box crashes. As
I have basically replaced everything, I am at a loss as to where to go from
here, so looking for some type of pointers or help with this..


 The other day I was there, and got the following from one of the crashes,
as many times I am gone and luckally in some ways the box will just panicboot 
and go on it's way.  Here is what I was able to copy down:


Fatal trap 12: page fault while in kernel mode
mp_lock=0102; cpuid=1; lapic.id=0100
fault virtual address= 0x30
fault code= supervisor read, page not present
instruction pointer= 0x8:0xC01CAF71
stack pointer= 0x10:0xFF80DE48
frame pointer= 0x10:0xFF80DE4C
code segment= base 0x0, limit 0xF, type 0x1B
= DPL 0, pres 1, def 32, gran 1
processor eflags= interrupt enabled, resume, IOPL=0
current process = idle
interupt mask= bio <- SMP: XXX
trap number= 12
panic: page fault


The formatting of it may not be perfect, but the information should be 
accurate, as I tried to be precise on what I wrote down.  Also here are
a few previous messages I had posted a while back when I thought this 
might be network related, but after trying several different NIC's I still
have the same issues.  I will include the info below, as maybe it will 
have some value in trying to debunk this problem.



  Hello, I am running a 4.0-STABLE machine which is being used to host an
Undernet IRC server, and the machine keeps dying at times, or should I say
the networking side of it is at least dying.  At first I thought it might
have been related to the dc (DEC Chip) based drivers, so I replaced it with
a EEpro board using the fxp driver, but the same results.  

 I have also set MNBCLUSTERS to 20480, and when I do a netstat I see in
general plenty of free clusters, but suspect I must be running out of some
other resource.  If I do a netstat -m, I see info like this:

u2$ netstat -m
1697/2144/81920 mbufs in use (current/peak/max):
498 mbufs allocated to data
1199 mbufs allocated to packet headers
221/514/20480 mbuf clusters in use (current/peak/max)
1296 Kbytes allocated to network (50% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines


When the machine last froze, the Kbytes allocated to the network was 99% in 
use, and the mbufs were up to about 20K of the 80K allocated, but I saw no
calls for memory denied or delayed.

Still after a few hours of uptime, I start seeing errors like this, and then
the machines network interface dies and I have to reboot to get everything
back in operation:

Mar 27 12:39:00 u2 /kernel: fxp0: device timeout
Mar 27 12:39:00 u2 syslogd: sendto: No buffer space available
Mar 27 12:39:38 u2 last message repeated 2 times
Mar 27 12:41:32 u2 last message repeated 6 times
Mar 27 12:44:15 u2 syslogd: sendto: No buffer space available
Mar 27 12:44:04 u2 last message repeated 8 times


Not sure what other information to send, but here is a dmesg on the machine,
and if anyone has any ideas, or needs more info please let me know.  It's
very annoying to have to reboot this machine daily, sometimes more often.. :(

Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #8: Wed Mar 22 18:31:51 EST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/U2
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (551.25-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
  
Features=0x183fbff
real memory  = 402587648 (393152K bytes)
config> q
avail memory = 387022848 (377952K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Preloaded elf kernel "kernel" at 0xc02c8000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02c809c.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
pci0:  at 7.2 irq 5
Timecounter "PIIX"  frequency 3579545 Hz
chip1:  port 0x5000-0x500f at device 7.3 on 
pci0
fxp0:  port 0xd400-0xd

snapshots...

[Darren Reed]

Does anyone have any idea about when a snapshot for -current will be
available ?

Darren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

protosw or ipprotosw - code mess in netinet

[Darren Reed]

Looking through /sys/netinet, it would appear that sometimes inetsw[]
is "struct protosw" and others "struct ipprotosw".  Which is it meant
to be ?  If ipprotosw is the same as protosw, why does ipprotosw exist ?

e.g.
in_proto.c:struct ipprotosw inetsw[] = {
in_proto.c:  (struct protosw *)inetsw,
in_proto.c:  (struct protosw *)&inetsw[sizeof(inetsw)/sizeof(inetsw[0])], 0,
ip_mroute.c:extern struct protosw inetsw[];
ip_output.c:extern  struct protosw inetsw[];

Darren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: /usr/share/examples/cvsup -> /usr/local/share/examples/cvsup

[Jan Koum]

i agree with peter. first thing i do after a fresh OS install is ftp over
binary from ftp://ftp.freebsd.org/pub/FreeBSD/CVSup/binaries/

the next thing is do is:
$ cp /usr/share/examples/cvsup/ .
$ vi 
$ ./cvsup -g -L 2 

so your change won't be the end of the day, but it will just extra step.
[or i just get to learn cvsup command line options ;]

-- yan

On Mon, May 01, 2000 at 07:25:17AM -0700, Peter Wemm <[EMAIL PROTECTED]> wrote:
> Nik Clayton wrote:
> > Folks,
> > 
> > Would anyone object to pulling /usr/share/examples/cvsup out of the base
> > system, and into /usr/local/share/examples/cvsup, to be installed by the
> > CVSup port?  There's no technical reason for the change, but it would be
> > more consistent with our other ports.
> 
> Which cvsup port would get it? There are two...
> 
> And what about the folks who ftp the binary and never install the ports
> collection?  They use the /usr/share/examples stuff as a base.  I certainly
> do not install the ports dist at sysinstall time and only do so eventually
> after cvsup'ing the ncvs tree and checking source and ports out of there.
> 
> Also, the share/examples stuff is supposed to be preset for getting the
> active branch that the release is from, when using checkout mode.  To
> duplicate that in the port you'd need multiple versions of the files and be
> sensitive on the OS version.
> 
> Cheers,
> -Peter
> 
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message