Single character errors in source files, stop kernel compile!
Hi I'm running FreebSD 3.3 on a AMD-K6 box thats totally SCSI. The controller is Adaptec 2940 and the drive in question is a 40MB/sec IBM 9GB (SCSI 3?).. In the process of attempting to make a new kernel I follow the usual procedure. %cd /sys/i386/conf/ %config KERNEL %cd ../../compile/KERNEL %make depend Everything to this point completes and reports no errors. %make This is where I start to get failures. The compiler will stop with code 1 and will claim that the reason is a single character error in the source code. A typical example would be the word "struct" spelt "strwct". Clearly there is a problem which I doubt is the source code. To work around this I just repeat the make command again and again until the job is done. then I install the kernel and reboot sucessfully. Any ideas? I'm tempted to think it's some kind of a problem with the drive, but I haven't had any real hard failures. The /etc/make.conf has -O2 optimization for the kernel. Ta! Tom Brown = __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Surplus 3.2-RELEASE cds
On Sat, 9 Oct 1999, Jonathan M. Bresler wrote: > > bill, > please send me one box. i can give them out at the Washington > Area FreeBSD User's Group...as well as to people at work. After a > year of quiet work a number of die hard Linux folks are coming around > to see the light. ;) Could you get me some info on the meetings? I'd appreciate it :) > > jmb > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New command for cdcontrol(1)
> > > > In agreement. Now if someone will give me commit priviledges I'll commit it :) > > I think the correct procedure is to ply the right people with lots of > beers at FreeBSDCon 8*) me! me! ply me! jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Surplus 3.2-RELEASE cds
bill, i should have said that i can pick these up from you next week at the FreeBSDcon. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Surplus 3.2-RELEASE cds
bill, please send me one box. i can give them out at the Washington Area FreeBSD User's Group...as well as to people at work. After a year of quiet work a number of die hard Linux folks are coming around to see the light. ;) jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
Randell Jesup wrote... > This discussion should probably move to the freebsd-scsi list... > > "Kenneth D. Merry" <[EMAIL PROTECTED]> writes: > >Nick Hibma wrote... > >> Especially some help on the topic of polling would be appreciated. > >> Otherwise I'll have to resort to figuring out how to do things in > >> interrupt context, and that is going to be dirty. > > >If you're talking about polling for transaction completion in a device > >driver, my guess is that you're going to have to do things in an interrupt > >context. (Unless you use a kernel process to do it.) > > > >The thing to remember is that when you get CCBs down in a CAM device > >driver, it may well be in an interrupt context. You have to be able to > >deal with that. My guess is that it might be easiest to just use a timeout > >handler to poll the device for completion every so often. A kernel process > >may also be an option, depending on how nasty the device is. > > Ick. Polling == bad. Interrupts == good. This isn't a single- > tasking OS ala Win9x. This goes double for SCSI drivers, which are > inherently async and overlapped. I never said polling was good. Nick just asked about polling, and I commented on how it could be done. I have no idea why he wanted to know about polling, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: file system full
Assuming its descriptor usage is bounded, i.e. it is not leaking descriptors, you can solve the problem by using sysctl to raise the max files and max files per process. -Kip On Sat, 9 Oct 1999, James Howard wrote: > On Fri, 8 Oct 1999, Chris Costello wrote: > > >Too many open file descriptors. This has nothing to do with > > the file system. > > Is there anyway this can be gotten around? A friend has a mail server > that will spontaneously do this then crash. > > Jamie > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
This discussion should probably move to the freebsd-scsi list...
"Kenneth D. Merry" <[EMAIL PROTECTED]> writes:
>Nick Hibma wrote...
>> Especially some help on the topic of polling would be appreciated.
>> Otherwise I'll have to resort to figuring out how to do things in
>> interrupt context, and that is going to be dirty.
>If you're talking about polling for transaction completion in a device
>driver, my guess is that you're going to have to do things in an interrupt
>context. (Unless you use a kernel process to do it.)
>
>The thing to remember is that when you get CCBs down in a CAM device
>driver, it may well be in an interrupt context. You have to be able to
>deal with that. My guess is that it might be easiest to just use a timeout
>handler to poll the device for completion every so often. A kernel process
>may also be an option, depending on how nasty the device is.
Ick. Polling == bad. Interrupts == good. This isn't a single-
tasking OS ala Win9x. This goes double for SCSI drivers, which are
inherently async and overlapped.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Kris Kennaway <[EMAIL PROTECTED]> writes:
>Make uids randomly assigned. This solves the problem of collision between
>uids on an introduced medium and the ones on the local system by making it
>statistical (if the uid space is large enough). In order to manage this
>among multiple machines, you'd probably need a synchronisation facility,
>both online (connect to some network database), and by an "export/import"
>facility which lets you dump a DB and import (parts of) it on another
>machine. Storing the large uid in the inode is probably not feasible w/o
>breaking compatability, but you could indirect it through a mapping table
>loaded from elsewhere on disk when the FS is mounted.
>
>The downside to this is not being able to assign the uids according to
>your own numbering scheme. Perhaps what could be done is to have a lookup
>table which maps between in-system uids and on-disk ones, such that the
>kernel presents the translated uid to the system, and remaps the unknown
>ones.
This is a form of the "how do I know who is?"
Other interesting ideas (some related to the above):
Store on the disk a (small) UID to user-name/identifier mapping. When
mounting a disk, use those mappings to provide the (super)user with
the option to map the UID's of users who match the users of files on
the disk. There are some issues with identifying whether "joe" is the
same "joe" on the other system, but when combined with information
that's currently in passwd, it shouldn't be hard. You can also provide
this info to the person mounting the disk in a nice form that they
can accept, modify, or reject (and mount as totally foreign). For the
case of shared user databases, this should always come up with a
1:1 complete mapping.
You could extend this to use some form of public-key signature to
distinguish between users with similar names, and/or query the original
machine for more info/permission if possible.
When you mount a disk with UID translation going on, you could also
change the UID of new/modified files to be that of the user on the
new system (and update the user database on the partition), so when the
disk was moved back the original owner could filter out modifications
if he so wishes, or 'vet' them. Note: this includes root; or root can
be handled specially.
Much of what's going on here is that the decisions need to be in user
space, and this allows the software to present the user with a likely
set of mappings that they can accept, modify or reject.
If a (non-priviledged) user wants to mount a disk, they should not
be given any other than "other" access to anything (if that(?)), unless
they can identify themselves as the same user as one of the users
on the mounted disk (see above) - depending on how draconian you want
to be, and what level of security you've configured the disk for.
(Note: that last may be an important aspect. When a disk is set up
in a physically somewhat insecure setup (disk outside box, firewire,
etc as is being contemplated) you should be able to decide if you want
the disk to be "movable" or not. (And change that decision later if
you want to move it.)
Please excuse the rambling; I was just throwing out some ideas to see
if any stick to the wall.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: file system full
| >Too many open file descriptors. This has nothing to do with | > the file system. | | Is there anyway this can be gotten around? A friend has a mail server | that will spontaneously do this then crash. | | Jamie If you're csh'ish, you can use the ``limit'' command to see what your allowed openfiles are. You can raise this with ``unlimit''. You will also want to look at a few kernel options if the above doesn't fix it. -- Dan Moschuk ([EMAIL PROTECTED]) "Try not. Do, or do not. There is no try." -- Yoda To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
On Sat, 9 Oct 1999, W Gerald Hicks wrote: > > On Slashdot, ... > > > > Under QNX, if your driver crashes, the kernel just restarts it. > > That's not in the least bit how QNX works... oh well, it's slashdot. I've noticed Slashdotters tend to be clueless. It doesn't matter in this case, it is still a cool idea. :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vis(3), unvis(3), HTTP-URIs and libfetch
Thus spake Alexander Langer ([EMAIL PROTECTED]): > int strunvisx(char *dst, const char *src, int flag); ok. I'll use a function like this. Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs
> On Slashdot, ... > > Under QNX, if your driver crashes, the kernel just restarts it. That's not in the least bit how QNX works... oh well, it's slashdot. Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
