Re: Perl broken in 4.0-CURRENT ?

1999-08-31 Thread Anton Berezin

On Tue, Aug 31, 1999 at 02:09:00AM +0200, Pascal Hofstee wrote:

 I get the following errors when trying to run certain perl stuff ..
 like mirror:

 su-2.03# mirror /usr/local/lib/mirror/packages/daemonnews 
 DynaLoader:/usr/libdata/perl/5.00503/DynaLoader.pm:188 Caught a SIGSEGV
 shutting down at /usr/local/bin/mirror line 3873.

Yep.  The easiest way to reproduce this is

$ perl -MIO -e ''

It dies during IO's bootstrap, but I have not investigated this further.

Something in libc?

Cheers,
-- 
Anton Berezin [EMAIL PROTECTED]
The Protein Laboratory, University of Copenhagen


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



Re: HEADS UP

1999-08-31 Thread Doug Rabson

On Mon, 30 Aug 1999, Poul-Henning Kamp wrote:

 In message [EMAIL PROTECTED], Jonathan Lemon writes:
 On Aug 08, 1999 at 11:36:30PM +0200, Poul-Henning Kamp wrote:
  In message [EMAIL PROTECTED], Jonathan Lemon writes:
I've just committed the revised TCP timer code.  There are some 
  user visible changes:
  
User visible TCP timers are now in units of the system clock
(10ms for the i386)
  
  Please, can we have them be in milliseconds ? 
 
 Wouldn't this mean writing a sysctl proc for each variable, 
 instead of directly changing the underlying integer?  I did
 consider this, but wasn't sure if it would be worth the effort.
 
 Yes, you'd have to, but considering that HZ is 1024 on alpha
 and 100 on i386 I think it is well worth the effort...

Actually on the alpha, HZ is whatever the firmware tells us. Its often
1024 but I remember SimOS used to pretend it was 1200 for some reason.

--
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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Matthew Dillon


:Two things I've noticed:
:1) my cdrom delivers about 2M/s which is the same as before DMA.  Is
:the improvement only in cpu usage or should I be seeing a speed
:improvement too? 
:
:speed tested with:
:dd if=/dev/racd0c of=/dev/null bs=64k count=320
:(I get it to spin up with another dd before this test)

Well 2MB/sec == 14x CDRom drive.  Is it a 14x CDRom drive?  CDRom
drives are typically limited to how quickly they can get data off
the platter.  A faster bus transfer will not improve that.

:2) I can crash my system (sometimes a panic, sometimes a freeze) with:
:dd if=/dev/racd0c of=/dev/null bs=1m count=1
:
:I could do bs=1m before the DMA code went in.  
:
:If the system freezes I see:
:atapi_error: READ_BIG - timeout error = 00
:long pause
:the dd puts out a message about transferring 0 records

(This is a different problem, one I can't address.  Presumably someone
else can).

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


:Kevin Street
:[EMAIL PROTECTED]



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



Re: Docs blows up make release

1999-08-31 Thread Nik Clayton

[ quoted section retained for context ]

On Thu, Aug 26, 1999 at 08:53:00PM +0100, Nik Clayton wrote:
 -stable, -current,
 
 On Sun, Aug 22, 1999 at 11:05:11AM +0100, Nik Clayton wrote:
  [ cc'd to -current ]
  
  On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote:
   mode ugly monolingual American
   Will support for building release docs in English only be
   revived?
   /mode
  
  For the immediate future, it looks like it will -- it seems as though
  we don't have the man power to make the necessary changes to sysinstall
  to support "installing the docs as packages", so I'm going to fix up 
  src/release/Makefile as necessary to cope with the new directory structure.
 
 With thanks to Jack O'Neill, this is now done.  They're only in -current 
 at the moment, but they should backport to -stable fairly easily.  I'd
 be obliged if those if you who like to do these things grabbed a copy
 of -current that has r1.504 of src/release/Makefile, and tried building
 a release with that, and a copy of the doc/ tree that's of a similar
 vintage.  Everything should pretty much work.
 
 Brickbats should be sent my way if it doesn't.

There's been a disturbing lack of brickbats landing at my feet, so can I
assume that the new doc/ "make release" stuff is working for everybody?

If so, I'll MFC the infrastructure tonight.

N
-- 
 [intentional self-reference] can be easily accommodated using a blessed,
 non-self-referential dummy head-node whose own object destructor severs
 the links.
-- Tom Christiansen in [EMAIL PROTECTED]


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Kevin Street

Matthew Dillon [EMAIL PROTECTED] writes:

 :Two things I've noticed:
 :1) my cdrom delivers about 2M/s which is the same as before DMA.  Is
 :the improvement only in cpu usage or should I be seeing a speed
 :improvement too? 
 :
 :speed tested with:
 :dd if=/dev/racd0c of=/dev/null bs=64k count=320
 :(I get it to spin up with another dd before this test)
 
 Well 2MB/sec == 14x CDRom drive.  Is it a 14x CDRom drive?  CDRom
 drives are typically limited to how quickly they can get data off
 the platter.  A faster bus transfer will not improve that.

