Re: UDMA interfering with install
Jonathan Smith wrote: That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. So we removed it from the kernel config... and the damn thing enabled it again. I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: Jonathan Smith wrote: That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. You lost me here, what version of FreeBSD are we talking about ? I thought it was 4.3 but that doesn't contain any ifdef's about DMA at all -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
That's good enough. :) Thanks Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. What do you mean with this? The procedure that I described (barring typos) do work here and was used here to install and run FreeBSD on a silly A+ motherboard. Without disabling the DMA the install would fail and even if I installed with DMA disabled, but rebooted afterwards with DMA enabled, it would corrupt the filesystem to an almost unusable state. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. So we removed it from the kernel config... and the damn thing enabled it again. I don't know if the #ifdef was intended to only guard in the boot case, but it doesn't help, because there are several missign guards around the code, if that's the case, and at least four places in the code ignore the tuning variable, as well, if it isn't commented out of the kernel at build time (thus disabling one of the places). Look for the #ifdef, and then look for the function call to do the enable, and the problem will be obvious. I'm not sure where the #ifdef comes into play. I didn't even recompile anything, so whatever #ifdef can be whatever it likes to be. Jun 5 18:42:51 d-5-71 /boot/kernel/kernel: ad0: 4104MB SAMSUNG SW0434A (4.3GB) [8896/15/63] at ata0-master PIO4 John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
Bosko Milekic wrote: I plan to commit the new bits within the next week. However, as is usually the case with commits of this magnitude, I'd like a few more tests to be run by a few more people. I've been testing the allocator myself (in several different ways, mainly resource exhaustion simulations) for the past couple of weeks and have been able to catch and fix a couple of bugs. Also, jake, jlemon, and Silby (Mike Silbersack) have provided me with some reviews, all of which have been integrated into the latest version of the patch (below). A general comment, and then a comment on the patch: I would like to see this code be optional, until such time as benchmarks have proven it to be better than the existing code, or have proben it to be worse. Diking out the existing code, and forcing it to be diked out by making unnecessary function name changes seems to me to be a problem. Overall, I like the idea of moving towards a Dynix allocator type model to support many processors (not just 4) well, but I'm leery of many of the changes, particularly in light of the claim that It has been established that we do not benefit from different locks for different objects, so we use the same lock, regardless of object type. On to the specific comments... I have addressed them in patch order, so that they can be read side-by-side: -- The npg calculation has always been incorrect for large memory systems with non-sparse physical maps, and now it is much worse. I commented on this before in -arch. Consider the case of a machine with 4G of physical memory. -- Is the policy two line or 4 line license, these days? -- The MBALLOC_CPU stuff should be more dynamic; it appears that the real number of CPUs is known at the time the allocations take place. -- I think you should spin, and only block if you don't get the spin lock after several attempts. The Solaris tradeoff in this regard is 10 attempts. Direct blocking on the cv seems a little wasteful. -- I'm not sure why you mutex the per-CPU containers? Aren't they, by definition, per-CPU, and therefore immune from contention? -- You realize that there is a dependency on MAXFILES, right? Specifically, there is an mbuf allocated per open socket for the tcptmpl (even though it only needs 60 bytes). --- If you fix the tcptmpl allocation, a couple of additional issues arise: 1) Since the allocations are in page-units, you will end up with a lot of waste. 2) Allocation in page units will make it hard to give 60 byte allocations back to the system. 3) The allocator is not really general enough for this (or for things like TIME_WAIT zombie structs, etc.). 4) Yeah, this sort of also implies that mbuf cluster headers come from a seperate pool, instead of being 256 bytes as well... -- Why do you lock around things in mb_init()? It's never called twice, let alone reentrantly... the code will be done before an AP is allowed to run. Alpha has this same restriction, from what I can see from the code. -- Dropping the lock in mb_pop_cont() seems wrong; I guess you are avoiding sleeping with the lock held? I don't think you need to worry (per-CPU, again), unless you later attempt lazy repopulation; it seems to me that the lock that should be held is a global lock, to prevent reentrancy on the global memory pool, and the malloc() code does that. Perhaps I'm missing something here. -- The ability to specify a how that implies an unwillingness to block implies interrupt allocation; yet you can't support this, since you do not preallocate a kernel map (ala the zone allocator). The zone allocator is actually very misleading, in that some of it's code never has the values it implies that it might have; in particular, there are functions which are passed parameters which can't really be variant, as implied by the use of per zone variables as arguments. -- Ah. I see why all the locks: mb_alloc_wait attempts to be a primitive reclaimer. You would do much better with a per-CPU high-watermark reclaim at free(), I think, instead of doing this. Really, you are in a starvation condition because of your load, and not because someone is hogging already free mbufs, I think. This is probably premature optimization. -- In the starvation case during a free, I don't think you really care, except perhaps to adjust the high/low watermarks. An interesting issue here is that the average TCP window size will end up being 16k, which comes out to 4 1-page buckets (2, on Alpha), where you end up with multiple buckets and many mbufs (64) per, so freeing isn't really an option, if you are sending lots of data (serving content). It would be different for a desktop system, since the receive interrupt might come to any idle CPU. -- I like the cleanup via the use of local macros. -- I think the m_getclr - m_get_clrd change is gratuitous. -- I like the only comment claifications. -- I
Re: msdosfs can't mount Extended partition. Any ideas?
In message [EMAIL PROTECTED] Bruce Evans writes: : The first ls should create about 8000 new tun devices by first accessing : them via stat(2), but there is some garbage collection, so the second ls : may show that some of the devices have magically unappeared. I just want to see the disk slices that are availabe. Define 'available'? If there are two slices, and they overlap, which one should be visible? Or both, with exclusion based on whichever is opened first? There are a lot of nasty corner cases here. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: msdosfs can't mount Extended partition. Any ideas?
In message [EMAIL PROTECTED] Mike Smith writes: : Define 'available'? If there are two slices, and they overlap, which one : should be visible? Or both, with exclusion based on whichever is opened : first? All slices that the system considers to be valid. Ditto partitions on *BSD slices that we recognize as such. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Supported ATAPI cdr/cdrw drives
Good day! On Mon, 28 May 2001, Søren Schmidt wrote: As promised I've made up a list of reports I've received so far go to http://freebsd.dk/ and follow the link. I also have a patch for the Yamaha's (yamaha-cdr.p1) which also can be found via the above URL. Let me know if that make things work... yamaha-cdr.p1 is mode 0600, there is yamaha-cdr.p2, but it does not apply cleanly (FreeBSD srv2.any 4.3-STABLE, cvsupped about 7-8 Jun). I tried to apply it manually, and everything was ok. The disk was written and closed successfully. Thank you. When MFC'ing, close my PR 25960 :) -- ---+--- Is that not what living is for?| Regards, Alexey V. Neyman | mailto: [EMAIL PROTECTED] ( Pkunk, SC2 )-+--- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
Søren Schmidt wrote: Maybe _that_ will keep that ata code from over-riding the bios to disable dma (or maybe the bios just wasn't doing it's job right ;) This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... This was a 4.3 system -- things seem to have changed in the source tree since then. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
It seems Terry Lambert wrote: Søren Schmidt wrote: This won't work. Someone was having the same problem the other day, and I suggested the same soloution, but after probe, the damn driver enabled UDMA at attach time anyway. Just set hw.ata.ata_dma=0 in /boot/loader.conf and it will not enabled DMA.. So we removed it from the kernel config... and the damn thing enabled it again. There is nothing in the config file that affects DMA... This was a 4.3 system -- things seem to have changed in the source tree since then. Nope. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). there is no atapi.c... This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. I think you are confused :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA interfering with install
S?ren Schmidt wrote: This was a 4.3 system -- things seem to have changed in the source tree since then. Nope. In 4.3, it's not possible to disable DMA, because it gets reenabled in many places (atapi.c, etc.). there is no atapi.c... This was off-topic for -current, unless the original poster was running 4.3-RELEASE or a RELENG_4_3_0_RELEASE... Sorry for the confusion. I think you are confused :) I expected you might say this... I will beat on the system in question for its source code revisions and file names tomorrow (it's not mine: it has IDE drives). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No Subject
Salve, Con DirectLine potrai riferirti ad un unico operatore per tutte le tue chiamate urbane, interurbane, internazionali e verso cellulari a tariffe MAI VISTE... Segnalando il servizio ai tuoi amici, arriverai ad eliminare del tutto la bolletta telefonica, e se gli amici sono tanti... potrai addirittura guadagnare denaro! la DirectLine è lieto di annunciarLe nuovi ribassi di tariffe in vigore dal 1 Maggio 2001 NUOVE TARIFFE IN VIGORE DAL 1 Maggio 2001 +--+---+-+ | Destinazione| Fascia | Fascia | | |Ord. | Rid.| +--+---+-+ |Italia Urbano | 50 | 40 | |Italia Inter. | 85 | 70 | |Italia Cell. | 450 | 450| +--+---+-+ TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE ! IL GIRO DEL MONDO CON POCHE LIRE +--+---+ | Destinazione| Tariffa | | | al min/Lre| +--+---+ |Francia | 170 | |Germania | 170 | |Grecia| 399 | |Hong Kong | 349 | |Ungheria | 349 | |Irelanda | 170 | |Israele | 539 | |Giappone | 349 | |Korea del Sud | 399 | |Olanda| 259 | |Filippine | 1049| |Polonia | 500 | |Portogallo| 419 | |Spain | 170 | |Svizzera | 170 | |U.S.A | 170 | |UK| 170 | |Venezula | 699 | |Canada| 170 | |Brazil| 699 | |Argentina | 699 | +--+---+ per visualizzare la tabella, impostare il carattere Courier INOLTRE SONO PREVISTE SCONTI APPLICABILI SULLE DESTINAZIONI PIU' CHIAMATE TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE ! Cordiali saluti ISCRIZIONE - Per iscrizione al servzio invia un messaggio a : mailto:[EMAIL PROTECTED]?Subject=SIGN-UP ed indicato il suo recapito telefonico ed sarete contattati °° ° DirectLine° ° NUMERO VERDE 800 787085 ° ° NUMERO VERDE 800 787086 ° ° mailto:[EMAIL PROTECTED]° °° +-+ |Questo messaggio e' stato inviato in seguito alla vostra | |iscrizione alla newsletter e se pertanto | |non avete richiesto informazioni al rigurado c'e' la possibilita'| |che qualcuno abbia inserito in errore il suo indirizzo email | | | +-+ Per cancellarVi dalla lista mandateci un e-mail all`indirizzo: mailto:[EMAIL PROTECTED]?Subject=cancel ed invia l'email Volete ricevere in futuro maggiori informazioni via email ? mailto:[EMAIL PROTECTED]?Subject=informazioni directline ed sarete contattati FINE NEWSLETTER dULTRA_v01.1_0614 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS v4
The only BSD-related NFSv4 work I know about is at: http://www.citi.umich.edu/projects/nfsv4/download/ The amount of BSD-related information on the CITI NFSv4 page has gradually diminished over time (that is, originally they proudly stated ports to Linux and OpenBSD, and now they proudly state a port to Linux and, by the way, here's an OpenBSD-related link). That said, I haven't been following the work, so don't know much about it, or if there is other relevant work elsewhere. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Thu, 14 Jun 2001, Ilmar S. Habibulin wrote: Do somebody works on it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
Hi Terry, On Thu, Jun 14, 2001 at 01:03:13AM -0700, Terry Lambert wrote: A general comment, and then a comment on the patch: I would like to see this code be optional, until such time as benchmarks have proven it to be better than the existing code, or have proben it to be worse. Diking out the existing code, and forcing it to be diked out by making unnecessary function name changes seems to me to be a problem. This is going to be a very difficult thing to do. Hear me out. :-) The present code has been designed without any SMP in mind and without any concept of allowing for the possibility to have pages that were once wired-down and put to use by the mbuf subsystem to being freed when no longer used so that memory could be reclaimed. The new code attempts to offer both, but as with almost anything, sacrifices must be made. I'm hesitant to accept your `benchmark this' offer merely because it's difficult to accurately quantify overall performance while it will be easy for the benchmark to detect that the new code is in some ways slower than the old (because of additional complexity) and therefore rule: old allocator new allocator, which is false given the ignorance of most benchmarks. I'll try my best to circle some of the Pros and Cons of each allocation technique and try to give you an overall picture of the tradeoffs and gains made. - The old allocator has one lock to protect all the free lists. As the number of CPUs grows, so does contention and, consequently, the mbuf allocator may become a significant bottleneck when several threads are servicing net-related requests. The new allocator has a lock per CPU thus allowing for more than one CPU to allocate mbufs and clusters at any one time, ultimately splitting contention in most cases. Additionally, the old allocator, in an SMP system, will likely have the lock (and list structure, etc.) ping-ponging from data cache to data cache whereas the new allocator, because of the separate lists and locks will minimize this effect. - The old allocator fragments memory and can never reclaim it and never easily determine if all the objects in one given page of data are free therefore if we were to ever decide that yes, it's now time to have the allocator free some pages back to the map, we won't be able to easily implement it (if at all). The new allocator has the framework for this type of thing so that if users continue requesting (as many have already done) to have FreeBSD free up resources it allocates for mbufs and clusters, we should be able to relatively easily implement freeing from a kproc, for example, and only do it, for example, when X number of bytes is in the pool but when only Y bytes are in use (where Y X). (Why from a kproc? Because freeing back to the map is relatively expensive for a thread that wants to merely free up an mbuf or cluster - this I *have* determined from previous profiling - results are probably archived somewhere on the lists). - The old allocator's macros MGET, MCLGET, MFREE, etc. could get away with making an allocation without performing a single function call. A function call was done only by those using the function equivalents m_get(), m_gethdr(), etc. The new allocator performs one function call in the common case for allocation. I don't foresee this to be a real problem - if it's any argument at all: NetBSD OpenBSD have both been doing this for quite a long time (one function call per allocation) and in fact so have we before this allocator was introduced to replace calls to malloc() _and_ also as a result, the new allocator has shrunk those macros to effectively nothing in terms of size thus improving overall performance (less code cache pollution) whereas the old allocator has, needless to say, pretty large macros. - The common case of allocation and freeing in the new allocator is larger (although realistically, not significantly) than the common case for the old allocator. This is due to the added complexity in the new allocator and is expected. The increase in size of the common case is basically from `insignificant' to `insignificant + insignificant' when taking into account the fact that CPU speed is increasing incredibly quickly. Keep in mind that although it may take longer to execute the common case in the new allocator, the fact that there is less contention in the same common case may make it faster, overall. - The old allocator has all mbufs and clusters mixed in the same heap and there is no concept of `producer' and `consumer' in that although one thread may allocate an mbuf and write to it, and another thread may only free the mbuf, the second thread will, if the first thread is on another CPU, that CPU's data cache entries for the given mbuf because during freeing, the thread will write to the mbuf. Since in the new allocator mbufs
Re: new ipv6 causes panic
Thus spake Michael Harnois ([EMAIL PROTECTED]): Building the kernel without INET6 makes this error go away. cvsup as of about two hours ago. Is it fixed now? Ume has committed a fix to the mbuf locks recently. Alex (I just got the same panic with a different traceback with a kernel from before the fix as well). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
$B!JL5NA%3%s%F%s%D!K(BFREE JAPANESE TOONS UPDATED DAILY!
To cancel your subscription please click on the link : http://64.23.86.178/rejectmail.html XXX FREE-ASIAN DAYLY PICTURE ARCHIVE! Japanese 10 pics updated daily! Point your browser at: http://www.free-asia.com/free/okazu/ JAPANESE SCHOOL GIRL'S GOLDEN ARCHIVES! Our favorite now with over 1000 good NO CUT samples at: http://www.hentaij.com/gold/ JAPANESE TEENS PUSSY ARCHIVE! JAPANESE PUSSY!! 10+ nice free 10 pics updated daily from my lists at: http://www.free-asia.com/free/pussy/ AMATEUR 2000 JAPANESE GIRLS! Best favorite 2000 good samples and more than 2000 girls photo at: http://www.amateurj.com/2000/ HENTAI SUKIYAKI GIRLS ARCHIVE! Get the latest on Asian's bad girl and her boy toy at: http://www.free-asia.com/free/sukiyaki/ JAPANESE HENTAI CRAZY MAG! All Japanese Crazy pics. Definitely So great mag at: http://www.hentaij.com/crazy/ SEXY MODELS AND QUEENS ROSE SCAN! 1000 free pics if you scroll down the page from: http://151.196.201.3/ ALL AMATEUR WOMAN ARCHIVE! Lots of Amateur pics rotated here. Check it out now: http://www.amateurj.com/ama/ MANIA BONDEGE AND RAPE JAPANESE WOMAN! 1000 + nice Hentai SM pics. there is this: http://151.196.93.148/sm/ JAPANESE AMATEUR XXX ARCHIVE! Lots of Asian Amateur Teens pics rotated here: http://www.hentaij.com/teens_vip/ Copyrighted (c) FREE-ASIA.COM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Clever! The kernel make that won't die...
Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot oot/kernel make all === 3dfx ^C ^C'd it nellie.feral.com === accf_data root mak=== accf_http e nellie.feral.com === agp === aha fg=== amr bash: fg: current: no such job nellie.feral.com === an === aue === cam === ccd === cd9660 === coda === cue === dc === de === dgm === digi === digi/digi === digi/digi_CX === digi/digi_CX_PCI === digi/digi_EPCX === digi/digi_EPCX_PCI Terminated killall make from another xterm === digi/digi_Xe === digi/digi_Xem === digi/digi_Xr That make- takes a licking, but keeps on ticking. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clever! The kernel make that won't die...
On Thu, Jun 14, 2001 at 12:38:43PM -0700, Matthew Jacob wrote: Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot oot/kernel make all === 3dfx ^C^C'd it nellie.feral.com === accf_data root mak=== accf_http e ... === digi/digi_CX === digi/digi_CX_PCI === digi/digi_EPCX === digi/digi_EPCX_PCI Terminated killall make from another xterm === digi/digi_Xe === digi/digi_Xem === digi/digi_Xr That make- takes a licking, but keeps on ticking. Is it make, or is it the compiler? I once, years back, saw some really pathological C code that made de C-compiler's optimizing step go bonkers. It just never stopped trying to figure out the code ;) Entertaining.. -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clever! The kernel make that won't die...
Oh, this is make On Thu, 14 Jun 2001, Wilko Bulte wrote: On Thu, Jun 14, 2001 at 12:38:43PM -0700, Matthew Jacob wrote: Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot oot/kernel make all === 3dfx ^C ^C'd it nellie.feral.com === accf_data root mak=== accf_http e ... === digi/digi_CX === digi/digi_CX_PCI === digi/digi_EPCX === digi/digi_EPCX_PCI Terminated killall make from another xterm === digi/digi_Xe === digi/digi_Xem === digi/digi_Xr That make- takes a licking, but keeps on ticking. Is it make, or is it the compiler? I once, years back, saw some really pathological C code that made de C-compiler's optimizing step go bonkers. It just never stopped trying to figure out the code ;) Entertaining.. -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clever! The kernel make that won't die...
On Thu, Jun 14, 2001 at 12:38:43PM -0700, Matthew Jacob wrote: Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot tot... what?:-) Hello? Are you still there?:-) oot/kernel make all === 3dfx ^C^C'd it nellie.feral.com === accf_data root mak=== accf_http e nellie.feral.com === agp === aha fg=== amr bash: fg: current: no such job nellie.feral.com === an Well... this seems rather strange... is this several ttys output or just one? That make- takes a licking, but keeps on ticking. Yes, FreeBSD's real mascot is the Energizer Bunny don't you know? It just keeps going and going and going and ... Seriously: no, I have never seen anything like it. And I never use -j for kernel builds either... what is possible is however this: there was some talk about ^C, ^Z and friends being incorrectly masked by the login routine thus making these useless in some cases even after login. (With the original point being that you shouldn't be able to use these while logging in) This is supposed to be fixed now, but maybe you have the buggy version running? Also, the talk was that while bash (and sh?) were affected, tcsh wasn't, and since that's what I use, maybe that's why I never noticed this... What is the date of your current world? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Clever! The kernel make that won't die...
On Thu, 14 Jun 2001, Szilveszter Adam wrote: On Thu, Jun 14, 2001 at 12:38:43PM -0700, Matthew Jacob wrote: Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot tot... what?:-) Hello? Are you still there?:-) Top of Tree oot/kernel make all === 3dfx ^C ^C'd it nellie.feral.com === accf_data root mak=== accf_http e nellie.feral.com === agp === aha fg=== amr bash: fg: current: no such job nellie.feral.com === an Well... this seems rather strange... is this several ttys output or just one? That make- takes a licking, but keeps on ticking. Yes, FreeBSD's real mascot is the Energizer Bunny don't you know? It just keeps going and going and going and ... Seriously: no, I have never seen anything like it. And I never use -j for kernel builds either... what is possible is however this: there was some This was not a -j talk about ^C, ^Z and friends being incorrectly masked by the login routine thus making these useless in some cases even after login. (With the original point being that you shouldn't be able to use these while logging in) This is supposed to be fixed now, but maybe you have the buggy version running? Also, the talk was that while bash (and sh?) were affected, tcsh wasn't, and since that's what I use, maybe that's why I never noticed this... Ah. I use bash. Maybe that's it. Even in -stable bash will break massively a number of ports builds. What is the date of your current world? June 5th... -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Clever! The kernel make that won't die...
I've also seen this while making ports. If I ^C while fetch is trying to connect to the distfile site, it doesn't die. It might be that the mk.* stuff is spinning off shells and allowing them to become disconnected from terminal input somehow. -Original Message- From: Szilveszter Adam [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 2:12 PM To: [EMAIL PROTECTED] Subject: Re: Clever! The kernel make that won't die... On Thu, Jun 14, 2001 at 12:38:43PM -0700, Matthew Jacob wrote: Heh- is this a bug or a feature? Making a kernel, no -j args, -current, tot tot... what?:-) Hello? Are you still there?:-) oot/kernel make all === 3dfx ^C ^C'd it nellie.feral.com === accf_data root mak=== accf_http e nellie.feral.com === agp === aha fg=== amr bash: fg: current: no such job nellie.feral.com === an Well... this seems rather strange... is this several ttys output or just one? That make- takes a licking, but keeps on ticking. Yes, FreeBSD's real mascot is the Energizer Bunny don't you know? It just keeps going and going and going and ... Seriously: no, I have never seen anything like it. And I never use -j for kernel builds either... what is possible is however this: there was some talk about ^C, ^Z and friends being incorrectly masked by the login routine thus making these useless in some cases even after login. (With the original point being that you shouldn't be able to use these while logging in) This is supposed to be fixed now, but maybe you have the buggy version running? Also, the talk was that while bash (and sh?) were affected, tcsh wasn't, and since that's what I use, maybe that's why I never noticed this... What is the date of your current world? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
tcsh.cat
Hi folks I'm having a prob with tcsh.cat when performing a a make install after a buildworld and can't seem to shrug it off and or find a reason to it's occurance does any one know of a fix as I cant go any further :( /bin/tcsh - /bin/csh install -c -o root -g wheel -m 444 csh.1.gz /usr/share/man/man1 /usr/share/man/man1/tcsh.1.gz - /usr/share/man/man1/csh.1.gz === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat install: /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat: No such file or directory *** Error code 71 Stop in /usr/src/bin/csh/nls/finnish. *** Error code 1 Stop in /usr/src/bin/csh/nls. *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cheers Adrian [EMAIL PROTECTED] __ _ / /___ ___ / __ ) ___// __ \ / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / / __/ / / / __/ __/ /_/ /__/ / /_/ / /_/ /_/ \___/\___/_//_/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Thu, Jun 14, 2001 at 22:53:25 +0100, Adrian Browne wrote: Hi folks I'm having a prob with tcsh.cat when performing a a make install after a buildworld and can't seem to shrug it off and or find a reason to it's occurance does any one know of a fix as I cant go any further :( It seems that 'make hierarchy' step is missing somehow, so required directories are not created. 'make world' definitely create them. Probably you run 'make install' instead of 'make installworld' which create them too. /bin/tcsh - /bin/csh install -c -o root -g wheel -m 444 csh.1.gz /usr/share/man/man1 /usr/share/man/man1/tcsh.1.gz - /usr/share/man/man1/csh.1.gz === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat install: /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat: No such file or directory *** Error code 71 Stop in /usr/src/bin/csh/nls/finnish. *** Error code 1 Stop in /usr/src/bin/csh/nls. *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. cheers Adrian [EMAIL PROTECTED] __ _ / /___ ___ / __ ) ___// __ \ / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / / __/ / / / __/ __/ /_/ /__/ / /_/ / /_/ /_/ \___/\___/_//_/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New SMP Mbuf Allocator (PATCH and TESTING request)
FWIW- your patches appear to work fine for top of tree alpha. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh.cat
On Fri, 15 Jun 2001, Andrey A. Chernov wrote: On Thu, Jun 14, 2001 at 22:53:25 +0100, Adrian Browne wrote: Hi folks I'm having a prob with tcsh.cat when performing a a make install after a buildworld and can't seem to shrug it off and or find a reason to it's occurance does any one know of a fix as I cant go any further :( It seems that 'make hierarchy' step is missing somehow, so required directories are not created. 'make world' definitely create them. Probably you run 'make install' instead of 'make installworld' which create them too. /bin/tcsh - /bin/csh install -c -o root -g wheel -m 444 csh.1.gz /usr/share/man/man1 /usr/share/man/man1/tcsh.1.gz - /usr/share/man/man1/csh.1.gz === bin/csh/nls === bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat install: /usr/share/nls/fi_FI.ISO8859-1/tcsh.cat: No such file or directory *** Error code 71 There is a bug somewhere, possibly related to error handling for installworld when the hierarchy is incomplate, that causes the tcsh.cat symlink to point to the empty pathname. ISTR that once you have such a symlink for tcsh.cat, installworld is unable to recover even when the hierarchy is fixed (I used the easy fix of removing the symlink). Related bugs: - symlink(2) is happy to create a symlink to the empty pathname although empty pathnames are invalid. - many utilities are confused by symlinks to the empty pathname. ISTR that one error mode is to blindly append a slash to pathnames, so gets transformed to the completely different pathname /. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pxeboot broken
Does anyone else also have problems with pxeboot on -current? I just rebuilt a system and the pxeboot just garbles the screen when it starts. I have a pxeboot built on May 5 that do work. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
