Re: apmconf(8) -e ends to panic in apm_bios_call

[Nate Williams]

> When I cvsuped, made and installed the new world and kernel on 1st May 1999,
> the kernel paniced in apm_bios_call called from apmconf(8) -e...

Does the BIOS of your laptop claim to have less memory than FreeBSD
claims?  If so, you need to use the 'MAXMEM' option to set the memory to
what your BIOS claims.


Nate


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Call for Review: Voxware midi driver for serial ports

[Seigo TANIMURA]

From: Juergen Lock 
Subject: Re: Call for Review: Voxware midi driver for serial ports
Date: Sun, 2 May 1999 02:15:00 +0200
Message-ID: <19990502021500.a3...@saturn.kn-bremen.de>

nox> On Tue, Apr 20, 1999 at 10:27:35AM +0900, Seigo TANIMURA wrote:
nox> > On Sun, 18 Apr 1999 22:15:05 +0200,
nox> >   Juergen Lock  said:
nox> > 
nox> > >> Another bad news, I tried driving my SC-88 connected directly to a PC 
using
nox> > >> Windows 95 and Portman PC/S driver, to find a miserable result. I saw 
no midi
nox> > >> messages come properly, so Portman PC/S should be cooking the signals 
in some way...
nox> > 
nox> > nox> Or uses a higher speed than 38k4, can you check that?  Hmm, or maybe
nox> > nox> i should just take my old Atari MSTe and use that as serial<->midi
nox> > nox> interface...
nox> > 
nox> > 
nox> > Bitrate > 38.4k... I wish I had a long serial cable. The PC I had a 
test
nox> > on the Portman driver is not in my room, and it is not a portable one.
nox> > 
nox> > Atari, I have only heard the name. I played with an Acorn when I was a 
kiwi.
nox> 
nox> Acorn, what CPU did it have again? :)

Sorry, it was not mine, so I have no idea. I remember that Acone had a FM 
synthesizer
in it, no midi interfaces. It sounded like a flat harpsichord, which was good 
at that
time(in 1993, six years ago).


nox>  Anyway I now have restored the m68k-atari crosscompiler from tape and made
nox> a little /dev/midi <-> /dev/modem2 connection program.  Well, it works!
nox> Now, does anyone know a sequencer program that has a tick display and
nox> that can record one track while playing back another?  rosegarden can only
nox> do one thing at a time...

Playing and recording simultaneously? I wish I knew one...


nox>  Oh and i had to patch this to get my kernel to build:
nox> 
nox> Index: i386/conf/files.i386
nox> @@ -225,8 +225,10 @@
nox>  i386/isa/sound/uart6850.c optionaluartdevice-driver
nox>  i386/isa/sound/uart16550.coptionaluartsio device-driver
nox>  i386/isa/sound/midi_synth.c   optionaluartdevice-driver
nox> +i386/isa/sound/midi_synth.c   optionaluartsio device-driver
nox>  i386/isa/sound/midi_synth.c   optionalcss device-driver
nox>  i386/isa/sound/midibuf.c  optionaluartdevice-driver
nox> +i386/isa/sound/midibuf.c  optionaluartsio device-driver
nox>  i386/isa/sound/midibuf.c  optionalcss device-driver
nox>  i386/isa/sound/trix.c optionaltrixdevice-driver
nox>  i386/isa/sound/adlib_card.c optionaltrixdevice-driver
nox> 
nox>  (the box has no sound card so these files were not compiled before.)

Fixed the patch, thanks!


Seigo TANIMURA   |M2, Nakagawa Lab, Dept of Electronics & CS
=|Faculty of Engineering, Yokohama National Univ
Powered by SIEMENS,  |http://www.naklab.dnj.ynu.ac.jp/~tanimura/
FreeBSD 4.0-CURRENT  |http://www.sakura.ne.jp/~tcarrot/
(25th Apr 1999) & muesli.|tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com

VoxWare Midi Driver for Serial Ports on FreeBSD:
http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/
Seigo TANIMURA   |M2, Nakagawa Lab, Dept of Electronics & CS
=|Faculty of Engineering, Yokohama National Univ
Powered by SIEMENS,  |http://www.naklab.dnj.ynu.ac.jp/~tanimura/
FreeBSD 4.0-CURRENT  |http://www.sakura.ne.jp/~tcarrot/
(25th Apr 1999) & muesli.|tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com

VoxWare Midi Driver for Serial Ports on FreeBSD:
http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Harlan Stenn]

The folks who did BitKeeper have a "compare/contrast" section in their web 
page that talks about BitKeeper vs. CVS and Perforce.



I'm running CVS at several places, and I'm going to try BitKeeper for a 
couple of projects.

H



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: IDE DMA timeouts (was: Kernel won't boot from IDE disk)

[Greg Lehey]

On Friday, 30 April 1999 at 10:49:39 -0500, Glenn Johnson wrote:
> On Fri, Apr 30, 1999 at 02:05:00PM +0930, Greg Lehey wrote:
>> On Thursday, 29 April 1999 at 10:10:43 -0500, Glenn Johnson wrote:
>>> I am doing a fresh installation. I installed the April 23, 1999 snapshot
>>> of STABLE and then cvsupped the CURRENT source (4.0 CURRENT). 
>>> ...
>>> Upon reboot, the system would hang after doing all of the probes. Below is 
>>> some
>>> of the output that I got from a boot -v. I wrote this down on paper, so the
>>> formatting may be a little off.
>>>
>>> isa_compat: didn't get drq for wdc1
>>> ...
>>> changing root device to wd0s1a
>>>
>>> At this point it hangs. But if I press a key on the keyboard I then get:
>>> wd0s1: type 0xa5, start 0, end = 3173183, size 3173184
>>> wd0s1: C/H/S end 197/132/63 (1659041) != end 3173183: invalid
>>> start_init: trying /sbin/init
>>> wd0: interrupt timeout (status 50 error 0)
>>> wd0: wdtimeout() DMA status 4
>>>
>>> This last two lines above are repeated 5x, then I get:
>>>
>>> wd0: Last time I say: interrupt timeout. Probably a portable PC.
>>>
>>> It is a desktop PC. I am not at the system now, so the following is from
>>> memory.  It is an AMI BIOS, a Western Digital 1.6 GB IDE drive on the
>>> primary IDE and a Mitsumi 4x CD-ROM drive on the secondary IDE.
>>
>> What's your chipset?  If it's an SiS 5591, I'd be interested in seeing
>> your complete dmesg output (preferably with a -v output).  You'll also
>> be able to get it to work by changing the wdc0 flags to eliminate DMA.
>
> The IDE controller chip is an Intel PIIX3 Bus Master IDE controller. I
> did turn off all flags, via boot -c, then deleting the flags. That did
> not help.

Ah, OK.  Not the problem I was afraid of.  Sorry, I can't help on this
one.

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FBSDBOOT.EXE

[Mike Smith]

> Won't fbsdboot.exe be able to boot /boot/loader?  (maybe I am just naive)
> (or could it be modified to do so with little effort?)

We've had this discussion.  No.

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: mem.c v1.57 and mp_machdep.c v1.99 and kernel panic

[Mike Smith]

Whoops, fixed.  Sorry about that.

> Kernels built with these panic at mem_range_AP_init() on a dual
> pentium system. The cvs log entries for mem.c and mp_machdep.c,
> v1.57 and v1.99 respectively, indicate that the hook
> (mem_range_softc.mr_op->initAP()) is for the i686 and seems to have
> NULL entry for a pentium.
> 
> dave adkins
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 

-- 
\\  Sometimes you're ahead,   \\  Mike Smith
\\  sometimes you're behind.  \\  m...@smith.net.au
\\  The race is long, and in the  \\  msm...@freebsd.org
\\  end it's only with yourself.  \\  msm...@cdrom.com




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FBSDBOOT.EXE

[Jordan K. Hubbard]

> Does this mean that install.bat will disappear as well?

It already did.

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

Oh, very well, I'll have to say Perforce isn't that bad- it's just that it
doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole
branch and revision histories.. It doesn't have a 3-way filemerge tool (I
still fire up teamware (what NSElite became) to do heavy merging and use
the automerge feature)... Perforce *does* have the disparate release
stream feature, but I have found it somewhat difficult to use. Perhaps if
I'd actually had the depot locally I'd feel more at home with it


> > Bitkeeper is a substantial improvement over CVS and Perforce. It's really
> 
> WHat are the improvements compared to Perforce ? I've begun looking at it and
> if we forgot the Open Source argument (one that the FreeBSD project can't
> forget), it is really a very nice SCM.
> 
> They even give free licenses to people writing/maintaining free software. I
> know, I just got mine.
> 
> User name: roberto
> Client name: dotfiles
> Client root: /users/staff/roberto
> Current directory: /tmp
> Client address: 193.56.58.65:2838
> Server address: keltia.freenix.fr:1666
> Server root: /work/p4home
> Server version: P4D/FREEBSD/99.1/10314 (1999/03/31)
> Server license: Robert Ollivier  10 users on freebsd 
> (support ends 2000/04/26) 
> 
> -- 
> Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
> FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FBSDBOOT.EXE

[Greg Lehey]

On Saturday,  1 May 1999 at 17:54:26 -0700, Jordan K. Hubbard wrote:
>> Is there anybody out there working on upgrading fbsdboot.exe so that it can
>> recognize ELF?
>
> I believe that fbsdboot.exe has, instead, simply been retired.  Sorry
> I don't have better news than this.

Does this mean that install.bat will disappear as well?

Greg
--
See complete headers for address, home page and phone numbers
finger g...@lemis.com for PGP public key


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Ollivier Robert]

According to Harlan Stenn:
> I'm mostly interested in the "lines of development" features, the ability 
> to check in various revisions of my *local* work, the ability to apply a 
> patch set as an atomic unit, and several of the GUI tools.

Perforce has all that.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Ollivier Robert]

According to Matthew Jacob:
> Bitkeeper is a substantial improvement over CVS and Perforce. It's really

WHat are the improvements compared to Perforce ? I've begun looking at it and
if we forgot the Open Source argument (one that the FreeBSD project can't
forget), it is really a very nice SCM.

They even give free licenses to people writing/maintaining free software. I
know, I just got mine.

User name: roberto
Client name: dotfiles
Client root: /users/staff/roberto
Current directory: /tmp
Client address: 193.56.58.65:2838
Server address: keltia.freenix.fr:1666
Server root: /work/p4home
Server version: P4D/FREEBSD/99.1/10314 (1999/03/31)
Server license: Robert Ollivier  10 users on freebsd 
(support ends 2000/04/26) 

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FBSDBOOT.EXE

[Jordan K. Hubbard]

> Won't fbsdboot.exe be able to boot /boot/loader?  (maybe I am just naive)
> (or could it be modified to do so with little effort?)

Good question - you tell me. :)

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> Well, I'm not philosophically opposed to a clearly superior solution,
> I simply don't want to see us make any moves which involve so many
> messy trade-offs that we end up wasting more time embroiled in debate
> than we save with the new tool.
> 
> My suggestion would be to wait and see how bitkeeper pans out.  Enough
> people in the Linux camp have already looked at CVSup and gone "ooh,
> sexy!"  that I think there will already be significant pressure to
> develop similar tools for the bitkeeper environment.  When that
> happens, we can start to look at this more seriously.

Well, that's fine too, then...




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Jordan K. Hubbard]

Well, I'm not philosophically opposed to a clearly superior solution,
I simply don't want to see us make any moves which involve so many
messy trade-offs that we end up wasting more time embroiled in debate
than we save with the new tool.

My suggestion would be to wait and see how bitkeeper pans out.  Enough
people in the Linux camp have already looked at CVSup and gone "ooh,
sexy!"  that I think there will already be significant pressure to
develop similar tools for the bitkeeper environment.  When that
happens, we can start to look at this more seriously.

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FBSDBOOT.EXE

[David E. Cross]

Won't fbsdboot.exe be able to boot /boot/loader?  (maybe I am just naive)
(or could it be modified to do so with little effort?)

--
David Cross   |  email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer |  Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, |  Ph: 518.276.2860
Department of Computer Science|  Fax: 518.276.4033
I speak only for myself.  |  WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: (FWD) Re: Progs linked against libstdc++ dead...

[Keith Walker]

John Polstra wrote:

> David O'Brien wrote:
>
> > Since the Linux config files specify DEFALUT_VTABLE_THUNKS=1, no one
> > has posted a bug report related to them, there is an option to turn
> > them off, and this *is* -CURRENT. I may just leave them turned on by
> > default.
> >
> > Opinions?
>
> I think that's the best solution for now.
>