I should have mentioned that ... it's a 32x cdrom.  dmesg says it
claims to be able to do 5515 KB/sec. 

I've played around with using dd ... skip=n to reposition which part
of the cd I'm reading and I've seen some much better speeds on the
outer tracks (I think I now recall that cd's start numbering from the
inside tracks, don't they?).  So you're probably right that it's just
the rotational speed that I was seeing.

-- 
Kevin Street
[EMAIL PROTECTED]


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Matthew Dillon


:Matthew Dillon [EMAIL PROTECTED] writes:
:
: :Two things I've noticed:
: :1) my cdrom delivers about 2M/s which is the same as before DMA.  Is
: :the improvement only in cpu usage or should I be seeing a speed
: :improvement too? 
: :
: :speed tested with:
: :dd if=/dev/racd0c of=/dev/null bs=64k count=320
: :(I get it to spin up with another dd before this test)
: 
: Well 2MB/sec == 14x CDRom drive.  Is it a 14x CDRom drive?  CDRom
: drives are typically limited to how quickly they can get data off
: the platter.  A faster bus transfer will not improve that.
:
:I should have mentioned that ... it's a 32x cdrom.  dmesg says it
:claims to be able to do 5515 KB/sec. 
:
:I've played around with using dd ... skip=n to reposition which part
:of the cd I'm reading and I've seen some much better speeds on the
:outer tracks (I think I now recall that cd's start numbering from the
:inside tracks, don't they?).  So you're probably right that it's just
:the rotational speed that I was seeing.
:
:-- 
:Kevin Street
:[EMAIL PROTECTED]

Dunno re: starting track.

All modern CDRom units have vibration sensors (actually I think they
just use the error rate from the head) and will adjust the rotational
speed based on that as well as on the rate the data is being requested
at.  So it will depend on the physical CD as well as other matters.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread David Scheidt

On 31 Aug 1999, Kevin Street wrote:

 Matthew Dillon [EMAIL PROTECTED] writes:
 
 I should have mentioned that ... it's a 32x cdrom.  dmesg says it
 claims to be able to do 5515 KB/sec. 
 
 I've played around with using dd ... skip=n to reposition which part
 of the cd I'm reading and I've seen some much better speeds on the
 outer tracks (I think I now recall that cd's start numbering from the
 inside tracks, don't they?).  So you're probably right that it's just

Almost all fast (12X or so) CD-ROM drives are variable speed.  You will see
much greater performance from the outer edge as from the inside edge.  You
are correct that the begining of the CD is in the center.  dd the whole disk
and use iostat to see what your transfer rates are.  They will go up as the
disk reaches the end.

David Scheidt



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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Soren Schmidt

It seems Kevin Street wrote:
 Two things I've noticed:
 1) my cdrom delivers about 2M/s which is the same as before DMA.  Is
 the improvement only in cpu usage or should I be seeing a speed
 improvement too? 

Depends.. There are many factors involved here, using DMA only lowers
the CPU usage, and will enable faster transfers if the problem was
that the CPU was saturated with the PIO transfer. It gave about 
double the transfer rate on my old P6 based maschine, because the
CPU drain was the limitting factor. Most modern CDROM are variable
speed, and you will see varying rates depending on the quality of
the media.

 2) I can crash my system (sometimes a panic, sometimes a freeze) with:
 dd if=/dev/racd0c of=/dev/null bs=1m count=1
 
 I could do bs=1m before the DMA code went in.  
 
 If the system freezes I see:
 atapi_error: READ_BIG - timeout error = 00
 long pause
 the dd puts out a message about transferring 0 records
 ata1: master: timeout waiting to give command s = d8 e = 00

