** HEADS UP ** network KLM names have changed.

1999-09-20 Thread David O'Brien

I have just changed the names of the installed network driver KLM's.
The KLM's are now prefixed by "if_".  (their registered DRIVER_MODULE
names have been changed to match).

You will probably want to clean out the old modules after your next
``build world''.

Also, please don't forget to change any necessary files in /boot, such as
loader.rc, for this change.

-- 
-- David([EMAIL PROTECTED])


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



Re: ** HEADS UP ** network KLM names have changed.

1999-09-20 Thread David O'Brien

 I have just changed the names of the installed network driver KLM's.

Foo.  Make that KLD's.  (some name changes are just hard to engrained on
 the brain...)


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



Re: Testers please!

1999-09-20 Thread Poul-Henning Kamp


Ok, noted.  I changed to to fail the probe but still use the hardware.

Poul-Henning

In message [EMAIL PROTECTED], Peter Wemm writes
:
Poul-Henning Kamp wrote:
 
 If you have a PIIX4 based SMP system and run current, could you
 please try out this patch:
 
  http://phk.freebsd.dk/piix/
 
 I'm very interested in hearing if there are any measurable difference
 apart from clock granularity being 3 times better.

There is a problem with it as it tries to claim the same device as claimed
by pcisupport.c and intpm.c..  pcisupport.c is where some folks have been
hanging Tor Egge's RTC SMI trap patch from..

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]



--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Re: newpcm and Vibra16X

1999-09-20 Thread Pat Lynch

I don;t need it back...so I don't mind...

Peter Wemm also had an idea, of setting up a clean installed box here
allowing certain hosts into the network and giving a serial console to
work from. I don;t mind doing this either. Let me know. 

If you want me to ship it, give me your address and I'll ship it in the
morning. 

The machine I do use the Vibra16X in is at work, and for now I'm without
music again. Too bad we can't have both oldpcm and newpcm for a while ;)

but with the new pnp stuff I'm not sure whether I can use the old pcm
stuff anymore anyway, but I've been away for 3 weeks traveling across the
United States to visit my grandmother in AZ, US. Haven't has a chance to
catch up on -current totally yet.


-Pat

___

Pat Lynch   [EMAIL PROTECTED]
[EMAIL PROTECTED]
Systems Administrator   Rush Networking
___

On Mon, 20 Sep 1999, Doug Rabson wrote:

 On Sun, 19 Sep 1999, Pat Lynch wrote:
 
  I have an extra Vibra16X if you haven't gotten one yet, I'm dying to have
  my sound working again. -Pat
 
 If you don't mind shipping it to the UK, I can give you my address.
 Cameron is in the process of moving and I don't have his new address. I'm
 very keen to get all the cards covered by the old pcm driver (and the
 voxware driver as far as possible) supported again.
 
 --
 Doug Rabson   Mail:  [EMAIL PROTECTED]
 Nonlinear Systems Ltd.Phone: +44 181 442 9037
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



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



Re: Testers please!

1999-09-20 Thread Peter Wemm

Poul-Henning Kamp wrote:
 
 Ok, noted.  I changed to to fail the probe but still use the hardware.

If intpm is probed first (the smbus driver), your probe won't even get
called. I think we need an early quirks or hooks handler in the pci probes
to handle stuff like this.  For example, we have hooks fixing up a handful
of wierd bios misconfigurations, collecting these together via a quirks
table or whatever would also give a convenient place for you to hook this
sort of thing into, and without it being dependent on link or probe order.

 Poul-Henning
 
 In message [EMAIL PROTECTED], Peter Wemm writ
es
 :
 Poul-Henning Kamp wrote:
  
  If you have a PIIX4 based SMP system and run current, could you
  please try out this patch:
  
 http://phk.freebsd.dk/piix/
  
  I'm very interested in hearing if there are any measurable difference
  apart from clock granularity being 3 times better.
 
 There is a problem with it as it tries to claim the same device as claimed
 by pcisupport.c and intpm.c..  pcisupport.c is where some folks have been
 hanging Tor Egge's RTC SMI trap patch from..

Cheers,
-Peter



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



Re: Testers please!

