Re: [ATAng?] ad1 disappeared again
In [EMAIL PROTECTED] Chris Faulhaber [EMAIL PROTECTED] wrote: Could you try this patch and get back to me with the result please: Works for me: GEOM: create disk ad0 dp=0xc6972c60 ad0: 57241MB ST360015A [116301/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc6972b60 ad1: 57241MB ST360015A [116301/16/63] at ata0-slave UDMA100 Me too. Thanks! GEOM: create disk ad0 dp=0xc8304d60 ad0: 38166MB ST340810A [77545/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc866eb60 ad1: 38166MB ST340810A [77545/16/63] at ata0-slave UDMA100 -- NAKAJI Hiroyuki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/i386
TB --- /home/des/tinderbox/CURRENT/i386/i386/lock: flock(): Resource temporarily unavailable TB --- ERROR: unable to lock sandbox ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On Wed, 3 Dec 2003, Eric Anderson wrote: ... Well, there are so many kinds of PERC cards. Some are just Mylex cards. Others are MegaRAID. I think they use some Adaptec now. My troubles were with the MegaRAID variant, I'm not sure about the others.. Either way, I tried booting the install CD with all cards disconnected, just to see if I could get the installer up to the main menu. No go. The display switches off as soon as sysinstall starts probing devices. It appears to panic, but the display is dead. Once I was able to use scrolllock at the critical moment just before the kernel starts sysinstall, and prevent the display from switch off, but when I release the scroll lock, I was at the DDB prompt. Not good. First - I hope you mean the cards are physically OUT of the machine - it seemed to me that if they had a logical disk configuration on the card, it would hang. Although, it sounds like your problem is different. Actually, it kind of sounds like it thinks you are doing the -p boot thing to check for keyboard and roll over to the serial port. Other than that, I'm out of ideas (doesn't take long for that to happen though!).. :( Yes, the cards are physically out of the machine. -p seems unlikely, since the display is literally shutoff. The monitor goes into a power-save mode, so it appears that as soon as sysinstall touches whatever devices it touches, the onboard video stops generating output. I've also tried a serial console, which seems to fail the same way. There is simply no output to the serial console after sysinstall starts, and the machine appears to be hung. So, this was with 5.0 and 5.1. I will have to try 5.2 and see if it has the same problem. No one has contacted me about my PR, or even given me any suggestions about more debugging info that I can gather, so unless this gets fixed by chance, I suspect that 5.x is just going to orphan a significant number of machines. Which is a shame, since 5.x would be clearly superior on a quad Xeon machine than 4.9-RELEASE. Eric Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
On Wed, Dec 03, 2003 at 11:54:45PM -0800, David Schultz wrote: On Thu, Nov 27, 2003, Tim Robbins wrote: I've ported Niels Provos's file descriptor allocation code to FreeBSD in case anyone wants to try it out run some benchmarks. If the performance boost turns out to be worth the added complexity, I might clean it up a bit and commit it. I've used a similar data structure for a special-purpose allocator before, and it had extremely low allocation time overhead--- basically a few memory references for every level of the tree in the common case. Unless for some strange reason it pessimizes processes with a small number of file descriptors significantly, it would be really great to have this in the tree! It doesn't seem to make a noticeable impact on execution time for processes with small numbers of descriptors. It's probably swamped by the overhead of mode switches, locking, and filesystem operations. What makes uneasy is the amount of extra memory it consumes when processes have a small number of descriptors: (32**2)/8 = 128 bytes (when int is 32 bits), or (64**2)/8 = 512 bytes (when int is 64 bits). I've been thinking of switching to a flat bitmap for small fd tables, possibly just using a single int, or falling back to the old way of scanning fd_ofiles directly. Once I decide what to do about that and find someone to test my latest patch on a 64-bit machine, I'll commit it. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Port of Niels Provos's file descriptor allocation code
On Thu, Nov 27, 2003, Tim Robbins wrote: I've ported Niels Provos's file descriptor allocation code to FreeBSD in case anyone wants to try it out run some benchmarks. If the performance boost turns out to be worth the added complexity, I might clean it up a bit and commit it. I've used a similar data structure for a special-purpose allocator before, and it had extremely low allocation time overhead--- basically a few memory references for every level of the tree in the common case. Unless for some strange reason it pessimizes processes with a small number of file descriptors significantly, it would be really great to have this in the tree! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAPI CD still not detected, verbose boot logs available
On Wed, Dec 03, 2003 at 10:52:25PM +0100, Pav Lucistnik wrote: V st, 03. 12. 2003 v 22:39, Christoph Sold pí?e: On Wednesday 03 December 2003 09:55, Soren Schmidt wrote: Could you try this simple patch and see if that helps? Works for me. No problems so far during three reboots. Me too! My second Seagate drive is back and running. Ditto here. :-) I had quit complaining about this for a while, even though my DVD drive hadn't been working for quite some time. Didn't want to be a constant nuisance. :-) Glad to see the fix is in. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