Especially since the bug that may be caused by vtable thunks is greatly
outweighed by the Bug Of Not Working At All :-)

--
Keith Walker, Spokane, WA
FreeBSD 4.0-CURRENT (ASUS) #39: Sat May  1 17:47:40 PDT 1999





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

mem.c v1.57 and mp_machdep.c v1.99 and kernel panic

[dave adkins]

Kernels built with these panic at mem_range_AP_init() on a dual
pentium system. The cvs log entries for mem.c and mp_machdep.c,
v1.57 and v1.99 respectively, indicate that the hook
(mem_range_softc.mr_op->initAP()) is for the i686 and seems to have
NULL entry for a pentium.

dave adkins





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: FBSDBOOT.EXE

[Jordan K. Hubbard]

> Is there anybody out there working on upgrading fbsdboot.exe so that it can
> recognize ELF?

I believe that fbsdboot.exe has, instead, simply been retired.  Sorry
I don't have better news than this.

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> > Look- if Linux adopts Bitkeeper, you really should pay attention to that.
> > I doubt you'd find a more difficult set of software engineers to keep code
> > in sync for than the Linux folks- if Bitkeeper works for them and
> > essentially makes a rational release train for Linux, then a major
> > glaring flaw in Linux' strategy that keeps serious businesses from really
> > being able to trust it will be removed. Think about it.
> 
> I think this all fails to address the distribution problem, however.
> Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb,
> all interfaces in extremely common use today?  It's not just enough to
> say "something will be worked out" as an answer either, not when
> contemplating a move which will remove services currently in heavy
> operational use.  Think about it. :)

I'll try, but it hurts my head ("Why, Ale, man! Ale's the stuff to drink,
for them whom it hurts to think!"...)

I wasn't suggesting that we jump..I would like to see a plan. I believe
BitKeeper and other tools are a good set of tools for the next 5-10 years
for *development*. 

*Distribution* is a separate issue. Again, CVS is a fine tool for
distribution and asymmetric (biased toward a higher level of outbound
source changes) development. It all depends on what we want. And I'll have
to admit that distribution of binaries && source is not something that
always is on the top of my list (well, *I'm* not working for a software
distribution company...:-))..

My comment about 'think about it' is that if Linux gets it's chaotic
source non-management corrected and is able to successfully coordinate all
the relatively anarchic and free running clock different groups  then the
'predictability and reproducibility' concerns of commercial buyers are
closer to being met (which is silly because of how really chaotic internal
company release spasms are, SGI being a notorious example- but there it
is).

If FreeBSD (and NetBSD and OpenBSD) are to continue the way it is now, CVS
is probably a good enough tool. However, if you incorporate something
like BitKeeper into the picture, then it actually becomes technically more
feasible to even begin *considering* a *BSD coordination- you start to
have to toolset that can manage large amounts of code that is mostly alike
but differs in enough ways to be too hard to just merge this week.

But then again you might say, "Pshaw- Matt's been smokin' some serious
rope again".






To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Jordan K. Hubbard]

> Look- if Linux adopts Bitkeeper, you really should pay attention to that.
> I doubt you'd find a more difficult set of software engineers to keep code
> in sync for than the Linux folks- if Bitkeeper works for them and
> essentially makes a rational release train for Linux, then a major
> glaring flaw in Linux' strategy that keeps serious businesses from really
> being able to trust it will be removed. Think about it.

I think this all fails to address the distribution problem, however.
Let's say we adopt bitkeeper - what becomes of CTM, CVSup and CVSWeb,
all interfaces in extremely common use today?  It's not just enough to
say "something will be worked out" as an answer either, not when
contemplating a move which will remove services currently in heavy
operational use.  Think about it. :)

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: silo overflows in CURRENT ... some info that may help

[Doug Russell]

On Sun, 2 May 1999, Matthew Thyer wrote:

> I have been investigating the silo overflow situation for some time.
> 
> I can trigger them every time by the following action:
> 
> - Run M.A.M.E. (Multi arcade machine emulator) and then try to
> download something. (I am using user mode ppp).

Can you nice M.A.M.E. slightly?

Later.. 





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: if_xl.c noise

[Matthew Dillon]

:
:You could have answered this yourself by checking in
:/pub/FreeBSD/FreeBSD-current/src/sys/pci/if_xl.c on ftp.cdrom.com.
:Yes, this is only your repository; you must be using some patches
:from Matt Dillon for NFS. The code in -current has the change that
:he made already in it (but with a different comment). Grab a fresh
:copy of if_xl.c and if_xlreg.h from -current and stick with it.
:
:-Bill

He probably did.  I meant to remove those from my NFS stuff... they're
gone now.  Hopefully the NFS patches ( non-inclusive of the xl stuff )
will be committed soon.

-Matt


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

apmconf(8) -e ends to panic in apm_bios_call

[Seigo TANIMURA]

Hi!


When I cvsuped, made and installed the new world and kernel on 1st May 1999,
the kernel paniced in apm_bios_call called from apmconf(8) -e...

[sys/i386/apm/apm_setup.s:_apm_bios_call]
movl8(%ebp),%ecx
movl4(%ebp),%ebx
movl0(%ebp),%eax
pushl   %ebp
lcall   _apm_addr   <--- paniced here
popl%ebp
movl%eax,0(%ebp)
 

Strangely, the kernel attaches the APM BIOS without any problem at all.

[a part of /var/log/messages with APM_DEBUG]
May  1 14:15:20 silver /kernel: apm0:  on motherboard
May  1 14:15:20 silver /kernel: apm: APM BIOS version 0102
May  1 14:15:20 silver /kernel: apm: Code32 0xc00f, Code16 0xc00f, Data 
0xc00fdbd0
May  1 14:15:20 silver /kernel: apm: Code entry 0x78a8, Idling CPU 
disabled, Management enabled
May  1 14:15:20 silver /kernel: apm: CS32_limit=0x1e, CS16_limit=0x1e, 
DS_limit=0x66ae
May  1 14:15:20 silver /kernel: apm: Engaged control enabled
May  1 14:15:20 silver /kernel: apm: found APM BIOS version 1.2
May  1 14:15:20 silver /kernel: apm: Slow Idling CPU disabled
May  1 14:15:20 silver /kernel: Add hook "default suspend"
May  1 14:15:20 silver /kernel: Add hook "default resume"
May  1 14:15:20 silver /kernel: called apm_event_enable()


On attaching, apm_event_enable() calls apm_bios_call successfully.

I traced to watch _apm_addr, which pointed the correct entry(0x78a8)
in both situations. The only one difference was CS... Has anyone got a clue?


Thanks in advance!


Seigo TANIMURA   |M2, Nakagawa Lab, Dept of Electronics & CS
=|Faculty of Engineering, Yokohama National Univ
Powered by SIEMENS,  |http://www.naklab.dnj.ynu.ac.jp/~tanimura/
FreeBSD 4.0-CURRENT  |http://www.sakura.ne.jp/~tcarrot/
(25th Apr 1999) & muesli.|tanim...@naklab.dnj.ynu.ac.jp tcar...@sakuramail.com

VoxWare Midi Driver for Serial Ports on FreeBSD:
http://www.naklab.dnj.ynu.ac.jp/~tanimura/freebsd-serialmidi/


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: if_xl.c noise

[Bob Bishop]

Hi,

At 5:59 pm -0400 1/5/99, Bill Paul wrote:
>[...]>Yes, this is only your repository; you must be using some patches
>from Matt Dillon for NFS.

Argh. Pointy hat please - didn't notice "C src/sys/pci/if_xl.c" staring me
in the face.


--
Bob Bishop  (0118) 977 4017  international code +44 118
r...@gid.co.ukfax (0118) 989 4254  between 0800 and 1800 UK




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: if_xl.c noise

[Bill Paul]

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

> Hi,
> 
> Does version 1.34 of if_xl.c really look like the following around line
> 1886, or is my repository hosed?

You could have answered this yourself by checking in
/pub/FreeBSD/FreeBSD-current/src/sys/pci/if_xl.c on ftp.cdrom.com.
Yes, this is only your repository; you must be using some patches
from Matt Dillon for NFS. The code in -current has the change that
he made already in it (but with a different comment). Grab a fresh
copy of if_xl.c and if_xlreg.h from -current and stick with it.

-Bill

-- 
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home:  wp...@skynet.ctr.columbia.edu | 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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Linux char devices (was: Porting Greg Lehey's rawio.c from FreeBSD to Linux...)

[Brad Knowles]

On Sat, May 1, 1999, Greg Lehey  wrote:

>On Friday, 30 April 1999 at 21:25:12 -0700, Matt Jacob wrote:

>> There are no raw devices in Linux. Linus is totally against them as
>> stupid. Linus has some good points about this, but it's still an, um,
>> interesting stance.
>
>It also makes it impossible for rawio to run accurately.  rawio
>measures device throughput, not system throughput.  Cache the data and
>you completely lose this ability (hey!  Under Vinum, an array of four
>floppies has a random read throughput of 50 MB/s!).

It also makes it rather hard for programs like Oracle or Sybase to
run and use raw devices for their databases, so you instead wind up
polluting your buffer cache no matter what.  As I understand it, the
Oracle guys finally pounded into his brain the importance of real raw
device access, and they are starting to take some steps towards fixing
this problem in 2.2.x.


Anyway, a friend of mine just yesterday actually got rawio.c to work
under Linux.  He ended up having to make some changes to rawio, as well
as some changes to the way mmap() is implemented.  Let me quote his
entire message on this subject:

>On Fri, Apr 30, 1999 at 03:37:03PM +0200, Brad Knowles wrote:
>> Anyway, if there's anyone out there with any experience in porting
>> programs that do low-level disk I/O, I'd appreciate it if you could take
>> a look at this program and give me some pointers on what it would take to
>> get it to compile and run under Linux (specifically, Debian Linux with
>> kernel 2.2.6).
>
>
>
>Ok, I decided to work on this a bit and I had no idea the trouble I'd run
>into  I ported rawio to Red Hat Linux 5.2 pretty easily--it took about
>fifteen minutes.  Here's a summary of changes:
>
>a few more #includes (sys/ioctl.h, among others)
>swap out the BSD disklabel.h for linux/genhd.h and rename struct disklabel 
>   to struct bsd_disklabel (from linux/genhd.h)
>add srandomdev() from FreeBSD sources
>delete MAP_INHERIT from mmap()--no exec's in the program, so not useful--
>   good thing, because linux doesn't support it
>
>This wasn't too bad.  Then I tried to run it and got the "Can't mmap shared
>memory: Invalid argument" message.  Aargh.  It works fine under OpenBSD.
>After perusing the mmap() man pages, I think that everything's ok. I run
>rawio with strace and find this:
>
>mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = \
>   0x4010
>...
>mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0) = -1 \
>   EINVAL
>_exit(1)
>
>I think, "Huh.  mmap() with the MAP_PRIVATE flag works fine.  mmap() with
>the MAP_SHARED flag returns EINVAL.  That's dumb."  I check the man page
>again and look at the reasons for EINVAL--nothing different if it's private
>or shared.  So, I figure it is a kernel bug and check out the kernel source
>for mmap.  Sure enough, in some function do_mmap():
>
>if (file != NULL) {
>...
>} else if ((flags & MAP_TYPE) != MAP_PRIVATE)
>   return -EINVAL;
>
>So (on a development/test/guinea pig/sacrificial lamb machine) I remove this
>offensive bit of code, recompile the kernel, reboot, and voila, rawio can
>actually communicate between the parent and the child processes,  just like
>it should have been able to in the first place.
>
>Of course, now I wonder why this code was there in the first place  I'm
>not so expert a kernel hacker that I can definitively say that this is a
>ridiculous bit of of non-logic, but it sure did interfere with rawio
>
>
>
>Anyway, I half ported it to Linux and half ported Linux to the rest of the
>world.  You can get the patches at:
>
>ftp://mvhs1.mbhs.edu/pub/linux/linux-2.2.5-mmap.patch  (kernel patch)
>ftp://mvhs1.mbhs.edu/pub/linux/rawio-linux.patch   (patch to author src)
>ftp://mvhs1.mbhs.edu/pub/linux/rawio-linux.tar.gz  (patched srcs)
>ftp://mvhs1.mbhs.edu/pub/linux/rawio.tar.gz(author src)
>
>Now you can run your benchmark tests against buffered device files to your
>heart's content.:)
>
>P.S.  Keep in mind that you'll have to specify the device size manually.  On
>BSD, rawio can read the disklabel and get the size from there.  I didn't go
>to the trouble of reimplementing the device size for ext2fs labels.  So,
>unless you are running rawio under Linux against a BSD disk, the disklabel
>code won't help you much.  ;)
>-- 
>Matt Shibla  mshi...@mbhs.edu   (301) 649-2880 (vox)  (301) 649-2830 (fax)
>   Maryland Virtual High School   Montgomery Blair High School
>  51 University Boulevard East Silver Spring, MD  20901
>PGP Key:  http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0x8918CBCD


