Re: New ATA driver and crash dumps
It seems Christopher Masto wrote: My machine panicked today for the first time since switching to the new ATA drivers, and I noticed that I no longer have crash dumps. Is this something that is expected to be put back in soon? I know Søren's a busy guy, and I'm glad we have the results of his work. I just hope the old drivers don't get killed off until the replacement has the same functionality. Then again, wddump() is only 100 lines of code, so I should probably try to fix it myself before whining. I know :), it has just not been done yet. It will be done eventually but I have other areas in the driver I want finish first. Also the old wd driver will probably not be killed off entirely, as its the only one we have that support old ST506/ESDI drives. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
egcs bug caused ftp hang problem
An egcs optimizer bug caused incorrect tcp checksum recalculation in libalias for the rewritten PORT command packet and the server subsequently discard the packet. The following piece of C code (from TcpChecksum() in alias_util.c) u_short *ptr; int sum, oddbyte; oddbyte = 0; *((u_char *) oddbyte) = *(u_char *) ptr; sum += oddbyte; is compiled into (%esi = ptr, %ecx = sum) 0x28067038 TcpChecksum+80:movb (%esi),%al 0x2806703a TcpChecksum+82:addl %eax,%ecx egcs should have zeroed %eax before the movb. libalias compiled without -O works correctly. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: newbus and modem(s)
On Wed, 21 Apr 1999 p...@originative.co.uk wrote: -Original Message- From: Peter Wemm [mailto:pe...@netplex.com.au] Sent: 20 April 1999 21:20 To: Doug Rabson Cc: Takanori Watanabe; freebsd-current@freebsd.org Subject: Re: newbus and modem(s) Doug Rabson wrote: On Mon, 19 Apr 1999, Peter Wemm wrote: [..] Now what I'm curious about is how to handle the nexus and isa/eisa better so they don't need to explicitly name the children. On one hand it could look at the hints table to see all the 'at nexus?' declarations, but I think it might be better to go for a hunt to locate all the children it can find. One way to do this might be to simply add a heap of unidentified devices and let the bus mechanism find all the devices that are children and let them probe themselves while ignoring the fake device id's. Perhaps this could change the probe order enough so that isa and eisa won't be attached until after pci has been recursively probed. I'm not sure how this would work. At the nexus, I think it has to know what the possibly attached devices are (or at least a list of names). The NetBSD code does a simple probe (e.g. checking for pci config method or looking for the mainboard ID) before adding devices. Thinking about this some more, the same problem is applicable to smart isa devices where the driver can find the card and the settings without any help. Presently it won't even get probed unless there is an 'at isa?' hint to cause the driver to be connected to isa. Presently, drivers are added to busses mostly in two ways. The first is where the bus has identification, and each identifier is added listing a device_id with an unknown driver/unit. The new-bus code will try all of the registered child drivers in turn until it finds one that matches and stops there. The isa bus on the other hand uses the hints to create a device instance that needs verification/probing. If there's no hint, the driver doesn't get a chance to probe. What I'd like would be for the busses to be able to call all the child drivers to let them look for themselves, and not stop until all are probed. For isa this would mean hint-less probing capabilities. For example, a driver could know that the hardware lives at one of 4 IO port addresses, so it could test them to see if it looks likely that there is one there. Doesn't this get in to the area we discussed some time back on the new-bus list about changing the way probing works so that instead of the pci code calling all the device drivers it just looks the device id up in a table and assigns that driver? I much prefer that direction than having all drivers called. Obviously there is danger in this as calling the generic probe routines with no hints at all (ie: all zero) will cause rather bad results on most existing drivers. Perhaps there could be a specific 'identify' method for drivers that support this. ie: the probe/attach sequence would become: bus identifies what it can, ie: find device id's or look up resource hints. bus calls all child drivers to probe what has been found or hinted at bus calls all child drivers with an identify methods to see if they can find something on their own without an id or hint. If I'm reading this right then you'd call an identify function in all available isa drivers and have them try and identify hardware? The risk here is that isa drivers/devices don't play well together and will trash you're machine if asked to probe for hardware that isn't present. If we do this, possible it should be restricted to 'wildcard' style declarations in the probe hints. -- 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: ed0: device timeout
On 21-Apr-99 Martin Blapp wrote: Hi, Recently I bought a new laptop and my ed0-pccard stopped working. This happened before the newconfig stuff came in. I first thought there were some irq-related problems, but I wasn't able to figure out where the problems are. The pccard-controller is now on irq 3 (SIO1 is disabled). I also tried to put it on irq 9 or 10 with set machdep.pccard.pcic_irq, after I disabled the soundcard. That worked, but the result was the same. Is suppose that the irq's aren't as free they should be. I tried other io-settings, other irq's, the result was the same. I had the same problem with ed0 not being recognized. I recompiled world and all was fine. Rick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/i386/conf LINT GENERIC
P.S.: USBDI as in, our version of it. The people from the consortium kicked us out. Can you elaborate on the reason that USBDI does not FreeBSD to be involved with the consortium? Money. We cannot pay the fee (1000 US $) to join the kindergarten aka consortium. No company was willing to pay it for us and the consortium was not willing to waive the fee, because not-for-profit organisations still draw a certain benefit for their community, or something along those lines. All sounds a bit strange if you consider the fact that the spec will be open and free-for-all eventualy. Tnks P.S.: Just got a 3 COM USB modem and I am going over the USB specs right now 8) The dev/usb/umodem.c file probes it. but the attach function is not filled in at all. Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/i386/conf LINT GENERIC
P.S.: USBDI as in, our version of it. The people from the consortium kicked us out. Can you elaborate on the reason that USBDI does not FreeBSD to be involved with the consortium? Money. We cannot pay the fee (1000 US $) to join the kindergarten aka consortium. No company was willing to pay it for us and the consortium was not willing to waive the fee, because not-for-profit organisations still draw a certain benefit for their community, or something along those lines. All sounds a bit strange if you consider the fact that the spec will be open and free-for-all eventualy. Tnks P.S.: Just got a 3 COM USB modem and I am going over the USB specs right now 8) The dev/usb/umodem.c file probes it. but the attach function is not filled in at all. Okay, I will take a look at the umodem.c driver. Tnks! Amancio -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files)
On Tue, 20 Apr 1999, Matthew Dillon wrote: NFS patch #6 is now available for -current. This patch has been extensively tested with NFS and with FFS+softupdates and has not screwed up yet, so I'm reasonably confident that it will not scrap whole filesystems :-) http://www.backplane.com/FreeBSD4/ Please remember to back-out all prior patches before applying this one. Note that the memory-zeroing code ( which is committed to -current ), is *correct* and should not be disabled. This patch is for CURRENT ONLY. Do not apply to -3.x unless you like seeing computer equipment melt! The only difference between patch #5 and patch #6 is that the VMIO directory backing mods have been removed. These mods worked, but appear to have resulted in an occassional softupdates panic during 'installworld'. It is more important for us to have a rock solid implementation then majorly optimized implementation, so... The patch will probably return later on when we figure out why it is causing softupdates to panic. Please post bug reports to -current or -hackers. .(14:57:37)(r...@thumper.reserved) /usr # mount /dev/da0s1a on / (local, soft-updates, writes: sync 598 async 27021) /dev/da0s1g on /home (local, soft-updates, writes: sync 25 async 679) /dev/da0s1f on /usr (local, soft-updates, writes: sync 738 async 42763) /dev/da0s1e on /var (local, soft-updates, writes: sync 106 async 1783) procfs on /proc (local) server:/usr/src on /usr/src server:/usr/obj on /usr/obj server:/home/ncvs on /home/ncvs /usr/src # for i in 1 2 3 4 5 6 ; do make world -j64 ; echo $i done.. ; done ../build.log nfs server server:/usr/obj: not responding nfs server server:/usr/obj: is alive again .(15:00:59)(r...@thumper.reserved) /usr # uptime 3:01PM up 6:55, 1 user, load averages: 1.72, 7.03, 7.34 .(15:01:47)(r...@thumper.reserved) /usr # grep ^[0-9] done build.log 1 done.. 2 done.. 3 done.. .(15:05:05)(r...@thumper.reserved) /usr # .(03:33:51)(r...@bright.reserved) /usr/obj # uptime 10:02AM up 14:40, 1 user, load averages: 0.18, 0.16, 0.14 yeah the clocks are not setup properly :) but otherwise i'm just gonna say HOLY SH*T you fixed NFS! :) Actually I just realized I'm not running nfsiod on the client, I just started up 8 of them (it's an SMP box). So far no problems. I'm using the default mount operations, as far as NFS server not responding messages, i have no clue, but the server is still up and i've seen that message happen when a lot of pressure is being put on an NFS server even though everything is fine. Normally i'd have client corruption and a rebooted server with both of them locked up sending out garbled RPC about now, but everything seems fine... great work! 2 questions I had: 1) you said you disabled partial writes that were causing these mmap() problems, they were causing problems because NFS had to muck with the structures directly in order to do zero copy? so if our NFS impelementation didn't do that it wouldn't be an issue probably. I know it's a good thing for speed and definetly essensial, but i'm not sure i understand NFS and the FS getting out of sync. 2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you an Julian talking about VM issues. :) Something you guys brought up was problems with mmap() + read()/write() no staying in sync and requireing an msync() to correctly syncronize. I really didn't understand how this could happen except recently I figured that my first question could be the answer. Does this problem only happen on NFS mounted dirs? Is it fixed? thanks again, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
someone fixed CPU time bug, thanks.
SMP on -current would lose the WCPU and CPU times after a while in top's output, this seems to be fixed on my machine/mobo with the latest source. Asus PD2 afaik dual 400mhz. thanks guys, great work! -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Please close PR gnu/9175
This PR is no longer validate now that g77 has enter the base distribution. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
yeah the clocks are not setup properly :) but otherwise i'm just gonna say HOLY SH*T you fixed NFS! :) We all owe Matt big for this. :) I'm using the default mount operations, as far as NFS server not responding messages, i have no clue, but the server is still up and i've seen that message happen when a lot of pressure is being put on an NFS server even though everything is fine. Try mounting with -d... Can I make a guess that the NFS mount is going over 100MB ethernet? I have a strong theory that the dynamic retransmit timer needs rework for low latency connections, with high variability in their performance during high traffic. (lots of collisions) Kevin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
On Wed, 21 Apr 1999, Kevin Day wrote: yeah the clocks are not setup properly :) but otherwise i'm just gonna say HOLY SH*T you fixed NFS! :) We all owe Matt big for this. :) I'm using the default mount operations, as far as NFS server not responding messages, i have no clue, but the server is still up and i've seen that message happen when a lot of pressure is being put on an NFS server even though everything is fine. Try mounting with -d... Can I make a guess that the NFS mount is going over 100MB ethernet? I have a strong theory that the dynamic retransmit timer needs rework for low latency connections, with high variability in their performance during high traffic. (lots of collisions) Hmmm, well the client/server are both on 100mbit full duplex switched ethernet, fxp0-fxp0 with no load other than the build going on. btw, just finished run 4 of buildworld, still kicking. I would just like to say, that unlike certain zealots of other operating systems I've always been a bit hesitant to recommend FreeBSD over solaris because of this one factor (NFS). It now seems I can't think of a single reason, (I'm much more a cluster fan than an SMP fan) SMP just doesn't buy you enough to justify putting all your eggs in one basket... Oh and the client is SMP, so i'm quite impressed on that fron as well. Oh and the newbus stuff rah rah rah! works like a charm except my USB (which i have no prepherals for anyhow). -Alfred 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)
Great work guys! It almost seems that -current is more stable than -stable! Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
On Wed, 21 Apr 1999, Alfred Perlstein wrote: On Wed, 21 Apr 1999, Kevin Day wrote: Try mounting with -d... Can I make a guess that the NFS mount is going over 100MB ethernet? I have a strong theory that the dynamic retransmit timer needs rework for low latency connections, with high variability in their performance during high traffic. (lots of collisions) Hmmm, well the client/server are both on 100mbit full duplex switched ethernet, fxp0-fxp0 with no load other than the build going on. With a full duplex setup collisions don't exist. In a switched setup the latency should be very consistent and extremely low. Something else must be wrong here. I'm very glad NFS is getting fixed - I'd really like to use FreeBSD in a frontend/backend setup with multiple round-robin DNS setup web servers with the web content on a backend NFS/RAID server. (poor man's Network Appliance equivalent :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need testers files)
:2 questions I had: : :1) you said you disabled partial writes that were causing these :mmap() problems, they were causing problems because NFS had to :muck with the structures directly in order to do zero copy? : so if our NFS impelementation didn't do that it wouldn't be :an issue probably. I know it's a good thing for speed and definetly :essensial, but i'm not sure i understand NFS and the FS getting out :of sync. The problem w/ the partial writes has to do with cache coherency between the server, the client's VFS subsystem ( read() and write() ), and the client's VM subsystem ( mmap() ). NFS implemented the notion of unaligned valid and dirty range using struct buf's b_validoff, b_validend, b_dirtyoff, and b_dirtyend fields in order to keep track of partial writes without having to read-in the rest of the buffer. The implementation was very fragile and failed to address a number of combination situations that would occur with mmap(), read(), and write(). This in turn lead to a series of problems and, further, lead to the situation where we would fix unrelated bugs in the VM system and cause NFS to break. I finally gave up on it. What NFS does now is optimize only two write situations: (1) when a write covers the entire buffer, e.g. an 8K+ write on an 8K boundry. And (2) piecemeal writes in the write-append case. Both cases allow us to mark the buffer as essentially being fully valid without having to mess with valid and dirty ranges. We use buf-b_bcount to handle the file EOF case and resize it rather then try to use b_validoff/b_validend. Thus, b_validoff/b_validend have been completely removed. b_dirtyoff/b_dirtyend have been left intact in order to allow us to support piecemeal write RPC's. This is different from the piecemeal write optimizations we were doing before. In this case, we are able to support piecemeal writes in the middle of the file that go into *PRELOADED* buffers. That is, A read-merge-write case. The original code attempted to do piecemeal writes without the read-before resulting in the partially invalid, partially dirty buffer. Now we only allow piecemeal writes to occur in fully-valid buffers. While we could theoretically discard the dirty range and simply writeback the entire buffer when a modification is made to part of it, we keep the dirty range in order to *only* write the portion of the buffer that the explicit write() covered. This is done for cache coherency reasons. For example, take the situation where two different client machines do a seek/write to different portions of the same server-backed NFS file, where the two areas abut each other. Say one client writes 2 bytes at seek offset 10 and the second client writes 2 bytes at seek offset 12. As long as the areas are not overlapping, we want this type of operation to work properly and not scramble the data on the server even if the client's idea of the state of the date is not coherent. :2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you :an Julian talking about VM issues. :) Something you guys brought up :was problems with mmap() + read()/write() no staying in sync and requireing :an msync() to correctly syncronize. I really didn't understand how this :could happen except recently I figured that my first question could be :the answer. Does this problem only happen on NFS mounted dirs? Is it :fixed? : :thanks again, :-Alfred This should not be an issue any more for either UFS or NFS. If people find that it is an issue, there's a bug somewhere that needs to be addressed. This *was* an issue for NFS prior to the patch set. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
: :I would just like to say, that unlike certain zealots of other operating :systems I've always been a bit hesitant to recommend FreeBSD over :solaris because of this one factor (NFS). : :It now seems I can't think of a single reason, (I'm much more a :cluster fan than an SMP fan) SMP just doesn't buy you enough to :justify putting all your eggs in one basket... : :-Alfred Heh. We still do not have file locking over NFS. That's a major piece. In general, though, I think FreeBSD's NFS is shaping up pretty well. It is certainly much, much better then any other OS out there except solaris. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
: We all owe Matt big for this. :) : : : I'm using the default mount operations, as far as NFS server : not responding messages, i have no clue, but the server is still : up and i've seen that message happen when a lot of pressure is : being put on an NFS server even though everything is fine. : : Try mounting with -d... Can I make a guess that the NFS mount is going over : 100MB ethernet? I have a strong theory that the dynamic retransmit timer : needs rework for low latency connections, with high variability in their : performance during high traffic. (lots of collisions) : :Hmmm, well the client/server are both on 100mbit :full duplex switched ethernet, fxp0-fxp0 with no load :other than the build going on. : :-Alfred I think Kevin is right re: the dynamic retransmit timeout. I've noticed it occuring on my systems too -- although without the lockups. But Kevin has other problems w/ his network that could be contributing to the problems he is experiencing. :btw, just finished run 4 of buildworld, still kicking. I've gone through 4 buildworlds so far without any errors using an NFS mounted /usr/src and /usr/obj. Though, I must say, it takes about twice as long as with a FFS+softupdates /usr/obj ( two hours verses 50 minutes ). The read optimization is very good, though. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
On Wed, 21 Apr 1999, Matthew Dillon wrote: : :With a full duplex setup collisions don't exist. In a switched setup the :latency should be very consistent and extremely low. Something else must :be wrong here. I should explain this more: It isn't actually the ethernet latency that is causing the problem, but instead it is the packet backlog that is occuring on the interface. Even at 100BaseTX speeds. Under a heavy NFS load, an NFS client might send several requests simultaniously or the server might send several responses simultaniously. If each request takes 0.5 mS to transit the network, the first request will have a latency of 1 ms, the second will have a latency of 1.5 ms. The third 2 ms. And so forth. When N requests are queued simultaniously, the last request in the queue will have a much longer latency then the first one. Full-duplex setups do not have collisions, but latency can occur due to internal switch routing latencies. Perhaps the timeout should be slightly adjusted it seems that it can cause panics, panics by users, not the kernel. :) As in... what the heck is this? when in reality everything is fine except a miniscule amount of latency on the interface. Some error messages should be constrained to DIAGNOSTIC so new users or people not interested in the kernel don't get nervous about freebsd. Everything seems fine, but why am i getting errors? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Reimer wrote: Great work guys! It almost seems that -current is more stable than -stable! Matt Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :) , WAS: Re: solid NFS patch #6 avail for -current - need tester
On Wed, 21 Apr 1999, Matthew Dillon wrote: : :I would just like to say, that unlike certain zealots of other operating :systems I've always been a bit hesitant to recommend FreeBSD over :solaris because of this one factor (NFS). : :It now seems I can't think of a single reason, (I'm much more a :cluster fan than an SMP fan) SMP just doesn't buy you enough to :justify putting all your eggs in one basket... : :-Alfred Heh. We still do not have file locking over NFS. That's a major piece. In general, though, I think FreeBSD's NFS is shaping up pretty well. It is certainly much, much better then any other OS out there except solaris. File locking over a stateless filesystem is just plain icky. Supposedly someone is working on client side locking, and I definetly will take a look at it just out of interest, not that i think i have a chance of implementing it. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? , :) , WAS: Re: solid NFS patch #6 avail for -current - need testers , files)
On Wed, 21 Apr 1999, Matthew Dillon wrote: :2 questions I had: : :2) at BAFUG 2 or 3 months ago I, *cough* attempted to keep up with you :an Julian talking about VM issues. :) Something you guys brought up :was problems with mmap() + read()/write() no staying in sync and requireing :an msync() to correctly syncronize. I really didn't understand how this :could happen except recently I figured that my first question could be :the answer. Does this problem only happen on NFS mounted dirs? Is it :fixed? : :thanks again, :-Alfred This should not be an issue any more for either UFS or NFS. If people find that it is an issue, there's a bug somewhere that needs to be addressed. This *was* an issue for NFS prior to the patch set. Ok, so is this what you and Julian were discussing about coherency issues? And it is fixed... cool. :) -Alfred 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)
Peter Wemm once wrote: Great work guys! It almost seems that -current is more stable than -stable! Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Speaking of, when can we expect to see this wonderfull _stability_ improvement in -stable? I'm setting up a server here, and would rather have fixed NFS code in it... Yet, jumping to -current is officially wrong... Thanks! -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:Matthew Reimer wrote: : Great work guys! It almost seems that -current is more stable than : -stable! : : Matt : :Funny you should mention it. I've heard this from a number of people over :the last week.. One has even suggested using a particular known-good 4.0 :snapshot in preference to a 3.1-stable for a production system.. : :Cheers, :-Peter I think that people should stick with 3.x unless there is something in -current that they really need such as the fixed NFS. current's core is very solid now and getting better, but a lot of the peripheral stuff has undergone rapid change. The new bus structure, the new compiler, the kernel build setup, configuration changes, and so forth. It's hard to keep up with it. I expect it will settle down in the next month or so. Most of the bug fixes have been backported to -stable. Getting the new VM system into -stable ( which I want to do just after the 3.2 release ) is going to require brute force, though. Unfortunately, the most recent fixes to NFS fall into that category so NFS-centric installations may need to use -current. :To Unsubscribe: send mail to majord...@freebsd.org :with unsubscribe freebsd-current in the body of the message : -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Thu, 22 Apr 1999, Peter Wemm wrote: Matthew Reimer wrote: Great work guys! It almost seems that -current is more stable than -stable! Matt Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Cheers, -Peter And on this note -- is it planned to merge or backport these patches to -stable? We make very heavy use of NFS (udp, 100mb fxp0 fullduplex). We're using FreeBSD-3.1-STABLE as NFS clients to a big Auspex NS7000 NFS file server. We're in production mode in our lab and can't risk running -current on many of our machines so we've decided to run -stable on ALL of them (except perhaps MY machine but don't tell anyone ;-) Tom To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Reimer wrote: Great work guys! It almost seems that -current is more stable than -stable! Matt Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. Cheers, -Peter Are there any particularly good snapshots one should try? I have a couple of spare boxes on the home net that I am willing to try or crash, for the fun of it. I was using the snap from about 3 weeks back on my home web server and it seems rock solid, but I am running rather plain hardware. Bob Keys To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
USB keyboard attach function?
While playing over here with the USB stuff, I rebooted the system and disconnected the USB keyboard waited till the system was fully up and re-connected the USB keyboard which resulted in the system not attaching the USB keyboard. A side note, someone fixed syscons so it no longer panics if the atkbd device is not configured . In my case, I have a USB keyboard and a USB mouse connected to the system with no atkbdc nor atbkd device . It works like a charm now 8) -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On Wed, 21 Apr 1999, Matthew Dillon wrote: :Matthew Reimer wrote: : Great work guys! It almost seems that -current is more stable than : -stable! : : Matt : :Funny you should mention it. I've heard this from a number of people over :the last week.. One has even suggested using a particular known-good 4.0 :snapshot in preference to a 3.1-stable for a production system.. : :Cheers, :-Peter I think that people should stick with 3.x unless there is something in -current that they really need such as the fixed NFS. current's core is very solid now and getting better, but a lot of the peripheral stuff has undergone rapid change. The new bus structure, the new compiler, the kernel build setup, configuration changes, and so forth. It's hard to keep up with it. I expect it will settle down in the next month or so. Most of the bug fixes have been backported to -stable. Getting the new VM system into -stable ( which I want to do just after the 3.2 release ) is going to require brute force, though. Unfortunately, the most recent fixes to NFS fall into that category so NFS-centric installations may need to use -current. I wonder if it would be too radical to suggest that the release cycle for 4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets worse and worse as time goes on and it just becomes a waste of programmer time. If we are reasonably careful with the 4.0 tree, I think a 4.0 release could be branched off it after 3.2 or maybe 3.3. It seems to me that merging a complex set of changes (such as the VM fixes or the new-bus work) from 4.0 to the 3.x branch would tend to produce a system which was less stable than the 'natural' environment for the software which is being merged across. -- 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 wonder if it would be too radical to suggest that the release cycle for :4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets :worse and worse as time goes on and it just becomes a waste of programmer :time. If we are reasonably careful with the 4.0 tree, I think a 4.0 :release could be branched off it after 3.2 or maybe 3.3. : :It seems to me that merging a complex set of changes (such as the VM fixes :or the new-bus work) from 4.0 to the 3.x branch would tend to produce a :system which was less stable than the 'natural' environment for the :software which is being merged across. : :-- :Doug RabsonMail: d...@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 I think the existing release schedule is pretty good. Any faster and we might as well not have two branches at all. We really need a -current branch in order to make and test radical changes, and the companies people who use FreeBSD need a -stable branch to keep production boxes up to date without having to bet the farm. We already have the ability to shortcut certain things simply by copying them from -current to -stable wholesale after we've determined their stability under -current. The issue here really is safety. I know some of you really want some of the things in -current to be backported into -stable more quickly, but you have to be patient. We can't compromise -stable's stability by acting too quickly. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
On 21-Apr-99 Matthew Dillon wrote: Most of the bug fixes have been backported to -stable. Getting the new VM system into -stable ( which I want to do just after the 3.2 release ) is going to require brute force, though. Unfortunately, the most recent fixes to NFS fall into that category so NFS-centric installations may need to use -current. -Matt Matthew Dillon dil...@backplane.com I'm curious, is there any plan to backport egcs to -stable or no? Also, as a side note: good thing we went with egcs, as it was just announced that egcs is now the official gcc. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use 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: USB keyboard attach function?
While playing over here with the USB stuff, I rebooted the system and disconnected the USB keyboard waited till the system was fully up and re-connected the USB keyboard which resulted in the system not attaching the USB keyboard. You need to be running usbd. In any case, we need some more work in the usb and ukbd driver code to be able to detach the ukbd driver while the system is running. A side note, someone fixed syscons so it no longer panics if the atkbd device is not configured . In my case, I have a USB keyboard and a USB mouse connected to the system with no atkbdc nor atbkd device . It works like a charm now 8) Hmm, I don't see why ukbd and syscons paniced in your system before. Kazu 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 Wed, 21 Apr 1999, Matthew Dillon wrote: :I wonder if it would be too radical to suggest that the release cycle for :4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets :worse and worse as time goes on and it just becomes a waste of programmer :time. If we are reasonably careful with the 4.0 tree, I think a 4.0 :release could be branched off it after 3.2 or maybe 3.3. : :It seems to me that merging a complex set of changes (such as the VM fixes :or the new-bus work) from 4.0 to the 3.x branch would tend to produce a :system which was less stable than the 'natural' environment for the :software which is being merged across. : :-- :Doug Rabson Mail: d...@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 I think the existing release schedule is pretty good. Any faster and we might as well not have two branches at all. We really need a -current branch in order to make and test radical changes, and the companies people who use FreeBSD need a -stable branch to keep production boxes up to date without having to bet the farm. We already have the ability to shortcut certain things simply by copying them from -current to -stable wholesale after we've determined their stability under -current. The issue here really is safety. I know some of you really want some of the things in -current to be backported into -stable more quickly, but you have to be patient. We can't compromise -stable's stability by acting too quickly. I totally agree about not wanting to compromise the stability of our release branch. However as the codebases diverge (and 3.0 diverged pretty massively from 2.2) it will get harder and harder to merge significant improvements across from the development branch without compromising the stability which we are trying to maintain. All I'm saying (I think) is that we shouldn't allow the 4.0 release cycle to stretch out to 2 years like the 3.0 cycle did (discounting 3.0 as a beta release). -- 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: USB keyboard attach function?
Don't worry quite a few fixes went into syscons so it is no longer isa centric. While playing over here with the USB stuff, I rebooted the system and disconnected the USB keyboard waited till the system was fully up and re-connected the USB keyboard which resulted in the system not attaching the USB keyboard. You need to be running usbd. In any case, we need some more work in the usb and ukbd driver code to be able to detach the ukbd driver while the system is running. A side note, someone fixed syscons so it no longer panics if the atkbd device is not configured . In my case, I have a USB keyboard and a USB mouse connected to the system with no atkbdc nor atbkd device . It works like a charm now 8) Hmm, I don't see why ukbd and syscons paniced in your system before. Kazu -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
:Speaking of, when can we expect to see this wonderfull _stability_ :improvement in -stable? I'm setting up a server here, and would :rather have fixed NFS code in it... Yet, jumping to -current is :officially wrong... Thanks! : : -mi Well, you already see a lot of the pure bug fixes being backported. What you don't see in -stable are the bug fixes that also depend on the rewritten portions of the system, nor do you see the rewritten portions of the system themselves. The latest NFS patch is borderline -- it would be possible to backport in time enough for the 3.2 deadline, but it wouldn't be fun. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
At 01:09 PM 4/21/99 -0700, Matthew Dillon wrote:
:Speaking of, when can we expect to see this wonderfull _stability_
:improvement in -stable? I'm setting up a server here, and would
:rather have fixed NFS code in it... Yet, jumping to -current is
:officially wrong... Thanks!
:
: -mi
Well, you already see a lot of the pure bug fixes being backported.
What you don't see in -stable are the bug fixes that also depend on the
rewritten portions of the system, nor do you see the rewritten portions
of the system themselves. The latest NFS patch is borderline -- it
would be possible to backport in time enough for the 3.2 deadline, but
it wouldn't be fun.
Hi,
Just wondering if these changes also have the side effect of fixing the
nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
the file, but then it does some really weird crap when dealing with
larger files.
It's the most idiotic code I've ever seen. The code uses a PRIVATE+RW
mmap() until it gets to odd point in the file, at which point it read()'s
additional information from the file into the mapped space ( that might
contain a previous mmap'd portion of the file ).
So what happens is this:
* read() call
* shared lock obtained on vnode
( some other process attempts to get shared lock on vnode and
succeeds... for example, a namei operation is attempted by
another grep )
* access MMAP'd area
* exclusive lock attempt obtained on same vnode. This blocks because
some other process has a shared lock on the vnode.
( the other process then attempts to get an exclusive lock on the
vnode this blocks.
Deadlock.
Even worse, the gnu grep does not bother munmap()'ing the space so, in
fact, the deadlock can occur between two unrelated files as well as with
the same file. This is the more likely deadlock scenario.
The solution is more difficult. We could hack an exception for PRIVATE
mmap's... there really is no need for the vm_fault code to lock the
vnode.
Howver, other situations can occur where this hack would not work.
This is 'kinda a known problem' in FreeBSD. We really need to find a
solution to it. Other similar deadlocks can occur if you mmap() one file
and read() or write() data from it to another file, and vise versa at
the same time.
Personally, I think the only real solution is to make vn_read() and
vn_write() lock the uio space as well as the vnode being read or
written. It would have to do it in the right order, and it would have
to deal with the situation where the uio space covers multiple vnodes.
Alternately, vnodes need to be redesigned without these fraggin
all-encompassing locks for data R+W ops.
-Matt
(kgdb) back
#0 mi_switch () at ../../kern/kern_synch.c:827
#1 0xf0151919 in tsleep (ident=0xf0a2e500, priority=0x8, wmesg=0xf0263a9c
inode, timo=0x0)
at ../../kern/kern_synch.c:443
#2 0xf014b774 in acquire (lkp=0xf0a2e500, extflags=0x140,
wanted=0x700) at ../../kern/kern_lock.c:145
#3 0xf014b835 in lockmgr (lkp=0xf0a2e500, flags=0x1030041,
interlkp=0xf51719b0, p=0xf5151200)
at ../../kern/kern_lock.c:209
#4 0xf0171df0 in vop_stdlock (ap=0xf5176b94) at ../../kern/vfs_default.c:210
#5 0xf0204b39 in ufs_vnoperate (ap=0xf5176b94) at
../../ufs/ufs/ufs_vnops.c:2309
#6 0xf017aba4 in vn_lock (vp=0xf5171940, flags=0x1030041, p=0xf5151200)
at vnode_if.h:811
#7 0xf01747b0 in vget (vp=0xf5171940, flags=0x1020041, p=0xf5151200) at
../../kern/vfs_subr.c:1348
#8 0xf0212f1e in vnode_pager_lock (object=0xf02af2b4) at
../../vm/vnode_pager.c:960
#9 0xf0206a56 in vm_fault (map=0xf51497c0, vaddr=0x805d000,
fault_type=0x3, fault_flags=0x8)
at ../../vm/vm_fault.c:243
#10 0xf022aebe in trap_pfault (frame=0xf5176d14, usermode=0x0,
eva=0x805d038) at ../../i386/i386/trap.c:816
#11 0xf022ab92 in trap (frame={tf_es = 0x10, tf_ds = 0x10, tf_edi =
0x805d000, tf_esi = 0xf223e000,
tf_ebp = 0xf5176e0c, tf_isp = 0xf5176d3c, tf_ebx = 0x1060, tf_edx =
0x0, tf_ecx = 0x700, tf_eax = 0x0,
tf_trapno = 0xc, tf_err = 0x3, tf_eip = 0xf0229ce4, tf_cs = 0x8,
tf_eflags = 0x10287, tf_esp = 0x1272,
tf_ss = 0x}) at ../../i386/i386/trap.c:437
#12 0xf0229ce4 in fastmove_loop ()
#13 0xf0229b2b in i586_copyout ()
#14 0xf01fd707 in ffs_read (ap=0xf5176ef0) at
../../ufs/ufs/ufs_readwrite.c:289
#15 0xf017a689 in vn_read (fp=0xf09dda80, uio=0xf5176f38, cred=0xf09ef480)
at vnode_if.h:303
#16 0xf015a757 in read (p=0xf5151200, uap=0xf5176f94) at
../../kern/sys_generic.c:121
#17 0xf022b4a0 in syscall (frame={tf_es = 0x2f, tf_ds = 0x2f, tf_edi =
0x0, tf_esi = 0x8000, tf_ebp = 0xefbf85c8,
tf_isp = 0xf5176fe4, tf_ebx = 0x, tf_edx = 0x8059000, tf_ecx
= 0xa, tf_eax = 0x3,
fxp driver and dhclient
When running dhclient with the kernel fxp driver I get a kernel panic in ifconfig. Might be some other things I enabled in the kernel, but I haven't double-checked yet. -- Eric Hodel hodel...@seattleu.edu 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)
:Hi, :Just wondering if these changes also have the side effect of fixing the :nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99 : : :The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing :the file, but then it does some really weird crap when dealing with :larger files. : I believe this was fixed in -current. I don't know if it was backported to -stable. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
Kazu == Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes: Kazu You need to be running usbd. Kazu In any case, we need some more work in the usb and ukbd driver code to Kazu be able to detach the ukbd driver while the system is running. Amancio and Nick helped me get my system with only a USB keyboard and USB mouse up and running. Right now I'm pretty happy with the way it is now. My only concern is that the FreeBSD bootloader does not appear to see keystrokes from the USB keyboard (which kinda makes it difficult to switch OSes on an USB only system). Kazu Kazu [Amancio: I'm currently building world in preparation for compiling a kernel without atkbdc and atkbd, as you suggested] Viren -- Viren R. Shah You are about as sharp as a sack of wet mice -- Foghorn Leghorn 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)
Speaking of upgrading to -current from 3.x-STABLE, I was just wondering -- does the new EGCS imply that things like apps2go Motif won't link properly against a 4.x-CURRENT world now? It's things like this that will hold me back, if they indeedy are a problem. Brian 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)
At 01:29 PM 4/21/99 -0700, Matthew Dillon wrote: :Hi, :Just wondering if these changes also have the side effect of fixing the :nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99 : : :The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing :the file, but then it does some really weird crap when dealing with :larger files. : I believe this was fixed in -current. I don't know if it was backported to -stable. Unfortunately no... It can still lockup a 3.x machine. ---Mike Mike Tancsa, tel 01.519.651.3400 Network Administrator,m...@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
Hi, is now. My only concern is that the FreeBSD bootloader does not appear If you are running -current as of at least last nite you will not have any problems with the bootloader and your USB keyboard in fact I just rebooted my test system and was able to select the kernel to boot; previously, you are right the bootloader didn't work with a USB keyboard only system. -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
Amancio == Amancio Hasty ha...@rah.star-gate.com writes: Amancio Hi, is now. My only concern is that the FreeBSD bootloader does not appear Amancio If you are running -current as of at least last nite you Amancio will not have any problems with the bootloader and your USB Amancio keyboard in fact I just rebooted my test system and was able Amancio to select the kernel to boot; previously, you are right the Amancio bootloader didn't work with a USB keyboard only system. You are right! I just rebooted after a make world and a new kernel, and it worked!!! Cool. Viren -- Viren R. Shah You are about as sharp as a sack of wet mice -- Foghorn Leghorn To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :)
Matthew Dillon dil...@apollo.backplane.com wrote: [Partial writes] I finally gave up on it. What NFS does now is optimize only two write situations: ... And (2) piecemeal writes in the write-append case. I'm nothing like an NFS expert, so I may be talking through my hat, but... I presume NFS correctly supports O_APPEND semantics for multiple clients (as seen from the server). In this case, the optimization only works when there's only one client machine (though possibly multiple processes on that machine) is using write+O_APPEND. Peter 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)
Hi, At 4:34 pm -0700 20/4/99, Matthew Dillon wrote: NFS patch #6 is now available for -current.[etc] Looks real good here. Been running two servers continuously building the world with their /usr/obj cross-mounted on each other. Oh, and one of them is SMP running -j8. Great job! -- 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
NFSv3 seriously broken in 3.1
I'm only subscribed to freebsd-stable, so I missed the original thread, but reading the lines below, a question arises: On Wed, 21 Apr 1999, Matthew Dillon wrote: Well, you already see a lot of the pure bug fixes being backported. What you don't see in -stable are the bug fixes that also depend on the rewritten portions of the system, nor do you see the rewritten portions of the system themselves. The latest NFS patch is borderline [...] Are you aware that NFSv3 seems to be seriously broken, at least for FreeBSD 3.1 clients connecting to a Solaris 2.6 server? Has that been fixed for current resp. stable? If not, what can I do to help getting this fixed? Symptoms are the following: We upgraded a perfectly running 2.2.7 client to 3.1, and out of a sudden NFS performed sluggish, sometimes even hanging for ten, twenty seconds, even five minutes or more. Adding the NFSv2 compatibility option to the AMD tables solved the problem. Gerald -- Gerald Jerry pfei...@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new-bus Success
I am running 4.0-current SMP, cvsup today and built an hour ago. Everything seems OK. Great work. tomdean 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'm curious, is there any plan to backport egcs to -stable or no? No. Also, as a side note: good thing we went with egcs, as it was just announced that egcs is now the official gcc. Yep, I had some inside info that this was probably going to happen. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) 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)
Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) - Jordan 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)
Speaking of, when can we expect to see this wonderfull _stability_ improvement in -stable? I'm setting up a server here, and would Usually when we're sure it's not a pessimization in other ways. I think people are getting just a bit prematurely excited here, not to knock Matt's good work or anything but I think even he would be the last to jump up and down saying NFS is fixed! It's totally perfect now! as some younger, less wise heads are currently saying. :-) - Jordan 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 wonder if it would be too radical to suggest that the release cycle for 4.0 be *much* shorter than the 3.0 cycle. Maintaining two branches gets worse and worse as time goes on and it just becomes a waste of programmer time. If we are reasonably careful with the 4.0 tree, I think a 4.0 What's your definition of much in this case? I also disagree that the multi-branch model is a waste of programmer time since it's what keeps us able to have an experimental line of development at all. To programmers, that's pretty important. :) - Jordan 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'm curious, is there any plan to backport egcs to -stable or no? Also, as a There are no plans at this time to merge egcs over. This will only happen if time and hindsight prove egcs to be of low enough impact that it's suitable -stable material. - Jordan 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)
All I'm saying (I think) is that we shouldn't allow the 4.0 release cycle to stretch out to 2 years like the 3.0 cycle did (discounting 3.0 as a beta release). No argument there - the current schedule is 12 months for 4.0. 2 years far too long and merely the result of unforseen delays and more than a little paralysis over the issue. This caused a lot of soul-searching in core over our development practices, hopefully enough that we won't repeat that particular painful experience. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
On 21-Apr-99 Viren R. Shah wrote: Kazu be able to detach the ukbd driver while the system is running. Amancio and Nick helped me get my system with only a USB keyboard and USB mouse up and running. Right now I'm pretty happy with the way it is now. My only concern is that the FreeBSD bootloader does not appear to see keystrokes from the USB keyboard (which kinda makes it difficult to switch OSes on an USB only system). Isn't that a BIOS problem? I know the BIOSen I have here have an option to support USB keyboards etc... --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
newbus resource manager
Can newbus resource manager manage discontinuouse I/O port? Many PC-98 devices use discontinuous I/O port like: 0x00d0, 0x10d0, 0x20d0, 0x30d0, 0x40d0, ..., 0xf0d0 Current API seems to assume contiguity and not to be able to manage such I/O port addresses. ---+--+ KATO Takenori k...@ganko.eps.nagoya-u.ac.jp |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | FreeBSD(98) 3.1: Rev. 01 available! |http://www.jp.FreeBSD.org/| FreeBSD(98) 2.2.8: Rev. 01 available! +==+ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Book - Pulpit Confessions: Exposing The Black Church
CALL TODAY TO ORDER THIS BOOK - (800) 305-1458 [24hrs.] -- What nobody had the nerve to tell you until now. Real evidence of what you only suspected. The Black Church as you've never known it before. Pulpit Confessions: Exposing The Black Church by N. Moore $16.00 ISBN: 0-9658299-2-8 _ Pulpit Confessions: Exposing The Black Church is an honest, behind the scenes look at the African-American church. The author spent a decade as a preacher and pastor in the black church and is actually betraying an unofficial code of silence by writing this book. The author began ministry in his teens and was pastoring by his early twenties. He speaks frankly about his and other ministers' odysseys from sincere, well intentioned prodigies to cynical, sinful, showman. He soon discovered that things in the church were not as they seemed. In this ground-breaking book, he describes a secular and often profane ministerial community that is often shrouded in pseudo holiness. He exposes the thoughts and motivations of both ministers and congregations and their degenerate power struggles which often turn violent. He pulls no punches when he untangles the myths, unravels the mystique and reveals the secrets of the Black Church. _ ORDERING INFORMATION **Book will be sent via COD.** **COD charges are free for a limited time*** Pulpit Confessions: Exposing The Black Church by N. Moore $16.00 ISBN: 0-9658299-2-8 $3.00 Shipping _ Order By Phone 800-305-1458 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
The problem was not really a bios problem not sure what the guys did to fix the boot loader probably switch to using a dos int function to access the keyboard from the boot loader. -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
On 22-Apr-99 Amancio Hasty wrote: The problem was not really a bios problem not sure what the guys did to fix the boot loader probably switch to using a dos int function to access the keyboard from the boot loader. Hmm.. what does it do now? Just talk to the keyboard controller directly? The BIOS I have here have an option 'Port 60/64 emulation' in the USB related section... --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: USB keyboard attach function?
Viren R. Shah once stated: =Amancio and Nick helped me get my system with only a USB keyboard and =USB mouse up and running. Right now I'm pretty happy with the way it is =now. My only concern is that the FreeBSD bootloader does not appear to =see keystrokes from the USB keyboard (which kinda makes it difficult to =switch OSes on an USB only system). Provided I configure two video cards not to conflict, can I use two USB keyboard and two USB mice (or one USB and one usual of each) and run two independent X-servers? Two instances of sc? Thanks! -mi 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)
Jordan K. Hubbard wrote: Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Well, Windows works, using a loose definition of 'works'... 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)
Daniel C. Sobral wrote: Jordan K. Hubbard wrote: Funny you should mention it. I've heard this from a number of people over the last week.. One has even suggested using a particular known-good 4.0 snapshot in preference to a 3.1-stable for a production system.. That's a little foolish since we've still not found all the egcs optimizer bugs and whatnot; didn't you guys see the one Luigi found the other day for ftpd? Now *that* had to be some obscure debugging work! :-) Clearly, that goes to show Luigi must have no life... :-) Luigi is an interesting spelling of Louqi. The bug was actually in libalias. -- Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Book - Pulpit Confessions: Exposing The Black Church
what is this shit? damn, i need to tell my uncle, he used to be an assemblies of god preacher, and he has enough choice words on those racists to fill a book... this shit doesn't belong here. In reply: CALL TODAY TO ORDER THIS BOOK - (800) 305-1458 [24hrs.] -- What nobody had the nerve to tell you until now. Real evidence of what you only suspected. The Black Church as you've never known it before. Pulpit Confessions: Exposing The Black Church by N. Moore $16.00 ISBN: 0-9658299-2-8 _ Pulpit Confessions: Exposing The Black Church is an honest, behind the scenes look at the African-American church. The author spent a decade as a preacher and pastor in the black church and is actually betraying an unofficial code of silence by writing this book. [rest of racist drivel deleted] jim -- All opinions expressed are mine, if you| I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered! - #1, The Prisoner -- Inet: jbry...@tfs.netAX.25: kc5...@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant -- HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ 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)
Luigi is an interesting spelling of Louqi. Or even Luoqi, as his name is actually spelled. :-) Sorry, Mr. Chen, for the transposition of you and Luigi. Temporary brain fade! :) The bug was actually in libalias. Yes, also correct. - Jordan 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)
: Speaking of, when can we expect to see this wonderfull _stability_ : improvement in -stable? I'm setting up a server here, and would : :Usually when we're sure it's not a pessimization in other ways. I :think people are getting just a bit prematurely excited here, not to :knock Matt's good work or anything but I think even he would be the :last to jump up and down saying NFS is fixed! It's totally perfect :now! as some younger, less wise heads are currently saying. :-) : :- Jordan NFS is definitely not fixed. NFS/TCP is still broken, the leasing stuff is still broken, and probably a bunch of other esoteric situations will cause breakage. There are still issues with stale file handles. There is no locking support ( however much NFS locking is a bad idea in general ). But it's *much* better then it was before'. The patch is certainly good enough to commit into -current. It is not commitable to -stable, though, because it depends on -current's VM VFS/BIO system. From my point of view, NFS/VM/VFS/BIO is now sitting where it *should* have been sitting a year ago if people had been paying more attention to it. If this were a Matt Dillon project, I would be sitting at my first 'beta' release :-( and everything up to this point would have been alpha. We have a long ways to go, folks. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
: work! :-) : : Clearly, that goes to show Luigi must have no life... :-) : : :Luigi is an interesting spelling of Louqi. : :The bug was actually in libalias. : :-- :Steve Luoqi found a bug in the compiler's optimizer. I presume someone has/will commit a change to libalias to work around it, and hopefully Luoqi notified the EGCS people. This sort of optimizer bug is usually fairly easy to fix given demonstration code, and Luoqi presented demonstration code. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
Matthew Dillon wrote: : work! :-) : : Clearly, that goes to show Luigi must have no life... :-) : : :Luigi is an interesting spelling of Louqi. Whoops! Luoqi ;-) :The bug was actually in libalias. : Luoqi found a bug in the compiler's optimizer. I presume someone has/will commit a change to libalias to work around it, and hopefully Luoqi notified the EGCS people. This sort of optimizer bug is usually fairly easy to fix given demonstration code, and Luoqi presented demonstration code. Luoqi committed a fix, but I don't remember if he fixed egcs or libalias. In his commit message, he states that he sent a bug report to the egcs people. -- Steve 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)
:Just wondering if these changes also have the side effect of fixing the
:nmap problem that crashes 3.x boxes ? i.e. as you wrote back on 3/4/99
:
:The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing
:the file, but then it does some really weird crap when dealing with
:larger files.
:
I believe this was fixed in -current. I don't know if it was backported
to -stable.
Unfortunately no... It can still lockup a 3.x machine.
This is the only thing stopping me from upgrading our production machines
to 3.1-STABLE.
Please, please, please backport these fixes!
--
:{ an...@speednet.com.au
Andy Farkas
System Administrator
Speed Internet Services
http://www.speednet.com.au/
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 was just wondering -- does the new EGCS imply that things like apps2go Motif won't link properly against a 4.x-CURRENT world now? My Apps2go Motif works just file post-EGCS. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Alright, who's the smart alleck that fixed NFS this last week? :)
: :I'm nothing like an NFS expert, so I may be talking through my hat, :but... I presume NFS correctly supports O_APPEND semantics for :multiple clients (as seen from the server). In this case, the :optimization only works when there's only one client machine (though :possibly multiple processes on that machine) is using write+O_APPEND. : :Peter I don't this was ever supported or ever will be in the multiple-client case. Maybe eventually with the leasing stuff. Otherwise, no way. The stateless nature of NFS makes it virtually impossible. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
