Re: solid NFS patch #6 avail for -current - need testers files)
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
Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
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: PCM
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: System Management Bus on bti2c0 smb0: SMBus general purpose I/O 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...
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
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: System Management Bus on bti2c0 smb0: SMBus general purpose I/O 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
Error while make world (cvsuped 990501). Sorry!
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 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: System Management Bus on bti2c0 smb0: SMBus general purpose I/O 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
Re: PCM
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
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: System Management Bus on bti2c0 smb0: SMBus general purpose I/O 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: -stable vs -current (was Re: solid NFS patch #6... )
-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: ep0 *UTP*
It seems Dag-Erling Smorgrav wrote: Alex Zepeda garba...@hooked.net 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: ep0 *UTP*
Soren Schmidt s...@freebsd.dk 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: solid NFS patch #6 avail for -current - need testers files)
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: default route not set up??
Lars Fredriksen l...@odin-corporation.com 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
sound and sio problems after newbus changes
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
Odd message during -current boot
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
Re: Odd message during -current boot
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
Re: ep0 *UTP*
It seems Dag-Erling Smorgrav wrote: Soren Schmidt s...@freebsd.dk 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: default route not set up??
Dag-Erling Smorgrav wrote:
Lars Fredriksen l...@odin-corporation.com 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: DUMMYNET broken in -current ?
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: Any action on PR 10570 ? getting closer to 65K :-(
John Polstra writes: Snob Art Genre wrote: On Fri, 30 Apr 1999, Poul-Henning Kamp wrote: In message xfmail.990430112019@polstra.com, 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: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
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: default route not set up??
Daniel C. Sobral d...@newsguy.com 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: sound and sio problems after newbus changes
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: Odd message during -current boot
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: Further on tape CAM problems
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
voxware drivers
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: SoundBlaster Pro 3.1 sb0: interrupting at irq 5 mpu0 at port 0x330 irq 9 on isa0 snd0: MPU-401 0.0 Midi interface mpu0: interrupting at irq 9 opl0 at port 0x388 on isa0 snd0: Yamaha OPL3 FM 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 sound
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: SoundBlaster Pro 3.1 sb0: interrupting at irq 5 mpu0 at port 0x330 irq 9 on isa0 snd0: MPU-401 0.0 Midi interface mpu0: interrupting at irq 9 opl0 at port 0x388 on isa0 snd0: Yamaha OPL3 FM 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: ep0 *UTP*
On 1 May 1999, Dag-Erling Smorgrav wrote: Soren Schmidt s...@freebsd.dk 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
Re: PCM
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 SB16 PnP 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 z...@uffdaonline.net 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)
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: default route not set up??
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
netatalk (atalkd,papd,afpd)
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: XFree86 and egcs
In article 199904282026.oaa13...@zen.alb.khoral.com, Steve Jorgensen st...@khoral.com wrote: In article 199904271932.naa01...@zen.alb.khoral.com, Steve Jorgensen st...@khoral.com 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
Re: PCM
I'm using a _PnP_ card, and mine comes up as: pcm1 (CS423x/Yamaha/AD1816 Yamaha SA2 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: 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. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
silo overflows in CURRENT ... some info that may help
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
New ATA drivers wont boot if second IDE controller enabled
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#
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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.
Re: sound and sio problems after newbus changes
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: sound and sio problems after newbus changes
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: BitKeeper (was 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. 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: PCM
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 z...@uffdaonline.net 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)
-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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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: -stable vs -current (was Re: solid NFS patch #6... )
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: default route not set up??
Daniel C. Sobral d...@newsguy.com writes: Dag-Erling Smorgrav wrote: Daniel C. Sobral d...@newsguy.com 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
Strange figures reported by i586_bzero...
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=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX 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: math processor 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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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
Re: RE: solid NFS patch #6 avail for -current - need testers files)
: 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 dil...@backplane.com :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: Further on tape CAM problems
[ 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: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
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
Sv: ep0 *UTP*
- Oprindelig meddelelse - Fra: Soren Schmidt s...@freebsd.dk Til: Dag-Erling Smorgrav d...@flood.ping.uio.no Cc: garba...@hooked.net; jbry...@unix.tfs.net; freebsd-current@FreeBSD.ORG 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: -stable vs -current (was Re: solid NFS patch #6... )
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
Re: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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: Problems with ahc (2940U2W) and USB
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: e...@habatech.no To: freebsd-current@FreeBSD.ORG 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: solid NFS patch #6 avail for -current - need testers files)
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
FBSDBOOT.EXE
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: PCM
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
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. 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: solid NFS patch #6 avail for -current - need testers files)
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)
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)
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)
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: PCM
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
if_xl.c noise
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: Linux char devices (was: Porting Greg Lehey's rawio.c from FreeBSD to Linux...)
On Sat, May 1, 1999, Greg Lehey g...@lemis.com 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).
rant
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
/rant
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. sniff :)
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=getsearch=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 b...@shub-internet.org http://www.shub-internet.org/brad/
http://wwwkeys.pgp.net:11371/pks/lookup?op=getsearch=0xE38CCEF1
Your mouse has moved. Windows NT must be restarted for the change to
take effect. Reboot now? [ OK
Re: if_xl.c noise
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: if_xl.c noise
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
apmconf(8) -e ends to panic in apm_bios_call
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: APM BIOS 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
: :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
Re: silo overflows in CURRENT ... some info that may help
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.. Doug 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)
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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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: FBSDBOOT.EXE
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
mem.c v1.57 and mp_machdep.c v1.99 and kernel panic
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: (FWD) Re: Progs linked against libstdc++ dead...
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
Re: FBSDBOOT.EXE
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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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)
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 robe...@eurocontrol.fr 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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
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: FBSDBOOT.EXE
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)
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 robe...@eurocontrol.fr 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
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: mem.c v1.57 and mp_machdep.c v1.99 and kernel panic
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
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: IDE DMA timeouts (was: Kernel won't boot from IDE disk)
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 50rdy, seekdone 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: BitKeeper (was Re: solid NFS patch #6 avail for -current - need testers files)
The folks who did BitKeeper have a compare/contrast section in their web page that talks about BitKeeper vs. CVS and Perforce. http://www.bitkeeper.com 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: Call for Review: Voxware midi driver for serial ports
From: Juergen Lock n...@jelal.kn-bremen.de 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, noxJuergen Lock n...@jelal.kn-bremen.de 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