Yup I know of that one, not sure how to fix it (right) yet...

-Søren


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



zsh problem after updating to -CURRENT

1999-08-31 Thread FreeBSD -- The Power to Serve


I recently cvsupped to -CURRENT, did successful make world and updated the
kernel..
Now I get errors in zsh even after compiling the port.. I'm using the
zsh-devel port which is basically 0-day since I updated ports too

Errors:
(from startup)
zsh in free(): warning: malloc() has never been called.
(after every command or carriage return)
su in free(): warning: junk pointer, too low to make sense.

Could this be a -CURRENT malloc problem? Thanks in advance!

-JD-



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



Re: followup to apm problems.

1999-08-31 Thread Nate Williams

 : And it seems there still are other devices which wake your PC up in
 : 2-3 mins time.
 : Hmmm, anyone has ideas?
 
 I think we need to set the interrupt mask to 0 in the PIC.

I don't think makes any difference, since the APM Bios is in charge of
what happens at this point, and the BIOS is below the level of the OS.



Nate


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Kevin Street

Soren Schmidt writes:

Depends.. There are many factors involved here, using DMA only lowers
the CPU usage, and will enable faster transfers if the problem was
that the CPU was saturated with the PIO transfer. It gave about 
double the transfer rate on my old P6 based maschine, because the
CPU drain was the limitting factor. Most modern CDROM are variable
speed, and you will see varying rates depending on the quality of
the media.

dd'ing the whole cd and watching with iostat shows speeds from 2M
increasing to 5.5M on the outside tracks with cpu staying at 
98% to 100% idle on a PII 400.  So DMA seems to be doing its stuff.

I did try checking for correct data coming off the cd as well, and saw 
no problems.
-- 
Kevin Street
[EMAIL PROTECTED]


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



Re: followup to apm problems.

1999-08-31 Thread Warner Losh

In message [EMAIL PROTECTED] Nate Williams writes:
:  I think we need to set the interrupt mask to 0 in the PIC.
: 
: I don't think makes any difference, since the APM Bios is in charge of
: what happens at this point, and the BIOS is below the level of the OS.
: 

The theory is that no more interrupts would come in.  However, I think
there is another reason that you might be right  "Standby" needs
to be able to wakeup on keyboard events, which needs interrupts
enabled...

Warner


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Peter Jeremy

David Scheidt [EMAIL PROTECTED] wrote:
Almost all fast (12X or so) CD-ROM drives are variable speed.

To put this a different way, the data on CD's is stored at a constant
lineal density (closely related to the wavelength of the laser).
Audio CDs are read using constant-linear-velocity, the angular
(rotational) speed reduces from the inside edge to the outside edge,
to maintain a constant data rate.  CD-ROM drives initially just copied
this approach.

Almost all fast CD-ROM drives now use constant-angular-velocity (which
simplifies the rotational mechanics and should improve seek times, at
the expense of slightly more complex read logic).  This means the the
lineal velocity (and hence data rate) increases from the inside
(start) to the outside (end) of the disk.

The quoted CD-ROM speeds are always based on the peak data rate
(and the better manufacturers actually quote the speed range).

Peter


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Warner Losh

In message [EMAIL PROTECTED] Kevin Street writes:
: I should have mentioned that ... it's a 32x cdrom.  dmesg says it
: claims to be able to do 5515 KB/sec. 

Is it a 32x cdrom or a 32x mamimum cdrom?  There have been many of the
big-num speed max, smaller-num speed average drives on the market in
the last few years.  14x does sound a little slow, but not outside the
realm of possibilities.

Warner


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



Help needed with debugging (was: 4.0-CURRENT SMP crash with vinum raid-5 and softupdates)

1999-08-31 Thread Greg Lehey

