Re: malloc
In message <[EMAIL PROTECTED]>, David Schultz writes: >You can find a somewhat more thorough comparison of malloc >implementations at http://citeseer.nj.nec.com/440671.html . There are many problems with this paper, and my feeling is that it was written with a very specific purpose in mind, although I havn't been able to figure out just what that purpose was. My own research while writing phkmalloc indicated that applications are their own worst enemy when it comes to memory allocation, and therefore the focus for phkmalloc was not to optimize for the individual application, but rather for the system as a whole. The philosphy being that if the entire system gets more work done, the individual applications must ipso facto on average also benefit. I was never able to get the authors of this paper into a dialogue, in particular I tried to find out if they just measured where sbrk() was or if they had tried to examine the real memory load of the application. The reference to correspondence with me in the conclusion can at best me interpreted as "we didn't understand his answer and/or didn't have/wanted to spend more time." It is to some extent remarkable that people still, ten years after I pointed out the fact in my paper on phkmalloc, still hasn't realized that VM systems don't behave like swapping systems did and that memory allocators need to be aware of this. The standing of sbrk() is only a very weak indicator of the live set of active pages needed for an application to run in a VM system, yet people still keep measuring it as a performance parameter. Imagine a C-compiler: read in source for function foo() check on it a lot (allocating 4M) allocate the resulting info, 64 bytes. generate the ass'y output free all temp memory read in source for function bar() ... This will usually result in sbrk() sitting just above that 64 bytes but there may be 4MB of untouched memory beneath it. If you run phkmalloc with the 'H' option, this will be madvise(2)'ed to the system, but even without that, the fact that it is _truly_ untouched means that it will soon become a candidate for pageout, and it will stay out until needed. Many mallocs make the mistake of storing the free-list in the actual free memory as a linked list. This means that to free a bit of memory you have to page in all the otherwise unused space, just to traverse the list. If physical RAM is limited, this is a bad plan. The _real_ way to benchmark a malloc implementatio is therefore to measure how it performs with different amounts of physical RAM available, because then a bad malloc will suffer a terrible hit in paging activity where a good malloc may not result in any significant amount of paging. In informal tests along those lines I have seen differences of up to a factor five in wall-clock time. Of course, with 512MB RAM in a workstation, people will never notice this and I'm just a old foghorn who doesn't know anything about performance, but run a server where you actually have RAM pressure and you might notice the difference. Progress may be overrated, but it seldom goes too far... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: malloc
In message <[EMAIL PROTECTED]>, David Schultz writes: >Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: >> In message <[EMAIL PROTECTED]>, David Schultz writes: >> >> >You can find a somewhat more thorough comparison of malloc >> >implementations at http://citeseer.nj.nec.com/440671.html . >> >> There are many problems with this paper, and my feeling is that it was >> written with a very specific purpose in mind, although I havn't been >> able to figure out just what that purpose was. > >I did say `somewhat', didn't I? ;-) As I mentioned in the part of >my message that you didn't quote, I don't much care for the paper >either, but it's the only half-reasonable comparison I know of. >I don't think the authors know what they're talking about, but they >did collect extensive data for some real world programs, which I >assume is valid. Right, and their study of the correlation between number of bugs on the windshield versus price-tag is scientifically rigorous and highly commendable. You just can't conclude anything useful from it :-) >I agree that the behavior of the program from the point of view of >the VM system is the most important metric. But internal and >external fragmentation are also significant issues. Often, these >are a result of programmers not understanding how their malloc >works. For example, programs that make numerous 2K allocations in >phkmalloc will get twice the amount of memory they asked for, and >since each chunk is page-aligned, it will be twice as bad for the >VM system. Not if they are 2k allocations, but if they are 2k+1 allocations: yes. >A harder problem to solve is fragmentation for long-running >servers, where the RSS tends to creep upwards over time as virtual >memory fills with holes. This is where you want to run phkmalloc with the 'H' option. It practically makes it a non-issue last I tried. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: malloc
In message <[EMAIL PROTECTED]>, David Schultz writes: >Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: >> >A harder problem to solve is fragmentation for long-running >> >servers, where the RSS tends to creep upwards over time as virtual >> >memory fills with holes. >> >> This is where you want to run phkmalloc with the 'H' option. >> It practically makes it a non-issue last I tried. > >Perhaps phkmalloc could be made self-tuning with regards to 'H'; >I doubt many people know when to use that feature. For example, >you might have a heuristic where phkmalloc detects that the program >has been running for a long time or has called malloc() and free() >many times, so it starts using madvise() on some free pages. I actually considered adding a "SIGVMMALLOC" which the kernel could use to modify the behaviour of MALLOC to suit present circumstances. Never got around to it before RAM prices dropped. Search the mail-arcives for some of my ideas. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, Maxim Sobolev writes: >Hi folks, > >I noticed that FreeBSD buf/bio subsystem has one very annoying problem >- once the write request is ejected into it, and write operation >failed, there seemingly no way valid to tell the layer to drop the >buffer. Instead, it retries the attempt over and over again, until >reboot, even though originator of request (usually vfs layer) was >already notified about failure and propagated error condition to the >underlying user-lever program. Yes, I noticed that appeared at some time. That misfeature should be removed in toto. If a retry can solve the issue, it's the drivers responsibility to retry as much as makes sense and then fail if it doesn't work. Neither the buf nor the bio layer should get involved in those retries. If you really want to change the behaviour here, you should add a flag on the buf going down, saying "Never, ever retry". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
5.0-RUSH: -current install testers wanted!
I built a "make release" overnight and I managed to install from it by copying the boot.flp image to a ZIP disk, selecting Minimum and FTP passive. So far so good. But we all know that sysintall has a few more bells and whistles than that, so NOW is the TIME of all good men to come to the aid of their favourite installer! I want as many people as possible to beat up on sysinstall as much as they can. And I want them to do it RSN: 5.0-R is only 9 days away. Please try to be creative in the choices you make in sysinstall, we don't need 20 people all testing ftp-passive, we need to get all the media options tested, IPv4 and IPv6, all the different distributions, scripted installs, on different hardware configs and so. If you find problems, please try to see if you reproduce them, if you can, try to see if you can isolate them to some particular menu choice or set of circumstances. Please report your findings with send-pr. If you don't have the machine-power to run make release yourself, I hope the japanese snapshot server is producing good snapshots, if that fails, I would appreciate if somebody will produce and put up good releases and/or ISO images somewhere. I can't promise to fix all the issues which come up, but I will do my very best... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] .de writes: > >Is sysinstall still supposed to copy the contents of the mfsroot- >image to /stand ? This at least results in two copies of sysinstall, >one in /stand and the other one in /usr/sbin. That is intentional -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] .de writes: >On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote: >> >> That is intentional >> > >Is it ok then that the sysinstall in /stand of the 0917-JPSNAP >immediately dumps core with signal 10 when run on a 1017 -current ? Current developments considered: that's probably to be expected. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, Hanspeter Roth writes: > On Oct 18 at 20:45, Maxim Sobolev spoke: > >> again, then again ad infinitum. The same effect if you'll mount >> write-protected floppy in read/write mode. This is just lame, but I'm not willing to to take a shouting match with the person who committed this brain-damage. >As of a write-protected floppy, why is it allowd to be mounted as >writeable? >The mount should be degraded to readonly or rejected. That's a slightly more involved issue because you would have to actually try to write to it before you find out that you can't. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, Hanspeter Roth writes: > On Oct 29 at 18:34, Poul-Henning Kamp spoke: > >> That's a slightly more involved issue because you would have to >> actually try to write to it before you find out that you can't. > >Isn't there a means to determine the state of the protection before >the mount is attempted? As far as I know there isn't. I'm not sure if it is a device driver (morituri te salutem!) or hardware issue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, David Schultz writes: >IMO, the retry-forever bug is the >real problem, but I'm a bit skeptical that it's easy to solve >safely. Just revert the commit which added it recently. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to allow a driver to report unrecoverable write errors to the buf layer
In message <[EMAIL PROTECTED]>, David Schultz writes: >Thus spake Poul-Henning Kamp <[EMAIL PROTECTED]>: >> In message <[EMAIL PROTECTED]>, David Schultz writes: >> >> >IMO, the retry-forever bug is the >> >real problem, but I'm a bit skeptical that it's easy to solve >> >safely. >> >> Just revert the commit which added it recently. > >Recently? I know that the bug was present at least six months >ago, and probably earlier as well. That's "recently" enough for me :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem corruption
In message <[EMAIL PROTECTED]>, Larry Sica wri tes: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Not sure if hackers is the correct place to ask about this but... > >On Friday, November 8, 2002, at 06:28 PM, Nick Rogness wrote: > >> >> We have a server that is doing some wierd things. /var/mail filesystem >> (/dev/idad2s1e) is reporting errors during certain tasks (like dump). >> It does fsck clean umounted. I have yet to see this type of error and >> can't tell whether this is a bug or a hardware problem: >> >> Nov 8 15:41:20 pop1 /kernel: dscheck(#idad/0x20014): negative b_blkno >> -791620152 >> Nov 8 15:41:20 pop1 /kernel: dscheck(#idad/0x20014): negative b_blkno > >I've seen mention of this before, not sure what the fix was. I heard >about this a few years ago on some quantam drives, the guy updated his >firmware and it went away iirc. Does it do this only when you dump or >under other circumstances? If other circumstances, which ones? The fix is to not run dump(8) on a live filesystem. You should either use a snapshot or umount the device. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem corruption
In message <[EMAIL PROTECTED]>, Nick Rogness w rites: >> The fix is to not run dump(8) on a live filesystem. You should >> either use a snapshot or umount the device. > > I've been running dump for years on live filesystems with FreeBSD > and never had a problem. I was not aware of any snapshot feature > available for 4.X-STABLE (only 5.0)? It works most of the time, but not always. There is no way for dump(8) to realize what has changed under its feet and therefore it sometimes ends up with a bunch of negative blocknumbers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shrinking /(s)bin: A Proposal
In message , Rich Morin writes: >My spouse had the problem of creating a bootable copy of A/UX on a >single floppy. She decided to write a "doitall" program that had >functionality from a number of small commands. This amortized the >overhead a great deal. man crunchgen. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tty/pty devices not safe in jail?
In message <[EMAIL PROTECTED]>, Matthew Dillon w
rites:
>Hmm. While tracking down a null mount issue I think I might have
>come across a potentially serious problem with jail. It seems to
>me that it would be possible for someone inside a jailed environment
>to 'steal' pty's, tty's, or the tty side of a pty that is being
>used from within other jails or by processes outside the jail. Has
>this ever come up before?
There has always been code in kern/tty_pty.c which makes sure that the
master and slave have the same prison:
} else if (pti->pt_prison != td->td_ucred->cr_prison) {
return (EBUSY);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tty/pty devices not safe in jail?
In message <[EMAIL PROTECTED]>, Matthew Dillon w
rites:
>:
>:In message <[EMAIL PROTECTED]>, Matthew Dillon w
>:rites:
>:>Hmm. While tracking down a null mount issue I think I might have
>:>come across a potentially serious problem with jail. It seems to
>:>me that it would be possible for someone inside a jailed environment
>:>to 'steal' pty's, tty's, or the tty side of a pty that is being
>:>used from within other jails or by processes outside the jail. Has
>:>this ever come up before?
>:
>:There has always been code in kern/tty_pty.c which makes sure that the
>:master and slave have the same prison:
>:
>:} else if (pti->pt_prison != td->td_ucred->cr_prison) {
>:return (EBUSY);
>:
>:
>:--
>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>:[EMAIL PROTECTED] | TCP/IP since RFC 956
>
> Ah, excellent. Is there a limit inside the prison so a jail cannot
>exhaust all available ptys?
No.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tty/pty devices not safe in jail?
In message <[EMAIL PROTECTED]>, Matthew Dillon w rites: >Would people be interested if I added such a feature? Limit the >highest allocatable pty to 90% when operating within a jail? In practice there is no real "upper limit" on ptys, apart from the amount of KVM you need. I don't really think running out of ptys is a problem compared to other resource limitations (number of processes etc etc). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tty/pty devices not safe in jail?
In message <[EMAIL PROTECTED]>, Julian Elischer writes : >> There has always been code in kern/tty_pty.c which makes sure that the >> master and slave have the same prison: > >but a jailed user could perform a denial of service by using up all teh ptys.? There is no general resource protection for jails: You can use up any resource you can get your hand on: processes, disk, filedescriptors, ptys, mbuf clusters, you name it. If you want to add resource limitations to jails, then do it right from the bottom, instead of as local hacks in random drivers or other hotspots. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Report from EuroBSDCon 2002
a virtualized
network stack in FreeBSD. Fortunately a number of people alerted
me and I was given a private demonstration afterwards: You can run
fully virtualized network stacks on the same machine. And fully
virtualized means that each stack has its own interfaces, its own
routing table, sockets, ipfw rules etc etc etc. This brings us one
step closer on having truly virtual machines and offers some truly
astonishing abilities. I tell ya: this stuff is coming to -current
RSN: http://www.tel.fer.hr/zec/BSD/vimage/
des@ finished the talks off with a good talk about PAM on FreeBSD.
A number of people had asked me about the GBDE stuff so a small BoF
were held on the subject ending when a man warned us that the last
buf to the social event would leave in 10 minutes. Quite a bit
more interest than I had expected.
40 minutes later we entered the bus and headed for the central
rail-road station, next to which a "party-boat" took us for a tour
of the canals while food, drink and general partying was experienced.
I have no idea why they always serve indonesian food at events like
this in .nl. Neither did Edwin when I asked him and he should know:
he lives here. The novelty on this boat was the food elevator.
A small informal committer gathering on deck uncovered a few
interesting historical facts and that it's f**king cold at night
in Amsterdam this time of the year. The lockpickers showed a their
skills, lack thereoff and an assortment of pointy tools which I
belive has not been brought here as carry-on luggage. Should have
brought the spare dual-six cylinder lock I have back home but I
doubt they could have done much, most of the locks they had were
quite simple cylinders. Even the dance-floor got used, that's
somewhat seldom for computer conferences.
Guido@ tried to make a lump sum down payment on the beer-ware
license, using his conference expense account I suspect. Pictures
will undoubtedly be posted.
Sunday morning was scheduled to start late, a sign og highly
intelligent planning, and two tracks of decent talks filled the
day. My own talk was in the last slot so over the day I got
increasingly unattentive and tense. Packet loss up to 56%
in the terminal room.
Admired the vendors who had a table each. The FreeBSD crowd were
there, and showed why any self-respecting committer should answer
"boxers" in the future.
There was a clothing company there called OpenBSD, later somebody
told me they make an operating system as well.
Apple showed an animated pictureframe, about 23 inches I guess,
which in a fully automatic way could display images of staggering
beauty while playing soothing music thoughout the entire conference.
Some people claimed that it was a computer, but I saw now signs of
that at any time, only the beautiful images and the soothing music.
NetBSD were there, and they seem to have a bunch of technical
"sales-material" which will certainly give them good mileage in
the embedded world. They also had some dot(1) produced graphs
related to the new RCng thing, it didn't quite come across to
me as an argument for the "pro" side.
My timecounter talk went ok, but I failed to come up with a good
joke about people arriving 30 minutes early for a talk about
timekeeping.
Finally we got to the closing session, where Guido told us that we
should have hacked his machine and complained about the DNS server
to win prizes. Nobody did either it seems. He did use the occasion
to give me a pair of wooden shoes ("cloggies") which totally ruined
my carefully planned luggage design. The two capable organizers from
ICONIX.NL got champagne and a box of chocholate for a job well done.
Interestingly enough, the "BSDcon sweets curse" seems to be going
strong and have left the organizers with three boxes of "red hot
devils". Nik didn't quite seem to have been able to get rid of
the remaining "Brighton rock".
And then a bunch of tired danes sat around in the Lobby with a drink
waiting for the cab to take us to the airport. The rest of the
story is long and torturous, keywords are: luggage handling strike
in CPH, canceled plane, stuck in hotel for the night, celebrating
Kristens 40 year birthday, more canceled planes, 10 hours in a car
and one hour by train, arrive totally wasted.
A big thanks from here to the organizers.
Next time seems to be 2003 in the US and then 2004 in Paris.
See you there !
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Report from EuroBSDCon 2002
In message <[EMAIL PROTECTED]>, Luigi Rizzo writes: >Very nice report, thanks :) > >just wanted to mention that i am totally unrelated to the Torino >crew (at least, as far as i can tell... unless there was some >former student of mine!) and the credit for the cool stuff >they did is entirely to them. I'm pretty sure I heard them say that it was all your fault they got started on this, but then again, I may be totally wrong. >> Luigi@ had sent a part of his crew from Torino to talk about VPN >> and other cool networking stuff in FreeBSD. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel basic block profiling
In message <[EMAIL PROTECTED]>, Harti Brandt wri
tes:
>${subject} seems not to work on -current. First of all 'man kernbb' tells
>me to compile at least one kernel file with '-a'. Well, gcc tells me that
>it doesn't know anything about '-a'. After some grepping in the gcc
>sources I came to the conclusion, that -fprofile-arcs is what it wants.
>But even then 'kernbb' gives me nothing on the new kernel and gdb shows
>bbhead to contain a 0. As far as I could figure out, the profile-arcs uses
>a ctor section and I somehow doubt, that this works in the kernel case.
>
>So, is ${subject} usable on current or is it just a stale feature?
I havn't checked it lately, but it should be brought to work again
I think, it is a very valuable provider of insight into what code
is really executed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: strange coredump in malloc_bytes()/libc in 4.7p2
In message <[EMAIL PROTECTED]>, Daniel L ang writes: >Hi folks, > >before I send a PR, I though I'll ask about the opinion >of the people here. > >Background: > >We run an IRCnet ircd on a FreeBSD box here. This combination >lived very happy for a very long time. Recently I've updated >the box to 4.7-RELEASE-p2. After the update, the "ircd" >won't start any longer. > >Recompile of ircd did not help at all. > >ow, after many hours trying to debug the problem, I built >a world with CFLAGS=-g to get a libc with debugging symbols >and a useful backtrace: > >(gdb) bt >#0 0x2819244b in malloc_bytes (size=476) >at /usr/src/lib/libc/../libc/stdlib/malloc.c:673 >#1 0x28192581 in imalloc (size=476) >at /usr/src/lib/libc/../libc/stdlib/malloc.c:715 >#2 0x28192a44 in malloc (size=476) >at /usr/src/lib/libc/../libc/stdlib/malloc.c:1076 >#3 0x281885b5 in calloc (num=1, size=476) >at /usr/src/lib/libc/../libc/stdlib/calloc.c:49 I think we can more or less conclude that something has trashed your memory. I'd suggest you try to run your program with ElectricFence or similar. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
End-Of-Life announcement for M-Systems DiskOnChip driver ("fla").
This is _only_ about the driver for the DiskOnChip devices from M-Systems. This does not affect any other device. If you have never seen a /dev/fla0 mounted on your system, you don't need to read the rest. I realize that there are users of the DiskOnChip hardware out there now, but I seriously don't expect there to be any users once we get to FreeBSD 6.0 so I plant to remove the driver once the 5-stable branch is laid down. This means that the 5.x series of FreeBSD releases will be the last to have built in support for the Disk-On-Chip driver. The driver in the tree works with the M-systems devices I have to test with, but M-Systems have neither sent me the necessary software updates nor hardware samples of the latest generation of the DoC and I have received no emails from people who were stuck because of this. Combine this with the fact that the DoC is a CPU-poll technology where you busy-wait for the flash devices to do their thing, rather than get an interrupt when they are done, I think we can safely say that the DoC is well past its prime time. As far as I can tell, people use CompactFlash these days instead. Protests to: [EMAIL PROTECTED] Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64 bit endian routines
In message <[EMAIL PROTECTED]>, Nate Lawson writ es: >Both scsi and geom implement unaligned access functions that perform byte >ordering. I never intended to supplant them with __bswap*(). What I want >is for machine/endian.h to have functions that provide 16-64 bit endian >conversions in both aligned and unaligned access forms. After these functions >are there, I'd like us to unify use of them and remove driver-private >versions. I'm all for a unification. I only made my private version in geom because I couldn't get any responses when I raised the issue on [EMAIL PROTECTED] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: D_KQFILTER & ltmdm.
In message <[EMAIL PROTECTED]>, "Mike Edenfield
" writes:
>I'm working up a patch to the ltmdm to accomodate phk's recent changes to
>cdevsw. I've gotten the module to build and load, but I have two questions
>before I go ahead and submit a pr.
>
>1) I simply removed D_KQFILTER from the list of flags. Based on phk's
>commit message I assumed the flag was simply not needed, and that removing
>it would not break anything. Is this assumption correct? Thus far the
>module is working (it loaded w/out a panic anyway) but I haven't tested it
>very much.
correct. D_KQFILTER was added so that we wouldn't dereference the
d_kqfilter pointer in case it was not there (ie: if the driver was
binary and compiled before the d_kqfilter pointer was added to
cdevsw). It's hacks like this we avoid now.
>2) The patch, which I've included below, only works for -CURRENT with
>rev1.170 of conf.h. I wasn't sure how to get the preprocessor to
>differentiate between -CURRENT before and after this specific revision of a
>specific file. What is the correct way to do this? Or, alternatively,
>should the patch simply assume FreeBSD 5 is the latest -CURRENT and not
>worry about the imcompatibility w/ 5.0-RELEASE?
I have bumped __FreeBSD_version so you can test for this.
But your patch is wrong. Please format the initialization like
you see in all the other device drivers:
static struct cdevsw sio_cdevsw = {
.d_maj = MAJOR_AUTO,
.d_flags = D_TTY,
.d_open = sioopen
etc
etc
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Makefiles to modify for adding new sys/*.h header files?
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes
:
>On Sat, Mar 08, 2003 at 11:05:16AM -0500, Craig Rodrigues wrote:
>> Hi,
>>
>> If I add new headers file in the directories /usr/src/sys/sys
>> and /usr/src/sys/{arch}/include, then which Makefiles do I need
>> to modify in order to make sure that my new header files
>> get installed properly when I do a make installworld?
>
>None.
... which is a bug.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: per-open device private data, mmap
In message <[EMAIL PROTECTED]>, Eric Anholt writes: >To work properly, the DRM needs an area of memory per open of the device >which stores information on whether that fd is authenticated and also to >have a unique identifier for use in the lock. I have some plans for this for 6.x but we would have multiple respiratory failures in the re@ team if I even think about it until the RELENG_5 branch has been laid down, so for now you're on your own. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: "Expensive timeout(9) function..."
In message <[EMAIL PROTECTED]>, Yar Tikhiy writes: >Hello, > >I'm getting the following DIAGNOSTIC messages on my -CURRENT box: > > Expensive timeout(9) function: 0xc02677e0(0) 0.006095064 s > >(it's uma_timeout(), which triggers the warning once per boot) > > Expensive timeout(9) function: 0xc0141610(0xc0dfcc00) 0.006581587 s > Expensive timeout(9) function: 0xc0141610(0xc0dfcc00) 0.008510173 s > >(and this one is fxp_tick(); it triggers the warning from time to time) > >Are those warnings harmless? Yes, but indicative of code which needs attention, but harmless. >As far as my understanding of the issue reaches, a timeout function >is called under protection of the Giant mutex unless it's marked >as MP-safe, and that's the reason to spend as little time as possible >in it. Right? Yes, but there are other reasons why you would generally not want to spend too much time in the timeout function, mostly that it may screw up other time-critical things in the system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Expensive timeout(9) function..."
In message <[EMAIL PROTECTED]>, Mike Silbersack writes: > > >On Tue, 1 Apr 2003, Yar Tikhiy wrote: > >> Thanks for your explanation! >> >> I hope this little thread will draw the attention of the >> responsible or interested parties to the warnings ;-) >> >> -- >> Yar > >The _tick routines are not easy to fix, FWIW. MII access functions are >quite time consuming almost any way you look at it. I'm not sure the _tick functions should even be called from a timeout(). In many ways it seems preferable to me to have then run sequentially from a single thread, possibly via a task-queue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Expensive timeout(9) function..."
In message <[EMAIL PROTECTED]>, Mike Silbersack writes: >Yeah, I suppose limiting it to one mii_tick routine per second would help >somewhat... but it's still a bad situation. I wasn't advocating slowing it down that much, merely trying to run it sequentially out of timeout()'s hair. >Actually, we could improve it quite a bit if someone adds NANODELAY() >(hint, hint...) Couldn't we have a first-run nanodelay that just used >nanotime to do the counting for it? It should probably be called either nanosleep() or nanospin(). It is not a trivial task to do it. Writing the short end calibration code to be sufficiently robust and precise will take some time and a lot of experiments. There used to be a crumbled note with this somewhere in my stack of TODO items, but by now I suspect that it is ironed perfectly flat from the weight of all the stuff on top of it. But to add to my knowledge-base: What length of delays are you looking for ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Wed, Jun 04, 2003 at 10:44:53PM -0700, Brian O'Shea wrote:
>> System panics after PQI Travel Flash (USB Compact Flash reader/writer mass
>> storage device) is plugged in.
>>
>> This is 5.0-RELEASE on i386.
>
>Many things have been changed since 5.0.
>Please retry with 5.1-RC1 or wait the few days for 5.1-RELEASE.
Actually, he probably wants this patch which I just sent to the
QuirkMeister:
Index: scsi_da.c
===
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.143
diff -u -r1.143 scsi_da.c
--- scsi_da.c 15 May 2003 17:35:35 - 1.143
+++ scsi_da.c 5 Jun 2003 12:47:54 -
@@ -507,6 +507,16 @@
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, "OTi", "Flash Disk", "*"},
/*quirks*/ DA_Q_NO_6_BYTE
+ },
+ {
+ /*
+* PQI Travel Flash, rev 1.10/2.05, addr 2
+* General Flash Disk Drive 2.05
+* Serial Number ST92163-2000
+*/
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive",
+"*", "*"},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
}
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >Mine works fine without quirks: > port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307), > PQI(0x0483), rev 2.05 Mine is: port 1 addr 2: full speed, power 100 mA, config 1, Travel Flash(0x0001), PQI(0x3538), rev 2.05 I do find it odd, that the quirks are not assigned in the umass code and passed to scsi_da some way, that would be much more reliable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >On Thu, Jun 05, 2003 at 04:10:59PM +0200, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Bernd Walter writes: >> >> >Mine works fine without quirks: >> > port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307), >> > PQI(0x0483), rev 2.05 >> >> Mine is: >> >> port 1 addr 2: full speed, power 100 mA, config 1, Travel Flash(0x0001), >> PQI(0x3538), rev 2.05 > >Is this the 4 slot USB1.1 version? >Mine is an older 3 slot USB1.1 device. > >> I do find it odd, that the quirks are not assigned in the umass code and >> passed to scsi_da some way, that would be much more reliable. > >Considering that we may require quirks for usb-ata converters but see >the drives in scsi_da I agree. >In this case it's not critical - the quirks are not wrong for my >version, just not required. >Nevertheless: Does it panic without quirk or simply don't work? It seems to hang the gadget which blocks the daopen() which holds GEOM's topology lock which makes a lot of things not happen any more. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: imgact_gzip.c
In message <[EMAIL PROTECTED]>, David Yeske wr ites: >imgact_gzip.c seems to be pretty stale. Has anyone considered fixing this? If this >were fixed >then kldload() / linker_load_module() could deal with a gzipped .ko file, and gzipped >elf >executables would work also? At least originally imgact_gzip.c was heavily a.out aware. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Preliminary gbde performance patchset
How cute. Our favourite troll has given us a link which redirects to an url which he thinks will send a message to SCO: http://www.sco.com/company/feedback/thanks.html?location=206&category=10&[EMAIL PROTECTED]&subject=FUCK_YOU_ASSHOLES!!!&message=SCOsuckmydick!! Unfortunately, his skills are not up to the task, so it does not work at all. Poor troll. I hope we can get the social services or a mental institution near his home to take care of him, he _really_ need to take his medication every day. Poul-Henning In message <[EMAIL PROTECTED]>, "Jason Str yker" writes: >Hello hackers, > >I've finished testing my first set of performance patches for gdbe. After >some testing >it seems to work ok. The performance gain is about 15% on i386 and >sparc64. Other systems >haven't been tested yet, but I encourage all of you to test and give >feedback. There's a >weird bug in SMP systems that I haven't been able to fully track down. >Sometimes gbde will >fail to attach on systems with more than 1 CPU. Fortunately, it's >harmless. > >Fetch the patch from here: http://tinyurl.com/cx5f > >The patch should apply cleanly on any recent -CURRENT. Sorry, it won't >work on 5.0-R >It's my first patch against the kernel code, so expect a few >non-BDE-complying mistakes. Sorry >for that. > >Thanks, > Jason >-- > Jason Stryker > [EMAIL PROTECTED] > >-- >http://www.fastmail.fm - IMAP accessible web-mail > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Preliminary gbde performance patchset
>Stay out of it Pull, you have no poul with me and you know it. Well, apart from the fact that it seems that I can tell vowels apart a fair bit better than you, I clearly seem to have quite some pull with you because you feel compelled to react to my emails to you. Isn't it very depressing to be so lame that you cannot contribute meaningfully to the project and have to resort to vent your frustration over your own suckyness by trolling our mailing lists ? It must be a real torture to be so weak that you can not even turn your back on your big failure and get on with your life, but instead be drawn again and again to vent your anger and display your lameness for all the people who you most of all wanted to impress. That dot-com thing really made a lot of failures like you think they could fly, didn't it ? If you weren't so lame, I could almost have felt pity for you. Anyway: now please run along, be quiet and find something to play with, and leave the grown ups around here to do their work. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Preliminary gbde performance patchset
>Stay out of it Pull, you have no poul with me and you know it. I is so sad to see how you keep repeating this silly thing. Do you expect that by repeating it we will suddenly "get it" and fall in awe with your skills with words ? I hate to think this is the best you can do when you try to be funny, that would so pathetic. That's almost as lame was the fact that you claim to speak for "the community" and claim to know the truth, yet you dare not use your own name, because you know we would laugh even harder then. As for you claim to have been a committer, or even that you have code in the tree: Yeah, right, and sell me the Eifel tower too. There is one count where I will concede that the FreeBSD project sucks: We have really lousy incompetent stupid boring trolls. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Preliminary gbde performance patchset
>Why am I not using my real name? I don't >want to be threatened again by members of FreeBSD. Since you are obviously to dim to realize the following very simple fact I will spell it out in detail to you: A better strategy would be to not upset the members of the FreeBSD project by lamely trolling our mailing lists. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Retrieving disk geometry
In message <[EMAIL PROTECTED]>, Andrew writes: >Hi, > >Under FreeBSD 4.x the ioctl DIOCGDINFO could be used to retrieve the >number of cylinders, heads and sectors of a drive. This could be called on >/dev/ad0 for example. Under FreeBSD 5 it seems to produce "Inappropriate >ioctl for device" unless you call it on an individual partition >(/dev/ad0s1a for example). > >Is there a way around this? Use the ioctls you find in they should work on all disk devices. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Interview in Byte with Chris Sontag/SCO and FUD relatingtoBSDsettlement agreement
In message <[EMAIL PROTECTED]>, "Greg 'groggy' Lehey" writes: >>> I suppose you mean John Lions. >> >> Yes. I always spell his name wrong. >> >>> He got into a lot of trouble for that, and I doubt he would have >>> got away with it in the USA. >> >> Really? Can you point to the signed non-disclosure agreement >> that he violated in order to publish his commentary? The U.S. >> was not nearly as anal about this stuff until the 1980's. > >Things have got worse, yes. But certainly there was enough trouble in >the 70s. Peter Salus book "A Quarter Century of UNIX" mentioned that he got in trouble and that AT&T stopped the distribution (to the extent that they could). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Encrypted filesystems
In message <[EMAIL PROTECTED]>, Erez Zadok wr ites: >In message <[EMAIL PROTECTED]>, Michael Sierchio writes: >> Peter B wrote: >[...] >> > Which operating systems manage to effectivly to use encrypted swap..? >> >> That's quite a different problem -- Poul-Henning Kamp's done work >> in GEOM based disk encryption which is directly applicable to >> encrypting swap. Key management is always interesting. > >You might check the work/papers by Niels Provos on encrypted swap. > >We've been working on this problem for our NCryptfs. To provide a >comprehensive solution, we have to also handle swap. Luckily in Linux, >there are specific VOPs and APIs that make it easy to hook a crypto f/s w/ >the swap. I will present a paper on the GBDE encrypted disk facility at BSDcon2003. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: complicated downgrade
In message <[EMAIL PROTECTED]>, Valentin Nechayev writes: >(Cc'ed to phk@ as to main GEOM and DEVFS developer; see corresponding >questions below.) I'm on vacation right now, and sort of semi offline (you know, the undocumented ACPI S-1 "wife mandated offline state" :-) In addition to what you already have discovered, you _may_ have an issue with your bsd disklabels (too). I would probably do it like this (assuming you have remote console): Put 4.8 kernel and a 4.8 mfsroot image (with plenty of fixit like stuff, size is not a big issue if you boot this from disk) on the 5.x system, boot that kernel using the mfsroot as root filesystem and try to do the surgery from there. The advantage to this approach is that you can explore the issues returning to your 5.x installation and adjust your approach. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: uma_zalloc() not checking flags
In message <[EMAIL PROTECTED]>, Harti Brandt write s: > >Given that uma_zalloc() has the same flags as malloc(9) shouldn't it check >these flags like malloc(9) does? I would think we could copy the #ifdef >INVARIANTS section at the beginning of malloc(9) to uma_zalloc_arg(). > >I just found a large number of calls in the ATM code that have just >M_ZERO or even 0 flags. > >Anything against this check? Good point, please implement! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: getting from bio to buf in dastrategy()
In message <[EMAIL PROTECTED]>, Eno Thereska writes: >Hi all, > >I am hacking into the FreeBSD 5.0 code. >I jumped from using 4.4 to 5.0 and a couple of things >have changed. Here is my question: > >in /sys/cam/scsi/scsi_da.c the dastrategy() >function takes as an argument "struct bio* bp" >Now I need to get to the "struct *buf" that bp >belongs to. You can't do that, there may not be any struct buf. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
small statistics tool in the tree ?
I written up a small statistics tool which is targeted at showing if a benchmark proves anything or not. critter phk> cat before 29195 29232 29226 29203 29211 critter phk> cat after 29179 29203 29195 29194 29196 critter phk> ./ministat before after x before + after +--+ |++*+ * xx x| ||___A_M___|_|___M__A_|| +--+ N Min MaxMedian AvgStddev x 5 29195 29232 29211 29213.4 15.469324 + 5 29179 29203 29195 29193.4 8.7920419 Difference at 95.0% confidence -20 ± 18.3497 -0.0684617% ± 0.0628127% (Student's t, pooled s = 12.5817) In this case the benchmark shows a very small improvement has obtained with 95% probability Here is a more convincing result: x before + after +--+ | +| | +| |xx +| |xx x + +| ||_A__M__| |_MA_| | +--+ N Min MaxMedian AvgStddev x 5 0.132 0.134 0.1330.1328 0.00083666003 + 5 0.136 0.138 0.1360.1364 0.00089442719 Difference at 99.5% confidence 0.0036 ± 0.0024642 2.71084% ± 1.85558% (Student's t, pooled s = 0.000866025) The program is a <500 line .c program and I was wondering if it belongs in the tree so we have an easy to use tool to point people at when they run benchmarks. Source: http://phk.freebsd.dk/patch/ministat Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM Gate.
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writes : > >--Dx9iWuMxHO1cCoFc >Content-Type: text/plain; charset=iso-8859-2 >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >Hello hackers... > >I've done something what will be called GEOM Gate. >This software provide disk devices mounting through the network. COOL > http://garage.freebsd.pl/geom_gate.tbz I'll look over it when I have a second. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
In message <[EMAIL PROTECTED]>, John Birrell writes : >I'm not convinced that any hacking is required other than passing the >device_t parent to nexus_pcib_is_host_bridge (in STABLE) as Bernd says. >I traced the boot on my system and the MMCR is initialised early (when >the Timecounter "ELAN" output occurs). Immediately following that >initialisation, 'pcib' is added as a child of 'nexus'. I don't see why >'mmcr' couldn't be added as a child of 'nexus' too. At this point, >nexus isn't walking through it's children so there shouldn't be a problem. >Then the ELAN specific devices (like GPIO and flash) can attach to 'mmcr'. > >This seems straight forward. Maybe I'm missing something. 8-) That's my take too. And MMCR belongs on nexus not on legacy from an architectural point of view. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >I need to add I2C support for a Elan520 based soekris system. >The system has the required GPIO pins and there is the iicbb driver >to handle generic bitbang code - just needing a simple layer driver to >enable, disable and read pins. >But unlike normal isa/pci hardware probing the existence of the GPIO >line is a bit difficult. >The current elan-mmcr.c gets started from i386/pci/pci_bus.c at >host bridge probing, because that's seems to be the only place to >safely detect this special CPU. That's my doing, based on my reading of the datasheet from AMD. It would be better if we could detect the Elan in the normal CPU identification stuff, but I couldn't seem to find a reliable way. >>From the logicaly standpoint the extensions had to be attached to >nexus, but nowhere is the current code path there is a handle for >nexus or any other device_t. In fact what you may want to do is hang the entire MMCR off the nexus as a bus, and hang the various drivers off that bus. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: getting from bio to buf in dastrategy()
In message <[EMAIL PROTECTED]>, Eno Thereska writes: > >>in /sys/cam/scsi/scsi_da.c the dastrategy() > >>function takes as an argument "struct bio* bp" > >>Now I need to get to the "struct *buf" that bp > >>belongs to. > > >You can't do that, there may not be any struct buf. > >How can a bio exist on it's own, unrelated to any buf? >Would that be a special case or does that happen all the >time? A concrete example would help. struct buf represents a block in the cache/VM system. struct bio represents a disk I/O request. For historical reasons, a buf contains a bio, but that is by no means the only way to create a bio. Throughout geom bio's are created a destroyed which have no relation to any specific buf, for instance to read the key sectors in gbde. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Bernd Walter writes: >> >I need to add I2C support for a Elan520 based soekris system. >> >The system has the required GPIO pins and there is the iicbb driver >> >to handle generic bitbang code - just needing a simple layer driver to >> >enable, disable and read pins. >> >But unlike normal isa/pci hardware probing the existence of the GPIO >> >line is a bit difficult. >> >The current elan-mmcr.c gets started from i386/pci/pci_bus.c at >> >host bridge probing, because that's seems to be the only place to >> >safely detect this special CPU. >> >> That's my doing, based on my reading of the datasheet from AMD. >> >> It would be better if we could detect the Elan in the normal CPU >> identification stuff, but I couldn't seem to find a reliable way. > >I could reread the datasheet, but don't give it much hope if you >hadn't find anything usefull. > >> >>From the logicaly standpoint the extensions had to be attached to >> >nexus, but nowhere is the current code path there is a handle for >> >nexus or any other device_t. >> >> In fact what you may want to do is hang the entire MMCR off the nexus >> as a bus, and hang the various drivers off that bus. > >What needs to be in *_probe() to conditionalize on elan existence? Well, my idea was to hang the mmcr bus on nexus when we find out it is an elan. It may be that you are not allowed to attach a bus to the nexus when we find out it is an elan in the host/pci bridge probe, but then I guess you could just hang it off that instead. Pressumably some newbus magic will then probe that bus. If its not an elan, there is no mmcr bus and nothing will get probed. I'm not the worlds greatest newbus specialist, so check this concept with somebody who know what they are talking about before you do it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to get a device_t
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >On Wed, Aug 06, 2003 at 12:45:43PM +0200, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Bernd Walter writes: >> >On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote: >> >> In message <[EMAIL PROTECTED]>, Bernd Walter writes: >> >> >>From the logicaly standpoint the extensions had to be attached to >> >> >nexus, but nowhere is the current code path there is a handle for >> >> >nexus or any other device_t. >> >> >> >> In fact what you may want to do is hang the entire MMCR off the nexus >> >> as a bus, and hang the various drivers off that bus. >> > >> >What needs to be in *_probe() to conditionalize on elan existence? >> >> Well, my idea was to hang the mmcr bus on nexus when we find out it >> is an elan. > >Back to the original question: >How do I get the device_t from nexus? >Is there a get_nexus() function somewhere? That's were I don't know enough newbus :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/nfsclient bootp_subr.c nfs_diskless.cnfs_vfsops.c nfsdiskless.h
In message <[EMAIL PROTECTED]>, Peter Jeremy wri tes: >[Redirected to -hackers because this isn't directly relevant to the > actual code committed] > >On Fri, Aug 15, 2003 at 05:04:02AM -0700, Poul-Henning Kamp wrote: >> Suggested replacement command sequence on the client: >> >> dd if=/dev/zero of=/swapfile bs=1k count=1 oseek=10 >> swapon /swapfile > >This results in a sparse swapfile. You don't _have_ to make it a sparse file, you are free to preallocate the entire file if that is important to you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM Gate.
In message <[EMAIL PROTECTED]>, Pawel Jakub Dawidek writes : > >--X8oaj2qX3NXXvcHN >Content-Type: text/plain; charset=iso-8859-2 >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Fri, Aug 15, 2003 at 11:53:11AM -0400, Robert Watson wrote: >+> That said, I think the geom gate stuff looks very cool :-). You might be >+> able to run some interesting performance numbers comparing NFS and UFS >+> over a remote block device. > >Ok. After last geom gate optimizations I'm ready to show some tests. > >NFS read: 2539890 bytes/sec >NFS write: 2668428 bytes/sec > >GG read file: 5791796 bytes/sec (file was exported) >GG write file: 4071411 bytes/sec (file was exported) > >GG read device:4635277 bytes/sec (disk device was exported) >GG write device: I wasn't able to test Please use /usr/src/tools/tools/ministat to do a proper statistical benchmark. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM Gate.
In message <[EMAIL PROTECTED]>, Dan Nelson writes: >I think this just demonstrates that you should not run benchmarks with >all your debugging flags enabled :) Most people will not be running >production systems with WITNESS, and parts of the kernel that bog down >under the heavy load of WITNESS may work just fine on a regular kernal >config. To quote from src/UPDATING: ] NOTE TO PEOPLE WHO THINK THAT 5.0-CURRENT IS SLOW: ] FreeBSD 5.0-CURRENT has many debugging features turned on, in ] both the kernel and userland. These features attempt to detect ] incorrect use of system primitives, and encourage loud failure ] through extra sanity checking and fail stop semantics. They ] also substantially impact system performance. If you want to ] do performance measurement, benchmarking, and optimization, ] you'll want to turn them off. This includes various WITNESS- ] related kernel options, INVARIANTS, malloc debugging flags ] in userland, and various verbose features in the kernel. Many ] developers choose to disable these features on build machines ] to maximize performance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
