Re: bikeshed
On Friday, 12 September 2003 at 5:10:39 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], [EMAIL PROTECTED] ibsd.org writes: Did you ever consider that your doing exactly what phk's logo protests? ;) Maybe that is why phk hasn't responded any further, because he's laughing at you! You have to admit that is just a bit ironic. Well, the reason I didn't answer until now was that I was eating some sort of fish (species now forgotten). But let me make it 100% clear: You can use the no bikeshed logo for anything you want, anywhere you want, anytime you want with the following simple exception: YOU MAY NOT UNDER ANY CIRCUMSTANCES _EVER_ make it the subject of a bikeshed discussion. The question is, can you restrict use of the topic in this manner? Since you have received no consideration for the topic, in most countries you can't restrict its use. Greg -- See complete headers for address and phone numbers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I've just had a massive file system crash
On Sunday, 26 January 2003 at 14:24:02 +1030, Daniel O'Connor wrote: On Sun, 2003-01-26 at 08:08, David Schultz wrote: Good. I was referring to IDE in this case, because I assume that's what Greg's laptop uses. The ATA driver flushes the cache when the device is closed, but I don't think that happens during shutdown. It probably needs to register a shutdown hook like the SCSI driver. Also, the driver is a bit optimistic about how long the flush will take; it times out after 5 seconds, whereas the ATA spec says a flush can take up to 30 seconds. I am wondering if I experienced this problem with my -stable laptop.. I shut it down and then booted it up later to find fsck having a nice good chew on the drive (deleting REAMS of files). Did you use shutdown -p? If my hypothesis is correct, it's possible to get this result with shutdown -h if you press the power switch as soon as the System halted message appears, but normally you'd give it a few seconds longer. With shutdown -p, it's immediate, modulo delay. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
I've just had a massive file system crash
I'm rather astounded. I'm currently at a Linux conference, and have of course been boasting about the stability of ufs, and today I had a crash which tore apart my /home file system. This is on a laptop, one which has been running -CURRENT for years with no trouble. At the moment it's running 5.0-RELEASE. Today I shut it down cleanly, and a couple of hours later rebooted it. It has three file systems, one of which came up dirty. fsck -y reported thousands of errors, and when it was finished, my home directory and some other files were gone, and all the subdirectories of my home directory were in lost+found, a total of 1.4 GB. Most of the errors appear to be duplicate Inode numbers. Obviously it's too late to work out what happened, but I thought it's worth mentioning in case somebody else is having the same trouble. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
On Friday, 24 January 2003 at 20:34:24 +1000, Andy Farkas wrote: I'm rather astounded. I'm currently at a Linux conference, and have of course been boasting about the stability of ufs, and today I had a crash which tore apart my /home file system. This is on a laptop, one which has been running -CURRENT for years with no trouble. At the moment it's running 5.0-RELEASE. Today I shut it down cleanly, and a couple of hours later rebooted it. It has three file systems, one of which came up dirty. fsck -y reported thousands of errors, and when it was finished, my home directory and some other files were gone, and all the subdirectories of my home directory were in lost+found, a total of 1.4 GB. Most of the errors appear to be duplicate Inode numbers. Obviously it's too late to work out what happened, but I thought it's worth mentioning in case somebody else is having the same trouble. I can only think that your disk is going bad. That was one of my thoughts too. Try a dd if=/dev/ad0 of=/dev/null and see if you get any read errors. Nope, runs fine. It also doesn't explain why it happened at startup time. On Friday, 24 January 2003 at 6:53:41 -0500, Thomas David Rivers wrote: Don't be too hasty to blame UFS. I'm not. I've just reported what happened, in case others see it. On Friday, 24 January 2003 at 11:06:26 -0500, Robert Watson wrote: Next time you run fsck -y in this scenario, log the output to an md partition and stick it somewhere for analysis. At least, that was the moral of the story last time I hosed a box in this form (incidentally, I think it ended up being a failing hard disk). Yes, if you know it's going to happen. I could easily have written it to /var/tmp, which was mounted. I just wasn't expecting anything like this to happen. I've been using UFS on a daily basis for over 10 years, and this is the first time this has happened to me. I've been thinking about what happened, and I have a possibility: the session before shutdown included a lot of writing to that file system, and I did a shutdown -p. It's possible that the shutdown powered off the system before the disk had flushed its cache. For the moment I'm avoiding shutdown -p, but when I get home I'll try to provoke it again. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What is user uucp good for?
On Tuesday, 5 November 2002 at 21:57:50 +0100, Marcin Cieslak wrote: Kris Kennaway ([EMAIL PROTECTED]) napisa?(a): On Sat, Nov 02, 2002 at 04:11:39PM +1030, Greg 'groggy' Lehey wrote: A number of base system utilities and ports still use it for access to the serial port devices (which are owned by the uucp user). Really, the uucp user is now misnamed and should be called something like Let's leave it like it is. Maybe future generations will wonder what it is named after similarly to GCOS field in passwd today :-) At the very least we should change the shell. But Kris' suggestions sound the best. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serial break into debugger broken from 'cu' on -CURRENT?
On Sunday, 10 March 2002 at 10:07:07 -0500, Robert Watson wrote: For the past couple of months, I've been working with a set of identical test boxes from SGI which, for some reason, stopped responding to serial break on the serial console. I switched to the 'alternative break' option in LINT, and things work fine. I assumed it was actually some issue with that particular batch of machines, since no one else had had a problem, and I didn't really have time to follow up. Yesterday, I brought online two more crash boxes via serial console, both older TeleNet servers, and noticed that neither of them respond to serial break over the serial console using cu. This leads me to wonder two things: (1) Is serial break currently broken in -CURRENT Yes, I think so. (2) Is serial break currently broken in 'cu'? No opinion, since I haven't tried using it. What I have observed is: I use the same gdb for remote serial debugging both for FreeBSD and Linux (ia32). That's right, it's a FreeBSD box running FreeBSD gdb in both cases. I can break to the Linux kernel, but not to the FreeBSD kernel. From this, I conclude that it's a kernel issue, not a gdb issue. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Tuesday, 5 March 2002 at 9:43:29 -0800, Matthew Dillon wrote: phk wrote: you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. This is an extreme misrepresentation of the facts. I stated very clearly at the original Yahoo SMP summit that I would soon not be available. I did what work I could before I became unavailable, and then I was, SURPRISE! Unavailable for 2 years! I did not abandon anyone. I wrote that code that is the basis for allowing us to remove Giant from syscalls, I wrote the original idle process code including all the hard assembly stuff. I cleaned up the pre-SMPng SPL masks (cpl and cml). I did what I could in the time I had. I've got to defend Matt here. This happened exactly the way he says. This in no way detracts from the work John has done, of course. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for critical_enter()/critical_exit() interrupt assem
On Thursday, 7 March 2002 at 14:30:47 -0800, Matthew Dillon wrote: after reverting the change and silently waiting for a week 1/ no person bothered to review it. 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to optimization and those objections haven't been sanely answered with anything more constructive than BS. Warner I think John has a right to object to the work based on it being an optimization, but that should not sufficient reason in anyone's book to veto a commit, especially something that is as straightforward and obvious as I believe my work to be in this case. I think this is a good point. We're in a development phase now, and we shouldn't step on each others' feet. But Matt has gone to some trouble to ensure it can be turned off at will. Come a release, it's possible that the project manager might decide to chop it out again, but I'm betting on it staying. Another issue: sure, it's partially an optimization. Sure, it contains MD code. But it also fixes bugs. Should a policy of structure now, optimize later mean we should reject bug fixes which also perform better? And will we, in the long term, be able to eliminate MD code and still have good performance? I think the issue of i386 only is a non-issue. It has to start somewhere, and it doesn't break the other platforms. Unlike John, I am not the type of person who leaves hundreds of kilobytes of patches laying around my tree. For me completed work is either committable, or it should be thrown away. Without prejudice to John (I don't know how much uncommitted stuff he has), I think that Matt's right here too. Where practicable, smaller increments are easier to handle. John's other objections - in regards to interference with future work, are completely unsubstantiated. He has not explained any reasoning for his objections AT ALL other then to make vague, undirected comments about how it doesn't fit with his idea of the world. He pointed me to a 10-page mini paper and I even after reading it I do not see how any of my work inteferes with anything he is doing. Core has asked John to describe his objections. Based on the current flam^H^H^H^Hdiscussion, I'm sure people will agree that it's probably better to discuss things in a smaller group first. The results will, of course, be made known. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SMPng manager's responsibilities (was: Patch for critical_enter()/critical_exit() interrupt assem)
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote: On Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. So, where is it? *sigh* It's not explicitly in the statement. I mentioned this point in core, and got the reply: Core recognizes John Baldwin's continued hard work on the SMPng project over the last 18 months. John has been informally directing the SMPng project for some time and we would like to formalize the arrangement. We are officially recognizing him as technical lead and he will be the final arbiter of technical issues relating to SMPng. I think we should say that he is responsible to core for his decisions. That would deflate some of dillon's objections. That goes without saying. Sigh. I'm getting tired of putting that in every last damn thing we do. This is not a differences of direction within core. We had a long discussion, and in the end it's a question of formulation. As I feared, this particular issue has been dragged up again. The text quoted above was version 5 of the draft. The final statement contained the additional text He has the authority to take those actions necessary to keep the SMPng effort on track, similar to the Security Officer's authority in the area of security. If you look back to *that* charter, you'll see that the SO is also responsible to core. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SMPng manager's responsibilities (was: Patch for critical_enter()/critical_exit() interrupt assem)
On Thursday, 7 March 2002 at 16:43:40 -0800, David Greenman wrote: On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote: On Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. So, where is it? *sigh* It's not explicitly in the statement. I mentioned this point in core, and got the reply: I think Julian is asking for John's justification, not our appointment message. Ah, sorry. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Well, maybe, like me, he doesn't know how. I only recently learnt of the existence of this repo, and I still don't know where it is. It certainly wasn't announced on the SMP mailing list. I've seen a few references to p4 there, but no indication of how to access the repo. What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also be doing a lot of acquires and releases of sched_lock. I must be misinterpreting this statement. Under what circumstances do you spin? Yes, I read the while the owner is running in another CPU, but the way I read that, it turns the blocking lock into a spin lock. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Version control software (was: Patch sets to date and timing tests with Giant out of userret.)
On Tuesday, 19 February 2002 at 16:44:06 -0800, David O'Brien wrote: On Tue, Feb 19, 2002 at 01:51:31PM -0700, M. Warner Losh wrote: Bitkeeper enforces the linux devleopment model to a large extent, In what way(s)? I'd be interested in this too. I've been using Bitkeeper for, well, Linux development, but I don't see anything which locks it in to that direction. Of course, Bitkeeper isn't free either, so there's no particular reason to prefer it to p4. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)
On Tuesday, 19 February 2002 at 0:00:19 -0800, Peter Wemm wrote: Julian Elischer wrote: I'd prefer to be working on a branch of CVS if it weren't for the people that would scream whenever I moved my merged tag up. (eek eek cvsup bloat). That way i would have a dozen people helping me but with my code in P4 I have me and occasionally Peter. Everybody who can commit to cvs on freefall also has p4 access. Well, I certainly missed this. The set of people who can help is exactly the same. In fact, we even have a couple of non-comitters with access. As I posted before, When? the instructions are in http://people.freebsd.org/~peter/p4cookbook.txt, and the 'p4newuser' command on freefall is what is run to activate it. If we want a majordomo [EMAIL PROTECTED] mailing list (or something like that, as an analog to [EMAIL PROTECTED]), I can have that set up as well. Am I the only person who, despite careful scrutiny, missed this announcement? I would have thought that this would at least have been worth a HEADS UP and prior discussion in -core. I've just checked my -core archive, and though we discuss this repo from time to time, there was nothing there to suggest that it was publicly available. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Monday, 18 February 2002 at 23:04:03 -0800, Peter Wemm wrote: Matthew Dillon wrote: What a waste.. John has already done all this stuff already (using td_ucred instead of p_ucred) over the entire tree. Cheers, -Peter He didn't instrument Giant, and if you actually believe that one massive commit is going to be more stable then the piecemeal safe-mode commits I am making then you are smoking something. Or are you expecting John to commit his patchset piecemeal as well and test inbetween? If that is so, then he just wasted a whole lot time managing all this junk in P4 because, frankly, it only took me a few minutes to instrument the easier system calls. I spend far more time testing. So, John's last few months of work is junk then, is it? On Monday, 18 February 2002 at 23:22:28 -0800, Peter Wemm wrote: Matthew Dillon wrote: So, John's last few months of work is junk then, is it? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] I'll tell you what is junk... patches for things like getuid() sitting in P4 (whether instrumented or not). That's junk. I'll tell what is NOT junk. What isn't junk are things like John's more complex patch to kern_descrip.c. There's real work involved there that can be salvaged, and which can be committed to the -current piecemeal if Giant is properly instrumented. The biggest problem is that all of this stuff is sitting in P4 and none of it belongs there. With all due respect, bullshit! The p4 tree exists only as an alternative to people having large uncommitted diffs sitting in checked out cvs trees. Mailing patches between people trying to work in parallel is a bigger waste of time. That is inherently single threaded. While I don't agree with dillon's tone, I can understand his frustration. There is a lack of communication in the SMP project. I might have done more myself if I had been able to follow it without being on IRC 24 hours a day. I suspect that this applies to other people as well. Note that dillon has suffered because of this. He has gone and done what looks like being unnecessary work. When he tries to commit it, he finds that somebody else has been working on it, and despite a kernel summit only a couple of days ago, he didn't know about it. I'm not picking on jhb here. This is the project's fault, not any individual's. We need some kind of project management to coordinate this effort, or the results will be seriously suboptimal. I would certainly not like to see dillon go away because it's too difficult to work with the project. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Wednesday, 20 February 2002 at 18:35:37 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [020220 18:26] wrote: I'm not picking on jhb here. This is the project's fault, not any individual's. We need some kind of project management to coordinate this effort, or the results will be seriously suboptimal. I would certainly not like to see dillon go away because it's too difficult to work with the project. First with the code complete has it go in. Seems pretty simple enough doesn't it? Too simple. It's not the code complete, it's the correct code to implement a part of the overall goal. And we should be working together, not duplicating each other's efforts. I've had quite enough of people telling others to hold off because i'll have the feature any day now, or that fix is in my local tree. That's a detail, though admittedly one that needs to be addressed. We have more serious issues. Last Friday I asked for an overall project plan, and I still haven't seen one. Yes, we had some useful discussions, but it's still not enough. If it took Sun 8 years of (relatively) careful project planning to get their SMP up to a reasonable standard, how can we hope to succeed if we don't even decide what we're trying to do? Two years ago I spoke with you on the phone about SMP, and said that I didn't think that the project could cope with such a pervasive change. That's why I was happy when BSD[Ii] dropped both the design and the code into our lap, and we had an SMP project manager (for all of 6 months). Looking back now, we're making the same old mistakes. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Wednesday, 20 February 2002 at 21:42:48 -0500, Andrew R. Reiter wrote: On Wed, 20 Feb 2002, George V. Neville-Neil wrote: I'm not in the core of the SMP stuff (the closest I'll get is the networking stuff) but I wonder if there is: Doesn't this belong on [EMAIL PROTECTED] so that SMP people could answer? Only up to a point. My issues (and George's, for that matter) are the project management side of things. I'm copying -developers, but maybe we need a different list: I'm open to suggestions. Maybe it's a symptom of the problem that there's no project management list. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: On 21-Feb-02 Greg Lehey wrote: On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Well, maybe, like me, he doesn't know how. I only recently learnt of the existence of this repo, and I still don't know where it is. It certainly wasn't announced on the SMP mailing list. I've seen a few references to p4 there, but no indication of how to access the repo. What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also be doing a lot of acquires and releases of sched_lock. I must be misinterpreting this statement. Under what circumstances do you spin? Yes, I read the while the owner is running in another CPU, but the way I read that, it turns the blocking lock into a spin lock. Only in some cases. This is the classic way of implementing an adaptive mutex. Well, no, the classic way of implementing an adaptive lock is to spin a little bit and then block. Alternatives would be to learn what's going on and then decide whether to spin or block, or how long to spin before blocking. I've never heard it applied to a choice of CPU. Obviously any spin lock shouldn't spin if the lock holder is in the same CPU. You spin if the other thread is actually executing on another CPU (the idea being it will release the lock soon so you are better off avoiding the context switch) and block if it is not executing on another CPU (releasing the lock is already at least one context switch away, so we might as well switch). If you're talking about Giant here, one of us is seriously misunderstanding something. The whole idea of Giant is that it should be a blocking lock, not a spin lock. Tell me I'm misunderstanding you. The very first project milestone at http://www.freebsd.org/smp/ read Convert the giant lock from spinning to blocking. You might say ah, but the average system call takes less time than a schedule. We can test that. I've run lmbench on zaphod and found: Scheduling overhead:18 µs Null syscall (1 CPU):9 µs Null syscall (2 CPUs): 57 µs So this doesn't stand up. Note also that if there are more than two CPUs, the loss of time is much more significant. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: microuptime went backwards
On Saturday, 26 January 2002 at 16:28:04 +0100, Gabriel Ambuehl wrote: -BEGIN PGP SIGNED MESSAGE- Hello, I just installed 5 CURRENT (20.1. snapshot) on a K6-2 500 whic was previously running 4.4 STABLE without any problems but since CURRENT is running, it keeps printing error messages about microuptime went backwards which doesn't seem to hurt the system itself but is very annoying to work with as it jams the whole screen in a matter of seconds with error messages, thus making it impossible to really work with the system. Now in some mailinglist archive it was suggested to turn of the APM of the board (some Elitegroup Super Socket 7 board based on a SiS chipset, can dig out the specs if that helps) but that didn't help at all... Funny, it always does for me. Note that you have to build a kernel without APM support; just disabling it doesn't work. If that doesn't help, you're probably on your own. Oh and please reply to me privately as well as I'm not reading this list (too much traffic)! If you're running -CURRENT, you should be reading this list. If you don't have time, don't run -CURRENT. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum issue with USB CompactFlash reader.
On Friday, 28 December 2001 at 14:48:54 -0600, Jim Bryant wrote: I know this is probably a minor issue, as it is only an annoyance, and doesn't impact operation or performance, but still.. Ever since I concatenated some old drives to make a more reasonable capacity out of them, I have been noticing the following whenever vinum is loaded at startup [Note: The dmesg output doesn't show it, but before the check condition errors, vinum is loaded. Also this occurs when no CF card is present in the reader, seems to do well when booted with a card in place.]: Could vinum not be detecting that this is a removable media device? This has nothing to do with Vinum. The errors are at the device driver level, and they appear to relate only to the compact flash adaptor. Does it work when Vinum is not loaded? Was there in fact a CF card in the adaptor? Greg Waiting 15 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 5 lun 0 sa0: HP C1533A 9608 Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 8) da0 at ahc1 bus 0 target 0 lun 0 da0: COMPAQ ST15150W 6213 Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) da1 at ahc1 bus 0 target 15 lun 0 da1: COMPAQ ST15150W 6215 Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) Mounting root from ufs:/dev/ad0s1a cd1 at ahc0 bus 0 target 3 lun 0 cd1: TOSHIBA CD-ROM XM-6401TA 1009 Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 0 da3: eUSB Compact Flash \\0001 Removable Direct Access SCSI-2 device da3: 150KB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present cd2 at ahc0 bus 0 target 4 lun 0 cd2: NEC CD-ROM DRIVE:841 1.0 Removable CD-ROM SCSI-2 device cd2: 3.300MB/s transfers cd2: Attempt to query device size failed: NOT READY, Medium not present da2 at ahc0 bus 0 target 2 lun 0 da2: SEAGATE ST32550N 0022 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) cd0 at ahc0 bus 0 target 6 lun 0 cd0: NEC CD-ROM DRIVE:466 1.06 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present (da3:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da3:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da3:umass-sim0:0:0:0): SCSI Status: Check Condition (da3:umass-sim0:0:0:0): NOT READY asc:3a,0 (da3:umass-sim0:0:0:0): Medium not present (da3:umass-sim0:0:0:0): Unretryable error -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum issue with USB CompactFlash reader.
On Saturday, 29 December 2001 at 6:21:29 +0100, Bernd Walter wrote: On Sat, Dec 29, 2001 at 10:09:11AM +1030, Greg Lehey wrote: This has nothing to do with Vinum. The errors are at the device driver level, and they appear to relate only to the compact flash adaptor. Does it work when Vinum is not loaded? Was there in fact a CF card in the adaptor? vinums read_drive_label triggers this. It tries to read the label and produces the given errors if the drive is not ready - nothing wrong IMHO. This would assume that Vinum was started after the adaptor was inserted. I see the same messages for an MO drive if there is no media inserted. And I see these errors for a fixed drive with media errors. It is just unavoidable to have a single error for each drive and I don't know for shure why it happens several times - maybe vinum probes for multiple partitions. Yes, Vinum probes for up to 35 partitions. First it tries each partition in each slice. If that doesn't work, it tries the compatibility slice. In each case, it ignores partition c. I suppose it would be possible to recognize conditions like medium not present and stop after the first attempt. But I can't see how to handle this without at least one error message. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))
On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: striped: If you have 512byte stripes and have 2 disks. You access 64k which is put into 2 32k transactions onto the disk. Only if your software optimizes the transfers. There are reasons why it should not. Without optimization, you get 128 individual transfers. If the software does not we end with 128 transactions anyway, which is not very good becuase of the overhead for each of them. Correct. UFS does a more or less good job in doing this. Well, it requires a lot of moves. Vinum *could* do this, but for the reasons specified below, there's no need. raid5: For a write you have two read transactions and two writes. This is the way Vinum does it. There are other possibilities: 1. Always do full-stripe writes. Then you don't need to read the old contents. Which isn't that good with the big stripes we usually want. Correct. That's why most RAID controllers limit stripe size to something sub-optimal, because it simplifies the code to do full-stripe writes. 2. Cache the parity blocks. This is an optimization which I think would be very valuable, but which Vinum doesn't currently perform. I thought of connecting the parity to the wait lock. If there's a waiter for the same parity data it's not droped. This way we don't waste memory but still have an efect. That's a possibility, though it doesn't directly address parity block caching. The problem is that by the time you find another lock, you've already performed part of the parity calculation, and probably part of the I/O transfer. But it's an interesting consideration. If we had a fine grained locking which only locks the accessed sectors in the parity we would be able to have more than a single ascending write transaction onto a single drive. Hmm. This is something I hadn't thought about. Note that sequential writes to a RAID-5 volume don't go to sequential addresses on the spindles; they will work up to the end of the stripe on one spindle, then start on the next spindle at the start of the stripe. You can do that as long as the address ranges in the parity block don't overlap, but the larger the stripe, the greater the likelihood of this would be. This might also explain the following observed behaviour: 1. RAID-5 writes slow down when the stripe size gets 256 kB or so. I don't know if this happens on all disks, but I've seen it often enough. I would guess it when the stripe size is bigger than the preread cache the drives uses. This would mean we have a less chance to get parity data out of the drive cache. Yes, this was one of the possibilities we considered. 2. rawio write performance is better than ufs write performance. rawio does truly random transfers, where ufs is a mixture. The current problem is to increase linear write performance. I don't see a chance that rawio benefit of it, but ufs will. Well, rawio doesn't need to benefit. It's supposed to be a neutral observer, but in this case it's not doing too well. Do you feel like changing the locking code? It shouldn't be that much work, and I'd be interested to see how much performance difference it makes. I put it onto my todo list. Thanks. Note that there's another possible optimization here: delay the writes by a certain period of time and coalesce them if possible. I haven't finished thinking about the implications. That's exactly what the ufs clustering and softupdates does. If it doesn't fit modern drives anymore it should get tuned there. This doesn't have too much to do with modern drives; it's just as applicable to 70s drives. Whenever a write hits a driver there is a waiter for it. Either a softdep, a memory freeing or an application doing an sync transfer. I'm almost shure delaying writes will harm performance in upper layers. I'm not so sure. Full stripe writes, where needed, are *much* faster than partial strip writes. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote:
On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
performance without it - for reading OR writing. It doesn't matter
so much for RAID{1,10}, but it matters a whole lot for something like
RAID-5 where the difference between a spindle-synced read or write
and a non-spindle-synched read or write can be upwards of 35%.
If you have RAID5 with I/O sizes that result in full-stripe operations.
Well, 'more then one disk' operations anyway, for random-I/O. Caching
takes care of sequential I/O reasonably well but random-I/O goes down
the drain for writes if you aren't spindle synced, no matter what
the stripe size,
Can you explain this? I don't see it. In FreeBSD, just about all I/O
goes to buffer cache.
and will go down the drain for reads if you cross a stripe -
something that is quite common I think.
I think this is what Mike was referring to when talking about parity
calculation. In any case, going across a stripe boundary is not a
good idea, though of course it can't be avoided. That's one of the
arguments for large stripes.
In a former life I was involved with a HB striping product for SysVr2
that had a slightly modified filesystem that 'knew' when it was
working on a striped disk. And as it know, it avoided posting I/O s
that crossed stripes.
So what did it do with user requests which crossed stripes?
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 1:08:23 -0800, Terry Lambert wrote: Greg Lehey wrote: FS porting to FreeBSD is actually pretty trivial(*), though some transactioning changes to the FreeBSD VFS layer consumers (the system calls and NFS server code) would be necessary to make the journal roll-back function correctly, following a failure. (*) Trivial: meaning grunt work is required; not necessarily an indicator of the amount of work, only the intellectual effort required for the job Considering that the current UFS implementation didn't need to be ported, and people are still working on the details, I think that this is a highly misleading statement. The current UFS has a number of issues which make it non-trivial; it was, in effect, a port; here is the short list: snip Live code always has issues, particularly if you are trying to pound a round peg into a square hole (hence Kirk taking up the task of a redesign). Of course. But you're missing the point: ufs is *not* a port, it has been with BSD since the beginning. There is a similar list of items for JFS which would need to be addressed, with the additional issue of the fact that it was not designed for FreeBSD. I think that everyone saying Ut oh! SCARY! gives people the wrong idea, and scares off potential contributors in these areas. I'm not saying that. I'm saying that it's non-trivial, which I suppose is what you mean when you say where are the patches?. As I said, I'm quite happy to help people port JFS2 to FreeBSD. On Tuesday, 11 December 2001 at 2:26:45 -0800, Hiten Pandya wrote: [... Hiten want's to GPL'ify FreeBSD ...] hi, first of all, i would like to clear of some point which have been taken wrongly. o My Intentions were never to GPL'ify FreeBSD :-) Agreed, I don't think anybody thought that. o The reason i started this discussion was because i think JFS/JFS2 would be a nice addition to FreeBSD like the rest of the other filesystems. o The JFS does _not_ have to be root, and even if people were to download it because it is GPL'ed, the size of the filesystem is only around 1.0MB If we port JFS2, it will be relatively trivial to have it as the root file system too. o It is hard to Port AIX or OS/2 based code, but we have to agree that, BSD Users were meant to take that kind of challenges, have taken before It's probably easier to port AIX based code than OS/2 or Linux based code. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))
On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote:
On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
performance without it - for reading OR writing. It doesn't matter
so much for RAID{1,10}, but it matters a whole lot for something like
RAID-5 where the difference between a spindle-synced read or write
and a non-spindle-synched read or write can be upwards of 35%.
If you have RAID5 with I/O sizes that result in full-stripe operations.
Well, 'more then one disk' operations anyway, for random-I/O. Caching
takes care of sequential I/O reasonably well but random-I/O goes down
the drain for writes if you aren't spindle synced, no matter what
the stripe size,
Can you explain this? I don't see it. In FreeBSD, just about all I/O
goes to buffer cache.
After waiting for the drives and not for vinum parity blocks.
and will go down the drain for reads if you cross a stripe -
something that is quite common I think.
I think this is what Mike was referring to when talking about parity
calculation. In any case, going across a stripe boundary is not a
good idea, though of course it can't be avoided. That's one of the
arguments for large stripes.
striped:
If you have 512byte stripes and have 2 disks.
You access 64k which is put into 2 32k transactions onto the disk.
Only if your software optimizes the transfers. There are reasons why
it should not. Without optimization, you get 128 individual
transfers.
The wait time for the complete transaction is the worst of both,
which is more than the average of a single disk.
Agreed.
With spindle syncronisation the access time for both disks are
beleaved to be identic and you get the same as with a single disk.
Correct.
Linear speed could be about twice the speed of a single drive. But
this is more theoretic today than real. The average transaction
size per disk decreases with growing number of spindles and you get
more transaction overhead. Also the voice coil technology used in
drives since many years add a random amount of time to the access
time, which invalidates some of the spindle sync potential. Plus it
may break some benefits of precaching mechanisms in drives. I'm
almost shure there is no real performance gain with modern drives.
The real problem with this scenario is that you're missing a couple of
points:
1. Typically it's not the latency that matters. If you have to wait
a few ms longer, that's not important. What's interesting is the
case of a heavily loaded system, where the throughput is much more
important than the latency.
2. Throughput is the data transferred per unit time. There's active
transfer time, nowadays in the order of 500 µs, and positioning
time, in the order of 6 ms. Clearly the fewer positioning
operations, the better. This means that you should want to put
most transfers on a single spindle, not a single stripe. To do
this, you need big stripes.
raid5:
For a write you have two read transactions and two writes.
This is the way Vinum does it. There are other possibilities:
1. Always do full-stripe writes. Then you don't need to read the old
contents.
2. Cache the parity blocks. This is an optimization which I think
would be very valuable, but which Vinum doesn't currently perform.
There are easier things to raise performance.
Ever wondered why people claim vinums raid5 writes are slow?
The answer is astonishing simple:
Vinum does striped based locking, while the ufs tries to lay out data
mostly ascending sectors.
What happens here is that the first write has to wait for two reads
and two writes.
If we have an ascending write it has to wait for the first write to
finish, because the stripe is still locked.
The first is unlocked after both physical writes are on disk.
Now we start our two reads which are (thanks to drives precache)
most likely in the drives cache - than we write.
The problem here is that physical writes gets serialized and the drive
has to wait a complete rotation between each.
Not if the data is in the drive cache.
If we had a fine grained locking which only locks the accessed sectors
in the parity we would be able to have more than a single ascending
write transaction onto a single drive.
Hmm. This is something I hadn't thought about. Note that sequential
writes to a RAID-5 volume don't go to sequential addresses on the
spindles; they will work up to the end of the stripe on one spindle,
then start on the next spindle at the start of the stripe. You can do
that as long as the address ranges in the parity block don't overlap,
but the larger the stripe, the greater the likelihood of this would
be. This might also explain the following observed behaviour:
1. RAID-5 writes slow down when the stripe size gets 256 kB or so.
I don't know if this happens
Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Tuesday, 11 December 2001 at 23:41:51 +0100, Wilko Bulte wrote: On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: .. and will go down the drain for reads if you cross a stripe - something that is quite common I think. I think this is what Mike was referring to when talking about parity calculation. In any case, going across a stripe boundary is not a good idea, though of course it can't be avoided. That's one of the arguments for large stripes. In a former life I was involved with a HB striping product for SysVr2 that had a slightly modified filesystem that 'knew' when it was working on a striped disk. And as it know, it avoided posting I/O s that crossed stripes. So what did it do with user requests which crossed stripes? Memory is dim, but I think the fs code created a second i/o to the driver layer. So the fs never sent out an i/o that the driver layer had to break up. That's what Vinum does. In case of a pre-fetch while reading I think the f/s would just pre-fetch until the stripe border and not bother sending out a second i/o down. Yes, that's reasonable. In the end all of this benchmarked quite favorably. Note that this was 386/486 era, with the classic SysV filesystem. I don't think that UFS would behave that differently, just faster :-) Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 19:42:30 -0800, Terry Lambert wrote: Greg Lehey wrote: Of course. But you're missing the point: ufs is *not* a port, it has been with BSD since the beginning. There is a similar list of items for JFS which would need to be addressed, with the additional issue of the fact that it was not designed for FreeBSD. I maintain that the FreeBSD UFS *is* a port of the Heidemann implementation from the FICUS project, which had to be done because certain files were claimed to be contaminated with USL IP, and were removed as part of the USL/UCB settlement (6 key files from 5 subsystems, which they thought we couldn't rewrite from scratch in time to be a competitive threat). Which files? Did they require adapting to a different environment? I also maintain that the most difficult thing is getting the list of items, and, with the information from the UFS work in hand, the JFS specific items not on that list are trivial (there are exactly two items, in fact: log roll forward/backward, and transaction abort). I'd expect these to be the easiest parts, since they don't have too much to do with the rest of the system. One of the issues with Linux is that the interface to the rest of the system, and I don't expect these parts to have much interfacing to do. I think that everyone saying Ut oh! SCARY! gives people the wrong idea, and scares off potential contributors in these areas. I'm not saying that. I'm saying that it's non-trivial, which I suppose is what you mean when you say where are the patches?. As I said, I'm quite happy to help people port JFS2 to FreeBSD. I ported the entire GFS user space tools set, sans two, to FreeBSD in about 2 hours. I expect the user space tools for JFS2 to be pretty straightforward too. If we port JFS2, it will be relatively trivial to have it as the root file system too. Only, you will never be able to build a firewall, router, or other product that ships with it statically linked into the kernel, since that would violate the terms of the GPL (additional restrictions, and linked code not being GPL'ed). Fine, so we load the module. What's your point? What good is the damn thing, if the only people who can use it are ... Well, I suppose it'll still be good for them. Maybe. RMS has indicated a willingness to sue people distributing bipartite distributions, where the linking is delayed until installation to work around the letter of the GPL. Given his religious convictions, I can't see him *not*. Factor that into your decision. You want me personally to get him to agree that loading modules at boot time does not violate the GPL? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously Decidated yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
On Monday, 10 December 2001 at 0:17:14 -0800, Mike Smith wrote: Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the situation is that this table is required, and we're going to put it there. The reality of the situation is far from being clear. The only thing I can see is that you're trying to dictate things without adequate justification. You should reconsider that attitude. You can't substantiate your argument by closing your eyes, Greg. No, of course not. I also can't substantiate my arguments by sticking my fingers down my throat and shouting dangerously dedicated!. But then, I wasn't doing either. Read back this thread for the evidence I have given and which you apparently choose to ignore. There's a wealth of evidence against your stance, Possibly, you just haven't shown it. What we know so far is that there are some kludges in the boot loader which can confuse BIOSes; peter went into some detail earlier on IRC. Only, they apply both to systems with Microsoft partitions and those without. And there are reports that some Adaptec host adaptors (or, presumably, their BIOSes) can't handle our particular boot blocks. It's possible, as peter suggests, that this is a fixable bug, but every time I mention it, I get shouted down. And yes, like Jörg, I don't care enough. I'm not saying ditch the Microsoft partition table, I'm saying don't ditch disks without the Microsoft partition table. Note also that, although this is so dangerous, it has never bitten me on any system. and frankly, none that supports it other than myopic bigotry (I don't want to do this because Microsoft use this format). None that you care to remember. Are you going to stop using all of the other techniques that we share with them? No. See above. What is it about this particular topic brings out such irrational emotions in you and others? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
[Format recovered--see http://www.lemis.com/email/email-format.html] Long-short syndrome in first message. On Monday, 10 December 2001 at 14:01:53 -0800, Hiten Pandya wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ Well, JFS was developed by IBM for AIX. If you look at the header files, it is clearly derived from UFS. They later developed a completely new file system, JFS2, for OS/2, and later ported this version to Linux. It's also available for AIX, but the standard AIX file system is still the old JFS1. It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I don't think the zSeries (System/390) runs JFS. As I said above, the RS/6000 uses a different JFS file system. On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote: * Hiten Pandya [EMAIL PROTECTED] [011210 16:02] wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I'm glad you took the time to read the marketting literature. The problem is that porting it is going to be a bit more complicated than just dumping it into src/gnu. Feel free to take a shot at porting it though, let us know when you're done. I'm gainfully employed by IBM (although not for FreeBSD pursuits), and have had this on my TODO list for a while. Well, I'm gainfully employed by IBM, both for FreeBSD and JFS. I've thought (and spoken) about this from time to time. It would be a lot of work. The licence issue is a real sticky point, especially since the GPL and BSD licences are like oil and water. Because of the GPL licence, JFS support can never become part of the GENERIC kernel, and any related support tools will have to exist as separate binaries (newfs.jfs, fsck.jfs), as is currently done with the EXT2FS filesystem. As others have pointed out, this is a detail. The real question is: will JFS2 buy anything? The only real way to find out is to try it. On Monday, 10 December 2001 at 17:47:11 -0500, Anthony Schneider wrote: I'm no expert on journaled filesystems, but isn't the freebsd softupdates option similar? No, at least not from a technical standpoint. From a user standpoint, they both try to make things faster and more reliable, but they do it in very different ways. perhaps there could be an upgrade to offer options SOFTERUPDATES as an equal-but-different alternative to jfs? And what would that do? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Tuesday, 11 December 2001 at 10:56:17 +1030, Greg Lehey wrote: On Monday, 10 December 2001 at 17:39:35 -0500, Matthew Emmerton wrote: * Hiten Pandya [EMAIL PROTECTED] [011210 16:02] wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I'm glad you took the time to read the marketting literature. The problem is that porting it is going to be a bit more complicated than just dumping it into src/gnu. Feel free to take a shot at porting it though, let us know when you're done. I'm gainfully employed by IBM (although not for FreeBSD pursuits), and have had this on my TODO list for a while. Well, I'm gainfully employed by IBM, both for FreeBSD and JFS. I've thought (and spoken) about this from time to time. It would be a lot of work. BTW, if anybody wants to do it anyway, let me know. I'm in a position to help with information, though possibly not with coding. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
performance without it - for reading OR writing. It doesn't matter
so much for RAID{1,10}, but it matters a whole lot for something like
RAID-5 where the difference between a spindle-synced read or write
and a non-spindle-synched read or write can be upwards of 35%.
If you have RAID5 with I/O sizes that result in full-stripe operations.
Well, 'more then one disk' operations anyway, for random-I/O. Caching
takes care of sequential I/O reasonably well but random-I/O goes down
the drain for writes if you aren't spindle synced, no matter what
the stripe size,
Can you explain this? I don't see it. In FreeBSD, just about all I/O
goes to buffer cache.
and will go down the drain for reads if you cross a stripe -
something that is quite common I think.
I think this is what Mike was referring to when talking about parity
calculation. In any case, going across a stripe boundary is not a
good idea, though of course it can't be avoided. That's one of the
arguments for large stripes.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Dangerously Dedicated (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 16:59:28 -0800, Peter Wemm wrote: Joerg Wunsch wrote: Mike Smith [EMAIL PROTECTED] wrote: I'd love to never hear those invalid, unuseful, misleading opinions from you again. ETOOMANYATTRIBUTES? :-) As long as you keep the feature of DD mode intact, i won't argue. If people feel like creating disks that aren't portable to another controller, they should do. I don't like this idea. We can just as easily have bootable-DD mode with a real MBR and have freebsd start on sector #2 instead of overlapping boot1 and mbr. This would seem to be a reasonable alternative. This costs only one sector instead of 64 sectors (a whopping 32K, I'm sure that is going to break the bank on today's disks). Well, the real question is the space wasted at the end, which can be up to a megabyte. Still not going to kill you, but it's aesthetically displeasing. I'd rather that we be specific about this. If somebody wants ad2e or da2e then they should not be using *any* fdisk tables at all. Ie: block 0 should be empty. The problem is that if you put /boot/boot1 in there, then suddenly it looks like a fdisk disk and we have to have ugly magic to detect it and prevent the fake table from being used. I would prefer that the fdisk table come out of /boot/boot1 so that we dont have to have it by default, and we use fdisk to install the DD magic table if somebody wants to make it bootable. So where would you put the bootstrap? In sector 2? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
On Monday, 10 December 2001 at 22:45:22 -0800, Terry Lambert wrote: Hiten Pandya wrote: i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... Not unless you have plans. When I was an IBM employee, they would not change the license, and so it's impossible to ship a CDROM where it's the boot FS, or boxes on which it is the boot FS, and still have it be legal, because of the license conflicts. I fought this for about a year within IBM, before I gave up. Since then, it has become possible for the loader to load modules before booting the kernel. This means that, theoretically, it would be possible to have a JFS root file system. Given the strong opposition to the GPL in some factions of the FreeBSD project, I don't see this happening any time soon, especially since we still don't know if it will buy us anything. It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... No, it's not. The Linux JFS is derived from the OS/2 JFS code, not the good AIX JFS code. That's correct, but note that AIX is moving to this code base too, so it's not as if it's second-rate. From what I've seen of the structures, JFS2 is *much* better than JFS1. I haven't compared performance. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Dangerously dedicated yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 22:52:58 +1030, Daniel O'Connor wrote: On 09-Dec-2001 [EMAIL PROTECTED] wrote: (The other day a coworker of mine wanted to use DD for some IBM DTLA disks, because he'd heard that the disks performed better that way - something to do with scatter-gather not working right unless you used DD. I'm highly skeptical about this since I have my own measurements from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they show the disks performing extremely well. Anybody else want to comment on this?) Sounds like an Old Wives Tale to me. I don't understand the need some people have for using something that is labelled as DANGEROUS. I don't understand the need some people have for labelling something as DANGEROUS when it works nearly all the time. We don't have many disks which are shared between different platforms, but that will change. As you know, I have the ability to hot swap disks between an RS/6000 platform and an ia32 platform. The RS/6000 disks will never have a Microsoft partition table on them. They will have BSD partition tables on them. Why call this dangerous? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Dangerously Decidated yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 12:15:19 -0800, Mike Smith wrote: As Peter Wemm wrote: There shouldn't *be* bootblocks on non-boot disks. dd if=/dev/zero of=/dev/da$n count=1 Dont use disklabel -B -rw da$n auto. Use disklabel -rw da$n auto. All my disks have bootblocks and (spare) boot partitions. All the bootblocks are DD mode. I don't see any point in using obsolete fdisk tables. (There's IMHO only one purpose obsolete fdisk tables are good for, co-operation with other operating systems in the same machine. None of my machines uses anything else than FreeBSD.) Since I tire of seeing people hit this ignorant opinion in the list archives, I'll just offer the rational counterpoints. - The MBR partition table is not obsolete, it's a part of the PC architecture specification. And if it's part of the PC architecture specification, it can't be obsolete? I dont see any contradiction here. - You omit the fact that many peripheral device vendors' BIOS code looks for the MBR partition table, and will fail if it's not present or incorrect. What do you mean by peripheral device? I've never heard of disk drives having a BIOS. If you're talking about host adaptors, it's you who omit what Jörg says about it: No, on the contrary, he went into some detail on this point: On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: personal opinion Still, it's my opinion that these BIOSes are simply broken: interpretation of the fdisk table has always been in the realm of the boot block itself. The BIOS should decide whether a disk is bootable or not by looking at the 0x55aa signature at the end, nothing else. Think of the old OnTrack Disk Manager that extended the fdisk table to 16 slots -- nothing the BIOS could ever even handle. It was in the realm of the boot block to interpret it. /personal opinion I agree with Jörg on this. I'd love to never hear those invalid, unuseful, misleading opinions from you again. I'd love to never have to see this level of invective poured onto what was previously a calm discussion. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously Decidated yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 18:32:38 -0800, Mike Smith wrote: On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: personal opinion Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the situation is that this table is required, and we're going to put it there. The reality of the situation is far from being clear. The only thing I can see is that you're trying to dictate things without adequate justification. You should reconsider that attitude. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously dedicated yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 18:46:24 -0800, Terry Lambert wrote: Greg Lehey wrote: [ ... IBM DTLA drives ... ] No, that wasn't me. IBM DTLA drives are known to rotate fast enough near the spindle that the sustained write speed exceeds the ability of the controller electronics to keep up, and results in crap being written to disk. What about the cache? This is not often a problem with windows, the FS of shich fills sectors in towards the spindle, so you only hit the problem when you near the disk full state. This sounds very unlikely. Do a Google/Tom's Hardware search to reassure yourself that I am not smoking anything. I think I'd rather put the shoe on the other foot. This looks like high-grade crack. Who was smoking it? I don't understand the need some people have for using something that is labelled as DANGEROUS. I don't understand the need some people have for labelling something as DANGEROUS when it works nearly all the time. I *did* write this. It's because you have to reinstall, should you want to add a second OS at a later date (e.g. Linux, or Windows). So all dedicated installations are dangerous? I would have to do that whether I had a Microsoft partition table or not if I had already used the entire disk for FreeBSD. We don't have many disks which are shared between different platforms, but that will change. As you know, I have the ability to hot swap disks between an RS/6000 platform and an ia32 platform. The RS/6000 disks will never have a Microsoft partition table on them. They will have BSD partition tables on them. Why call this dangerous? Your use is orthogonal to the most common expected usage, which is disks shared between OSs on a single platform, rather than disks shared between a single OS on multiple platforms. Expected usage is to install once and then never change it. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Dangerously dedicated yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)
On Sunday, 9 December 2001 at 22:44:52 -0800, Peter Wemm wrote: 3) You get a system lockup when booting the *computer* if *any* DD disk is attached anywhere at all. This is what killed the Thinkpad T20*, A20*, 600X etc. After all the yelling we did at IBM, it turned out to be FreeBSD's fault. It also happens on Dell systems. It kills all IA64 boxes if a FreeBSD/i386 disk is attached anywhere. What are you talking about? The IBM lockup was due to the presence of *Microsoft partition* of type 0xn5, for any value of n. If these systems also lock up with a dedicated disk, it's due to some other bug. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP ATA support for newer SiS chipsets added
On Sunday, 2 December 2001 at 11:56:45 +0100, Søren Schmidt wrote: Well, I finally got to it, please report back to me if this works for you on newer SiS chipsets, especially: SiS 630, 633, 635, 730, 733 and 735 Also, support for the older: SiS 530, 540 and 620 Should be in place now. Anyhow If you have one of the above, please test with a new -current, and report to me how it goes, I dont have any of those chipsets, so I cant test it myself, donations of such boards are welcome :)... If it seems to work then please do the following on an idle system: for n in 1 2 3 4 5 do dd if=/dev/adX of=/dev/null bs=512K count=1 Don't you mean dd if=/dev/ad$n of=/dev/null bs=512K count=1 ? done Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Headsup! KSE Nay-sayers speak up!
On Monday, 27 August 2001 at 18:43:13 -0700, David O'Brien wrote: On Mon, Aug 27, 2001 at 03:13:19PM -0500, Jim Bryant wrote: Count my vote as a go-for-it. Blah. You're vote doesn't mean jack in this. Be that as it may, this kind of message does mean something, but it's nothing positive. We've had enough nastiness in this area already. If you don't like what Jim's saying, why not just ignore him? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: ffs_blkfree: freeing free block / + UDMA ICRC error with ad0
On Saturday, 18 August 2001 at 14:56:10 +0200, Alexander Leidinger wrote:
Hi,
-current as of Aug 16, ~2pm CEST:
I don't see a freeing free block in the stack trace. What is
missing from the trace below? Does the trace belong to the panic
message?
The trace shows two panics: the first looks like a page fault kernel
mode, though the backtrace address looks user mode. The second panic
is a bremfree: bp not locked in the subsequent sync. That one may
be related to some SMP stuff that has been done recently. It would be
interesting to look at the return address from the trap: the code
space ID is 0xc000, which I don't recognize. What process was
running?
---snip---
IdlePTD 4812800
initial pcb at 305f60
panicstr: bremfree: bp 0xc69e0748 not locked
panic messages:
---
panic: ffs_blkfree: freeing free block
panic: from debugger
[...]
#0 dumpsys () at ../../../kern/kern_shutdown.c:479
#1 0xc01baf11 in boot (howto=260) at ../../../kern/kern_shutdown.c:322
#2 0xc01bb32a in panic (fmt=0xc02ba51e bremfree: bp %p not locked)
at ../../../kern/kern_shutdown.c:601
#3 0xc01ed20e in bremfree (bp=0xc69e0748) at ../../../kern/vfs_bio.c:479
#4 0xc01eeb7a in getnewbuf (slpflag=0, slptimeo=0, size=8192, maxsize=8192)
at ../../../kern/vfs_bio.c:1632
#5 0xc01ef8d1 in getblk (vp=0xd063eec0, blkno=64, size=8192, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2244
#6 0xc01ed2ef in breadn (vp=0xd063eec0, blkno=64, size=8192, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0xc049ae10)
at ../../../kern/vfs_bio.c:537
#7 0xc01ed2b4 in bread (vp=0xd063eec0, blkno=64, size=8192, cred=0x0,
bpp=0xc049ae10) at ../../../kern/vfs_bio.c:519
#8 0xc0228650 in ffs_update (vp=0xd063eda0, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:101
#9 0xc023601f in ffs_fsync (ap=0xc049ae8c) at ../../../ufs/ffs/ffs_vnops.c:292
#10 0xc0233f9f in ffs_sync (mp=0xc1870400, waitfor=2, cred=0xc0e61d00,
p=0xc0337000) at vnode_if.h:441
#11 0xc01fc2e1 in sync (p=0xc0337000, uap=0x0)
at ../../../kern/vfs_syscalls.c:620
#12 0xc01baa37 in boot (howto=256) at ../../../kern/kern_shutdown.c:231
#13 0xc01bb32a in panic (fmt=0xc02cfc5e %s)
at ../../../kern/kern_shutdown.c:601
#14 0xc0276c90 in trap_fatal (frame=0xc049afa8, eva=794529)
at ../../../i386/i386/trap.c:935
#15 0xc02769c9 in trap_pfault (frame=0xc049afa8, usermode=0, eva=794529)
at ../../../i386/i386/trap.c:849
#16 0xc027615c in trap (frame={tf_fs = 0, tf_es = 0, tf_ds = 0, tf_edi = 3557,
tf_esi = 20371, tf_ebp = 24, tf_isp = -1068912684, tf_ebx = 8,
tf_edx = 145, tf_ecx = 3, tf_eax = 1544, tf_trapno = 12, tf_err = 4,
tf_eip = 8097, tf_cs = 49152, tf_eflags = 721410, tf_esp = 4030,
tf_ss = 0}) at ../../../i386/i386/trap.c:408
#17 0x1fa1 in ?? ()
Cannot access memory at address 0x18.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
[Format recovered--see http://www.lemis.com/email/email-format.html] Your MUA wraps incorrectly. On Friday, 17 August 2001 at 9:16:59 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Julian Elischer writes: Well you timed them out without askling the developer what he had in the wings and that was more than impolite, it was stupid, because most of the shortcomings of devfs and SLICE had been solved and all I was waiting for was the CAM switchover, so that I didn't have to do everything twice. Yeah, and together with Terrys VFS patches that would have made Microsoft bankrupt overnight. People, could we please stop this kind of nastiness? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Thursday, 16 August 2001 at 6:36:45 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg Lehey writes: On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. Uhm, have you forgotten how ls(1) works ? No. Try this then: ls -lad /dev/fd /dev/fd/[012] Hmm. Strange. Last time I looked, I thought I had /dev/fd0, /dev/fd1 and /dev/fd2. But I've booted a new kernel since that attempt. In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. History being rewritten eh ? I spent 3+ years trying to argue his DEVFS should be made default! They must have been before I met you, then. My very vivid recollection was that I met you at USENIX in New Orleans on 19 June 1998, and the very first thing you said was What does Vinum do about DEVFS? Don't use it, it's going away. We (you, Justin Gibbs, Jonathan Bresler, and I, maybe also one other person, but not Julian, whom you wouldn't let participate) then found an empty room and we discussed the matter. It was an interesting first impression. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devfs deficiencies (was: devfs and Vinum (was: any -current vinum problems?))
On Wednesday, 15 August 2001 at 19:17:47 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Ju lian Elischer writes: the lack of subdirectory support is a pitty. There is support for subdirectories: ls -la /dev/fd What am I supposed to see there? I get three character devices, all mounted on /dev directly. In any case, what devfs has is support for names with / in them. It violates POLA and causes serious problems in third party software. I think that you should implement subdirectories. it was a primary design goal in the previous devfs and its disappearance caught me by surprise. (the support I mean) SATIRE The ability to not panic left, right and centre was a primary design goal of this devfs and its absense in the previos devfs caught be by surprise. (The lack of support as well). /SATIRE In view of the fact that this thread is about deficiencies in your devfs, this is particularly uncalled for. One of the reasons that Julian's devfs never got debugged was that you had made it very clear from the start that it would be removed. And in general, can we stop the high incidence of mud-slinging we've seen on the lists lately? Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
devfs and Vinum (was: any -current vinum problems?)
On Tuesday, 14 August 2001 at 19:26:09 -0400, Michael Lucas wrote: Before I start generating crash dumps etc., are there any gotchas with Vinum -current? I'm using devfs on a SMP system, upgraded 3 days ago. I get a panic whenever I stripe something. Ah, now you say devfs. There was a bug in devfs; I haven't checked whether it's been fixed. Basically, devfs as supplied in CURRENT had a 16 character limit on device names, and it didn't understand subdirectories: it treated the / as a part of the device name. Vinum device names can be much longer than 16 characters, so I changed the limit to 96 characters on my test machine, but wasn't able to get it to run reliably. I've told phk about this on IRC some months ago, but I haven't seen a commit fixing the problem. I could have missed something, of course. To help localize this problem, could you please try this same thing on a kernel without devfs? The dump you sent me did not look like a Vinum bug, as I said in my reply. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs and Vinum (was: any -current vinum problems?)
On Wednesday, 15 August 2001 at 7:16:02 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andrew Kenneth Milton
writes:
+---[ Greg Lehey ]--
[snip]
whether it's been fixed. Basically, devfs as supplied in CURRENT had
a 16 character limit on device names, and it didn't understand
subdirectories: it treated the / as a part of the device name.
The subdir part bit me about a week ago, so I'd say it's still not fixed.
This is absolutely news to me.
Thinking about it, it is to me too. I noticed that devfs doesn't
create directory nodes when I was trying to find ways to delete
existing directory entries, but that's the only problem I've had with
it. I mentioned it here because it related to the name length limit:
the length of the name includes the complete path from the mount
point.
More details on this bug are most welcome.
I'm working on the 16char limit problem as well, but I want to avoid
allocating memory in incovenient circumstances if at all possible.
The problem is that I kept having problems with the devfs/vinum
combination even after increasing the size to 96 characters. As I
said to you on IRC quite some time ago now:
groggy phk: I've been getting a lot of panics out of zaphod.
groggy phk: I suspect a bogon or misunderstandingn with Vinum and devfs.
phk groggy: any clues/traces/pointers ?
phk wli: you're not a member of the club.
groggy phk: I'm just guessing that it's a name length problem.
groggy phk: Hmm. Could be due to incorrect header files somewhere.
groggy phk: I upped the name length to 96 chars.
groggy phk: Traceback:
groggy 1 0xc01b88c4 in panic (fmt=0xc034ce38 getnewvnode: free vnode isn't) at
../../kern/kern_shutdown.c:598
groggy #2 0xc01fb30e in getnewvnode (tag=VT_UFS, mp=0xc230d400, vops=0xc22c4600,
vpp=0xcfcdec10) at ../../kern/vfs_subr.c:552
groggy #3 0xc02c33aa in ffs_vget (mp=0xc230d400, ino=0x12099, vpp=0xcfcdec60) at
../../ufs/ffs/ffs_vfsops.c:1157
groggy #4 0xc02b409d in ffs_valloc (pvp=0xcfc9b920, mode=0x81a4, cred=0xc252db00,
vpp=0xcfcdec60)
groggy at ../../ufs/ffs/ffs_alloc.c:615
groggy #5 0xc02cc670 in ufs_makeinode (mode=0x81a4, dvp=0xcfc9b920, vpp=0xcfcdeea4,
cnp=0xcfcdeeb8)
groggy at ../../ufs/ufs/ufs_vnops.c:2215
groggy #6 0xc02c9c14 in ufs_create (ap=0xcfcdedbc) at ../../ufs/ufs/ufs_vnops.c:194
groggy #7 0xc02ccb39 in ufs_vnoperate (ap=0xcfcdedbc) at
../../ufs/ufs/ufs_vnops.c:2587
groggy #8 0xc02068a9 in vn_open (ndp=0xcfcdee90, flagp=0xcfcdee5c, cmode=0x1a4) at
vnode_if.h:90
groggy #9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
groggy #10 0xc0312445 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f,
tf_edi = 0xbfbff9b8, tf_esi = 0x8,
groggy tf_ebp = 0xbfbff820, tf_isp = 0xcfcdefd4, tf_ebx = 0x80b54a0, tf_edx =
0x80b5b80, tf_ecx = 0x10, tf_eax = 0x5,
groggy tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x8091fec, tf_cs = 0x1f,
tf_eflags = 0x293, tf_esp = 0xbfbff7f4,
groggy tf_ss = 0x2f}) at ../../i386/i386/trap.c:1176
groggy phk: I'm wondering whether to analyse, reboot and upgrade, or ignore for the
moment.
phk groggy doesn't really point to either of vinum or DEVFS if you ask me...
groggy (kgdb) f 9
groggy #9 0xc0201f9a in open (p=0xcfc25cc0, uap=0xcfcdef80) at
../../kern/vfs_syscalls.c:1077
groggy warning: Source file is more recent than executable.
groggy 1077error = vn_open(nd, flags, cmode);
groggy (kgdb) p *uap
groggy $1 = {
groggy path = 0x80c4030 lib/username.o,
groggy path_ = 0xcfcdef84 \001\006,
groggy flags = 0x601,
groggy flags_ = 0xcfcdef88 ¶\001,
groggy mode = 0x1b6,
groggy mode_ = 0xcfcdef8c ¸ù¿¿\006
groggy }
groggy phk: Not directly. I'm suspecting some kind of corruption.
groggy phk: But nobody else has mentioned it, and there must be some reason why it
keeps happening.
groggy phk: The trouble is, I use this box for two different purposes;
groggy phk: 1: Testing Vinum.
groggy phk: 1: Testing Samba.
* groggy points at http://build.samba.org/
groggy s/1/2/
groggy phk: This only started happening since I installed devfs, and I think it only
happens if Vinum is loaded.
phk groggy: well, as far as I know we still havn't conclusive evidence that
vinum+DEVFS does the right thing, do we ?
groggy phk: Exactly.
groggy phk: I was just waiting for you to say hey, that sounds familiar.
phk groggy I'm sorry I havn't gotten further on the long-names for devices, but life
has kind of kept me busy this week, starting with a leaky water pipe last sunday...
groggy phk: No worries. I'll keep looking, maybe.
Sorry I can't give you a date on this, but I'm sure you remember.
Maybe the leaky water pipe will put a date on it :-)
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Vinum + DEVFS ?
On Sunday, 1 July 2001 at 14:22:36 -0500, Patrick Hartling wrote: Alfred Perlstein [EMAIL PROTECTED] wrote: * Patrick Hartling [EMAIL PROTECTED] [010630 14:04] wrote: I just got two new hard drives, and I am preparing to set them up to do RAID-1 with Vinum. A few weeks ago (around the time that use of DEVFS became the default in -current), I saw a message saying that Vinum was not yet ready for use with DEVFS. Is that still the case? I fixed that. :) Let me and Grog know if you have problems. Everything seems to be okay with the vinum device node creation, but I am having problems with my vinum configuration. I basically copied this from an example in the online documentation (which is also in the vinum(8) manpage); drive da3e device /dev/da3s1e drive da4e device /dev/da4s1e volume mirror plex org concat sd length 12g drive da3e plex org concat sd length 12g drive da4e When I do 'vinum create', I get the following: 1: drive da3e device /dev/da3s1e ** 1 : Invalid argument 2: drive da4e device /dev/da4s1e ** 2 : Invalid argument 3: volume mirror 4: plex org concat 5: sd length 12g drive da3e 6: plex org concat 7: sd length 12g drive da4e Which one is the invalid argument, The name of the partition. and why is it invalid? I can't say for sure, since you don't supply the info asked for in the man page and the web page. But I'd be prepared to bet that your da3s1e and da4s1e partitions are not of type Vinum. Look for 'disklabel' in the man page. BTW, it's bad practice to name your drives after the partition on which they are currently resident. You can take those two drives and swap their SCSI IDs. Vinum will still find them and operate correctly, but your da3s1e partition will be drive da4e, and da4s1e will be drive da3e, which is completely confusing. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic from May
On Saturday, 16 June 2001 at 15:22:39 -0600, Chad David wrote: I get the following panic on a GENERIC kernel from around May 23: (copied by hand) /usr/src/sys/kern/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c:428 panic: sleeping process owns a mutext Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db trace Debugger() panic() propagate_priority() _mtx_lock_sleep() obreak() syscall() syscall_with_err_pushd() this looks a lot like... my system cvsupped around May 25 reliably causes a panic when I $ cp /cdrom/distfiles/somefiles /tmp I've written down the message from the debugger: /usr/src/sys/kern_synch.c:385: sleeping with vm locked from /usr/src/sys/vm/vm_pager.c: 428 panic: sleeping process owns a mutex Debugger(panic) trace Debugger(...) panic() propagate_priority() _mtx_lock_sleep() ffs_write() vn_write() writev() syscall() syscall_with_err_pushed() from the current archives. What can I do get this thing through a make world? Sorry, I don't understand that. Would a recent kernel over the existing userland have any hope between then and now? Maybe. If you're using -CURRENT, you should expect this kind of problem. And we expect that you try to solve it yourself. There are very few people who are interested in problems you might have with a month old -CURRENT. The first thing you should do is update to real -CURRENT sources. Try again. If it still happens, climb into the dump and have a good look round. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The FreeBSD core team needs your help
On Sunday, 3 June 2001 at 16:54:47 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Greg Lehey writes: Could you stick some numbers in here please. How much email does core@ get ? Normally much less than 10 messages a day. In Q1 2001, we got 650ish mail messages. I'd expect Q2 to be twice that, but I'd say fully 1/2 of those can be summaried as Core, show us more of what you do. Hmm, I'd consider that an overstatement. I'd guess 80% were either applications for commit bits, developer A pointing fingers at developer B, or followups to either (including well, it's been 3 weeks; what gives?). Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The FreeBSD core team needs your help
On Friday, 1 June 2001 at 17:54:13 +0200, Steve O'Hara-Smith wrote: On Fri, 1 Jun 2001 13:41:57 +0930 Greg Lehey [EMAIL PROTECTED] wrote: GL When a request or question is sent to core@ you reply with an Could you stick some numbers in here please. How much email does core@ get ? Normally much less than 10 messages a day. What percentage of it (roughly) is handled immediately ? Currently, almost none. The thing is that we currently all need to respond, and that takes time; thus the one week rule. Since jkh's suggestion a couple of days ago, we're taking this rule less seriously and getting things done more quickly. GL It is also your responsibility to prepare a summary of core@'s GL businnes once per month and after cores approval of the text, to Based on the aforementioned email or is there more 'input' ? If so roughly how much ? With very few exceptions it's all email. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The FreeBSD core team needs your help
Those of you who have been following the mailing lists will have noticed (or participated in) a thread bemoaning the continued lack of feedback from the core team. That thread is still very active, but one suggestion (made by phk) was to send out a message asking for help getting things done. It's easy to claim that this would work, but first we need to know if anybody would be interested. Here's phk's text: HELP WANTED The FreeBSD core team is looking for an assistant to help with tracking and recording the issues being worked by core. Responsibilities: When a request or question is sent to core@ you reply with an acknowledgement that it has been received, and nag the core team until it has been decided on and replied to. It is also your responsibility to prepare a summary of core@'s businnes once per month and after cores approval of the text, to send this to developers@. This summary should be detailed enough to show the committers which core members participate in the core business and which don't. You will obviously gain insight into the work of and communications of the core team, but apart from the above mentioned summary, this information is of course strictly confidential. Working hours: All. Benefits: The FreeBSD project has a comprehensive benefits plan which you will take full advantage off. The benefits include: Lots and lots of email. birth control (you wont have time to spend with your SO), sunburn protection (you wont have time to spend away from the computer). Despite the appearances, this is not an official request for applicants. We just want to know who would be interested in doing such a thankless task, and whether it's worth core's time to discuss the exact terms of reference (does the person get elected, for example, or appointed?). If you're interested, it's your choice whether you copy -developers, though personally I'd prefer if you just replied to core@. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sbin/vinum broken
On Thursday, 24 May 2001 at 18:28:19 +0300, Ruslan Ermilov wrote:
On Thu, May 24, 2001 at 09:24:56AM +0930, Greg Lehey wrote:
On Wednesday, 23 May 2001 at 16:56:39 +0300, Ruslan Ermilov wrote:
Hi!
src/sbin/vinum is broken at the moment.
It doesn't build without -DVINUMDEBUG.
*sigh*. I could have sworn I tested this, but it seems I did it in a
parallel universe. It's fixed now, I think. me-pointyhat++;
A quick workaround:
Index: Makefile
===
RCS file: /home/ncvs/src/sbin/vinum/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- Makefile2001/05/23 05:24:53 1.20
+++ Makefile2001/05/23 13:55:24
@@ -5,6 +5,7 @@
MAN= vinum.8
CFLAGS+= -I${.CURDIR}/../../sys -Wall
+CFLAGS+= -DVINUMDEBUG
This didn't work for me:
=== root@zaphod (/dev/ttyp1) /src/FreeBSD/5.0-CURRENT/src/sbin/vinum 4 - make
Warning: Using /wantadilla/home/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum as
object directory instead of canonical /usr/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum
cc -O -pipe -c /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c
In file included from /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c:57:
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:75: dev/vinum/vinumvar.h: No such
file or directory
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:76: dev/vinum/vinumio.h: No such
file or directory
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:77: dev/vinum/vinumkw.h: No such
file or directory
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:78: dev/vinum/vinumutil.h: No such
file or directory
Am I missing something?
I bet you specified CFLAGS on a command line, and that clobbered
CFLAGS+=-I${.CURDIR}/../../sys from Makefile.
No, that wasn't it.
Otherwise, I fail to see why there's no -I... in the above output.
So do I. It works now. But I don't understand what has changed.
Missing /usr/include/dev/vinum headers, yeah? :-)
No, of course not. With the -I it worked fine.
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sbin/vinum broken
On Wednesday, 23 May 2001 at 16:56:39 +0300, Ruslan Ermilov wrote:
Hi!
src/sbin/vinum is broken at the moment.
It doesn't build without -DVINUMDEBUG.
*sigh*. I could have sworn I tested this, but it seems I did it in a
parallel universe. It's fixed now, I think. me-pointyhat++;
A quick workaround:
Index: Makefile
===
RCS file: /home/ncvs/src/sbin/vinum/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- Makefile 2001/05/23 05:24:53 1.20
+++ Makefile 2001/05/23 13:55:24
@@ -5,6 +5,7 @@
MAN= vinum.8
CFLAGS+= -I${.CURDIR}/../../sys -Wall
+CFLAGS+= -DVINUMDEBUG
This didn't work for me:
=== root@zaphod (/dev/ttyp1) /src/FreeBSD/5.0-CURRENT/src/sbin/vinum 4 - make
Warning: Using /wantadilla/home/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum as object
directory instead of canonical /usr/obj/src/FreeBSD/5.0-CURRENT/src/sbin/vinum
cc -O -pipe -c /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c
In file included from /src/FreeBSD/5.0-CURRENT/src/sbin/vinum/v.c:57:
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:75: dev/vinum/vinumvar.h: No such file
or directory
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:76: dev/vinum/vinumio.h: No such file
or directory
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:77: dev/vinum/vinumkw.h: No such file
or directory
/src/FreeBSD/5.0-CURRENT/src/sbin/vinum/vext.h:78: dev/vinum/vinumutil.h: No such file
or directory
Am I missing something?
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Breakage in today's -CURRENT
I've just built a couple of worlds from -CURRENT cvsupped at 2030 UTC on the 18th, and at 0600 UTC on the 19th. In each case, I have massive problems, apparently with the synchronization. Here's some log file output: Apr 19 18:11:34 zaphod /boot/kernel/kernel: fforrwwarardd__hsatradtcclloocckk:: ch ecchkesctkasttea te 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: ffrwaordr_whaarrdd_cstocakt:c lock: checkstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: heckstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: forward_statclock: checkstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: forward_statclock: checkstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: fforwoarrwd_rds_hatacrldckckl:o cckheckstate : c0h Apr 19 18:11:34 zaphod /boot/kernel/kernel: eckstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: fforwarodr_whaarrdd_cstoactk:lo ccheckstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: k: checkstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: forfwarod_rhaarrdcd_sltoactkc:l occk: checkstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: heckstate 0 Apr 19 18:11:34 zaphod /boot/kernel/kernel: forward_statclock: checkstate 0 These blocks repeat exactly every 30 seconds. Also, the display is dead: the keyboard responds to NumLock and ScrollLock, but the last line on the bottom of the display consists of random data in bright. I can't enter ddb, or if I do, I can't tell that I've made it. I can rlogin with no problems. zaphod is an Abit BP6 with 2 Celerons. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel preemption, yes or no? (was: Filesystem gets a huge performance boost)
On Tuesday, 17 April 2001 at 1:19:57 -0700, Alfred Perlstein wrote: * Matt Dillon [EMAIL PROTECTED] [010415 23:16] wrote: For example, all this work on a preemptive kernel is just insane. Our entire kernel is built on the concept of not being preemptable except by interrupts. We virtually guarentee years of instability and bugs leaking out of the woodwork by trying to make it preemptable, and the performance gain we get for that pain is going to be zilch. Nada. Nothing. Pre-emption is mearly a side effect of a mutex'd kernel. The actual gains are in terms of parallel execution internally. Meaning if we happen to copyin() a 4 meg buffer we can allow more than one process to be completing some sort of work inside the kernel other than spinning on the giant lock. *sigh* Couldn't you have changed the subject line when discussing something of this importance? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Monday, 26 March 2001 at 18:19:06 +1000, Andrew Reilly wrote: On Mon, Mar 26, 2001 at 05:24:14PM +0930, Greg Lehey wrote: On Sunday, 25 March 2001 at 23:48:10 -0800, Doug Barton wrote: Greg Lehey wrote: On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: The Portmapper binary has been renamed from `portmap' to `rpcbind'. Why? So we can be more like sysV This is good? If it's the best path to NFS over IPv6, which seems to be the issue, then sure it's good. Play the ball, not the man. I don't have an objection to the change, I was just asking. And "because System V does it this way" has never been a good answer for us. And no, I'm not picking on Doug, just making a point. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** portmap daemon renamed to rpcbind
On Wednesday, 21 March 2001 at 10:44:38 -0800, David O'Brien wrote: The Portmapper binary has been renamed from `portmap' to `rpcbind'. Why? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 22:26:11 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 21:20] wrote: On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Since both you and Poul refused to fix the code I choose how I thought it should be. Can you explain why: Yes, it looks more uniform, but the objects aren't uniform. It just doesn't make sense to me to mix these device nodes in with the control/Control/controld nodes. Understood. But I don't like the very long device names. Also, why not have a /dev/vinum/ctl/ directory for those nodes? I can go along with that. They're almost completely invisible anyway. We could even call it /dev/vinum/.ctl. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BP6 motherboard and hangs ...
On Saturday, 17 March 2001 at 16:43:14 -0400, The Hermit Hacker wrote: Anyone have any experience with the Abit BP6 motherboards? I've been reporting and talking about problems with -CURRENT the past little while, where when I start X, it pretty much dies soon after ... well, this weekend, I needed to make my system Dual-BOOT into W2K Professional Server for some work I'm doing (installing FreeBSD in vmware over w2k to run some server software) and W2K hangs solid also ... I'm starting to wonder if its a motherboard problem and has nothing to do with OS ... Anyone with experience here? I've had one for nearly a year. I used it for my contribution to the SMPng project, and I've had no problems that I would ascribe to the board. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: * Niels Chr. Bank-Pedersen [EMAIL PROTECTED] [010311 02:29] wrote: I'll sneak in my experience with DEVFS+vinum here as well: vinum: loaded vinum: reading configuration from /dev/da3s1f vinum: updating configuration from /dev/da1s1e vinum: updating configuration from /dev/da2s1e vinum: updating configuration from /dev/da0s1e swapon: adding /dev/da1s1b as swap device swapon: adding /dev/da2s1b as swap device Automatic boot in progress... /dev/da0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da0s1a: clean, 406977 free (1049 frags, 50741 blocks, 0.2% fragmentation) Can't stat /dev/vinum/raid01: No such file or directory Can't stat /dev/vinum/raid01: No such file or directory /dev/vinum/raid01: CAN'T CHECK FILE SYSTEM. /dev/vinum/raid01: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. This was with a -current from around March 1. (don't think anything has changed since). Booting a non-DEVFS kernel passes the fs-check and works as expected. Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Sunday, 11 March 2001 at 20:39:03 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [010311 15:21] wrote: On Sunday, 11 March 2001 at 3:27:02 -0800, Alfred Perlstein wrote: Vinum+DEVFS doesn't make the million symlinks that non-devfs vinum does. The only symlinks that the non-devfs version makes are to the drives. Everything else is device nodes. But yes, it doesn't make as many device nodes, and that is a Good Thing. Try using /dev/vinum/vol/raid01 instead of /dev/vinum/raid01 (notice you need the '/vol/' path component) I missed that. This is not correct. The directory /dev/vinum/vol should go away. Er, too late. :) On a devfs system here's what you'll see: ls -lR /dev/vinum/ total 0 crw--- 1 root wheel 91, 0x4001 Feb 22 21:26 Control crw--- 1 root wheel 91, 0x4002 Feb 22 21:26 control crw--- 1 root wheel 91, 0x4000 Feb 22 21:26 controld drwxr-xr-x 2 root wheel 0 Mar 11 03:24 plex drwxr-xr-x 2 root wheel 0 Mar 11 03:24 sd drwxr-xr-x 2 root wheel 0 Mar 11 03:24 vol /dev/vinum/plex: total 0 crw--- 1 root wheel 91, 1 Feb 22 21:26 vinum0.p0 /dev/vinum/sd: total 0 crw--- 1 root wheel 91, 2 Feb 22 21:26 vinum0.p0.s0 crw--- 1 root wheel 91, 0x1002 Feb 22 21:26 vinum0.p0.s1 /dev/vinum/vol: total 0 crw--- 1 root wheel 91, 0 Feb 22 21:26 vinum0 I'd like to keep it this way, it just makes sense. No, that's a gratuitous change. All the docco talks about keeping the volumes in the main directory. That's why people are having trouble. Yes, it looks more uniform, but the objects aren't uniform. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how's vinum these days with DEVFS?
On Saturday, 10 March 2001 at 17:12:42 -0800, Matt Jacob wrote:
(top of tree within the last day or so):
Things seem *almost* okay, but:
nellie.feral.com root vinum
vinum - stripe -v /dev/da3a /dev/da4a /dev/da5a /dev/da6a /dev/da7a /dev/da8a
/dev/da9a /dev/da10a /dev/da11a /dev/da12a
drive vinumdrive0 device /dev/da3a
snip
Can't get config for plex 0: Invalid argument
and at the console:
WARNING: Driver mistake: repeat make_dev("vinum/control")
Hmm.
Mar 10 17:09:57 nellie /boot/kernel/kernel: vinumioctl: invalid ioctl from process
682 (vinum): c1384644
This looks like a mismatch between the plex size in the userland and
kernel code. Did you rebuild vinum(8)?
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Watch your devfs permissions in driver make_dev calls
On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote: Robert Watson wrote: crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci This one may appear harmless, but it is not. It is trivially easy to create an alignment fault (fatal on an alpha) with the userland pciconf tool. We must not allow this to be used by users until the kernel part is fixed. Eg: try this on an alpha: pciconf -r -l pci0:x:x 0x3 - ie: read a longword at byte offset 3 in configuration space.. kaboom! This looks like a separate issue. Presumably you can do this as root as well. pciconf should check the parameters. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Monday, 29 January 2001 at 16:10:24 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Steve Ames writes: On Sun, Jan 28, 2001 at 10:19:34PM -0800, John Baldwin wrote: On 29-Jan-01 John Indra wrote: 2. If something change to the source tree's MAKEDEV, what should I do? Nothing. With DEVFS, each driver in the kernel creates its own entries automatically, so MAKEDEV isn't used. Hrm... what about some custom entries or symlinks I may have? (/dev/cdrom for instance) You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS newbie...
On Tuesday, 30 January 2001 at 8:37:56 +0600, Boris Popov wrote: On Tue, 30 Jan 2001, Greg Lehey wrote: You can create symlinks in /dev, you cannot mknod there. What is the reason for this? How does a program or script know whether the system is running DEVFS or not? I don't see any good reason why this can't be supported. We may talk about 'broken' devices, etc., but while there any - mknod needs to be supported to make transition more smooth. I'm assuming that there's a good technical reason for the lack of mknod. It also seems that mkdir doesn't work in devfs. Let's give phk time to wake up and tell us. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Tuesday, 16 January 2001 at 9:28:43 -0500, Will Andrews wrote: On Tue, Jan 16, 2001 at 09:16:14AM -0500, Kenneth Wayne Culver wrote: Wont this make installing using sysinstall a bit hard? I know the generic kernel includes all the CPU lines, so that all cpu's are recognized... so are you going to just take this line out of the generic kernel, and have a special kern.flp disk with a generic kernel that only has the i386 support in it? I don't think it's worth the effort. By the time 5.0-RELEASE goes out, the 386 will have been around for over 10 years (actually I think it has already reached that point and gone beyond). There are not likely to be many more installs of FreeBSD on 386's, let alone 5.x installs. People who *really* want to install 5.x on a 386 can generate their own kernel and such. Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: I386_CPU
On Wednesday, 17 January 2001 at 19:16:18 -0500, Will Andrews wrote: On Wed, Jan 17, 2001 at 04:21:15PM +1100, Greg Lehey wrote: Don't forget that the i386 is still a popular CPU for embedded work. Of course, embedded people will have less of an issue with sysinstall. Of course. But of these people, which really need 5.x's features over 4.x? I thought about that, too. I came to the conclusion "probably not", but 4.x won't be maintained for ever. Plus they can still compile I386_CPU by itself, which I'm sure they already do to keep the kernel size as small as possible. Sure. As I said, the installation would be much more specific anyway. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fatal trap while printing under SMP
On Tuesday, 2 January 2001 at 20:49:04 -0800, Manfred Antar wrote: When trying to print using a current SMP kernel, I get the following: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0c00 fault virtual address = 0xe1810412 fault code = supervisor write, page not present instruction pointer = 0x8:0xcb0a7977 stack pointer = 0x10:0xcb08cf84 frame pointer = 0x10:0xcb08cf9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30652 (irq7: lpt0) trap number = 12 panic: page fault cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 We really need more information than this. Can you get a dump, or at least a stack trace? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Supported wireless PCMCIA cards (was: Lucent Orinoco Gold PCCard?)
On Sunday, 10 December 2000 at 15:46:27 -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "[EMAIL PROTECTED]" writes: : Is there a list of wireless pc cards that work (and how well they work) : with FreeBSD?? There's /etc/defaults/pccard.conf, which says breifly: ... WebGEAR Aviator 2.4 (ray driver, not 802.11b) Specifically, it's 802.11 FHSS. I've been having a *lot* of trouble with this one. It maps a total of 52 kB into I/O space (48 kB + 4 kB, each contiguous), and I can't find that much memory. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hangs during 'make world -j4' on recent current
On Saturday, 9 December 2000 at 8:07:34 +0200, John Hay wrote: For over a week now, I have been unable to complete a 'make world' on my -CURRENT box if I specify -j4. The system hangs and is completely unresponsive. This is a dual Celeron and an Abit BP6 motherboard. As far as I can tell, nobody knows what's causing this, nor even how to attack the problem. I'd like to solicit feedback about the extent of the problem, the possible causes, and how to debug it. I have been building releases with WORLD_FLAGS=-j4 successfully on my SMP box with a Dec 1 kernel for the past week. Yesterday I upgraded the kernel and with the new kernel did a make world -j4 which completed with no problems. And afterwards a make release with WORLD_FLAGS=-j4 also finished with no problems. So -current isn't totally broken. It might be timing related. My machine is an old dual 266MHz PII. How many processors does your machine have? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hangs during 'make world -j4' on recent current
For over a week now, I have been unable to complete a 'make world' on my -CURRENT box if I specify -j4. The system hangs and is completely unresponsive. This is a dual Celeron and an Abit BP6 motherboard. As far as I can tell, nobody knows what's causing this, nor even how to attack the problem. I'd like to solicit feedback about the extent of the problem, the possible causes, and how to debug it. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current kernel hangs machine solid ...
On Wednesday, 6 December 2000 at 17:37:14 -0600, Michael Harnois wrote: Just checking in ... I haven't had one of these random hangs in the last week or so. Anyone else? Yup. My freshly installed machine has hung up again. Completely dead, apparently during a make world. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic m_copydata, negative off out of tcp_output
I've been having a few panics lately with a PRE_SMPNG snap: kgdb) bt #0 dumpsys () at ../../kern/kern_shutdown.c:461 #1 0xc01cf043 in boot (howto=256) at ../../kern/kern_shutdown.c:302 #2 0xc01cf3e5 in panic (fmt=0xc037db85 "m_copydata, negative off %d") at ../../kern/kern_shutdown.c:550 #3 0xc01edd02 in m_copydata (m=0x0, off=-1, len=1, cp=0xc0cd7970 "xmission\003com") at ../../kern/uipc_mbuf.c:766 #4 0xc02356a0 in tcp_output (tp=0xcb54d720) at ../../netinet/tcp_output.c:590 #5 0xc02343f3 in tcp_input (m=0xc0cd7900, off0=20, proto=6) at ../../netinet/tcp_input.c:2249 #6 0xc022e5d2 in ip_input (m=0xc0cd7900) at ../../netinet/ip_input.c:750 #7 0xc022e62f in ipintr () at ../../netinet/ip_input.c:778 Does anybody recognize this? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: very high CPU time demand from process #10 ('idle')
On Sunday, 8 October 2000 at 7:51:20 +, attila! wrote: -- ps -ax -- 0 ?? DLs0:00.40 (swapper) 1 ?? ILs0:00.07 /sbin/init -- 2 ?? DL 0:04.23 (pagedaemon) 3 ?? DL 0:00.65 (vmdaemon) 4 ?? DL 0:00.70 (bufdaemon) 5 ?? DL 0:44.85 (syncer) 10 ?? RL 4986:29.70 (idle) 11 ?? WL 5:43.86 (softinterrupt) 12 ?? DL24:58.44 (random) 13 ?? WL 0:05.88 (irq10: ahc0) 14 ?? WL 0:00.00 (irq11: dc0) 15 ?? WL 0:14.91 (irq1: atkbd0) 16 ?? WL 0:46.60 (irq12: psm0) 17 ?? WL 0:00.00 (irq6: fdc0) 18 ?? WL 0:00.08 (irq7: ppc0) 19 ?? WL 3:19.82 (irq0: clk) 20 ?? RL 5:43.47 (irq8: rtc) What is process 10? It's the idle process. Is this literally a representation of the CPU idle time accumulation for the 85 hours since boot? Yes. Despite the enormous time burn on 'idle' it does not show on 'top'. Yes, that didn't seem to make sense. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: interesting problem
[Format recovered--see http://www.lemis.com/email/email-format.html] On Thursday, 28 September 2000 at 19:54:01 -0500, Tony Johnson wrote: On Thursday, September 28, 2000 5:33 AM, Thomas David Rivers wrote: Alfred Perlstein [EMAIL PROTECTED] wrote: * Tony Johnson [EMAIL PROTECTED] [000927 18:26] wrote: OK Well Here is the issue. If I put in the 2 boot floppies I get a page fault 12 after I press Q for "quit" on the visual kernel config. If I can save a crash dump before any FS's are mounted or even before I tell FBSD where to put the crash dump, I'd really like to know this... I'd like to read a handbook page on thisb since some people think I just haven't read it. At this point in an install, if you could tell me (and the rest of the FreeBSD users) where I could get the boot floppies to save a crash dump (because I haven't even gotten this far) then I would appreciate this amd be more then happy to substantiate this by sending you a crash dump. Do you realize how much developer time you're wasting by thrashing around cluelessly on the list demanding help? Here's a clue: Forget about your damn irq problem, boot with the disks installed, then read section of the handbook about crashdumps, compile a debug kernel and figure out what the problem is. Fix it and send us a patch. Or you could simply run -stable. Alfred, Just playing `devils advocate' here. But, in some initial install situations, exactly how is the user, even the most knowledgeable one, supposed to do much of anything if the install itself doesn't work? Not too much chance of building a kernel, getting a crashdump, etc... Although it may be something we want to put off for awhile, being able to gather debugging information during a failed install would be rather nice. I'm not sure how this could happen; perhaps a crashdump to an MSDOS file system (if available)? Or, straight to a partition with some recovery program that reads the dump? Or, over a serial line? [Just tossing out ideas.] Maybe ficl can get involved and manage this? I would keep this as one of those "maybe nice to have in the ideal future" ideas - but it's something to ponder... Certainly it would be a nice idea. We have plenty of cases where a -CURRENT system might have difficulties booting. In general we solve the problem in one of two ways: 1. Build a kernel with debugger support and analyse what the problem is. 2. Work around it long enough to get the system to a point where you can take dumps. This is the approach Alfred is suggesting. I don't think this has much to to with the current situation: based on the evidence we have seen, it seems that Tony has tried to boot a release snapshot of -CURRENT. It failed. Coincidentally, he has also disabled IDE support in the belief that this might buy him something. Now he comes and claims that there is a connection between these two events, but he doesn't give us any evidence. I really did not want to reply to this but since some people believe that I am just see-ing things, then I will set this straight. I don't think anybody claims you're seeing things. I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs FreeBSD5.0-Current since it came out. Maybe you should change the teflon cables. I have been running FreeBSD for years... I ran 3.0 and 4.0 when they were /current and I never had these problems. I cannot even get the thing (5.0-Current in recent days) to boot from boot floppies that you put on ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386. If you are producing an OS that does not boot on /current then say this publicly and not curse me out for your production of a non functional product. For public record: we are not producing an OS that does not boot. We're prepared to believe that you're unable to boot it, but you're not doing anything to get people to help you. I'm sure I could produce a set of non-functioning asm code that just crashes peoples machines, if your idea of development is this. I don't believe that I need to write an email list for this. No, of course not. In fact, saying things like that really discredits you. I have a better idea, how about an option on the install to save buffer cache to a floppy disk , or atleast the portion that caused the automatic reboot??? Gdb anyone? A typical machine nowadays has 128 MB of memory. That would just about fit on an LS-120, but you'd need about 90 floppies to dump to. That doesn't make sense. My personal feeling is that you should take Alfred's advice and try to boot without disabling IDE. It may or may not work. If it doesn't, you'll know you're wrong about connecting the two events. If it does, it'll give you a system which is usable for debugging the problem. If you need more information from me about my product then please ask me and I will say so. I
Repeated panic out of chgsbsize
In the past couple of days, I've had a couple of panics out of chgsbsize:
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01cbac9 in panic (fmt=0xc0380e6f "page fault") at ../../kern/kern_shutdown.c:553
#2 0xc0316466 in trap_fatal (frame=0xc038a5c4, eva=48) at ../../i386/i386/trap.c:951
#3 0xc0316119 in trap_pfault (frame=0xc038a5c4, usermode=0, eva=48) at
../../i386/i386/trap.c:844
#4 0xc0315c8f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi
= -1033507840,
tf_ebp = -1070029304, tf_isp = -1070029328, tf_ebx = -1069888396, tf_edx =
6864928, tf_ecx = -808467136,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070853968, tf_cs = 8,
tf_eflags = 66050,
tf_esp = -1033507840, tf_ss = -1070029272}) at ../../i386/i386/trap.c:443
#5 0xc02c10b0 in acquire_lock (lk=0xc03acc74) at ../../ufs/ffs/ffs_softdep.c:263
#6 0xc02c4eac in softdep_update_inodeblock (ip=0xc265ec00, bp=0xc6c17f60, waitfor=0)
at ../../ufs/ffs/ffs_softdep.c:3626
#7 0xc02bd9b1 in ffs_update (vp=0xcfcfc540, waitfor=0) at
../../ufs/ffs/ffs_inode.c:107
#8 0xc02c9922 in ffs_fsync (ap=0xc038a6d4) at ../../ufs/ffs/ffs_vnops.c:289
#9 0xc02c8243 in ffs_sync (mp=0xc1a7be00, waitfor=2, cred=0xc0e39780, p=0xc03e0400)
at vnode_if.h:537
#10 0xc01fdf19 in sync (p=0xc03e0400, uap=0x0) at ../../kern/vfs_syscalls.c:566
#11 0xc01cb4ff in boot (howto=256) at ../../kern/kern_shutdown.c:225
#12 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at
../../kern/kern_shutdown.c:553
#13 0xc01c8d7b in chgsbsize (uid=50, diff=-17520, max=9223372036854775807) at
../../kern/kern_proc.c:206
#14 0xc01ee6aa in sbrelease (sb=0xcdc091f4, so=0xcdc09180) at
../../kern/uipc_socket2.c:453
#15 0xc01eb9fb in sofree (so=0xcdc09180) at ../../kern/uipc_socket.c:261
#16 0xc0221e0b in in_pcbdetach (inp=0xce1c3aa0) at ../../netinet/in_pcb.c:542
#17 0xc022c462 in tcp_close (tp=0xce1c3b60) at ../../netinet/tcp_subr.c:711
#18 0xc0229bf6 in tcp_input (m=0xc0e96500, off0=20, proto=6) at
../../netinet/tcp_input.c:2012
#19 0xc02247ee in ip_input (m=0xc0e96500) at ../../netinet/ip_input.c:756
#20 0xc022484b in ipintr () at ../../netinet/ip_input.c:784
#21 0xc0309195 in swi_net_next ()
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01cbac9 in panic (fmt=0xc0380e6f "page fault") at ../../kern/kern_shutdown.c:553
#2 0xc0316466 in trap_fatal (frame=0xc038a728, eva=48) at ../../i386/i386/trap.c:951
#3 0xc0316119 in trap_pfault (frame=0xc038a728, usermode=0, eva=48) at
../../i386/i386/trap.c:844
#4 0xc0315c8f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi
= 0, tf_ebp = -1070028948,
tf_isp = -1070028972, tf_ebx = -1069888396, tf_edx = 6864928, tf_ecx =
-1046781312, tf_eax = 0, tf_trapno = 12,
tf_err = 0, tf_eip = -1070853968, tf_cs = 8, tf_eflags = 66050, tf_esp =
-960338688, tf_ss = -1070028924})
at ../../i386/i386/trap.c:443
#5 0xc02c10b0 in acquire_lock (lk=0xc03acc74) at ../../ufs/ffs/ffs_softdep.c:263
#6 0xc02c63a8 in softdep_count_dependencies (bp=0xc6c26500, wantcount=0) at
../../ufs/ffs/ffs_softdep.c:4566
#7 0xc02c96fb in ffs_fsync (ap=0xc038a800) at ../../sys/buf.h:439
#8 0xc02c8243 in ffs_sync (mp=0xc1a7be00, waitfor=2, cred=0xc0e39780, p=0xc03e0400)
at vnode_if.h:537
#9 0xc01fdf19 in sync (p=0xc03e0400, uap=0x0) at ../../kern/vfs_syscalls.c:566
#10 0xc01cb4ff in boot (howto=256) at ../../kern/kern_shutdown.c:225
#11 0xc01cbac9 in panic (fmt=0xc0356920 "reducing sbsize: lost count, uid = %d") at
../../kern/kern_shutdown.c:553
#12 0xc01c8d7b in chgsbsize (uid=50, diff=-17424, max=9223372036854775807) at
../../kern/kern_proc.c:206
#13 0xc01ee6aa in sbrelease (sb=0xcdc08674, so=0xcdc08600) at
../../kern/uipc_socket2.c:453
#14 0xc01eb9fb in sofree (so=0xcdc08600) at ../../kern/uipc_socket.c:261
#15 0xc0221e0b in in_pcbdetach (inp=0xce1c0aa0) at ../../netinet/in_pcb.c:542
#16 0xc022c462 in tcp_close (tp=0xce1c0b60) at ../../netinet/tcp_subr.c:711
#17 0xc022cf76 in tcp_timer_2msl (xtp=0xce1c0b60) at ../../netinet/tcp_timer.c:212
#18 0xc01d2015 in softclock () at ../../kern/kern_timeout.c:131
This is out of a -CURRENT built some time round Mon Aug 28 16:17:04
CST(+9:30) 2000. I haven't had any other problems, so it doesn't seem
to be a general problem. Before I go looking in more detail, has
anybody else seen this, or do they have an idea what I should be
looking at?
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: interesting problem
On Thursday, 28 September 2000 at 21:45:13 -0500, Tony Johnson wrote: I will not provide comments as the below messages are already too messy. It would be nice if you'd adhere to the conventions when you reply, however. It's much easier to understand in chronological order. I've now had to manually move your comments to below the text to which they refer. The issue is this. I have been cvsup-ing 5.0-Current for months and recently I have and these problems. Within the last 4 weeks. My scsi cables or my adaptec controller had no influence on this since recently... OK, this is new information. I don't believe turning on stuff that has no functionality to the system should be an issue. If it is then this is broken. Agreed, if it is. We first need to establish that. You seem to be missing the point that we don't blame individual components until we have evidence. "People compile daily from -Current" Well I was one of them and I don't believe that my system is the problem! I don't believe anything yet. You need to find out what the problem is. In case you didn't notice it, I've had some problems as well in the last couple of days. Follow that thread, it might give you an idea about how we go about solving problems in -CURRENT. On Thursday, September 28, 2000 8:51 PM, Greg Lehey wrote: On Thursday, 28 September 2000 at 19:54:01 -0500, Tony Johnson wrote: I have a dual PPro-200 systems. aha-3950u2 scsi card. Teflon cables from scsi-cables.com. Segate cheetah 4.5gig drive that runs FreeBSD5.0-Current since it came out. Maybe you should change the teflon cables. Remove my teflon cables... Hmmm... I'll try it but something tells me that this is like trying to shoot an arbitrary star in the midnight sky. FreeBSD doesn't like teflon or is it just my system??? I'm sorry, this was intended as a reductio ad absurdum. I consider it so unlikely that it is the cables that I was drawing a parallel to you assuming that disabling the IDE drivers was the reason for My personal feeling is that you should take Alfred's advice and try to boot without disabling IDE. It may or may not work. If it doesn't, you'll know you're wrong about connecting the two events. If it does, it'll give you a system which is usable for debugging the problem. People keep saying that I am shooting blanks because I haven't provided any evidence. Give me a way to provide evidence and I will show you that 2000927-5.0CURRENT has crashed my machine which has worked on pretty much every revision of FreeBSD since 3.0-Current! The teflon cables and everything... It looks a little funny now that I've moved your text here, doesn't it? See how chronological order changes and clarifies things? In case you haven't noticed, I have given you a suggestion immediately above, but since you replied in a different place, you appear not to have noticed it. Maybe it's time to remind people about -CURRENT: Many users compile almost daily from FreeBSD-CURRENT sources, but there are times when the sources are uncompilable. The problems are always resolved, but others can take their place. On occasion, keeping up with FreeBSD-CURRENT can be a full-time business. If you use -CURRENT, you should be prepared to spend a lot of time keeping the system running. In particular, note who should be doing the work: the people who have the problem. It doesn't do any good to thrash around, make unsubstantiated claims and blame other people. On the contrary, it makes people think you're a jerk. As said below... As said just above, where it belongs. "In particular, note who should be doing the work: the people who have the problem. It doesn't do any good to thrash around, make unsubstantiated claims and blame other people. On the contrary, it makes people think you're a jerk." You don't need to repeat it, it's there in the text. Since I am complaining then I need to figure out what U have done to make 5.0-CURRENT crash?? Well atleast U admit that U do not know and U do not care. So anyone who is using FreeBSD should also not care?? This is more screwed up then I thought and people @FreeBSD have made this much harder then necessary. This kind of statement just tends to harden the negative impression you're already making. We care, but we don't care enough to do work for other people when they're just being abusive. If you want to run -CURRENT, at least pull your weight. I won't answer another message of this nature. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in kernel configuration menu
On Thursday, 28 September 2000 at 22:20:52 -0400, Wesley Morgan wrote: When the kernel configuration menu comes up with the three possible selections, pressing ctrl-alt-del ends up with this message: panic: spin lock (null) held by 0x0 for 5 seconds sounds like one that should be an easy fix Don't count on it. At the moment, it probably fits into the category "well don't do that then". Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: interesting problem
[Format recovered--see http://www.lemis.com/email/email-format.html] On Wednesday, 27 September 2000 at 19:07:17 -0500, Tony Johnson wrote: On Wednesday, September 27, 2000 6:48 PM, Kris Kennaway wrote: On Wed, 27 Sep 2000, Tony Johnson wrote: When I booted the 9/27/2000 (ie. today) I got a page fault 12 in kernel mode. The problem seems to be because I have all my IDE devices turned off in my bios. This is a claim which you need to substantiate. If this is the case, please undo this! How do we know if this is the case? That would be the silliest reason for a kernel to not boot because I want to save irq's. I got this from downloading the flp images and fdimage-ing them to disks! Well, no, I can think of sillier reasons. But if it's the case, we should do something about it. Please fix this Fix what? You havent given enough information to diagnose the problem. See the handbook about kernel debugging. I don't believe the handbook covers "today's" 5.0-Current... It contains information that you need to understand. Why would having no bustmastering DMA IDE disk contriollers on an all-scsi system cause a system to page fault from "today's" kern.flp mfsroot.flp boot floppy. Who knows? You haven't given any evidence for this opinion. Try again... Your turn. If you run -CURRENT, you're expected to do some work yourself. Certainly it's inappropriate to make an unsubstantiated claim and then say "fix it". If you want help, do what people suggest and come back with sensible questions if you don't understand something. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking doc.?
On Friday, 22 September 2000 at 19:50:11 -0700, Julian Elischer wrote: Do we have a document that descibes in great detail the locking policy that the SMPng code should follow? I've seen several descriptionms as to how it might be done, but I haven't seen a "Ok we've decided that this is the strategy we are using" document. I haven't seen one either. On the one hand it might be a little early to come up with a (restrictive) policy document, but I do think we should be discussing more actively how we go about subdividing the locking. There's been plenty of experience in the past to show that it's madness to just go about subdividing locks. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 1131 unneeded includes in the kernel...
On Wednesday, 20 September 2000 at 3:10:21 -0400, Brandon D. Valentine wrote: On Tue, 19 Sep 2000, Matthew Jacob wrote: Oh- don't get me wrong. Valuable info. Thanks. What would be very cool is to feed this into another script which strips these unnecesary includes out. Then do a test build of LINT in your local tree and if it succeeds commit a mass removal of them. The same concept could be applied to the greater source tree. Things aren't that simple. I've checked some of the vinum ones, and I find something like: #ifdef VINUMDEBUG #include sys/reboot.h #endif sys/reboot.h has been flagged as unnecessary. Obviously the #ifdef's have to do as well--if the script is correct. There are a number of options in Vinum which never get as far as the source tree. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Sunday, 17 September 2000 at 16:29:41 +0200, Michael Reifenberger wrote: Hi, ... The frames above are what the system went to as the result of your debugger request. I'd also be interested to see the output of the 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and 'ps' (the macro I promised above). (kgdb) icnt 1215544*566*0 0* 0 0 1 0 1555964*0* 0* 0* 0 0* 22636* 11 1 0 0 0 0 0 441031 imen: 6f0b (kgdb) ps pidprocaddruid pri ppid pgrp flag stat comm wchan 37 c7874a00 c96650000 32 636 004086 3 tar piperd c9663f20 36 c7874bc0 c960a0000 32 636 004006 3 tar FFS node c02f4220 35 c7874d80 c96070000 32 635 004006 3 tar inode c1d2fa00 6 c7874f40 c96040000 32 1 6 004086 3 sh wait c7874f40 5 c7875100 c82950000 4 0 0 000204 3 syncer syncer c03236e8 4 c78752c0 c82930000 4 0 0 100204 3 bufdaemonpsleep c03072f0 3 c7875480 c82910000 4 0 0 000204 3 vmdaemon psleep c0317a00 2 c7875640 c828f0000 4 0 0 100204 3 pagedaemon psleep c02f5938 21 c7875800 c78d40000 1*0 0 000204 2 irq8: rtc 20 c78759c0 c78d20000 1*0 0 000204 2 irq0: clk 19 c7875b80 c78b0 7*0 0 000204 6 irq5: pcm0 18 c7875d40 c788e0000 7*0 0 000204 6 irq7: ppc0 17 c7875f00 c788c0000 7*0 0 000204 6 irq12: psm0 16 c78760c0 c788a0000 7*0 0 000204 2 irq1: atkbd0 15 c7876280 c78870000 6*0 0 000204 6 irq6: fdc0 14 c7876440 c78850000 6*0 0 000204 6 irq15: ata1 13 c7876600 c78830000 6*0 0 000204 2 irq14: ata0 12 c78767c0 c78810000 4 0 0 000204 3 random rndslp c0322934 11 c7876980 c787f0000 15*0 0 008204 6 softinterrupt 10 c7876b40 c787d0000 4 0 0 008204 2 idle 1 c7876d00 c787b0000 4 0 1 004284 3 init wait c7876d00 0 c0322960 c03c0 4 0 0 000204 3 swapper sched c0322960 ... handler. At this point, it would be very interesting to see the value of p-p_comm, which is the process name at the end of the ps listing. (kgdb) proc 35 Why are you interested in this process? It was one of the tar's which I grabbed by hand (without your ps macro) ... Whats next to show :-) To quote: At this point, it would be very interesting to see the value of p-p_comm, which is the process name at the end of the ps listing. You could also show the content of p-p_pid. If you don't have a p pointer in the frame you're looking at, use ((struct *proc)gd_curproc)-p_pid and ((struct *proc)gd_curproc)-p_comm. We need to know what is hanging. I'm probably going on holiday for the rest of the week; somebody else should pick this one up. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Monday, 18 September 2000 at 1:23:30 +0200, Michael Reifenberger wrote: On Mon, 18 Sep 2000, Greg Lehey wrote: ... You could also show the content of p-p_pid. If you don't have a p pointer in the frame you're looking at, use ((struct *proc)gd_curproc)-p_pid and ((struct *proc)gd_curproc)-p_comm. We need to know what is hanging. Sorry doesn't seem to work: (kgdb) p p-p_comm No symbol "p" in current context. (kgdb) p ((struct*proc)gd_curproc)-p_pid A syntax error in expression, near `proc)gd_curproc)-p_pid'. (kgdb) p ((struct *proc)gd_curproc)-p_comm A syntax error in expression, near `proc)gd_curproc)-p_comm'. (kgdb) p gd_curproc $1 = 0xc78760c0 Oops, that's what comes of typing hurriedly early in the morning. p ((struct proc *)gd_curproc)-p_comm p ((struct proc *)gd_curproc)-p_pid Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote: On Mon, 18 Sep 2000, Greg Lehey wrote: ... Oops, that's what comes of typing hurriedly early in the morning. p ((struct proc *)gd_curproc)-p_comm p ((struct proc *)gd_curproc)-p_pid Works better: (kgdb) p ((struct proc *)gd_curproc)-p_comm $6 = "irq1: atkbd0\000\000\000\000" (kgdb) p ((struct proc *)gd_curproc)-p_pid $7 = 0x10 Hmm. I suppose that's reasonable, since you've just pressed a key. We obviously have a problem here, but I'm not going to be able to look at it myself until Friday or Saturday. Anybody else want to take a look? There's also the possibility that a problem I had seen and not investigated could in fact be the same problem: I got it tarring and untarring across an NFS connection. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Sunday, 17 September 2000 at 0:32:01 +0200, Michael Reifenberger wrote:
Hi,
-current hangs reliable (as described in another mail) for me.
For short:
"tar cf /dev/null /usr/ports; tar cf - /usr/ports | tar tf -"
locks the system solid after a few minutes.
The first tar itself seems to need some time longer before hang.
This is verified to occure with 2 different disks (IDE).
I've seen this on NFS a few weeks back, but I haven't followed
through. In my case, I couldn't even get to the debugger.
Now the questions how to debug this:
- How do I get a backtrace of a specific process from within DDB?
- How do I determine where the system hangs/loops fromm within DDB?
I can't give you answers for ddb.
- How do I get the process-list (like ps) from within gdb (postmortem)
I have a macro which does this. I should commit some of them, but
they're in terrible shape. I'm attaching them to this message.
You'll have to modify at least .gdbinit.paths.
Below is a first try to debug postmortem with gdb
Does this look reasonable? Something else to look?
snip
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475
475 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:475
#1 0xc017aeb3 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc017b255 in panic (fmt=0xc02802b4 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:568
#3 0xc013b2c9 in db_panic (addr=-1071295444, have_addr=0, count=-1,
modif=0xc788bd88 "") at /usr/src/sys/ddb/db_command.c:433
#4 0xc013b269 in db_command (last_cmdp=0xc02bf5b4, cmd_table=0xc02bf414,
aux_cmd_tablep=0xc03002fc) at /usr/src/sys/ddb/db_command.c:333
#5 0xc013b32e in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#6 0xc013d4eb in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
#7 0xc02551ca in kdb_trap (type=3, code=0, regs=0xc788beac)
at /usr/src/sys/i386/i386/db_interface.c:163
#8 0xc0260fdc in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1070530544,
tf_edi = -1070468928, tf_esi = -1070491744, tf_ebp = -947339528,
tf_isp = -947339560, tf_ebx = 582, tf_edx = -1072984320, tf_ecx = 32,
tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071295444, tf_cs = 8,
tf_eflags = 70, tf_esp = -1070930945, tf_ss = -1070944311})
at /usr/src/sys/i386/i386/trap.c:584
#9 0xc025542c in Debugger (msg=0xc02aafc9 "manual escape to debugger")
at machine/cpufunc.h:64
The frames above are what the system went to as the result of your
debugger request. I'd also be interested to see the output of the
'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and
'ps' (the macro I promised above).
#10 0xc0251f36 in scgetc (sc=0xc031f0c0, flags=2)
at /usr/src/sys/dev/syscons/syscons.c:3133
#11 0xc024ef59 in sckbdevent (thiskbd=0xc0317f60, event=0, arg=0xc031f0c0)
at /usr/src/sys/dev/syscons/syscons.c:634
#12 0xc0246eae in atkbd_intr (kbd=0xc0317f60, arg=0x0)
at /usr/src/sys/dev/kbd/atkbd.c:462
#13 0xc026c45c in atkbd_isa_intr (arg=0xc0317f60)
at /usr/src/sys/isa/atkbd_isa.c:125
The ones above are the keyboard interrupt handler.
#14 0xc02681a4 in ithd_loop (dummy=0x0) at /usr/src/sys/i386/isa/ithread.c:239
This is the interesting one. We appear to be looping in an interrupt
handler. At this point, it would be very interesting to see the value
of p-p_comm, which is the process name at the end of the ps listing.
(kgdb) proc 35
Why are you interested in this process?
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
source .gdbinit.kernel
source .gdbinit.paths
tr
# GRRR
# set remotebaud 115200
set remotebaud 9600
set remotetimeout 1
set complaints 1
set print pretty
# dir /src/ZAPHOD/src/sys/modules/vinum
# dir /src/ZAPHOD/src/sys/i386/conf
# dir /src/ZAPHOD/src/sys
dir src/sys/i386/conf
dir src/sys
file src/sys/compile/ZAPHODng/kernel.ko.debug
define asf
set $file = linker_files.tqh_first
set $found = 0
while ($found == 0)
if (*$file-filename == 'v')
set $found = 1
else
set $file = $file-link.tqe_next
end
end
shell /usr/bin/objdump --section-headers sys/modules/vinum/vinum.ko | grep ' .text'
| awk '{print "add-symbol-file sys/modules/vinum/vinum.ko \$file-address+0x" $4}'
.asf
source .asf
end
document asf
Find the load address of Vinum in the kernel and add the symbols at this address
end
define xi
x/10i $eip
end
define xs
x/12x $esp
end
define xb
x/12x $ebp
end
define z
ni
x/1i $eip
end
define zs
si
x/1i $eip
end
define xp
printf " esp: "
output/x $esp
echo (
output (((int)$ebp)-(int)$esp)/4-4
printf " words on stack)\n ebp: "
output/x $ebp
printf "\n eip: "
x/1i $eip
printf "Saved ebp: "
output/x *(int*)$ebp
printf " (maximum of "
output ((*(int*)$ebp)-(int)$ebp)/4-4
printf " parameters possible)\nSaved eip: "
x/1i *(int*)($ebp+4)
printf "\nParm 1 at "
No block devices (was: VMWare on -current, how fast should I expect it to be?)
On Tuesday, 12 September 2000 at 10:13:16 -0400, Thomas David Rivers wrote: Julian Elischer ([EMAIL PROTECTED]) wrote: Nik Clayton wrote: Hi guys, For those of you running VMWare (2) on -current, how fast do you expect it to be? I'm running it quite successfully on a 750MHz PIII w/ 128MB RAM, and the following disk controller / disk atapci0: Intel PIIX4 ATA33 controller port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 17301MB FUJITSU MHJ2181AT [35152/16/63] at ata0-master using UDMA33 This is -current from about three weeks ago. It works, but it's a bit slow. Applications themselves run at a reasonable speed, but every now and then (can be as frequent as 10-15 seconds) use only virtual disks and see if it still happens. I found (on vmware 1) that using the raw disks was a recipe for poor performance. Since we don't have block devices any more, we are screwed in this regard. Virtual disks (files) are however buffered and so can sometimes work faster. I'm confused... I thought one of the justifications for removing the block devices was "look - Linux doesn't have any." No, that's never been a justification for removing block devices. Linux has block devices but no character disk devices. FWIW, I was never happy with the removal of block devices either. I was shouted down with "can you point to any one use they are?", to which I replied "just because I don't know of one doesn't mean there isn't one, or that there will never be one in the future". This is an example where they could presumably be useful. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
On Monday, 11 September 2000 at 17:44:43 +1100, Bruce Evans wrote: On Mon, 11 Sep 2000, Greg Lehey wrote: On Monday, 11 September 2000 at 13:18:37 +1100, Bruce Evans wrote: The stray interrupt handler needs to have a thread, or stray interrupts need to be handled as traps. Stray interrupts are more like NMIs than normal interrupts, and NMIs are already (mis)handled as traps. Independently of that, we need to be able to survive a spurious interrupt on any IRQ. Not really independent. Spurious interrupts on "any" IRQ can't happen, interrupts without a handler are masked. Right, I had forgotten that. But it's still defensive programming to DTRT if we get one, especially if it doesn't cost anything. Spurious interrupts on irq7/irq15 can happen because normal masking by the irq7/irq15 bit in the ICU doesn't apply (I think they can happen even if all bits in the ICU mask are set). They are like an NMI in this respect. Strange. Does this still happen on modern hardware? The old code accidentally had some defense against nested spurious interrupts. Masking in the ICU doesn't work, but masking in `cpl' happens to do the right thing (actually the same wrong thing as for non-nested spurious interrupts). We don't have a cpl any more. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
On Sunday, 10 September 2000 at 0:23:15 -0500, Mike Meyer wrote: Ben Smithurst writes: After poking around a bit with remote GDB, this seems to be caused by a stray IRQ 7, since irq == 7, ir == ithds[irq] == NULL, ir-foo == BOOM. The attached rather crude patch has "fixed" the problem for now, but does anyone have any suggestions for a real fix? Isn't a stray IRQ a hardware glitch? If so, I'd say that logging it and then ignoring it would be the right thing. Sorry, I missed the beginning of this. Could somebody send me the patch? I'd assume that a relatively simple check would handle the issue, based on what I've seen here. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: page fault in sched_ithd
On Monday, 11 September 2000 at 13:18:37 +1100, Bruce Evans wrote: On Sat, 9 Sep 2000, Ben Smithurst wrote: After poking around a bit with remote GDB, this seems to be caused by a stray IRQ 7, since irq == 7, ir == ithds[irq] == NULL, ir-foo == BOOM. The attached rather crude patch has "fixed" the problem for now, but does anyone have any suggestions for a real fix? The stray interrupt handler needs to have a thread, or stray interrupts need to be handled as traps. Stray interrupts are more like NMIs than normal interrupts, and NMIs are already (mis)handled as traps. Independently of that, we need to be able to survive a spurious interrupt on any IRQ. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New ATA tagged queuing patch available
On Friday, 8 September 2000 at 13:48:37 -0500, Chris Dillon wrote: On Fri, 8 Sep 2000, Soren Schmidt wrote: If I dont get any serious problem reports I'll commit this shortly, making FreeBSD the first OS that has tagged Queuing support for ATA drives :) Wow, even before Windows? :-) He did say "OS". Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPng CPU states
On Friday, 8 September 2000 at 14:17:58 -0300, Brandon Hume wrote: I've built world and kernel yesterday, and was delighted to see the AIC7xxx problems had gone away. I actually got tripped up by having Linux emulation enabled and forgetting to remove old modules, but that was fixed quick. All-in-all, I'm not having a rough time at all with the new code. My machine has been up for 7.5 hours now without a hiccup. I DID notice that I can't load X without a hang, which I think is the same AGP problem someone else mentioned. FWIW, I've had no trouble running X on my development box. Well, the monitor can only do 640x480, but that's not an OS issue. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes committed ... ?
On Thursday, 7 September 2000 at 3:11:27 -0300, The Hermit Hacker wrote: I thought one of the SMP developers announced that it was now committed, yet I haven't seen any commit messages for it ... I'm running the newest patch, so am waiting for the commit messages before I actually do my next upgrade ... Did I mis-read a message from earlier today? There were only two relatively short commit messages. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP mega-commit complete
On Thursday, 7 September 2000 at 20:06:20 +0900, Motomichi Matsuzaki wrote: At 6 Sep 2000 18:35:17 -0700, Jason Evans [EMAIL PROTECTED] wrote: If you run into issues that appear related to the SMP changes, and they aren't listed as known issues, please bring them up on the -smp or -current mailing list. this breaks building GENERIC kernel. cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/opt/usr/src/sys -I/opt/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /opt/usr/src/sys/i386/i386/genassym.c In file included from /opt/usr/src/sys/sys/signalvar.h:42, from /opt/usr/src/sys/sys/user.h:59, from /opt/usr/src/sys/i386/i386/genassym.c:66: machine/smp.h:19: #error SMP not supported with I386_CPU *** Error code 1 Sorry, my bad. Pass the pointy hat. I didn't know that smp.h was included in a non-SMP system. I see that John Baldwin has already committed a fix. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'interrupt-level buffer overflows' for sio device?
On Thursday, 7 September 2000 at 17:00:15 -0600, Chuck Paterson wrote: FYI, this is very likely not caused by the heavy weight interrupt threads, but rather because the interrupt threads can't be run because the giant lock is held by a process running in the kernel. Once we get drivers to have their own locking and pulled out from under the giant lock this problem should deminish greatly. Before we can do this there are various infrastructure pieces which must be made mp safe, such as the lockmanger. We're running sio as a fast interrupt, so it's definitely not because of a heavyweight thread :-) I think fast interrupts also completely bypass mutexes, though something might have changed since I last looked. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
On Thursday, 7 September 2000 at 17:28:02 -0700, John Baldwin wrote: Steve Ames wrote: Just upgraded to -CURRENT as of about noon (EST) today. At reboot I got a lot of these: microuptime() went backwards (1.7682417 - 1.997434) I recall reading in -current earlier this week that someone was looking for victims getting this. What further information can I provide? This is a SMPng issue on UP machines. Yes, but it's not the only cause. We've also seen it on pre-SMPng stuff, and Athlons seem to be particularly capable of doing it. phk is looking at it at the moment, and he has an idea what's causing it. I'd guess, however, that this *is* the SMPng problem. It's subtly different from other manifestations in that the first time typically has 7 digits after the decimal point. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
On Thursday, 7 September 2000 at 17:48:06 -0700, John Baldwin wrote: Greg Lehey wrote: On Thursday, 7 September 2000 at 17:28:02 -0700, John Baldwin wrote: Steve Ames wrote: Just upgraded to -CURRENT as of about noon (EST) today. At reboot I got a lot of these: microuptime() went backwards (1.7682417 - 1.997434) I recall reading in -current earlier this week that someone was looking for victims getting this. What further information can I provide? This is a SMPng issue on UP machines. Yes, but it's not the only cause. We've also seen it on pre-SMPng stuff, and Athlons seem to be particularly capable of doing it. phk is looking at it at the moment, and he has an idea what's causing it. I'd guess, however, that this *is* the SMPng problem. It's subtly different from other manifestations in that the first time typically has 7 digits after the decimal point. Most definitely an SMPng issue. If you take a SMP machine and compile a UP and an SMP kernel on it, the SMP kernel will boot fine, whereas the UP kernel will generate these warnings. The point I'm making is that we've had these problems before SMPng, and that you can't automatically assume that it's SMPng just because you get the messages. On the other hand, the 7 digits seem to be a pretty reliable signature. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
On Thursday, 7 September 2000 at 22:49:30 -0400, Kenneth Wayne Culver wrote: The point I'm making is that we've had these problems before SMPng, and that you can't automatically assume that it's SMPng just because you get the messages. On the other hand, the 7 digits seem to be a pretty reliable signature. I'm getting this error while starting XFree86 4.0.1 on my laptop computer, and I'm using FreeBSD 4.1-STABLE, so I'm sure it's not the SMP stuff that's causing it. Right, but you're not getting the 7 digit microsecond count, right? You should contact phk. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
On Friday, 8 September 2000 at 0:18:07 -0400, Kenneth Wayne Culver wrote: On Fri, 8 Sep 2000, Greg Lehey wrote: On Thursday, 7 September 2000 at 22:49:30 -0400, Kenneth Wayne Culver wrote: The point I'm making is that we've had these problems before SMPng, and that you can't automatically assume that it's SMPng just because you get the messages. On the other hand, the 7 digits seem to be a pretty reliable signature. I'm getting this error while starting XFree86 4.0.1 on my laptop computer, and I'm using FreeBSD 4.1-STABLE, so I'm sure it's not the SMP stuff that's causing it. Right, but you're not getting the 7 digit microsecond count, right? You should contact phk. Well, here is one of the messeges: Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412, -694583121) this is bad.. right ? :-) Well, at any rate it looks very funny. If this is a laptop, try building a kernel without apm and see if that helps. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
On Thursday, 7 September 2000 at 22:43:11 -0700, Mike Smith wrote: Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 - 10412, -694583121)y this is bad.. right ? :-) Well, at any rate it looks very funny. If this is a laptop, try building a kernel without apm and see if that helps. It only helps "hide" the problem. There's either *extremely* bogus data coming in, or an arithmetic or sequencing error that's allowing a corrupt timecounter to be seen. Correct. As I mentioned earlier in the thread, phk has an idea what the problem is, and he's asked for people with it to contact him. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
On Monday, 28 August 2000 at 8:24:50 -0500, Mike Meyer wrote: Maxim Sobolev writes: Mike Meyer wrote: Will the system fail to boot if there isn't an empty device.hints file? No, it will boot, but some devices (like keyboard, console etc) would not work. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. That's probably because you have hints compiled into your kernel. Try to compile kernel w/o hints and use it with empty/unexistent /boot/device.hints and you will see what I mean. Well, yeah, I'd expect that. I'm still trying to figure out what *good* failing to compile unless there's an empty /boot/device.hints does. I mean, if I didn't provide kernel hints, it would make some sense if the build process could determine that it was building on the machine it was running on. On Monday, 28 August 2000 at 14:45:23 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Meyer writes: Maxim Sobolev writes: Mike Meyer wrote: Donn Miller writes: Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Actually, device.hints isn't used in the build process. In that case, why does the kernel build process fail if it doesn't exist? Probably because you have `hints "BLABLA.hints"' line in your kernel config file. That doesn't really answer the question. Yup, I use GENERIC.hints. That exists. I can see why that not existing would cause problems, but not /boot/device.hints? *Especially* when I'm building a kernel for a different machine? The build of the kernel isn't forbidden by not having /boot/device.hints, just the install. I just copied my GENERIC.hints to /boot/device.hints and things were happy. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. Specifically, the console will not work without hints. These hints can be compiled in or in /boot/device.hints. You need to have hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbd.0.flags="0x1" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" At a minimum, but I might be mistaken about that. At the very least, there appears to be confusion about how to use the hints. I can see two conflicting views here: 1. You must have a /boot/device.hints file, but it may be empty. 2. You must have a /boot/device.hints file, and it must contain at least some entries. I ran into this same problem yesterday. I had noticed it in the cvs mailing list, and I found the first entry in UPDATING. But it didn't say what to put in, and I found no other documentation. Finally John Baldwin told me to copy my GENERIC.hints, so I did that, and it worked. But it seems that we should have some documentation here. On the face of it, (1) above seems the most obvious solution. In that case, 'make install' shouldn't fail if there's no device.hints file, it should make one. If it's (2), it can still copy the MYKERNEL.hints file. Which begs the question: when should the hints file be updated? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent -CURRENT locks up keyboard
I've just built a new world on one of my test boxes. The good news is that the Macronix Ethernet card that I have in it works fine (this is the one with the MX98715AEC-C chip with the small hash table). The bad news is that the keyboard is non-functional. This is a GENERIC kernel with nothing changed. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