On Monday, 30 August 1999 at  7:53:12 +0200, Bernd Walter wrote:
 On Sun, Aug 29, 1999 at 04:48:32PM -0700, Matthew Dillon wrote:
 :
 :How similar?  The trap above is extremely bad; it looks like a return
 :on a corrupted stack or a jump through a null function vector.
 :
 :Make very sure that your vinum kld is in sync with your kernel.

 This looks like an indirect call through a NULL function pointer.

 In my case it is a call to bp-b_iodone in kern/vfs_bio.c:2580 which is 0 :(

We seem to have a specific problem here.  To summarize:

1.  It was first reported (by Bernd) on 15 August.

2.  The system crashes in biodone because the buffer header has the
B_CALL flag set, but the value of bp-b_iodone is NULL.

3.  bp-b_iodone is only set to NULL (well, 0) in one place:
getnewbuf, which I don't call.  It gets reset to a previous value
in dsiodone, which is about the only place where things could
conceivably go wrong.  I put some check code in at every
conceivable place, and the only place which found the situation
was in biodone.

4.  In every case, the fields just before b_iodone were also zeroed:

  b_dev = 0xc098d840,
  b_data = 0xc0befc00 "\2275\t",
  b_kvabase = 0x0,
  b_kvasize = 0x0,
  b_lblkno = 0x0,
  b_blkno = 0x0,
  b_offset = 0x0,
  b_iodone = 0,
  b_iodone_chain = 0x0,
  b_vp = 0xc5d4a700,

The b_dev and b_vp fields are OK, and b_data looks OK as well.
I'm guessing that something is overwriting some of the fields in
the header, but it's always the same, and I can't find anything in
the code that does that.

5.  In one case yesterday, there were two requests involved in the
vinum request.  The other one had already completed (been through
biodone), but the bp-b_iodone word was zeroed out in the same
manner.  In addition, other fields have been set by Vinum's iodone
function.  From this I deduce that the fields were zeroed after
biodone, which makes it very unlikely that it was done by Vinum.

I don't know how to proceed at the moment.  Matt Dillon has suggested
adding some dummy fields in the buffer header and setting them to
known values, but I expect this will drive the problem into hiding.
Instead, I'm migrating the whole thing to -STABLE to see if it happens
there.  In view of the impending release of 3.3, this makes sense
anyway.  In the meantime, if anybody has any ideas, or if any of this
rings a bell, I'd be grateful for feedback.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


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



Re: followup to apm problems.

1999-08-31 Thread Mike Smith

 In message [EMAIL PROTECTED] Nate Williams writes:
 :  I think we need to set the interrupt mask to 0 in the PIC.
 : 
 : I don't think makes any difference, since the APM Bios is in charge of
 : what happens at this point, and the BIOS is below the level of the OS.
 : 
 
 The theory is that no more interrupts would come in.  However, I think
 there is another reason that you might be right  "Standby" needs
 to be able to wakeup on keyboard events, which needs interrupts
 enabled...

Actually, that's almost entirely system-dependant.  The BIOS may well 
poll the keyboard controller/USB controller, for example.

-- 
\\  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: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Richard Tobin

 lineal velocity (and hence data rate) increases from the inside
 (start) to the outside (end) of the disk.

And consequently any CD that isn't completely full will *always*
be slower than the quoted ("guaranteed not to exceed") rate.

-- Richard


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



tput(1) appears broken.

1999-08-31 Thread Peter Edwards

Hi,
(Sorry if this hits the list a couple of times, I had some problems with my mail 
system)

I never thought I'd see "clear" break :-) Here's a fix.

It seems to be down to an ncurses change in tgetstr(). The implementation in ncurses 
just ignores the "area" parameter, while the one in libtermcap is does something quite 
bizzare with it. tput.c relies on the old functionality.

A better patch would probably be to the manpage, though. It doesn't even mention the 
"area" parameter, apart from in the synopsis.

I wonder if "cls" ever broke on DOS?
--
Peter.


*** tput.c.orig Wed Sep  1 00:00:14 1999
--- tput.c  Tue Aug 31 23:55:22 1999
***
*** 64,70 
extern char *optarg;
extern int optind;
int ch, exitval, n;
!   char *cptr, *p, *term, buf[1024], tbuf[1024];

term = NULL;
while ((ch = getopt(argc, argv, "T:")) != -1)
--- 64,70 
extern char *optarg;
extern int optind;
int ch, exitval, n;
!   char *cptr, *p, *term, *capstr, buf[1024], tbuf[1024];
 
term = NULL;
while ((ch = getopt(argc, argv, "T:")) != -1)
***
*** 105,112 
break;
}
cptr = buf;
!   if (tgetstr(p, cptr))
!   argv = process(p, buf, argv);
else if ((n = tgetnum(p)) != -1)
(void)printf("%d\n", n);
else
--- 105,112 
break;
}
cptr = buf;
!   if (capstr = tgetstr(p, cptr))
!   argv = process(p, capstr, argv);
else if ((n = tgetnum(p)) != -1)
(void)printf("%d\n", n);
else




