Re: Superblock.
Julian Elischer scribbled this message on Sep 10: > At least one person has already written this program... > > THeey have mentionned this in the hackers list so maybe a search of the > list may turn something up.. > withing th last 2 years from memory. actually, it should be part of my ffsrecov program that I wrote... I'm not sure how well it works, but it should do what most people want to find the super block... > On Fri, 10 Sep 1999, Robert Sexton wrote: > > > On Fri, Sep 10, 1999 at 10:26:26AM +0200, Alex Le Heux wrote: > > > Hi, > > > > > > I once had a similar situation: I had wiped my disklabel. > > > > > > > > I know its easy to suggest somebody else do things, but turning this > > into software might make for a very handy salvage tool, without a lot > > of work for the author. We seem to have folks popping up often > > looking for little projects. > > > > I wonder how many folks have toasted drives in a recoverable way and > > not bothered to ask for help [why can't people learn to delete sig's?] -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Superblock.
Julian Elischer scribbled this message on Sep 10: > At least one person has already written this program... > > THeey have mentionned this in the hackers list so maybe a search of the > list may turn something up.. > withing th last 2 years from memory. actually, it should be part of my ffsrecov program that I wrote... I'm not sure how well it works, but it should do what most people want to find the super block... > On Fri, 10 Sep 1999, Robert Sexton wrote: > > > On Fri, Sep 10, 1999 at 10:26:26AM +0200, Alex Le Heux wrote: > > > Hi, > > > > > > I once had a similar situation: I had wiped my disklabel. > > > > > > > > I know its easy to suggest somebody else do things, but turning this > > into software might make for a very handy salvage tool, without a lot > > of work for the author. We seem to have folks popping up often > > looking for little projects. > > > > I wonder how many folks have toasted drives in a recoverable way and > > not bothered to ask for help [why can't people learn to delete sig's?] -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mysterious FreeBSD hardware problems
(sorry if this appears here twice - but as far as i can see the first try didn't make it here due to non optimal configuration of my news to mailinglist gateway :-) i'm a bit at the end of my phantasie with this machine i'm writing this here on ... something mystically seems to be broken with running FreeBSD on it ... first mystical thing is that the moused takes about a minute to start but workes then fine ... ok after that it boots on into x and works - but everything is very slow somehow as if the machine is under heavy load - but it isn't - one other thing noticable is that it produces very high rates of interupts on the serial ports with the mouse sometimes ... ok - and in addition to all this it won't reboot - if i try to reboot it via reboot/halt/shutdown - it starts to kill processes and nothing more happens - but via ctrl-alt-del or an "kill -INT 1" which that does it reboots fine ... has anyone ever seen this on any machine or any idea where this might come from ? - some more details: the machine runs fine with linux - also i've had another machine (different board) with exacly the same symptoms and there turning on apm in the bios and in the kernel fixed the problems all together but on this board i can't turn on apm - because it does not detect the amd cpu and i think thus refuses to turn on apm (it prints apm disabled at bootup even if i set it to enabled in the bios) - i would really like to see FreeBSD running completely on this machine here are some more details - first a "boot -v" output and second a ktrace of the hanging "halt" ... Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-RELEASE #1: Mon Sep 13 05:43:35 CEST 1999 r...@battus.at.home:/usr/src/sys/compile/BATTUS Calibrating clock(s) ... TSC clock: 74378519 Hz, i8254 clock: 1193729 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 74345070 Hz CPU: AMD K5 model 0 (74.35-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x500 Stepping=0 Features=0x3bf real memory = 41943040 (40960K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0027d000 - 0x027fdfff, 39325696 bytes (9601 pages) avail memory = 38395904 (37496K bytes) Found BIOS32 Service Directory header at 0xc00f6f10 Entry = 0xf6f20 (0xc00f6f20) Rev = 0 Len = 1 PCI BIOS entry at 0x6f41 Other BIOS signatures found: ACPI: $PnP: 000f9500 Preloaded elf kernel "kernel" at 0xc027. Preloaded elf module "if_tun.ko" at 0xc027009c. pci_open(1):mode 1 addr port (0x0cf8) is 0x8000384c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=122d8086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x122d, revid=0x01 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 chip0: rev 0x01 on pci0.0.0 CPU Inactivity timer: clocks Peer Concurrency: enabled CPU-to-PCI Write Bursting: enabled PCI Streaming: enabled Bus Concurrency: enabled Cache: 256K pipelined-burst secondary; L1 enabled DRAM: no memory hole, 50 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-3-3-3 RAS-CAS delay: 2 clocks found-> vendor=0x8086, dev=0x122e, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: rev 0x02 on pci0.7.0 I/O Recovery Timing: 8-bit 8 clocks, 16-bit 4 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: disabled, B: IRQ12, C: disabled, D: disabled MB0: disabled, MB1: disabled found-> vendor=0x8086, dev=0x1230, revid=0x02 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base 8000, size 4 ide_pci0: rev 0x02 on pci0.7.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: 8002 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/sl
mysterious FreeBSD hardware problems
(sorry if this appears here twice - but as far as i can see the first try didn't make it here due to non optimal configuration of my news to mailinglist gateway :-) i'm a bit at the end of my phantasie with this machine i'm writing this here on ... something mystically seems to be broken with running FreeBSD on it ... first mystical thing is that the moused takes about a minute to start but workes then fine ... ok after that it boots on into x and works - but everything is very slow somehow as if the machine is under heavy load - but it isn't - one other thing noticable is that it produces very high rates of interupts on the serial ports with the mouse sometimes ... ok - and in addition to all this it won't reboot - if i try to reboot it via reboot/halt/shutdown - it starts to kill processes and nothing more happens - but via ctrl-alt-del or an "kill -INT 1" which that does it reboots fine ... has anyone ever seen this on any machine or any idea where this might come from ? - some more details: the machine runs fine with linux - also i've had another machine (different board) with exacly the same symptoms and there turning on apm in the bios and in the kernel fixed the problems all together but on this board i can't turn on apm - because it does not detect the amd cpu and i think thus refuses to turn on apm (it prints apm disabled at bootup even if i set it to enabled in the bios) - i would really like to see FreeBSD running completely on this machine here are some more details - first a "boot -v" output and second a ktrace of the hanging "halt" ... Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-RELEASE #1: Mon Sep 13 05:43:35 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/BATTUS Calibrating clock(s) ... TSC clock: 74378519 Hz, i8254 clock: 1193729 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 74345070 Hz CPU: AMD K5 model 0 (74.35-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x500 Stepping=0 Features=0x3bf real memory = 41943040 (40960K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0027d000 - 0x027fdfff, 39325696 bytes (9601 pages) avail memory = 38395904 (37496K bytes) Found BIOS32 Service Directory header at 0xc00f6f10 Entry = 0xf6f20 (0xc00f6f20) Rev = 0 Len = 1 PCI BIOS entry at 0x6f41 Other BIOS signatures found: ACPI: $PnP: 000f9500 Preloaded elf kernel "kernel" at 0xc027. Preloaded elf module "if_tun.ko" at 0xc027009c. pci_open(1):mode 1 addr port (0x0cf8) is 0x8000384c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=122d8086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x122d, revid=0x01 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 chip0: rev 0x01 on pci0.0.0 CPU Inactivity timer: clocks Peer Concurrency: enabled CPU-to-PCI Write Bursting: enabled PCI Streaming: enabled Bus Concurrency: enabled Cache: 256K pipelined-burst secondary; L1 enabled DRAM: no memory hole, 50 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-3-3-3 RAS-CAS delay: 2 clocks found-> vendor=0x8086, dev=0x122e, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip1: rev 0x02 on pci0.7.0 I/O Recovery Timing: 8-bit 8 clocks, 16-bit 4 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: disabled, B: IRQ12, C: disabled, D: disabled MB0: disabled, MB1: disabled found-> vendor=0x8086, dev=0x1230, revid=0x02 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base 8000, size 4 ide_pci0: rev 0x02 on pci0.7.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 2 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: 8002 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/sla
Re: mbuf shortage situations (followup)
On Mon, 13 Sep 1999, Matthew Dillon wrote: > The case that is causing the panics is with the non-interrupt mbuf > allocation mechanism. Specifically, the case where M_WAIT is used. > > The second problem under discussion, which really ought to be separated > out from the mbuf panic problem, is the potential for a deadlock or > denial of service attack when the system is attacked in a manner that > eats all available mbufs. > The traditional way to prevent resource-starvation DoSes from the user populus has been to add administrative limits. Using RLIMIT_SBSIZE does this nicely. Yes, this isn't actually fixing the panics, but it is good preventative medicine. > -Matt > Matthew Dillon > > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / gr...@freebsd.org`--' To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
On Mon, 13 Sep 1999, Matthew Dillon wrote: > The case that is causing the panics is with the non-interrupt mbuf > allocation mechanism. Specifically, the case where M_WAIT is used. > > The second problem under discussion, which really ought to be separated > out from the mbuf panic problem, is the potential for a deadlock or > denial of service attack when the system is attacked in a manner that > eats all available mbufs. > The traditional way to prevent resource-starvation DoSes from the user populus has been to add administrative limits. Using RLIMIT_SBSIZE does this nicely. Yes, this isn't actually fixing the panics, but it is good preventative medicine. > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
:In 4.3, the code was able to deal with cluster allocation failing. We :have a somewhat different situation now, because many network :interface devices have less-flexible DMA mechanisms which don't allow :packet reception into non-contiguous buffers, so we need to have at :least a certain number of clusters available for this purpose. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same This is an interrupt level mechanism. The mbuf code is *already* allowed to (and does) return NULL in this case so I don't think it applies to the problem under discussion. The case that is causing the panics is with the non-interrupt mbuf allocation mechanism. Specifically, the case where M_WAIT is used. The second problem under discussion, which really ought to be separated out from the mbuf panic problem, is the potential for a deadlock or denial of service attack when the system is attacked in a manner that eats all available mbufs. :[EMAIL PROTECTED] | O Siem / The fires of freedom :Opinions not those of| Dance in the burning flame -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
:In 4.3, the code was able to deal with cluster allocation failing. We :have a somewhat different situation now, because many network :interface devices have less-flexible DMA mechanisms which don't allow :packet reception into non-contiguous buffers, so we need to have at :least a certain number of clusters available for this purpose. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same This is an interrupt level mechanism. The mbuf code is *already* allowed to (and does) return NULL in this case so I don't think it applies to the problem under discussion. The case that is causing the panics is with the non-interrupt mbuf allocation mechanism. Specifically, the case where M_WAIT is used. The second problem under discussion, which really ought to be separated out from the mbuf panic problem, is the potential for a deadlock or denial of service attack when the system is attacked in a manner that eats all available mbufs. :woll...@lcs.mit.edu | O Siem / The fires of freedom :Opinions not those of| Dance in the burning flame -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
I think that what needs to be done is to split the problem in two. First, allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT is used, it simply means 'try harder, sleeping a bit if necessary'. This requires ensuring that all the networking code deal with the failure case - a time consuming but straightforward task. If a failure occurs, one simply drops the packet, not the connection or anything else drastic. just the packet. The second problem that needs to be addressed is resource exhaustion. For example, allocating thousands of connections and socket-opting their buffers as large as possible, or programs such as syslog accepting new connections ad-infinitum. This is a harder problem to fix properly, but a lot of the various issues such as those with syslog can be dealt with in userland rather then the kernel. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Matthew Dillon wrote: :> :Tony Finch wrote: :... :> :> Hmm... well, there is a problem here. I believe this will allow :> you to open the underlying block device read-only as well as mount :> the filesystem read-only. This will confuse the buffer cache badly. : :I don't think so -- spec_open checks whether the block device has been :mounted in order to prevent this, and I made sure that that check :remains in force except when spec_open is called by ffs_mountfs (by :adding the FMOUNTING flag). I assumed that the buffer cache will :handle multiple read-only mounts because it handles multiple userland :reading file descriptors. Ah, I see it now! :> Also, this may not be the best place to put the code. It make sense :> to be able to mount a block device multiple times in a read-only :> fashion, but the code should be in the open for the block device :> rather then in UFS/FFS, so it can be used with other filesystems :> and for other purposes. : :Yes, it's evident that this is true because I had to hack around :essentially the same test in both spec_open and ffs_mountfs; removing :the checks down from ffs_mountfs so it relies on spec_mount to DTRT :would be neater, I think. : :Tony. :-- :f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix Yes. I think this is the right track to take. The result will be more useful to the system and probably a cleaner patch as well. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates panic in 3.3-RC
:Our ftp server crashed early this morning with what appears to be a softupdates :error: : :> Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on /exports/share3/ftp/.2: file system full :> :> panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568 :> syncing disks... panic: softdep_lock: locking against myself : :'perl' would have been the nightly mirror(1) run to sync up our ftp site. : :What additional details would be usefull? We didn't have crashdumps enabled :on this machine, so a backtrace is not fully possible, although it would seem :the contextual evidence for what went wrong is strong. : :-- :David Cross | email: cro...@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd :Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Softupdates has known bugs relating to filesystem full conditions which I believe Kirk is working on. There isn't much you can do until then other then either disable softupdates or work to avoid the disk-full condition. The panic does not occur very frequently so working to avoid the disk-full condition is what I would recommend. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Tony Finch wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. : :Some things I wonder about this change is whether the mounts will share :the same pages in the buffer cache, and whether the resource :accounting is still right. I've subtly funted the meaning of :v_specmountpoint when multiple mounts happen; does this matter? : :Tony. :-- :f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: boston globe article....
: :http://www.boston.com/dailyglobe2/259/business/Even_better_than_Linux+.shtm :l Neato! But next time don't line-break the URL :-) -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
I think that what needs to be done is to split the problem in two. First, allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT is used, it simply means 'try harder, sleeping a bit if necessary'. This requires ensuring that all the networking code deal with the failure case - a time consuming but straightforward task. If a failure occurs, one simply drops the packet, not the connection or anything else drastic. just the packet. The second problem that needs to be addressed is resource exhaustion. For example, allocating thousands of connections and socket-opting their buffers as large as possible, or programs such as syslog accepting new connections ad-infinitum. This is a harder problem to fix properly, but a lot of the various issues such as those with syslog can be dealt with in userland rather then the kernel. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor numbers in shared libraries.
> I would also add that you can "fake" a minor number by simple > multiplication. You have to assume how many digits you want > to allow in minor numbers. > > For example, if we assume a minor number has no more than 3 > digits (allowing the minor numbers to grow to 999) then, > M.N can readily be encoded as M*100+N. > > So, if M = 2 and N = 50, the Elf library number would be 2050. 250, I think you mean. This is good, but you would still need to modify ld.so to know about this, so it'll load ld.so.208 (or version 2.8) when you specified 204 (v 2.4), but won't load ld.so.301 (v 3.1). > It doesn't look pretty when you do an ls. Since ld.so knows about it anyway, you could have it parse file names appropriately, so the version number on the file itself can remain dotted, with a symlink like X.so.2 -> X.so.2.8 to make things easier for mere humans. The problem is that this is less compatible with forign version numbers, unless you had a patch program that applied the appropriate multiplicative factor to the version number when you imported it. How big is the version number field in elf anyway? If it's big enough, you could just arbitrarily say something like "version numbers below 1 are treated literally, otherwise subtract 1 and divide by 100 then take the quotient and remainder as the major and minor numbers". To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Matthew Dillon <[EMAIL PROTECTED]> wrote: :> :Tony Finch <[EMAIL PROTECTED]> wrote: :... :> :> Hmm... well, there is a problem here. I believe this will allow :> you to open the underlying block device read-only as well as mount :> the filesystem read-only. This will confuse the buffer cache badly. : :I don't think so -- spec_open checks whether the block device has been :mounted in order to prevent this, and I made sure that that check :remains in force except when spec_open is called by ffs_mountfs (by :adding the FMOUNTING flag). I assumed that the buffer cache will :handle multiple read-only mounts because it handles multiple userland :reading file descriptors. Ah, I see it now! :> Also, this may not be the best place to put the code. It make sense :> to be able to mount a block device multiple times in a read-only :> fashion, but the code should be in the open for the block device :> rather then in UFS/FFS, so it can be used with other filesystems :> and for other purposes. : :Yes, it's evident that this is true because I had to hack around :essentially the same test in both spec_open and ffs_mountfs; removing :the checks down from ffs_mountfs so it relies on spec_mount to DTRT :would be neater, I think. : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix Yes. I think this is the right track to take. The result will be more useful to the system and probably a cleaner patch as well. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates panic in 3.3-RC
:Our ftp server crashed early this morning with what appears to be a softupdates :error: : :> Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on /exports/share3/ftp/.2: :file system full :> :> panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568 :> syncing disks... panic: softdep_lock: locking against myself : :'perl' would have been the nightly mirror(1) run to sync up our ftp site. : :What additional details would be usefull? We didn't have crashdumps enabled :on this machine, so a backtrace is not fully possible, although it would seem :the contextual evidence for what went wrong is strong. : :-- :David Cross | email: [EMAIL PROTECTED] :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd :Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Softupdates has known bugs relating to filesystem full conditions which I believe Kirk is working on. There isn't much you can do until then other then either disable softupdates or work to avoid the disk-full condition. The panic does not occur very frequently so working to avoid the disk-full condition is what I would recommend. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
:Tony Finch <[EMAIL PROTECTED]> wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. : :Some things I wonder about this change is whether the mounts will share :the same pages in the buffer cache, and whether the resource :accounting is still right. I've subtly funted the meaning of :v_specmountpoint when multiple mounts happen; does this matter? : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boston globe article....
: :http://www.boston.com/dailyglobe2/259/business/Even_better_than_Linux+.shtm :l Neato! But next time don't line-break the URL :-) -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor numbers in shared libraries.
> I would also add that you can "fake" a minor number by simple > multiplication. You have to assume how many digits you want > to allow in minor numbers. > > For example, if we assume a minor number has no more than 3 > digits (allowing the minor numbers to grow to 999) then, > M.N can readily be encoded as M*100+N. > > So, if M = 2 and N = 50, the Elf library number would be 2050. 250, I think you mean. This is good, but you would still need to modify ld.so to know about this, so it'll load ld.so.208 (or version 2.8) when you specified 204 (v 2.4), but won't load ld.so.301 (v 3.1). > It doesn't look pretty when you do an ls. Since ld.so knows about it anyway, you could have it parse file names appropriately, so the version number on the file itself can remain dotted, with a symlink like X.so.2 -> X.so.2.8 to make things easier for mere humans. The problem is that this is less compatible with forign version numbers, unless you had a patch program that applied the appropriate multiplicative factor to the version number when you imported it. How big is the version number field in elf anyway? If it's big enough, you could just arbitrarily say something like "version numbers below 1 are treated literally, otherwise subtract 1 and divide by 100 then take the quotient and remainder as the major and minor numbers". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor numbers in shared libraries.
> > In a discussion with Nate Williams, I have learned that the reason FreeBSD > doesn't use minor numbers with shared libraries because standard ELF doesn't > support it. Is this a hard-and-fast unbreakable rule, or is this something > that could be implemented if it can be done in a way that's compatible with > standard ELF? > > It seems to me that there should be a way of working around this, by adding > a field (either in a new section or an unused field (properly flagged with a > magic number) in the header) to communicate the minor version number to ld.so, > and having ld.so modify its search path by looking for X.so.M.N (where N >= > the number in the header), before X.so.M. This shouldn't break any "foreign" > libraries, nor break libraries created under FreeBSD when used on "foreign" > systems. > > Am I missing something really obvious here? > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > I would also add that you can "fake" a minor number by simple multiplication. You have to assume how many digits you want to allow in minor numbers. For example, if we assume a minor number has no more than 3 digits (allowing the minor numbers to grow to 999) then, M.N can readily be encoded as M*100+N. So, if M = 2 and N = 50, the Elf library number would be 2050. It doesn't look pretty when you do an ls. Also, you would want to "teach" the loaded about this. Just a thought - not really a suggestion - just a thought. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Minor numbers in shared libraries.
> > In a discussion with Nate Williams, I have learned that the reason FreeBSD > doesn't use minor numbers with shared libraries because standard ELF doesn't > support it. Is this a hard-and-fast unbreakable rule, or is this something > that could be implemented if it can be done in a way that's compatible with > standard ELF? > > It seems to me that there should be a way of working around this, by adding > a field (either in a new section or an unused field (properly flagged with a > magic number) in the header) to communicate the minor version number to ld.so, > and having ld.so modify its search path by looking for X.so.M.N (where N >= > the number in the header), before X.so.M. This shouldn't break any "foreign" > libraries, nor break libraries created under FreeBSD when used on "foreign" > systems. > > Am I missing something really obvious here? > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > I would also add that you can "fake" a minor number by simple multiplication. You have to assume how many digits you want to allow in minor numbers. For example, if we assume a minor number has no more than 3 digits (allowing the minor numbers to grow to 999) then, M.N can readily be encoded as M*100+N. So, if M = 2 and N = 50, the Elf library number would be 2050. It doesn't look pretty when you do an ls. Also, you would want to "teach" the loaded about this. Just a thought - not really a suggestion - just a thought. - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
booting current with ata0 etc.
i've just upgraded one of my machines here at work to -current and enabled the ata stuff - but after rebooting it says "cannot mount root" - earlier then i tried this with -current it was working fine and transparent (i.e. without anything to change from wd0 to ad0) - so the question - did anything of this change ? (btw. the machine is an old 486 with isa ide controller and the disk and cdrom are found fine by the ata driver) a lot of thanks in advance for any hint t -- graic...@innominate.de innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: TLB miss handler for alpha running FreeBSD-4.0
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT) Mohit Aron wrote: ...well, I'm speaking from the NetBSD perspective, but it's the same in FreeBSD, because both use the OSF/1 PALcode... > as I understand it, TLB misses on the alpha are handled by the > software (as opposed to x86 where they are handled in hardware). Can someone They're handled by software, but not the operating system software (at least not under the OSF/1 PALcode). TLB misses are serviced by the PALcode, which presents a 3-level page table interface to the operating system. > help me with the FreeBSD code. I'm trying to locate the kernel code that > implements the TLB handler. I'd appreciate if someone can tell me how the > control is given to the software (i.e. what trap is generated), how the > handler is called and finally how does the control return back. Thanks, You should start by reading the `Alpha AXP Architecture Reference Manual', which is in the Third Edition now, I believe. It will describe to you in detail the interface the operating system has to the processor. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
booting current with ata0 etc.
i've just upgraded one of my machines here at work to -current and enabled the ata stuff - but after rebooting it says "cannot mount root" - earlier then i tried this with -current it was working fine and transparent (i.e. without anything to change from wd0 to ad0) - so the question - did anything of this change ? (btw. the machine is an old 486 with isa ide controller and the disk and cdrom are found fine by the ata driver) a lot of thanks in advance for any hint t -- [EMAIL PROTECTED] innominate AG networking people fon: +49.30.308806-13 fax: -77 web: http://innominate.de pgp: /pgp/tg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TLB miss handler for alpha running FreeBSD-4.0
On Thu, 16 Sep 1999 23:10:21 -0500 (CDT) Mohit Aron <[EMAIL PROTECTED]> wrote: ...well, I'm speaking from the NetBSD perspective, but it's the same in FreeBSD, because both use the OSF/1 PALcode... > as I understand it, TLB misses on the alpha are handled by the > software (as opposed to x86 where they are handled in hardware). Can someone They're handled by software, but not the operating system software (at least not under the OSF/1 PALcode). TLB misses are serviced by the PALcode, which presents a 3-level page table interface to the operating system. > help me with the FreeBSD code. I'm trying to locate the kernel code that > implements the TLB handler. I'd appreciate if someone can tell me how the > control is given to the software (i.e. what trap is generated), how the > handler is called and finally how does the control return back. Thanks, You should start by reading the `Alpha AXP Architecture Reference Manual', which is in the Third Edition now, I believe. It will describe to you in detail the interface the operating system has to the processor. -- Jason R. Thorpe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
looking for older (< V1.1) mtv
As mtv 1.1 is producing unusable stuttering audio on 3.3-RC (I know, I'll cvsup tonite..) I wonder if someone has an older version for me to try. W/ -- | / 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
Minor numbers in shared libraries.
In a discussion with Nate Williams, I have learned that the reason FreeBSD doesn't use minor numbers with shared libraries because standard ELF doesn't support it. Is this a hard-and-fast unbreakable rule, or is this something that could be implemented if it can be done in a way that's compatible with standard ELF? It seems to me that there should be a way of working around this, by adding a field (either in a new section or an unused field (properly flagged with a magic number) in the header) to communicate the minor version number to ld.so, and having ld.so modify its search path by looking for X.so.M.N (where N >= the number in the header), before X.so.M. This shouldn't break any "foreign" libraries, nor break libraries created under FreeBSD when used on "foreign" systems. Am I missing something really obvious here? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
looking for older (< V1.1) mtv
As mtv 1.1 is producing unusable stuttering audio on 3.3-RC (I know, I'll cvsup tonite..) I wonder if someone has an older version for me to try. W/ -- | / 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
socket buffer DoS/administrative limits
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general resource limit which can be used in any case.
I've chosen the name "sbsize" (RLIMIT_SBSIZE) for this. Here's what
happens with the limit in action (note that the pdksh in use has been
patched to include the ulimit):
{"/home/green"}$ ulimit -b 200 ; ulimit -a | grep sbsize
sbsize(bytes)200
{"/home/green"}$ ./testsockbuf
socketpair: No buffer space available
14 sockets had been allocated
And another DoS attempt has been foiled with administrative limits :)
I'm sorry for not having something working sooner, but I ran into the problem
of my KASSERT() being tripped, which ended up being caused by me not
grokking an evil local define (look for "#define (snd|rcv) "...) correctly.
After fixing that, everything is wonderful.
The patch, which applies to FreeBSD 4.0-CURRENT, and should be easily
portable or backportable, can be found at:
http://www.FreeBSD.org/~green/sbsize4.patch
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
gr...@freebsd.org`--'
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Minor numbers in shared libraries.
In a discussion with Nate Williams, I have learned that the reason FreeBSD doesn't use minor numbers with shared libraries because standard ELF doesn't support it. Is this a hard-and-fast unbreakable rule, or is this something that could be implemented if it can be done in a way that's compatible with standard ELF? It seems to me that there should be a way of working around this, by adding a field (either in a new section or an unused field (properly flagged with a magic number) in the header) to communicate the minor version number to ld.so, and having ld.so modify its search path by looking for X.so.M.N (where N >= the number in the header), before X.so.M. This shouldn't break any "foreign" libraries, nor break libraries created under FreeBSD when used on "foreign" systems. Am I missing something really obvious here? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
socket buffer DoS/administrative limits
Yes folks, it's that time again: time for more administrative limits!
I've worked out a resource limit (for FreeBSD in this case, but not
non-portable) which allows prevention of DoS by mbuf starvation. Others
are working on making the networking code more resilient, while this is
a general resource limit which can be used in any case.
I've chosen the name "sbsize" (RLIMIT_SBSIZE) for this. Here's what
happens with the limit in action (note that the pdksh in use has been
patched to include the ulimit):
{"/home/green"}$ ulimit -b 200 ; ulimit -a | grep sbsize
sbsize(bytes)200
{"/home/green"}$ ./testsockbuf
socketpair: No buffer space available
14 sockets had been allocated
And another DoS attempt has been foiled with administrative limits :)
I'm sorry for not having something working sooner, but I ran into the problem
of my KASSERT() being tripped, which ended up being caused by me not
grokking an evil local define (look for "#define (snd|rcv) "...) correctly.
After fixing that, everything is wonderful.
The patch, which applies to FreeBSD 4.0-CURRENT, and should be easily
portable or backportable, can be found at:
http://www.FreeBSD.org/~green/sbsize4.patch
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Multiple routes to the same destination
As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple routes to the same destination (identical key and mask). Does the radix tree code in FreeBSD - 4.0 has the same limitation? I am wondering if there is already a solution for this? 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
Multiple routes to the same destination
As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple routes to the same destination (identical key and mask). Does the radix tree code in FreeBSD - 4.0 has the same limitation? I am wondering if there is already a solution for this? 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: Moving bt848 driver to /sys/dev/bktr
It seems Roger Hardiman wrote: > Hi, > > I want to move the Bt848 driver to /sys/dev/bktr > > So, does anyone see any problems with this? Nope, go for it I'd say, and could we then have some of all the version text and stuff put away too, thats why we have CVS :) -Soren To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Moving bt848 driver to /sys/dev/bktr
Hi, I want to move the Bt848 driver to /sys/dev/bktr Here is why. The Bt848 driver (bktr) is contained in one file (/sys/pci/brooktree848.c) and currently runs to about 7000 lines. I've broken the driver down into 4 smaller files which cleanly splits the functionality (tuner, audio, card probing, Bt848 programming) With all the new .c and .h files, the new Bt848 driver consists of about 9 files now instead of 1. Rather than commit 8 new files to /sys/pci I would rather move the whole lot to /sys/dev/bktr and keep them neatly in their own directory (just like all the USB files are in one place) Splitting the files up makes it easier to maintain, easier to understand and easier to update. So, does anyone see any problems with this? Thanks Roger -- Roger Hardiman| Telepresence Research Group ro...@cs.strath.ac.uk | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving bt848 driver to /sys/dev/bktr
It seems Roger Hardiman wrote: > Hi, > > I want to move the Bt848 driver to /sys/dev/bktr > > So, does anyone see any problems with this? Nope, go for it I'd say, and could we then have some of all the version text and stuff put away too, thats why we have CVS :) -Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple NAT alias addresses
On Thu, Sep 16, 1999 at 11:25:53PM -0700, Doug White wrote: [...] > An update: > > I set up a test config at work with some spare boxes. I found that if you > specify an aliasIP that is the primary alias address (as determined by the > -n or -a options), those redirections will be ignored. Others continue to > work. I don't know why they weren't working on the real box, I may had > made a mistake there. > > So this file is wrong: > > interface fxp0 > redirect_port 10.0.0.1:ssh 128.1.1.1:ssh > redirect_port 10.0.0.2:ssh 128.1.1.2:ssh > > But this correct: > > interface fxp0 > redirect_port 10.0.0.1:ssh ssh > redirect_port 10.0.0.2:ssh 128.1.1.2:ssh > > There is some logic in natd to handle the wrong case so that it is > equivalent to the right case, but that logic may be flawed. > You know, natd(8) is not guilty, this is a bug in libalias(3) :-( I have made a patch for this and yet another bug and will send my patch for review to Brian Somers and Eivind Eklund. Please let me know if you would like to test these patches, and THANK YOU VERY MUCH for digging this out, there was a cool hacking! Cheers, -- 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
Moving bt848 driver to /sys/dev/bktr
Hi, I want to move the Bt848 driver to /sys/dev/bktr Here is why. The Bt848 driver (bktr) is contained in one file (/sys/pci/brooktree848.c) and currently runs to about 7000 lines. I've broken the driver down into 4 smaller files which cleanly splits the functionality (tuner, audio, card probing, Bt848 programming) With all the new .c and .h files, the new Bt848 driver consists of about 9 files now instead of 1. Rather than commit 8 new files to /sys/pci I would rather move the whole lot to /sys/dev/bktr and keep them neatly in their own directory (just like all the USB files are in one place) Splitting the files up makes it easier to maintain, easier to understand and easier to update. So, does anyone see any problems with this? Thanks Roger -- Roger Hardiman| Telepresence Research Group [EMAIL PROTECTED] | DMEM, University of Strathclyde tel: 0141 548 2897| Glasgow, Scotland, G1 1XJ, UK fax: 0141 552 0557| http://telepresence.dmem.strath.ac.uk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
j = 0;
> if (flag)
> j = 1;
>
return j;
> }
Or, if you really want to, use your other return scheme.
In other words, initialize j, probably to 0.
Neil
--
Neil Blakey-Milner
n...@rucus.ru.ac.za
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
Gregory Bond writes: > Us humans can see that j is not used without being set, but cc can't. How do > I > remove this warning in a style(9)-compatible way? Initialize j. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple NAT alias addresses
On Thu, Sep 16, 1999 at 11:25:53PM -0700, Doug White wrote: [...] > An update: > > I set up a test config at work with some spare boxes. I found that if you > specify an aliasIP that is the primary alias address (as determined by the > -n or -a options), those redirections will be ignored. Others continue to > work. I don't know why they weren't working on the real box, I may had > made a mistake there. > > So this file is wrong: > > interface fxp0 > redirect_port 10.0.0.1:ssh 128.1.1.1:ssh > redirect_port 10.0.0.2:ssh 128.1.1.2:ssh > > But this correct: > > interface fxp0 > redirect_port 10.0.0.1:ssh ssh > redirect_port 10.0.0.2:ssh 128.1.1.2:ssh > > There is some logic in natd to handle the wrong case so that it is > equivalent to the right case, but that logic may be flawed. > You know, natd(8) is not guilty, this is a bug in libalias(3) :-( I have made a patch for this and yet another bug and will send my patch for review to Brian Somers and Eivind Eklund. Please let me know if you would like to test these patches, and THANK YOU VERY MUCH for digging this out, there was a cool hacking! Cheers, -- 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: "style" question
On Fri 1999-09-17 (18:21), Gregory Bond wrote:
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
j = 0;
> if (flag)
> j = 1;
>
return j;
> }
Or, if you really want to, use your other return scheme.
In other words, initialize j, probably to 0.
Neil
--
Neil Blakey-Milner
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
Gregory Bond <[EMAIL PROTECTED]> writes: > Us humans can see that j is not used without being set, but cc can't. How do I > remove this warning in a style(9)-compatible way? Initialize j. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: panic() the system from the console (was: Re: kern/13721: There is no way to force system panic from console)
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote: > Would not the 'panic' option in DDB be enough to handle this, or > am I missing something? He wanted a to be able to panic() a machine from console without being able to drop to DDB from console. I think this is because he believes that DDB is a security problem. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: panic() the system from the console (was: Re: kern/13721: There is no way to force system panic from console)
On Thu, 16 Sep 1999 13:30:30 MST, Doug wrote: > Would not the 'panic' option in DDB be enough to handle this, or > am I missing something? He wanted a to be able to panic() a machine from console without being able to drop to DDB from console. I think this is because he believes that DDB is a security problem. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
>
> if (flag)
> j = 1;
>
> /*
> * This noop statement is enough to confuse the optimiser so it
> * forgets that j is initialised iff flag != 0
> */
> flag = !!flag;
I don't know about the "official" way to silence the compiler (a well
placed else statement or a "default" switch case usually does the
trick for me) That is to say, I'm willing to argue that fixing the
flow of control is the only clean way of getting rid of these
warnings, unless you know something special about the allowed values
of the offending variable (eg. you know that your switch case is
exhaustive), in which case a dummy "default" or initializer cannot
hurt you much.
Also !!x IS NOT a noop. For example, !!5 == 1. I think you meant to
say `flag = ~~flag', which indeed is a NOP.
Pat.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: TLB miss handler for alpha running FreeBSD-4.0
On Thu, 16 Sep 1999, Mohit Aron wrote: > Hi, > as I understand it, TLB misses on the alpha are handled by the > software (as opposed to x86 where they are handled in hardware). Can someone > help me with the FreeBSD code. I'm trying to locate the kernel code that > implements the TLB handler. I'd appreciate if someone can tell me how the > control is given to the software (i.e. what trap is generated), how the > handler is called and finally how does the control return back. Thanks, TLB misses are handled by the PALcode on the alpha (which is often part of the firmware). There is no trap handler in the FreeBSD code which needs to handle TLB misses as the PALcode deals with it transparently. PALcode is 'special' software which runs at a higher privilege level than the kernel and handles low-level traps, interrupts, etc., translating them into a standard form for the kernel's consumption. If a later processor revision needs different handling for low-level issues, it will use a different PALcode but will generally present the same interface to the kernel. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
"style" question
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing "may not be used" warnings:
int
foo(int flag)
{
int j;
if (flag)
j = 1;
/*
* This noop statement is enough to confuse the optimiser so it
* forgets that j is initialised iff flag != 0
*/
flag = !!flag;
if (flag)
return j;
return 0;
}
Us humans can see that j is not used without being set, but cc can't. How do I
remove this warning in a style(9)-compatible way?
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: "style" question
> I'm looking at cleaning up a few compile nits and I'm wondering what the
> officially approved way of silencing "may not be used" warnings:
>
> int
> foo(int flag)
> {
> int j;
>
> if (flag)
> j = 1;
>
> /*
> * This noop statement is enough to confuse the optimiser so it
> * forgets that j is initialised iff flag != 0
> */
> flag = !!flag;
I don't know about the "official" way to silence the compiler (a well
placed else statement or a "default" switch case usually does the
trick for me) That is to say, I'm willing to argue that fixing the
flow of control is the only clean way of getting rid of these
warnings, unless you know something special about the allowed values
of the offending variable (eg. you know that your switch case is
exhaustive), in which case a dummy "default" or initializer cannot
hurt you much.
Also !!x IS NOT a noop. For example, !!5 == 1. I think you meant to
say `flag = ~~flag', which indeed is a NOP.
Pat.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: TLB miss handler for alpha running FreeBSD-4.0
On Thu, 16 Sep 1999, Mohit Aron wrote: > Hi, > as I understand it, TLB misses on the alpha are handled by the > software (as opposed to x86 where they are handled in hardware). Can someone > help me with the FreeBSD code. I'm trying to locate the kernel code that > implements the TLB handler. I'd appreciate if someone can tell me how the > control is given to the software (i.e. what trap is generated), how the > handler is called and finally how does the control return back. Thanks, TLB misses are handled by the PALcode on the alpha (which is often part of the firmware). There is no trap handler in the FreeBSD code which needs to handle TLB misses as the PALcode deals with it transparently. PALcode is 'special' software which runs at a higher privilege level than the kernel and handles low-level traps, interrupts, etc., translating them into a standard form for the kernel's consumption. If a later processor revision needs different handling for low-level issues, it will use a different PALcode but will generally present the same interface to the kernel. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
"style" question
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing "may not be used" warnings:
int
foo(int flag)
{
int j;
if (flag)
j = 1;
/*
* This noop statement is enough to confuse the optimiser so it
* forgets that j is initialised iff flag != 0
*/
flag = !!flag;
if (flag)
return j;
return 0;
}
Us humans can see that j is not used without being set, but cc can't. How do I
remove this warning in a style(9)-compatible way?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: nuking a vnode
> int major;
> dev_t dev;
> struct vnode *vp;
>
> major = ultp_cdevsw.d_maj;
> dev = makedev(major, self->dv_unit)
> vp = SLIST_FIRST(&dev->si_hlist);
if (vfinddev(dev, VCHR, &vp))
VOP_REVOKE(vp, REVOKEALL);
#if 0
> if (vp) {
> VOP_REVOKE(vp. REVOKEALL);
> }
#endif
> remove_dev(dev);
/* Good one! I had not yet thought about that one */
> 3.3 will be considerably different.
Not one of my main concerns.
Nick
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
