dirlist mangling
Never done any kernel hacking before so I'm just looking for some pointers. What's needed is a mechanism to specify a directory (or set of them) and whenever a request is made for the contents of that directory, if it exists in the list then what is returned needs to be mangled in some ways. For instance an ls in a directory in the list might only return a list of files that you own, or that you have permission to read. -- Samuel J. Greear [EMAIL PROTECTED] Developer - GetMegabits, Inc. http://www.itmom.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
On Mon, Sep 24, 2001 at 06:14:34PM -0700, Bakul Shah wrote: FWIW, in a Unix port we did I remember putting the user struct *above* the kernel stack. The stack grew down so you hit the red zone (the guard pages) without clobbering the user struct. Since struct user _ended_ on a page boundary, its size was needed at locore.s assembly time but that was a small price to pay for the added safety. I don't think a guard page can help here, because the page fault handler needs a working stack. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
On Tue, Sep 25, 2001 at 10:01:03AM +0200, Peter Wullinger wrote: On Tue, Sep 25, 2001 at 09:56:07AM +0200, Bernd Walter wrote: On Mon, Sep 24, 2001 at 06:14:34PM -0700, Bakul Shah wrote: FWIW, in a Unix port we did I remember putting the user struct *above* the kernel stack. The stack grew down so you hit the red zone (the guard pages) without clobbering the user struct. Since struct user _ended_ on a page boundary, its size was needed at locore.s assembly time but that was a small price to pay for the added safety. I don't think a guard page can help here, because the page fault handler needs a working stack. Depends on what is does ... if it just panics and syncs and does not care overwriting the user struct of the current process (which is lost anyway), is this much of a problem? Please correct me if I'm missing something. If it is overwriting there is no page fault thus no guard page and no panic. If you would have a page fault there is no space where the CPU can write the state information to for entering the handler. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
In message [EMAIL PROTECTED], Bernd Walter writes: On Tue, Sep 25, 2001 at 10:01:03AM +0200, Peter Wullinger wrote: On Tue, Sep 25, 2001 at 09:56:07AM +0200, Bernd Walter wrote: On Mon, Sep 24, 2001 at 06:14:34PM -0700, Bakul Shah wrote: FWIW, in a Unix port we did I remember putting the user struct *above* the kernel stack. The stack grew down so you hit the red zone (the guard pages) without clobbering the user struct. Since struct user _ended_ on a page boundary, its size was needed at locore.s assembly time but that was a small price to pay for the added safety. I don't think a guard page can help here, because the page fault handler needs a working stack. Depends on what is does ... if it just panics and syncs and does not care overwriting the user struct of the current process (which is lost anyway), is this much of a problem? Please correct me if I'm missing something. If it is overwriting there is no page fault thus no guard page and no panic. If you would have a page fault there is no space where the CPU can write the state information to for entering the handler. And it would take a double-fault for which we have a handler with it's own stack. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: termcap sources
Giorgos Keramidas wrote: [snip] As you can see there are quite a few terminals that have capabilities defined more than once! I don't have THAT many terminals to check, but I'm open to suggestions. Should we do something about this? If yes, what? this isn't a problem since only the first matching capability is used. others are ignored. I've a pending termcap update related to http://www.tuxedo.org/terminfo. for instance, I don't remember if reorder works w/ termtypes.tc ? Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
missing words, lots of them
These words, 830 of them, were obtained by intersecting the words in a number of lexicons and then subtracting the words in /usr/share/dict/web2. This all done with words that contain only lowercase letters. You'll find those words at the end of this message. Should you take even a cursory look at this list, I expect you'll be appalled at the words that are not in the lexicon. The point is *not* that these words should be added. The point is that a cursory, in-my-sleep check of the word list shows glaring deficiencies. A serious audit of the list will find way many more missing words (I did a preliminary -- think ~50,000-100,000 missing words if it is supposed to approximate the contents of an unabridged dictionary.) Anyway, I'm willing to create a replacement list, if it's likely to actually get used. Missing words: == abbreviated aborning absentminded academia acknowledgment actuate addictive adios aerospace affairs affianced aficionado aforementioned agonized agonizing agribusiness airborne airflow airline airs airspace airspeed alleged allowed aloes aloha alphanumeric ammoniac analog anechoic anomie antebellum antecedents antidisestablishmentarianism antimatter antimicrobial antipasto antiperspirant anytime appetizing apples appointed arbitrage archives arrears artwork ashtray assembled asserted attested audiovisual authors autocorrelation automate automation auxiliaries avionics awed backpack backstairs bags baklava balls bananas bandwagon bandwidth bans baptistry barbell barracks barrens baseline bawdy beatnik becalmed became bedraggled beep began begot belongings biased bidden bifocals bijection bimetallic binoculars biofeedback biomass biomedicine blabbermouth blacklist bleachers blew blinders blinkers blond bloodstream boatyard bobsledding boldface boogie boson botulinus bouncy bounds boutique box boyfriend braggadocio brainchild brainstorm bratwurst breathtaking briefcase brindle brindled brinkmanship britches brouhaha buckskins bugs bullshit bullyboy bumbling bunkmate burdened burger busboy butterflies buttocks byte cacciatore cannonball capita cards careerism cartwheel cassette castanets catalog caulk caveman challenging chambers changeover charged checklist checkpoint children chipboard chops chorale chromaticness ciao circuitry clannish classics classify classless clericals clipboard clippers clomp clueless cm coastline combo computerize coney confer cons contend contrabassoon contrived conveyor cookie cooperate cooperation cooperative coordinate coordination copywriter cordless cords corduroys corned corticosteroid councillor counterproductive courses coven coverall cowgirl cowpoke credits creeps critter crocked crud cuffs curia curtsey damaging damnedest danged dated dateline deadweight debug decencies decoder decor decrypt dedicated deli demo demodulate demur demythologize denims deprived desegregate despatch destined destruct diminished directions disadvantaged disembodied dishonesty distended disulfide disused divertimento dividers dogleg dominations dominions donnybrook doubleheader doubles downs downwards drily droppings drops dryer duce ducks duds dues dumbfound dumps dystopia eastwards eatables ecstatics ecumenicist edibles eggbeater einsteinium elan electromyography elevenses emaciated emancipated endgame enervated epoxy equities ergo erstwhile esprit esthete estranged evenings expecting expertise extramarital eyeglasses fallout falsity famed famished fantasize farmland fatigued fatso feathers feet feints femme fermion fermium ferroelectric fete fewer fiberglass fief fieldstone filigreed finicky fireworks fisticuffs fjord flamethrower flashback flashbulb flats floats floorboard fluorocarbon foiled fond footloose forensics forgave forgiven forklift forsook foxed frag frazzled fresher freshwater frostbitten frustrated fumed futures gadgetry geese gigahertz gills gimbals girlfriend gizmo glim glob globetrotter goddamn goddamned goggles goodbye gooey grapheme greatest greenbelt groceries grooved groundhog gunfight gunslinger gutsy hadron haiku hairstyle hammered handcrafted handlebar hands handyman hang hangover harassed hardboard hardened hards hardtop hardworking harken harrumph has haunted haunting heads headwaters heated heaves heist held hellfire helluva hereabouts heres heroics hibachi hid hideout hightail hijacker hipster histrionics hoagy holography homecoming honky hooray hooves hopping horrified horseshoes hubris hype icosahedron idiolect idyll immersed implied impoverished improvised incised inclined including incorporating industrials inherited innards instructions integrated interdisciplinary interfaith interferon intransigence intro ironic irons irritated isometrics itemized ivories jackboot jackpot jacks jaundiced jaws jeepers jetliner jiggered jigging jigsaw jockstrap jumbled junkie karat kcal keystroke kg kid kidding killjoy kilohertz kitsch klutz km knives knockwurst krill
Re: missing words, lots of them
[EMAIL PROTECTED] wrote: These words, 830 of them, were obtained by intersecting the words in a number of lexicons and then subtracting the words in /usr/share/dict/web2. [snip] The point is *not* that these words should be added. The point is that a cursory, in-my-sleep check of the word list shows glaring deficiencies. A serious audit of the list will find way many more missing words (I did a preliminary -- think ~50,000-100,000 missing words if it is supposed to approximate the contents of an unabridged dictionary.) This is to be expected. The word list was created from an very old Webster dictionary, because the copyright had to expire before it could be used in an open source dictionary. Anyway, I'm willing to create a replacement list, if it's likely to actually get used. That would be a welcome contribution to the project. Missing words: [Lots of them deleted] Just my EUR.02 -Christoph Sold To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: missing words, lots of them
Christoph Sold [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: This is to be expected. The word list was created from an very old Webster dictionary, because the copyright had to expire before it could be used in an open source dictionary. I know. :) However, there are several lexicons that have acceptable copyrights. E.g., the Moby list, though I have some reservations about it, is public domain. So there's no good reason to live with an archaic list. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Patch to test kstack usage.
Peter Wemm wrote:
Matt Dillon wrote:
This isn't perfect but it should be a good start in regards to
testing kstack use. This patch is against -stable. It reports
kernel stack use on process exit and will generate a 'Kernel stack
underflow' message if it detects an underflow. It doesn't panic,
so for a fun time you can leave UPAGES at 2 and watch in horror.
It is checking against the wrong guard value. It should be u_guard2.
FWIW; the max stack available is 4688 bytes on a standard 4.x system. Yes,
that is too freaking close. Also, the maximum usage depends on what sort
of cards you have in the system.. If you have a heavy tty user (eg: a 32+
port serial card) then you have lots of tty interrupts nesting as well.
Having the ppp/sl/plip drivers in the system partly negates the effect of
this though since it wires the net/tty interrupt masks together.
usb devices allocate 2K on the stack so if you have them too...
so does openning an atapi cdrom...
so a combination of interrupts and those, might consume 4K
peter@thunder[10:13pm]~-111 ./tu
stack base = 3504
stack size = 4688
peter@thunder[10:13pm]~-112 cat tu.c
#include sys/param.h
#include sys/user.h
#include stdio.h
#include stddef.h
int
main(int ac, char **av)
{
int stack_base = offsetof(struct user, u_kproc);
printf("stack base = %d\n", stack_base);
printf("stack size = %d\n", UPAGES * PAGE_SIZE - stack_base);
}
--- sys/user.h1999/12/29 04:24:49 1.24
+++ sys/user.h2001/09/25 03:41:04
@@ -109,9 +109,13 @@
* Remaining fields only for core dump and/or ptrace--
* not valid at other times!
*/
+ u_int32_t u_guard2; /* guard the base of the kstack */
struct kinfo_proc u_kproc; /* proc + eproc */
struct md_coredump u_md; /* machine dependent glop */
+ u_int32_t u_guard; /* guard the base of the kstack */
};
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
boot source code
Hi, I am looking for the source code used by the boot floppy to load itself into memory. At www.freebsd.org I found a lot of boot source code but I don't really know which one is intersting for me. My platform is i386. Thanks for your help, Christophe. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
4.4 jail and udp
Hi! Looks like jailed processes can't use udp or icmp, but can use tcp: # ping www.freebsd.org ping: socket: Operation not permitted # telnet www.freebsd.org 80 Trying 216.136.204.21... Connected to freefall.freebsd.org. Escape character is '^]'. ^] telnet q Connection closed. # options IPFIREWALL is enabled, net.inet.ip.fw.enable is 0 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
got bad cookie vp 0xe2e5ef80 bp 0xcf317328
I'm starting to see errors in /var/log/messages under 4.2-RELEASE: Sep 23 00:31:17 bmdb1 /kernel: got bad cookie vp 0xe2e5ef80 bp 0xcf317328 Not many, but more than one, and I've never seen this in my years of using FreeBSD. The code producing this message is in /usr/src/sys/nfs/nfs_bio.c, with this associated comment: /* * Yuck! The directory has been modified on the * server. The only way to get the block is by * reading from the beginning to get all the * offset cookies. * * Leave the last bp intact unless there is an error. * Loop back up to the while if the error is another * NFSERR_BAD_COOKIE (double yuch!). */ Is this an error that I need to worry about? Is this just my NFS client loosing track of some bookkeeping details? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.4 jail and udp
In message [EMAIL PROTECTED], Dmitry S. Rzhavin writes: Hi! Looks like jailed processes can't use udp or icmp, but can use tcp: RTFM. UDP works fine. ICMP and other raw socket magic doesn't. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328
What OS is running on the NFS client and server? -- Matthew Emmerton || [EMAIL PROTECTED] GSI Computer Services || http://www.gsicomp.on.ca On Tue, 25 Sep 2001, Brian Reichert wrote: I'm starting to see errors in /var/log/messages under 4.2-RELEASE: Sep 23 00:31:17 bmdb1 /kernel: got bad cookie vp 0xe2e5ef80 bp 0xcf317328 Not many, but more than one, and I've never seen this in my years of using FreeBSD. The code producing this message is in /usr/src/sys/nfs/nfs_bio.c, with this associated comment: /* * Yuck! The directory has been modified on the * server. The only way to get the block is by * reading from the beginning to get all the * offset cookies. * * Leave the last bp intact unless there is an error. * Loop back up to the while if the error is another * NFSERR_BAD_COOKIE (double yuch!). */ Is this an error that I need to worry about? Is this just my NFS client loosing track of some bookkeeping details? -- Brian 'you Bastard' Reichert [EMAIL PROTECTED] 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path 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: 4.4 jail and udp
Poul-Henning Kamp wrote: RTFM. thank you very much! === cut === # man jail | g socket Formatting page, please wait...Done. jail.socket_unixiproute_only UNIX domain sockets, IPv4 addresses, and routing sockets. To enable # man jail | g raw Exit 1 # === /cut === can you tell me please what poor user must read to know about magic words raw socket? ;) sorry... UDP works fine. ICMP and other raw socket magic doesn't. ... and shouldn't? Will it work in future releases, or it is better to forget about icmp for me? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ecc on i386
Peter Wemm writes: Thanks for your description of how ECC is reported on PCs. That was very, very helpful. The Tyan Thunder 2510 BIOS even disables ECC - NMI routing so you have to go to quite a bit of trouble to reprogram the serverworks chipset to actually generate NMI's so that you can find out if something got trashed. Is that the He-Sl or the LE-3 chipset? Is that code available? I have some LE-3 based boxes which I'd like be certain DTRT. Unlike my wife's Dual Athlon, these boxes have nothing in their BIOS pertaining to ECC error reporting. (Supermicro 370-DLE) Our NMI / ECC handling really really sucks in FreeBSD. Consider: - i686_pagezero - reads before writing in order to minimize cache snooping traffic in SMP systems. However, if it gets an NMI while trying to check if the cache line is already zero, it will take the entire machine down instead of just zeroing the line. - NFS / VM / bio: when they get an NMI while trying to copy data that is clean and backed by storage, they take the machine down instead of trying to recover and re-read the page. - userland.. If userland gets an NMI, the machine dies instead of killing the process (or rereading a text page etc if possible) - our NMI handlers are a festering pile of excretement. They dont have the code to 'ack' the NMI so it isn't possible to return after recovery. - and so on. Well, at least we take the machine down, which is a heck of a lot better than ignoring the problem, which is really all that I was hoping for. Thanks again, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328
On Tue, Sep 25, 2001 at 09:54:34AM -0400, Matthew Emmerton wrote: What OS is running on the NFS client and server? My client is the 4.2-RELEASE box in question. There are several servers, all of which (at this point) are Netapps. -- Matthew Emmerton || [EMAIL PROTECTED] GSI Computer Services || http://www.gsicomp.on.ca -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ecc on i386
Thus spake Peter Wemm ([EMAIL PROTECTED]): Our NMI / ECC handling really really sucks in FreeBSD. Consider: [...] Is there any effort to fix this stuff? Considering FreeBSD is still known as one of the best server platforms, this is more important than a multi-threaded kernel or similar stuff, IMO. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ecc on i386
In message [EMAIL PROTECTED] Peter Wemm writes: : - our NMI handlers are a festering pile of excretement. They dont have : the code to 'ack' the NMI so it isn't possible to return after recovery. I have code to do the ack, but people have complained in the past that this code is too chipset specific so I've never committed it. :-( Being able to break to debugger with the NMI switch multiple times sure is nice, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
NFS append race (was Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328)
[Should have included this in my earlier mail, sorry.]
In addition to bad cookies, I also see the following messages very
frequently:
NFS append race @0:954
They're issued in nfs/nfs_bio.c:
/*
* If dirtyend exceeds file size, chop it down. This should
* not normally occur but there is an append race where it
* might occur XXX, so we log it.
*
* If the chopping creates a reverse-indexed or degenerate
* situation with dirtyoff/end, we 0 both of them.
*/
if (bp-b_dirtyend bcount) {
printf(NFS append race @%lx:%d\n,
(long)bp-b_blkno * DEV_BSIZE,
bp-b_dirtyend - bcount);
bp-b_dirtyend = bcount;
}
Any idea what these are about?
Lars
--
Lars Eggert [EMAIL PROTECTED] Information Sciences Institute
http://www.isi.edu/larse/ University of Southern California
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: ecc on i386
Andrew Gallatin wrote: Peter Wemm writes: Thanks for your description of how ECC is reported on PCs. That was very, very helpful. The Tyan Thunder 2510 BIOS even disables ECC - NMI routing so you have to go to quite a bit of trouble to reprogram the serverworks chipset to actually generate NMI's so that you can find out if something got trashed. Is that the He-Sl or the LE-3 chipset? Is that code available? I have some LE-3 based boxes which I'd like be certain DTRT. LE-3 is the one we've been using and the stuff I've tested my hackery with. The main problem is that it currently uses magic bit arithmetic rather than using defined values. I'll clean it up and get it out. I am pretty sure it will work for all the serverworks chips, since the docs for various different chips all describe the same interface. Similarly, the Intel 440BX/GX use the same interface, and I suspect the later ones will as well. We have ECC/NMI drivers for at least the BX/GX as well. Unlike my wife's Dual Athlon, these boxes have nothing in their BIOS pertaining to ECC error reporting. (Supermicro 370-DLE) Serverworks say that ECC *must* be turned on in their manuals. However, whether the bioses do this is another thing. Our NMI / ECC handling really really sucks in FreeBSD. Consider: - i686_pagezero - reads before writing in order to minimize cache snooping traffic in SMP systems. However, if it gets an NMI while trying to check if the cache line is already zero, it will take the entire machine down instead of just zeroing the line. - NFS / VM / bio: when they get an NMI while trying to copy data that is clean and backed by storage, they take the machine down instead of trying to recover and re-read the page. - userland.. If userland gets an NMI, the machine dies instead of killing the process (or rereading a text page etc if possible) - our NMI handlers are a festering pile of excretement. They dont have the code to 'ack' the NMI so it isn't possible to return after recovery. - and so on. Well, at least we take the machine down, which is a heck of a lot better than ignoring the problem, which is really all that I was hoping for. I'll email you some code and start doing some cleanup. Thanks again, Drew Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: termcap sources
Cyrille Lefevre wrote: Giorgos Keramidas wrote: [snip] As you can see there are quite a few terminals that have capabilities defined more than once! I don't have THAT many terminals to check, but I'm open to suggestions. Should we do something about this? If yes, what? this isn't a problem since only the first matching capability is used. others are ignored. I've a pending termcap update related to http://www.tuxedo.org/terminfo. for instance, I don't remember if reorder works w/ termtypes.tc ? done, see PR #30812 : http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30812 Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328
Matthew Emmerton wrote: What OS is running on the NFS client and server? I see these too, with a FreeBSD-4.4 client and SunOS 5.5.1 servers. Seen them with FreeBSD-4.2 clients to the same servers as well. Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Disk based file system cache
Attila Nagy wrote: Hello, I'm just curious: is it possible to set up an NFS server and a client where the client has very big (28 GB maximum for FreeBSD?) swap area on multiple disks and caches the NFS exported data on it? This could save a lot of bandwidth on the NFS server and also redues load on that. There is a configuration called dataless, in which you have local swap for an NFS booted system; this has been supported by SunOS since 1991/1992. It can also be used with FreeBSD, with some rc file tweaking (FreeBSD has seemingly resisted rc file changes to make this kind of division easier, as well as diskless). You are also allowed locacl data storage, with the idea that the OS and utilities, etc. all come off the remote server. The major value would be to mark the VFS type as precache executables to swap... the main failure mode for diskless and dataless SunOS machines has historically been the fact that, when the machine when to swap in a page in an exectable, the server was down, and therefore, all the engineers sit and twiddle their thumbs while their machine is locked up sitting in the page-in path. To combat this, you could have an attribute flag on the FS that indicated it was remote, and thus triggered local swap caching of the executable file image in its entirety, so that demand paging over the network was held to a minimum. This would permit people to continue to do work during a server outage, since the pages will be there. This is an idea I've suggested before. If, on the other hand, you are asking for caching of data file contents for writable files (unlike executables, which are read-only except for the server, since when you run a program, you do not tend to write to its image), then the answer is no, not unless you implement NFSv4. The problem is that, prior to NFSv4, there was not a working distributed cache coherency protocol, so locally cached data can become stale; writebacks to the server by one client can therefore overwrite adjacent but unrelated data written back by another client, if such writes are not restricted to page boundaries (or worse). So that answer is that any system that does this, risks the corruption of its data in the common case (even the simplest case, a mail server whose mailbox files are accessed by a single client machine at a time, will get corruption). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
Matt Dillon wrote: :I had been contemplating making a fake 'struct user' in userland only in :order to keep the a.out coredump reader code happy. The a.out coredump :code (see cpu_coredump() in */*/vm_machdep.c) can generate this fake :structure in order to keep gdb happy. But then I realized that a.out :coredump debugging was almost totally irrelevant these days. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Hmm. How about this... if we keep the guard field at the end of struct user we could #ifdef _KERNEL it so userland doesn't notice it. -Matt So, Matt, does this solve the original question? (VM Corruption) or is it just a fruitful red-herring? -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
:Ok, time to take a good stab at sticking my foot in my mouth here. : :Would it be possible to have a kernel mode where the read-only bit was :turned on for malloc pools which shouldn't currently be accessed? This :could be gated through the spl() calls (or specific mutexes on -current), :ensuring that something like getpid couldn't stomp on the vm structures :w/o first doing a splvm(). Kinda sounds like Multics :-)... no, it would be too messy trying to protect kernel structures in one subsystem from another. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
:I had been contemplating making a fake 'struct user' in userland only in :order to keep the a.out coredump reader code happy. The a.out coredump :code (see cpu_coredump() in */*/vm_machdep.c) can generate this fake :structure in order to keep gdb happy. But then I realized that a.out :coredump debugging was almost totally irrelevant these days. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Hmm. How about this... if we keep the guard field at the end of struct user we could #ifdef _KERNEL it so userland doesn't notice it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
:So, Matt, does this solve the original question? (VM Corruption) or :is it just a fruitful red-herring? :-- :++ __ _ __ :| __--_|\ Julian Elischer | \ U \/ / hard at work in It seems unlikely to me, but you never know. Certainly this is a problem that has to be fixed now. I've bumped -stable's UPAGES up to 3 but we absolutely have to MFC the fixes for the two devices allocating 2K stacks. Maybe I should have bumped UPAGES up to 4 :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: librsa and 4.4
Julian Elischer wrote: In a related problem: we have a set of 4.1.1 binaries we want ot run on 4.4 but they (apache+other stuff) want to find a librsaUSA.so but can't.. I fixed it by copying the one from 4.1.1 into /usr/lib/compat. Is that the right answer? Is it possible we can have a compat librsa? (maybe even empty if the stuff is now in libcrypt or something). libcrypto.so.1.gz.uu and libssl.so.1.gz.uu need to be MFC'ed. This should have been done before 4.4-REL as well. On Tue, 25 Sep 2001, Paul Saab wrote: set COMPAT4X=yes in make.conf cd /usr/lib/compat make make install Julian Elischer ([EMAIL PROTECTED]) wrote: I seem to have cvsupp'd at a bad moment.. various older ( e.g. Netscape) have the following problem: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp so I figure: I'll cvsup again.. but: + /usr/local/bin/cvsup -L1 -P - /tmp/501.supfile /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp Is here a quick workaround? (I still have connectivity and CVS just no netscape, KDE or cvsup..) (by workaround I mean a manual patch I should apply somewhere to get me up and going again after another buildworld). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM Corruption - stumped, anyone have any ideas?
I really don't think it is necessary to hack up GCC to figure out stack utilization. We have issues with only a few drivers and it is fairly trivial (as my patch shows) to throw a pattern into the kernel stack to determine how much is actually used. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
IMPORTANT!! Re: panic on mount
Hello, Just to clarify things for everyone who may be having this probme: there is a panic on bootup with current, within the witness* code. You can avoid this by commenting out WITNESS in your kernel configuration and recompiling. It worked for me.. Hope this helps someone. Thanks, Evan John Baldwin writes: On 25-Sep-01 Bill Fenner wrote: I also started getting this error with recent kernels (in the last day or so). It looks like the mutex is really held since the mtx_assert before witness_unlock didn't trigger. You can try turning witness off for the time being as a workaround. I'm not sure why witness would be broken, however. Mounting root from ufs:/dev/ad0s1a panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vfs_default.c:460 Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db t Debugger(c03c5bbb) at Debugger+0x44 panic(c03c8c40,c03c4b80,c03ccf20,c03cc8a0,1cc) at panic+0x70 witness_unlock(c7765f2c,8,c03cc8a0,1cc,c7765f2c,1,c03c4ba0,f6) at witness_unlock+0x1d0 _mtx_unlock_flags(c7765f2c,0,c03cc8a0,1cc,c0567bd0) at _mtx_unlock_flags+0x59 vop_nolock(c0567be8,c0567bf8,c02920c2,c0567be8,c0567d4c) at vop_nolock+0x24 vop_defaultop(c0567be8) at vop_defaultop+0x15 vn_lock(c7765ec0,20002,c049f7c4,c0567d4c,c1346680) at vn_lock+0xca ffs_mountfs(c7765ec0,c1351600,c049f7c4,c0446900,c0567d4c) at ffs_mountfs+0x7e ffs_mount(c1351600,0,0,0,c049f7c4) at ffs_mount+0x67 vfs_mountroot_try(c05447a8,c03cc48c) at vfs_mountroot_try+0x14e vfs_mountroot(0,564c00,564000,0,c012caac) at vfs_mountroot+0x5a mi_startup() at mi_startup+0x90 begin() at begin+0x43 I dunno how to get a dump from this point since kern.dumpdev hasn't been set.. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