I don't suppose anyone here knows why this piece of do_mmap() is
written this particular way, and if there's any harm in removing that code?


TIA!

-- 
Brad Knowles  


Your mouse has moved.   Windows NT must be restarted

if_xl.c noise

[Bob Bishop]

Hi,

Does version 1.34 of if_xl.c really look like the following around line
1886, or is my repository hosed?

<<< if_xl.c
/*
 * Force longword alignment for packet payload for all cpus.  This
 * will optimize NFS ops which have to realign unaligned buffers.
 */
===
/* Force longword alignment for packet payload. */
>>> 1.34
m_new->m_data += 2;
<<< if_xl.c

===

>>> 1.34
c->xl_mbuf = m_new;
c->xl_ptr->xl_status = 0;
c->xl_ptr->xl_frag.xl_addr = vtophys(mtod(m_new, caddr_t));
c->xl_ptr->xl_frag.xl_len = MCLBYTES | XL_LAST_FRAG;

return(0);



--
Bob Bishop  (0118) 977 4017  international code +44 118
r...@gid.co.ukfax (0118) 989 4254  between 0800 and 1800 UK




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Doug Rabson]

On Sat, 1 May 1999, Doug Rabson wrote:

> On Sat, 1 May 1999, Zach Heilig wrote:
> 
> > I found the commit that "broke" sound (beyond that, I don't know how
> > to fix it):
> 
> Now this is interesting. You are saying that the previous mega-commit (the
> new-bus one) didn't break sound? That gives us a bit more to go on.

I have managed to reproduce the problem with some old hardware. I have to
rearrange things a bit to debug it but I'll see what I can do tomorrow.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> That sounds like it would be time well spent. I like the sound of
> Bitkeeper a lot. I just want someone else to test it :-).

You and everyone else!




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Doug Rabson]

On Sat, 1 May 1999, Matthew Jacob wrote:

> 
> > I agree about CVS' limitations completely. I know that a lot of Linux
> > projects are under their own CVS control but what kind of history is
> > available for code once it reaches Linus?  Does Linus have a CVS
> > repository which stores file-by-file history for the kernel?
> 
> No. That's what Bitkeeper and some of the retroactive release stream
> reconstruction that Larry's been doing is about.

That sounds like it would be time well spent. I like the sound of
Bitkeeper a lot. I just want someone else to test it :-).

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> I agree about CVS' limitations completely. I know that a lot of Linux
> projects are under their own CVS control but what kind of history is
> available for code once it reaches Linus?  Does Linus have a CVS
> repository which stores file-by-file history for the kernel?

No. That's what Bitkeeper and some of the retroactive release stream
reconstruction that Larry's been doing is about.





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Doug Rabson]

On Sat, 1 May 1999, Matthew Jacob wrote:

> > 
> > > 
> > > :BitKeeper should be ready soon.
> > > :
> > > :Once it's been proven stable, might it be a better alternative to CVS?
> > > :
> > > :H
> > > 
> > > Maybe, but we wouldn't know for a couple of years.  You don't just go
> > > trusting 15+ years worth of source history to a program that has just
> > > barely been written.  I think the Linux people are making a huge 
> > > mistake
> > > by not using CVS.
> > 
> > My thoughts almost exactly (I think the Linux people have already made a
> > huge mistake and are compounding it).
> > 
> 
> But they are using CVS- sparclinux has been under anon CVS for years.
> 
> The problem with CVS is that it *just doesn't work* if you try and have
> truly separate development streams. Branches and corrupted trees and
> directory renames are as pleasant and easy in CVS as trying to deal
> with Charles Hannum and Jason Thorpe in NetBSD (crazed weasels on
> angel dust going for your nether body parts is a comparative tickle). And
> don't even *begin* to talk about merging...
> 
> Don't get me wrong- *I* like CVS and how it's used for FreeBSD right now.
> But if you begin to have separate branch development models and want to
> really have a flexible source tree that you can repartition and repackage
> at will, CVS is not your friend.

I agree about CVS' limitations completely. I know that a lot of Linux
projects are under their own CVS control but what kind of history is
available for code once it reaches Linus?  Does Linus have a CVS
repository which stores file-by-file history for the kernel?

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> 
> > 
> > :BitKeeper should be ready soon.
> > :
> > :Once it's been proven stable, might it be a better alternative to CVS?
> > :
> > :H
> > 
> > Maybe, but we wouldn't know for a couple of years.  You don't just go
> > trusting 15+ years worth of source history to a program that has just
> > barely been written.  I think the Linux people are making a huge mistake
> > by not using CVS.
> 
> My thoughts almost exactly (I think the Linux people have already made a
> huge mistake and are compounding it).
> 

But they are using CVS- sparclinux has been under anon CVS for years.

The problem with CVS is that it *just doesn't work* if you try and have
truly separate development streams. Branches and corrupted trees and
directory renames are as pleasant and easy in CVS as trying to deal
with Charles Hannum and Jason Thorpe in NetBSD (crazed weasels on
angel dust going for your nether body parts is a comparative tickle). And
don't even *begin* to talk about merging...

Don't get me wrong- *I* like CVS and how it's used for FreeBSD right now.
But if you begin to have separate branch development models and want to
really have a flexible source tree that you can repartition and repackage
at will, CVS is not your friend.





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Doug Rabson]

On Sat, 1 May 1999, Zach Heilig wrote:

> I found the commit that "broke" sound (beyond that, I don't know how
> to fix it):

Now this is interesting. You are saying that the previous mega-commit (the
new-bus one) didn't break sound? That gives us a bit more to go on.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

FBSDBOOT.EXE

[Carlos C. Tapang]

Is there anybody out there working on upgrading fbsdboot.exe so that it can
recognize ELF?

Carlos C. Tapang
http://www.genericwindows.com



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Doug Rabson]

On Sat, 1 May 1999, Matthew Dillon wrote:

> 
> :BitKeeper should be ready soon.
> :
> :Once it's been proven stable, might it be a better alternative to CVS?
> :
> :H
> 
> Maybe, but we wouldn't know for a couple of years.  You don't just go
> trusting 15+ years worth of source history to a program that has just
> barely been written.  I think the Linux people are making a huge mistake
> by not using CVS.

My thoughts almost exactly (I think the Linux people have already made a
huge mistake and are compounding it).

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Problems with ahc (2940U2W) and USB

[Nick Hibma]

Did I miss an update on this? Could you guys drop me the output of dmesg
(after a boot -v if possible)?

Cheers,

Nick


On Wed, 28 Apr 1999, Jim Bloom wrote:

> Add me to the list of people seeing this problem.  I have an ASUS P2B-S with
> onboard Adaptec 7890.  I have been seeing the problem on and off since 
> December
> of last year.  One time it boots and the next time it doesn't.  Once the disk 
> is
> hung, the reset switch or power cycling are the only ways to unfreeze it.
> 
> I have seen this problem mentioned on both freebsd-current and freebsd-scsi
> several times without a solution.  I don't recall a link to USB being 
> mentioned
> before.
> 
> I'll try to post my dmesg output later this tonight.
> 
> Jim Bloom
> bl...@acm.org
> 
> 
> Rick Whitesel wrote:
> > 
> > Hi:
> > I am seeing the same thing on a ASUS P2B with a Adaptec 2940??
> > controller.
> > 
> > Rick
> > 
> > - Original Message -
> > From: 
> > To: 
> > Sent: Wednesday, April 28, 1999 11:38 AM
> > Subject: Problems with ahc (2940U2W) and USB
> > 
> > With the current sources, there seems to be a problem with the Adaptec
> > 2940U2W driver when using USB.
> > 
> > Whenever I try to boot a kernel with the USB driver, the boot process
> > gets to the "Waiting 15 seconds for SCSI devices to settle" and stops.
> > If I compile a kernel with an nearly identical config, only the USB
> > driver has been commented out, it boots all right.
> > 
> > My computer has a Spacewalker 661 mainboard, which is a 440BX based card.
> > The SCSI controller is an Adaptec 2940U2W.
> > 
> > Kernels compiled before the integration of new-bus works fine.
> > 
> > Now, this is not a critical situation for me, as I have no USB devices,
> > but I thought someone else would want this information.
> > 
> > Anyone else experiencing this?
> > 
> > --
> > +---+
> > Erik H. Bakke, Habatech AS  | To be or not to be... |
> > E-Mail: e...@habatech.no| Is simply a question of binary logic. |
> > This message was sent by XFMail |   |
> > +---+
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-current" in the body of the message
> > 
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-current" in the body of the message
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 

-- 
e-Mail: hi...@skylink.it



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> As I understand it, BitKeeper is indeed based on SCCS, and is a superset of 
> it.  The performance hit of SCCS has been "solved".
> 
> There are several "significant" commercial users of BitKeeper waiting for 
> the first production release, and Larry McVoy seems to be a bit of a maniac 
> when it comes to things being production stable.
> 
> He said that a CVS->BitKeeper conversion tool is not far off.

Cool!


> 
> I'm mostly interested in the "lines of development" features, the ability 
> to check in various revisions of my *local* work, the ability to apply a 
> patch set as an atomic unit, and several of the GUI tools.
> 

Amen to that




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> So will bitkeeper provide a nice interface for migrating code from an
> existing and well-established CVS repository to whatever they use?

They have tools for RCS to SCCS- I dunno about CVS tho...

> 
> I'm quite happy to allow them to test bitkeeper in a production
> environment before using it in one myself, needless to say. :)

fair enuff




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: -stable vs -current (was Re: solid NFS patch #6... )

[David Greenman]

>> point, we shouldn't be merging stuff back into the -stable branch, only fix
>> specific straightforward problems that don't require complete
>> re-engineering.
>
>No new features means stagnation in development. It means that someone
>coming to FreeBSD and looking for a feature will only find it in -current,
>which, by virtue of being -current, will have other miscellaneous problems.
>This person gets annoyed and leaves. 

   Sorry, but this just isn't how our development model has worked over the
past 6 years. -stable means it and we are not going to change that. -current
is for new features. The only new features that are added to -stable are
those which don't affect existing functionality and architectural changes are
to be avoid as much as possible. This has been a winning model for us and
we're not going to change it.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Sv: ep0 *UTP*

[Leif Neland]

- Oprindelig meddelelse -
Fra: Soren Schmidt 
Til: Dag-Erling Smorgrav 
Cc: ; ;

Sendt: 1. maj 1999 14:22
Emne: Re: ep0 *UTP*

> To get back to the subject, the default interface type (AUI/BNC/UTP)
> are store in an EEPROM on board, this default is shown in the probe.
> The default can be changed with a DOS util from 3COM.

There even exists a linux util which does that.
However, it doesn't run 'out of the box', but as long as my card works, I
won't bother doing more about it.

Leif




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...

[Bruce Evans]

>> >Linux' fsync() works only on directories, not on files.
>> 
>>Huh? That doesn't make any sense. The "f" in fsync() stands for "file".
>
>It does write the file to the disk but not the inode. To get the inode
>on the disk you have to fsync() the directory (which sync'ed the whole
>FS before 2.0.35). Kinda stupid...

fsync() can't reasonably sync everything on filesystems with async metadata.
It think it should sync the file's contents and inode, but not directory
entries pointing to the inode.  fsync() on the directories containing the
entries that you care about seems reasonable.

>If you can't believe it:
>http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/05/threads.html#00691

No one mentioned the POSIX.1b way, perhaps because it has only been
standard for 4-5 years.  It has:

__POSIX_FSYNC feature test macro.  If this is defined, then fsync() exists
and synchronizes the file to an implementation-defined stage.

__POSIX_SYNCHRONIZED_IO feature test macro.  If this is defined,
then fsync() synchronizes to completion.  Also, fdatasync() exists
and synchronizes the file's contents, like Linux's fsync() does.  Also,
there are open flags ODSYNC, O_RSYNC and O_SYNC.  O_SYNC and O_DSYNC have
similar semantics to fsync() and fdatasync().  O_RSYNC is to synchronise
metadata changed by reads (mainly access timestamps).

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Further on tape & CAM problems

[Wilko Bulte]

[ should we keep this on -current ?? ]

As Bob Willcox wrote ...
> On Fri, Apr 30, 1999 at 12:36:25AM +0200, Wilko Bulte wrote:
> > As Bob Willcox wrote ...
> > > On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
> > > > As Bob Willcox wrote ...
> > > > > On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:

> > > Hmm, why is that?  The newest of the IBM branded Exabyte 8200's that I
> > 
> > That is what I've been told by an Exabyte engineer years back. I can only
> > guess that some OEMs need adaptations to the firmware behaviour that are
> > incompatible with what the rest of the world needs (or has standardised
> > on, e.g. in the ANSI SCSI standard). Again, guessing.
> 
> Well, I can only speak for the IBM OEM'd drives that I have (as a
> retired IBMer, I've been picking them up at their employee surplus
> store here in Austin, TX).  For these drives the generic firmware works
> just fine.  I can see why Exabyte wouldn't openly recommend the change
> though.

