Re: STABLE kern/13546: Too-verbose output from PCI probe at bootup
> >The code which figures out the bushigh stuff for your machine > >probably needs a similar kludge, unless someone can say for certain > >that it isn't harful for the SMP case. > > Probably not worth the effort, since for this system at least, SMP works > just fine after probing for 253 non-existent PCI buses. The "if > (bootverbose)" just keeps it from blowing the dmesg buffer at bootup. It seemmed to work fine for us too, but if there is a possibility of some problem it's probably worth working around "properly". It only takes about 4 lines of code. (Unless someone can say this is definitely harmless in the SMP case) > (The CURRENT code doesn't even look for this "bushigh" value nor display > the "Probing" message.) All the more reason to get it right in STABLE. David. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: High Availability (Re: MAC takeover )
> Another issue: I was recently involved in a project which required HA
> solutions (that's why I asked]. I gathered a lot of ideas and materials
> (and perhaps some code if that company agrees to release it). Is ther
> someone else here who is interested in these issues, and using FreeBSD for
> that? We could start some info pages, howto's, and perhaps a mailing
> list...
Definitely... I use FreeBSD for critical medical applications (no life
support equipment, though.. :) ) Although the main DB server is running
on an Alpha under DEC Unix (for legal reasons, not by choice), the rest of
the network is "powered by FreeBSD". Failures are rare, but when they
happen, my pager goes off immediately, and I get to drop whatever I'm
doing and head off to work. HA capabilities like this would really help
out -- most of the software running is duplicated between machines so one
box can take over another's workload if necessary, but it's a manual job
doing all the switching... (IP aliasing, NATD/IPFW changes, etc. just to
move DNS and printing to another box, for example.) Although our
switching equipment has an "understanding" of path redundancy and other HA
techniques, most of the other boxes don't...
I suppose the first thing I'd make use of would be the ability to drop two
ethernet cards (fxp, probably) into each machine -- if one of them croaks
("network cable yanked -- you mean I can't plug a phone into this
jack???" is the most frequent problem), the other one would be brought
online automatically -- preferrably with the same ethernet address to
avoid confusing the rest of the network.
--mike
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: High Availability (Re: MAC takeover )
Mike Nowlin wrote: > > > Another issue: I was recently involved in a project which required HA > > solutions (that's why I asked]. I gathered a lot of ideas and materials > > (and perhaps some code if that company agrees to release it). Is ther > > someone else here who is interested in these issues, and using FreeBSD for > > that? We could start some info pages, howto's, and perhaps a mailing > > list... > > Definitely... ... the same situation here. And I think that a lot of ISP would at appreciate at least some basic HA support in FreeBSD. Milon -- pape...@pvt.net, but speaking on my own. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Problem with SMP in 3.3-RC
I have been running a 3.2-STABLE from around June 1st on my Asus P2B-D with 2 400MHz PII CPUs (128MB memory) without any problems. Yesterday I cvsup'ed RELENG_3 and now SMP doesn't work anymore. Halfway through /etc/rc some severe memory corruption seems to occur as all new processes core dumps immediately on signal 11. Finally the machine locks up and the reset button it the only way out. Same kernel without SMP works fine. Looking through the commitlogs, I found the two entries below that could be related. So I checked out a RELENG_3 src/sys from 1999/08/29, but that kernel failes in the same way. Tonight I will try to compile and run an older RELENG_3 GENERIC kernel. Does anyone have any idea of what's causing this problem? Is there some driver that doesn't work with SMP? msmith 1999/08/30 18:19:33 PDT MFC: Intel 686 and AMD K6/2 memory range attribute support. This merge brings all of the memory range attribute support from -current back to -stable, as requested by a number of folks. msmith 1999/09/02 16:57:06 PDT Bring back the rest of the changes required to make memory range support work on SMP systems. Tested by various folks on the -stable list, thanks for their patience and support. -- Mikael HybschEmail: mi...@securitydynamics.com Security Dynamics AB Phone: +46-8-7250900 Box 10704Fax: +46-8-6494970 S-121 29 STOCKHOLM, SWEDEN To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > > I'm assuming you actually have a Winbond card. If you do, try this for > > Yah, some Unicom card, I think. > > > me: connect the Winbond to a link partner who's media settings you can > > [ . . . snip . . . ] > > > Winbond that if I changed the link partner's speed settings, it would > > start DMAing all kinds of crap into the host's memory. Furthermore, I > > think it ignores the RX buffer lengths specified in the receive descriptor > > ring and trashes various chunks of memory that it shouldn't, leading to > > a crash. Given that I never observed this behavior with any of the other > > tulip clones using similar code, I was pretty sure this was a chip bug and > > not some horrible coding error that I had made somewhere. > > Yes, I have seen exactly this. I could only get it to happen if I changed > the Winbond's link partner from 10 -> 100 while the Winbond was still in 10. That sounds right. > I see the TDSTAT_Rx_FS and TDSTAT_Rx_LS bits cleared in the descriptor, > as well. When I see this condition occur, I attempt to reset the chip. > This does NOT help this condition on the Winbond. It's thorougly wedged. > > Oh yay, cheap chips. > > > I saw this with at least three separate Winbond cards and I tried my > > best to detect the condition and smack the chip upside the head to make > > it stop, but I'd be interested to see somebody else duplicate the problem > > and give me their take on it. > > Were you ever able to smack it and make it stop? :-) Well, yes, but I made some assumptions in order to do it. The assumption is that whatever the current speed setting is now, the link partner's speed setting is exactly opposite. So if I detect the condition, I first toggle the speed setting (if it's IFM_10_T, make it IFM_100_TX and vice- versa), then do a reset, then re-init the chip. However, the main problem is keeping the chip from zapping memory that it doesn't own. Normally I use mbuf cluster buffers in the receive ring, but I would only tell the chip that the buffer was 1536 bytes long instead of 2048. But again, it seemed like the chip was DMAing much more data than it should have been and overruning the whole cluster. Since I needed to copy received packets in order to fix up the alignment anyway, I stopped using mbuf clusters and instead allocated my own 4K receive buffers and told the chip to DMA into those, on the theory that it may have been barfing up the entire contents of its FIFO memory which was more than 2048 bytes. Sure, most of the time you waste a lot of those 4K blocks, but at least when the chip freaks out it doesn't trash any memory that you don't know about. The driver in -current has code that swaps the speed setting and the extra large buffers; originally I just tried to reset the chip and swap the speed as fast as possible, but this proved not to work too well once I started using the miibus sublayer so I had to revisit the whole thing and come up with a better solution. > > Also, just out of curiosity, have you ever observed the PNIC receiver > > bug that gave me so many fits? > > I observed it briefly back when there were still some pretty basic bugs > in the driver, which have since been squashed. I haven't seen it since. > I'm aware of the nature of the problem and your work-around. I'm hoping > I don't need to implement it :-) Unfortunately, I'm still not sure how to trigger it reliably so I can't tell you exactly where or when you might see it. > I have seen some pretty awful problems with the PNIC, tho. The DMA engine > is a piece of crap. On a 500MHz AlphaStation 500, who's PCI bus can surely > keep up with a cheap fast Ethernet board, the PNIC gets constant DMA underruns > unless in Store-and-Forward mode, *including the setup frame*. I have to > initialize the chip into S-F mode just to get the damn filter programmed :-) > > I also noticed that DMA underruns don't abort the transmit pipe on the PNIC. > Every DMA underrun on a real packet corresponded to a junk frame hitting > the wire. A short frame I could understand... but we're talking even the > Ethernet header is toast. > > Another interesting problem I've been seeing; The very first setup frame > fails to complete. All subsequent setup frames succeed. Including setup > frames sent after an ifconfig down/up. Utterly bizarre. > > Oh yay, cheap chips. Bleh. My experience with the PNIC shows that it does not handle multi-fragment transmits very well (i.e. a packet split across multiple buffers instead of just a single configuous buffer). Lite-On claims that they get pretty good transmit speed with the PNIC, however I'm certain they do their measurements using only single buffer transmits. I typically don't see more than about 80-85Mbps, though others using the Linux driver (which doesn't use multi-fragment transmits) have claimed better performance (90-95Mbps). On
ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
--- Begin Message --- --- End Message ---
ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa
We've had a group (including representatives from LSB, Mesa, Metro Link, NVIDIA, PTC, Precision Insight, SGI, XFree86, and Xi Graphics) working on a proposal for standardizing X11 OpenGL/Mesa ABI and SDK issues on Linux. The purpose is to allow applications to build against any implementation following this standard and the resulting binaries to run against any other implementation; this interoperability will be increasingly important as the amount of 3D activity on Linux grows and the variety of drivers increases even further. The "0.9" draft of the proposal can be found at http://reality.sgi.com/opengl/linux/linuxbase.html A mailing list has been created for further discussion and finalization of this proposal. We're unable to follow discussions in all the forums where this announcement is being made, so if you want to have an effect, please join this mailing list. We particularly solicit participation by ISVs writing OpenGL-based applications on Linux, IHVs writing OpenGL drivers on Linux, and Linux distributions. To initially subscribe to the list, send a message with body subscribe oglbase-discuss to 'external-majord...@corp.sgi.com'. To participate in the list after you've subscribed, send messages to 'oglbase-disc...@corp.sgi.com'. To unsubscribe to the list, send a message containing the body unsubscribe oglbase-discuss to external-majord...@corp.sgi.com. Jon Leech (For the Linux/OpenGL Base working group) SGI - FAQ and OpenGL Resources at: http://www.geocities.com/SiliconValley/Hills/9956/OpenGL -- Author: Jon Leech INET: game...@oddhack.engr.sgi.com Fat City Network Services-- (619) 538-5051 FAX: (619) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: listg...@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). --- =_aa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18422.93680561...@ariadne.prth.tensor.pgs.com> -- 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 --- =_aa0-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
The usage of MNT_RELOAD
The flag MNT_RELOAD is not documented in mount manpages. From the source code, I find that it is always used along with MNT_UPDATE which can be speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD for me? It seems not to be used normally. Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, Sep 08, 1999, Zhihui Zhang wrote: > > The flag MNT_RELOAD is not documented in mount manpages. From the source > code, I find that it is always used along with MNT_UPDATE which can be > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > for me? It seems not to be used normally. It looks like it 'reloads' the file system when you change the mount flags, e.g. changing a synchronous file system to an asynchronous file system, without really un-mounting it. -- |Chris Costello |Base 8 is just like base 10, if you are missing two fingers. - Tom Lehrer `-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
> The flag MNT_RELOAD is not documented in mount manpages. From the source > code, I find that it is always used along with MNT_UPDATE which can be > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > for me? It seems not to be used normally. > > Any help is appreciated. > > -- > Zhihui Zhang. Please visit http://www.freebsd.org > -- > It is created almost exclusively for fsck (and similar programs) to update the in core image of the superblock (of / in single user mode) after the on disk version has been modified. -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
panic.. 3.2-STABLE-OLD...
Well, it has been a long time since I have needed to write an email with that tagline. Our primary NFS server had been up for almost 2 months with no panics. We did need to reboot it for a network change, but it was up for 28 days at that point. Anyway here are the details: dev = 0x20014, block = 2096, fs = /exports/home3 panic: ffs_blkfree: freeing free block #0 0xc014b6cb in boot () #1 0xc014b950 in at_shutdown () #2 0xc01d50ef in ffs_blkfree () #3 0xc01d992c in indir_trunc () #4 0xc01d9688 in handle_workitem_freeblocks () #5 0xc01d7c28 in softdep_process_worklist () #6 0xc016f9b4 in sched_sync () #7 0xc013e56a in kproc_start () #8 0xc020328a in fork_trampoline () UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -18 0 00 sched DLs ??0:00.00 (swapper) 0 1 0 0 10 0 4960 wait Is??0:00.00 (init) 0 2 0 0 -18 0 00 - RL??0:00.00 (pagedaemon 0 3 0 0 18 0 00 psleep DL??0:00.00 (vmdaemon) 0 4 0 272 -6 0 00 - RL??0:00.00 (syncer) 042 1 0 10 0 2629000 mfsidl ILs ??0:00.00 (mount_mfs) 0 140 1 0 2 0 8160 - Rs??0:00.00 (syslogd) 0 150 1 14 2 -12 10480 - Rhttp://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
As Jason Thorpe wrote ... > On Tue, 7 Sep 1999 03:11:24 -0400 (EDT) > Bill Paul wrote: > > > The SiS 900 only has one combined status/control word in its > > descriptor structure (some of the bits mean different things depending > > on whether the descriptors are in the RX ring or TX ring) instead of a > > separate status and control word. The descriptors are also only 3 > > longwords in size. ... > BTW, you forgot EISA (DE-425) ... when I finish all the clone support There was also an DE-422 EISA card. Dunno if they are different. Do you have/want one? I could try to get you one. EISA is dead of course, but older machines tend to have EISA slots to spare, and PCI in short supply. Wilko -- | / 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-hackers" in the body of the message
32+ signals and library versions
Hi, Another issue when sigset_t changes is the version numbers of shared libraries. Since libc and libc_r have changed on the interface level, they need a version bump. I assume that all others automaticly also need a version bump then. Am I correct in this assumption? -- Marcel Moolenaarmailto:mar...@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:mar...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Fequent panics in FreeBSD 3.3-RC
Hi, I last night I have upgraded a system to the latest stable, and have already received two of these panics: uname -a reads FreeBSD addr3.addr.com 3.3-RC FreeBSD 3.3-RC #0: Tue Sep 7 21:57:07 GMT 1999 r...@addr3.addr.com:/usr/src/sys/compile/ADDRKERN i386 the panic reads: Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0100 fault virtual address = 0xc4e7f08c fault code = supervisor write, page not present instruction pointer = 0x8:0xc025f47a stack pointer = 0x10:0xd2ed2f0c frame pointer = 0x10:0xd2ed2f1c 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 = 12498 (httpd) interrupt mask = net tty bio cam <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = 0100 boot() called on cpu#1 nm /kernel for that area shows: c025f314 T pmap_page_exists c025f30c T pmap_pageable c025f3a4 T pmap_remove_pages c025f4e0 t pmap_testbit The server is a dual PentiumIII-450 with 512 MB of ram and DPT raid controller. Max users is set at 256 (I don't know about this version, but on previous versions setting it higher caused constant panics). It usually runs at load average of about 2, serving apache/sendmail/telnet/ftpd/ipop3d as well as a little bit of NFS data for local updates and a completely idle NFS client. I am unable to trace the panic to any particular event, the system can run high load with no problems and one of the panics was in the evening when the system was running at only 0.5 load average. If you need any more info I would be glad to provide it. Any help regarding this problem would be greatly appreciated. Best Regards, Anthony Bourov To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fequent panics in FreeBSD 3.3-RC
> Hi, > > I last night I have upgraded a system to the latest stable, and have > already received two of these panics: Do you have APM enabled on this system, even just in the BIOS? > uname -a reads > FreeBSD addr3.addr.com 3.3-RC FreeBSD 3.3-RC #0: Tue Sep 7 21:57:07 GMT 1999 >r...@addr3.addr.com:/usr/src/sys/compile/ADDRKERN i386 > > the panic reads: > Fatal trap 12: page fault while in kernel mode > mp_lock = 0102; cpuid = 1; lapic.id = 0100 > fault virtual address = 0xc4e7f08c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc025f47a > stack pointer = 0x10:0xd2ed2f0c > frame pointer = 0x10:0xd2ed2f1c > 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 = 12498 (httpd) > interrupt mask = net tty bio cam <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0102; cpuid = 1; lapic.id = 0100 > boot() called on cpu#1 > > nm /kernel for that area shows: > > c025f314 T pmap_page_exists > c025f30c T pmap_pageable > c025f3a4 T pmap_remove_pages > c025f4e0 t pmap_testbit > > The server is a dual PentiumIII-450 with 512 MB of ram and DPT raid > controller. Max users is set at 256 (I don't know about this version, but > on previous versions setting it higher caused constant panics). It usually > runs at load average of about 2, serving apache/sendmail/telnet/ftpd/ipop3d > as well as a little bit of NFS data for local updates and a completely idle > NFS client. > I am unable to trace the panic to any particular event, the system can run > high load with no problems and one of the panics was in the evening when > the system was running at only 0.5 load average. > If you need any more info I would be glad to provide it. Any help regarding > this problem would be greatly appreciated. > > Best Regards, > Anthony Bourov > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Superblock.
So... I lost my partition table. I'm willing to spend a little time on this. Is there a byte sequence that I might recognise in a superblock or at the start of a partition? I know this isn't an easy task, but man 5 fs leads me to believe that I might find: #define FS_MAGIC0x011954 /* the fast filesystem magic number */ #define FS_OKAY 0x7c269d38 /* superblock checksum */ ... but I don't see those bytes. Any hints? I'm willing to post a description of a solution for the FAQ if I can find the filesystems. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilb...@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Luoqi Chen wrote: > > The flag MNT_RELOAD is not documented in mount manpages. From the source > > code, I find that it is always used along with MNT_UPDATE which can be > > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > > for me? It seems not to be used normally. > > > It is created almost exclusively for fsck (and similar programs) to update > the in core image of the superblock (of / in single user mode) after the > on disk version has been modified. > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes sense to me: if fsck modifies the on-disk copy of the superblock, it does not have to unmount and then remount the filesystem, it only need to reload the superlock for disk. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
Nice Idea however wrong operating system. The losers should have done it for FreeBSD instead of linux. -- Amancio Hasty ha...@rah.star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes > sense to me: if fsck modifies the on-disk copy of the superblock, it does > not have to unmount and then remount the filesystem, it only need to > reload the superlock for disk. I think it's more for the case where fsck has to run on a filesystem which is mounted. It's better to fsck unmounted filesystems, but you don't always have that option (say you want to fsck the fs with fsck on it :-) Take care, Bill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > On Wed, 8 Sep 1999, Luoqi Chen wrote: > > > It is created almost exclusively for fsck (and similar programs) to update > > the in core image of the superblock (of / in single user mode) after the > > on disk version has been modified. > > > > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes > sense to me: if fsck modifies the on-disk copy of the superblock, it does > not have to unmount and then remount the filesystem, it only need to > reload the superlock for disk. The root filesystem is mounted when it is fscked, as it is difficult to run fsck, which lives on the root filesystem, without mounting the root filesystem. You shouldn't run fsck on a mounted filesystem, except for this. The results are generally not fun. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > On Wed, 8 Sep 1999, Luoqi Chen wrote: > > > > The flag MNT_RELOAD is not documented in mount manpages. From the source > > > code, I find that it is always used along with MNT_UPDATE which can be > > > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > > > for me? It seems not to be used normally. > > > > > It is created almost exclusively for fsck (and similar programs) to update > > the in core image of the superblock (of / in single user mode) after the > > on disk version has been modified. > > > > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes > sense to me: if fsck modifies the on-disk copy of the superblock, it does > not have to unmount and then remount the filesystem, it only need to > reload the superlock for disk. > Filesystems do not have to be mounted to fsck them (in fact, it is generally bad to have them mounted rw when fsck'd); however, in order for the root filesystem to be fsck'd on boot, it must be mounted ro in order to access the fsck program itself. After done fsck'ing, it can remount rw for normal operation, done without actually unmounting the filesystem. - Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
:> Does fsck have to run on a MOUNTED filesystem? If so, your answer makes :> sense to me: if fsck modifies the on-disk copy of the superblock, it does :> not have to unmount and then remount the filesystem, it only need to :> reload the superlock for disk. : :The root filesystem is mounted when it is fscked, as it is difficult to run :fsck, which lives on the root filesystem, without mounting the root :filesystem. You shouldn't run fsck on a mounted filesystem, except for :this. The results are generally not fun. : :David Scheidt The root filesystem is mounted *READ-ONLY* initially. fsck is then run on all filesystems. Once fsck is done the root filesystem is remounted R/W and the remaining filesystems are mounted R/W. It's relatively safe to run fsck on a filesytem which has been mounted read-only. It is not safe to run fsck on a filesystem which has been mounted R/W. It is best, of course, to run fsck only on filesystems that have not been mounted but this cannot be done for the root filesystem for obvious reasons, hence the read-only mount + fsck + remount R/W. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> Another issue when sigset_t changes is the version numbers of shared > libraries. Since libc and libc_r have changed on the interface level, they > need a version bump. I assume that all others automaticly also need a > version bump then. Am I correct in this assumption? Libc_r already had a version bump in -current without a subsequent release. You do not want to give it another one. Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> Another issue when sigset_t changes is the version numbers of shared > libraries. Since libc and libc_r have changed on the interface level, they > need a version bump. I suggest to try to avoid the version bump. NetBSD-like way to do it: Give new implementations another names in object files, so that they don't conflict with old implementations, and preserve old implementations in the library too. To make the compiler generate calls to new implementations, one can add appropriate #define s in .h files. For GCC, __asm__ attribute also can be used. Dima To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with SMP in 3.3-RC
On Wed, 8 Sep 1999, I wrote: > Yesterday I cvsup'ed RELENG_3 and now SMP doesn't work anymore. > Halfway through /etc/rc some severe memory corruption seems to occur > as all new processes core dumps immediately on signal 11. Finally the > machine locks up and the reset button it the only way out. > Same kernel without SMP works fine. > The problem turned out to be that apm0 and SMP don't like each other. A kernel built from sources around Aug 20 works with apm0 and SMP. After that some apm related checkins were done that seems to have changed that. -- Mikael HybschEmail: mi...@securitydynamics.com Security Dynamics AB Phone: +46-8-7250900 Box 10704Fax: +46-8-6494970 S-121 29 STOCKHOLM, SWEDEN To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Superblock.
On Wed, Sep 08, 1999 at 01:46:18PM -0400, David Gilbert wrote: > So... I lost my partition table. I'm willing to spend a little time > on this. Is there a byte sequence that I might recognise in a > superblock or at the start of a partition? I know this isn't an easy > task, but man 5 fs leads me to believe that I might find: > > #define FS_MAGIC0x011954 /* the fast filesystem magic number */ > #define FS_OKAY 0x7c269d38 /* superblock checksum */ > > ... but I don't see those bytes. Any hints? > > I'm willing to post a description of a solution for the FAQ if I can > find the filesystems. > > Dave. It's better to find a whole disklabel. According to the disklabel(5): #define DISKMAGIC ((u_long) 0x82564557) /* The disk magic number */ My disk is set in dedicated mode, so: # dd if=/dev/da0c bs=1 skip=1b count=4 | hd 4+0 records in 4+0 records out 4 bytes transferred in 0.022311 secs (179 bytes/sec) 57 45 56 82 |WEV┌| 0004 HTH, -- Ruslan Ermilov Sysadmin and DBA of the r...@ucb.crimea.ua United Commercial Bank, r...@freebsd.orgFreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
In message <199909081811.laa88...@apollo.backplane.com> Matthew Dillon writes: : It is best, of course, to run fsck only on filesystems that have not : been mounted but this cannot be done for the root filesystem for obvious : reasons, hence the read-only mount + fsck + remount R/W. Back in the Bad Old Days, when this option didn't exist, if fsck changed ANYTHING on /, the system rebooted... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Superblock.
On Wed, Sep 08, 1999 at 01:46:18PM -0400, David Gilbert wrote: > So... I lost my partition table. I'm willing to spend a little time > on this. Is there a byte sequence that I might recognise in a > superblock or at the start of a partition? I know this isn't an easy > task, but man 5 fs leads me to believe that I might find: > > #define FS_MAGIC0x011954 /* the fast filesystem magic number */ > #define FS_OKAY 0x7c269d38 /* superblock checksum */ > > ... but I don't see those bytes. Any hints? > > I'm willing to post a description of a solution for the FAQ if I can > find the filesystems. > > Dave. Search the hackers mailing list for a mail from me, which contains a C program to do the work for you. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Superblock.
On Wed, Sep 08, 1999 at 01:46:18PM -0400, David Gilbert wrote: > So... I lost my partition table. I'm willing to spend a little time > on this. Is there a byte sequence that I might recognise in a > superblock or at the start of a partition? I know this isn't an easy > task, but man 5 fs leads me to believe that I might find: > > #define FS_MAGIC0x011954 /* the fast filesystem magic number */ > #define FS_OKAY 0x7c269d38 /* superblock checksum */ > > ... but I don't see those bytes. Any hints? > > I'm willing to post a description of a solution for the FAQ if I can > find the filesystems. > If you have problems finding it, let me know - I'll send a copy (which is currently at home.) Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Fequent panics in FreeBSD 3.3-RC
In article <199909081736.kaa04...@dingo.cdrom.com>, you say... > >> Hi, >> >> I last night I have upgraded a system to the latest stable, and have >> already received two of these panics: > >Do you have APM enabled on this system, even just in the BIOS? > If enabling 'device apm...' with SMP is a no no now, do anyone have another recommanded fix/workaround for running top with ASUS P2-B SMP? Regards > [snip] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT) Bill Paul wrote: > Well, yes, but I made some assumptions in order to do it. The assumption > is that whatever the current speed setting is now, the link partner's > speed setting is exactly opposite. So if I detect the condition, I first > toggle the speed setting (if it's IFM_10_T, make it IFM_100_TX and vice- > versa), then do a reset, then re-init the chip. ...hm... okay, I'll investigate this option. > However, the main problem is keeping the chip from zapping memory that it > doesn't own. Normally I use mbuf cluster buffers in the receive ring, but > I would only tell the chip that the buffer was 1536 bytes long instead of > 2048. But again, it seemed like the chip was DMAing much more data than > it should have been and overruning the whole cluster. Since I needed to > copy received packets in order to fix up the alignment anyway, I stopped > using mbuf clusters and instead allocated my own 4K receive buffers and > told the chip to DMA into those, on the theory that it may have been > barfing up the entire contents of its FIFO memory which was more than > 2048 bytes. Sure, most of the time you waste a lot of those 4K blocks, > but at least when the chip freaks out it doesn't trash any memory that > you don't know about. Um. Ew. Okay. Sigh. In NetBSD, we only copy if the system doesn't have __NO_STRICT_ALIGNMENT (e.g. i386, m68k [we support some PCI m68k boxes], VAX [all those PCI vaxes, you know!)... I'll have to see what I can do about all of this. > Bleh. My experience with the PNIC shows that it does not handle > multi-fragment transmits very well (i.e. a packet split across multiple > buffers instead of just a single configuous buffer). Lite-On claims > that they get pretty good transmit speed with the PNIC, however I'm > certain they do their measurements using only single buffer transmits. > I typically don't see more than about 80-85Mbps, though others using > the Linux driver (which doesn't use multi-fragment transmits) have > claimed better performance (90-95Mbps). On a whim, I decided one day > to disable the code in pn_encap() that splits the outbound packet up > amount multiple descriptors and just let it copy all packer fragments > into a single buffer -- transmit performance actually got a little > faster. That's ... scary. Y'know, since real 21143s are *still available* (Intel is still manufacturing them!) you'd think the companies that used to put Tulips on their boards would still use them ... oh well. > My biggest problem with this stupid thing now is trying to get to work > on the 486/66 that I'm currently using for testing. It has an old Integrated > Micro Systems PCI bridge and the PNIC seems to have decided not to be > friends with it: the machine tends to freeze up solid whenever the chip > does any DMA, including just loading the setup frame. It it trying to use Memory-Read-Multiple or Memory-Read-Line? Old (esp. 486) PCI bridges were known to have problems with those PCI commands. > http://www.freebsd.org/~wpaul/PNIC/pnic.ps.gz Excellent! Thank you very much! > I've also got a Winbond datasheet at: > > http://www.freebsd.org/~wpaul/Winbond/winbond.ps.gz > > The originals of both these documents were in M$ Turd format. :) Already have this one; the Winbond datasheet is available at www.winbond.com.tw in PDF form... > All of the Winbond cards are essentially the same so the one you have > should be enough -- mine is from a company called Trendware. The PNIC > is a bit tougher to deal with because there are a couple of revisions: > the original LinkSys PNIC cards use the 82c168 and the internal busted > NWAY support (i.e. no MII transceiver). For these you have to fiddle > with the GPIO bits to flip the relay on the card (yes, a relay) in order Heh... I have a Kingston 21140 board that uses the PCS function to do 100baseTX, and you hear a relay flip on that board too :-) On these PNIC boards which use the external ENDEC / PCS ... I guess you'd be able to detect which flavor you have (for flipping the GPIO pins) using the subsystem IDs in PCI configuration space... The PNIC doesn't use the DEC-format SROM, unfortunately, so just getting CSR6 and CSR12 from the SROM isn't an option... > to select the right media. The trouble is LinkSys doesn't sell them > anymore: the later cards use the 82c169, and now they've gone to the > PNIC II. I had some 82c168 cards donated by FreeBSD users. I can part > with one of them if you can't find one anywhere. As for the Macronix, I would appreciate this... I haven't been able to find '168 boards at all. > ideally you need one each of the 98713, 98713A and 98715A. The 98713 I have a '15A board... I know of a NetBSD user who has a '13 board (he sent in patches to make it work with the `de' driver initially). > look at the application notes from Macronix, they mention the "magic > numbers" you need to program into CSR15
Re: Fequent panics in FreeBSD 3.3-RC
> In article <199909081736.kaa04...@dingo.cdrom.com>, you say... > > > >> Hi, > >> > >> I last night I have upgraded a system to the latest stable, and have > >> already received two of these panics: > > > >Do you have APM enabled on this system, even just in the BIOS? > > If enabling 'device apm...' with SMP is a no no now, do anyone have another > recommanded fix/workaround for running top with ASUS P2-B SMP? Get the BIOS revision that works; this was discussed a while back. I seem to recall that a something-11 BIOS was broken, but the something-10 revision worked. You can get better information by searching the lists. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: STABLE kern/13546: Too-verbose output from PCI probe at bootup
>It seemmed to work fine for us too, but if there is a possibility
>of some problem it's probably worth working around "properly". It
>only takes about 4 lines of code. (Unless someone can say this
>is definitely harmless in the SMP case)
Ok, here's the proper fix. Turns out that this 4xPPro box has two
"Orion" chips in it, and the code that picks off the number of
subordinate buses returns 255 for whatever reason. The fix is copied
from the fixbushigh_450nx() routine into the fixbushigh_orion() routine,
which appears to have the same problem.
The fix could be made generic and moved out of both bushigh routines if
there are no systems out there with 255 subordinate buses. The magic
number 255 may mean different things to different chipsets so I settled
for this Orion-specific fix.
Better? Anyone out there with 255 Orion chips in their system?
-- Parag Patel
*** /sys/pci/pcisupport.c Sat Sep 4 04:02:49 1999
--- pcisupport.cWed Sep 8 12:03:00 1999
***
*** 129,134
--- 129,149
{
tag->secondarybus = pci_cfgread(tag, 0x4a, 1);
tag->subordinatebus = pci_cfgread(tag, 0x4b, 1);
+
+ if (tag->subordinatebus == 255) {
+ printf("fixbushigh_orion: bogus highest PCI bus %d",
+ tag->subordinatebus);
+ #ifdef NBUS
+ tag->subordinatebus = NBUS - 2;
+ #else
+ tag->subordinatebus = 10;
+ #endif
+ printf(", reduced to %d\n", tag->subordinatebus);
+ }
+
+ if (bootverbose)
+ printf("fixbushigh_orion: subordinatebus is %d\n",
+ tag->subordinatebus);
}
static void
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: K6 Write Combining & FreeBSD
As Brian F. Feldman wrote ... > On Tue, 7 Sep 1999, Wilko Bulte wrote: > > > Wilko (confused...) > > No, I already committed the change to comment it out in -STABLE. I will > investigate further, but I will definitely not have it in by -RELEASE time. OK, clear. I was just worried it would silently sneak itself in 3.3R. 3.3-RC suddenly sporting it sort of worried me.. > No problem has been noticed before because XFree86 has not supported MTRRs > until recently (snapshots of pre-4.0.) I am going to see what could be > wrong, and possibly reenable the code at a later date. For now, it's > considered "dangerous" and you shouldn't mess with it unless you are willing > to accept the risks that entails. The first thing I did was comment it out, even before I got this email ;-) Thanks, Wilko -- | / 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-hackers" in the body of the message
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > > However, the main problem is keeping the chip from zapping memory that it > > doesn't own. Normally I use mbuf cluster buffers in the receive ring, but > > I would only tell the chip that the buffer was 1536 bytes long instead of > > 2048. But again, it seemed like the chip was DMAing much more data than > > it should have been and overruning the whole cluster. Since I needed to > > copy received packets in order to fix up the alignment anyway, I stopped > > using mbuf clusters and instead allocated my own 4K receive buffers and > > told the chip to DMA into those, on the theory that it may have been > > barfing up the entire contents of its FIFO memory which was more than > > 2048 bytes. Sure, most of the time you waste a lot of those 4K blocks, > > but at least when the chip freaks out it doesn't trash any memory that > > you don't know about. > > Um. Ew. Okay. Sigh. > > In NetBSD, we only copy if the system doesn't have __NO_STRICT_ALIGNMENT > (e.g. i386, m68k [we support some PCI m68k boxes], VAX [all those PCI > vaxes, you know!)... I'll have to see what I can do about all of this. Somebody raised the point that the NFS code will copy packets in order to obtain longword alignment for the benefit of XDR decoding. The argument was that since NFS wants the payload aligned, you may as well fix up the alignment in the driver. Of course, at the time this was a bigger issue because the copying in NFS was broken. There aren't that many PCI chipsets that allow byte alignment for receive buffers. The high end cards (Intel, 3Com, Texas Instruments) do, as well as the gigabit ethernet NICs, or at least the ones I have do. The only cheap one that does it is the Sundance ST201, which clones the 3Com XL interface. (D-Link will be using this chip on the DFE-550TX. Sundance is at www.sundanceti.com.) > > My biggest problem with this stupid thing now is trying to get to work > > on the 486/66 that I'm currently using for testing. It has an old > Integrated > > Micro Systems PCI bridge and the PNIC seems to have decided not to be > > friends with it: the machine tends to freeze up solid whenever the chip > > does any DMA, including just loading the setup frame. > > It it trying to use Memory-Read-Multiple or Memory-Read-Line? Old (esp. 486) > PCI bridges were known to have problems with those PCI commands. I'm not sure. I got tired of schlepping from my office to the lab to reboot the stupid machine all the time and put it aside for a while. :) > > http://www.freebsd.org/~wpaul/PNIC/pnic.ps.gz > > Excellent! Thank you very much! No problem. > > All of the Winbond cards are essentially the same so the one you have > > should be enough -- mine is from a company called Trendware. The PNIC > > is a bit tougher to deal with because there are a couple of revisions: > > the original LinkSys PNIC cards use the 82c168 and the internal busted > > NWAY support (i.e. no MII transceiver). For these you have to fiddle > > with the GPIO bits to flip the relay on the card (yes, a relay) in order > > Heh... I have a Kingston 21140 board that uses the PCS function to do > 100baseTX, and you hear a relay flip on that board too :-) > > On these PNIC boards which use the external ENDEC / PCS ... I guess you'd > be able to detect which flavor you have (for flipping the GPIO pins) using > the subsystem IDs in PCI configuration space... The PNIC doesn't use the > DEC-format SROM, unfortunately, so just getting CSR6 and CSR12 from the > SROM isn't an option... I have to confess that I've been ignoring the SROM. My usual scheme is to probe for a PHY on the MII bus first, and if I find none, I assume the card uses some other form of media. In the case of the PNIC, you can distinguish the 82c168 from the 82c169 by checking the PCI revision code. I've seen the following: - 0x10: original 82c168 - 0x20: 82c169 used on LinkSys/Matrox PNIC cards with Myson PHY - 0x21: 82c169 used on Netgear FA310-TX rev D1/D2 cards The Netgear cards have chips that say NGM169B (rev D1) or NGM169C (rev D2). The PCI revision has not changed between the B and C chips so I don't know what the difference is. The cards themselves differ in that the Rev D1 boards use a Level One LXT970 PHY while the Rev D2 boards use a Broadcom PHY. > > to select the right media. The trouble is LinkSys doesn't sell them > > anymore: the later cards use the 82c169, and now they've gone to the > > PNIC II. I had some 82c168 cards donated by FreeBSD users. I can part > > with one of them if you can't find one anywhere. As for the Macronix, > > I would appreciate this... I haven't been able to find '168 boards at all. Okay, I just dug one out of my pile (it says Matrox on the back but it's identical to the LinkSys one). Give me an address where I should send it and I'll try to drop it in the mail sometime this week. > > ideally
Re: Tulip device driver question
On Wed, 8 Sep 1999, Wilko Bulte wrote: > There was also an DE-422 EISA card. Dunno if they are different. > > Do you have/want one? I could try to get you one. EISA is dead of course, > but older machines tend to have EISA slots to spare, and PCI in short > supply. I'd love to find an EISA based tulip card. Know where I might pick one up for under $10? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
On Wed, 8 Sep 1999 00:17:52 +0200 (CEST) Wilko Bulte wrote: > There was also an DE-422 EISA card. Dunno if they are different. I'm not sure what a DE-422 had on it... Matt? > Do you have/want one? I could try to get you one. EISA is dead of course, > but older machines tend to have EISA slots to spare, and PCI in short > supply. If you could arrange it, that'd be great! I have EISA AlphaStations. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Using gdb with fork()
I am using gdb 4.18 on FreeBSD-current. The program being debugged consists of two small files: test1.c and test2.c. The main() in test1.c has a call to fork() and for the child process case, it will call a routine, say test(), in test2.c. I use "set follow-fork-mode child", "break fork", "step" command trying to access the source in test2.c without success. The program is compiled with "cc -g test1.c test2.c" and I run gdb with "gdb a.out". If there is no fork(), a call from test1.c to a routine in test2.c will bring up the source of test2.c if I step that routine. Why it does not work with fork()? Am I missing something? Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Using gdb with fork()
You need to detach from your current process and attach to the spawned process. It might make it easier to attach in a timely fashion if you put a 3 second sleep in right after the fork. This would all be easiest using something like DDD where DDD will tell you what other processes are running with the same name, and allow you to attach to them through the GUI. -Kip On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > I am using gdb 4.18 on FreeBSD-current. The program being debugged > consists of two small files: test1.c and test2.c. The main() in test1.c > has a call to fork() and for the child process case, it will call a > routine, say test(), in test2.c. > > I use "set follow-fork-mode child", "break fork", "step" command trying to > access the source in test2.c without success. The program is compiled > with "cc -g test1.c test2.c" and I run gdb with "gdb a.out". > > If there is no fork(), a call from test1.c to a routine in test2.c will > bring up the source of test2.c if I step that routine. Why it does not > work with fork()? Am I missing something? > > Thanks for any help. > > -- > Zhihui Zhang. Please visit http://www.freebsd.org > -- > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
At 01:41 PM 9/8/99 , Jason Thorpe wrote: >On Wed, 8 Sep 1999 00:17:52 +0200 (CEST) > Wilko Bulte wrote: > > > There was also an DE-422 EISA card. Dunno if they are different. > >I'm not sure what a DE-422 had on it... Matt? LANCE. It's supported by the DEPCA attachment (though as ISA). Very nice card. It has 128KB of local RAM (which can be moved to almost any where in phyical memory). The only real botch is that the IRQ is a write only register so you need to read the EISA bios to autoconfigure it. > > Do you have/want one? I could try to get you one. EISA is dead of course, > > but older machines tend to have EISA slots to spare, and PCI in short > > supply. > >If you could arrange it, that'd be great! I have EISA AlphaStations. I have one DE425 and one DE422. -- Matt Thomas Internet: m...@3am-software.com 3am Software Foundry WWW URL:http://www.3am-software.com/bio/matt/ Cupertino, CA Disclaimer: I avow all knowledge of this message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
On Wed, 8 Sep 1999, Matt Thomas wrote: > LANCE. It's supported by the DEPCA attachment (though as ISA). Very > nice card. It has 128KB of local RAM (which can be moved to almost any > where in phyical memory). The only real botch is that the IRQ is a write > only register so you need to read the EISA bios to autoconfigure it. Yea, the write only config registers are really pushing me towards implementing the EISA BIOS routines in order to just get the config from them. If anyone has any references on this they could point me to I'd really appriciate it. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | win...@jurai.net | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
Quickly going back to this issue of making sio.c work with PCI uarts. If any developer would like to step forward who's willing to make this work for us in the next few days, I'm willing to pay for this. We've had a deadline spring up, which is making me move on to other things. If anyone who can, in good faith, say they could have something workable by early next week, please contact me privately with your rates. We'll pay a decent amount to have this done, if it can be done quickly. Any takers? Kevin Day Midway Games To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
> Nice Idea however wrong operating system. The losers should > have done it for FreeBSD instead of linux. 1. Unconstructive (losers?) 2. Irrelevant (what gets done for Linux by XFree86 et all gets to FreeBSD pretty quickly) 3. Needlessly cross-posted (watch your cc lines, loser! :). - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
How to follow child process in gdb
On Wed, 8 Sep 1999, Kip Macy wrote: > You need to detach from your current process and attach to the spawned > process. It might make it easier to attach in a timely fashion if you put > a 3 second sleep in right after the fork. This would all be easiest using > something like DDD where DDD will tell you what other processes are > running with the same name, and allow you to attach to them through the > GUI. In dbx on a Sun workstation, all I need to do to follow a child process after fork() is to use the following command in advance: (dbx)dbxenv follow_fork_mode child Your response suggests that I can not achieve the same result simply by using (I am using gdb 4.18): (gdb)set follow-fork-mode child I have to use attach and dettach to do so. Does that mean I have to display the pid of the new process in order to follow it. And I have to modify the child process so that it can wait until I can attach to it. That will not be as easy. -Zhihui > > > > On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > > > > I am using gdb 4.18 on FreeBSD-current. The program being debugged > > consists of two small files: test1.c and test2.c. The main() in test1.c > > has a call to fork() and for the child process case, it will call a > > routine, say test(), in test2.c. > > > > I use "set follow-fork-mode child", "break fork", "step" command trying to > > access the source in test2.c without success. The program is compiled > > with "cc -g test1.c test2.c" and I run gdb with "gdb a.out". > > > > If there is no fork(), a call from test1.c to a routine in test2.c will > > bring up the source of test2.c if I step that routine. Why it does not > > work with fork()? Am I missing something? > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
> > Nice Idea however wrong operating system. The losers should > > have done it for FreeBSD instead of linux. > 2. Irrelevant (what gets done for Linux by XFree86 et all gets to FreeBSD >pretty quickly) What gets done by XFree86 is not relevant . What is relevant in the context of developing an ABI/SDK for GL apps is library compatibility in linux and we just went a few rounds in -multimedia about this issue which in some strange way is more relevant to that list than this one. My previous posting was an instant knee jerk reaction which was very hard to control. Got to exercise and train my knee a little bit better . -- Amancio Hasty ha...@rah.star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
message queues for I/O (usenix paper)
There is alot of talk going on over at the linux-kernel mailing list about implementing synchronous messaging for I/O. They are talking about a paper that was presented at USENIX: http://www.cs.rice.edu/~gaurav/papers/usenix99.ps The general idea is that select() and poll() fall over with large numbers of file descriptors for two reasons. First, scanning the interest list begins to consume more time. Second, the stateless nature between calls means that alot of redundant processing occurs. The solution these guys (the authors) say is to have a way of registering interest in descriptors, then you can call a procedure to find out what has changed since last time. I personally think that select() is just fine and can be implemented more efficiently than currently, but I would be willing to give it a shot at both cooperating with the Linux people to get a good Linux/FreeBSD API layed down and then implementing it. I know some of you heard this paper presented so does anybody have any ideas about it? Does anybody care? -jason To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
> 3. Needlessly cross-posted (watch your cc lines, loser! :). On a different topic, does anyone know of a good X mailer (currently I am using exmh) : 1. user friendly 2. filtering capability 3. thread topic support Kind of like Netscape's mail reader however I hate to bring up netscape to just read my mail so I am looking for something a little bit smaller foot print 8) Tnks! -- Amancio Hasty ha...@rah.star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
CS Project
Dear gentleman, i am a computer science student, and this semester i had to began my project to get graduated. After looking for some interesting topics on many sources, one rised up: Privacity on Shared Environments. My ideia is to add system facilities to improve privacity for users on shared environment like, for instance, FreeBSD. One clear example: No user(but only that ones previous allowed to) should be able to see other users process. This facility have to be done at kernel level, (that's what i think). There is many more thing like this, that could improve system privacity. This would be my cents to FreeBSD Project. So, what you think about this project? Is it cool enough to be done? Is it waste of time? I would really like to have your feedback. Please, report me something. Again: i would really enjoy hearing from you wizards what you have to say! Thanks a lot for your time and cooperation. best regards. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: message queues for I/O (usenix paper)
In article you write: >There is alot of talk going on over at the linux-kernel mailing list >about implementing synchronous messaging for I/O. They are talking about >a paper that was presented at USENIX: > > http://www.cs.rice.edu/~gaurav/papers/usenix99.ps > >The general idea is that select() and poll() fall over with large numbers of >file descriptors for two reasons. First, scanning the interest list begins to >consume more time. Second, the stateless nature between calls means that >alot of redundant processing occurs. The solution these guys (the authors) >say is to have a way of registering interest in descriptors, then you can >call a procedure to find out what has changed since last time. > >I personally think that select() is just fine and can be implemented >more efficiently than currently, but I would be willing to give it a shot >at both cooperating with the Linux people to get a good Linux/FreeBSD >API layed down and then implementing it. > >I know some of you heard this paper presented so does anybody have any >ideas about it? Yes. I don't particularly like some of the things in the paper, although it does have several good concepts. I have an implementation that does exactly this, and have a line on two other implementations that do the same thing (but in a different fashion). Unfortunately, all of these are somewhat problem-specific and are not a general solution. I've spent some time working on a generic implementation that draws its ideas from several places. I hope to be in a position where I can work on this almost full time within a month. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
> > 3. Needlessly cross-posted (watch your cc lines, loser! :). > > On a different topic, does anyone know of a good X mailer > (currently I am using exmh) : > > 1. user friendly > 2. filtering capability > 3. thread topic support XEmacs + VM works very well for me, but Emacsen have a fairly large footprint. Then again, anything implemented in X is fairly large, so it's no worse than most other X applications, and it's highly configurable, as with all things in emacs. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
How about xf and use procmail for filtering? -- Jim Durham To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
> How about xf and use procmail for filtering? > Tnks I will give xf a try and will look around a bit more . If don't find anything real neat I will probably roll out my own. Tnks Again! -- Amancio Hasty ha...@rah.star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote: > Dear gentleman, > One clear example: > No user(but only that ones previous allowed to) should be able to see > other users process. This facility have to be done at kernel level, > (that's what i think). Define "see". Access the memory? See that it is running? View the argv list? I don't see how this would affect privacy. -- |Chris Costello |Your fault, core dumped. `-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Current Development Branches
I know I will probably be shunned for the rest of my natural life for suggesting this, but here goes. How difficult would it be to change things around a little with the development branches? It seems there are a few problems with 3.3-RC (including determining what RC means) and this makes it hard in my opinion for people with production boxes to cvsup to the -STABLE branch if they are hoping to solve problems or get the latest patches and fixes. I would be in favor of a -PRODUCTION branch that can never contain code that hasn't been tested for a while. I would also like to propose a -BETA branch which would be -PRODUCTION with new code added. It seems to me that the name -STABLE is confusing many people and they seem to believe that it isn't actually stable unless it is in the -STABLE branch when this isn't always the case. The only other suggestion is a possible change of -CURRENT to -DEVELOPMENT which would better describe what that branch is actually for. Thanks for your time, I'm getting into my firesuit now. Anthony Rubin Hoffman Estates, IL j...@enteract.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: message queues for I/O (usenix paper)
> From: Jayson Nordwick > Date: 1999-09-08 17:38:56 -0700 > To: freebsd-hackers@FreeBSD.ORG > Subject: message queues for I/O (usenix paper) > Content-id: <66138.93683747...@scam.xcf.berkeley.edu> > Delivered-to: freebsd-hackers@freebsd.org > X-Loop: FreeBSD.ORG > > There is alot of talk going on over at the linux-kernel mailing list > about implementing synchronous messaging for I/O. They are talking about > a paper that was presented at USENIX: > > http://www.cs.rice.edu/~gaurav/papers/usenix99.ps > > The general idea is that select() and poll() fall over with large numbers of > file descriptors for two reasons. First, scanning the interest list begins to > consume more time. Second, the stateless nature between calls means that > alot of redundant processing occurs. The solution these guys (the authors) > say is to have a way of registering interest in descriptors, then you can > call a procedure to find out what has changed since last time. > > I personally think that select() is just fine and can be implemented > more efficiently than currently, but I would be willing to give it a shot > at both cooperating with the Linux people to get a good Linux/FreeBSD > API layed down and then implementing it. > > I know some of you heard this paper presented so does anybody have any > ideas about it? > > Does anybody care? >From the FWIW department, we have, in the Darwin source, an implementation of a "select replacement" that is designed to get around some of the (perceived or real) issues with select(), e.g., looking at a long (FD_SETSIZE or larger) array of bits several times in the kernel and in user space. In the available sources, this is represented in sys/ev.h, and is implemented only for sockets. Our tests indicate a roughly 5-10% speed improvement when a lot of sockets are in use but not exuberantly so. For Darwin in the future (the Core OS for Mac OS X), this scheme will be somewhat generalized, to provide a uniform mechanism for fielding events from any subsystem. It will be made more interesting by the need to incorporate mach message handling in addition to file-descriptor-based events. Have a look, should this be of interest. I'll be happy to field questions, since the doc is a bit, oh, scant... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: message queues for I/O (usenix paper)
>Yes. I don't particularly like some of the things in the paper, >although it does have several good concepts. I have an implementation >that does exactly this, and have a line on two other implementations >that do the same thing (but in a different fashion). Unfortunately, >all of these are somewhat problem-specific and are not a general >solution. > >I've spent some time working on a generic implementation that draws >its ideas from several places. I hope to be in a position where I >can work on this almost full time within a month. >-- >Jonathan > Would you like to share your implementation and the line you have on two other implementation that do the same thing (but in a different fassion)? I (and others I know) would be very interested to know what you have come across and what these other ideas are. -jason To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
Chris Costello wrote: > > On Wed, Sep 08, 1999, Gustavo V G C Rios wrote: > > Dear gentleman, > > > One clear example: > > No user(but only that ones previous allowed to) should be able to see > > other users process. This facility have to be done at kernel level, > > (that's what i think). > >Define "see". Access the memory? See that it is running? > View the argv list? I don't see how this would affect privacy. > > -- > |Chris Costello > |Your fault, core dumped. > `-- > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message Cannot see: it would not be possible for user (except the owner) to see that the process exists: For instance: (my current system) myname:~> ps auxwf USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root240 7.8 10.9 15288 14036 ?? S 9:00PM 8:49.59 /usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/wdm/authdir/authfiles/A:0-iP root 1 0.0 0.2 496 256 ?? Is6:00PM 0:00.07 /sbin/init -- root 2 0.0 0.0 00 ?? DL6:00PM 0:00.01 (pagedaemon) root 3 0.0 0.0 00 ?? DL6:00PM 0:00.00 (vmdaemon) root 4 0.0 0.0 00 ?? DL6:00PM 0:01.26 (syncer) root 32 0.0 0.1 204 80 ?? Is6:00PM 0:00.00 adjkerntz -i root 89 0.0 0.4 824 568 ?? Is9:00PM 0:01.25 syslogd root130 0.0 0.4 864 472 ?? Is9:00PM 0:00.01 inetd root133 0.0 0.4 992 568 ?? Is9:00PM 0:00.28 cron root137 0.0 0.4 832 568 ?? Is9:00PM 0:00.01 /usr/sbin/lpd root146 0.0 0.5 832 588 ?? S 9:00PM 0:00.06 /usr/sbin/lpd root178 0.0 0.3 792 432 ?? Ss9:00PM 0:04.08 moused -p /dev/cuaa1 -t auto root191 0.0 0.2 500 312 con- I+9:00PM 0:00.01 /bin/sh /usr/local/bin/safe_mysqld root205 0.0 1.3 11032 1724 con- I+9:00PM 0:00.06 /usr/local/libexec/mysqld --basedir=/usr/local --datadir=/var/db/mysql root206 0.0 0.7 1148 888 ?? Is9:00PM 0:00.92 /usr/local/sbin/sshd (sshd1) root235 0.0 0.4 828 548 v2 Is+ 9:00PM 0:00.01 /usr/libexec/getty Pc ttyv2 root236 0.0 0.4 828 548 v3 Is+ 9:00PM 0:00.01 /usr/libexec/getty Pc ttyv3 root237 0.0 1.2 2724 1512 ?? I 9:00PM 0:00.10 /usr/X11R6/bin/wdm -nodaemon ttyv4 root241 0.0 1.3 2744 1688 ?? I 9:00PM 0:00.02 -:0 (wdm) grios 254 0.1 2.1 3352 2716 ?? S 9:00PM 0:08.95 /usr/X11R6/bin/wmaker grios 268 0.0 0.8 1576 1072 ?? S 9:00PM 0:11.80 wmnet grios 269 0.0 0.8 1512 968 ?? S 9:00PM 0:03.88 wmmixer -w grios 270 0.0 0.9 1684 1180 ?? S 9:00PM 0:00.36 wmdate -s grios 271 0.0 0.8 1524 1012 ?? S 9:00PM 0:17.23 wmtictactoe grios 272 0.0 0.9 1660 1180 ?? S 9:00PM 0:03.07 wmitime grios 273 0.0 1.0 1744 1240 ?? S 9:00PM 0:08.85 ascpu -withdrawn -u 1 -sys red -nice yellow -user blue -idle white -ex grios 274 0.0 0.9 1676 1184 ?? S 9:00PM 0:23.74 wmSun grios 275 0.0 1.2 2064 1508 ?? S 9:00PM 0:24.84 wmCalClock grios 276 0.0 0.8 1576 976 ?? S 9:00PM 0:02.30 wmnetselect root 1213 0.0 0.3 468 344 v1 Is+ 10:36PM 0:00.07 -csh (csh) root 1254 0.0 0.8 1400 1032 ?? Ss 10:46PM 0:00.09 ppp -background td grios 1256 0.0 14.0 20148 17996 ?? S10:46PM 0:04.92 /usr/local/netscape-4.51/communicator-4.51.bin grios 1257 0.0 10.6 16068 13680 ?? I10:46PM 0:00.06 (dns helper) (communicator-4.5) grios 1259 0.0 0.8 1516 976 ?? S10:46PM 0:00.18 wmcdplay -w root 1266 0.0 2.2 3224 2872 ?? R10:48PM 0:00.11 xterm grios 1267 0.0 0.4 992 504 p0 Ss 10:48PM 0:00.04 -bash (bash) root 0 0.0 0.0 00 ?? DLs 6:00PM 0:00.00 (swapper) grios 1269 0.0 0.2 404 240 p0 R+ 10:48PM 0:00.00 ps -auxwf After changes made by me: myname:~> ps auxwf USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND grios 274 0.0 0.9 1676 1184 ?? S 9:00PM 0:24.03 wmSun grios 275 0.0 1.2 2064 1508 ?? S 9:00PM 0:25.15 wmCalClock grios 276 0.0 0.8 1576 976 ?? S 9:00PM 0:02.32 wmnetselect grios 1256 0.0 14.0 20148 17996 ?? S10:46PM 0:05.56 /usr/local/netscape-4.51/communicator-4.51.bin grios 1257 0.0 10.6 16068 13680 ?? I10:46PM 0:00.06 (dns helper) (communicator-4.5) grios 1259 0.0 0.8 1516 976 ?? S10:46PM 0:00.28 wmcdplay -w grios 1267 0.0 0.4 992 504 p0 Ss 10:48PM 0:00.04 -bash (bash) grios 254 0.0 2.1 3352 2728 ?? S 9:00PM 0:09.19 /usr/X11R6/bin/wmaker I would be able to see any other proccess which i am not the owner, top would indicated, only 8 proccess, for this current scenario. do you understand now, what i meant? Linux already have such a facility! Thanks a lot!
Re: CS Project
Gustavo V G C Rios wrote: > > After changes made by me: > > > I would be able to see any other proccess which i am not the owner, top would not be (there was a mistaken in the sentece above, it was in lack of "not" ) > would indicated, only 8 proccess, for this current scenario. > > do you understand now, what i meant? > > Linux already have such a facility! > > Thanks a lot! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
On Wed, Sep 08, 1999, Gustavo V G C Rios wrote: > I would be able to see any other proccess which i am not the owner, top > would indicated, only 8 proccess, for this current scenario. > > do you understand now, what i meant? > > Linux already have such a facility! I don't believe such a facility is needed. If a user does not want their process to be seen, they could do something like call setproctitle(). > Thanks a lot! -- |Chris Costello |I suppose when it gets to that point, we shan't |know how it does it. - Turing `--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
On 09-Sep-99 Gustavo V G C Rios wrote: > > I would be able to see any other proccess which i am not the owner, top > > would not be (there was a mistaken in the sentece above, it was > in lack of "not" ) > > > would indicated, only 8 proccess, for this current scenario. > > > > do you understand now, what i meant? > > > > Linux already have such a facility! Hack ps and turn off procfs :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum pgpe89Jezshou.pgp Description: PGP signature
X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
On Wed, Sep 08, 1999 at 05:43:17PM -0700, Amancio Hasty wrote: > > 3. Needlessly cross-posted (watch your cc lines, loser! :). > > On a different topic, does anyone know of a good X mailer > (currently I am using exmh) : There aren't any. :-) (depends on your value of "good") > 1. user friendly > 2. filtering capability I've decided that threading isn't the mailer's job. I don't want to have to wade through a mailbox full of lists when I'm connecting from off site, and have shut down my on-site mailer. Lots of folk use procmail, but since I'm using qmail as an MTA, I thought I'd see if I could use it's native methods, and it's really easy, with a shell script that's just a case $SENDER block. > 3. thread topic support The best threading mail reader that I've come across is mutt, but that might be too traditional for your option 1. If you find a pretty, lightweight X-based MUA that does a good job with threads (and MIME, and PGP), I'd like to know about it too. XFMail isn't acceptable, because I've got 130M of mbox mail boxes in a deep directory hierarchy, and I'd like to keep them that way. The last time I looked at XFMail it insisted on an un-nested mh-directory style of mailbox. Is it still the case? Nate: it's a while since I looked at VM on XEmacs. I found its layout cluttered and it's key sequences awkward. How configurable is it, really? Do you use it as it comes out of the box? -- Andrew To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Current Development Branches
On Wed, Sep 08, 1999, Anthony Rubin wrote: > I know I will probably be shunned for the rest of my natural life for > suggesting this, but here goes. How difficult would it be to change things > around a little with the development branches? It seems there are a few > problems with 3.3-RC (including determining what RC means) and this makes it "Release Candidate." > hard in my opinion for people with production boxes to cvsup to the -STABLE > branch if they are hoping to solve problems or get the latest patches and > fixes. I would be in favor of a -PRODUCTION branch that can never contain > code that hasn't been tested for a while. I would also like to propose That's the point of the -STABLE branch. Code is explicitly _NOT_ allowed to go into -STABLE without having first been tested in -CURRENT. > a -BETA branch which would be -PRODUCTION with new code added. It seems to Up until now, -BETA was the testing period that went up to -RELEASE. > me that the name -STABLE is confusing many people and they seem to believe > that it isn't actually stable unless it is in the -STABLE branch when this > isn't always the case. The only other suggestion is a possible change We can't be perfect. If there is instability in the -STABLE branch, please use the send-pr mechanism to report this bug, and if possible, provide a patch. -STABLE is meant explicitly for production systems, and we try to keep only stable code in that branch. -- |Chris Costello |Entropy isn't what it used to be. `-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: CS Project
On Wed, 8 Sep 1999, Gustavo V G C Rios wrote: > Dear gentleman, > > i am a computer science student, and this semester i had to began my > project to get graduated. After looking for some interesting topics on > many sources, one rised up: > Privacity on Shared Environments. > > My ideia is to add system facilities to improve privacity for users on > shared environment like, for instance, FreeBSD. > > One clear example: > No user(but only that ones previous allowed to) should be able to see > other users process. This facility have to be done at kernel level, > (that's what i think). > > There is many more thing like this, that could improve system privacity. > This would be my cents to FreeBSD Project. > > So, what you think about this project? Is it cool enough to be done? Is > it waste of time? I would really like to have your feedback. Please, > report me something. > > Again: i would really enjoy hearing from you wizards what you have to > say! You have a little problem with our language, and it's making it difficult to tell if you know enough to start hacking. There are already lots of extra security measures on FreeBSD; if you want to research this, and perhaps come up with something extra, you'd certainly want to look at the "pam" facility (man pam), which would probably be where you'd want to do your work.
Re: message queues for I/O (usenix paper)
On Sep 09, 1999 at 06:49:46PM -0700, Jayson Nordwick wrote: > >Yes. I don't particularly like some of the things in the paper, > >although it does have several good concepts. I have an implementation > >that does exactly this, and have a line on two other implementations > >that do the same thing (but in a different fashion). Unfortunately, > >all of these are somewhat problem-specific and are not a general > >solution. > > > >I've spent some time working on a generic implementation that draws > >its ideas from several places. I hope to be in a position where I > >can work on this almost full time within a month. > >-- > >Jonathan > > > > Would you like to share your implementation and the line you have on > two other implementation that do the same thing (but in a different > fassion)? There wouldn't be much point, since it was written for a specific problem and doesn't handle some general cases that could come up. Search the -hackers archive for "poll() and scalability", around July, for the archived discussions, and my original interface. > I (and others I know) would be very interested to know what you have come > across and what these other ideas are. I'll present a possible interface (and implementation) when I'm satisfied it'll work well for most consumers. This isn't going to be for a month or so, I have PhD qualifying exams and some other things to clear off my plate first. -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
New(bus|pnp)-ifyed joy(4)
Hi, I write patch for joy.c so that it recognize CS4235 Game port by PnP.
API do work,but hardware seems to be uninitialized.
(Read returns only 0x8000)
Are there any person who review this?
To use PnP Interface,
write simply
device joy0
and add your GAME port ID to
joy_ids[];
Takanori Watanabe
http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html";>
Public Key
Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A
BTW.
diff -u /home/ctm/src/sys/i386/isa/isa_compat.h ./isa_compat.h
--- /home/ctm/src/sys/i386/isa/isa_compat.h Thu Sep 9 08:17:07 1999
+++ ./isa_compat.h Thu Sep 9 09:27:49 1999
@@ -140,7 +140,9 @@
extern struct isa_driver spigotdriver;
extern struct isa_driver gpdriver;
extern struct isa_driver gscdriver;
+#if 0
extern struct isa_driver joydriver;
+#endif
extern struct isa_driver cydriver;
extern struct isa_driver dgbdriver;
extern struct isa_driver dgmdriver;
@@ -371,7 +373,7 @@
#if NSPIGOT > 0
{ INTR_TYPE_MISC, &spigotdriver },
#endif
-#if NJOY > 0
+#if 0
{ INTR_TYPE_MISC, &joydriver },
#endif
diff -u /home/ctm/src/sys/i386/isa/joy.c ./joy.c
--- /home/ctm/src/sys/i386/isa/joy.cFri Aug 27 03:17:58 1999
+++ ./joy.c Thu Sep 9 10:04:56 1999
@@ -35,12 +35,19 @@
#include
#include
+
+
#include
#include
+#include
-#include
-#include
+#include
+#include
+#include
+#include
+#include
#include
+#include "isa_if.h"
/* The game port can manage 4 buttons and 4 variable resistors (usually 2
* joysticks, each with 2 buttons and 2 pots.) via the port at address 0x201.
@@ -65,17 +72,17 @@
#define JOY_TIMEOUT 2000 /* 2 milliseconds */
#endif
-static struct {
-int port;
+struct joy_softc{
+bus_space_tag_t bt;
+bus_space_handle_t port;
int x_off[2], y_off[2];
int timeout[2];
-} joy[NJOY];
+} ;
-static int joyprobe (struct isa_device *);
-static int joyattach (struct isa_device *);
+static int joy_probe (device_t);
+static int joy_attach (device_t);
-struct isa_driver joydriver = {joyprobe, joyattach, "joy"};
#define CDEV_MAJOR 51
static d_open_tjoyopen;
@@ -107,12 +114,17 @@
static int get_tick __P((void));
-
+devclass_t joy_devclass;
+static struct isa_pnp_id joy_ids[] = {
+ {0x0100630e,"CS4235 PnP Joystick"},
+ {0}
+};
static int
-joyprobe (struct isa_device *dev)
+joy_probe (device_t dev)
{
static int once;
-
+if(ISA_PNP_PROBE(device_get_parent(dev),dev,joy_ids)==ENXIO)
+ return ENXIO;
if (!once++)
cdevsw_add(&joy_cdevsw);
#ifdef WANT_JOYSTICK_CONNECTED
@@ -120,60 +132,77 @@
DELAY (1); /* 10 ms delay */
return (inb (dev->id_iobase) & 0x0f) != 0x0f;
#else
-return 1;
+return 0;
#endif
}
static int
-joyattach (struct isa_device *dev)
+joy_attach (device_t dev)
{
-intunit = dev->id_unit;
-
-joy[unit].port = dev->id_iobase;
-joy[unit].timeout[0] = joy[unit].timeout[1] = 0;
-printf("joy%d: joystick\n", unit);
+intunit = device_get_unit(dev);
+int rid=0;
+struct resource *res;
+struct joy_softc *joy=device_get_softc(dev);
+res=bus_alloc_resource(dev,SYS_RES_IOPORT,&rid,0,~0,8,RF_ACTIVE);
+if(res==NULL)
+ return ENXIO;
+joy->bt =rman_get_bustag(res);
+joy->port = rman_get_bushandle(res);
+joy->timeout[0] = joy->timeout[1] = 0;
+printf("joy%d : joystick\n ", unit);
make_dev(&joy_cdevsw, 0, 0, 0, 0600, "joy%d", unit);
-return 1;
+return 0;
}
+static device_method_t joy_methods[]={
+ DEVMETHOD(device_probe,joy_probe),
+ DEVMETHOD(device_attach,joy_attach),
+ {0,0}
+};
+static driver_t joy_isa_driver ={
+ "joy",
+ joy_methods,
+ sizeof (struct joy_softc)
+};
+DRIVER_MODULE(joy,isa,joy_isa_driver,joy_devclass,0,0);
static int
joyopen (dev_t dev, int flags, int fmt, struct proc *p)
{
-int unit = UNIT (dev);
int i = joypart (dev);
+struct joy_softc *joy=devclass_get_softc(joy_devclass,UNIT(dev));
-if (joy[unit].timeout[i])
+if (joy->timeout[i])
return EBUSY;
-joy[unit].x_off[i] = joy[unit].y_off[i] = 0;
-joy[unit].timeout[i] = JOY_TIMEOUT;
+joy->x_off[i] = joy->y_off[i] = 0;
+joy->timeout[i] = JOY_TIMEOUT;
return 0;
}
static int
joyclose (dev_t dev, int flags, int fmt, struct proc *p)
{
-int unit = UNIT (dev);
int i = joypart (dev);
-
-joy[unit].timeout[i] = 0;
+struct joy_softc *joy=devclass_get_softc(joy_devclass,UNIT(dev));
+joy->timeout[i] = 0;
return 0;
}
static int
joyread (dev_t dev, struct uio *uio, int flag)
{
-int unit = UNIT(dev);
-int port = joy[unit].port;
+struct joy_softc *joy=devclass_get_softc(joy_devclass,UNIT(dev));
+int port = joy->port;
+int bt=joy->bt;
int i, t0, t1;
int state = 0, x = 0, y = 0;
struct joystick c;
disable_intr ();
-outb (port, 0xff);
+bus_space_write_1 (bt,port,0, 0xff);
t0 = get_tick ();
t1 = t0;
-i = usec2ticks(joy[unit].
Re: message queues for I/O (usenix paper)
thank for the pointers to the mailing list... very enlightening. I am going to try to write up an API for it this weekend with some cooperation with others. I will then give it a first pass around the freebsd-hackers and linux-kernl mailing lists. There are a few unanswered questions as to what an event it and how to handle them between threads and processes, but the general structure of an event queue seems to be wanted by almost everybody. I am not convinced by the usenix paper that this is the right way to do things, yet. state management is a bitch and taken too lightly most of the time. -jason To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
> Nate: it's a while since I looked at VM on XEmacs. I found its > layout cluttered and it's key sequences awkward. How configurable > is it, really? Do you use it as it comes out of the box? Really configurable, and no, I don't use it in an out-of-the-box configuration. I remap many of the keybindings, as well as have it setup to deal with procmail filtered email, which works very well. For more information, talk to me offline. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
Hi Nate, Somewhere , theres got to be a nice little email place where Unix people can talk about usability and ease of software. Have Fun Guys -- Amancio Hasty ha...@rah.star-gate.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
Dmitrij Tejblum wrote: > > > Another issue when sigset_t changes is the version numbers of shared > > libraries. Since libc and libc_r have changed on the interface level, they > > need a version bump. > > I suggest to try to avoid the version bump. NetBSD-like way to do it: > Give new implementations another names in object files, so that they > don't conflict with old implementations, and preserve old > implementations in the library too. To make the compiler generate calls > to new implementations, one can add appropriate #define s in .h files. > For GCC, __asm__ attribute also can be used. That still is an interface change and thus needs a version bump. How else do I know wich version x library has the new implementations (besides the larger one :-)? -- Marcel Moolenaarmailto:mar...@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:mar...@freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Sangoma Wanpipe
Hi all, Sort of off topic, though thought it might bring about some positive response and ideas here... I've successfully avoided a Cisco solution (though not the ADC kentrox one =( ) recently with the Sangoma Wanpipe using FreeBSD 3.2-STABLE (cvsupped last week). Time permitting, I intend to put together an article about this and submitting it to a few places.. This could make FreeBSD look better in the view of the coder that isn't core member material, though capable when needed. Being a little rusty on basic kernel tweaking, it took me about 2 hours total to come to the conclusion that /usr/include/sys/file.h changed the parameters changed slightly in file->filops->fo_read, and that I needed to add a fourth parameter, O_RDONLY, to get it working again =) Could probably have been done in 2 minutes by someone that regularly has there head deep in the FreeBSD kernel sources =) At the same time, sangoma is short on programmers, and hasn't someone to devote to FreeBSD/linux.. The linux community has helped them... Dave MandelSomething (Sales, not the other dave in sales =) at sangoma expressed interest in FreeBSD side help. For more info on there products, see www.sangoma.com. The particular card I used was the S508. Had to still use a ADC kentrox CSU/DSU since the network was splitting 2 channels data(128k), 18 voice, and 4 unused at this time. If it was full data use of the T1, for another $330, would have had a built in CSU/DSU (for a total of $880 or so, plus the cost to build the PC). I don't think it would take to much to match the tools they have for NT, on FreeBSD. Further, I think picoBSD could be used to make a better troubleshooting program on a disk that might help better help debug issues between external CSU/DSU, and the wanpipe. I am going to give them the updated code later today, and talk about if it could be included in the FreeBSD distrib.. CORE: Could this be added by someone b4 3.3 if they agree? Would probably lead to a little more coverage on there home page as well.. They aren't a bad company, and the Wanpipe ptpipe driver worked pretty good, along with the card =).. The main changes are sys/i386/isa/ptpipe.[ch], and an entry in sys/i386/conf/files.i386, and of course a line in the KERNEL CONFIG file. FreeBSD - making routers out of PC's =) Eric A. Griff setjmp Software (315) 734-1668 Extension 205 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: CS Project
> -Original Message- > From: owner-freebsd-hack...@freebsd.org > [mailto:owner-freebsd-hack...@freebsd.org]on Behalf Of > Daniel O'Connor > Sent: Wednesday, September 08, 1999 9:05 PM > To: Gustavo V G C Rios > Cc: freebsd-hackers@FreeBSD.ORG; ch...@calldei.com > Subject: Re: CS Project > > > > On 09-Sep-99 Gustavo V G C Rios wrote: > > > I would be able to see any other proccess which i am > not the owner, top > > > > would not be (there was a mistaken in the > sentece above, it was > > in lack of "not" ) > > > > > would indicated, only 8 proccess, for this current scenario. > > > > > > do you understand now, what i meant? > > > > > > Linux already have such a facility! > > Hack ps and turn off procfs :) I would think it more appropriate to adjust procfs' permissions in the kernel such that a user couldn't look at processes they don't own, i.e., can't cd or look into /proc/$PIDTHEYDONTOWN. Adding group-read for wheel or operator or a special new group would be good for things that must see all the processes. Like this: > ls -al /proc dr-xr-x--- 15 rootoperator512 Sep 9 00:36 171 dr-xr-x--- 15 rootoperator512 Sep 9 00:36 17430 dr-xr-x--- 15 doogie operator512 Sep 9 00:36 17758 dr-xr-x--- 15 doogie operator512 Sep 9 00:36 17760 Alternatively, you could just have only the entries you're supposed to see show up in /proc, and the rest would be suppressed entirely. If you then have procfs directly disclaim knowledge of that process when queried by an unpriveleged user (chdir to /proc/$PIDEXISTSBUTNOTYOURS would return ENOENT instead of EACCES), you deny brute force attacks to find out if a PID exists and by who it is owned. That increases privacy a bit. After all that, one could implement a 'ps' command that would use only procfs for process info. Procfs would need to export some more info, I think, that is only available via kvm but surely this is a trivial task. Then you have a simple situation where the kernel tells the user exactly what they should know and ps just looks up all the info it's allowed to. This should be controlled by sysctls like (placement based on nfs and ffs sysctl placement precedent): vfs.procfs.user_proc_privacy (0 or 1) vfs.procfs.user_proc_overridegid (obvious, -1 for no magic GID) I vaguely recall that PicoBSD has already got a procfs ps implementation. I might be wrong there. Somebody's done one, anyway. I think it would be a nice idea to have such a thing in the base system, since such a simple utility shouldn't have to grovel in kmem and be suid root. Note that this feature would dovetail itself nicely to the jail() concept. The kernel could check jail credentials as well as UID/GID credentials to present only the jailed virtual machine processes to the users (including root) inside the jail. I think the idea (of a procfs ps) was shot down on the lists some time ago because ps needs to retain the ability to look at the process list in a kernel coredump. IMHO that's a lot of messy kvm groveling and associated kernel-to-userland sync dependencies, just to cater to the (generous figure) 0.5% of the people out there who have 1) a crashing FreeBSD box and 2) the expertise and the will to debug the crash dump. I think that issue needs to be revisited somehow. Unfortunately I don't have my proposal written in diff(1) at the moment, but writing all this out makes me really want to go ahead and do it. Then again, somebody DID ask for a CS project. :) Hope this helps, Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: CS Project
On 09-Sep-99 Jason Young wrote: > > Hack ps and turn off procfs :) > I would think it more appropriate to adjust procfs' permissions in the > kernel such that a user couldn't look at processes they don't own, > i.e., can't cd or look into /proc/$PIDTHEYDONTOWN. Adding group-read > for wheel or operator or a special new group would be good for things > that must see all the processes. Like this: Well.. that doesn't sound *too* complex either. Would make an interesting CS project :) > queried by an unpriveleged user (chdir to /proc/$PIDEXISTSBUTNOTYOURS > would return ENOENT instead of EACCES), you deny brute force attacks > to find out if a PID exists and by who it is owned. That increases > privacy a bit. Yes. it depends on your level of paranoia. > After all that, one could implement a 'ps' command that would use only > procfs for process info. Procfs would need to export some more info, I It would be a good idea anyway.. I think someone has one floating around anyway. > allowed to. This should be controlled by sysctls like (placement based > on nfs and ffs sysctl placement precedent): Or even a mount option to procfs :) > I think the idea (of a procfs ps) was shot down on the lists some time > ago because ps needs to retain the ability to look at the process list > in a kernel coredump. IMHO that's a lot of messy kvm groveling and > associated kernel-to-userland sync dependencies, just to cater to the > (generous figure) 0.5% of the people out there who have 1) a crashing > FreeBSD box and 2) the expertise and the will to debug the crash dump. > I think that issue needs to be revisited somehow. Well.. I do use crash dumps, but rarely use ps on them.. Even so you could have 2 implementations of ps, or a ps which allows you to compile in a different 'back end'. That way you can use either easily. > Unfortunately I don't have my proposal written in diff(1) at the > moment, but writing all this out makes me really want to go ahead and > do it. Then again, somebody DID ask for a CS project. :) Heh :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum pgpp8moQf25oh.pgp Description: PGP signature
RE: CS Project
> > I think the idea (of a procfs ps) was shot down on the > lists some time > > ago because ps needs to retain the ability to look at > the process list > > in a kernel coredump. IMHO that's a lot of messy kvm > groveling and > > associated kernel-to-userland sync dependencies, just to > cater to the > > (generous figure) 0.5% of the people out there who have > 1) a crashing > > FreeBSD box and 2) the expertise and the will to debug > the crash dump. > > I think that issue needs to be revisited somehow. > > Well.. I do use crash dumps, but rarely use ps on them.. > Even so you could have > 2 implementations of ps, or a ps which allows you to > compile in a different > 'back end'. That way you can use either easily. I concur; those were my thoughts exactly. > > Unfortunately I don't have my proposal written in diff(1) at the > > moment, but writing all this out makes me really want to > go ahead and > > do it. Then again, somebody DID ask for a CS project. :) > > Heh :) Say, when is babelfish going to put up an English->diff(1) translator? Would make things a hell of a lot easier around here! :> Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: X mailers (was Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa)
Hi! On 09-Sep-99 Andrew Reilly wrote: > XFMail isn't acceptable, because I've got 130M of mbox mail > boxes in a deep directory hierarchy, and I'd like to keep them > that way. The last time I looked at XFMail it insisted on an > un-nested mh-directory style of mailbox. Is it still the case? Nope (at least in version 1.3). Also support of regular unix mailboxes is less efficient than that of mh. Unfortunately (due to the lack of time mostly) i had to stop working on XFMail. Hope to get back to it someday. Best regards. Gennady B. Sorokopud - System programmer at NetVision Israel. E-Mail: Gennady Sorokopud PGP public key is available through PGP keyserver. This message was sent at 09-Sep-99 08:49:56 by XFMail To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: CS Project
Some further thoughts before I doze off: > > allowed to. This should be controlled by sysctls like > (placement based > > on nfs and ffs sysctl placement precedent): > > Or even a mount option to procfs :) After some thought, I think the mount option idea is best. I hadn't thought of that before. One might want to apply different procfs security policies to different mounts of procfs, especially in a jail() situation. Good call. > > I think the idea (of a procfs ps) was shot down on the > lists some time > > ago because ps needs to retain the ability to look at > the process list > > in a kernel coredump. IMHO that's a lot of messy kvm > groveling and > > associated kernel-to-userland sync dependencies, just to > cater to the > > (generous figure) 0.5% of the people out there who have > 1) a crashing > > FreeBSD box and 2) the expertise and the will to debug > the crash dump. > > I think that issue needs to be revisited somehow. > > Well.. I do use crash dumps, but rarely use ps on them.. > Even so you could have > 2 implementations of ps, or a ps which allows you to > compile in a different > 'back end'. That way you can use either easily. I think that the best idea here is a single ps implementation with both backends available. Normally it would use the simple, secure and possibly privacy-enhancing procfs method, but using the -M or -N options to specify a dump or kernel file (or the live /dev/kmem and /kernel, if one were so inclined) would automagically switch ps over to the kvm grovel method. This would make the change transparent to both users and developers. SGID can still be removed - a developer/debugger will already be root or have had to chown the dump/kernel files to do any debugging. It would be mild bloat, but disk is cheap, and a disk space to debugging ease tradeoff has already been made (to the tune of several megs!) by the decision to build debug kernels by default. I agree with that. One could also #ifdef the kvm version. Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: High Availability (Re: MAC takeover )
Mike Nowlin wrote: > > > Another issue: I was recently involved in a project which required HA > > solutions (that's why I asked]. I gathered a lot of ideas and materials > > (and perhaps some code if that company agrees to release it). Is ther > > someone else here who is interested in these issues, and using FreeBSD for > > that? We could start some info pages, howto's, and perhaps a mailing > > list... > > Definitely... ... the same situation here. And I think that a lot of ISP would at appreciate at least some basic HA support in FreeBSD. Milon -- [EMAIL PROTECTED], but speaking on my own. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem with SMP in 3.3-RC
I have been running a 3.2-STABLE from around June 1st on my Asus P2B-D with 2 400MHz PII CPUs (128MB memory) without any problems. Yesterday I cvsup'ed RELENG_3 and now SMP doesn't work anymore. Halfway through /etc/rc some severe memory corruption seems to occur as all new processes core dumps immediately on signal 11. Finally the machine locks up and the reset button it the only way out. Same kernel without SMP works fine. Looking through the commitlogs, I found the two entries below that could be related. So I checked out a RELENG_3 src/sys from 1999/08/29, but that kernel failes in the same way. Tonight I will try to compile and run an older RELENG_3 GENERIC kernel. Does anyone have any idea of what's causing this problem? Is there some driver that doesn't work with SMP? msmith 1999/08/30 18:19:33 PDT MFC: Intel 686 and AMD K6/2 memory range attribute support. This merge brings all of the memory range attribute support from -current back to -stable, as requested by a number of folks. msmith 1999/09/02 16:57:06 PDT Bring back the rest of the changes required to make memory range support work on SMP systems. Tested by various folks on the -stable list, thanks for their patience and support. -- Mikael HybschEmail: [EMAIL PROTECTED] Security Dynamics AB Phone: +46-8-7250900 Box 10704Fax: +46-8-6494970 S-121 29 STOCKHOLM, SWEDEN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > > I'm assuming you actually have a Winbond card. If you do, try this for > > Yah, some Unicom card, I think. > > > me: connect the Winbond to a link partner who's media settings you can > > [ . . . snip . . . ] > > > Winbond that if I changed the link partner's speed settings, it would > > start DMAing all kinds of crap into the host's memory. Furthermore, I > > think it ignores the RX buffer lengths specified in the receive descriptor > > ring and trashes various chunks of memory that it shouldn't, leading to > > a crash. Given that I never observed this behavior with any of the other > > tulip clones using similar code, I was pretty sure this was a chip bug and > > not some horrible coding error that I had made somewhere. > > Yes, I have seen exactly this. I could only get it to happen if I changed > the Winbond's link partner from 10 -> 100 while the Winbond was still in 10. That sounds right. > I see the TDSTAT_Rx_FS and TDSTAT_Rx_LS bits cleared in the descriptor, > as well. When I see this condition occur, I attempt to reset the chip. > This does NOT help this condition on the Winbond. It's thorougly wedged. > > Oh yay, cheap chips. > > > I saw this with at least three separate Winbond cards and I tried my > > best to detect the condition and smack the chip upside the head to make > > it stop, but I'd be interested to see somebody else duplicate the problem > > and give me their take on it. > > Were you ever able to smack it and make it stop? :-) Well, yes, but I made some assumptions in order to do it. The assumption is that whatever the current speed setting is now, the link partner's speed setting is exactly opposite. So if I detect the condition, I first toggle the speed setting (if it's IFM_10_T, make it IFM_100_TX and vice- versa), then do a reset, then re-init the chip. However, the main problem is keeping the chip from zapping memory that it doesn't own. Normally I use mbuf cluster buffers in the receive ring, but I would only tell the chip that the buffer was 1536 bytes long instead of 2048. But again, it seemed like the chip was DMAing much more data than it should have been and overruning the whole cluster. Since I needed to copy received packets in order to fix up the alignment anyway, I stopped using mbuf clusters and instead allocated my own 4K receive buffers and told the chip to DMA into those, on the theory that it may have been barfing up the entire contents of its FIFO memory which was more than 2048 bytes. Sure, most of the time you waste a lot of those 4K blocks, but at least when the chip freaks out it doesn't trash any memory that you don't know about. The driver in -current has code that swaps the speed setting and the extra large buffers; originally I just tried to reset the chip and swap the speed as fast as possible, but this proved not to work too well once I started using the miibus sublayer so I had to revisit the whole thing and come up with a better solution. > > Also, just out of curiosity, have you ever observed the PNIC receiver > > bug that gave me so many fits? > > I observed it briefly back when there were still some pretty basic bugs > in the driver, which have since been squashed. I haven't seen it since. > I'm aware of the nature of the problem and your work-around. I'm hoping > I don't need to implement it :-) Unfortunately, I'm still not sure how to trigger it reliably so I can't tell you exactly where or when you might see it. > I have seen some pretty awful problems with the PNIC, tho. The DMA engine > is a piece of crap. On a 500MHz AlphaStation 500, who's PCI bus can surely > keep up with a cheap fast Ethernet board, the PNIC gets constant DMA underruns > unless in Store-and-Forward mode, *including the setup frame*. I have to > initialize the chip into S-F mode just to get the damn filter programmed :-) > > I also noticed that DMA underruns don't abort the transmit pipe on the PNIC. > Every DMA underrun on a real packet corresponded to a junk frame hitting > the wire. A short frame I could understand... but we're talking even the > Ethernet header is toast. > > Another interesting problem I've been seeing; The very first setup frame > fails to complete. All subsequent setup frames succeed. Including setup > frames sent after an ifconfig down/up. Utterly bizarre. > > Oh yay, cheap chips. Bleh. My experience with the PNIC shows that it does not handle multi-fragment transmits very well (i.e. a packet split across multiple buffers instead of just a single configuous buffer). Lite-On claims that they get pretty good transmit speed with the PNIC, however I'm certain they do their measurements using only single buffer transmits. I typically don't see more than about 80-85Mbps, though others using the Linux driver (which doesn't use multi-fragment transmits) have claimed better performance (90-95Mbps). On
ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
We've had a group (including representatives from LSB, Mesa, Metro Link, NVIDIA, PTC, Precision Insight, SGI, XFree86, and Xi Graphics) working on a proposal for standardizing X11 OpenGL/Mesa ABI and SDK issues on Linux. The purpose is to allow applications to build against any implementation following this standard and the resulting binaries to run against any other implementation; this interoperability will be increasingly important as the amount of 3D activity on Linux grows and the variety of drivers increases even further. The "0.9" draft of the proposal can be found at http://reality.sgi.com/opengl/linux/linuxbase.html A mailing list has been created for further discussion and finalization of this proposal. We're unable to follow discussions in all the forums where this announcement is being made, so if you want to have an effect, please join this mailing list. We particularly solicit participation by ISVs writing OpenGL-based applications on Linux, IHVs writing OpenGL drivers on Linux, and Linux distributions. To initially subscribe to the list, send a message with body subscribe oglbase-discuss to '[EMAIL PROTECTED]'. To participate in the list after you've subscribed, send messages to '[EMAIL PROTECTED]'. To unsubscribe to the list, send a message containing the body unsubscribe oglbase-discuss to [EMAIL PROTECTED] Jon Leech (For the Linux/OpenGL Base working group) SGI - FAQ and OpenGL Resources at: http://www.geocities.com/SiliconValley/Hills/9956/OpenGL -- Author: Jon Leech INET: [EMAIL PROTECTED] Fat City Network Services-- (619) 538-5051 FAX: (619) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- 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
The usage of MNT_RELOAD
The flag MNT_RELOAD is not documented in mount manpages. From the source code, I find that it is always used along with MNT_UPDATE which can be speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD for me? It seems not to be used normally. Any help is appreciated. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, Sep 08, 1999, Zhihui Zhang wrote: > > The flag MNT_RELOAD is not documented in mount manpages. From the source > code, I find that it is always used along with MNT_UPDATE which can be > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > for me? It seems not to be used normally. It looks like it 'reloads' the file system when you change the mount flags, e.g. changing a synchronous file system to an asynchronous file system, without really un-mounting it. -- |Chris Costello <[EMAIL PROTECTED]> |Base 8 is just like base 10, if you are missing two fingers. - Tom Lehrer `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
> The flag MNT_RELOAD is not documented in mount manpages. From the source > code, I find that it is always used along with MNT_UPDATE which can be > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > for me? It seems not to be used normally. > > Any help is appreciated. > > -- > Zhihui Zhang. Please visit http://www.freebsd.org > -- > It is created almost exclusively for fsck (and similar programs) to update the in core image of the superblock (of / in single user mode) after the on disk version has been modified. -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
panic.. 3.2-STABLE-OLD...
Well, it has been a long time since I have needed to write an email with that tagline. Our primary NFS server had been up for almost 2 months with no panics. We did need to reboot it for a network change, but it was up for 28 days at that point. Anyway here are the details: dev = 0x20014, block = 2096, fs = /exports/home3 panic: ffs_blkfree: freeing free block #0 0xc014b6cb in boot () #1 0xc014b950 in at_shutdown () #2 0xc01d50ef in ffs_blkfree () #3 0xc01d992c in indir_trunc () #4 0xc01d9688 in handle_workitem_freeblocks () #5 0xc01d7c28 in softdep_process_worklist () #6 0xc016f9b4 in sched_sync () #7 0xc013e56a in kproc_start () #8 0xc020328a in fork_trampoline () UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -18 0 00 sched DLs ??0:00.00 (swapper) 0 1 0 0 10 0 4960 wait Is??0:00.00 (init) 0 2 0 0 -18 0 00 - RL??0:00.00 (pagedaemon 0 3 0 0 18 0 00 psleep DL??0:00.00 (vmdaemon) 0 4 0 272 -6 0 00 - RL??0:00.00 (syncer) 042 1 0 10 0 2629000 mfsidl ILs ??0:00.00 (mount_mfs) 0 140 1 0 2 0 8160 - Rs??0:00.00 (syslogd) 0 150 1 14 2 -12 10480 - Rhttp://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tulip device driver question
As Jason Thorpe wrote ... > On Tue, 7 Sep 1999 03:11:24 -0400 (EDT) > Bill Paul <[EMAIL PROTECTED]> wrote: > > > The SiS 900 only has one combined status/control word in its > > descriptor structure (some of the bits mean different things depending > > on whether the descriptors are in the RX ring or TX ring) instead of a > > separate status and control word. The descriptors are also only 3 > > longwords in size. ... > BTW, you forgot EISA (DE-425) ... when I finish all the clone support There was also an DE-422 EISA card. Dunno if they are different. Do you have/want one? I could try to get you one. EISA is dead of course, but older machines tend to have EISA slots to spare, and PCI in short supply. Wilko -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
32+ signals and library versions
Hi, Another issue when sigset_t changes is the version numbers of shared libraries. Since libc and libc_r have changed on the interface level, they need a version bump. I assume that all others automaticly also need a version bump then. Am I correct in this assumption? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fequent panics in FreeBSD 3.3-RC
Hi, I last night I have upgraded a system to the latest stable, and have already received two of these panics: uname -a reads FreeBSD addr3.addr.com 3.3-RC FreeBSD 3.3-RC #0: Tue Sep 7 21:57:07 GMT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/ADDRKERN i386 the panic reads: Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0100 fault virtual address = 0xc4e7f08c fault code = supervisor write, page not present instruction pointer = 0x8:0xc025f47a stack pointer = 0x10:0xd2ed2f0c frame pointer = 0x10:0xd2ed2f1c 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 = 12498 (httpd) interrupt mask = net tty bio cam <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = 0100 boot() called on cpu#1 nm /kernel for that area shows: c025f314 T pmap_page_exists c025f30c T pmap_pageable c025f3a4 T pmap_remove_pages c025f4e0 t pmap_testbit The server is a dual PentiumIII-450 with 512 MB of ram and DPT raid controller. Max users is set at 256 (I don't know about this version, but on previous versions setting it higher caused constant panics). It usually runs at load average of about 2, serving apache/sendmail/telnet/ftpd/ipop3d as well as a little bit of NFS data for local updates and a completely idle NFS client. I am unable to trace the panic to any particular event, the system can run high load with no problems and one of the panics was in the evening when the system was running at only 0.5 load average. If you need any more info I would be glad to provide it. Any help regarding this problem would be greatly appreciated. Best Regards, Anthony Bourov To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fequent panics in FreeBSD 3.3-RC
> Hi, > > I last night I have upgraded a system to the latest stable, and have > already received two of these panics: Do you have APM enabled on this system, even just in the BIOS? > uname -a reads > FreeBSD addr3.addr.com 3.3-RC FreeBSD 3.3-RC #0: Tue Sep 7 21:57:07 GMT 1999 >[EMAIL PROTECTED]:/usr/src/sys/compile/ADDRKERN i386 > > the panic reads: > Fatal trap 12: page fault while in kernel mode > mp_lock = 0102; cpuid = 1; lapic.id = 0100 > fault virtual address = 0xc4e7f08c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc025f47a > stack pointer = 0x10:0xd2ed2f0c > frame pointer = 0x10:0xd2ed2f1c > 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 = 12498 (httpd) > interrupt mask = net tty bio cam <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0102; cpuid = 1; lapic.id = 0100 > boot() called on cpu#1 > > nm /kernel for that area shows: > > c025f314 T pmap_page_exists > c025f30c T pmap_pageable > c025f3a4 T pmap_remove_pages > c025f4e0 t pmap_testbit > > The server is a dual PentiumIII-450 with 512 MB of ram and DPT raid > controller. Max users is set at 256 (I don't know about this version, but > on previous versions setting it higher caused constant panics). It usually > runs at load average of about 2, serving apache/sendmail/telnet/ftpd/ipop3d > as well as a little bit of NFS data for local updates and a completely idle > NFS client. > I am unable to trace the panic to any particular event, the system can run > high load with no problems and one of the panics was in the evening when > the system was running at only 0.5 load average. > If you need any more info I would be glad to provide it. Any help regarding > this problem would be greatly appreciated. > > Best Regards, > Anthony Bourov > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Superblock.
So... I lost my partition table. I'm willing to spend a little time on this. Is there a byte sequence that I might recognise in a superblock or at the start of a partition? I know this isn't an easy task, but man 5 fs leads me to believe that I might find: #define FS_MAGIC0x011954 /* the fast filesystem magic number */ #define FS_OKAY 0x7c269d38 /* superblock checksum */ ... but I don't see those bytes. Any hints? I'm willing to post a description of a solution for the FAQ if I can find the filesystems. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Luoqi Chen wrote: > > The flag MNT_RELOAD is not documented in mount manpages. From the source > > code, I find that it is always used along with MNT_UPDATE which can be > > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > > for me? It seems not to be used normally. > > > It is created almost exclusively for fsck (and similar programs) to update > the in core image of the superblock (of / in single user mode) after the > on disk version has been modified. > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes sense to me: if fsck modifies the on-disk copy of the superblock, it does not have to unmount and then remount the filesystem, it only need to reload the superlock for disk. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: Linux ABI/SDK standards for OpenGL/Mesa (fwd)
Nice Idea however wrong operating system. The losers should have done it for FreeBSD instead of linux. -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes > sense to me: if fsck modifies the on-disk copy of the superblock, it does > not have to unmount and then remount the filesystem, it only need to > reload the superlock for disk. I think it's more for the case where fsck has to run on a filesystem which is mounted. It's better to fsck unmounted filesystems, but you don't always have that option (say you want to fsck the fs with fsck on it :-) Take care, Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > On Wed, 8 Sep 1999, Luoqi Chen wrote: > > > It is created almost exclusively for fsck (and similar programs) to update > > the in core image of the superblock (of / in single user mode) after the > > on disk version has been modified. > > > > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes > sense to me: if fsck modifies the on-disk copy of the superblock, it does > not have to unmount and then remount the filesystem, it only need to > reload the superlock for disk. The root filesystem is mounted when it is fscked, as it is difficult to run fsck, which lives on the root filesystem, without mounting the root filesystem. You shouldn't run fsck on a mounted filesystem, except for this. The results are generally not fun. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
On Wed, 8 Sep 1999, Zhihui Zhang wrote: > > On Wed, 8 Sep 1999, Luoqi Chen wrote: > > > > The flag MNT_RELOAD is not documented in mount manpages. From the source > > > code, I find that it is always used along with MNT_UPDATE which can be > > > speficied by user (-u option). Can anyone explain the usage of MNT_RELOAD > > > for me? It seems not to be used normally. > > > > > It is created almost exclusively for fsck (and similar programs) to update > > the in core image of the superblock (of / in single user mode) after the > > on disk version has been modified. > > > > Does fsck have to run on a MOUNTED filesystem? If so, your answer makes > sense to me: if fsck modifies the on-disk copy of the superblock, it does > not have to unmount and then remount the filesystem, it only need to > reload the superlock for disk. > Filesystems do not have to be mounted to fsck them (in fact, it is generally bad to have them mounted rw when fsck'd); however, in order for the root filesystem to be fsck'd on boot, it must be mounted ro in order to access the fsck program itself. After done fsck'ing, it can remount rw for normal operation, done without actually unmounting the filesystem. - Chris D. Faulhaber <[EMAIL PROTECTED]> | All the true gurus I've met never System/Network Administrator,| claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
:> Does fsck have to run on a MOUNTED filesystem? If so, your answer makes :> sense to me: if fsck modifies the on-disk copy of the superblock, it does :> not have to unmount and then remount the filesystem, it only need to :> reload the superlock for disk. : :The root filesystem is mounted when it is fscked, as it is difficult to run :fsck, which lives on the root filesystem, without mounting the root :filesystem. You shouldn't run fsck on a mounted filesystem, except for :this. The results are generally not fun. : :David Scheidt The root filesystem is mounted *READ-ONLY* initially. fsck is then run on all filesystems. Once fsck is done the root filesystem is remounted R/W and the remaining filesystems are mounted R/W. It's relatively safe to run fsck on a filesytem which has been mounted read-only. It is not safe to run fsck on a filesystem which has been mounted R/W. It is best, of course, to run fsck only on filesystems that have not been mounted but this cannot be done for the root filesystem for obvious reasons, hence the read-only mount + fsck + remount R/W. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> Another issue when sigset_t changes is the version numbers of shared > libraries. Since libc and libc_r have changed on the interface level, they > need a version bump. I assume that all others automaticly also need a > version bump then. Am I correct in this assumption? Libc_r already had a version bump in -current without a subsequent release. You do not want to give it another one. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 32+ signals and library versions
> Another issue when sigset_t changes is the version numbers of shared > libraries. Since libc and libc_r have changed on the interface level, they > need a version bump. I suggest to try to avoid the version bump. NetBSD-like way to do it: Give new implementations another names in object files, so that they don't conflict with old implementations, and preserve old implementations in the library too. To make the compiler generate calls to new implementations, one can add appropriate #define s in .h files. For GCC, __asm__ attribute also can be used. Dima To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problem with SMP in 3.3-RC
On Wed, 8 Sep 1999, I wrote: > Yesterday I cvsup'ed RELENG_3 and now SMP doesn't work anymore. > Halfway through /etc/rc some severe memory corruption seems to occur > as all new processes core dumps immediately on signal 11. Finally the > machine locks up and the reset button it the only way out. > Same kernel without SMP works fine. > The problem turned out to be that apm0 and SMP don't like each other. A kernel built from sources around Aug 20 works with apm0 and SMP. After that some apm related checkins were done that seems to have changed that. -- Mikael HybschEmail: [EMAIL PROTECTED] Security Dynamics AB Phone: +46-8-7250900 Box 10704Fax: +46-8-6494970 S-121 29 STOCKHOLM, SWEDEN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Superblock.
On Wed, Sep 08, 1999 at 01:46:18PM -0400, David Gilbert wrote: > So... I lost my partition table. I'm willing to spend a little time > on this. Is there a byte sequence that I might recognise in a > superblock or at the start of a partition? I know this isn't an easy > task, but man 5 fs leads me to believe that I might find: > > #define FS_MAGIC0x011954 /* the fast filesystem magic number */ > #define FS_OKAY 0x7c269d38 /* superblock checksum */ > > ... but I don't see those bytes. Any hints? > > I'm willing to post a description of a solution for the FAQ if I can > find the filesystems. > > Dave. It's better to find a whole disklabel. According to the disklabel(5): #define DISKMAGIC ((u_long) 0x82564557) /* The disk magic number */ My disk is set in dedicated mode, so: # dd if=/dev/da0c bs=1 skip=1b count=4 | hd 4+0 records in 4+0 records out 4 bytes transferred in 0.022311 secs (179 bytes/sec) 57 45 56 82 |WEV| 0004 HTH, -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: The usage of MNT_RELOAD
In message <[EMAIL PROTECTED]> Matthew Dillon writes: : It is best, of course, to run fsck only on filesystems that have not : been mounted but this cannot be done for the root filesystem for obvious : reasons, hence the read-only mount + fsck + remount R/W. Back in the Bad Old Days, when this option didn't exist, if fsck changed ANYTHING on /, the system rebooted... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Superblock.
On Wed, Sep 08, 1999 at 01:46:18PM -0400, David Gilbert wrote: > So... I lost my partition table. I'm willing to spend a little time > on this. Is there a byte sequence that I might recognise in a > superblock or at the start of a partition? I know this isn't an easy > task, but man 5 fs leads me to believe that I might find: > > #define FS_MAGIC0x011954 /* the fast filesystem magic number */ > #define FS_OKAY 0x7c269d38 /* superblock checksum */ > > ... but I don't see those bytes. Any hints? > > I'm willing to post a description of a solution for the FAQ if I can > find the filesystems. > > Dave. Search the hackers mailing list for a mail from me, which contains a C program to do the work for you. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
