Re: current on a laptop...
In message <01be9cef$64202e60$2c4b9...@william> "William Woods" writes: : I am haveing a bear of a time getting pcmcia cards to work in 3.1-Stable and : was wondering how well current performs with these. Hmmm. I don't think that -current will help, and may even hurt. What kind of laptop? Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message <199905122048.qaa72...@misha.cisco.com> Mikhail Teterin writes: : Perhaps, the newbus vs. newconfig discussion can be summarized to both : sides' satisfaction offline and then presented to the rest of the world? It is my impression that the language barrier has made this discussion harder to follow. In all the discussions I've seen, both here and elsewhere, it seems like the two sides are talking past one another. That's one reason I really like Doug's idea for a meeting at Usenix (sadly, I'm unable to attend). This isn't a simple issue, and there are many subtle advantages and disadvantages to both systems which are hard to convey in email... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message <199905120901.saa04...@srapc288.sra.co.jp> Noriyuki Soda writes: : This reminds me another ugly kluge in sys/pccard/i82365.h: : #define PCIC_INDEX_00x3E0 : #define PCIC_INDEX_1(PCIC_INDEX_0 + 2) : This is the way what some clever FreeBSD people saids "right" to : Nakagawa-san, though Nakagawa-san never agreed that it is right, and : rather likes the newconfig way like below: : pcic0 at isa? port 0x3e0 : pcic1 at isa? port 0x3e2 : pcic* at pci? : pcic* at isapnp? : It is apparent which is better and cleaner for me. But perhaps you do : not agree with me. :-) This is a horrible kludge (eg what is in FreeBSD right now is bogus and truely evil). I like the way that newconfig attaches things, which is why I'm currently reworking the pccard code. Actually, I'd rather junk most/all of the code that is there now. The code was good for the time, but now it has been overtaken by events. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Solved: Repeated I/O errors in 3.2-BETA
On Thursday, 13 May 1999 at 14:19:23 +0930, Greg Lehey wrote: > I've had a couple of these in a 3.2-BETA box today: > > May 13 14:11:51 daemon /kernel: spec_getpages: I/O read failure: (error > code=16) > May 13 14:11:57 daemon /kernel: size: 65536, resid: 65536, a_count: 65536, > valid: 0x0 > May 13 14:11:57 daemon /kernel: nread: 0, reqpage: 0, pindex: 0, pcount: 16 > > After that, the system is effectively dead. This is the same system I > normally run -CURRENT on, so it's not specifically a hardware error. > It's a pity that the message doesn't specify the device, but I assume > it has to be the swap partition. There aren't any other error > messages. error appears to be bp->b_error, which means it's an EBUSY, > which is puzzling enough as it is. Well, it looks as if it's a dying disk. Sorry for the false alarm. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: stay -current without skill in debugging (was: panic !)
> It's certainly not because of the helping hands that have been > extended to him. -current doesn't come with seat belts or air bags. If you're looking for a helping hand rather than a ranger combat course where people just boot you in the ass whenever you fall into the mud, go next door to -stable please. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: stay -current without skill in debugging (was: panic !)
On Wednesday, 12 May 1999 at 21:56:53 -0700, Jordan K. Hubbard wrote: >> No offense surely, but I have been running -current in this (and others >> with Libretto too) box since 2.2-current, in true, without too much >> trouble, and I am survived to a lots of nasty things in the meantime. I > > This only constitutes a confession on your part that you've survived > by pure luck up to now, I'm afraid. :-) It's certainly not because of the helping hands that have been extended to him. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: stay -current without skill in debugging (was: panic !)
> No offense surely, but I have been running -current in this (and others > with Libretto too) box since 2.2-current, in true, without too much > trouble, and I am survived to a lots of nasty things in the meantime. I This only constitutes a confession on your part that you've survived by pure luck up to now, I'm afraid. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
stay -current without skill in debugging (was: panic !)
At 12/05/99, you wrote: >> Pardon, but I am not be able to figure by myself what you asked to me... >> If you can explain me step by step in a newbie way I can do everything ... >> The crashes is easily reproducible... > >No offense, but are you sure you should even be running -current? A >certain amount of skill in doing such diagnosis is generally >considered mandatory for people running it, even though many people >who shouldn't be doing so for that reason still do it. :) No offense surely, but I have been running -current in this (and others with Libretto too) box since 2.2-current, in true, without too much trouble, and I am survived to a lots of nasty things in the meantime. I have reinstalled this box from cdrom only a couple of time. because I usually use cvsup (and make world) to stay in sync (my cvs tree is at 194.184.65.3 , cvsup.masternet.it). I don't know too much (nothing !?) of kernel debugging, but I have learn surely in these years how survive in case of the most common problems with it (-current). Let's say I am learning how to become an hacker, but I do it very slowly, even if I am confident for the future :-) and so for the moment my function is still only "bug advisor" :-) Thanks for your kind reply. Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Repeated I/O errors in 3.2-BETA
I've had a couple of these in a 3.2-BETA box today: May 13 14:11:51 daemon /kernel: spec_getpages: I/O read failure: (error code=16) May 13 14:11:57 daemon /kernel: size: 65536, resid: 65536, a_count: 65536, valid: 0x0 May 13 14:11:57 daemon /kernel: nread: 0, reqpage: 0, pindex: 0, pcount: 16 After that, the system is effectively dead. This is the same system I normally run -CURRENT on, so it's not specifically a hardware error. It's a pity that the message doesn't specify the device, but I assume it has to be the swap partition. There aren't any other error messages. error appears to be bp->b_error, which means it's an EBUSY, which is puzzling enough as it is. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
current on a laptop...
I am haveing a bear of a time getting pcmcia cards to work in 3.1-Stable and was wondering how well current performs with these.I have current running on a few desktop systems here so running it is no prob..reccomendations? William To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Some interrupt bogons still around.
On Thu, 13 May 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > An old 486 of mine still cant see its IDE driver with versions of ata-all.c > later than 1.8, and my soundcard (PAS16) still doesn't seem to generate > interrupts since the nexus stuff went in. my stock SB16 + freebsd+x11amp hasn't worked right since newbus. sound skips quite a bit. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
-current page fault at 0xdeadc0de
I had two systems reboot at nearly the same time. (30 seconds apart), and
are completely unrelated.
One system was running 2.2.8, and my core file presents me with this:
su-2.02# gdb -k
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation,
Inc.
(kgdb) exec-file kernel.0
(kgdb) symbol-file kernel.0.debug
Reading symbols from kernel.0.debug...done.
(kgdb) core-file vmcore.0
IdlePTD 24a000
current pcb at 202bfc
#0 0x14 in ?? ()
(kgdb) bt
#0 0x14 in ?? ()
#1 0x3404 in ?? ()
Cannot access memory at address 0x7205c76a.
Were things just trashed, or am I doing something wrong?
The other system was running -current, and gives me:
su-2.02# gdb -k
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation,
Inc.
(kgdb) exec-file kernel.2
(kgdb) symbol-file kernel.2.debug
Reading symbols from kernel.2.debug...done.
(kgdb) core-file vmcore.2
IdlePTD 3096576
initial pcb at 27ea40
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc0de
fault code = supervisor read, page not present
instruction pointer = 0x8:0xdeadc0de
stack pointer = 0x10:0xcb4adec0
frame pointer = 0x10:0xcb4adefc
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 = 40969 (eggdrop)
interrupt mask =
trap number = 12
panic: page fault
syncing disks...
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc126
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc018e3d8
stack pointer = 0x10:0xcb4ad91c
frame pointer = 0x10:0xcb4ad93c
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 = 40969 (eggdrop)
interrupt mask =
trap number = 12
panic: page fault
dumping to dev 20001, offset 467137
dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238
237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219
218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200
199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181
180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162
161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143
142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124
123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105
104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81
80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56
55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31
30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3
2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:288
288 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:288
#1 0xc0145755 in panic () at ../../kern/kern_shutdown.c:450
#2 0xc020e9e2 in trap_fatal (frame=0xcb4ad8dc, eva=3735929126)
at ../../i386/i386/trap.c:917
#3 0xc020e695 in trap_pfault (frame=0xcb4ad8dc, usermode=0, eva=3735929126)
at ../../i386/i386/trap.c:810
#4 0xc020e2d7 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi =
0,
tf_esi = 0, tf_ebp = -884287172, tf_isp = -884287224, tf_ebx = 16384,
tf_edx = -559038242, tf_ecx = -1059309536, tf_eax = -1053816960,
tf_trapno = 12, tf_err = 0, tf_eip = -1072110632, tf_cs = 8,
tf_eflags = 66182, tf_esp = -1062703744, tf_ss = -911937724})
at ../../i386/i386/trap.c:436
(kgdb)
Not exactly a lot to go on... Mean anything to anyone? Any more info I can
provide?
Kevin
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> On whose authority do you say that? Garrett is a core team member. I heard from Asami-san, Any voting not yet for new-bus. After that, "new-bus patch" merge is decided. new-bus merge is core decision, but "drop static configration", ... these are not yet voted. > Then explain to us why newbus is wrong and why the 4.4BSD scheme is > right. Because, you are misunderstanding 4.4BSD scheme (and newconfig). -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: cvs commit: src/sys/pci pcisupport.c
> Because if it's a day of coding, you should just do it. If it's a 3 > month project, you don't waste such time, and you should communicate it. > The time factor is judged by folks who code for a living, and maybe it's > a little high, but not too bad. I haven't seen this rule misapplied, > but it's possible some may think so; they are most likely mis-estimating > the scope of the work involved. Believe it or not, good ideas can even come from people who can't code at all, and the ideas are just as good. Slapping these people down just ensures they don't contribute in the future. Now if their ideas genuinely are bad, you are more than welcome to slap them down as much as you wish. If that means they don't contribute more bad ideas in the future, so much the better. Heck, it even may save you the idea of having to explain why the bad idea is, in fact, bad. But "if it's such a good idea, why don't you code it?" doesn't fall into any of these categories. It's one of those "that's what you think" type arguments that serves as an excuse to ignore the merits of the other side's case. DS To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, David Schwartz wrote: > > > I have to comment on this, it's too outrageous. Several times in the > > past, folks have written in and asked, if they wrote some particular > > piece of software, would it get committed. They said that it was a > > large undertaking, and that they wouldn't undertake it, unless there was > > general agreement beforehand about it. > > There is a big difference between a general agreement that some feature > or > other is a "good thing" and a blank check of approval for code changes. > These seem to get confused all the time. > > One example of this problem, in the opposite direction of the one you > mentioned, is the old, "If you think that's such a good idea, why don't you > code it and submit it?" This is equally unhelpful. If it's a bad idea, why > should anyone code it? If it's a code idea, why does it matter who codes it, > as long as it's coded well? Because if it's a day of coding, you should just do it. If it's a 3 month project, you don't waste such time, and you should communicate it. The time factor is judged by folks who code for a living, and maybe it's a little high, but not too bad. I haven't seen this rule misapplied, but it's possible some may think so; they are most likely mis-estimating the scope of the work involved. I have a 3 day project in mind; I'm just going to code it (once I get finished with classes in 2 weeks); if it gets turned down, I'm a big boy, I'll get over it. If it was longer, I would bore you all with it. It's not, and I won't. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Some interrupt bogons still around.
An old 486 of mine still cant see its IDE driver with versions of ata-all.c later than 1.8, and my soundcard (PAS16) still doesn't seem to generate interrupts since the nexus stuff went in. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: cvs commit: src/sys/pci pcisupport.c
> I have to comment on this, it's too outrageous. Several times in the > past, folks have written in and asked, if they wrote some particular > piece of software, would it get committed. They said that it was a > large undertaking, and that they wouldn't undertake it, unless there was > general agreement beforehand about it. There is a big difference between a general agreement that some feature or other is a "good thing" and a blank check of approval for code changes. These seem to get confused all the time. One example of this problem, in the opposite direction of the one you mentioned, is the old, "If you think that's such a good idea, why don't you code it and submit it?" This is equally unhelpful. If it's a bad idea, why should anyone code it? If it's a code idea, why does it matter who codes it, as long as it's coded well? DS To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999, Noriyuki Soda wrote: > This doesn't answer my wondering. The core members can safely postpone > the decision after Usenix, because all of core members must know that > both new-bus people and newconfig people will come to Freenix track. > Who is the chair of Freeunix track ? :-) > > > Whether new-bus or newconfig is "better" was really, honestly not > > the issue so much as were the following two bullet points: > > Quite interesting. This means that FreeBSD doesn't choose technology > by it's design, but by which spokes loudly. I definitely say that this > is worst way to design software. I have to comment on this, it's too outrageous. Several times in the past, folks have written in and asked, if they wrote some particular piece of software, would it get committed. They said that it was a large undertaking, and that they wouldn't undertake it, unless there was general agreement beforehand about it. This has always had one response. No. We don't give apriori blank check agreement to stuff like that, because we don't know which way it's going to go, and if the final product isn't going where the developers (which means generally core, but not completely) then it's gong to be rejected. This has caused bad feelings sometimes, but it's stopped some folks from trying to hi-jack FreeBSD, and force it to go where one person wants it to go; it forces FreeBSD to be a group decision. So, how do big projects get done, then? The first point being brought up is true, no one wants to invest hugely in a project, just to see the work rejected. The way we get around that is by communicating, regularly and thoroughly, about the design and implementation of the project. Good communications means that we don't get into fights, and FreeBSD goes where the group wants it to go, not where some small set of interests want to hi-jack it. I am NOT saying that you or your group want to hijack anything, but the process DOES stop folks from doing that, and it's in fact already stopped that from happening more than once in my memory. Communications is a good thing, not something to be embarrassed about. Describing communications as "by which spokes loudly" is missing the point. Loudness hasn't the least to do with it. Regularity and clarity, getting the message across, is what's important. That is where your group has misunderstood the process. By going off on your own, and doing all that coding without any input, you established a reputation for not being willing to work together. Someone with a proven track record of communicating regularly was chosen. Not from a technical standpoint, but from a managerial standpoint, why does this surprise you? Don't offer technical arguments, this is not a technical issue. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Vinum broken in -CURRENT
I've just had some convincing reports that Vinum in current doesn't work at the moment. This is almost certainly something to do with the change in the representation of device numbers, and it's something I've been half expecting, but I don't have time to look at it this week. If you're using Vinum, please wait until next week before updating your configuration. Sorry about the trouble Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, Mike Smith wrote: > > This option should automatically select the appropriate sources > > which is compiled into kernel, according to the source is needed > > only in UP case, or only in SMP case, or both. This is what > > oldconfig and newconfig does. > > This is, again, defective reasoning. > > For a usable dynamic architecture, loadable modules need to be compiled > to support both UP and SMP architectures simultaneously. Thus the > locking primitives need to be conditionalised at _runtime_. Or, alternately, at load time by choosing the appropriate subsystem to match the hardware. It is clearly possible to arrange that lowest-common-denominator code is initially loaded and then replaced with a configuration optimized version. The "configuration" at compile time is in the Makefile to cause, when appropriate, the various versions to be compiled from common code. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mikael Karpberg wrote: > That would be so lovely, with a DEVFS too: > Plug your Cool card into your pcmcia slot, and get the message on > the sytem console that an unknown pcmcia card called "Cool", made > by CoolMakers, Inc. Damn... not even a generic driver wanted this card. > Pull the card out and go for the web: > # ftp ftp.a.cool.thing.com > ftp> get cool.tgz > --> Downloading file. Pah. kldload http://www.cool.com/drivers/freebsd/cool.ko Perhaps kld modules should have some kind of signature verification to support such a thing. That'd be so great. The FreeBSD installation floppy could delay most device probes until after you've set up networking (so you'd need some network drivers on the floppy) then grab all the latest versions of the other drivers it wants to complete the install from www.freebsd.org... - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
> On Wed, May 12, 1999 at 05:06:03PM -0700, Mike Smith wrote: > > > well, I wonder if other people have noticed this also, but if you don't > > > have a previous boot loader installed (like windows/dos) the ONLY way > > > to install onto a machine is TO use a dangerously dedicated mode... > > > > This is quite untrue. I do a lot of installs to virgin systems on a > > wide range of hardware, and I haven't encountered any situations where > > DD has been necessary in a long time. OTOH, I have met many where DD > > would be fatal. > > Virgin systems is not virgin disks. If you buy a complete PC, this > bootloader from Redmonton is already on the disk. I had similiar > problems a while back and unless someone has explicitely looked > after this, it still persits. I am not a complete idiot, and when I say "virgin" system, I mean it. I'm quite aware of your problem. I outlined several solutions to it in the previous message, and elaborated on them in the handbook update I wrote about DD mode. I'm always looking for better ways of dealing with this problem; DD mode is not one however. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
On Thu, May 13, 1999 at 12:16:17PM +1200, a little birdie told me that Joerg Micheel remarked > > Virgin systems is not virgin disks. If you buy a complete PC, this > bootloader from Redmonton is already on the disk. I had similiar > problems a while back and unless someone has explicitely looked > after this, it still persits. I just last night did a full install onto a set of fresh virgin disks in a fresh virgin system (all bought component-at-a-time) without using DD. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew FullerMF4839http://www.over-yonder.net/ | * fulle...@futuresouth.com fulle...@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | *is because I haven't figured out how to light the* | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
Mike, On Wed, May 12, 1999 at 05:06:03PM -0700, Mike Smith wrote: > > well, I wonder if other people have noticed this also, but if you don't > > have a previous boot loader installed (like windows/dos) the ONLY way > > to install onto a machine is TO use a dangerously dedicated mode... > > This is quite untrue. I do a lot of installs to virgin systems on a > wide range of hardware, and I haven't encountered any situations where > DD has been necessary in a long time. OTOH, I have met many where DD > would be fatal. Virgin systems is not virgin disks. If you buy a complete PC, this bootloader from Redmonton is already on the disk. I had similiar problems a while back and unless someone has explicitely looked after this, it still persits. Just my 2 Pfennige, Joerg -- Joerg B. MicheelEmail: Waikato Applied Network DynamicsPhone: +64 7 8384794 The University of Waikato, SCMS Fax: +64 7 8384155 Private Bag 3105Pager: +64 868 38222 Hamilton, New Zealand Plan: TINE and the DAG's To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999, Noriyuki Soda wrote: > > It is actually true that FreeBSD becomes Linux. > It is truely unfortunate that it comes to this.. however it has always been to me a source of great frustration to me that Linus was able to implement a driver framework that allows a very dynamic loading of modules and drivers. FreeBSD is designing the next logical step beyond this. Config.new is a stepping stone in an evolution. In our case we have pretty much all decided that the 'goal' for this next phase of evolution is the complete dynamic configuration of the kernel. The old "BSD way" was simply a step in the evolutionary chain. There is nothing inherrently 'right' about it. It reflects the limitations of the technology at that time. config.new did not change the level of the technology, but rather, re-arrange it a bit. The newconfig crew have made improvements to config.new to better support dynamic loading, but after a lot of discussions (face to face in many cases) the statements have been agreed by nearly all the FreeBSD people involved. 1/ a module that is pre-loaded should be treated the same as one that is 'post' loaded as much as possble. 2/ A module should not rely on any prior knowledge of it's existance to function correctly. 3/ A module should be able to supply it's own default configuration information, and also be able to access additional information that may be availabel at load time. 4/ The loadable module may implement an entirely new class of modules (e.g. a new bus type) of which there was no previous knowledge. 5/(not agreed by all) In a perfect world, /dev/ entries would reflect reality, and the sysctl name space would also do so. 6/ all the usual desirable aspects of loadable modules (e.g. unloadability) apply. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> This doesn't answer my wondering. The core members can safely postpone > the decision after Usenix, because all of core members must know that > both new-bus people and newconfig people will come to Freenix track. I'm not sure this was adequate reason to postpone the decision either, and like I said, Peter had the time to do it and it wasn't clear when he was next going to have the time again. In a volunteer project, you have to sometimes move when people are ready to move or you'll miss your window of opportunity. > Quite interesting. This means that FreeBSD doesn't choose technology > by it's design, but by which spokes loudly. I definitely say that this > is worst way to design software. No, it doesn't mean that, it means that assessing technology isn't JUST a question of looking at code since code, by its very nature, changes rapidly - if you cannot see that then this conversation is likely to be just about as productive as arguing with a first-year high school student on the subject. Evaluating technology is a question of deciding which code is both superior AND has the best longevity, longevity being a more difficult equation which combines the history of the developers involved and how effective your communications with them are. In this case, I don't believe communications are effective and that kills newconfig just as thoroughly as having the code be a total mess; I think I've pointed this out several times now. > Have you ever asked to newconfig people? > No, no one of core members who takes charge of kernel part contacted > to newconfig people, ever. As I told you before, I didn't even know you *existed* until I saw your paper. How am I supposed to contact you guys if I don't even know you're alive? There are presently over 5 billion people on the planet and I can't call each and every one of them regularly to find out whether or not they're working on FreeBSD. :) The time for you guys to have contacted core (or, even better, -hackers) to let us know of your existence was back when you started your project, not at the point where you were so far along that papers were being published. Don't expect people to contact YOU since, as I've said, people generally don't even know you exist until you tell them. > Note that there are core members who supports new-bus, everytime this > issue is raised between core, new-bus people can reply about this, > newconfig people never have that chance. You don't "get" chances in this business, you MAKE chances. :) > Can you write Japanese ? > If no, why do you blame the one who cannot write English. I'm very fortunate to have had my mother tongue chosen as the defacto international language of computer science and don't think I don't realize my degree of good fortune. Had Japanese or French been chosen instead, you may rest assured that I'd have put the time necessary into learning those languages as well. I'm certainly capable of learning a foreign language when and if it's necessary, don't think I'm an english bigot here or anything (sprechen Sie Deutsch? :), but I'm also a realist and if the prevailing language of communication is language X then I expect everyone concerned to just learn language X and I don't particularly care how difficult it is, Just Do It and don't whine about it is my motto. To be more specific, I expect you and anyone else in Japan who wishes to communicate with an international audience to learn english and, should I ever live in Japan and need to speak frequently with Japanese speakers, you may rest assured that I'll learn Japanese, however hard that process might be. We're supposed to be intelligent people here and if we can't learn to speak others languages if and as necessary then maybe we're not as intelligent as we think. :-) > Please point out the "general annoyance from Japan". I have seen a lot of arguing about technical merits and decisions made by the core team, but I have yet to see any constructive comments about fixing the communication problems which led to this decision. Focusing on the negative and not the positive counts for "general annoyance" in my book since people generally don't do that unless they're annoyed. I'm sure your command of english is not so deficient that you're unable to make positive suggestions - I thought Japanese people had more cultural difficulty in saying "no" than in saying "yes" :-) > Then you don't know about language barrier. > Please learn Japanese, and write/speak Japanese, then you can find why > the voice from Japan is not enough. See above. > Actually Japan is the country where FreeBSD most succeeded. > There are over 50 books in Japan which includes "FreeBSD" in it's title. > This is not joke. I know, I've been to Akihabara and I've even taken pictures of the books in question (http://www.freebsd.org/~jkh/japan/report/dayfive-books.jpg). Don't think that I underestimate the importance of the Japanese market - if I did, do you think I'd be taking time out *r
Re: panic ! panic ! panic !
On Wednesday, 12 May 1999 at 18:41:15 +0200, Gianmarco Giovannelli wrote: > At 12/05/99, you wrote: >> >> At least put DDB in your kernel, type "trace" when it >> panics and tell us what it says. > > Ok... it's a bit long ... (Tell me there isn't a command to write the trace > output on a disk :-) You should have a kernel built with the -g option, and have enabled dumps. Then you can analyse the dump at your leisure, and you'll also get more information. There's a section in the handbook about it. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
> Mike Smith scribbled this message on May 12: > > > > > > no, it's a "dangerously dedicated" SCSI disk. > > > > That's never a good start. > > well, I wonder if other people have noticed this also, but if you don't > have a previous boot loader installed (like windows/dos) the ONLY way > to install onto a machine is TO use a dangerously dedicated mode... This is quite untrue. I do a lot of installs to virgin systems on a wide range of hardware, and I haven't encountered any situations where DD has been necessary in a long time. OTOH, I have met many where DD would be fatal. > I did a couple installs using normal slices and standard MBR, and when > the machine restarted, I got the "Operating System Missing" error... > the only way I was able to install on the system was to use dangerous > dedicated mode... I've seen this happen a couple times w/ 3.0-R and > 3.1-19990328-STABLE IIRC... The determining factors here are the BIOS on your system and the geometries that you've set for them in your system's setup. If you manually match the system geometry to the BSD geometry, or your BIOS is smart enough to check the disk geometry and match it, you'll be fine. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
< said: > Have you ever asked to newconfig people? > No, no one of core members who takes charge of kernel part contacted > to newconfig people, ever. It's your responsibility to communicate with us, not the other way around. The only way for your views to be even considered is for you to make them known BEFORE the die is cast. I can't speak for any of the other developers, but I personally get 200-400 messages a day, and unless you speak up and -- most importantly -- inform everyone REGULARLY of the progess you make, your views will not be considered. > Note that there are core members who supports new-bus, everytime this > issue is raised between core, new-bus people can reply about this, > newconfig people never have that chance. The issue hasn't been raised in -core. Doug built the system, and refined it in FreeBSD/alpha with encouragement from many of us. Last November, I set up a public mailing-list, announced it to the world several times, and used it to coordinate the further development. Peter and I developed the i386 part of the mechanism long after the Alpha side was well-entrenched. Peter and Doug continue to enhance it. The only discussion -core ever had on the topic was ``ok, when should we bring this into current?''. Once those milestones were met -- about four days, as I recall -- we threw the switch. By that time, a de facto decision had long since been made, since it's a well-known principle of volunteer projects that the people who do the work (like Doug with the Alpha port) are the ones who really make the decisions, by choosing which projects to spend their time on. > We contacted to the one of core who takes charge of kernel part, and > talked all problem about new-bus, before the decision is made. There is no such person as ``the one of core who takes charge of kernel part''. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> > NetBSD people have not the same stated aim of completely eliminating > > config, so for them it made more sense to migrate to config.new. > > I think it's also safe to say that because of NetBSD's interest in > supporting 'older' hardware, it would be suicide to use a truly dynamic > scheme since much of the old hardware doesn't have the necessary > capabilities to do dynamic configuration. Yeah, like a sparcstation-1. It really can't do dynamic reconfiguration at all. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
Mike Smith scribbled this message on May 12: > > > > no, it's a "dangerously dedicated" SCSI disk. > > That's never a good start. well, I wonder if other people have noticed this also, but if you don't have a previous boot loader installed (like windows/dos) the ONLY way to install onto a machine is TO use a dangerously dedicated mode... I did a couple installs using normal slices and standard MBR, and when the machine restarted, I got the "Operating System Missing" error... the only way I was able to install on the system was to use dangerous dedicated mode... I've seen this happen a couple times w/ 3.0-R and 3.1-19990328-STABLE IIRC... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> NetBSD people have not the same stated aim of completely eliminating > config, so for them it made more sense to migrate to config.new. I think it's also safe to say that because of NetBSD's interest in supporting 'older' hardware, it would be suicide to use a truly dynamic scheme since much of the old hardware doesn't have the necessary capabilities to do dynamic configuration. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
ok, here is a reason for all this... It has benn a common thought among the FreeBSD people I have spoken too (and that's nearly all of the main developers, INCLUDING bill Jolitz) that with cheaper RAM and better organosed busses teh way to go is towards removing all static devoce information from the kernel, so that new device drivers are loaded completely dynamically. We are living in a world where NT is the competition. You do not recompile NT to add a device. Nor should you have to recompile FreeBSD to add a device. We want the distributed FreeBSD binary kernel skelaton to work with a driver that was written fro hardware that was built after the skelaton was compiled. This requires that the kernle have NO (NONE, ZIP, NADA, 0) information about the driver compiled into it. This is true as well for BUS types. If someone writes a VMEbus module it should be loadable to the kernel with no recompile, and after that all VME bus devices for which tere is a driver should be usabel once their drivers are loaded. The config.new(8) was evaluated a long time ago and rejected. Not because it was worse than config (.old) but because it was NOT SUFFICIENTLY BETTER. If we did the work to convert to config.new then that would be wasted effort, because we would then have to discard config.new and all it's changes when we got to the next step. It was decided (not officially, but effectively enough) that it would be just as easy to go directly to where we want to get from old config as from new config, so that itermediate step of config.new is wasted effort. We are planning on dicarding (mostly) config(.old) as well, but at least we have not needed to do a lot ofo work on it. NetBSD people have not the same stated aim of completely eliminating config, so for them it made more sense to migrate to config.new.
Substitute for "dumps on" specification in kernel config file
Is there an alternative way of specifying where system dumps are to go similar to the now obsolete: config kernel root on da0s1 dumps on da0s1b line? I am experiencing a panic on a recently cvsuped -current kernel and need to get a crash dump during boot (prior to dumpon being executed). Thanks, Bob -- Bob Willcox The man who follows the crowd will usually get no b...@luke.pmr.comfurther than the crowd. The man who walks alone is Austin, TX likely to find himself in places no one has ever been.-- Alan Ashley-Pitt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> > It is actually true that FreeBSD becomes Linux. > Comments like this will only ensure that you wind up in kill files, > mine included. They add nothing to the discussion. I see, sorry. -- soda To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
It seems Mike Smith wrote: > > > It is actually true that FreeBSD becomes Linux. > > This is a childish troll, especially coming from you. If for no other > reason, this is an excellent reason _not_ to be working with your team. Oh boy... Could we end this now please ?? We've made our decision, and thats it, period, end of story. -Søren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> It is actually true that FreeBSD becomes Linux. Comments like this will only ensure that you wind up in kill files, mine included. They add nothing to the discussion. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> > On Wed, 12 May 1999 15:09:05 -0700, Mike Smith said: > > > It would appear that you don't understand the problem, as no > > configuration technique can telepathically determine in advance which > > new drivers you are going to load. > > Apparently you misunderstand newconfig. :-) > There is compiled format of "files" file which path is known by > kernel. Aha. And the kernel has to read this file? How does it read it if it's loading eg. the disk driver that it will be using to read the disk? Why does the information have to be in this file? Why not put it in the drivers themselves? > >> The way on new-bus will cause compatibility problem when > >> OS is upgraded, because the implementation (filename) may > >> be changed between versions and versions. > > > This is a transient implementation issue, the obsolecesnce of which is > > already manifest in the plans that have been laid for a device > > identifier to module to file lookup with the translation data _outside_ > > the kernel. > > In other words, that is not compatible with the BSD way where FreeBSD > and BSDI and NetBSD and OpenBSD already probed. There is no "BSD way" anymore. The "BSD way" was developed to support Unibus on the early Vax systems. It's not clear to you that newbus does draw on ideas from newconfig. But newbus is a lot more than _just_ a new set of names for the probe/ configuration functions; it's a complete driver interface architecture. Newconfig is a good semi-static semi-dynamic configuration framework, but that's all it is. > It is actually true that FreeBSD becomes Linux. This is a childish troll, especially coming from you. If for no other reason, this is an excellent reason _not_ to be working with your team. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> On Wed, 12 May 1999 15:09:05 -0700, Mike Smith said: > It would appear that you don't understand the problem, as no > configuration technique can telepathically determine in advance which > new drivers you are going to load. Apparently you misunderstand newconfig. :-) There is compiled format of "files" file which path is known by kernel. >> - newconfig can cope with both static configuration and dynamic >> configuration. new-bus can handle dynamic configuration only. > This is actually a major defect in the newconfig design; if the kernel > doesn't already know about a device when it is built, it can never > support it. Apparently you misunderstand newconfig, too. :-) See above. >> The way on new-bus will cause compatibility problem when >> OS is upgraded, because the implementation (filename) may >> be changed between versions and versions. > This is a transient implementation issue, the obsolecesnce of which is > already manifest in the plans that have been laid for a device > identifier to module to file lookup with the translation data _outside_ > the kernel. In other words, that is not compatible with the BSD way where FreeBSD and BSDI and NetBSD and OpenBSD already probed. It is actually true that FreeBSD becomes Linux. -- soda To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
On Wednesday, 12 May 1999 at 15:37:40 +0200, Dag-Erling Smorgrav wrote: > I have a brand new 10 GB IBM UltrStar (DTTA-371010) which is causing > me some pains. If I boot with flags 0x80ff, everything works fine: > > wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 > wdc0: unit 0 (wd0): , 32-bit, multi-block-16 > wd0: 9641MB (19746720 sectors), 19590 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at port 0x170-0x177 irq 15 on isa0 > wdc1: unit 0 (wd2): , 32-bit, multi-block-16 > wd2: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S What chip set are you using? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: vinum broken??
On Wednesday, 12 May 1999 at 15:01:51 +0200, Christian Carstensen wrote: > > Hi, > > Does anyone else experience problems with the current kernel release > and vinum? > I've compiled a new kernel along with a make world today. After rebooting > vinum did not start: "/dev/vinum/Control: invalid operation..." > Any suggestions? I did have a glitch in vinumparser.c. Make sure you have revision 1.10 of that file. If you do (it's the latest of all revision), send me some more details of your configuration and when the error occurs. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: Someone blew up the handbook again.
>/usr/local/bin/jade -V html-manifest -ioutput.html -c /usr/doc/share/sgml/catal >og -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sg >ml/docbook/3.0/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/doc/share/ >sgml/freebsd.dsl -t sgml handbook.sgml >/usr/local/bin/jade:install/chapter.sgml:279:13:E: character data is not allowed > >Should I just turn NODOC on for the -current snapshot builds? The problem >is that I'm not getting *any* -current (or releng3, for that matter) >snapshots out at releng3.freebsd.org and current.freebsd.org because >on the days when src isn't broken, the handbook is and that kills the >builds just as effectively. :-( Handbook builds for me at freefall with no problem: % make DOC_PREFIX=/home/jesusr/cvs/doc /usr/local/bin/jade -V html-manifest -ioutput.html -c /home/jesusr/cvs/doc/shar e/sgml/catalog -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/lo cal/share/sgml/docbook/3.0/catalog -c /usr/local/share/sgml/jade/catalog -d /ho me/jesusr/cvs/doc/share/sgml/freebsd.dsl -t sgml handbook.sgml tidy -i -m -f /dev/null *.html *** Error code 1 (ignored) % JesusR. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> On Wed, 12 May 1999 14:53:31 -0700, "Jordan K. Hubbard" said: >> I agree that this is better way to solve the conflicts between new-bus >> and newconfig. Although I wondered why FreeBSD's core decide to choose >> new-bus before Usenix. > We didn't choose it "before USENIX" as if it were somehow part of the > objective to get this feature in before a public event, it simply came > up that Peter had the time to actually integrate new-bus from the > Alpha platform to the x86 This doesn't answer my wondering. The core members can safely postpone the decision after Usenix, because all of core members must know that both new-bus people and newconfig people will come to Freenix track. Who is the chair of Freeunix track ? :-) > Whether new-bus or newconfig is "better" was really, honestly not > the issue so much as were the following two bullet points: Quite interesting. This means that FreeBSD doesn't choose technology by it's design, but by which spokes loudly. I definitely say that this is worst way to design software. > 1. Does this bring the alpha and x86 architecture ports into better >alignment so that any future permutations can be more easily >brought across and/or simply shared between the two platforms? BSD/OS, NetBSD and OpenBSD are all based on newconfig on various architectures. FreeBSD/alpha is directly derived from NetBSD/alpha and NetBSD/alpha is based on newconfig. And at the time when the decision is made, FreeBSD/i386 and FreeBSD/pc98 are already converted to newconfig. So this is definitely is not the reason. > 2. Have we had a good history of communications between the people >doing new-bus vs our history of communication with the newconfig >people? Have you ever asked to newconfig people? No, no one of core members who takes charge of kernel part contacted to newconfig people, ever. Only one communication is held between one of core members who is actually new-bus one, and newconfig people. And this is requested by newconfig people, not by one of core members. Note that there are core members who supports new-bus, everytime this issue is raised between core, new-bus people can reply about this, newconfig people never have that chance. If you'll make offical decision, always you can call both people, and can hear both opinion. But this is never done. > The latter point is actually *really important* since we've already > learned that having totally separate groups who talk to us maybe once > a month (if even that often) is just not a workable strategy for the > long term and often causes more confusion for our users than it > actually helps the project. > We talk to Doug Rabson on a practically daily basis on a wide > variety of issues whereas the only real communication I've seen from > you has been during this conflict. And did you call one of the newconfig people? No. The contact address of newconfig people is already publically announced, but no one of core who takes charge of kernel part contacted to the address. We contacted to the one of core who takes charge of kernel part, and talked all problem about new-bus, before the decision is made. So, which does effort of communication ? > Before that, I had no idea that a Noriyuki Soda even existed. :-) Actually I am not a FreeBSD person, but one of observers of newconfig project. Some of you does know that my name is listed in NetBSD contributer's list. Although I send-pr'ed to FreeBSD sometimes. This is the reason I never posted to this mailing list. The reason I posted now is I am disgusted in FUD about technical points of newconfig. (I don't really care non technical points.) All of core should know about the benefit of the newconfig, because we already talked about it to one of the core when the decision is made. The reason why real newconfig people doesn't appears here is that there is language barrier. How did you think about Nakagawa-san's English? Do you know the pain about writing English when he knows his English is actually quite broken? (Yes, my English is broken, too. But probably I am a person who don't know what is disgrace. This is rare character and not thought good in Japan.) Can you write Japanese ? If no, why do you blame the one who cannot write English. Actually they will write English, if one of the core asked it. But no one of core request it, ever. So why no one never stops the FUD like the later postings ? > To try and put it another way, I've seen a lot of arguing about the > technical merits of the two systems but very little arguing about how > to solve the HUMAN FACTORS aspect of this situation which are really > and truly what led up to the core team's decision. I've also called > for greater communication between the two groups and so far all I've > seen is a lot of arguing and expressions of general annoyance from > Japan - that is NOT communication! Please point out the "general annoyance from Japan". If you read it carefully, you can find the
Re: cvs commit: src/sys/pci pcisupport.c
> Mike Smith once wrote: > > > For a usable dynamic architecture, loadable modules need to be > > compiled to support both UP and SMP architectures simultaneously. Thus > > the locking primitives need to be conditionalised at _runtime_. > > What about > > kldload /modules/up/whatever.ko > and > kldload /modules/smp/whatever.ko > > and even > > kldload /debug-modules/up/whatever.ko > [...] This is just too painful for words. If people _really_ want to do this, you'd put all of the drivers into one .ko file and only partially link it (ie. just link the one module). But I do not think we want this at all; the obvious selectors so far are: - UP vs. SMP - BPF - Invariants That's eight versions of eg. a network driver already. I cut off BPF as an issue a little while back by putting stubs for the BPF routines into the kernel when BPF isn't actually built; we want to do the same things for the other functionality types. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mikael Karpberg wrote: > According to Mike Smith: > > This is actually a major defect in the newconfig design; if the kernel > > doesn't already know about a device when it is built, it can never > > support it. > > That would be so lovely, with a DEVFS too: > > Plug your Cool card into your pcmcia slot, and get the message on > the sytem console that an unknown pcmcia card called "Cool", made > by CoolMakers, Inc. Damn... not even a generic driver wanted this card. > Pull the card out and go for the web: > > # ftp ftp.a.cool.thing.com > ftp> get cool.tgz > --> Downloading file. > ftp> quit > --> Good bye. > # install_driver cool.tgz > --> Adding driver to driver database, and installing /modules/cool.ko! > > And at this point the kernel has not loaded the driver, but just > been told there's a new driver around and for what cards and vendors > it works, etc. This is done by a library call, or something, which > does adds the driver to the database, and a syscall to update the > kernel's already loaded database, or to get it to reload the database. > > Plug the card in again, and the kernel loads in cool.ko and probes the > card, and created a /dev/cool, and everything works just fine. No reboot, > no recompile, nada. *purr* This is exactly the way new-bus works. You merely load the driver, and the configuration engine reruns the probe for unclaimed devices on smart busses automatically. Of course, kicking off a generic driver when a more specific driver is loaded is a different problem... I have not looked to see if this is supported. It should not be a significant problem if it is not yet implemented. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mike Smith once wrote: > For a usable dynamic architecture, loadable modules need to be > compiled to support both UP and SMP architectures simultaneously. Thus > the locking primitives need to be conditionalised at _runtime_. What about kldload /modules/up/whatever.ko and kldload /modules/smp/whatever.ko and even kldload /debug-modules/up/whatever.ko [...] -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
According to Mike Smith: > This is actually a major defect in the newconfig design; if the kernel > doesn't already know about a device when it is built, it can never > support it. That would be so lovely, with a DEVFS too: Plug your Cool card into your pcmcia slot, and get the message on the sytem console that an unknown pcmcia card called "Cool", made by CoolMakers, Inc. Damn... not even a generic driver wanted this card. Pull the card out and go for the web: # ftp ftp.a.cool.thing.com ftp> get cool.tgz --> Downloading file. ftp> quit --> Good bye. # install_driver cool.tgz --> Adding driver to driver database, and installing /modules/cool.ko! And at this point the kernel has not loaded the driver, but just been told there's a new driver around and for what cards and vendors it works, etc. This is done by a library call, or something, which does adds the driver to the database, and a syscall to update the kernel's already loaded database, or to get it to reload the database. Plug the card in again, and the kernel loads in cool.ko and probes the card, and created a /dev/cool, and everything works just fine. No reboot, no recompile, nada. *purr* /Mikael To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> > Why should we, as a 3rd millenium OS need a static config tool ? > > For example, > > - To specify the drivers which is linked statically to kernel. > As I said earlier, you cannot link console driver dynamically, > If you do this, you cannot get error message when dynamic > linking of the console driver failed. This presumes you don't have a fallback console driver. If you look at the current console driver architecture, you'll see that it's not too difficult to do this, nor would it be too difficult to componentise the various console driver components and simply link-time aggregate them. > - There should be a way to inform kernel about inter module dependency > dynamically. config(8) converts this information to a file which is > kernel readable format. This is _the_ fundamental defect (as opposed to merely shortcoming) with newconfig. If I want to use a vendor-supplied driver module, I must first generate a kernel that knows about it. This is not "dynamic" by any definition of the word. KLD should (but does not, yet) obtain this information from the module as it is loaded. This is not a flaw in the KLD design, only its implementation. > - There should be a way to inform kernel about mapping from device > name to driver filename dynamically. config(8) converts this > information to a file which is kernel readable format. This is a task for a PnP ID:module mapping database. See eg. sys/boot/common/pnpdata. It should most definitely _not_ be inside the kernel. > - To achieve better performance in both UP and SMP cases. > Proper SMP implementation requires fine grained locking, though this > increases performance penalty in UP case. (e.g. Solaris shows this > problem.) Thus, the way to specify "options SMP" is needed to use > (static) source level and compiler level optimization. > This option should automatically select the appropriate sources > which is compiled into kernel, according to the source is needed > only in UP case, or only in SMP case, or both. This is what > oldconfig and newconfig does. This is, again, defective reasoning. For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Noriyuki Soda wrote: > NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing > list, because I am a NetBSD user. :-) Aha! Now a few things are starting to make sense... > > > It depends on old-config, so poor mechanism. newconfig already > > > implimented best match probe/attach. > > > > And a very useful mechanism it is. Which is why I implemented priority > > ordered probes in -current. > > Hmm, I thought this cannot be done correctly on new-bus, because > the new-bus kicks match/attach routine from SYSINIT(). It is apparent This has *never* been the case. All that the SYSINIT() system is used for is *registering* the drivers with the configuration engine. The actual configuration happens much later, in the i386 case the initial configuration is run from root_bus_configure() in i386/autoconf.c. > that this fails in dynamic configuration case, because a potencial > candidate of drivers which is dynamically loaded first always matches. > This behaviour can not be called as "best match", but "first match". :-) > Of course, dynamic configuration of newconfig solves this problem. > > Was this behaviour of the new-bus changed in -current ? Yes. Originally, the new-bus routines, apon finding a device, would "offer" it to the child drivers one at a time, and the first one that succeeded it's probe would then have it allocated to it. Now it uses a priority mechanism and the best-match driver wins. > BTW, there are many fundamental design flaws in new-bus, so I don't > think new-bus is comparable with newconfig, yet, even if priority > probe is implemented. For example: > > - newconfig can cope with both static configuration and dynamic > configuration. new-bus can handle dynamic configuration only. > > This is because critical information for configuration is > represented in C source internally. e.g. The bus/device > hierarchy information is embedded in DRIVER_MODULE() on > new-bus. > On newconfig, such information is represented externally > in "files" file. Thus the information can be used in > both static and dynamic configuration case. > As a result, newconfig can support same configuration > syntax in both static and dynamic configuration, > the new-bus never can do it. Obviously there is some confusion over terminology or some misunderstanding somewhere, because we have been through this what seems like at least half a dozen times in private mail, and got nowhere at all. It seems to me that the basic difference is: We do not *want* static hardcoded configuration to be compiled into the kernel if at all possible. That requires kernel recompiles to simply change things like a port number for a ne2000 clone card. At the moment, our interim code means that things like 'ed0 goes at port 0x300, irq 11' etc is compiled in via the hints table, but we want that moved out into /boot/isa.conf or something like that ASAP and have loader(8) preload it for the kernel. That means that changing the configuration of a statically compiled kernel does not require a recompile or reconfigure. Most (but not all) of the mechanisms are in place to have this done totally dynamically from loader. For example, if you put this in your kernel config file: device ed0 in -current, you can then add this to /boot/userconfig_script: port ed0 0x300 irq ed0 11 iomem ed0 0xd .. and when the kernel boots, it will probe for ed0 on the isa bus, as well as attach to pci devices. (I have not actually tried this, I do not expect problems though). Abusing userconfig for this is a bit horrible though and is limited in it's capabilities. Everything else is in 4.0-current dynamic. Yes, there are weaknesses still, but that is because it isn't quite finished and is evolving still. As an example, it is not possible to hardwire (for example) de4 on some particular pci slot. This is an implementation problem, not a design problem. isa uses the mechanism already, and pci could too if anybody wanted it enough to write a handful of lines of code. > - new-bus cannot support on-demand device driver loading, > dynamic configuration for newconfig can do it, though. > > This is because new-bus doesn't have the way to represent meta > information like a mapping from device name to driver filename. > If new-bus have this, there is no need to specifiy > "kldload if_fxp", but just say "I need fxp0", then configuration > framework can automatically load fxp driver, if it is not > loaded yet. This is how configuration works in both newconfig > and even oldconfig (look at static kernel configuration file > for oldconfig, there is the line "device fxp0" which demands > fxp driver to be loaded). File names shouldn't be in the kernel. You should not have to precompile a kernel to know that 'if_fxp' is loadable for some pci device id.. how can you do this with a 3rd par
Re: problem with dev_t changes and pageout..
now now :-) On Wed, 12 May 1999, Matthew Dillon wrote: > Maybe whoever committed the supposedly innocuous dev_t changes should > back it out. > > Just a thought. > > -Matt > Matthew Dillon > > : > :It looks like something has come unstuck: > : > :Fatal trap 12: page fault while in kernel mode > :mp_lock = 0002; cpuid = 0; lapic.id = > :fault virtual address = 0x28 > :fault code = supervisor read, page not present > :instruction pointer = 0x8:0xc017bb67 > :stack pointer = 0x10:0xc5d97de4 > :frame pointer = 0x10:0xc5d97df0 > :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 = 2 (pagedaemon) > :interrupt mask = net bio cam <- SMP: XXX > :kernel: type 12 trap, code=0 > :Stopped at spec_strategy+0x93: movl0x28(%edx),%eax > : ^^^ %edx = null > :db> trace > :spec_strategy(c5d97e1c) at spec_strategy+0x93 > :swap_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at > swap_pager_putpages+0x3e1 > :default_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at > default_pager_putpages+0x17 > :vm_pageout_flush(c5d97ecc,2,0,c5d97eb0,c02182cf) at vm_pageout_flush+0x91 > :vm_pageout_clean(c04d6b60,8000,c013e290,2000,c5d97f78) at > vm_pageout_clean+0x1f1 > :vm_pageout_scan(8000,c02789c0,c02789c0,c5d97fac,c013e2c3) at > vm_pageout_scan+0x45e > :vm_pageout(c5d8fdf7,c0255500,c02789c0,c020c640,c020c748) at vm_pageout+0x221 > :kproc_start(c02789c0) at kproc_start+0x33 > :fork_trampoline(10b8a0,d88e,18b8c08e,8e00,24448be0) at > fork_trampoline+0x30 > :db> ps > : pid proc addruid ppid pgrp flag stat wmesg wchan cmd > : 438 c680da40 c6818000 495 282 277 04 3 biord c332d9c0 p4d > : 437 c5d8c340 c6802000 433 417 415 004084 3 piperd c6760660 tee > : 436 c680dd00 c681 433 417 415 004004 3 biord c33626f8 p4 > : 418 c680dba0 c6815000 433 415 415 004084 3 piperd c6760700 mail > : 417 c680de60 c680e000 433 415 415 004084 3wait c680de60 sh > :[..] > : > :The offending line in spec_strategy is: > :(*bdevsw(bp->b_dev)->d_strategy)(bp); > : > :d_strategy was null.. I'm still looking. > : > :(I think this is the first time the box paged out since booting a few hours > :ago, it's got 128M, but p4d has got a lot of stuff to deal with and can hit > :a vsize of 70MB or so.) > : > :Cheers, > :-Peter > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing > list, because I am a NetBSD user. :-) > > > > It depends on old-config, so poor mechanism. newconfig already > > > implimented best match probe/attach. > > > > And a very useful mechanism it is. Which is why I implemented priority > > ordered probes in -current. > > Hmm, I thought this cannot be done correctly on new-bus, because > the new-bus kicks match/attach routine from SYSINIT(). It is apparent > that this fails in dynamic configuration case, because a potencial > candidate of drivers which is dynamically loaded first always matches. > This behaviour can not be called as "best match", but "first match". :-) > Of course, dynamic configuration of newconfig solves this problem. It would appear that you don't understand the problem, as no configuration technique can telepathically determine in advance which new drivers you are going to load. > BTW, there are many fundamental design flaws in new-bus, so I don't > think new-bus is comparable with newconfig, yet, even if priority > probe is implemented. For example: > > - newconfig can cope with both static configuration and dynamic > configuration. new-bus can handle dynamic configuration only. > > This is because critical information for configuration is > represented in C source internally. e.g. The bus/device > hierarchy information is embedded in DRIVER_MODULE() on > new-bus. > On newconfig, such information is represented externally > in "files" file. Thus the information can be used in > both static and dynamic configuration case. > As a result, newconfig can support same configuration > syntax in both static and dynamic configuration, > the new-bus never can do it. This is actually a major defect in the newconfig design; if the kernel doesn't already know about a device when it is built, it can never support it. > The way on new-bus will cause compatibility problem when > OS is upgraded, because the implementation (filename) may > be changed between versions and versions. This is a transient implementation issue, the obsolecesnce of which is already manifest in the plans that have been laid for a device identifier to module to file lookup with the translation data _outside_ the kernel. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: the new config and booting
> > no, it's a "dangerously dedicated" SCSI disk. That's never a good start. > the loader shows the floppy as DISK A and the SCSI disk as DISK B. Are you sure it lists the SCSI disk as B and not C? If it's showing up as B your BIOS is doing funny stuff. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
> Pardon, but I am not be able to figure by myself what you asked to me... > If you can explain me step by step in a newbie way I can do everything ... > The crashes is easily reproducible... No offense, but are you sure you should even be running -current? A certain amount of skill in doing such diagnosis is generally considered mandatory for people running it, even though many people who shouldn't be doing so for that reason still do it. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> I agree that this is better way to solve the conflicts between new-bus > and newconfig. Although I wondered why FreeBSD's core decide to choose > new-bus before Usenix. We didn't choose it "before USENIX" as if it were somehow part of the objective to get this feature in before a public event, it simply came up that Peter had the time to actually integrate new-bus from the Alpha platform to the x86 and it was deemed desirable to have the SAME bus configuration code for both architectures. I don't see how any engineer in his right mind could argue that it made sense to have two, active and shipping ports to different architectures, each with its own bus code. Whether new-bus or newconfig is "better" was really, honestly not the issue so much as were the following two bullet points: 1. Does this bring the alpha and x86 architecture ports into better alignment so that any future permutations can be more easily brought across and/or simply shared between the two platforms? 2. Have we had a good history of communications between the people doing new-bus vs our history of communication with the newconfig people? The latter point is actually *really important* since we've already learned that having totally separate groups who talk to us maybe once a month (if even that often) is just not a workable strategy for the long term and often causes more confusion for our users than it actually helps the project. We talk to Doug Rabson on a practically daily basis on a wide variety of issues whereas the only real communication I've seen from you has been during this conflict. Before that, I had no idea that a Noriyuki Soda even existed. :-) This project essentially lives and dies by the strength of its "ties" to various developers. Given the fact that one body of code came from someone whom I *knew* we could work with, given a long history of working with them, and the other body of code came from someone who really only became known to myself and the rest of core when we saw your paper submission for USENIX (which I'm looking forward to attending, as I'm sure are many others in this discussion), well, it really wasn't a hard decision to make at all. Given the same set of factors, we'd make the very same decision today. To try and put it another way, I've seen a lot of arguing about the technical merits of the two systems but very little arguing about how to solve the HUMAN FACTORS aspect of this situation which are really and truly what led up to the core team's decision. I've also called for greater communication between the two groups and so far all I've seen is a lot of arguing and expressions of general annoyance from Japan - that is NOT communication! Proper communication involves regular discussion about incremental improvements to the code base and how best to carry them out, biting off problems in small chunks and dealing with each completely before moving on to the next. Simply wandering off with the entire problem for 6 months and working on it in isolation DOES NOT WORK and we've proven this again and again. It only leads precisely to the situation we have here now with newconfig and also PAO. To put the problem in a larger context, people often ask me what all the FreeBSD people in Japan are working on and it's a point of eternal embarassment to me that I usually have to say "I honestly have no idea." Many of the various developers in Japan really don't go much out of their way to let me or core in general know what's going on (though there are some notable exceptions) and it's like working in a company where a major part of it is entirely off-site and never calls you on the phone; anyone who's actually worked in such an environment knows exactly what I'm talking about and can appreciate the frustration of not knowing what a good chunk of your organization is up to. We really really really need to fix this if we're to avoid further repetitions of this kind of thing and that's why I'm flying to Tokyo at the end of this month to talk with you guys - we're clearly not communicating adequately and I'm willing to do what I can, including physically relocating myself on a periodic basis, to fix it from this side. What are you doing to fix it on yours? :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
In message <65947.926544...@zippy.cdrom.com>, "Jordan K. Hubbard" writes: >> Try disabling "ultra DMA" in the BIOS, that seems to have worked for >> me on my IBM-DJNA-371800 drive. >> >> (Jordan: We may want to put something in the README about this in 3.2!) > >I'd welcome suggestions as to what the text should look like; I'm >still unclear as to what exactly the problem us. :) So am I. I think the problem is that the wd.c based DMA stuff doesn't support ultra-DMA, and unless you tell your BIOS to no do ultra-DMA it will barf up a printf for each transfer to the device. How to write things like this in a README file has repeatedly been proven to be beyond my capabilities. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message <199905122048.qaa72...@misha.cisco.com>, Mikhail Teterin writes: >Or, the core team may just say: "Because we said so" (which I think was >already done once) and stop discussing this... We did I think. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: problem with dev_t changes and pageout..
Maybe everybody should read to the end of their mailboxes before they come forward with baseless and unfounded snide remarks. And I never said they were "innocuous". This is Current mind you. Poul-Henning In message <199905122048.naa88...@apollo.backplane.com>, Matthew Dillon writes: >Maybe whoever committed the supposedly innocuous dev_t changes should >back it out. > >Just a thought. > > -Matt > Matthew Dillon > >: >:It looks like something has come unstuck: >: >:Fatal trap 12: page fault while in kernel mode >:mp_lock = 0002; cpuid = 0; lapic.id = >:fault virtual address = 0x28 >:fault code = supervisor read, page not present >:instruction pointer = 0x8:0xc017bb67 >:stack pointer = 0x10:0xc5d97de4 >:frame pointer = 0x10:0xc5d97df0 >: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 = 2 (pagedaemon) >:interrupt mask = net bio cam <- SMP: XXX >:kernel: type 12 trap, code=0 >:Stopped at spec_strategy+0x93: movl0x28(%edx),%eax >: ^^^ %edx = null >:db> trace >:spec_strategy(c5d97e1c) at spec_strategy+0x93 >:swap_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at >swap_pager_putpages+0x3e1 >:default_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at >default_pager_putpages+0x17 >:vm_pageout_flush(c5d97ecc,2,0,c5d97eb0,c02182cf) at vm_pageout_flush+0x91 >:vm_pageout_clean(c04d6b60,8000,c013e290,2000,c5d97f78) at >vm_pageout_clean+0x1f1 >:vm_pageout_scan(8000,c02789c0,c02789c0,c5d97fac,c013e2c3) at >vm_pageout_scan+0x45e >:vm_pageout(c5d8fdf7,c0255500,c02789c0,c020c640,c020c748) at vm_pageout+0x221 >:kproc_start(c02789c0) at kproc_start+0x33 >:fork_trampoline(10b8a0,d88e,18b8c08e,8e00,24448be0) at >fork_trampoline+0x30 >:db> ps >: pid proc addruid ppid pgrp flag stat wmesg wchan cmd >: 438 c680da40 c6818000 495 282 277 04 3 biord c332d9c0 p4d >: 437 c5d8c340 c6802000 433 417 415 004084 3 piperd c6760660 tee >: 436 c680dd00 c681 433 417 415 004004 3 biord c33626f8 p4 >: 418 c680dba0 c6815000 433 415 415 004084 3 piperd c6760700 mail >: 417 c680de60 c680e000 433 415 415 004084 3wait c680de60 sh >:[..] >: >:The offending line in spec_strategy is: >:(*bdevsw(bp->b_dev)->d_strategy)(bp); >: >:d_strategy was null.. I'm still looking. >: >:(I think this is the first time the box paged out since booting a few hours >:ago, it's got 128M, but p4d has got a lot of stuff to deal with and can hit >:a vsize of 70MB or so.) >: >:Cheers, >:-Peter > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: DMA problems with IBM DeskStar drive
> Try disabling "ultra DMA" in the BIOS, that seems to have worked for > me on my IBM-DJNA-371800 drive. > > (Jordan: We may want to put something in the README about this in 3.2!) I'd welcome suggestions as to what the text should look like; I'm still unclear as to what exactly the problem us. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
MS is trying desperatly to fight off and contained Linux and I am not sure that Microsoft will succeed -- Amancio Hasty ha...@star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
Ustimenko Semen wrote: >On Tue, 11 May 1999, Luigi Rizzo wrote: ... >> http://research.microsoft.com/programs/NTSrcLicInfo.htm >> >> Microsoft makes Windows NT source code available to universities >> and other "not-for-profit" research institutions at no charge. ... >P.S. What's happening with MS? Could be that someone at M$ has been studying the history of Unix. I'm not sure it'll work though - NT is somewhat more complex (and presumably more difficult to understand) than Sixth Edition Unix. Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mikhail Teterin says: : : Perhaps, the newbus vs. newconfig discussion can be summarized to both : sides' satisfaction offline and then presented to the rest of the world? But didn't this already happen. I seem to recall a round of discussions that went on a week before the new-bus switch. The entire discussion ran around in circles with both sides discussing the technical merits of their implementation and both sides pointing out the problems in the other's implementation. Check the archives for the all the messages. My personal opinion? Well, I've been looking at the newconfig stuff and I think that they weakened their cause by not following -current. I've been trying the stuff out since they announced. But it does me no good to try and use it if it's out of sync with userland. Hey, I don't feel like looking at "proc size mismatch" messages. 8) I think the real shame is that both sides have good ideas and a lot of the newconfig stuff could work with newbus. However, instead of pooling our resources we've divided them and drawn a line in the sand. And I can't say that I personally feel that all of the questioning e-mails that have been going around the past day make me any more sympathetic to the newconfig cause. Core made a decision. Let's follow it. And before anyone throws any of that "it's not traditional" stuff out, please remember that no other BSD is using a boot loader like ours, NetBSD dropped Mach-VM for UVM, etc, etc, etc... My real fear is that this causes a rift which will lead to a split like the Net/OpenBSD one. At that point, both sides lose. --Jerry name: Jerry Alexandratos || Open-Source software isn't a phone: 302.521.1018 || matter of life or death... email: jalex...@perspectives.net || ...It's much more important || than that! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> On Wed, 12 May 1999 12:12:54 -0700 (PDT), Julian Elischer said: > The eventual aim is to have a kernel which is a very sparse skelaton, > with very few services and drivers loaded (in fact possibly none). This is also aim of newconfig, although console driver should be linked statically at least. Also, newconfig is aiming to provide freedom to choose whether a driver is linked dynamically or statically. > At boot time, the needed drivers and services are loaded and configured > (by the loader possibly). A driver that is already linked in is treated > exactly as if it had been loaded, except that the loading is not > required.. In this view, a statically linked in module is really just a > 'pre-loaded' module. it still needs to be initialised. Yes. This is what newconfig on dynamic configuration does. But SYSINIT() of drivers is NOP in newconfig. Configuration framework does know all necessary operation to do, thus, there is nothing to do in SYSINIT(). Note that this is one of the key points to achieve best match policy for driver selection. > In this view, config(8) is reduced to being used to specify the preloaded > modules (though that may be done after compilation by an external > linker/loader) and to specify debugging options. A utility could exist > that takes a skelaton kernel, and a specified list of kld modules and > creates a composite loadable kernel, in which some modules are already > present. These modules should be specified by device name, or by feature name (i.e. attributes), oldconfig and newconfig use this model. But new-bus doesn't. It doesn't use device name and doesn't have the feature like the attributes of old/newconfig. It merely uses modules' filenames to specify modules which should be linked. This is one of the points what I think the new-bus is wrong. All configuration information should be specified by specification (device names and attribute names), not implementation (module filename). This is critical point to achieve on-demand dynamic loading and better compatibility. > I will admit that I have only looked a small amount at the new config that > NetBSD uses, but it seemed to me that it produced far too much static > information. IMHO, that's wrong. What newconfig produces is only what really needed. If you think there is unnecessary information, probably it means that you don't really understand the usage of the information, yet. > This infrastucture would be duplicated by a dynamic loading framework. This is wrong. The newconfig uses same information and same framework on both static and dynamic configuration. There is no duplication. > why have two such frameworks? No. The newconfig is unified framework for both static and dynamic configuration. If a driver is static configurated, it's "struct cfdata" is generated by config(8), and it will be parsed by configuration framework (kern/subr_autconf.c). If a driver is dynamically configured, then kernel generated "struct cfdata" is used instead. Thus, there is no duplicated information between static and dynamic configuration in newconfig. Both configurations use same "struct cfdata". The only difference is whether the generator of "struct cfdata" is config(8) or kernel. Do you call this duplication? Then you might not really understand what the configuration is, yet. Only config(8) reads "files" file (i.e. meta information) and it converts the information to binary format for kernel. So, there is no duplication about meta information parser. Yes, there is duplication about parser of configuration hint. But if you imagined that there is no need to implement the parser of configuration hint on userland. Then that's completely wrong. If config(8) doesn't have the parser of configuration hint, then you cannot determine which modules should be linked statically. The reason why new-bus doesn't have this duplication is new-bus doesn't have static configuration ability and it depends on oldconfig about static configuration. Actually, the one which has two framework is not newconfig, but new-bus. New-bus have it's own configuration framework for dynamic configuration and depends on oldconfig framework for static configuration. These frameworks are completely different, and as soon as you'd like to remove oldconfig, real problem of new-bus appears. As I said earlier, eventually new-bus will have to choose one of the following ways: [a] gives up static configuration. [b] uses ugly kluge (e.g. oldconfig remains forever). [c] reinvents features which already implemented on the newconfig. I'm not sure which is the way of the new-bus, in this point, though. > If newconfig has removed all static device framework from the kernel then > it is going the way I envision things moving. If it still does what the > NetBSD one did when I looked at it, and produces a statically compiled > framework of child devices and parent nodes, then that is one of the > things we are trying to get away from. This i
Re: Someone blew up the handbook again.
"Jordan K. Hubbard" wrote: > Should I just turn NODOC on for the -current snapshot builds? The problem > is that I'm not getting *any* -current (or releng3, for that matter) > snapshots out at releng3.freebsd.org and current.freebsd.org because > on the days when src isn't broken, the handbook is and that kills the > builds just as effectively. :-( Freeze the bastard as well :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Dag-Erling Smorgrav once wrote: As an outside observer, who does not understand most (all?) of the differences involved, I must say, this will have to be an unfairly "uphill" explanation. Because, using the style exemplified by PHK today, the newconfig people could say something like: > Then explain to us why newbus is wrong * newbus is too far in the future and too dynamic (as opposed to PHK's statement, the (new)config is too old and too static -- no details) > and why the 4.4BSD scheme is right. * newconfig(8) (as opposed to PHK's ``config(8)'') "We want the FreeBSD to keep the stability and ... it has today". I'm not arguing with PHK here (nor anyone else), I'm just saying the brevity is not always a virtue... And for me, who reads -current mostly to keep the grip on the FreeBSD's directions and currents (hey!), this brief responses are NOT informative at all. Should they be? I'm not sure, but usually people taking a stand try to make themselves clear to all/most of the audience... Another mailing came through today was a lot more informative, though... Perhaps, the newbus vs. newconfig discussion can be summarized to both sides' satisfaction offline and then presented to the rest of the world? Or, the core team may just say: "Because we said so" (which I think was already done once) and stop discussing this... Respectfully, -mi To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: problem with dev_t changes and pageout..
Maybe whoever committed the supposedly innocuous dev_t changes should back it out. Just a thought. -Matt Matthew Dillon : :It looks like something has come unstuck: : :Fatal trap 12: page fault while in kernel mode :mp_lock = 0002; cpuid = 0; lapic.id = :fault virtual address = 0x28 :fault code = supervisor read, page not present :instruction pointer = 0x8:0xc017bb67 :stack pointer = 0x10:0xc5d97de4 :frame pointer = 0x10:0xc5d97df0 :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 = 2 (pagedaemon) :interrupt mask = net bio cam <- SMP: XXX :kernel: type 12 trap, code=0 :Stopped at spec_strategy+0x93: movl0x28(%edx),%eax : ^^^ %edx = null :db> trace :spec_strategy(c5d97e1c) at spec_strategy+0x93 :swap_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at swap_pager_putpages+0x3e1 :default_pager_putpages(c02904fc,c5d97ecc,2,0,c5d97e60) at default_pager_putpages+0x17 :vm_pageout_flush(c5d97ecc,2,0,c5d97eb0,c02182cf) at vm_pageout_flush+0x91 :vm_pageout_clean(c04d6b60,8000,c013e290,2000,c5d97f78) at vm_pageout_clean+0x1f1 :vm_pageout_scan(8000,c02789c0,c02789c0,c5d97fac,c013e2c3) at vm_pageout_scan+0x45e :vm_pageout(c5d8fdf7,c0255500,c02789c0,c020c640,c020c748) at vm_pageout+0x221 :kproc_start(c02789c0) at kproc_start+0x33 :fork_trampoline(10b8a0,d88e,18b8c08e,8e00,24448be0) at fork_trampoline+0x30 :db> ps : pid proc addruid ppid pgrp flag stat wmesg wchan cmd : 438 c680da40 c6818000 495 282 277 04 3 biord c332d9c0 p4d : 437 c5d8c340 c6802000 433 417 415 004084 3 piperd c6760660 tee : 436 c680dd00 c681 433 417 415 004004 3 biord c33626f8 p4 : 418 c680dba0 c6815000 433 415 415 004084 3 piperd c6760700 mail : 417 c680de60 c680e000 433 415 415 004084 3wait c680de60 sh :[..] : :The offending line in spec_strategy is: :(*bdevsw(bp->b_dev)->d_strategy)(bp); : :d_strategy was null.. I'm still looking. : :(I think this is the first time the box paged out since booting a few hours :ago, it's got 128M, but p4d has got a lot of stuff to deal with and can hit :a vsize of 70MB or so.) : :Cheers, :-Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Someone blew up the handbook again.
/usr/local/bin/jade -V html-manifest -ioutput.html -c /usr/doc/share/sgml/catal og -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sg ml/docbook/3.0/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/doc/share/ sgml/freebsd.dsl -t sgml handbook.sgml /usr/local/bin/jade:install/chapter.sgml:279:13:E: character data is not allowed Should I just turn NODOC on for the -current snapshot builds? The problem is that I'm not getting *any* -current (or releng3, for that matter) snapshots out at releng3.freebsd.org and current.freebsd.org because on the days when src isn't broken, the handbook is and that kills the builds just as effectively. :-( - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
> Wilko Bulte wrote:
> > PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl
> > Writing Makefile for DynaLoader
> > ==> Your Makefile has been rebuilt. <==
> > ==> Please rerun the make command. <==
> > false
> > false: not found
> > *** Error code 1
>
> I periodically see this one reported, and It is always repaired
> by the reporter making sure their tree is _really_ clean before
> doing a make world. "Really clean" means "make cleandir" _twice_,
This indicates to me, the original author of ``cleandir'', that
something has broken the functionality that it had. This something
is more than likely the removal of code similiar to:
cd /usr/obj/{.CURDIR}; chflags -R noschg tmp; rm -rf *;
before the equiv of:
cd {.CURDIR}; ${make} clean
> and complete removal of the contents of /usr/obj. _Then_ cvsup.
> I prefer to usr CVS checkout, as it shows all the differences and
> other turds in my source tree.
If ``make cleandir'' is leaving some cruft in any form behind anyplace
in the build tree things are broken.
--
Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com
Accurate Automation, Inc. Reliable computers for FreeBSD
http://www.aai.dnsmgr.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
:I think we need to think a bit more about the right semantics before :making such a change. M_WAIT is supposed to mean `I am in process :context and don't mind sleeping in order to get an mbuf, but there is :too much locking going on inside the network stack to be able to :safely sleep without serious risk of deadlock. : :This is the sort of application which would be ideal for Matt's :`asleep' interface. Then, the code could back its way out of any :locks and spls, safely wait for sufficient mbufs to be freed, and then :retry. Even then, it's still possible to deadlock if one process hogs :the entire mbuf pool. It may be necessary to incrementally penalize :processes which do so. : :FWIW, the 4.3 code sleeps in a loop. : :-GAWollman Doing something like this is exactly what was intented for asleep(). The code is not entirely complete, though. Basically the idea is to use asleep() in situations where the system might block but does not normally block in order to avoid both deadlocks and unnecessary code serialization ( due to holding a lock through a blocking situation ). This becomes critically important in SMP models where most of the locks you hold are spinlocks rather then scheduler locks. asleep() allows a subroutine deep in the call stack to specify an asynchronous blocking condition and then return a temporary failure up through the ranks. At the top level, the scheduler sees and acts upon the asynchronous blocking condition. Higher level routines do not need to understand what condition is being blocked on, only that there is some condition being blocked on. With the current model, higher level routines have to assume that lower level routines may block which complicates matters greatly. -Matt Matthew Dillon :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same :woll...@lcs.mit.edu | O Siem / The fires of freedom :Opinions not those of| Dance in the burning flame :MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick : : :To Unsubscribe: send mail to majord...@freebsd.org :with "unsubscribe freebsd-current" in the body of the message : To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Sometimes again SCSI don't finish to boot
As Gianmarco Giovannelli wrote ... > > In 4.0-current sometimes the box will froze again after the : > "Waiting 3 seconds for SCSI devices to settle" > then nothing happens. > It was a thing happened also in early 1999, before the branch in > 4.0-current and 3.1 stable, if I remember well. > > Any others experience such behaviour ? > Here is again (part of) my infos: > > FreeBSD 4.0-CURRENT #0: Wed May 12 13:03:16 CEST 1999 > r...@gmarco.eclipse.org:/usr/src/sys/compile/GMARCO > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 400911064 Hz > CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x651 Stepping=1 > Features=0x183f9ff PAT,PSE36,MMX,FXSR> > real memory = 134217728 (131072K bytes) > avail memory = 127868928 (124872K bytes) > Preloaded elf kernel "kernel" at 0xc02ae000. > Pentium Pro MTRR support enabled, default memory type is uncacheable > Probing for PnP devices: > pcib0: on motherboard > pci0: on pcib0 > chip0: at device 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vga-pci0: irq 11 at device 0.0 on pci1 > isab0: at device 4.0 on pci0 > chip1: at device 4.1 on pci0 > chip2: at device 4.3 on pci0 > ahc0: irq 14 at device 6.0 on pci0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > [...] > Waiting 3 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 6 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 3.300MB/s transfers > changing root device to da0s1a > da2 at ahc0 bus 0 target 2 lun 0 > da2: Removable Direct Access SCSI-2 device Have you tried this without the ZIP drive? I've heared from people they sometimes cause grief. Groeten / Cheers, | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
As e...@habatech.no wrote ... > > On 12-May-99 Ustimenko Semen wrote: > > > > Are we going to get this license? I am interested in NTFS > > source code a lot... > > > > P.S. What's happening with MS? > > > They have got a virus. I think they're calling it Open Source... Na... it's called US Dept of Justice I guess ;-) > They're fighting really hard to get rid of it, but these things can happen > from time to time :) Groeten / Cheers, | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Nt source licenses...
Ustimenko Semen wrote: > > Hi, > > On Tue, 11 May 1999, Luigi Rizzo wrote: > > > Hi, > > maybe i am the last one in the world to know, but were you guys aware > > of this: > > > > http://research.microsoft.com/programs/NTSrcLicInfo.htm > > > > Microsoft makes Windows NT source code available to universities > > and other "not-for-profit" research institutions at no charge. > > Currently, there are over 55 universities and government agencies > > with source licenses. > > Are we going to get this license? I am interested in NTFS > source code a lot... > > P.S. What's happening with MS? Thanks for the info - I'll try to persuade my Uni to get a license... Shouldn't be much of a problem. :-) If no-one else wants it, I can always request it myself and get a signature of someone at UKC to back it up (or I can always sign "The Dean" :-) Dean To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Scanners
i tried it, i belive it's only for SCSI scanners, my UMAX 1220P is for the parallel port. On Wed, 12 May 1999, Edwin Culp wrote: > Have you tried /usr/ports/graphics/sane? > > ed -- == Tomer Weller s...@i.am well...@netvision.net.il "Drugs are good, and if you do'em pepole think that you're cool", NoFX To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
My personal opinion is that static configuration is a subset of dynamic configuration. The eventual aim is to have a kernel which is a very sparse skelaton, with very few services and drivers loaded (in fact possibly none). At boot time, the needed drivers and services are loaded and configured (by the loader possibly). A driver that is already linked in is treated exactly as if it had been loaded, except that the loading is not required.. In this view, a statically linked in module is really just a 'pre-loaded' module. it still needs to be initialised. In this view, config(8) is reduced to being used to specify the preloaded modules (though that may be done after compilation by an external linker/loader) and to specify debugging options. A utility could exist that takes a skelaton kernel, and a specified list of kld modules and creates a composite loadable kernel, in which some modules are already present. I will admit that I have only looked a small amount at the new config that NetBSD uses, but it seemed to me that it produced far too much static information. This infrastucture would be duplicated by a dynamic loading framework. why have two such frameworks? If newconfig has removed all static device framework from the kernel then it is going the way I envision things moving. If it still does what the NetBSD one did when I looked at it, and produces a statically compiled framework of child devices and parent nodes, then that is one of the things we are trying to get away from. julian On Wed, 12 May 1999, Noriyuki Soda wrote: > > On Wed, 12 May 1999 09:35:36 -0400, > "Rick Whitesel" said: > > > In general I believe that dynamic configuration of the system is > > extremely useful to both the development community and the user > > community. The development community has a much easier time if they > > can load / unload drivers. As for the users, my rule of thumb is > > that a computer should never ask a human the answer to a question > > that it can find out for itself. I think this is especially true for > > configuration information. In addition, the need for dynamic system > > (re)configuration will only increase as features like PCI hot swap > > become the standard. > > Of course, I completely agree with you. > > The reason I prefer newconfig is it actually can support dynamic > configuration better than the new-bus. All features which new-bus has > can be implemented on newconfig, too. And, more. (See the description > about on-demand dynamic loading in my previous post.) > > Furthremore, newconfig does static configuration better than the > new-bus, and newconfig has a option which removes dynamic configuration > entirely from kernel. New-bus apparently doesn't have this option. > > So, which is flexible ? :-) > -- > s...@sra.co.jpSoftware Research Associates, Inc., Japan > (Noriyuki Soda) Advanced Technology Group. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
X crashing under current
I also am experiencing a kernel panic whenever I start X using today's kernel. Thanks Kenneth Culver Computer Science Major at the University of Maryland, College Park. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa writes: > > mechanism was unacceptable -- else we would have used it years ago. > It is not formal core decision. On whose authority do you say that? Garrett is a core team member. > > Our policy in all areas has been that we'd rather do the Right Thing > > than follow the crowd. > new-bus is wrong way. You are misunderstanding 4.4BSD mechanism. Then explain to us why newbus is wrong and why the 4.4BSD scheme is right. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: dots in usernames?
On Wed, 12 May 1999, Mark Murray wrote: > Bob K wrote: > > Well, I did some reading through rfc821, and an email address is defined > > as follows: > > Email addresses != Usernames. What this suggests to me is that having > an _alias_ (say) Mark.Murray to markmurray in /etc/aliases is OK. Sigh. Yes, I know. However, here's the reasoning behind not having dots in usernames according to passwd(5): The login name must never begin with a hyphen (``-''); also, it is strongly suggested that neither upper-case characters nor dots (``.'') be part of the name, as this tends to confuse mailers. Since any mailer that can't handle a dot in an email address that consists of lo...@host is not compliant with RFC 821, I'm thinking "Hey! Why not make the change?" I've tested it on my -stable system here, and so far there's been no incompatibilities (but then, I only tested a few things: see the original email I sent - which is the point of putting something in -current before stable :) mela...@yip.org - Mustard gas: The kids love it! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: dots in usernames?
In the last episode (May 12), Mark Murray said: > Bob K wrote: > > Well, I did some reading through rfc821, and an email address is > > defined as follows: > > Email addresses != Usernames. What this suggests to me is that having > an _alias_ (say) Mark.Murray to markmurray in /etc/aliases is OK. but, from the chown manpage: COMPATIBILITY Previous versions of the chown utility used the dot (`.') character to distinguish the group name. This has been changed to be a colon (`:') character so that user and group names may contain the dot character. So it sounds like the rest of the system is leaning toward allowing dots in usernames as well. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: dots in usernames?
On Wed, 12 May 1999, David Wolfskill wrote: > >Date: Wed, 12 May 1999 14:15:12 -0400 (EDT) > >From: Bob K > > >People on -current: Just to recap, adduser (and rmuser) disallow .'s in > >usernames on FreeBSD-stable; passwd(5) cites that some mailers have > >problems with dots in usernames. However, they are becoming more common, > >and are a legal part of rfc821. So what are people's thoughts on allowing > >that in -current, and if there's no complaints, backporting it to -stable? > >It seems really really trivial... > > Syntax for valid mailboxes need not correspond to (but should be a > superset of, IMO) syntax for usernames. > > What's the problem you're trying to solve? I'm hoping to simplify things for my users so that they don't need to have a different email address from their username if they have a dot in the local-part. mela...@yip.org - Mustard gas: The kids love it! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: dots in usernames?
Bob K wrote: > Well, I did some reading through rfc821, and an email address is defined > as follows: Email addresses != Usernames. What this suggests to me is that having an _alias_ (say) Mark.Murray to markmurray in /etc/aliases is OK. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: dots in usernames?
>Date: Wed, 12 May 1999 14:15:12 -0400 (EDT) >From: Bob K >People on -current: Just to recap, adduser (and rmuser) disallow .'s in >usernames on FreeBSD-stable; passwd(5) cites that some mailers have >problems with dots in usernames. However, they are becoming more common, >and are a legal part of rfc821. So what are people's thoughts on allowing >that in -current, and if there's no complaints, backporting it to -stable? >It seems really really trivial... Syntax for valid mailboxes need not correspond to (but should be a superset of, IMO) syntax for usernames. What's the problem you're trying to solve? Cheers, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: de driver problem
Wilko Bulte wrote: > PERL_SRC=/usr/obj/usr/src/gnu/usr.bin/perl/perl > Writing Makefile for DynaLoader > ==> Your Makefile has been rebuilt. <== > ==> Please rerun the make command. <== > false > false: not found > *** Error code 1 I periodically see this one reported, and It is always repaired by the reporter making sure their tree is _really_ clean before doing a make world. "Really clean" means "make cleandir" _twice_, and complete removal of the contents of /usr/obj. _Then_ cvsup. I prefer to usr CVS checkout, as it shows all the differences and other turds in my source tree. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Scanners
On Wed, May 12, 1999 at 10:28:45AM -0700, David O'Brien wrote:
> > > i got a new UMAX Atrsa 1220P scanner, i have no idea how to configure
> > > this in FreeBSD or Linux (or if i even can), im on 4.0-CURRENT.
> ..snip..
>
> > Have you tried /usr/ports/graphics/sane?
>
> It doesn't build under 4.0-CURRENT.
Had to fix this a few days ago anyway...
-Jeremy
--
| "I could be anything I wanted to, but one things true
--+-- Never gonna be as big as Jesus, never gonna hold the world in my hand
|Never gonna be as big as Jesus, never gonna build a promised land
|But that's, that's all right, OK with me..." -Audio Adrenaline
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-01
graphics/sane/patches/patch-01
--- /usr/ports.ref/graphics/sane/patches/patch-01 Sun Dec 6 11:37:28 1998
+++ graphics/sane/patches/patch-01 Wed May 12 19:53:21 1999
@@ -5,7 +5,7 @@
# Use test -z because SunOS4 sh mishandles braces in ${var-val}.
# It thinks the first close brace ends the variable substitution.
-test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
-+test -z "$INSTALL_SCRIPT" && INSTALL_PROGRAM='${INSTALL}'
++test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL}'
test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-02
graphics/sane/patches/patch-02
--- /usr/ports.ref/graphics/sane/patches/patch-02 Tue May 26 10:17:59 1998
+++ graphics/sane/patches/patch-02 Wed May 12 19:56:24 1999
@@ -9,13 +9,12 @@
# Don't delete any intermediate files.
.PRECIOUS: %-s.c %-s.lo %.lo dll-preload.c
-@@ -94,16 +94,16 @@
+@@ -94,16 +94,13 @@
file=libsane-$${be}.so.$(V_MAJOR); \
lib=`grep dlname= libsane-$${be}.la | cut -f2 -d"'"`; \
- if test ! -f $${file} -a -n "$${lib}"; then \
+-if test ! -f $${file} -a -n "$${lib}"; then \
- ln -s $${lib} $${file}; \
-+ ln -sf $${lib} $${file}; \
- fi; \
+-fi; \
done
rm -f $(libdir)/libsane.a $(libdir)/libsane.so \
$(libdir)/libsane.so.$(V_MAJOR)*
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-03
graphics/sane/patches/patch-03
--- /usr/ports.ref/graphics/sane/patches/patch-03 Wed Sep 16 23:37:56 1998
+++ graphics/sane/patches/patch-03 Wed May 12 19:52:36 1999
@@ -1,12 +0,0 @@
backend/Makefile.in.orig Thu Sep 17 05:03:21 1998
-+++ backend/Makefile.inThu Sep 17 05:16:13 1998
-@@ -93,9 +93,6 @@
- @list="$(ALL_BACKENDS)"; cd $(libsanedir) && for be in $$list; do \
- file=libsane-$${be}.so.$(V_MAJOR); \
- lib=`grep dlname= libsane-$${be}.la | cut -f2 -d"'"`; \
--if test ! -f $${file} -a -n "$${lib}"; then \
-- ln -sf $${lib} $${file}; \
--fi; \
- done
- rm -f $(libdir)/libsane.a $(libdir)/libsane.so \
- $(libdir)/libsane.so.$(V_MAJOR)*
diff -urN -x CVS /usr/ports.ref/graphics/sane/patches/patch-04
graphics/sane/patches/patch-04
--- /usr/ports.ref/graphics/sane/patches/patch-04 Thu Jan 28 23:31:39 1999
+++ graphics/sane/patches/patch-04 Wed May 12 19:58:04 1999
@@ -17,28 +17,28 @@
*)
$echo "$modename: unknown library version type \`$version_type'" 1>&2
echo "Fatal configuration error. See the $PACKAGE docs for more
information." 1>&2
ltconfig.orig Tue Nov 24 17:04:26 1998
-+++ ltconfig Tue Nov 24 17:07:35 1998
-@@ -1123,10 +1123,21 @@
+--- ltconfig.orig Sun Nov 22 05:53:55 1998
ltconfig Wed May 12 19:57:19 1999
+@@ -777,7 +777,7 @@
+ ;;
+
+ # FreeBSD 3, at last, uses gcc -shared to do shared libraries.
+- freebsd3*)
++ freebsd*)
+ archive_cmds='$CC -shared -o $lib$libobjs'
+ hardcode_libdir_flag_spec='-R$libdir'
+ hardcode_direct=yes
+@@ -1123,10 +1123,10 @@
finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do
libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`;
test $rm /sys/libs/${libname}_ixlibrary.a; $show "(cd /sys/libs && $LN_S $lib
${libname}_ixlibrary.a)"; (cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a)
|| exit 1; done'
;;
-freebsd2* | freebsd3*)
-+freebsd2*)
- version_type=sunos
- library_names_spec='${libname}${release}.so.$versuffix $libname.so'
- finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'
-+ shlibpath_var=LD_LIBRARY_PATH
-+ ;;
-+
-+freebsd3* | freebsd4*)
+- version_type=sunos
++freebsd*)
+ version_type=freebsd
-+ library_names_spec='${libname}${release}.so.$versuffix $libname.so'
-+ if [ $PORTOBJFORMAT = elf ]; then
-+ finish_cmds='PATH="\$PATH:/sbin" OBJFORMAT="$PORTOBJFORMAT" ldconfig -m
$libdir'
-+ else
-+ finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
-+ fi
+ library_names_spec='${libname}${release}.so.$versuffix $libname.so'
+- finish_cmds='PATH="$PATH:/sbin" ldconfig -m $libdir'
++ finish_cmds='PATH="\$PATH:/sbin" OBJFORMAT="'"$PORTOBJFORMAT"'" ldconfig -m
$li
RE: dots in usernames?
Well, I did some reading through rfc821, and an email address is defined
as follows:
::= "@"
::= |
::= | "."
^^^ !
::= |
::= """ """
::= "\" | "\" | |
::= | "\"
::= any one of the 128 ASCII characters, but not any or
::= any one of the 128 ASCII characters (no exceptions)
::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." | "," | ";" |
":" | "@" """ | the control characters (ASCII codes 0 through 31
inclusive and 127)
(the above from ftp://passaic.cs.miami.edu/pub/rfc/rfc821.txt)
So if I've interpreted that right, .'s are indeed a legal part of the
local-part of email addresses (addresses with dots in 'em are also used in
various examples of that rfc); this would say to me that any mailer that
can't handle dots in the username should be considered non-RFC compliant.
I've bcc:'d freebsd-questions and cc:'d freebsd-current (which I'm not on,
btw) as I think the discussion is now headed in that direction.
People on -current: Just to recap, adduser (and rmuser) disallow .'s in
usernames on FreeBSD-stable; passwd(5) cites that some mailers have
problems with dots in usernames. However, they are becoming more common,
and are a legal part of rfc821. So what are people's thoughts on allowing
that in -current, and if there's no complaints, backporting it to -stable?
It seems really really trivial...
On Wed, 12 May 1999, Christopher Michaels wrote:
> That would be the e-mail message that I had in memory when I sent my reply.
> The way I see it, is if you've made the change and nothing's broken then why
> not! I think most of the wariness if from an earlier day when dots actually
> did break things. Now a days the mail software has to take into account
> that there ARE email addresses with dots in them.
>
> Maybe someone else on this list is better qualified to answer your question
> than I am, tho.
>
> I've noticed that most of the places that I've seen dots in user names are
> on Microsoft mail servers and windows NT logins. I personally have never
> seen them on a UNIX server. But again, just test it out and see what
> breaks, if nothing breaks then I don't see a problem with it.
>
> -Chris
>
> Anyone out there want to chime in as to why there shouldn't be dots in user
> names?
>
> > -Original Message-
> > From: Bob K [SMTP:mela...@yip.org]
> > Sent: Tuesday, May 11, 1999 6:36 PM
> > To: Christopher Michaels
> > Cc: freebsd-questi...@freebsd.org
> > Subject:RE: dots in usernames?
> >
> > Hmm. I searched freebsd-questions, and all I could come up with was the
> > following:
> >
> >
> > Date: Sun, 14 Mar 1999 21:39:39 +1000
> > From: Greg Black
> > To:Shawn Ramsey
> > Cc:Kelvin ,
> > freebsd-questi...@freebsd.org
> > Subject: Re: Question about login name
> > Message-ID: <19990314113940.12057.qm...@alpha.comkey.com.au>
> >
> > [snip]
> >
> > It's also worth reading the man page for passwd(5), in
> > particular the following partial paragraph:
> >
> > The login name must never begin with a hyphen (``-'');
> > also, it is strongly suggested that neither upper-case
> > characters nor dots (``.'') be part of the name, as this
> > tends to confuse mailers.
> >
> > And then ask yourself if you really *need* to use this kind of
> > login or if it's just something you'd like. If you don't really
> > need it (and there must be very few reasons why you might), you
> > would probably be better off not to do it.
> >
> > --
> > Greg Black
> >
> >
> > I'm just wondering how much of a problem this poses at this point; I'm
> > seeing more and more email addresses with dots in the username (not to say
> > that just because people do it means it's a good thing ;). Sendmail 8.9.2
> > certainly doesn't mind it, nor does Exim. Is there a list of mailers that
> > don't like this? Is there perhaps a more appropriate forum to ask this
> > sort of question?
> >
> > /me really should read manpages more often...
> >
> > On Tue, 11 May 1999, Christopher Michaels wrote:
> >
> > > My understanding of the situation is that you don't want dots in the
> > > usernames because it tends to confuse mailer programs (mainly).
> > > Unfortunately our web proxy isn't being very cooperative at work here
> > today
> > > and I can't lookup what I'm looking for in the archives.
> > >
> > > This was a top of discussion maybe a moth ago.
> > >
> > > -Chris
> > >
> > > > -Original Message-
> > > > From: Bob K [SMTP:mela...@yip.org]
> > > > Sent: Tuesday, May 11, 1999 11:42 AM
> > > > To: freebsd-questi...@freebsd.org
> > > > Subject:Re: dots in usernames?
> > > >
> > > > On Tue, 11 May 1999, Bob K wrote:
> > > >
> > > > > > will it break anything? I know I can add an alias; I'm just
> > hoping to
> > > > > > simplify things for the user in question. I suppose after doing
> > that,
> > > > a
> > > > > > make world & rebuild of any ports using utmp would be in order?
> > > > >
Re: Anybody actually using gigabit ethernet?
I bought two of the cards in order to decide whether or not I wanted to use them in my research group's PII cluster. Right now, they're plugged into a 233MHz Pentium Pro and a 400Mhz K6-2 (using an Aladdin V-based board). I did a bunch of NFS testing over the gigabit link last week and didn't see any glitches. The only "problems" that I've seen are (1) the round-trip latency for small UDP packets is at least 50% higher than FastEthernet on the same hardware and (2) the round-trip latency is highly variable. Alan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
Pierre Beyssac writes:
> if (resid >= MINCLSIZE) {
> MCLGET(m, M_WAIT);
> + if (m == 0) {
> + error = ENOBUFS;
> + goto release;
> + }
> if ((m->m_flags & M_EXT) == 0)
> goto nopages;
> mlen = MCLBYTES;
I think this part of the patch is useless. MCLGET() does not set
m to NULL when it fails, it simply doesn't set the M_EXT flag.
...unless things have changed recently.
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: has the 3.2 branch happened?
Joe Abley writes: > (he asked :) As I understand it, 3.2 is simply a release tag on the already existing branch called RELENG_3 (aka 3.1-stable). So there will be no additional branch for 3.2, just a release tag: RELENG_3_2_0 or somesuch. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Today's kernel crashes on starting X
Hello Geoff, Wednesday, May 12, 1999, 4:35:54 PM, you wrote: GR> I'm currently running into a problem, that when I start my system, GR> it spontaneously reboots when starting X. Has anyone else run into GR> this? yes, i'm experiencing the same problem with today's (May, 12) kernels. Best regards, Ilyamailto:ca...@avias.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Scanners
> > i got a new UMAX Atrsa 1220P scanner, i have no idea how to configure > > this in FreeBSD or Linux (or if i even can), im on 4.0-CURRENT. ..snip.. > Have you tried /usr/ports/graphics/sane? It doesn't build under 4.0-CURRENT. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
mbuf starvation
< said: > Another big problem is that there's a check in m_retry and friends > that panics when falling short of mbufs! I really believe this does > more harm than good, because it prevents correct calling code > (checking for NULL mbuf pointers) from exiting gracefully with > ENOBUFS... I think we need to think a bit more about the right semantics before making such a change. M_WAIT is supposed to mean `I am in process context and don't mind sleeping in order to get an mbuf, but there is too much locking going on inside the network stack to be able to safely sleep without serious risk of deadlock. This is the sort of application which would be ideal for Matt's `asleep' interface. Then, the code could back its way out of any locks and spls, safely wait for sufficient mbufs to be freed, and then retry. Even then, it's still possible to deadlock if one process hogs the entire mbuf pool. It may be necessary to incrementally penalize processes which do so. FWIW, the 4.3 code sleeps in a loop. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At 12/05/99, you wrote: >Ok, what I'd like you to do is, run this command, > nm -n /kernel | more >the output is the list of symbols in the kernel sorted by their addresses >(the left-most column), page through the output, find symbols around the >address 0xc0155ca4, and send me those symbol names along with their addresses. c0154d2c T ptrace c0155244 T trace_req c0155250 T stopevent c01552ac t gcc2_compiled. c01552ac T rman_init c015534c T rman_manage_region c0155404 T rman_fini c015549c T rman_reserve_resource c015584c t int_rman_activate_resource c01558a4 T rman_activate_resource c01558bc T rman_await_resource c0155940 t int_rman_deactivate_resource c0155960 T rman_deactivate_resource c0155970 t int_rman_release_resource c0155b18 T rman_release_resource c0155b2c t gcc2_compiled. c0155b2c T soo_read c0155b50 T soo_write c0155b78 T soo_ioctl c0155cd8 T soo_poll c0155cf8 T soo_stat c0155d28 T soo_close c0155d4c t gcc2_compiled. c0155d4c T ipcperm c0155dd8 t gcc2_compiled. c0155dd8 t msginit c0155f3c T msgsys c0155f6c t msg_freehdr c0156010 T msgctl c01561f0 T msgget c015638c T msgsnd c015678c T msgrcv c0156aa0 t gcc2_compiled. c0156aa0 t seminit c0156b38 T semsys c0156b9c T semconfig c0156bfc t semu_alloc c0156cb4 t semundo_adjust c0156da8 t semundo_clear c0156e1c T __semctl c0157398 T semget c01575c4 T semop c0157988 T semexit c0157b00 t gcc2_compiled. c0157b00 t shm_find_segment_by_key but now the kernel is changed because I add options ddb so you are more interested in the old kernel that was up when the crahs happens : This is : c0154084 T shmctl c0154190 t shmget_existing c0154238 t shmget_allocate_segment c015442c T shmget c0154488 T shmsys c01544b8 T shmfork c0154538 T shmexit c0154598 t shminit c01545ec t gcc2_compiled. c01545ec T ttyopen c0154644 T ttyclose c01546c4 T ttyinput c0154df8 t ttyoutput c0154f5c T ttioctl c0155a70 T ttypoll c0155b1c T ttpoll c0155b50 t ttnread c0155b94 T ttywait c0155c34 t ttywflush c0155c5c T ttyflush c0155d68 T termioschars c0155d80 T ttychars c0155d94 T ttyblock c0155dd8 t ttyunblock c0155e1c T ttstart c0155e38 T ttylclose c0155e64 T ttymodem c0155f38 t ttypend c0155fa0 T ttread c0156560 T ttycheckoutq c015660c T ttwrite c01569a0 t ttyrub c0156b3c t ttyrubo c0156b78 t ttyretype c0156c54 t ttyecho c0156ce0 T ttwakeup c0156d30 T ttwwakeup c0156d9c T ttspeedtab c0156dc8 T ttsetwater c0156f40 T ttyinfo c0157100 t proc_compare c01571cc T tputchar c0157224 T ttysleep c0157260 t gcc2_compiled. c0157260 t ttcompatspeedtab c0157290 T ttsetcompat c0157484 T ttcompat c01576e8 t ttcompatgetflags c0157840 t ttcompatsetflags c015797c t ttcompatsetlflags c0157a9c t gcc2_compiled. c0157a9c T ldisc_register and the trace of ddb on panic (new kernel) generated by screen is : >trace Stopped at ttyflush+0x48: movl 0x14(%eax), %eax ttyflush (c025f2a0,3,c02601e0,c025f2a0,80047410) at ttyflush+0x48 ttioctl(c025f2a0,80047410,c6860ee4,3,c6860e20) at ttioctl+0x4a9 ptyioctl(f700,80047410,c6860e04,c01de031,c6860e20,c6860eb0) at spec_ioctl+0x44 spec_vnoperate(c686e20,c6860eb0,c0172821,c6860e20,0) at spec_vnoperate+0x15 ufs_vnoperatespec(c6860e20,0,c0a44cc0,4,c6860f90) at ufs_vnoperatespec+0x15 vn_ioctl(c0a44cc0,80047410,c6860ee4,c5de94a0) at vn_ioctl+0xdd ioctl(c5de94a0,c6860f90,28113874,806df09,8073720) at ioctl+0x1ef syscall(2f,2f,2f,8073720,806df09) at syscall+0x126 Xint0x80_syscall() at Xint 0x80_syscall+0x30 Hope it helps... Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At 12/05/99, you wrote: > >At least put DDB in your kernel, type "trace" when it >panics and tell us what it says. Ok... it's a bit long ... (Tell me there isn't a command to write the trace output on a disk :-) After the panic make by "screen" ... >trace Stopped at ttyflush+0x48: movl 0x14(%eax), %eax ttyflush (c025f2a0,3,c02601e0,c025f2a0,80047410) at ttyflush+0x48 ttioctl(c025f2a0,80047410,c6860ee4,3,c6860e20) at ttioctl+0x4a9 ptyioctl(f700,80047410,c6860e04,c01de031,c6860e20,c6860eb0) at spec_ioctl+0x44 spec_vnoperate(c686e20,c6860eb0,c0172821,c6860e20,0) at spec_vnoperate+0x15 ufs_vnoperatespec(c6860e20,0,c0a44cc0,4,c6860f90) at ufs_vnoperatespec+0x15 vn_ioctl(c0a44cc0,80047410,c6860ee4,c5de94a0) at vn_ioctl+0xdd ioctl(c5de94a0,c6860f90,28113874,806df09,8073720) at ioctl+0x1ef syscall(2f,2f,2f,8073720,806df09) at syscall+0x126 Xint0x80_syscall() at Xint 0x80_syscall+0x30 A nightmare ! :-) Best Regards, Gianmarco Giovannelli , "Unix expert since yesterday" http://www.giovannelli.it/~gmarco http://www2.masternet.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
> On Wed, 12 May 1999 17:45:45 +0200, Poul-Henning Kamp said: >> What is the definition of "config"? > config(8) >> Why do you want to remove it? > Why should we, as a 3rd millenium OS need a static config tool ? For example, - To specify the drivers which is linked statically to kernel. As I said earlier, you cannot link console driver dynamically, If you do this, you cannot get error message when dynamic linking of the console driver failed. - There should be a way to inform kernel about inter module dependency dynamically. config(8) converts this information to a file which is kernel readable format. - There should be a way to inform kernel about mapping from device name to driver filename dynamically. config(8) converts this information to a file which is kernel readable format. - To achieve better performance in both UP and SMP cases. Proper SMP implementation requires fine grained locking, though this increases performance penalty in UP case. (e.g. Solaris shows this problem.) Thus, the way to specify "options SMP" is needed to use (static) source level and compiler level optimization. This option should automatically select the appropriate sources which is compiled into kernel, according to the source is needed only in UP case, or only in SMP case, or both. This is what oldconfig and newconfig does. The new-bus doesn't have these features. > We are working on FreeBSD as a OS for the future, not for the past. Of course! We never should go back to the age of 1979 (i.e. before 4.0BSD). -- soda To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Poul-Henning Kamp Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Wed, 12 May 1999 17:45:45 +0200 Message-ID: <5756.926523...@critter.freebsd.dk> phk> phk> >phk> >Since newconfig appears technically superior, what are the issues that phk> >phk> >are hindering its acceptance? phk> >phk> phk> >phk> That we want to have no "config" at all. phk> > phk> >That is too short an answer. phk> phk> No, it is complete and to the point. phk> phk> >What is the definition of "config"? phk> phk>config(8) phk> phk> >Why do you want to remove it? phk> phk> Why should we, as a 3rd millenium OS need a static config tool ? Newconfig is a *dynamic* configuration tool. Replacing the old config with newconfig is sufficient for your reason to remove config. Why do you refuse newconfig if it is a better framework for dynamic configuration? Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: somebody has broken sysctlbyname() in -current
On Wed, 12 May 1999, Stefan Bethke wrote: > Any pointer on Forth literature/web pages would be appreciated, especially > if it's not the ANSI standard (I've looked at it, and it is that: a > standard, not a reference manual or a tutorial). My Forth knowledge is > rather rusty, I realised... last time I remember I was sitting in front of > my Apple II clone about 15 years ago. "Real-Time Forth" could be good for beginners... It's on the web somewhere. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
On Wed, May 12, 1999 at 05:43:27PM +0200, Stefan Bethke wrote: > I've discussed this with Garett back in September. The reason is quite > simple: unless all cases of not checking for a NULL pointer returned are > fixed (or instrumented with a panic), it is better to fail with a panic > than with some obscure problem later on. Yes, I would agree in the general case, but in that particular case the reasonning is flawed: you panic every time, while there are many cases that currently are handled gracefully by the caller. In other words, you don't leave any choice to the caller. That's bad. IHMO it's not even a good thing in general because mbuf starvations can and _will_ happen as a normal condition, not because of bugs but because of high resource use. It can have its uses for debugging purposes, as a compilation option. -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: panic ! panic ! panic !
Only one problem with that - screen and keyboard are not responding when it panics. I'm hoping that I will be able to get a dump which I can look at post mortem. I'm going to try again though. The kernel I have at the moment is totally messing up my keyboard, and I cannot even get a single user login! Geoff. > -Original Message- > From: Poul-Henning Kamp [mailto:p...@critter.freebsd.dk] > Sent: 12 May 1999 05:56 > To: Geoff Rehmet > Cc: lu...@watermarkgroup.com; curr...@freebsd.org > Subject: Re: panic ! panic ! panic ! > > > > At least put DDB in your kernel, type "trace" when it > panics and tell us what it says. > > In message <19990512154854.78032.qm...@rucus.ru.ac.za>, > "Geoff Rehmet" writes: > >Luoqi Chen writes : > > > >I'm trying to get a crash dump myself, but the kernel I have > >right now, is screwing up my keyboard, and I cannot even log > >in! > >I will try again. > > > >Geoff. > >> > After make world this morning I received this panic : > >> > > >> > Fatal trap 12: page fault while in kernel mode > >> > fault virtual address = 0x14 > >> > fault code = supervisor read, page not present > >> > instruction pointer = 0x8:0xc0155ca4 > >> > stack pointer = 0x10:0xc6864d64 > >> > frame pointer = 0x10:0xc6864d78 > >> > code segment = base 0x0, limit 0xf, type 0x1b > >> > = DPL0, pres 1, def32 1, gran 1 > >> > processor eflags = interrupt enabled, resume , IOPL=0 > >> > current process = 374 (screen-3.7.6) > >> > interrupt mask = tty > >> > trap number = 12 > >> > panic: page fault > >> > > >> > I receive this panic with "screen", but before I kept > this box resetting > >> > itself trying to enter in X... and I was trying Xfree > 3.3.3.1 (recompiled > >> > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I > could not seen the > >> > panic probably due to X loading. > >> > > >> Could you show us the symbols around the faulting > instruction at 0xc0155ca4? > >> It would be even better if you have a crash dump and the > gdb backtrace. > >> > >> -lq > >> > >> > >> To Unsubscribe: send mail to majord...@freebsd.org > >> with "unsubscribe freebsd-current" in the body of the message > >> > > > > > >-- > >Geoff Rehmet, > >The Internet Solution > >geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org > >tel: +27-83-292-5800 > > > > > >To Unsubscribe: send mail to majord...@freebsd.org > >with "unsubscribe freebsd-current" in the body of the message > > > > -- > Poul-Henning Kamp FreeBSD coreteam member > p...@freebsd.org "Real hackers run -current on > their laptop." > FreeBSD -- It will take a long time before progress goes too far! > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
At least put DDB in your kernel, type "trace" when it panics and tell us what it says. In message <19990512154854.78032.qm...@rucus.ru.ac.za>, "Geoff Rehmet" writes: >Luoqi Chen writes : > >I'm trying to get a crash dump myself, but the kernel I have >right now, is screwing up my keyboard, and I cannot even log >in! >I will try again. > >Geoff. >> > After make world this morning I received this panic : >> > >> > Fatal trap 12: page fault while in kernel mode >> > fault virtual address = 0x14 >> > fault code = supervisor read, page not present >> > instruction pointer = 0x8:0xc0155ca4 >> > stack pointer = 0x10:0xc6864d64 >> > frame pointer = 0x10:0xc6864d78 >> > code segment = base 0x0, limit 0xf, type 0x1b >> > = DPL0, pres 1, def32 1, gran 1 >> > processor eflags = interrupt enabled, resume , IOPL=0 >> > current process = 374 (screen-3.7.6) >> > interrupt mask = tty >> > trap number = 12 >> > panic: page fault >> > >> > I receive this panic with "screen", but before I kept this box resetting >> > itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled >> > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the >> > panic probably due to X loading. >> > >> Could you show us the symbols around the faulting instruction at 0xc0155ca4? >> It would be even better if you have a crash dump and the gdb backtrace. >> >> -lq >> >> >> To Unsubscribe: send mail to majord...@freebsd.org >> with "unsubscribe freebsd-current" in the body of the message >> > > >-- >Geoff Rehmet, >The Internet Solution >geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org >tel: +27-83-292-5800 > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic ! panic ! panic !
Luoqi Chen writes : I'm trying to get a crash dump myself, but the kernel I have right now, is screwing up my keyboard, and I cannot even log in! I will try again. Geoff. > > After make world this morning I received this panic : > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x14 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc0155ca4 > > stack pointer = 0x10:0xc6864d64 > > frame pointer = 0x10:0xc6864d78 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume , IOPL=0 > > current process = 374 (screen-3.7.6) > > interrupt mask = tty > > trap number = 12 > > panic: page fault > > > > I receive this panic with "screen", but before I kept this box resetting > > itself trying to enter in X... and I was trying Xfree 3.3.3.1 (recompiled > > and reinstalled) SVGA, Metrolink and Xaccel 5.0 . But I could not seen the > > panic probably due to X loading. > > > Could you show us the symbols around the faulting instruction at 0xc0155ca4? > It would be even better if you have a crash dump and the gdb backtrace. > > -lq > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- Geoff Rehmet, The Internet Solution geo...@is.co.za; ge...@rucus.ru.ac.za; c...@freebsd.org tel: +27-83-292-5800 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
>phk> >Since newconfig appears technically superior, what are the issues >that >phk> >are hindering its acceptance? >phk> >phk> That we want to have no "config" at all. > >That is too short an answer. No, it is complete and to the point. >What is the definition of "config"? config(8) >Why do you want to remove it? Why should we, as a 3rd millenium OS need a static config tool ? Tell me which future technology we will need to handle which will require static config ? We are working on FreeBSD as a OS for the future, not for the past. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: mbuf starvation
Pierre Beyssac wrote: > Another big problem is that there's a check in m_retry and friends > that panics when falling short of mbufs! I really believe this does > more harm than good, because it prevents correct calling code > (checking for NULL mbuf pointers) from exiting gracefully with > ENOBUFS... I've discussed this with Garett back in September. The reason is quite simple: unless all cases of not checking for a NULL pointer returned are fixed (or instrumented with a panic), it is better to fail with a panic than with some obscure problem later on. Stefan -- Mühlendamm 12 | Voice +49-40-256848, +49-177-3504009 D-22089 Hamburg | e-mail: stefan.bet...@hanse.de Germany | s...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