The hardware is probably the same, so an EPROM swap brings them to
the generic model.

> recall that we did have some customizations in the firmware for the
> RS/6K AIX systems.  In addition to changing the Inquiry command Vendor
> ID data, I believe there were some functional changes (I don't recall
> the details).  I have always suspected that the functional changes are
> likely what made the IBM OEM'd drives fail on FreeBSD!  The upgraded
> firmware IBM drives work on both (as "Other SCSI Tape Drive").

That is quite possible. And it matches the recommendation of the
Exabyte engineer.

> > Mine works OK with that f/w. Not that I use the 8200 often anymore, 
> > I like my DLT4000 much better than the 8200. ;-)
> 
> I much prefer my Exabyte Mammouth drives as well  :-)
> 
> (But I do seem to get some fun out of playing with the 8200's I get for
> $10 apiece from the surplus store :-)

Absolutely right. And I got my DLT4000 for US$ 25 so you can guess where
I got it from 8-)

Groeten / Cheers,

|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: RE: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

:> trusting 15+ years worth of source history to a program 
:> that has just
:> barely been written.  I think the Linux people are making 
:> a huge mistake
:> by not using CVS.
:
:15 years? Our cvs repository is only about 5 years old and cvs isn't 15
:years old!

Well, ok, this reposity only goes as far back as 4.4-lite.  I was being
inclusive :-)

-Matt
Matthew Dillon 


:I agree with the sentiment though :-)
:
:Although, if it's widely used I suspect it will stabilise much sooner than a
:couple of years. If it has the required features it might be worth playing
:with on the back burner to see how it shaped up.
:
:Paul.
:



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Harlan Stenn]

As I understand it, BitKeeper is indeed based on SCCS, and is a superset of 
it.  The performance hit of SCCS has been "solved".

There are several "significant" commercial users of BitKeeper waiting for 
the first production release, and Larry McVoy seems to be a bit of a maniac 
when it comes to things being production stable.

He said that a CVS->BitKeeper conversion tool is not far off.

I'm mostly interested in the "lines of development" features, the ability 
to check in various revisions of my *local* work, the ability to apply a 
patch set as an atomic unit, and several of the GUI tools.

H



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Strange figures reported by i586_bzero...

[Maxim Sobolev]

Following is piece of dmesg -v output of my recent kernel (take a look
at i586_bzero bandwith figures


FreeBSD 4.0-CURRENT #1: Sat May  1 21:30:10 EEST 1999
Calibrating clock(s) ... TSC clock: 250536168 Hz, i8254 clock: 1193030
Hz
Timecounter "i8254"  frequency 1193030 Hz
CPU: \^E (250.54-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
  Features=0x8001bf
Data TLB: 128 entries, 2-way associative
Instruction TLB: 64 entries, 1-way associative
L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative
L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way
associative
Write Allocate Enable Limit: 64M bytes
Write Allocate 15-16M bytes: Enable
Hardware Write Allocate Control: Disable
.
npx0:  on motherboard
npx0: INT 16 interface
i586_bzero() bandwidth = -2111561183 bytes/sec
 ^^-
NEGASTIVE BANDWITH? IT'S INTERESTING!!!
bzero() bandwidth = 186046511 bytes/sec




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: default route not set up??

[Dag-Erling Smorgrav]

"Daniel C. Sobral"  writes:
> Dag-Erling Smorgrav wrote:
> > "Daniel C. Sobral"  writes:
> > > Dag-Erling Smorgrav wrote:
> > > > [exerpt from /etc/rc.network]
> > > Looking there, it *does* seem that there is a problem. defaultrouter
> > > is only used to set route_default, which is *not* used. At least on
> > > the code you quoted.
> > This is getting fun :) Look closer at the first line I commented, then
> > at the loop, and especially the eval.
> That's tricky, indeed. You should have commented the line below the
> second line, not the second line. :-)

Yep.

I was similarly miffed the first time I read this code, but I thought
'hey, it works, so it has to be right' and read it over until I was
enlightened. I still find it slightly spaghetti.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

RE: -stable vs -current (was Re: solid NFS patch #6... )

[Alex Perel]

On Sat, 1 May 1999 p...@originative.co.uk wrote:

> The -stable branch shouldn't have anything done to it, that's my whole
> point, we shouldn't be merging stuff back into the -stable branch, only fix
> specific straightforward problems that don't require complete
> re-engineering.

No new features means stagnation in development. It means that someone
coming to FreeBSD and looking for a feature will only find it in -current,
which, by virtue of being -current, will have other miscellaneous problems.
This person gets annoyed and leaves. 

This is the _LAST_ thing we need right now. 

Your idea of -beta is exactly the idea of -stable. If you want something
that is only receiving bugfixes, run 2.2.x. It's in maintanance mode now.

> Then what happens to -stable, is it going to get thouroughly tested with all
> these changes? You're currently treating -stable as a "beta stable" in that
> users who track it are being used as beta testers to find the bugs caused by
> merges from current. There's no track for "really stable" users who want to
> pick up necessary bug fixes.

Gosh, I was under the impression that every FreeBSD user was a beta
tester... :)

It's inevitable that bugs will be found in -stable more quickly than in
-current, simply because -stable has a much larger user base. Just think
back to the days after 3.0-RELEASE and the myriad of bug reports that
suddenly came in because the level of usage for that code skyrocketed. 




  Alex G. Perel  -=-  AP5081
   al...@iplink.net  -=-  (work)   
ve...@disturbed.net  -=-  (play)
 
Disturbed Networks - Powered exclusively by FreeBSD
== The Power to Serve -=- http://www.freebsd.org/ 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Robert Watson]

So will bitkeeper provide a nice interface for migrating code from an
existing and well-established CVS repository to whatever they use?

I'm quite happy to allow them to test bitkeeper in a production
environment before using it in one myself, needless to say. :)

On Sat, 1 May 1999, Matthew Jacob wrote:

> 
> > 
> > # 
> > #:BitKeeper should be ready soon.
> > #:
> > #:Once it's been proven stable, might it be a better alternative to CVS?
> > #:
> > #:H
> > # 
> > # Maybe, but we wouldn't know for a couple of years.  You don't just go
> > # trusting 15+ years worth of source history to a program that has just
> > # barely been written.  I think the Linux people are making a huge 
> > mistake
> > # by not using CVS.
> > 
> > >From what I gather (and I could very well be wrong), but I
> > think BitKeeper is somewhat based on SCCS.  I'm not advocating
> > that we ditch CVS either, just that BitKeeper may not be as new
> > and fresh as some would like us to believe.  Looks like an old
> > friend (or nemisis) dressed in a new set of rags. :)
> 
> No, not really. Larry's hostile to RCS because of it's lack of checksum.
> I've asked him about it a couple of times and he's not really excited
> about an RCS bottom end. It could be done if you insisted on it (I mean,
> it's GPL'd code, right?) but it's not something he would support.
> 
> Bitkeeper is a substantial improvement over CVS and Perforce. It's really
> a nice piece of work done by somebody who *really* knows his stuff.
> Remember that Larry saved Sun from complete disaster by inventing NSElite
> (which Bitkeeper is emphatically a granchild of) in time to keep 1000
> engineers from rising up and tearing Eric Schmidt to threads over his
> insistence that "The Sun/SVR4 merge *SHALL* use NSE and the [ broken ]
> translucent filesystem if we're here until the year 2000 doing it!".
> 
> Personally, I'm happy with CVS if you have a model a single main stream of
> development. It's a disaster when you have to maintain separate
> development clusters. And very few other packages really do any kind of 
> job of this either.
> 
> Look- if Linux adopts Bitkeeper, you really should pay attention to that.
> I doubt you'd find a more difficult set of software engineers to keep code
> in sync for than the Linux folks- if Bitkeeper works for them and
> essentially makes a rational release train for Linux, then a major
> glaring flaw in Linux' strategy that keeps serious businesses from really
> being able to trust it will be removed. Think about it.
> 
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 


  Robert N Watson 

rob...@fledge.watson.org  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1

Carnegie Mellon Universityhttp://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services http://www.safeport.com/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

RE: solid NFS patch #6 avail for -current - need testers files)

[paul]

> -Original Message-
> From: Matthew Dillon [mailto:dil...@apollo.backplane.com]
> Sent: 01 May 1999 18:24
> To: Harlan Stenn
> Cc: Doug Rabson; Kevin Day; Mike Smith; da...@aps-services.com;
> p...@originative.co.uk; freebsd-current@FreeBSD.ORG
> Subject: Re: solid NFS patch #6 avail for -current - need 
> testers files)
> 
> 
> 
> 
> :BitKeeper should be ready soon.
> :
> :Once it's been proven stable, might it be a better 
> alternative to CVS?
> :
> :H
> 
> Maybe, but we wouldn't know for a couple of years.  You 
> don't just go
> trusting 15+ years worth of source history to a program 
> that has just
> barely been written.  I think the Linux people are making 
> a huge mistake
> by not using CVS.

15 years? Our cvs repository is only about 5 years old and cvs isn't 15
years old!

I agree with the sentiment though :-)

Although, if it's widely used I suspect it will stabilise much sooner than a
couple of years. If it has the required features it might be worth playing
with on the back burner to see how it shaped up.

Paul.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Zach Heilig]

I found the commit that "broke" sound (beyond that, I don't know how
to fix it):

peter   1999/04/21 00:26:31 PDT

  Modified files:
sys/alpha/isaisa.c 
sys/alpha/pcipcibus.c 
sys/cam  cam_xpt.c 
sys/dev/ata  ata-all.c 
sys/i386/i386nexus.c 
sys/i386/include types.h 
sys/i386/isa clock.c intr_machdep.c intr_machdep.h 
 ipl_funcs.c isa_device.h isa_dma.c 
 random_machdep.c 
sys/isa  isavar.h 
sys/kern kern_intr.c 
sys/pci  intpm.c 
sys/sys  interrupt.h systm.h 
  Log:
  Stage 1 of a cleanup of the i386 interrupt registration mechanism.
  Interrupts under the new scheme are managed by the i386 nexus with the
  awareness of the resource manager.  There is further room for optimizing
  the interfaces still.  All the users of register_intr()/intr_create()
  should be gone, with the exception of pcic and i386/isa/clock.c.
  
  Revision  ChangesPath
  1.11  +3 -3  src/sys/alpha/isa/isa.c
  1.11  +1 -36 src/sys/alpha/pci/pcibus.c
  1.53  +1 -3  src/sys/cam/cam_xpt.c
  1.9   +28 -33src/sys/dev/ata/ata-all.c
  1.4   +7 -6  src/sys/i386/i386/nexus.c
  1.17  +2 -1  src/sys/i386/include/types.h
  1.130 +12 -16src/sys/i386/isa/clock.c
  1.19  +426 -42   src/sys/i386/isa/intr_machdep.c
  1.14  +16 -3 src/sys/i386/isa/intr_machdep.h
  1.16  +9 -1  src/sys/i386/isa/ipl_funcs.c
  1.60  +1 -3  src/sys/i386/isa/isa_device.h
  1.2   +1 -2  src/sys/i386/isa/isa_dma.c
  1.30  +2 -1  src/sys/i386/isa/random_machdep.c
  1.4   +3 -3  src/sys/isa/isavar.h
  1.22  +1 -405src/sys/kern/kern_intr.c
  1.5   +4 -8  src/sys/pci/intpm.c
  1.8   +4 -19 src/sys/sys/interrupt.h
  1.88  +1 -4  src/sys/sys/systm.h

A kernel from right before that works for sound, and one from right after
it is broken.

-- 
Zach Heilig 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Jacob]