_

Get your free E-mail at http://www.ireland.com


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



Re: HEADS UP! ATA driver (atapi DMA)..

1999-08-31 Thread Daniel O'Connor


On 31-Aug-99 Kevin Street wrote:
  Well 2MB/sec == 14x CDRom drive.  Is it a 14x CDRom drive?  CDRom
  drives are typically limited to how quickly they can get data off
  the platter.  A faster bus transfer will not improve that.
  I should have mentioned that ... it's a 32x cdrom.  dmesg says it
  claims to be able to do 5515 KB/sec. 

Which is slightly more correct..
32x = 32 * 150 = 4800 kb/s

1 spin = 150kb/sec

Of course given the advent of CLV drives a speed rating is now usually the
maximum read speed, not the average.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum

 PGP signature


Re: make -j 4 buildworld race problem

1999-08-31 Thread Bruce Evans

"make buildworld" completes without a problem.

"make -j 4 buildworld" gives:

libncurses now has lots of internal utilities.  Apparently the
dependencies for them are incomplete.  The utilities are are also
built at the wrong time and break cross compiling.  See the old curses
(libmytinfo part) for a (bad) way to handle internal utilities.
The right way to handle them is not to have any.

Bruce


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



kgzipped -STABLE GENERIC kernel boots on one machine, not the other

1999-08-31 Thread Mark J. Taylor


I've got a -STABLE GENERIC kernel, cvsupped and built this evening, that
is all
alone on a UFS floppy, and kgzipped.

My P-133 boots the -STABLE kernel fine.
My AMD-K6/2 400 stops immediately after "Uncompressing kernel ... done".

The same systems both can boot a -CURRENT GENERIC kgzipped kernel, from
the
same physical floppy, and run BOOTP/NFSROOT-ed (with minor changes to
kern/vfs_conf.c and a rc.diskless{12}).


Any ideas?  The AMD machine is an ASUS motherboard, and it's brand new.
Want me to try something?  ("boot -v" does not give any more
diagnostics)




-Mark Taylor
[EMAIL PROTECTED]
[EMAIL PROTECTED]


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



Re: make -j 4 buildworld race problem

1999-08-31 Thread Luoqi Chen

 Bruce Evans wrote:
  "make buildworld" completes without a problem.
  
  "make -j 4 buildworld" gives:
  
  libncurses now has lots of internal utilities.  Apparently the
  dependencies for them are incomplete.  The utilities are are also
  built at the wrong time and break cross compiling.  See the old curses
  (libmytinfo part) for a (bad) way to handle internal utilities.
  The right way to handle them is not to have any.
 
 After I sent the initial email, I started to look at the 
 Makefile for ncurses (and friends).  I knew that it had to
 be a dependence problem, but quite frankly I couldn't determine
 the (quick) fix.

Here's my quick fix:

Index: Makefile
===
RCS file: /home/ncvs/src/lib/libncurses/Makefile,v
retrieving revision 1.28
diff -u -r1.28 Makefile
--- Makefile1999/08/30 23:15:40 1.28
+++ Makefile1999/09/01 02:30:16
@@ -305,7 +305,7 @@
 make_keys: make_keys.c names.c
${CC} -o $@ ${CFLAGS} ${NCURSES}/ncurses/tinfo/make_keys.c
 
