Question about process rlimits
I've been poking at some bugs we have around pushing user memory to/past the limits of our box, and decided to try seeing what happens on a stock FreeBSD system (7.1 in this case). Basically I have a program that mallocs big memory chunks and zeros them to consume both physical and virtual memory. I had expected the program to stop malloc'ing when brk() reaches the process' RLIMIT_DATA (512MB cur and max). It didn't. It happily malloc'd many gigabytes of memory until I stopped it. On our 6.2 based product boxes, RLIMIT_DATA correctly stops the malloc from continuing, just like the manuals say. Am I missing something? -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Strange problems in the old libc malloc routines
We are still using the FreeBSD 6 malloc routines, and are rather suddenly having a large number of problems with one or two of our programs. Before I dig into the 100+ crash dumps I have, I thought I'd see if anyone else has ever encountered this. The problems all seem to stem from some case of malloc returning the pointer "1" instead of either NULL or a valid pointer. Always exactly "1". Where this goes bad depends on where it happens (in the program or inside malloc itself), but that pointer value of "1" is always involved. Some of the structures like page_dir look corrupted too. It seems as if maybe the "1" is coming from sbrk(0) which is just returning the value of curbrk (which is correct, and not even close to "1"). Does this ring any bells? -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: reverse of getchar() read() open() fopen() ?
I've never seen any such thing, but I've done similar things a lot. I'd say malloc/read the whole file in and use a decrementing pointer to return the "previous" character. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On Behalf Of Julian H. Stacey [j...@berklix.com] Sent: Friday, February 11, 2011 4:32 PM To: hack...@freebsd.org Subject: reverse of getchar() read() open() fopen() ? Hi hackers@, Do we have C libraries with reverse of getchar() [ & maybe read() ] & fopen() [ & maybe open() ] etc, to read from end of file toward beginning ? I dont see anything in the See Also sections. I'm not looking to write, just read. I'm looking for something that returns last char in file as first etc, I'm not interested in wchars etc, I could write some C functions, with seek etc & probably will, if none exist, but no point if they already exist ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: seeking into /dev/{null,zero}
I thought seeking past EOF was valid; writing something creates a file with a
hole in it. I always assumed that was standard semantics.
As for /dev/zero and /dev/null, you could easily ask "who cares about the file
position?" But I think some programs might want to seek around and check
values, and those shouldn't change behaviour if someone uses /dev/null as a
test file. It seems pretty trivial to update it, so why not make it behave the
same.
--
Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net Westford, MA 01886-3418
From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On
Behalf Of Garrett Cooper [gcoo...@freebsd.org]
Sent: Tuesday, February 22, 2011 11:22 AM
To: Alexander Best
Cc: freebsd-hackers@freebsd.org
Subject: Re: seeking into /dev/{null,zero}
On Tue, Feb 22, 2011 at 6:11 AM, Alexander Best wrote:
> hi there,
>
> there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just wanted
> to ask what the overall opinion is on this matter. technically it's quite easy
> to seek into those files upon fwrite(3) and fread(3). the point is, if the
> file
> position should be repositioned according the the amount of bytes read or
> written.
>
> the zero(4) and null(4) manual pages claim that both devices act as "ordinary"
> files. right now only reading from /dev/zero will seek into the file. writing
> to /dev/zero and reading/writing to /dev/null will *not* adjust the file
> position.
lseek on CURRENT (and its assorted functions) is funky. Try this as an example:
1. Create a zero character file.
2. lseek with SEEK_SET to byte 1.
2. will always return 1.
My Fedora Linux 13 VM on the other hand actually reports the error
when you try and seek outside the bounds of the file descriptor (this
makes more sense IMO because it accurately reflects reality). This is
an extension to the POSIX spec though as the spec doesn't say whether
or not seeking past the bounds of the descriptor is legal or illegal.
So what I'm trying to say is that the seek family functions in general
don't report helpful data except with success.
Found this when trying to write testcases for lseek(2) the night before last.
I'll get back to you about the POSIXness of those /dev's in the most
recent spec once I get access back to the OpenGroup download section
-_-...
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: New Boot-Loader
-Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon Sent: Monday, March 28, 2011 8:00 AM To: Alexander Best Cc: FreeBSD Hackers Subject: Re: New Boot-Loader Please note that graphical loaders are not very serial console friendly ;-) -- Andriy Gapon Amen, and we have a whole lot of platforms that are only serial consoles (and 9600 baud at that). Also, I like the letters instead of numbers for boot options, for those of us that have known for years that "s" is single user mode, "v" is verbose, etc ....... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: looking for error codes
AFAIK, FreeBSD does not really detect read-only media. This was something I had to add as a small project here at work, and was considering cleaning up to try to get into CURRENT. If there's a real need for it, I could speed that up. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On Behalf Of Warner Losh [i...@bsdimp.com] Sent: Friday, April 01, 2011 10:51 AM To: Andriy Gapon Cc: FreeBSD Hackers; FreeBSD Arch Subject: Re: looking for error codes On Apr 1, 2011, at 8:29 AM, Andriy Gapon wrote: > > I am looking for error codes that would unambiguously signal that a disk > drive has > readonly or write-protected media and that disk drive has no media at the > moment. > I foresee these error codes being used mostly between disk peripheral drivers > and > filesystem drivers. > > I will appreciate your suggestions. > > P.S. > I see that Linux uses EROFS and ENOMEDIUM for these purposes. > I am not sure about EROFS in this role. > And we don't have ENOMEDIUM (nor EMEDIUMTYPE). Maybe we could add ENOMEDIA for that (spelled however Linux spells it) after EDAVE. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: looking for error codes
My work is absolutely NOT in any shape at all to even consider, it's a really tailored point solution to a specific platform issue. I've been working with another engineer to expand it and make it more generic, but that effort is stalled at the moment. My plan was to add something like an ioctl to a device that would query it for read/write status, and percolate that up through the geom layer to capture it for mount requests. The correct place to stop it is at mount time. Even mounting a read-only device as read-write will eventually panic the system as super-block flag updates will not be able to complete. Once that is done, any attempt to open a file for writing fails. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 From: Andriy Gapon [a...@freebsd.org] Sent: Friday, April 01, 2011 11:18 AM To: Andrew Duane Cc: Warner Losh; FreeBSD Hackers; FreeBSD Arch Subject: Re: looking for error codes on 01/04/2011 18:04 Andrew Duane said the following: > AFAIK, FreeBSD does not really detect read-only media. This was something I > had to add as a small project here at work, and was considering cleaning up > to try to get into CURRENT. If there's a real need for it, I could speed that > up. > Yes, that's exactly the problem that I am looking at. So if you have anything to share it will be greatly appreciated at least by me. But I think many more people could benefit from it (e.g. those having SD/SDHC/etc cards). Thanks! > > From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] > On Behalf Of Warner Losh [i...@bsdimp.com] > Sent: Friday, April 01, 2011 10:51 AM > To: Andriy Gapon > Cc: FreeBSD Hackers; FreeBSD Arch > Subject: Re: looking for error codes > > On Apr 1, 2011, at 8:29 AM, Andriy Gapon wrote: > >> >> I am looking for error codes that would unambiguously signal that a disk >> drive has >> readonly or write-protected media and that disk drive has no media at the >> moment. >> I foresee these error codes being used mostly between disk peripheral >> drivers and >> filesystem drivers. >> >> I will appreciate your suggestions. >> >> P.S. >> I see that Linux uses EROFS and ENOMEDIUM for these purposes. >> I am not sure about EROFS in this role. >> And we don't have ENOMEDIUM (nor EMEDIUMTYPE). > > Maybe we could add ENOMEDIA for that (spelled however Linux spells it) after > EDAVE. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: looking for error codes
My work around read-only systems extended this, to allow a general FreeBSD system to come up with "main media" write locked. In the RC files, MFS partitions were made for /tmp, /var, and other places we needed to write. Now that we're upgrading to a later BSD, I hope to refit these with union filesystems instead, to save space and complexity. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On Behalf Of Warner Losh [i...@bsdimp.com] Sent: Saturday, April 02, 2011 11:54 AM To: per...@pluto.rain.com Cc: freebsd-hackers@freebsd.org; m.e.sanlit...@gmail.com; a...@freebsd.org; freebsd-a...@freebsd.org Subject: Re: looking for error codes On Apr 2, 2011, at 1:50 AM, per...@pluto.rain.com wrote: > >> With respect to my knowledge , no one of the operating systems >> has a facility to separate read-only and modifiable parts ... > > SunOS 4 had a partial solution to this, by rearranging the FS layout > so that /usr could be mounted read-only (and often, from a server -- > IIRC a single /usr could be shared among multiple diskless clients). > They used quite a few symlinks so that things could be found in > their accustomed places although actually located elsewhere. The > scheme was fairly well described in the SunOS 4 manual set; granted > _finding_ a SunOS 4 manual set these days may be a challenge :) FreeBSD can do this too. In fact, NanoBSD relies heavily on having most of the system mounted read-only, and has MFS partitions for /etc and /var. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: retry mounting with ro when rw fails
I had been letting this discussion settle a little bit before jumping in, but we've done some work in this area for a few of our platforms. The work was rather ham-fisted, but I've been looking for a way to try to get it cleaned up and back to FreeBSD. Basically, we have a way of detecting that our disk is physically write-protected, a pretty common scenario. Given that, I made some surgical changes to the mount path to prevent read-write mounts of the disk at all. You can't allow that, because even attempts to update the superblock or timestamp will fail and leave buffers outstanding. Over time, this eventually panics the system. My implementation simply drops the read-write flag and mounts the FS readonly, rather than return a failure (which stopped the startup RC scripts). What I was hoping to do was design a better mechanism for passing that R/O detection from the device to the filesystem code. Our implementation uses a platform sysctl that checks the incoming device name against some hardware or software settings. Ick. I don't know enough about device/GEOM calls to do it better though. ....... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Bruce Evans Sent: Friday, April 08, 2011 8:20 AM To: Andriy Gapon Cc: Garrett Cooper; freebsd...@freebsd.org; Jeremy Chadwick; FreeBSD Hackers Subject: Re: retry mounting with ro when rw fails On Fri, 8 Apr 2011, Andriy Gapon wrote: > on 08/04/2011 03:00 Jeremy Chadwick said the following: >> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote: >>> As a generic question / observation, maybe we should just >>> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux >>> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or >>> [Open]Solaris sported similar functionality. >> >> I was going to recommend exactly this. :-) >> >> I like the idea of Andriy's patch, but would feel more comfortable if it >> were only used if a mount option was specified (-o errors=remount-ro"). > > Having the option is appealing, but my main motivation was the simplicity that > comes from having that enabled by default. > That is, you absolutely want an R/W mount then use -o rw, you need R/O then > explicitly -o ro, you "just want" to get that media mounted then the default > behavior tries its best. But the default behaviour is backwards, especially for read-mostly removable media. The default should be ro, possibly with an automagic upgrade to rw iff the media really needs to be written too. Writing timestamps for file system and inode access times doesn't count as "really needs to be written to". I think I prefer requiring an explicit upgrade to rw. rw implies writing access times unless you also use noatime, and I wouldn't want noatime to be set automagically depending on whether rw is set explicitly, so I would want noatime to be set explicitly, and once you do that then you can easily set rw or ro at the same time. A new rm (read mostly) or "rwa" (read or write automagically) flag could give automatic upgrade from ro to rw. I'd also like automatic downgrade to ro after a file system has not been written to for some time (this would avoid fscks in most cases for read-mostly file systems. The ro flag should be per-cylinder-group in ffs so that on big disks, most parts are read-only most of the time and don't need to be checked). Bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: retry mounting with ro when rw fails
For SCSI-attached disks, yes. But other hardware has write-protect sensing (SD cards, CD-roms, our platform). So if you can do that, you should Cleaning up after a failed write is a real problem, one that I needed to avoid. /Andrew -Original Message- From: Andriy Gapon [mailto:a...@freebsd.org] Sent: Friday, April 08, 2011 11:23 AM To: Andrew Duane Cc: Bruce Evans; freebsd...@freebsd.org; FreeBSD Hackers; freebsd-s...@freebsd.org Subject: Re: retry mounting with ro when rw fails on 08/04/2011 15:36 Andrew Duane said the following: > What I was hoping to do was design a better mechanism for passing that R/O > detection from the device to the filesystem code. Our implementation uses a > platform sysctl that checks the incoming device name against some hardware or > software settings. Ick. I don't know enough about device/GEOM calls to do it > better though. I am actually not aware of any way to inquiry write-protection status from hardware. There are distinct SCSI sense codes for that, but you get them only after a failed write attempt. But there are many things that I don't know about... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: DEBUG - analysing core dumps
Damien Fleuriot wrote: > Hello list, > > > > We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and > serving as firewalls and openvpn gateways. > > We use CARP interfaces to provide an active-passive fault tolerant > system. > > > Today, we received a nagios alert from the master box saying it's > rsyslogd process had crashed. > > I logged on to it and tried to relaunch it, to no avail: > pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped) > > > > > I would like advice on how to debug the output from the core dump. > > This is what I get from gdb: > > # gdb > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are welcome to change it and/or distribute copies of it under > certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. This GDB was configured as "amd64-marcel-freebsd". > (gdb) core rsyslogd.core > Core was generated by `rsyslogd'. > Program terminated with signal 11, Segmentation fault. > #0 0x004258ec in ?? () > > > Sadly, getting a backtrace with "bt" gives me more lines with "??", > which is totally not helpful: > [SNIP] > #13 0x7f1f9d70 in ?? () > #14 0x in ?? () > #15 0x6f70732f7261762f in ?? () > #16 0x6c737973722f6c6f in ?? () > #17 0x5f6e70766f2f676f in ?? () > #18 0x746174732e676f6c in ?? () > #19 0x0065 in ?? () > #20 0x in ?? () > [SNIP] > > I am not sure what steps I should follow to get more information ? > > > > Also, I believe that often, core dumps with signal 11 = RAM problems > and I would like a confirmation here. > > I am concerned because rsyslogd is the only process that crashes in > this way, even after I rebooted the firewall. > > Thanks for your input :) For what it's worth, the addresses shown in frames 15, 16, 17, and 18 are ASCII: ops/rav/ lsysr/lo _npvo/go tats.gol /Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Dumping core over NFS
We have a strange problem in 6.2 that we're wondering if anyone else has seen. If a process is dumping core to an NFS-mounted directory, sending SIGINT, SIGTERM, or SIGKILL to that process causes NFS to wedge. The nfs_asyncio starts complaining that 20 iods are already processing the mount, but nothing makes any forward progress. Sending SIGUSR1, SIGUSR2, or SIGABRT seem to work fine, as does any signal if the core dump is going to a local filesystem. Before I dig into this apparent deadlock, just wondering if it's been seen before. ....... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Soliciting opinions on an extension of the bootinfo structure
I'm proposing an extension framework for the bootinfo structure used to pass
information from the bootstrap/loader to the kernel. Although I'm only
proposing this for the MIPS bootinfo, it's completely applicable to any of them.
What I propose is adding an optional platform extension structure:
bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT
struct bootinfo {
u_int32_t bi_kernend; /* end of kernel space */
u_int32_t bi_envp;/* environment */
u_int32_t bi_modulep; /* preloaded modules */
+#ifdef BOOTINFO_PEXT
+ struct bootinfo_pextbi_pext;/* platform extensions if
defined */
+#endif
};
Then, any vendor, platform, architecture, family, or developer could define a
new header file (or expand an existing one) with a definition of struct
bootinfo_pext, and a #define BOOTINFO_PEXT. Include the new (or existing)
header file in your source, and you have whatever extensions you want, without
affecting other platforms, architectures, families, or developers. The file
we're looking to add is sys/mips/cavium/bootinfo_octeon.h:
+/*
+ * Platform bootinfo extensions for OCTEON bootinfo structure
+ *
+ * Specific vendors can add their own bootinfo_pext structures
+ * surrounded by #ifdef OCTEON_VENDOR_XXX
+ */
+
+#include "opt_cvmx.h" /* For OCTEON_VENDOR_XXX definitions */
+
+#ifdef OCTEON_VENDOR_JUNIPER
+#define BOOTINFO_PEXT /* include bootinfo_pext in main structure */
+#define BOOTINFO_PEXT_MAGIC0xCADECADE
+#define BOOTINFO_PEXT_VERSION 1
+
+struct bootinfo_pext {
+int pext_i2cid;
+u_int32_t pext_flags;
+u_int32_t pext_magic; /* Magic number for octeon
pext */
+u_int32_t pext_version; /* Version of pext */
+u_int16_t pext_uboot_major_rev;
+u_int16_t pext_uboot_minor_rev;
+u_int16_t pext_loader_major_rev;
+u_int16_t pext_loader_minor_rev;
+};
+#endif /* OCTEON_VENDOR_JUNIPER */
Reasonable? Unreasonable? Insane?
--
Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net Westford, MA 01886-3418
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Soliciting opinions on an extension of the bootinfo structure
That's correct. This is actually part of a larger effort to open up the MIPS code to a range of new bootstraps. Some bootstraps use the bootinfo facility extensively. It's an easy way to pass some simple information to the kernel without the clutter of metadata and other such things. ....... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: Peter Wemm [mailto:pe...@wemm.org] Sent: Thursday, September 08, 2011 6:48 PM To: Peter Grehan Cc: Andrew Duane; freebsd-hackers@freebsd.org; freebsd-a...@freebsd.org Subject: Re: Soliciting opinions on an extension of the bootinfo structure On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan wrote: >> I'm proposing an extension framework for the bootinfo structure used >> to pass information from the bootstrap/loader to the kernel. Although >> I'm only proposing this for the MIPS bootinfo, it's completely >> applicable to any of them. >> >> What I propose is adding an optional platform extension structure: >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > Any reason not to put the vendor bits into another piece of loader metadata > ? That seems the extensible way to add additional info from the loader, > rather than extending bootinfo (as was the case pre-loader days). > > later, It sounds like they're not using loader, which is probably a reasonable thing for their environment. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Soliciting opinions on an extension of the bootinfo structure
Since this has turned out to be a more contentious idea than I thought, and the upcoming FDT work will probably remove the need for it at all, I'm withdrawing the idea. Although our current code uses such a platform extension structure, we can make do with either metadata or environment variables for the time being. ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net -Original Message- From: John Baldwin [mailto:j...@freebsd.org] Sent: Friday, September 09, 2011 8:32 AM To: freebsd-a...@freebsd.org Cc: Peter Wemm; Peter Grehan; freebsd-hackers@freebsd.org; Andrew Duane Subject: Re: Soliciting opinions on an extension of the bootinfo structure On Thursday, September 08, 2011 6:48:19 pm Peter Wemm wrote: > On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan wrote: > >> I'm proposing an extension framework for the bootinfo structure used > >> to pass information from the bootstrap/loader to the kernel. Although > >> I'm only proposing this for the MIPS bootinfo, it's completely > >> applicable to any of them. > >> > >> What I propose is adding an optional platform extension structure: > >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT > > > > Any reason not to put the vendor bits into another piece of loader metadata > > ? That seems the extensible way to add additional info from the loader, > > rather than extending bootinfo (as was the case pre-loader days). > > > > later, > > It sounds like they're not using loader, which is probably a > reasonable thing for their environment. That doesn't stop you from adding metadata to the kernel. It is just an array of variable length blobs appended after 'end'. Any boot loader can support adding metadata. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Hello World assembly language
Add a 0x0d to the end of the string (0xa = LF, 0xd = CR) ... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 adu...@juniper.net > -Original Message- > From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- > hack...@freebsd.org] On Behalf Of Colin Barnabas > Sent: Wednesday, September 28, 2011 1:27 PM > To: freebsd-hackers@freebsd.org > Subject: Hello World assembly language > > I found a hello world program written in assembly language which > runs on my amd64 8.2 stable box. However, I can not seem to get > it to print a new line. Any suggestions on how to print a line > feed in assembly? > > Here is the code- > > section .data > > message: > db 'hello, world!', 0x0a > > section .text > > global _start > _start: > mov rax, 4 > mov rdi, 1 > mov rsi, message > mov rdx, 13 > syscall > > mov rax, 1 > xor rdi, rdi > syscall > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: BUG: 'glabel label' name's lenght, is truncated without err/warn
Checking the return code of strlcpy won't say if the entire string fit
(exactly) correctly, or if it was truncated. I think explicitly checking the
length of label first is cleaner and more correct.
I would, however, replace "15" with "sizeof(md.md_label) - 1" both in the check
and the printf.
.......
Andrew Duane
Juniper Networks
o +1 978 589 0551
m +1 603-770-7088
adu...@juniper.net
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Ed Schouten
> Sent: Tuesday, November 08, 2011 6:34 AM
> To: Lucas Holt
> Cc: rank1see...@gmail.com; hack...@freebsd.org
> Subject: Re: BUG: 'glabel label' name's lenght, is truncated without
> err/warn
>
> * Lucas Holt , 2005 15:24:
> > --- src/sbin/geom/class/label/geom_label.c 2008/11/21 21:05:31
> 1.3
> > +++ src/sbin/geom/class/label/geom_label.c 2011/11/05 14:15:23
> 1.4
> > @@ -118,6 +118,12 @@ label_label(struct gctl_req *req)
> > return;
> > }
> >
> > + label = gctl_get_ascii(req, "arg0");
> > + if (strlen(label) > 15) {
> > + gctl_error(req, "Label cannot exceed 15 characters");
> > + return;
> > + }
> > +
> > /*
> > * Clear last sector first to spoil all components if device
> exists.
> > */
> > @@ -131,7 +137,6 @@ label_label(struct gctl_req *req)
> >
> > strlcpy(md.md_magic, G_LABEL_MAGIC, sizeof(md.md_magic));
> > md.md_version = G_LABEL_VERSION;
> > - label = gctl_get_ascii(req, "arg0");
> > strlcpy(md.md_label, label, sizeof(md.md_label));
> > md.md_provsize = g_get_mediasize(name);
> > if (md.md_provsize == 0) {
>
> Why not simply perform the strlcpy and check whether
>
> if (strlcpy(...) >= sizeof(md.md_label)
>
> ?
>
> --
> Ed Schouten
> WWW: http://80386.nl/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: mount_nfs does not like exports longer then 88 chars
MNAMELEN is used to bound the Mount NAMe LENgth, and is used in many many
places. It may seem to work fine, but there are lots of utilities and such that
will almost certainly fail managing it. Search the source code for MNAMELEN.
...
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
adu...@juniper.net
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Mark Saad
> Sent: Thursday, April 19, 2012 3:46 PM
> To: freebsd-hackers@freebsd.org
> Subject: mount_nfs does not like exports longer then 88 chars
>
> Hello Hackers
> I was wondering if anyone has come across this issue. This exists in
> FreeBSD 6, 7, and 9 , and probably in 8 but I am not using it at this time.
> When a nfs export path and host name total to more then 88 characters
> mount_nfs bombs out with the following error when it attempts to mount it.
>
> mount_nfs: nyisilon2-13.grp2:/ifs/clients/www/csar884520456/files_cms-
> stage-BK/imagefield_default_images:
> File name too long
>
> I traced this down to a check in mount_nfs.c . This is about line 560
> in the 7-STABLE version and 734 in the 9-STABLE version
>
>
> /*
> * If there has been a trailing slash at mounttime it seems
> * that some mountd implementations fail to remove the mount
> * entries from their mountlist while unmounting.
> */
> for (speclen = strlen(spec);
> speclen > 1 && spec[speclen - 1] == '/';
> speclen--)
> spec[speclen - 1] = '\0';
> if (strlen(hostp) + strlen(spec) + 1 > MNAMELEN) {
> warnx("%s:%s: %s", hostp, spec, strerror(ENAMETOOLONG));
> return (0);
> }
>
> Does any one know why the check for hostp + spec +1 to be less then
> MNAMELEN is there for ?
>
> I removed the check on my 9-STABLE box and it mounts the long mounts fine
>
> I submitted a pr for this its kern/167105
> http://www.freebsd.org/cgi/query-pr.cgi?pr=167105 as there is no
> mention of this in the man page and I cant find any reason for the check at
> all.
>
>
> --
> mark saad | nones...@longcount.org
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-
> unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: GSoC Project: Automated Kernel Crash Reporting System - Discussion
I'm interested in the server side of this project, as it's something we've been working on here. We are developing an internal tool for our own crash reporting that does analysis of backtraces and provides a pretty accurate synopsis of what happened. I have a set of heuristics that can find various panic and trap issues across different CPU architectures, and walk up the trace to the real culprit. This includes, for example, that if memset traps the real problem was memset's caller, not memset itself. We then use this information to be able to search for duplicate bug reports before opening new ones, and can help assign to the right team based on some lists of file and/or routine patterns. There is also a "hint" facility to extend the crash dump data collection for different kinds of crashes (e.g. memory exhaustion, lock issues, etc.) ....... Andrew Duane Juniper Networks +1 978-589-0551 (o) +1 603-770-7088 (m) adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: proper newfs options for SSD disk
> -Original Message- > From: owner-freebsd-hack...@freebsd.org > [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Tim Kientzle > Sent: Thursday, May 24, 2012 12:49 AM > To: Warren Block > Cc: freebsd-hackers@freebsd.org; Matthias Apitz > Subject: Re: proper newfs options for SSD disk > > GPart's alignment option doesn't work for MBR slices. > It rounds to the requested alignment, and then rounds again > to the track size, which defaults to 63 sectors. > > I'm not convinced this is a bug in the design of MBR. I don't > think anything in the MBR design requires that partitions > be track-aligned. > > Tim It really doesn't. This is old school thinking based around minimizing seek and rotation time on slow multiplatter HDDs. It also helped the redundant superblock layout scheme of UFS make that spiral striping down a set of disk platters. My bet is no one has ever bothered to rethink this in the 25 years since ... Andrew Duane Juniper Networks +1 978-589-0551 (o) +1 603-770-7088 (m) adu...@juniper.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: /proc filesystem
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Ian Lepore
> Sent: Thursday, July 12, 2012 6:42 PM
> To: Wojciech Puchar
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: /proc filesystem
>
> On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote:
> > that is what i need.
> >
> > but still need some explanation after using it and reading manual
> >
> > say:
> >PID STARTEND PRT RES PRES REF SHD FL
> TP PATH
> > 1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn
> > /usr/local/bin/Xorg
> > 1378 0x7ab000 0x7bc000 rw- 170 1 0 C-- vn
> > /usr/local/bin/Xorg
> > 1378 0x7bc000 0x80 rw- 140 1 0 C-- df
> > 13780x8007ab0000x8007c3000 r-x 240 32 0 CN- vn
> > /libexec/ld-elf.so.1
> > 13780x8007c30000x8007f rw- 430 1 0 C-- df
> > 13780x8007f0x8007f2000 rw-10 4 0 --- dv
> > 13780x8007f20000x8007f4000 rw-20 4 0 --- dv
> > 13780x8007f40000x800874000 rw- 110 4 0 --- dv
> > 13780x8008740000x800884000 rw- 160 4 0 --- dv
> > 13780x8008840000x800895000 rw- 100 1 0 CN- df
> > 13780x8009c20000x8009c5000 rw-30 1 0 C-- df
> >
> > 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But
> > what "REF" really means here and why it is 2 once and 1 second.
> >
> > 2) what really PRES ("private resident") means? df (default) mappings are
> > IMHO anonymous maps==private data of process. so why RES is nonzero while
> > PRES is zero, while on shared code PRES is nonzero and large. what does it
> > really means?
> >
> > thanks.
> >
>
> I'm catching up on threads I was following before I went on vacation,
> and it looks like there was never a response to this. I'm interested in
> the answers to these questions too, so today I did some spelunking in
> the code to see what I could figure out. I don't think I really
> understand things too well, but I'll just say what I think I found and
> hopefully the experts will correct anything I get wrong.
>
> I think you're right about the first two mappings in that procstat
> output. The REF value is the reference count on the vm object (the
> vnode for the exe file, I presume). I think the reason the reference
> count is 2 is that one reference is the open file itself, and the other
> is the shadow object. I've always been a bit confused about the concept
> of shadow objects in freebsd's vm, but I think it's somehow related to
> the running processes that are based on that executable vnode. For
> example, if another copy of Xorg were running, I think REF would be 3,
> and SHD would be 2.
>
> I don't know why there is no shadow object for the writable data mapping
> and why the refcount is only 1 for that.
BSS that doesn't exist in the file?
...
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
adu...@juniper.net
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Multiple page size support on FreeBSD?
Like all "performance" items (especially VM), it depends on the hardware and the load. On systems with small TLBs it helps more than with large TLBs. With software that needs access to lots of different areas the TLB gets more traffic so large ones help more. The answer for your firefox browser box with i386 is probably different from my compilation engine running MIPS, or his web server running AMD. Back at Digital, we spent a lot of time trying to find the "one true answer" to superpages, only to discover there wasn't one. We ended up with a combination of automatic use from big allocations, a rarely used API to advise for big TLBs, and some background work that coalesced when possible. Andrew L. Duane Resident Architect - AT&T Technical Lead m +1 603.770.7088 o +1 408.933.6944 (2-6944) skype: andrewlduane adu...@juniper.net -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Alfred Perlstein Sent: Wednesday, April 10, 2013 4:00 PM To: Benjamin Kaduk Cc: Wojciech Puchar; Sebastian Feld; freebsd-hackers@freebsd.org Subject: Re: Multiple page size support on FreeBSD? On 4/10/13 11:42 AM, Benjamin Kaduk wrote: > On Wed, 10 Apr 2013, Wojciech Puchar wrote: > >>> How do your tests work? Do you examine PTEs directly to check for >>> superpages or are you relying on the vm.pmap.pde sysctls? >> >> the later. >> >> anyway - algorithm described on list - that heuristics detects >> consecutive page access doesn't really help the urgent case - RANDOM >> access to large amount of memory. > > The algorithm is not a heuristic based on consecutive accesses, > promotion occurs when the entire superpage's worth of memory has > actually been accessed. If I remember correctly, the performance gain > from superpages was only a few percent, so spending more time trying > to decide when to use them would make the algorithm a net wash. > > You should really watch the talk I linked to if you're interested, it > was quite interesting. > >> sequential access will get minimal improvement. >> >> IMHO the only way that really make sens is to add options to madvise >> to give kernel information about usage. > > Maybe. It is cool that FreeBSD got this work via Alan Cox and the others that contributed. I am wondering if it makes sense to have an explicit model. At one place, for a platform with high performance but a very small TLB, we made it possible to explicitly request a large TLB for our process and it made a BIG difference for performance. Sometimes being "general purpose" means that you can expose such low level things for the user to tune instead of requiring them to fit the app to a heuristic that may change. -Alfred > > -Ben Kaduk > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: ``Stopping RAM access''
Well, if the system stops accessing RAM, you had better make sure that *all* the instructions you need are already loaded into the L1 and L2 caches. Otherwise you won't be able to turn RAM back on. That would involve carefully preloading everything through use of the system's appropriate PREFETCH calls, locking down the cache lines to make sure nothing else disturbs them, turning off interrupts, and probably more. To actually turn off RAM, you'd have to power down or otherwise disable the memory controller interface on your board. The procedures for that would be highly platform dependent. /Andrew > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Maslan > Sent: Tuesday, October 30, 2007 5:02 PM > To: Jaroszewski Łukasz > Cc: freebsd-hackers@freebsd.org > Subject: Re: ``Stopping RAM access'' > > > Can anyone give me a clue, how one can ``stop'' system from accessing > > RAM, and then allow it again? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: trap 12 with interrupts disabled, need help
Obvious question: is your stack set up properly, and is it big enough? It could be that you haven't set up a bigger kernel stack yet, and have overrun the small boot stack that the processor was running on. Do you know what the stack pointer is? If it is a few bytes below a page boundary, then overrunning the stack is a good guess. /Andrew > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Sharad Chandra > Sent: Friday, December 28, 2007 12:58 AM > To: freebsd-hackers@freebsd.org > Cc: [EMAIL PROTECTED] > Subject: trap 12 with interrupts disabled, need help > > Hi, > > I got a message on first boot "pid (): trap 12 with > interrupts > disabled", then it hanged and hard boot is required. > It does not appears all the time. > > I tried to figure out the problem, trap 12 is stack exception, find at the > last > http://www.acm.uiuc.edu/sigops/roll_your_own/i386/idt.html > and is coming from kernel, > The location of this message is /usr/src/ > sys/amd64/amd64/trap.c: "pid %ld (%s): trap %d with > interrupts disabled\n", > > What does this exception mean, and what could be possible reason that my > program is doing wrong? How to handle it > > Platform: freebsd 6.1 on amd64 > > -- > > Thanks > Sharad Chandra > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NOR flash drivers
I may have asked this once before, but are any NOR flash drivers available in FreeBSD? I have support that I put into the bootstrap I'm building, interfaced to libstand, but it is read-only, and far from useful for a real UFS. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr [EMAIL PROTECTED] Westford, MA 01886-3418 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: bad RAM? prove it with a crash dump?
owner-freebsd-hack...@freebsd.org wrote: > On Thu, 6 May 2010, Boris Kochergin wrote: > >> My experience with bad memory is that if it causes the machine to >> crash, it won't always happen while the machine is running the same >> process (or kernel thread)--so look for it crashing in a wide >> variety of places--and upon inspection of the core dump, a pointer >> somewhere will be pointing to garbage. > > > so really i'd need to collect two or more crash dumps, and if they > point to different addresses then i can reasonably say the RAM is bad? > > thanks... It's not just that they point to different addresses, it is garbage in many completely independent places. For example, pulling bad registers/return addresses off the stack, or garbage in random unrelated buffers/structures/pointers. On the other hand, if you often have garbage in some structure's "foo" pointer, that indicates a problem (maybe locking) in how your code manages setting that foo pointer. It's a subtle difference. It is also useful to make sure that the garbage itself is different. As mentioned before, a single bit error in an otherwise valid value, or maybe a missing/scrambled byte, these are good indications of memory problems. If random places are often overwritten with something else, that could just be another piece of misbehaving code that is writing someplace it shouldn't. I've often found code that writes some buffer into e.g. a piece of memory it no longer owns that looks like memory corruption until you realize the garbage is always something specific like a vnode structure. /Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: loader prompt: list / on other device
You *should* be able to use device1s2a:/ as a syntax, but I noticed a bug in our old loader code that parses devicenames like that where it wouldn't work correctly with unit numbers. I don't know if that bug is still around, but setting currdev did work around it. /Andrew > -Original Message- > From: owner-freebsd-hack...@freebsd.org > [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of > rank1see...@gmail.com > Sent: Wednesday, June 23, 2010 12:04 PM > To: freebsd-hackers@freebsd.org > Subject: loader prompt: list / on other device > > I've escaped to loader prompt: > Current device is disk0s3a, from which this loader is running. > > My USB stick is device1 and device1s2a is UFS /, on which I > would like to reach some file or simply list directory. > > Syntax? > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Q: case studies about scalable, enterprise-class firewall w/ IPFilter
Well, there are always Juniper Networks boxes :-) -Original Message- From: [EMAIL PROTECTED] on behalf of Matthias Apitz Sent: Tue 8/5/2008 4:05 AM To: freebsd-hackers@freebsd.org Subject: Fwd: Q: case studies about scalable,enterprise-class firewall w/ IPFilter Hello, I've posted the attached mail in the IP Filter mailing list; the only responses have been bad configured vacation replies :-( someone from freebsd-hackers has an idea? thanks in advance matthias - Forwarded message from Matthias Apitz <[EMAIL PROTECTED]> - From: Matthias Apitz <[EMAIL PROTECTED]> Date: Sun, 3 Aug 2008 08:24:15 +0200 To: IP Filter <[EMAIL PROTECTED]> Subject: Q: case studies about scalable, enterprise-class firewall w/ IPFilter Hello, We're currently protecting our network (and as well some FreeBSD laptops standalone) with IPFilter... I'm wondering if there are any case studies about scalable, enterprise-class firewall solutions, redundancy with state-full failover, and application-level inspection, and all that a like, based on IPFilter and FreeBSD; thanks in advance for any pointers matthias -- Matthias Apitz w http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. - End forwarded message - ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Spin down HDD after disk sync or before power off
From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On
Behalf Of Warren Block [wbl...@wonkity.com]
Sent: Wednesday, February 03, 2010 7:43 PM
To: Erich Dollansky
Cc: freebsd-hackers@freebsd.org
Subject: Re: Spin down HDD after disk sync or before power off
On Thu, 4 Feb 2010, Erich Dollansky wrote:
> In case of a reboot, it is already known when the command is given that the
> machine will restart without being powered of.
>
> If you spin-down the disk, you lose one start cycle.
>
> It is not that important but if it can be done with just one if, please, just
> do it.
AFAICT ad_shutdown can't tell whether it's called for a reboot or a
poweroff, it's just told to "shut down". So maybe it's one if, but it's
somewhere above ata-disk.c but below reboot(RB_POWEROFF).
-Warren Block * Rapid City, South Dakota USA
You can register for a shutdown even that *does* get to know the "howto"
variable; we do this quite a bit on some of our platforms that need special
handling at power-off versus halt.
extern void jsrxnle_poweroff_devices(void *junk, int howto);
/* Registering power-off handler to be called at the system shutdown */
EVENTHANDLER_REGISTER(shutdown_final, jsrxnle_poweroff_devices, NULL,
SHUTDOWN_PRI_LAST + 10);
The howto argument can be checked for RB_POWEROFF:
if (howto & RB_POWEROFF) {
/* Spin Down */
}
--
Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net Westford, MA 01886-3418
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Future CPUs - 128 threads
owner-freebsd-hack...@freebsd.org wrote: > Artem Belevich wrote: >>> Seriously, simply because of curiosity - are MIPS CPUs used in any >>> kind of "general purpose" machines? >> >> I'm not aware of any multi-core general-purpose MIPS box. >> Low-end MIPS CPUs are ubiquitous in low-end networking gear. >> High-end multicore MIPS chips are mostly going into mid-to-high end >> networking gear like firewalls. > > > However several companies are using FreeBSD as a base kernel for their > appliance, based on these chips. So they are of direct interest to us. >> >> They are probably not a very good fit for general purpose computing. >> >> --Artem I believe I know of one such company... :-) -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr adu...@juniper.net Westford, MA 01886-3418 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: Dead store elimination in the kernel?
owner-freebsd-hack...@freebsd.org wrote: > Hello, > > I'm asking if FreeBSD is safe regarding dead store elimination made > by gcc? > > By example, in crypto drivers, sensitive datas are cleared by a > bzero() after use to avoid potential leakages. But the bzero() by > itself is useless, is it removed by gcc? > > Thanks, regards. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscr...@freebsd.org" I would think the "correct" way to handle this is to make sure all appropriate items are declared volatile. This would eliminate dead store elimination, as the compiler can tell they are not dead. Unfortunately, the history of drivers (or any code) correctly using volatile declarations is intermittent at best. /Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