> 
> # 
> #:BitKeeper should be ready soon.
> #:
> #:Once it's been proven stable, might it be a better alternative to CVS?
> #:
> #:H
> # 
> # Maybe, but we wouldn't know for a couple of years.  You don't just go
> # trusting 15+ years worth of source history to a program that has just
> # barely been written.  I think the Linux people are making a huge mistake
> # by not using CVS.
> 
> >From what I gather (and I could very well be wrong), but I
> think BitKeeper is somewhat based on SCCS.  I'm not advocating
> that we ditch CVS either, just that BitKeeper may not be as new
> and fresh as some would like us to believe.  Looks like an old
> friend (or nemisis) dressed in a new set of rags. :)

No, not really. Larry's hostile to RCS because of it's lack of checksum.
I've asked him about it a couple of times and he's not really excited
about an RCS bottom end. It could be done if you insisted on it (I mean,
it's GPL'd code, right?) but it's not something he would support.

Bitkeeper is a substantial improvement over CVS and Perforce. It's really
a nice piece of work done by somebody who *really* knows his stuff.
Remember that Larry saved Sun from complete disaster by inventing NSElite
(which Bitkeeper is emphatically a granchild of) in time to keep 1000
engineers from rising up and tearing Eric Schmidt to threads over his
insistence that "The Sun/SVR4 merge *SHALL* use NSE and the [ broken ]
translucent filesystem if we're here until the year 2000 doing it!".

Personally, I'm happy with CVS if you have a model a single main stream of
development. It's a disaster when you have to maintain separate
development clusters. And very few other packages really do any kind of 
job of this either.

Look- if Linux adopts Bitkeeper, you really should pay attention to that.
I doubt you'd find a more difficult set of software engineers to keep code
in sync for than the Linux folks- if Bitkeeper works for them and
essentially makes a rational release train for Linux, then a major
glaring flaw in Linux' strategy that keeps serious businesses from really
being able to trust it will be removed. Think about it.






To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: sound and sio problems after newbus changes

[Blaz Zupan]

On Sun, 2 May 1999, Bruce Evans wrote:
> Fast interrupts were broken in early versions of new-bus.  Without
> fast interrupts, sio interrupt latency is limited by the worst spl
> hog in the system.

Yes I know that, but I believe this was later fixed. I'm running a kernel
compiled today and the sio overflows still happen. Also adding in the
sound problems which seem to be caused by missing interrupts, I think we
have a bug in the interrupt code after the newbus changes.

Blaz Zupan, b...@amis.net, http://www.herbie.amis.net
Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: sound and sio problems after newbus changes

[Bruce Evans]

>Also, has anybody problems with sio buffer overflows? My machine is a
>Pentium 200MMX, which should be able to handle 115.2K on a com port just
>fine (my old 486 did, when I was running 2.2.x, 3.0 and 4.0 before
>newbus). But now I'm receiving lots of sio overflows, it is as simple as
>typing "ATI4" to my Courier, some characters get lost on output.

Fast interrupts were broken in early versions of new-bus.  Without
fast interrupts, sio interrupt latency is limited by the worst spl
hog in the system.

Bruce


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)

[Steve Price]

On Sat, 1 May 1999, Matthew Dillon wrote:

# 
#:BitKeeper should be ready soon.
#:
#:Once it's been proven stable, might it be a better alternative to CVS?
#:
#:H
# 
# Maybe, but we wouldn't know for a couple of years.  You don't just go
# trusting 15+ years worth of source history to a program that has just
# barely been written.  I think the Linux people are making a huge mistake
# by not using CVS.

New ATA drivers wont boot if second IDE controller enabled

[Matthew Thyer]

I have been unable to use my Ultra DMA ATAPI CD-ROM since version 4
of Soren's ATAPI driver.

Version 4 worked fine but since then (since at least version 6 
I didn't try version 5)  The system wont boot if I have my secondary
IDE controller enabled.

The system never completes its kernel probing, it just sits there
after configuring the hard disk.

I am running an IBM 6.48 GB (metric GB) hard disk on the first IDE
controller as the master.

I am running a "Diamond Data 32 speed Ultra DMA CD-ROM" on the
second IDE controller and it doesnt matter if its a slave or master
(there is nothing else on the controller).

The CD-ROM is model number 632A 023 and is made in June 1998.
"Diamond Data" is a trade mark of "Mitsubishi Electric Australia".

My -CURRENT is only a few hours old (freshly build world and kernel).

Kernel config file and dmesg output are attached.

-- 
/===\
| Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973# Machine with Ultra DMA 32 Bit WD disk, ATAPI CD-ROM, SB16, NE2000 NIC,
#  NCR PCI SCSI, APM and Intel PIIX power management.
#   $Id: MATTE,v 11.8 1999/05/02 01:06:00 +09:30 matt Exp $
# based on: $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $
#
machine i386
ident   "MATTE"
maxusers20
options INCLUDE_CONFIG_FILE # Include this file in kernel
config  kernel  root on wd0
cpu I686_CPU
options CPU_DISABLE_5X86_LSSER  # Dont use if you use memory mapped I/O 
device(s).
options CPU_FASTER_5X86_FPU # Faster FPU exception handler
options NO_F00F_HACK# Disable Pentium F00F hack
# COMPATIBILITY OPTIONS
options COMPAT_43   # Compatible with BSD 4.3 [KEEP THIS!]
options USER_LDT# Let processes manipulate their local 
descriptor table (needed for WINE)
options SYSVSHM # Enable SYSV style shared memory
options SYSVSEM # Enable SYSV style semaphores
options SYSVMSG # Enable SYSV style message queues
options MD5 # Include a MD5 routine in the kernel
options VM86# Allow processes to switch to vm86 
mode (needed for doscmd)
# DEBUGGING OPTIONS
options DDB # Enable the kernel debugger
#optionsINVARIANTS  # Extra sanity checking (slower)
#optionsINVARIANT_SUPPORT   # Include sanity checking 
functions
options UCONSOLE# Allow users to grab the console
options USERCONFIG  # Boot -c editor
options VISUAL_USERCONFIG   # Visual boot -c editor
# NETWORKING OPTIONS
options INET# Internet communications protocols
# Network interfaces:
pseudo-device   ether   # Generic Ethernet
pseudo-device   loop# Network loopback device
pseudo-device   tun 1   # Tunnel driver(user process ppp)
pseudo-device   streams # SysVR4 STREAMS emulation
# FILESYSTEM OPTIONS
options FFS # Berkeley Fast Filesystem
options FFS_ROOT# FFS usable as root device
options NFS # Network Filesystem
options CD9660  # ISO 9660 Filesystem
options MFS # Memory Filesystem
options MSDOSFS # MSDOS Filesystem
options PROCFS  # Process Filesystem
options NSWAPDEV=4  # Allow this many swap-devices
options SOFTUPDATES # SoftUpdates aka delayed writes
controller  pci0
controller  ncr0
options P1003_1B
options _KPOSIX_PRIORITY_SCHEDULING
options _KPOSIX_VERSION=199309L
# SCSI DEVICE CONFIGURATION (CAM SCSI)
controller  scbus0  at ncr0 # Base SCSI code
diskda0 at scbus0 target 0
diskda1 at scbus0 target 1
diskda2 at scbus0 target 2
diskda3 at scbus0 target 3
diskda4 at scbus0 target 4
diskda5 at scbus0 target 5
diskda6 at scbus0 target 6
options SCSI_DELAY=500  # Only wait 0.5 seconds for SCSI
# MISCELLANEOUS DEVICES AND OPTIONS
pseudo-device   pty 64  # Pseudo ttys - can go as high as 256
pseudo-device   gzip  

silo overflows in CURRENT ... some info that may help

[Matthew Thyer]

I have been investigating the silo overflow situation for some time.

I can trigger them every time by the following action:

- Run M.A.M.E. (Multi arcade machine emulator) and then try to
download something. (I am using user mode ppp).

I believe that the sio driver is its own worst enemy in that once
you get one silo overflow, it seems that the driver tries to compensate
but it only makes it worse as I continue to get them and the serial port
is unusable after that.   Exiting MAME doesn't help, I have to reboot
or I will be unable to do the smallest thing such as download my mail.

I dont think its just MAME but rather anything that thrashes the
interrupt system.

This is not related to newbus as it occurrred before then in just the
same manner.

I have seen this effect on my home system no matter what combination
of motherboard, modem, serial hardware.

I was running a patch to sio.c before newbus came in to improve the
speed at which the FIFO buffers were processed but MAME would still
trigger the start of the silo overflow storm.

With either a patched or unpatched system I can download huge files
no problems as long as I dont run MAME at any time.

Now dont say "just dont do that" (I know some of you will want to).

Kernel config is attached.
/etc/ppp/ppp.conf (edited) is attached.
dmesg output is also attached.

-- 
/===\
| Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
 E. P. Tryon   from "Nature" Vol.246 Dec.14, 1973# Machine with Ultra DMA 32 Bit WD disk, ATAPI CD-ROM, SB16, NE2000 NIC,
#  NCR PCI SCSI, APM and Intel PIIX power management.
#   $Id: MATTE,v 11.8 1999/05/02 01:06:00 +09:30 matt Exp $
# based on: $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $
#
machine i386
ident   "MATTE"
maxusers20
options INCLUDE_CONFIG_FILE # Include this file in kernel
config  kernel  root on wd0
cpu I686_CPU
options CPU_DISABLE_5X86_LSSER  # Dont use if you use memory mapped I/O 
device(s).
options CPU_FASTER_5X86_FPU # Faster FPU exception handler
options NO_F00F_HACK# Disable Pentium F00F hack
# COMPATIBILITY OPTIONS
options COMPAT_43   # Compatible with BSD 4.3 [KEEP THIS!]
options USER_LDT# Let processes manipulate their local 
descriptor table (needed for WINE)
options SYSVSHM # Enable SYSV style shared memory
options SYSVSEM # Enable SYSV style semaphores
options SYSVMSG # Enable SYSV style message queues
options MD5 # Include a MD5 routine in the kernel
options VM86# Allow processes to switch to vm86 
mode (needed for doscmd)
# DEBUGGING OPTIONS
options DDB # Enable the kernel debugger
#optionsINVARIANTS  # Extra sanity checking (slower)
#optionsINVARIANT_SUPPORT   # Include sanity checking 
functions
options UCONSOLE# Allow users to grab the console
options USERCONFIG  # Boot -c editor
options VISUAL_USERCONFIG   # Visual boot -c editor
# NETWORKING OPTIONS
options INET# Internet communications protocols
# Network interfaces:
pseudo-device   ether   # Generic Ethernet
pseudo-device   loop# Network loopback device
pseudo-device   tun 1   # Tunnel driver(user process ppp)
pseudo-device   streams # SysVR4 STREAMS emulation
# FILESYSTEM OPTIONS
options FFS # Berkeley Fast Filesystem
options FFS_ROOT# FFS usable as root device
options NFS # Network Filesystem
options CD9660  # ISO 9660 Filesystem
options MFS # Memory Filesystem
options MSDOSFS # MSDOS Filesystem
options PROCFS  # Process Filesystem
options NSWAPDEV=4  # Allow this many swap-devices
options SOFTUPDATES # SoftUpdates aka delayed writes
controller  pci0
controller  ncr0
options P1003_1B
options _KPOSIX_PRIORITY_SCHEDULING
options _KPOSIX_VERSION=199309L
# SCSI DEVICE CONFIGURATION (CAM SCSI)
controller  scbus0  at ncr0 # Base SCSI code
diskda0 at scbus0 target 0
disk   

Re: solid NFS patch #6 avail for -current - need testers files)

[Matthew Dillon]

:BitKeeper should be ready soon.
:
:Once it's been proven stable, might it be a better alternative to CVS?
:
:H

Maybe, but we wouldn't know for a couple of years.  You don't just go
trusting 15+ years worth of source history to a program that has just
barely been written.  I think the Linux people are making a huge mistake
by not using CVS.

-Matt
Matthew Dillon 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Andrew Atrens]

I'm using a _PnP_ card, and mine comes up as:

pcm1 (CS423x/Yamaha/AD1816  sn 0x) at 0x530-0x537 irq 5 drq 
0 flags 0x11 on isa

When I use NAS I get an interesting 'riffing' effect (last 2 second
sample repeated over and over). The only way to shut it up is to kill the
NAS server. Killing nas generates the following kernel message:

> timeout flushing dbuf_out, chan 0 cnt 0xfffa3acc flags 0x40c1

which, originates in /sys/i386/isa/snd/dmabuf.c snd_flush(), which is
called by mss_close().

Interestingly other things like xanim and mpg123 are unaffected.


Andrew.

-- 
+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own,  not those of any employer. |
   --+
  Heller's Law: The first myth of management is that it exists.   
  Johnson's Corollary: Nobody really knows what is going on
   anywhere within the organization.   




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: XFree86 and egcs

[Steve Jorgensen]