1999-09-20 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Peter Wemm writes
:
Poul-Henning Kamp wrote:
 
 Ok, noted.  I changed to to fail the probe but still use the hardware.

If intpm is probed first (the smbus driver), your probe won't even get
called. I think we need an early quirks or hooks handler in the pci probes
to handle stuff like this.  For example, we have hooks fixing up a handful
of wierd bios misconfigurations, collecting these together via a quirks
table or whatever would also give a convenient place for you to hook this
sort of thing into, and without it being dependent on link or probe order.

sigh...

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Re: 2xPIIIx450 results NFS results

1999-09-20 Thread Bruce Evans

 I remember this one too.  I think the problem is that we fail to 
 service the RTC intr for some reason.  This patch was only a 
 workaround, and received a verbal broadside from Bruce if I
 remember right.
 
 Maybe it should be added under a sysctl until a better solution
 is know.
 
 --- clock.c   Sat Sep 18 22:41:40 1999
 +++ clock.c.new   Sun Sep  5 13:21:35 1999
 @@ -203,4 +203,6 @@
  clkintr(struct clockframe frame)
  {
 + while (rtcin(RTC_INTR)  RTCIR_PERIOD)
 + statclock(frame);
   if (timecounter-tc_get_timecount == i8254_get_timecount) {
   disable_intr();

Use a watchdog timeout like you should for any device that may hang.
Don't waste time running it every clock tick.

ISTR that we thought that the bug might be caused by a bug in unwanted
SMI interrupt handling.

Bruce



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



Re: 2xPIIIx450 results NFS results

1999-09-20 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Bruce E
vans writes:
 I remember this one too.  I think the problem is that we fail to 
 service the RTC intr for some reason.  This patch was only a 
 workaround, and received a verbal broadside from Bruce if I
 remember right.
 
 Maybe it should be added under a sysctl until a better solution
 is know.
 
 --- clock.c  Sat Sep 18 22:41:40 1999
 +++ clock.c.new  Sun Sep  5 13:21:35 1999
 @@ -203,4 +203,6 @@
  clkintr(struct clockframe frame)
  {
 +while (rtcin(RTC_INTR)  RTCIR_PERIOD)
 +statclock(frame);
  if (timecounter-tc_get_timecount == i8254_get_timecount) {
  disable_intr();

Use a watchdog timeout like you should for any device that may hang.
Don't waste time running it every clock tick.

ISTR that we thought that the bug might be caused by a bug in unwanted
SMI interrupt handling.

If anybody can reproduce this reliably on a *BX chipset I have
code that will block SMI interrupts we can test with...

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Re: 2xPIIIx450 results NFS results

1999-09-20 Thread Mike Smith

 Use a watchdog timeout like you should for any device that may hang.
 Don't waste time running it every clock tick.
 
 ISTR that we thought that the bug might be caused by a bug in unwanted
 SMI interrupt handling.
 
 If anybody can reproduce this reliably on a *BX chipset I have
 code that will block SMI interrupts we can test with...

I'm not sure I follow what the alleged problem is here; who is handling 
the "unwanted" SMIs?  If it's the BIOS, the last thing you want to do 
is block all SMIs. 

-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




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



Re: 2xPIIIx450 results NFS results

1999-09-20 Thread Poul-Henning Kamp

In message [EMAIL PROTECTED], Mike Smith writes:
 Use a watchdog timeout like you should for any device that may hang.
 Don't waste time running it every clock tick.
 
 ISTR that we thought that the bug might be caused by a bug in unwanted
 SMI interrupt handling.
 
 If anybody can reproduce this reliably on a *BX chipset I have
 code that will block SMI interrupts we can test with...

I'm not sure I follow what the alleged problem is here; who is handling 
the "unwanted" SMIs?  If it's the BIOS, the last thing you want to do 
is block all SMIs. 

The problem is that the RTC stalls.  It is suspected that it could
be long SMI durations which is responsible for this.  To confirm
the diagnosis disabling SMI is feasible.

You system will not blow up if you disable SMI, I have a system
happily chugging away here with SMI disabled for a month.

Doing so even idiot-proofs the soft-off button :-)

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Web page w/ postmark results so far...

1999-09-20 Thread Brad Knowles

Folks,

I haven't put everything online that I've gotten so far, but I 
have started putting my information online.  See 
http://www.shub-internet.org/brad/FreeBSD/postmark.html.  The 
tables were taken directly from Network Appliance, and then extended 
to include the additional entries.  I'll be adding columns for 
information from other sources, as I get the time and complete 
information.


Please send me e-mail if you have any comments.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  
|o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o|
|o| Systems Architect, News  FTP Admin  Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels   |o|
|o| http://www.skynet.be Belgium   |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.


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



Re: 2xPIIIx450 results NFS results

1999-09-20 Thread Michael Reifenberger

Hi,
 Use a watchdog timeout like you should for any device that may hang.
 Don't waste time running it every clock tick.
 
 ISTR that we thought that the bug might be caused by a bug in unwanted
 SMI interrupt handling.
Upgrading the BIOS to Rev. 1010 does solve the problem for me without the patch
to clock.c.

Bye!

Michael Reifenberger
Plaut Software GmbH, R/3 Basis



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



Page fault with ethernet xl0

1999-09-20 Thread Stephan van Beerschoten

I have experienced something nasty. After cvs'ing my tree 3 hours
ago which would be approx 16:00 CET, I did a buildworld, installed
it, compiled a new kernel.

This was right after the announcement that improvements had been
made to the xl device driver. I wanted to try...

The Result:
Pagefault while trying to ifconfig during boot.

fatal trap 12: page fault while in kernel mode
fault virtual address   =   0x0
fault code  =   supervisor read, page not present
instruction pointer =   0x8:0x0
stack pointer   =   0x10:0xccbfddf8
frame pointer   =   0x10:0xccbfde1c
code segment=   base 0x10, limit 0xf, type 0x1b
DPL 0, pres 1, def32 1, gran 1
processor eflags=   interrupt enabled, resume, IOPL=0
current process =   67 (ifconfig)
interrupt mask  =   net tty
trap number =   12
panic: page fault

I hope this can be of any help.
Let me know if you need more info.

-Steve

-- 
Stephan van BeerschotenEmail: [EMAIL PROTECTED] 
Network Engineer   Luna Internet Services www.luna.nl
   PO Box 28013 3003 KA  Rotterdam NL
PGPKey fingerprint = 45 57 97 61 B2 12 FB 4C  77 8D 35 29 C4 2A 2D 27
 "RETURN VALUES: The panic() function call does not return" :P


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



Re: Page fault with ethernet xl0

1999-09-20 Thread Bill Paul

Of all the gin joints in all the towns in all the world, Stephan van 
Beerschoten had to walk into mine and say:

 I have experienced something nasty. After cvs'ing my tree 3 hours
 ago which would be approx 16:00 CET, I did a buildworld, installed
 it, compiled a new kernel.

Dammit. You didn't even tell me what kind of card you have. Do you
really need me to ask you for this? Go back and boot the kernel in 
verbose mode and show me *EXACTLY* what it says.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home:  [EMAIL PROTECTED] | Columbia University, New York City
=
 "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=


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



Re: ep0 etherlink III breakage

1999-09-20 Thread David O'Brien

On Mon, Sep 20, 1999 at 12:28:27PM -0500, Mark Hittinger wrote:
 Hey per request I'm reporting some ep0 breakage in today's -current.  I have
 an etherlink III 3c509B and the probing appears correct.
 
 Sequence of events   boot -s
# ifconfig ep0 inet 192.168.18.200
  (PC hangs)

\begin{wpaul}

WHAT am I supose to do with this?  I don't even understand what you
are trying to tell me.  You booted single user and got a hang.  What
is the #'ed line supose to be?  Last time *_I_* booted single user I
didn't see such output.

Can you ``boot -sv''.  How far does it get?  (give the last two-three
lines).  What is printed out about your 3c509B?  (give this verbatum)

\end{wpaul}

-- 
-- David([EMAIL PROTECTED])


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



request for review, patch to specfs to fix EOF condition alignment with buffer

1999-09-20 Thread Matthew Dillon

This is a request for a review.  This patch fixes a bug in specfs
relating to dealing with the EOF condition of a block device.

If the EOF occurs in the middle of a block, specfs was not
properly calculating the truncation for the I/O.

This problem was first found by Tor.  Tor's example creates
an oddly-sized VN partition and then  dd's from it.  Without the
patch the dd believes that it can read 2880 sectors.  With the
patch it correctly reads the last (truncated) block.

dd if=/dev/zero of=/tmp/floppy.img bs=512 count=2879
vnconfig -s labels -c /dev/vn0 /tmp/floppy.img
dd if=/dev/vn0 of=/dev/null bs=8k

Once this patch is committed, the only problem we will have is
in recognizing the write-EOF case, which I will have a 
recommendation for after this patch goes in.

A similar problem in the VN device has already been fixed and
committed.

-Matt

Index: miscfs/specfs/spec_vnops.c
===
RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v
retrieving revision 1.108
diff -u -r1.108 spec_vnops.c
--- spec_vnops.c1999/09/17 06:10:26 1.108
+++ spec_vnops.c1999/09/20 17:50:48
@@ -311,19 +311,37 @@
do {
bn = btodb(uio-uio_offset)  ~(bscale - 1);
on = uio-uio_offset % bsize;
-   n = min((unsigned)(bsize - on), uio-uio_resid);
if (seqcount  1) {
nextbn = bn + bscale;
error = breadn(vp, bn, (int)bsize, nextbn,
(int *)bsize, 1, NOCRED, bp);
} else {
error = bread(vp, bn, (int)bsize, NOCRED, bp);
+   }
+
+   /*
+* Figure out how much of the buffer is valid relative
+* to our offset into the buffer, which may be negative
+* if we are beyond the EOF.
+*
+* The valid size of the buffer is based on 
+* bp-b_bcount (which may have been truncated by
+* dscheck or the device) minus bp-b_resid, which
+* may be indicative of an I/O error if non-zero.
+*/
+   n = bp-b_bcount - on;
+   if (n  0) {
+   error = EINVAL;
+   } else {
+   n -= bp-b_resid;
+   if (n  0)
+   error = EIO;
}
-   n = min(n, bsize - bp-b_resid);
if (error) {
brelse(bp);
return (error);
}
+   n = min(n, uio-uio_resid);
error = uiomove((char *)bp-b_data + on, n, uio);
brelse(bp);
} while (error == 0  uio-uio_resid  0  n != 0);
@@ -403,16 +421,48 @@
do {
bn = btodb(uio-uio_offset)  ~blkmask;
on = uio-uio_offset % bsize;
+
+   /*
+* Calculate potential request size, determine
+* if we can avoid a read-before-write.
+*/
n = min((unsigned)(bsize - on), uio-uio_resid);
if (n == bsize)
bp = getblk(vp, bn, bsize, 0, 0);
else
error = bread(vp, bn, bsize, NOCRED, bp);
+
+   /*
+* n is the amount of effective space in the buffer
+* that we wish to write relative to our offset into
+* the buffer. We have to truncate it to the valid
+* size of the buffer relative to our offset into
+* the buffer (which may end up being negative if
+* we are beyond the EOF).
+*
+* The valid size of the buffer is based on 
+* bp-b_bcount (which may have been truncated by
+* dscheck or the device) minus bp-b_resid, which
+* may be indicative of an I/O error if non-zero.
+*
+* XXX In a newly created buffer, b_bcount == bsize
+* and, being asynchronous, we have no idea of the
+* EOF.
+*/
+   if (error == 0) {
+   n = min(n, bp-b_bcount 

Re: request for review, patch to specfs to fix EOF condition alignment with buffer

1999-09-20 Thread Poul-Henning Kamp


Once this patch is committed, the only problem we will have is
in recognizing the write-EOF case, which I will have a 
recommendation for after this patch goes in.

...and the lack of error code returns on write.

--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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



Re: ep0 etherlink III breakage

1999-09-20 Thread Matthew Hunt

On Mon, Sep 20, 1999 at 11:58:28AM -0700, David O'Brien wrote:

  Sequence of events   boot -s
   # ifconfig ep0 inet 192.168.18.200
   (PC hangs)

 \begin{wpaul}

Dunno, you seem too mellow.

 WHAT am I supose to do with this?  I don't even understand what you
 are trying to tell me.  You booted single user and got a hang.  What
 is the #'ed line supose to be?  Last time *_I_* booted single user I
 didn't see such output.

At a guess, the "#" is the root prompt that shows up after boot -s,
and he typed the ifconfig command.

-- 
Matthew Hunt [EMAIL PROTECTED] * Stay close to the Vorlon.
http://www.pobox.com/~mph/   *


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



ports/net/kicq problem

1999-09-20 Thread Ilya Naumov

Hello ppl,

i have installed latest (1.1.2) kde11-i18n based on qt-i18-1.44a library.
kde itself works fine but, now i'm experiencing another problem: old
binaries that were built with older qt do not run. but the worst thing is 
impossibility to re-build that
binaries with new qt using ports (kicq is good example). configure just
fails while trying to find qt library:

checking for QT-1.4x... configure: error: QT-1.4x (libraries) not found. Please check 
your installation!

could anybody fix this?


Best regards,
 Ilya  mailto:[EMAIL PROTECTED]




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



Re: ep0 etherlink III breakage

1999-09-20 Thread Jason Young


I'm not certain what the problem is, but the ep0 changes that generated
the HEADS UP messages affect _only_ PC Cards. The other sections of code
are untouched. Further, I'm 99% sure the only card that could possibly
have been broken by the probe change is the 3C574 PC Card (not 3C574B). 

Jason Young
accessUS Chief Network Engineer

On Mon, 20 Sep 1999, Matthew Hunt wrote:

 On Mon, Sep 20, 1999 at 11:58:28AM -0700, David O'Brien wrote:
 
   Sequence of events   boot -s
  # ifconfig ep0 inet 192.168.18.200
(PC hangs)
 
  \begin{wpaul}
 
 Dunno, you seem too mellow.
 
  WHAT am I supose to do with this?  I don't even understand what you
  are trying to tell me.  You booted single user and got a hang.  What
  is the #'ed line supose to be?  Last time *_I_* booted single user I
  didn't see such output.
 
 At a guess, the "#" is the root prompt that shows up after boot -s,
 and he typed the ifconfig command.
 
 -- 
 Matthew Hunt [EMAIL PROTECTED] * Stay close to the Vorlon.
 http://www.pobox.com/~mph/   *
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 



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



Re: ep0 etherlink III breakage

1999-09-20 Thread Mark Hittinger

 WHAT am I supose to do with this?  I don't even understand what you
 are trying to tell me.  You booted single user and got a hang.  What
 is the #'ed line supose to be?  Last time *_I_* booted single user I
 didn't see such output.

Actually I don't really care what you do with this.  I did say "more later"
but you chopped that part out.  I was only trying to give a heads up.

I've been playing with it for a few minutes and here is some more info:

ie0: unknown board_id: f000
1 3C5x9 board(s) on ISA found at 0x300
ep0 at port 0x300-0x30f irq 10 on isa0
ep0: utp[*UTP*] address 00:a0:24:a1:9a:1e
isa_compat: didn't get ports for le
isa_compat: didn't get ports for cs
unknown0: 3Com 3C509B EtherLink III at port 0x210-0x21f irq 5 on isa0
ep0 XXX: driver didn't set ifq_maxlen
changing root device to wd0s1a

Since we have an ep0 and an unknown0 the ifconfig ep0 causes a hang.  Doing
this in stand alone eliminates other issues.  When debugging it pays to do
that.

I assume that the unknown0 probe success is where we are going astray - 
this may be a similar buglet to the ed_probe_HP_pclanp() routine I submitted
a patch for last week ( lots of return 0 instead of return ENXIO ).

I'll be doing some additional debugging this evening when I have more time.

Guess I made the mistake of misreading a request that came through
freebsd-current a few days ago asking for any problem reports with ep0.
My mistake - sorry - I shall return to lurking.

Regards,

Mark Hittinger
Mindspring/Netcom/Dallas
[EMAIL PROTECTED]


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



is this a f77 issue, egcs issue, or os issue?

1999-09-20 Thread Jim Bryant

Just for kicks, while waiting for my phones to be hooked up at the new
address, I ran some heavy duty benchmarks to see if the systems
transported fine.  i think they did arrive undamaged in the move, but
i ran pitest at the maximum rated precision.

apparently, this is not a /usr/bin/time issue, as i ran it again the
next day without it with the same IOT trap.

while this was running, it was approximately 80M or so into swap.

all other precisions seem to work fine up to and including MX=22 [~6
million digits].

this is a dual p2-333 system running -current from Sun Jul 25 23:51:16
CDT 1999 [yeah, i know, but i don't think that is the issue here].
512M RAM.  and am using a tyan 1696dlua motherboard.

I will attach source code to this message.  DO NOT change ANYTHING
except the MX value in pi4.f

i think the time returned by /usr/bin/time seems to be correct based
on my second run.  the program only attempts file i/o once the run is
complete.

i AM NOT going to submit the half a gig core file, generate your own!

in the past day or so, i have tested EVERY MX between 14 and 22.

since this is a f77 program, it could be the fortran compiler, egcs,
or the OS itself causing this problem.  the output file fort.4 remains
untouched and still contains the results of the previous test [MX=22].

--
 7:34:07am  wahoo(15): /usr/bin/time -l ./pitest_mx=23
PI4 COMPUTATION TEST -- DP COMPLEX FFT MP VERSION

MW = 23   NW =   2097152   ND =  12582906

ITERATION   1  12
ITERATION   2  12
ITERATION   3  12
ITERATION   4  12
ITERATION   5  12
ITERATION   6  12
ITERATION   7  12
ITERATION   8  12
ITERATION   9  12
ITERATION  10  12
ITERATION  11  12
ITERATION  12  12

CPU TIME =   0. SECONDS.
sfe: unit not connected
apparent state: unit 4 (unnamed)
lately writing sequential formatted external IO
time: command terminated abnormally
78538.50 real 75950.35 user   367.96 sys
447972  maximum resident set size
92  average shared memory size
66  average unshared data size
   128  average unshared stack size
912519  page reclaims
144493  page faults
 0  swaps
44  block input operations
  8148  block output operations
 0  messages sent
 0  messages received
 0  signals received
144724  voluntary context switches
   1875620  involuntary context switches
IOT trap (core dumped)
 5:23:10am  wahoo(16): d fort.4
 5:27:16am  wahoo(17): d
total 528545
drwxr-xr-x  2 root  wheel512 Sep  8 05:23 .
drwxr-xr-x  4 root  wheel512 Jul 21 04:16 ..
-rw---  1 root  wheel  57731 Jun 11 19:32 mp.f
-rw-r--r--  1 root  wheel  35244 Jun 11 19:45 mp.o
-rw-r--r--  1 root  wheel6377979 Jul 21 12:19 pi.mx=22
-rw---  1 root  wheel   2962 Jun 11 19:32 pi2.f
-rw---  1 root  wheel   3656 Jun 11 19:45 pi4.f
-rwxr-xr-x  1 root  wheel  35164 Jun 11 19:46 pitest.mx=14
-rwxr-xr-x  1 root  wheel 119285 Jun 11 19:32 pitest_mx=14
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=15
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=16
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=17
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=18
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=19
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=20
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=21
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=22
-rwxr-xr-x  1 root  wheel 119293 Jun 11 19:32 pitest_mx=23
-rw---  1 root  wheel  532840448 Sep  8 05:23 pitest_mx=23.core
-rw---  1 root  wheel 266240 Sep  8 05:23 time.core
-rw-r--r--  1 root  wheel812 Jun 13 11:47 time.out
 5:27:36am  wahoo(18): 

jim
-- 
All opinions expressed are mine, if you|  "I will not be pushed, stamped,
think otherwise, then go jump into turbid  |  briefed, debriefed, indexed, or
radioactive waters and yell WAHOO !!!  |  numbered!" - #1, "The Prisoner"
--
Inet: [EMAIL PROTECTED]AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw
voice: KC5VDJ - 6  2 Meters AM/FM/SSB, 70cm FM.   http://www.tfs.net/~jbryant
--
HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+

 pitest.tgz


DANGER: login and friends with libscrypt/libdescrypt

1999-09-20 Thread Pierre Beyssac

I've just been bitten by the following, so I figured I might as
well warn others. From a quick glance it doesn't seem to have been
mentioned, or not clearly enough, in this list.

- libscrypt/libdescrypt major number has been
  bumped a few days ago.
- /usr/bin/login and friends are now linked against libscrypt
  instead of libcrypt.

The bottom line is, if:

- you don't have crypto sources on your machine
- you were using a symbolic link from libcrypt* to
  libscrypt*/libdescrypt*
- you used that to link to an old libdes binary

then ***test*** your compiled login binary before you reinstall
everything.

Thanksfully I kept an older -current on another machine from which
I could find a working copy of login, which saved me from totally
ruining my night.

But I'll be sure to install complete crypto sources first thing
tomorrow morning on my machines.
-- 
Pierre Beyssac  [EMAIL PROTECTED]


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



Re: Wierd su/vnc issue

1999-09-20 Thread Pierre Beyssac

On Mon, Sep 20, 1999 at 09:16:13PM +, Adam Strohl wrote:
 adams@nightfall(21:13:30)$ su
 Password:load: 0.35  cmd: su 407 [ttyin] 0.00u 0.00s 0% 664k
 
 As soon as I hit enter I get more:
 load: 0.32  cmd: su 407 [ttyin] 0.00u 0.00s 0% 664k

I saw that, too. That might be a strange side effect of the
libcrypt-libscrypt change (note how it happens with programs which
ask for a passwd). I just get SIGSEVs right now when I try su but
I've had the same as you at least once before that.
-- 
Pierre Beyssac  [EMAIL PROTECTED]


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



Re: Wierd su/vnc issue

1999-09-20 Thread Adam Strohl

Well, is there a work around, telneting out does the same thing, using
the -l user option used to allow me to log into remote hosts, not
anymore, same with loopback telneting and suing.

I can hear Jordan already: "TAKE IT LIKE A MAN!" ;'D

- ( Adam Strohl ) -
-  UNIX Operations/Systems   http://www.digitalspark.net  -
-  adams (at) digitalspark.netxxx.xxx. x  -
- ( DigitalSpark.NET )--- -

On Tue, 21 Sep 1999, Pierre Beyssac wrote:

 On Mon, Sep 20, 1999 at 09:16:13PM +, Adam Strohl wrote:
  adams@nightfall(21:13:30)$ su
  Password:load: 0.35  cmd: su 407 [ttyin] 0.00u 0.00s 0% 664k
  
  As soon as I hit enter I get more:
  load: 0.32  cmd: su 407 [ttyin] 0.00u 0.00s 0% 664k
 
 I saw that, too. That might be a strange side effect of the
 libcrypt-libscrypt change (note how it happens with programs which
 ask for a passwd). I just get SIGSEVs right now when I try su but
 I've had the same as you at least once before that.
 -- 
 Pierre Beyssac[EMAIL PROTECTED]
 
 



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



Re: DANGER: login and friends with libscrypt/libdescrypt

1999-09-20 Thread Mark Murray

   - /usr/bin/login and friends are now linked against libscrypt
 instead of libcrypt.

This is a link bug. The Makefile says "-lcrypt". JDP?
i
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org


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



Re: ata drivers

1999-09-20 Thread David Krinsky

On Mon, Sep 20, 1999 at 12:05:38AM +, Gary Hampton ([EMAIL PROTECTED]) 
wrote:
 On Mon, 20 Sep 1999, Adam Strohl wrote:
 
  Remake your acd device, I think you may need a patch to do it.  I had the
  same problem, until I rm-ed the device and remade it.
  
  - ( Adam Strohl ) -
  -  UNIX Operations/Systems   http://www.digitalspark.net  -
  -  adams (at) digitalspark.netxxx.xxx. x  -
  - ( DigitalSpark.NET )--- -
 No luck I still just get:
 mount_cd9660: Block device required
 trying to mount acd0a acd0c acd1a and acd1c

What's the major number on acd0c?  It should be 31;  IIRC older
MAKEDEV scripts set it to 19.

Dave.


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