-make_hash: comp_hash.c
+make_hash: comp_hash.c hashsize.h
${CC} -o $@ ${CFLAGS} -DMAIN_PROGRAM \
${NCURSES}/ncurses/tinfo/comp_hash.c
 

-lq


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



Re: Problems with the latest changes to ifconfig (I guess) - Bad guess...

1999-08-31 Thread Ian Whalley

[Niels Chr. Bank-Pedersen wrote:]
After the recent changes to ifconfig and the xl driver I am
getting a panic when rc.network runs ifconfig:
Anybody else seeing this, or should I look somewhere else
alltogether?

I am seeing exactly the same breakage -- cvsup as of today,
mid-evening EDT.  This is the first -current build I've
done since if_xl was converted to miibus.

My card is identified as 3Com 3c905B-TX Fast Etherlink XL.

Best;

inw

-- 
Ian Whalley
first name @ last name . org


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



Re: Problems with the latest changes to ifconfig (I guess) - Badguess...

1999-08-31 Thread Peter Jeremy

Ian Whalley [EMAIL PROTECTED] wrote:
My card is identified as 3Com 3c905B-TX Fast Etherlink XL.

FWIW, I'm running a kernel about 30 hours old with a 3Com 3c905-TX
Fast Etherlink XL and I'm not seeing this problem.

At a quick quess, something in the miibus support broke the 3C905B
support.

Peter


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



xl driver problems on 3c905B-TX

1999-08-31 Thread Kevin Street

I'm getting a panic during an ifconfig on boot after building a kernel 
with the new xl driver.  This happens early in the boot so I don't have a
dump, but can probably arrange to get one if the dmesg output isn't
telling us something useful.  System is current as of about 7pm EDT
08/31.  The last working kernel I have is from 08/28.

The relevant dmesg and trap are:

xl0: 3Com 3c905B-TX Fast Etherlink XL irq 10 at device 10.0 on pci0
xl0: Ethernet address: 00:10:5a:c9:a4:5b
miibus0: MII bus on xl0
xlphy0: 3Com internal media interface on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xlphy1: 3Com internal media interface on miibus0
xlphy1: ignoring this PHY, non-zero instance
device_probe_and_attach: xlphy1 attach returned 6


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:0xc94f2dcc
frame pointer   = 0x10:0xc94f2de4
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 = 67 (ifconfig)
interrupt mask  = net
trap number = 12
panic: page fault
-- 
Kevin Street
[EMAIL PROTECTED]


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



Re: Problems with the latest changes to ifconfig (I guess) - Bad guess...

1999-08-31 Thread Luoqi Chen

 Ian Whalley [EMAIL PROTECTED] wrote:
 My card is identified as 3Com 3c905B-TX Fast Etherlink XL.
 
 FWIW, I'm running a kernel about 30 hours old with a 3Com 3c905-TX
 Fast Etherlink XL and I'm not seeing this problem.
 
 At a quick quess, something in the miibus support broke the 3C905B
 support.
 
 Peter
 
I got the same panic tonight. The xlphy attach function doesn't clean up
appropriately when it aborts, here's the fix.

Index: exphy.c
===
RCS file: /home/ncvs/src/sys/dev/mii/exphy.c,v
retrieving revision 1.3
diff -u -r1.3 exphy.c
--- exphy.c 1999/08/29 15:42:03 1.3
+++ exphy.c 1999/09/01 03:12:01
@@ -161,12 +161,6 @@
ma = device_get_ivars(dev);
sc-mii_dev = device_get_parent(dev);
mii = device_get_softc(sc-mii_dev);
-   LIST_INSERT_HEAD(mii-mii_phys, sc, mii_list);
-
-   sc-mii_inst = mii-mii_instance;
-   sc-mii_phy = ma-mii_phyno;
-   sc-mii_service = exphy_service;
-   sc-mii_pdata = mii;
 