> In article <199904282026.oaa13...@zen.alb.khoral.com>,
> Steve Jorgensen   wrote:
> > > In article <199904271932.naa01...@zen.alb.khoral.com>,
> > > Steve Jorgensen   wrote:
> > > > I cvsup'ed and installed yesterday morning it's the third
> > > > cvsup I've done since egcs went in, so I know it's working
> > > > ok.  Anyway, I decided to update my XFree86 installation,
> > > > and found that the port no longer works.  As it compiles
> > > > all binaries created report tons of missing symbols
> > > > from the various X library.  The wierd thing is that it
> > > > still installs most of the X binaries anyway, and they work
> > > > fine, but it dies when it gets to installing the X server
> > > > itself.
> [...]
> > Ok, well in the interest of not sending large compile
> > output to the news group, I've put an error log on
> > my webserver with all the info in it:
> > 
> > http://www.haunt.com/~steve/error.html

> I took a look at it.  All those undefined symbols are supposed to be
> in the "-lX11" library.  I don't really know why you're getting
> them.  Maybe you have an older version of the library lying around
> that is stripped?  Try a "locate libX11.so" and see what's there.
> Then do "file libX11.so" on each one and see if it's stripped.
No old versions, I removed the old XF86 installation before
installing this one.

> Maybe your LD_LIBRARY_PATH environment variable is set, screwing up
> the build?  Maybe you've got something funny in /etc/make.conf?
LD_LIBRARY_PATH is not set, and the only difference
in my make.conf is that I set HAVE_MOTIF  to yes, because
I intend to install lesstif.

> Sorry, these are just guesses.  I've never encountered the problem
> you're reporting.

Well, thanks for trying.. I'm going to try cvssuping once
more before I dig too deep into the xf86 port.  Maybe
I updated in the middle of a commit the last time.

Steve
--
---
Steven Jorgensen  st...@khoral.com  st...@haunt.com
--+
Khoral Research Inc.  | PHONE: (505) 837-6500
6200 Uptown Blvd, Suite 200   | FAX:   (505) 881-3842
Albuquerque, NM 87110 | URL: http://www.khoral.com/
---


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

netatalk (atalkd,papd,afpd)

[Edwin Culp]

I just realized that I have lost netatalk (atalkd/papd/afpd)  seems to
have silently died within the last week or so, for no clear reason.  Has
anyone else, who is running current and netatalk, seen this?  (Misery
loves company:-)  I'm going to start looking for a problem.

Thanks,

ed





To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: default route not set up??

[Daniel C. Sobral]

Dag-Erling Smorgrav wrote:
> 
> > > # Configure routing
> > >
> > > if [ "x$defaultrouter" != "xNO" ] ; then
> > > static_routes="default ${static_routes}"# look here...
> > > route_default="default ${defaultrouter}"
> > > fi
> > >
> > > # Set up any static routes.  This should be done before router 
> > > discovery.
> > > if [ "x${static_routes}" != "x" ]; then
> > > for i in ${static_routes}; do   # ...and here
> > > eval route_args=\$route_${i}
> > > route add ${route_args}
> > > done
> > > fi
> >
> > Looking there, it *does* seem that there is a problem. defaultrouter
> > is only used to set route_default, which is *not* used. At least on
> > the code you quoted.
> 
> This is getting fun :) Look closer at the first line I commented, then
> at the loop, and especially the eval.

That's tricky, indeed. You should have commented the line below the
second line, not the second line. :-)

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

"Proof of Trotsky's farsightedness if that _none_ of his
predictions have come true yet."


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Harlan Stenn]

BitKeeper should be ready soon.

Once it's been proven stable, might it be a better alternative to CVS?

H



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Zach Heilig]

On Sat, May 01, 1999 at 04:22:25PM +0800, Peter Wemm wrote:
> vortexia wrote:
> > Heh, the panic problem might be solved, but Ive just cvsupped with the
> > latest 4.0-CURRENT and the problems with pcm are definatly not over, Im
> > getting very jerky sound, its repeating bits of it over and over... and I
> > get messages like this while trying to play mp3s with mpg123:
> > 
> > May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt
> > 0xfff994bc flags 0x0141
> > 
> > Cheers
> > Andrew
> 
> I've run two systems with PCM right since the first newbus commit, and it's
> worked for me.  Admittedly I don't use it all that often, but it's never
> paniced and I don't recall getting any more sound problems than usual.
> 
> I checked that the isa_dma.c code is an exact split of the dma code that
> used to be in the old isa.c, there are zero changes to the isa dma code.

Ok, the discussion seems to be here, I posted a debugging log in
-multimedia last night.  (It basically shows a bunch of data being
queued up, one interrupt, and some buffer being filled).  One more
thing to add to that is:

pcm1 (SB16pnp  sn 0x12b9118f) at 0x220-0x22f irq 9 drq 0 flags 0x17 
on isa

and vmstat -i:

interrupt  total  rate
old irq910
mux irq10   478981
fdc0 irq6   20
wdc0 irq14  247000
wdc1 irq152070
atkbd0 irq1 363610
psm0 irq12   12150
sio1 irq3 3379354   90
ppc0 irq7   10
ed0 irq5  2380
clk irq0  3752093   99
rtc irq8  4802629  127
Total12044699  320

The sound driver is definately not getting the interrupts it should on my
system.  Everything worked properly in the first half of April.  What I'm
about to do is compile a kernel from every day since I last knew it worked
and see where it breaks...

-- 
Zach Heilig 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ep0 *UTP*

[Robert Watson]

On 1 May 1999, Dag-Erling Smorgrav wrote:

> Soren Schmidt  writes:
> > [...]
> > There are lots of better cards out there, but stating that the 3c509
> > doesn't work, is totally out in the dark...
> 
> Well, excuse me for breathing. I'll just take your word, and dismiss
> the problems I've had with flaky 3c509s (about two thirds of those
> I've encountered have been flaky) as mere hallucinations.

Well, if it's any reassurance at all, a friend of mine recently switched
to FreeBSD from Andrew Linux, and the 3c509 was flaky under Linux, but
seems to work fine under FreeBSD.  Given past experiences, I advised him
not to put it under too high a load, but since it's just a crash machine
anyway..  They were really amused when the FreeBSD boot sequence announced
that the card was known buggy and something should be done about it, and
they commented that that was exactly right and they were pretty impressed.
Even more so when the card worked for a change.

  Robert N Watson 

rob...@fledge.watson.org  http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1

Carnegie Mellon Universityhttp://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services http://www.safeport.com/



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

voxware sound

[Tomer Weller]

im trying to use the voxware drivers in FreeBSD 3.1 and CURRENT and the
configuration that worked for me in 2.2.7 (worked fine) doesn't work flawless
anymore. main problem is that i have problems with mixer. this is a pnp
soundcard that emulates SB Pro. 
when trying to run mixer : 
mixer: SOUND_MIXER_READ_DEVMASK: Device not configured

Kernel config : 
#sound VOXWARE
optionsSBC_IRQ=5
controller  snd0
device  sb0at isa? port 0x220 irq 5 conflicts drq 1
device  mpu0  at isa? port 0x330 irq 9
device  opl0  at isa? port 0x388 conflicts

dmesg : 
sb0 at port 0x220 irq 5 drq 1 on isa0

NOTE! SB Pro support required with your soundcard!
snd0:  
sb0: interrupting at irq 5
mpu0 at port 0x330 irq 9 on isa0
snd0:  
mpu0: interrupting at irq 9
opl0 at port 0x388 on isa0
snd0:  

how do i ass "SB Pro support" ? never needed that in 2.2.7. 
i tried pcm0, doesn't work good for me (though mixer works fine) 
==
 Tomer Weller
 s...@i.am
 well...@netvision.net.il
 "Drugs are good, and if you do'em 
 pepole think that you're cool", NoFX
 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

voxware drivers

[Tomer Weller]

im trying to use the voxware drivers in FreeBSD 3.1 and CURRENT and the
configuration that worked for me in 2.2.7 (worked fine) doesn't work flawless
anymore. main problem is that i have problems with mixer. this is a pnp
soundcard that emulates SB Pro. 
when trying to run mixer : 
mixer: SOUND_MIXER_READ_DEVMASK: Device not configured

Kernel config : 
#sound VOXWARE
options SBC_IRQ=5
controller  snd0
device  sb0 at isa? port 0x220 irq 5 conflicts drq 1
device  mpu0at isa? port 0x330 irq 9
device  opl0at isa? port 0x388 conflicts

dmesg : 
sb0 at port 0x220 irq 5 drq 1 on isa0

NOTE! SB Pro support required with your soundcard!
snd0:  
sb0: interrupting at irq 5
mpu0 at port 0x330 irq 9 on isa0
snd0:  
mpu0: interrupting at irq 9
opl0 at port 0x388 on isa0
snd0:  

how do i ass "SB Pro support" ? never needed that in 2.2.7. 
i tried pcm0, doesn't work good for me (though mixer works fine) 
==  
Tomer Weller
 s...@i.am
 well...@netvision.net.il
 "Drugs are good, and if you do'em 
 pepole think that you're cool", NoFX
 


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Further on tape & CAM problems

[Bob Willcox]

On Fri, Apr 30, 1999 at 12:36:25AM +0200, Wilko Bulte wrote:
> As Bob Willcox wrote ...
> > On Thu, Apr 29, 1999 at 10:26:36PM +0200, Wilko Bulte wrote:
> > > As Bob Willcox wrote ...
> > > > On Wed, Apr 28, 1999 at 08:45:36PM +0200, Wilko Bulte wrote:
> > > 
> > > > shipping 8200's (this was right at their end-of-life) was:
> > > > 
> > > > MX: 2680
> > > > SV: C034
> > > > 
> > > > This is for generic models.  OEM models may have different versions
> > > > due to customizations.
> > > 
> > > And these are not recommended for general use.
> > 
> > Hmm, why is that?  The newest of the IBM branded Exabyte 8200's that I
> 
> That is what I've been told by an Exabyte engineer years back. I can only
> guess that some OEMs need adaptations to the firmware behaviour that are
> incompatible with what the rest of the world needs (or has standardised
> on, e.g. in the ANSI SCSI standard). Again, guessing.

Well, I can only speak for the IBM OEM'd drives that I have (as a
retired IBMer, I've been picking them up at their employee surplus
store here in Austin, TX).  For these drives the generic firmware works
just fine.  I can see why Exabyte wouldn't openly recommend the change
though.

Back in the late 80's, when I was still working for IBM on AIX, I do
recall that we did have some customizations in the firmware for the
RS/6K AIX systems.  In addition to changing the Inquiry command Vendor
ID data, I believe there were some functional changes (I don't recall
the details).  I have always suspected that the functional changes are
likely what made the IBM OEM'd drives fail on FreeBSD!  The upgraded
firmware IBM drives work on both (as "Other SCSI Tape Drive").

> 
> > have have precisely these firmware levels in them (2680 & C034).  Also,
> 
> Mine works OK with that f/w. Not that I use the 8200 often anymore, 
> I like my DLT4000 much better than the 8200. ;-)

I much prefer my Exabyte Mammouth drives as well  :-)

(But I do seem to get some fun out of playing with the 8200's I get for
$10 apiece from the surplus store :-)

Bob

-- 
Bob Willcox The man who follows the crowd will usually get no
b...@luke.pmr.comfurther than the crowd.  The man who walks alone is
Austin, TX  likely to find himself in places no one has ever
been.-- Alan Ashley-Pitt


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Odd message during -current boot

[Steven P. Donegan]

On Sat, 1 May 1999, Jordan K. Hubbard wrote:

> haveseen_isadev() called - FIXME!
> (about 10 times)
> 
> This appears to happen around the bt_isa (Buslogic) probe.  Is that of
> any help?
> 
> - Jordan
> 

And, it happens even if the bt device driver is not configured into the 
kernel...


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: sound and sio problems after newbus changes

[Kris Kennaway]

Yes and yes (I have both the sound problems and the sio overflows) - these
started around the time of the newbus commits.

Kris

On Sat, 1 May 1999, Blaz Zupan wrote:

> I also experience the sound problems. Although sound works, it has
> problems stopping. For example when I hit stop in x11amp, the sound still
> loops for a couple of seconds and then I get the following message on the
> console:
> 
> timeout flushing dbuf_out, chan 1 cnt 0xfff9e46c flags 0x01c1
> 
> This message is being generated in snd_flush()  in
> /sys/i386/isa/snd/dmabuf.c. Looking at the code, it loops 10 times, each
> time waiting for a tsleep() to succeed. There are only two places in
> dmabuf.c that wakeup() this tsleep, one is dsp_wr_dmadone(), the second
> is in dsp_rd_dmadone(). Both are called from dsp_wrintr().
> 
> I put in a printf() at the start of dsp_wrintr(). The interrupt gets
> called when I start playing music in x11amp. When I stop it, no interrupt
> is generated, so dsp_wr_dmadone() is never called, so it never wakes up
> the tsleep() in snd_flush(). I really don't know why the interrupt does
> not occur (or if it should occur at all), maybe someone more knowledgable
> can take over from here Please. Pretty please with sugar on top :)
> 
> Also, has anybody problems with sio buffer overflows? My machine is a
> Pentium 200MMX, which should be able to handle 115.2K on a com port just
> fine (my old 486 did, when I was running 2.2.x, 3.0 and 4.0 before
> newbus). But now I'm receiving lots of sio overflows, it is as simple as
> typing "ATI4" to my Courier, some characters get lost on output.
> 
> If I am allowed to take a wild guess, this problem could be linked to the
> sound problem. Maybe some interrupts are generally lost or not correctly
> handled.
> 
> Blaz Zupan, b...@amis.net, http://www.herbie.amis.net
> Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 

-
The Feynman problem-solving algorithm: 1. Write down the problem
   2. Think real hard
   3. Write down the solution



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: default route not set up??

[Dag-Erling Smorgrav]

"Daniel C. Sobral"  writes:
> Dag-Erling Smorgrav wrote:
> > # Configure routing
> > 
> > if [ "x$defaultrouter" != "xNO" ] ; then
> > static_routes="default ${static_routes}"# look here...
> > route_default="default ${defaultrouter}"
> > fi
> > 
> > # Set up any static routes.  This should be done before router 
> > discovery.
> > if [ "x${static_routes}" != "x" ]; then
> > for i in ${static_routes}; do   # ...and here
> > eval route_args=\$route_${i}
> > route add ${route_args}
> > done
> > fi
> 
> Looking there, it *does* seem that there is a problem. defaultrouter
> is only used to set route_default, which is *not* used. At least on
> the code you quoted.

This is getting fun :) Look closer at the first line I commented, then
at the loop, and especially the eval.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...

[Andre Oppermann]

David Greenman wrote:
> 
> >Matthew Jacob wrote:
> >> For raw pattern testing Linux has a special challenge since you right
> >> directly into the buffer cache. There *is* a BLKFLSBUF ioctl that can try
> >> and force a flush but this probably ought to be written to use O_FSYNC- I
> >> think that the ll_rw code might use it or an fsync could be done...
> >
> >Linux' fsync() works only on directories, not on files.
> 
>Huh? That doesn't make any sense. The "f" in fsync() stands for "file".

It does write the file to the disk but not the inode. To get the inode
on the disk you have to fsync() the directory (which sync'ed the whole
FS before 2.0.35). Kinda stupid...

If you can't believe it:
http://www.ornl.gov/its/archives/mailing-lists/qmail/1998/05/threads.html#00691

Look for Linus' answers.

-- 
Andre


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Any action on PR 10570 ? getting closer to 65K :-(

[adrian]

John Polstra writes:
>Snob Art Genre wrote:
>> On Fri, 30 Apr 1999, Poul-Henning Kamp wrote:
>> 
>>> In message , John Polstra writes:
>>> >Rodney W. Grimes wrote:
>>> >
>>> >You're being totally unrealistic.  You can't create >2^32 of
>>> >_anything_ on an i386 without running out of memory.
>>> 
>>> Well, John, you can, the newer ones will address 2^36 bytes of memory
>>> and even a i386 can address 2^32 bytes or 2^35 bits...
>> 
>> Since when does FreeBSD only run on i386?
>
>Sheesh.  Make it a bloody long then so you'll get 64 bits on the
>Alpha.  And then go fix all the printf format mismatches.
>
>Or, pull you head out of that dark fantasyland and realize that (a) a
>32-bit counter is not a problem in any realistic sense, and (b) if it
>were, we'd have thousands of other equally serious problems throughout
>the system.
>
>I'm done with this absurd thread.

I tend to agree here - but I'll submit a patch with an assertion in the next
couple of days.


adrian


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: DUMMYNET broken in -current ?

[Eric J. Chet]

On Fri, 30 Apr 1999, Poul-Henning Kamp wrote:

> 
> I have two machines, the target being a -current SMP box.
> 
> On the source machine I do
>   ping target
> 
> On the target machine, SMP kernel with IPFW+DUMMYNET:
> 
>   ipfw pipe config 1 delay 200ms
>   ipfw add pipe 1 icmp from any to any
> 
> and get a panic in ether_output because "dst" is 0x14. 
> 
> Anybody who can try this ?

Hello
It's also broker for UP -current for the last two weeks.  Machine
locks up or reboots.

Later,

Eric Chet e...@kenpo-jujitsu.com e...@bazzle.com e...@freebsd.org 
ejc...@lucent.com
Senior Object Oriented Developer - Specializing in OOA, OOD, C++, Java, CORBA
Kenpo JuJitsu the Ultimate in Self Defense, Tai Chi for Life
cat man du : where UNIX geeks go when they die



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: default route not set up??

[Daniel C. Sobral]

Dag-Erling Smorgrav wrote:
> 
> Lars Fredriksen  writes:
> > If you set "defaultrouter" in /etc/rc.conf to an ip address,
> > I expected that rc.network would
> > do a route add default ..., but instead I find that rc.network doesn't
> > do anything with the defaultrouter variable except to pass it on to the
> > route_default variable, which doesn't seem to be used at all.
> >
> > What am I missing here???
> 
> # Configure routing
> 
> if [ "x$defaultrouter" != "xNO" ] ; then
> static_routes="default ${static_routes}"# look here...
> route_default="default ${defaultrouter}"
> fi
> 
> # Set up any static routes.  This should be done before router discovery.
> if [ "x${static_routes}" != "x" ]; then
> for i in ${static_routes}; do   # ...and here
> eval route_args=\$route_${i}
> route add ${route_args}
> done
> fi

Looking there, it *does* seem that there is a problem. defaultrouter
is only used to set route_default, which is *not* used. At least on
the code you quoted.

--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org

"Proof of Trotsky's farsightedness if that _none_ of his
predictions have come true yet."



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ep0 *UTP*

[Soren Schmidt]

It seems Dag-Erling Smorgrav wrote:
> Soren Schmidt  writes:
> > [...]
> > There are lots of better cards out there, but stating that the 3c509
> > doesn't work, is totally out in the dark...
> 
> Well, excuse me for breathing. I'll just take your word, and dismiss
> the problems I've had with flaky 3c509s (about two thirds of those
> I've encountered have been flaky) as mere hallucinations.

Yeah, could be, as I hinted in the former email :)

Or it could be pilot errors, there are both non-PnP and PnP
versions of those cards, and their default behavior can IIRC
be changed via a DOS util, so there are lots of room for confusion,
but that is not the same as it doesn't work, its just a bit
complex. I have used those cards since they showed up, and apart
from a few broken ones (they DONT like DC on your BNC cableing)
there has been no problems (we are talking hundreds of cards here).

To get back to the subject, the default interface type (AUI/BNC/UTP)
are store in an EEPROM on board, this default is shown in the probe.
The default can be changed with a DOS util from 3COM.

-Søren


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Odd message during -current boot

[Doug Rabson]

On Sat, 1 May 1999, Jordan K. Hubbard wrote:

> haveseen_isadev() called - FIXME!
> (about 10 times)
> 
> This appears to happen around the bt_isa (Buslogic) probe.  Is that of
> any help?

Its fairly harmless. We don't really support the old haveseen_isadev() api
and its a reminder to convert any old drivers which use it. I might deal
with it this weekend since I have some time. I'm going to finish importing
gdb-4.18 first though.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Odd message during -current boot

[Jordan K. Hubbard]

haveseen_isadev() called - FIXME!
(about 10 times)

This appears to happen around the bt_isa (Buslogic) probe.  Is that of
any help?

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

sound and sio problems after newbus changes

[Blaz Zupan]

I also experience the sound problems. Although sound works, it has
problems stopping. For example when I hit stop in x11amp, the sound still
loops for a couple of seconds and then I get the following message on the
console:

timeout flushing dbuf_out, chan 1 cnt 0xfff9e46c flags 0x01c1

This message is being generated in snd_flush()  in
/sys/i386/isa/snd/dmabuf.c. Looking at the code, it loops 10 times, each
time waiting for a tsleep() to succeed. There are only two places in
dmabuf.c that wakeup() this tsleep, one is dsp_wr_dmadone(), the second
is in dsp_rd_dmadone(). Both are called from dsp_wrintr().

I put in a printf() at the start of dsp_wrintr(). The interrupt gets
called when I start playing music in x11amp. When I stop it, no interrupt
is generated, so dsp_wr_dmadone() is never called, so it never wakes up
the tsleep() in snd_flush(). I really don't know why the interrupt does
not occur (or if it should occur at all), maybe someone more knowledgable
can take over from here Please. Pretty please with sugar on top :)

Also, has anybody problems with sio buffer overflows? My machine is a
Pentium 200MMX, which should be able to handle 115.2K on a com port just
fine (my old 486 did, when I was running 2.2.x, 3.0 and 4.0 before
newbus). But now I'm receiving lots of sio overflows, it is as simple as
typing "ATI4" to my Courier, some characters get lost on output.

If I am allowed to take a wild guess, this problem could be linked to the
sound problem. Maybe some interrupts are generally lost or not correctly
handled.

Blaz Zupan, b...@amis.net, http://www.herbie.amis.net
Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: default route not set up??

[Dag-Erling Smorgrav]

Lars Fredriksen  writes:
> If you set "defaultrouter" in /etc/rc.conf to an ip address,
> I expected that rc.network would
> do a route add default ..., but instead I find that rc.network doesn't
> do anything with the defaultrouter variable except to pass it on to the
> route_default variable, which doesn't seem to be used at all.
> 
> What am I missing here???

# Configure routing

if [ "x$defaultrouter" != "xNO" ] ; then
static_routes="default ${static_routes}"# look here...
route_default="default ${defaultrouter}"
fi

# Set up any static routes.  This should be done before router discovery.
if [ "x${static_routes}" != "x" ]; then
for i in ${static_routes}; do   # ...and here
eval route_args=\$route_${i}
route add ${route_args}
done
fi

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Kevin Day]

> > I honestly don't know when to bring up things like that, now. :)
> 
> For 3.2, _right_now_.  What you're doing with Matt is the first stage; 
> the next involves bringing it back to the 3.2-beta tree and testing it 
> there.
> 
> Please understand that if "you" (the community) aren't working on this, 
> nobody else is.  We don't have enough people manning the trenches 
> because they're all sitting back in the chateau waiting for the 
> afternoon dispatches.  This doesn't work. 8)
> 

Can I propose something? I realize gnats does most of this, but...

Suppose there's some central list where anyone who is having unresolved
problems can post their e-mail address, section of code, and a brief
explaination of the symptoms. Other people acn go to this list and tack on
their e-mail address to other people's compalaints saying "I'm seeing this
too.". Before each release, all of these people are e-mailed saying "Can you
test to see if your problem still exists?" This will also be a bonus for
developers to find people who are experiencing specific problems, to see if
their fixes work.

I know this is a lot like gnats, however:


I don't think gnats wants a list of 'me too's in it.

It's not easy to mail groups of people from gnats.

There's no reason for anyone to add their e-mail address to a PR at the
moment.



I'm not sure if this'll make things more confusing or not, but... It'll stop
people with legitimate problems from getting lost in the shuffle, and keeps
PR's to more timely issues.

Anyone have any comments? Really, i'm just picturing a list of people with
specific problems... maybe gnats can be tuned a bit for this...


Kevin


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ep0 *UTP*

[Dag-Erling Smorgrav]

Soren Schmidt  writes:
> [...]
> There are lots of better cards out there, but stating that the 3c509
> doesn't work, is totally out in the dark...

Well, excuse me for breathing. I'll just take your word, and dismiss
the problems I've had with flaky 3c509s (about two thirds of those
I've encountered have been flaky) as mere hallucinations.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: ep0 *UTP*

[Soren Schmidt]

It seems Dag-Erling Smorgrav wrote:
> Alex Zepeda  writes:
> > On Wed, 28 Apr 1999, Jim Bryant wrote:
> > > > Well, I'd chalk it up to buggy 3com h/w myself.  Alas I'm still getting:
> > > > ep0 XXX: driver didn't set ifq_maxlen
> > > I still get that one too.  Driver problem?
> > I'm guessing so.  I wonder if this is the cause of some odd network
> > behavior I'm getting..
> 
> Anybody using a 3c509 and expecting it to work reliably should be
> taken out and shot in the back of the head.

Would you please take your medication on a daily basis ?? Those mood
swings are not fun anymore :)

I have lots of machines running with 3c509 cards in them, including all
my machines here, I've never had a single problem with them.
The ep driver may have some rough edges, but I've never encountered
any of them to be a problem.

There are lots of better cards out there, but stating that the 3c509
doesn't work, is totally out in the dark...

-Søren


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

RE: -stable vs -current (was Re: solid NFS patch #6... )

[paul]

> -Original Message-
> From: Matthew Dillon [mailto:dil...@apollo.backplane.com]
> Sent: 01 May 1999 00:53
> To: freebsd-current@FreeBSD.ORG
> Subject: -stable vs -current (was Re: solid NFS patch #6... )
> 

> I expect the 3.2 release to be a really good release.
> 
> It is true that -current has been, more often then not, 
> more stable then
> -stable in the last two months.  This is because fixes 
> were being made
> to -current more quickly then they could be backported to 
> -stable.  Most
> of these fixes *have* been backported at this point.  
> There are still a 
> few that have not that are on my hot list ( and still not 
> addressed, even
> with prodding ).  There are also a few bug fixes that 
> simply cannot be 
> backported to stable without some pain ( i.e. require the complete
> replacement of a number of subsystems ), and pain is not 
> in the cards 
> with the 3.2 release so close.

But no-one is really testing -stable. How many people have a stable machine
and a current machine and spend as much time testing stable as they do
current?
 
> It is hard enough dealing with two branches of the source 
> tree.  I will
> personally take my Super Soaker 5000 to anyone suggesting 
> that we have
> *three* .  Sqirt sqirt sqirt!

The -stable branch shouldn't have anything done to it, that's my whole
point, we shouldn't be merging stuff back into the -stable branch, only fix
specific straightforward problems that don't require complete
re-engineering.

> I am hoping that we will be able to accomplish a major 
> synchronization
> after the 3.2 release.  I personally believe that 
> -current is stable 
> enough that we should do one big-assed commit to sync 
> -stable up to the
> current -current and then continue as per normal.  I only 
> wish EGCS 
> hadn't been incorporated quite yet.  At the very least, I want to 
> sync *my* stuff up ( NFS/VM/VFS/BIO/VN/SWAPPER ). 

Then what happens to -stable, is it going to get thouroughly tested with all
these changes? You're currently treating -stable as a "beta stable" in that
users who track it are being used as beta testers to find the bugs caused by
merges from current. There's no track for "really stable" users who want to
pick up necessary bug fixes.

Paul.


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[vortexia]

hrmmm strange, I booted this system with a 3.0-STABLE drive just now and I
have no problems with the sound, so Im not sure what it is, but its
definatly not hardware.

Cheers

Andrew

On Sat, 1 May 1999, Peter Wemm wrote:

> vortexia wrote:
> > Heh, the panic problem might be solved, but Ive just cvsupped with the
> > latest 4.0-CURRENT and the problems with pcm are definatly not over, Im
> > getting very jerky sound, its repeating bits of it over and over... and I
> > get messages like this while trying to play mp3s with mpg123:
> > 
> > May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt
> > 0xfff994bc flags 0x0141
> > 
> > Cheers
> > Andrew
> 
> I've run two systems with PCM right since the first newbus commit, and it's
> worked for me.  Admittedly I don't use it all that often, but it's never
> paniced and I don't recall getting any more sound problems than usual.
> 
> I checked that the isa_dma.c code is an exact split of the dma code that
> used to be in the old isa.c, there are zero changes to the isa dma code.
> 
> 
> > On Sat, 1 May 1999, Doug Rabson wrote:
> > 
> > > On Fri, 30 Apr 1999, Jordan K. Hubbard wrote:
> > > 
> > > > > It must be something that entered the tree late yesterday afternoon or
> > > > > an interaction between devices.
> > > > 
> > > > Same here...
> > > > 
> > > > FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999
> > > > j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY
> > > > ...
> > > > pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0
> > > > pcm0: interrupting at irq 5
> > > > 
> > > > And I'm using this right now to listen to an mp3 of a Loggins and
> > > > Messina album, so it must work. :-)
> > > > 
> > > > One thing I did notice which *is* kinda new, as of this last kernel,
> > > > is this:
> > > > 
> > > > smbus0:  on bti2c0
> > > > smb0:  on smbus0
> > > > bktr0: interrupting at irq 17
> > > > Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner.
> > > > devclass_alloc_unit: npx0 already exists, using next available unit 
> > > > numbe
> r
> > > > 
> > > > I'm pretty sure that npx0 does not "already exist" in this context,
> > > > leading me to believe that the message is actually being intermingled
> > > > with another probe's test or something is very odd here. :)
> > > 
> > > Do you have 'npx0 at isa?' in your config file by any chance?
> > > 
> > > --
> > > Doug Rabson   Mail:  d...@nlsystems.com
> > > Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> Cheers,
> -Peter
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Jordan K. Hubbard]

> Do you have 'npx0 at isa?' in your config file by any chance?

Whoops!  That's the problem; I failed to see that change in GENERIC
despite having scrolled past it more than several times.  My face is
red. :)

- Jordan


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Peter Wemm]

vortexia wrote:
> Heh, the panic problem might be solved, but Ive just cvsupped with the
> latest 4.0-CURRENT and the problems with pcm are definatly not over, Im
> getting very jerky sound, its repeating bits of it over and over... and I
> get messages like this while trying to play mp3s with mpg123:
> 
> May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt
> 0xfff994bc flags 0x0141
> 
> Cheers
> Andrew

I've run two systems with PCM right since the first newbus commit, and it's
worked for me.  Admittedly I don't use it all that often, but it's never
paniced and I don't recall getting any more sound problems than usual.

I checked that the isa_dma.c code is an exact split of the dma code that
used to be in the old isa.c, there are zero changes to the isa dma code.


> On Sat, 1 May 1999, Doug Rabson wrote:
> 
> > On Fri, 30 Apr 1999, Jordan K. Hubbard wrote:
> > 
> > > > It must be something that entered the tree late yesterday afternoon or
> > > > an interaction between devices.
> > > 
> > > Same here...
> > > 
> > > FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999
> > > j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY
> > > ...
> > > pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0
> > > pcm0: interrupting at irq 5
> > > 
> > > And I'm using this right now to listen to an mp3 of a Loggins and
> > > Messina album, so it must work. :-)
> > > 
> > > One thing I did notice which *is* kinda new, as of this last kernel,
> > > is this:
> > > 
> > > smbus0:  on bti2c0
> > > smb0:  on smbus0
> > > bktr0: interrupting at irq 17
> > > Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner.
> > > devclass_alloc_unit: npx0 already exists, using next available unit numbe
r
> > > 
> > > I'm pretty sure that npx0 does not "already exist" in this context,
> > > leading me to believe that the message is actually being intermingled
> > > with another probe's test or something is very odd here. :)
> > 
> > Do you have 'npx0 at isa?' in your config file by any chance?
> > 
> > --
> > Doug Rabson Mail:  d...@nlsystems.com
> > Nonlinear Systems Ltd.  Phone: +44 181 442 9037

Cheers,
-Peter




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Error while make world (cvsuped 990501). Sorry!

[REM]

My system was suped at 990501.

--
>>> elf make world started on Sat May  1 09:36:25 MSD 1999
--

[Skip]

cc: Internal compiler error: program cc1 got fatal signal 11
*** Error code 1

Sorry! My BIOS settings was incorrect! Make world is OK!

REM




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[vortexia]

Heh, the panic problem might be solved, but Ive just cvsupped with the
latest 4.0-CURRENT and the problems with pcm are definatly not over, Im
getting very jerky sound, its repeating bits of it over and over... and I
get messages like this while trying to play mp3s with mpg123:

May 1 10:12:16 main /kernel: timeout flushing dbuf_out, chan 3 cnt
0xfff994bc flags 0x0141

Cheers

Andrew

On Sat, 1 May 1999, Doug Rabson wrote:

> On Fri, 30 Apr 1999, Jordan K. Hubbard wrote:
> 
> > > It must be something that entered the tree late yesterday afternoon or
> > > an interaction between devices.
> > 
> > Same here...
> > 
> > FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999
> > j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY
> > ...
> > pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0
> > pcm0: interrupting at irq 5
> > 
> > And I'm using this right now to listen to an mp3 of a Loggins and
> > Messina album, so it must work. :-)
> > 
> > One thing I did notice which *is* kinda new, as of this last kernel,
> > is this:
> > 
> > smbus0:  on bti2c0
> > smb0:  on smbus0
> > bktr0: interrupting at irq 17
> > Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner.
> > devclass_alloc_unit: npx0 already exists, using next available unit number
> > 
> > I'm pretty sure that npx0 does not "already exist" in this context,
> > leading me to believe that the message is actually being intermingled
> > with another probe's test or something is very odd here. :)
> 
> Do you have 'npx0 at isa?' in your config file by any chance?
> 
> --
> Doug Rabson   Mail:  d...@nlsystems.com
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...

[David Greenman]

>Matthew Jacob wrote:
>> For raw pattern testing Linux has a special challenge since you right
>> directly into the buffer cache. There *is* a BLKFLSBUF ioctl that can try
>> and force a flush but this probably ought to be written to use O_FSYNC- I
>> think that the ll_rw code might use it or an fsync could be done...
>
>Linux' fsync() works only on directories, not on files.

   Huh? That doesn't make any sense. The "f" in fsync() stands for "file".

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: PCM

[Doug Rabson]

On Fri, 30 Apr 1999, Jordan K. Hubbard wrote:

> > It must be something that entered the tree late yesterday afternoon or
> > an interaction between devices.
> 
> Same here...
> 
> FreeBSD 4.0-CURRENT #0: Wed Apr 28 23:21:40 PDT 1999
> j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY
> ...
> pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0
> pcm0: interrupting at irq 5
> 
> And I'm using this right now to listen to an mp3 of a Loggins and
> Messina album, so it must work. :-)
> 
> One thing I did notice which *is* kinda new, as of this last kernel,
> is this:
> 
> smbus0:  on bti2c0
> smb0:  on smbus0
> bktr0: interrupting at irq 17
> Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner.
> devclass_alloc_unit: npx0 already exists, using next available unit number
> 
> I'm pretty sure that npx0 does not "already exist" in this context,
> leading me to believe that the message is actually being intermingled
> with another probe's test or something is very odd here. :)

Do you have 'npx0 at isa?' in your config file by any chance?

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...

[Andre Oppermann]

Matthew Jacob wrote:
> For raw pattern testing Linux has a special challenge since you right
> directly into the buffer cache. There *is* a BLKFLSBUF ioctl that can try
> and force a flush but this probably ought to be written to use O_FSYNC- I
> think that the ll_rw code might use it or an fsync could be done...

Linux' fsync() works only on directories, not on files.

-- 
Andre


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: solid NFS patch #6 avail for -current - need testers files)

[Doug Rabson]

On Fri, 30 Apr 1999, Kevin Day wrote:

> > > 
> > > To sum it all up is there any difference between the branches?
> > 
> > Yes.  We hope that people like you will help us by participating in the 
> > testing of potential releases _before_ they go out as releases, not 
> > _afterwards_.
> > 
> > Sitting around doing nothing and then complaining after the fact 
> > doesn't help anyone, least of all yourself.
> > 
> 
> This isn't meant in a bad way, but let me share with you my experiences.
> 
> Before 3.0 was released, I said several times "Hey, NFS got a lot worse on
> -CURRENT. Is anyone looking at this?" and got several replies of "Duh, this
> is -CURRENT. Don't whine about it. If you're trying to use this in a
> production environment, you're crazy."
> 
> After 3.0 was released, I said "Hey, 3.0 got released, and NFS was still
> broken", to which I got "Why didn't you bug us about this before the
> release?" and/or "Why didn't you test this before release?"
> 
> I understand NFS is a 'special' problem, but for those of us not in the
> trenches coding, I think the '3-level' system would be better. -CURRENT for
> those who are coding, -BETA for people like me to test things and bring up
> what broke, and -RELEASE for everyone else.
> 
> I honestly don't know when to bring up things like that, now. :)

I don't think a 3 branch system is workable for the simple reason that CVS
doesn't handle branches at all well. One possible alternative would be the
same structure that we have today with the addition of a 'last known good'
tag which is on the head branch and slides forward when a feature is
deemed 'good'. People who want features but don't want to fix them can
use this tag.

--
Doug Rabson Mail:  d...@nlsystems.com
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message