/*
 * The 3Com PHY can never be isolated, so never allow non-zero
@@ -176,6 +170,12 @@
device_printf(dev, "ignoring this PHY, non-zero instance\n");
return(ENXIO);
}
+   LIST_INSERT_HEAD(mii-mii_phys, sc, mii_list);
+
+   sc-mii_inst = mii-mii_instance;
+   sc-mii_phy = ma-mii_phyno;
+   sc-mii_service = exphy_service;
+   sc-mii_pdata = mii;
 
mii-mii_instance++;
 

-lq


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



Re: Problems with the latest changes to ifconfig (I guess) - Bad

1999-08-31 Thread Bill Paul

Of all the gin joints in all the towns in all the world, Peter Jeremy 
had to walk into mine and say:

 Ian Whalley [EMAIL PROTECTED] wrote:
 My card is identified as 3Com 3c905B-TX Fast Etherlink XL.
 
 FWIW, I'm running a kernel about 30 hours old with a 3Com 3c905-TX
 Fast Etherlink XL and I'm not seeing this problem.
 
 At a quick quess, something in the miibus support broke the 3C905B
 support.

Not quite.

The original 3c905-TX NIC used an external NatSemi PHY chip which
was mapped to MII address 24. The 3c905B uses an internal transceiver,
which is also mapped to MII address 24 for compatibility purposes.
However, there are several different 3c905B ASIC revisions and
at least one of them, for some peculiar reason, maps the transceiver
to *all* MII addresses (0 through 31). Technically this isn't a
big problem since if you always assume that the PHY is at address
24 (which I sure is what 3Com's drivers do) you'll never notice
the difference. But you have to watch out for it.

The old code in if_xl.c would probe for PHYs and stop the moment
it encountered the first one, which would work fine: it would stop at 
address 0 for the broken ASIC and 24 for the working ones. But the miibus 
code probes at all addresses because there are some NICs that actually 
have more than one transceiver. But with the  buggy 3Com ASIC, we end up 
incorrectly trying to map the same PHY several times over, which the 
xlphy driver doesn't like, so the probe fails, the miibus attach fails, 
and bad things happen later.

I just committed a patch to -current to deal with this: the
xl_miibus_readreg() and xl_miibus_writereg() routines will not
only return values at MII address 24. This will make the buggy
ASIC appear to work correctly so that only one PHY instance will
be detected.

Why didn't I catch this earlier? Well, the 3c905B NIC that I tested 
happens to work correctly. So did the 3c905C that I tried after it.
In fact, I think the only place I encountered the buggy ASIC locally
is with the embedded 3c905B NIC in some of the Dell machines in the
lab, which aren't currently running FreeBSD.

Don't you just love hardware programming?

-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: gdb-4.17 in FreeBSD 4.0-CURRENT

1999-08-31 Thread Alex Zepeda

On Sun, 22 Aug 1999, Richard Cownie wrote:

 On Sat, 21 Aug 1999, David O'Brien wrote:
  Are you saying 4.17 is better than 4.18 for debugging C++?  Or are you
  saying you didn't know FreeBSD comes with gdb:
 
 gdb-4.18 is badly broken on all platforms (at least for C++).  You can't
 call methods from the gdb command line, and also it frequently freezes
 to the point where you have to kill the window.  gdb-4.17 is much better
 for C++. 

Really?  I don't use gdb much so, I wouldn't know, but I've seen reports
that KOffice is undebugable with 4.17 (gdb segfaults), but is with 4.18.
Hmm.

- alex



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



Re: gdb-4.17 in FreeBSD 4.0-CURRENT

1999-08-31 Thread Kip Macy

on 3.2-R gdb-4.18 will core dump without fail when I try to read a core
file generated by the C++ program I am developing - gdb-4.17 does not have
this problem.

-Kip

On Tue, 31 Aug 1999, Alex Zepeda wrote:

 On Sun, 22 Aug 1999, Richard Cownie wrote:
 
  On Sat, 21 Aug 1999, David O'Brien wrote:
   Are you saying 4.17 is better than 4.18 for debugging C++?  Or are you
   saying you didn't know FreeBSD comes with gdb:
  
  gdb-4.18 is badly broken on all platforms (at least for C++).  You can't
  call methods from the gdb command line, and also it frequently freezes
  to the point where you have to kill the window.  gdb-4.17 is much better
  for C++. 
 
 Really?  I don't use gdb much so, I wouldn't know, but I've seen reports
 that KOffice is undebugable with 4.17 (gdb segfaults), but is with 4.18.
 Hmm.
 
 - alex
 
 
 
 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