Re: SMP machine, run a program on a single CPU?
On Sat, Jul 9, 2011 at 9:11 PM, Maurice Janssen wrote: > On Sat, Jul 09, 2011 at 07:52:58AM -0400, Nick Holland wrote: >>On 07/09/11 03:57, Maurice Janssen wrote: >>> Hi, >>> >>> Is it possible to somehow force a program to run on a single CPU in an >>> SMP system? >>> The reason I ask that on some SMP-capable architectures, I'm having some >>> problems with ntpd. On hppa and sgi, the clock won't sync because ntpd >>> sees replies with negative delay: >>> >>> Jul 9 08:58:19 hppa ntpd[21406]: reply from 192.168.4.12: negative >>> delay -0.854615s, next query 3120s >>> >>> (reported as PR6592) >>> >>> If I run the bsd.sp kernel, the negative delays are gone and ntpd syncs >>> without any problem. I was wondering if the problem would occur if I >>> could limit ntpd to a single CPU. Diving into the code is way beyond my >>> skills, so I was hoping that there is a utility like nice to achieve this. >>> >>> Thanks, >>> Maurice >> >>Things aren't that simple. >>Time is an illusion. Lunch time, doubly so >>(obligatory Hitchhiker's quote) >>Time on computers is complicated, doubly so on a multiprocessor system. >> >>ntpd isn't your problem, it's time on the SMP system. Fiddling with >>processor affinity (trying to attach particular tasks to particular >>CPUs) wouldn't help if you could (and you can't). > > OK, thanks for making that clear. > >>Is time really drifting (consistently increasing error in one direction) >>on these systems? Or is it just "jittering" around proper time? > > The hppa was about 10 seconds behind proper time since boot (the machine > is not powered on anymore). The delay was quite stable. > > The sgi was close to proper time (within one second) and finally synced > the clocked after about 4 hours. But the 'negative delay' lines keep > appearing in /var/log/daemon: > > Jul 9 07:10:40 sgi ntpd[25403]: ntp engine ready > Jul 9 07:11:47 sgi ntpd[7566]: set local clock to Sat Jul 9 07:11:47 CEST 2011 (offset 66.702436s) > Jul 9 07:11:53 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.422241s, next query 3298s This sounds like the timekeeping code isn't synchronizing between cpus. I don't know how those architectures are getting their time, but it sounds like different cpus have slightly out of sync counters or even frequencies. This is the reason why we don't use instruction counters to measure time on i386 and amd64. //art
Re: I don't get where the load comes from
On Tue, May 31, 2011 at 9:24 AM, Francois Pussault wrote: > Hi all, > > load is not realy a cpu usage %. > In facts it is sum of many % (cpu real load, memory, buffers, etc...) No, it isn't. > we should consider load as a "host" ressources %... No, we shouldn't. The load average is a decaying average of the number of processes in the runnable state or currently running on a cpu or in the process of being forked or that have spent less than a second in a sleep state with sleep priority lower than PZERO, which includes waiting for memory resources, disk I/O, filesystem locks and a bunch of other things. You could say it's a very vague estimate of how much work the cpu might need to be doing soon, maybe. Or it could be completely wrong because of sampling bias. It's not very important so it's not really critical for the system to do a good job guessing this number, so the system doesn't really try too hard. This number may tell you something useful, or it might be totally misleading. Or both. //art //art
Re: Bad frame pointer crash again
There is no such thing as a "bad frame pointer crash". That's a
diagnostic message from ddb that it can't find anything further up the
stack trace, which is correct, since the function sched_sync is on top
of the stack.
Now, what the kernel tells you is that your kernel didn't panic, so
I'm not entirely sure how you end up in ddb, since there is no panic
or fault in the traceback. What does the traceback on other cpus show?
"machine ddbcpu 0" will switch to cpu0, make a trace on each of them.
//art
On Mon, May 23, 2011 at 5:42 PM, Jeff Ross wrote:
> Hi all,
>
> I have a server that I'm trying to get on-line that continues to drop into
> ddb with a bad frame pointer crash. Right now it is only running an hourly
> rsync from the server it is to replace on an hourly basis. The server will
> run for no more than a week without this happening but sometimes it will
> crash after only a day.
>
> I filed a PR 6593 on Apr 26 on this. Right now it is running i386 -current
> from Apr 27, upgraded after I filed the PR.
>
> The message I get at the ddb prompt is virtually identical to the one
below.
>
> If anyone has any ideas on how I can further debug this, I'd like to know.
> I was hoping to use the upcoming 3 day weekend to make the final switch to
> this new server but I can't see how that will happen if I can't keep it
> running.
>
> Trace, ps and dmesg below.
>
> Thanks,
>
> Jeff Ross
>
> jross@mail:/home/jross $ sudo cu -l /dev/cua00
> Password:
> Connected
>
> ddb{2}> show panic
> the kernel did not panic
> ddb{2}> trace
> handle_workitem_freeblocks(d9d2ee78,e2ac1860,e0352f2c,d03e1c95) at
> handle_worki
> tem_freeblocks+0x2b
> process_worklist_item(0,0,e0352f5c,d03e1eff,e0352f44) at
> process_worklist_item+
> 0x171
> softdep_process_worklist(0,28,d08c4bbb,0,d03d2ec3) at
> softdep_process_worklist+
> 0x13f
> sched_sync(daea43b8) at sched_sync+0xe5
> Bad frame pointer: 0xd0ba9e88
Re: altq cripples other connections as well
On Wed, May 11, 2011 at 3:47 PM, Tom Murphy wrote: > I had set up ALTQ on a 4.9 firewall box as a box in our network needed > its sending throttled, but I noticed that while the firewall was > throttling this machine in question, ALL connections going through the > machine were adversely affected and slow. Interactive SSH sessions had > sometimes 1-2 seconds up to 10 seconds before keystrokes showed up. > I also noticed I had to jack qlimit up to 8000 to stop getting lots of > packets being dropped. What did you think would happen when you're queuing up over a second of packets? Dropped packets are good for you, they are the mechanism that TCP uses to know when it should step back a bit. //art
Re: Secret key in the packet filter.
Has anyone really been far even as decided to use even go want to do look more like? On Wed, Jul 14, 2010 at 5:54 PM, Kenneth Gober wrote: > I assume there's a language translation issue here. if there's a real > non-idiotic question you're asking, we can't tell what it is due to the way > it was translated to English. what *did* get translated is pretty funny, > though. > > -ken > > On Wed, Jul 14, 2010 at 11:35 AM, jackwssp q wrote: > >> So, you all guys just joke... >> >> >> >> On 14 July 2010 12:26, Jan Stary wrote: >> >> > On Jul 13 18:18:12, jackwssp q wrote: >> > > Hello brothers and sisters, >> > > >> > > Who knows anything about the secret keys in the packet filter(pf), such >> > as >> > > way only for developers. >> > > >> > > Is it real in the open source, and how can I realize it in my own >> > firewall >> > > with open source? >> > >> > --- pf.c.orig Wed Jul 14 10:23:45 2010 >> > +++ pf.cWed Jul 14 10:25:04 2010 >> > @@ -101,0 +102,6 @@ >> > +/* >> > + * The secret key for remapping the keyboard >> > + */ >> > + >> > +#define SECRET "jackwssp" >> > + >> > >> > >> >> >> -- >> with best respect
Re: Source Overview
On Tue, Apr 20, 2010 at 9:41 PM, Chris Bennett wrote: > Looking at this and Peters message, I think there may be an answer much > simpler than a TODO list, which I think will never work out. If developers > wanted a TODO list, we would already have one. "We" do. Multiple. Mine's not very up to date, but there are some interesting starting points there. I know there are others. //art
Re: Source Overview
On Tue, Apr 20, 2010 at 2:02 AM, Christiano F. Haesbaert wrote: > I also know he (as every developer) is busy with more important > things, so "publishing" these small tasks would also give the > developers more time to focus on the big/important issues. There are a bunch of assumptions here that are wrong. Small tasks are the most fun to do because they satisfy the instant gratification needs all of us have. I won't give you my list of the "fun and easy stuff", I want to keep it to myself. The lists that are published will contain "dull, heavy and not very important" tasks. The kind that gets you burned out the quickest. Also, todo lists have been published in the past leading to either no reaction whatsoever or a bunch of people offering help and vampiring the energy from whoever published the list without leading to any code committed. It's easy to become slightly bitter about the whole thing after spending hundreds of hours helping people who then don't follow through when they realize that it actually requires work. //art
Re: OpenBSD culture?
On Thu, Apr 15, 2010 at 10:52 PM, Donald Allen wrote: > Thanks for the compliment, but I'm a *lot* older than nine. Yet you still believe that it's ok for guests to tell the hosts how to behave in their home. Amazing. What culture are you from? //art
Re: OpenBSD culture?
On Thu, Apr 15, 2010 at 1:39 PM, VICTOR TARABOLA CORTIANO wrote: > Marco, instead of complaining about GNU, GPL, FSF, Linux, etc. Why > don't you write some code instead? I know it's a strange concept. Hehehe. A funny hippie. //art
Re: crontab "last day of the month"
On Tue, Apr 6, 2010 at 12:29 PM, Alexander Hall wrote: > frantisek holop wrote: >> hmm, on Tue, Apr 06, 2010 at 11:26:28AM +0200, Jan Stary said that >>> On Apr 06 11:15:26, frantisek holop wrote: hi there, what happens if i specify a cronjob like this? 23 59 31 * * $HOME/bin/whatever >>> Cron will just do what it's told: run whatever at "31.*. 23:59" >> >> so i could basically do 12 lines with the correct >> last day of the month rules :] >> > > No, you're forgetting about leap years... :-) Don't forget leap seconds. //art
Re: crontab "last day of the month"
On Tue, Apr 6, 2010 at 12:09 PM, frantisek holop wrote: >> > i am looking for an alternative @monthly, not >> > >> > 0 0 1 * * >> > >> > but the last minutes of the last day of the month. >> >> Why? > > because for me the month ends at 23:59:59 on the last day > of month n, and not at 00:00:00 on the first day of month n+1... cron can't guarantee that it will run the job at exactly that second. It will run the job some time after the time specified, but not before. So if you're looking for second precision for your jobs, cron is not the right tool (there aren't any tools that can guarantee this unless you're running a real time operating system). //art
Re: softdeps enabled = poor "concurrent" access?
On Wed, Feb 24, 2010 at 1:20 AM, Noah McNallie wrote: > Well, i've found on openbsd without sofdeps enabled it will do this just > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take > quite a while to complete. Simplified explaination. Without softdeps, your tar does one disk write and waits for it to finish, then ls does one disk read and waits for it to finish. Continue until done. With softdeps, tar will fill the whole buffer cache with writes, not letting any other process run, then ls will try to read one block, wait for at least one write to finish before it can get a buffer, but in the mean time, tar will be awoken by those writes finishing and schedule even more writes before ls gets the chance to run. It's slightly stupid and there have been experiments with diffs to make this better, but there's no functionality in the tree to deal with this currently. > exponentially. Did I miss some evolution of the english language? I recently keep hearing abuse of this word everywhere. A multiplication by a constant was not an exponential function last time I did high school math. //art
Re: uvm_fault dump to DDB
Brett Lymn writes: > On Tue, Jan 19, 2010 at 12:57:31PM +0100, Artur Grabowski wrote: >> Is this really the dmesg from the machine? Not manually copied or something? >> >> Because every strange error I see in it looks like one bit was flipped. >> >> E.g. "com`at)bili4y": >> "`" 0x60, should be "p" 0x70 >> ")" 0x29, should be "i" 0x69 >> "4" 0x34, should be "t" 0x74 >> > > more likely a screwed up parity setting on a serial line. Then the dmesg after reboot would be messed up too, it wasn't. //art
Re: uvm_fault dump to DDB
Is this really the dmesg from the machine? Not manually copied or something? Because every strange error I see in it looks like one bit was flipped. E.g. "com`at)bili4y": "`" 0x60, should be "p" 0x70 ")" 0x29, should be "i" 0x69 "4" 0x34, should be "t" 0x74 Etc. Although. This is pre-reboot dmesg. I've never seen a machine that would partially lose memory over a reboot, but I guess that could happen and still leave the dmesg checksum intact. The data modified on freelist messages seem to indicate that something is corrupting memory. And the corruptions seem larger, but still very strange. I'd definitely check memory on the machine. Something is likely not right. If that doesn't show anything, I'd try a later release, since 4.4 is old. //art Joseph Bustos writes: > # dmesg > ESB LPC" rev 0x02: 24-bit timer at 3579545Hz > pciide0 At pci0 dev #1 function 2 "Intel 6300ESB SATA" rev 0x02: DMA( channel > 0 aonfigured to coipathbility, channal 1 cknfigured to com`at)bili4y > atapiqcsi0 at pciide0 channel 0 drive0 > scsib5s0 at atapiscsa : 2tarfets, initiator 7 > cd0 at scsibes0 targ 0 lun 0: 8QSI, CD-ROM SCR(242, CHC8> ATAPI 5/cdrom > remova"le > cd0(pciide0:0:0): using PIO ,ode 4, Ultra-DMA mode 2 > wd0 at pciide0 channel 1 drive 1: > wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors > wd0(pciide0:1:1): using PIO mode 4, ULtra-DMA mode 5 > ichiic0 at pci0 dev 31funcTion 3 "Ijtel 6300ESB SMBus" rev 0x02: irq 9\^Biic0 > at ichiic0\^BadmCts0 atiic0 addr 0x2e > spdmem0 at iic0 addr 0x52: 1GB DDR SDRAM non-parity PC3200CL3.0 > spdmem1 at iic0 addr 0x53: 1GB DDR SDRAM non-parity PC3200CL3.0 > usb1 at uhci0: USB rerisiKn 1*0 > uhub1 at usb1 "Ijtel UHCI rood hub" rev 1.00/1.00 addr 1 > qsb2 at uhci1: ESB revision 1.0 > Uhub2 at esb2 "Intel UHCI root hQb" rev 1.0 /1.00 addr 1 > isa0 atich`cib0 > isadma0 at isa0 > coe0 aT isa0 port 0x3f8/8 irq 4: ns165\^U0a, 16 byte fifo > pckbc0 at isa0popT 0x60/5 > pck`d0 at pckbc0 (k"d slot) > pck"c0: using irq 1 forkbd slot > wskbd0at `ckbd0: consnle keyboard, using wsdisplay0 > pbppi0 at isa0 port 0x61 > midi0 at pcppi0: > spkr0 at pbppi0 > npx0 at i...@0 port 0xf0'16: reported by CPUID; using except)on 1\^V > fdc0 a4 iCa0 port 0x3f0/6 irq 6 drq 2 > bioEask ffc5 netmasJ ffed ttxmask fbff > mtrr: PentiuE Pro MTRR suppoBt > uhideV0 at uhtb1 port 1 configuration 1 interbace 0 "Locipech USB Optical > MouSe" rev 2.00/43.01 addr 2 > uhidev\^P: iclass 3/1 > ums0 at uhidev0: 3buttons, Z dir > wsmouse0 at ums0 mux 0 > uhidev1 a4 u ub1 port 2 cgnfifuration 1 interface 0 "LITEON Technology USB > MulTimedia Keyboard" rev 1.10/\^Q.01 addr 3 > uhid\^Ev1: iclass 3/1 > ukbd0 at uhidev1: 8 modif)er key3, 6 key codes > wskbd1 at ukbd0 mqx 1 > wskbd1: con ecting to w#dis0laY0 > softraid0 !t root > root on Wd0a swap on wd0b d5m0 on wd0b > WARNIJG: /was not properly ulmounted > wskbd1: disaon.ecting from wsdhsplaY0 > wskbd0 detached > ukBd0 de4ached > uhidev1 detached > wsmouSe0 ddtached > ums0 detached > uhidev0 detached > Data modified on freelist: word 1 of object 0xd29b99$0 size 0x4\^P pre\^Fious > tYpe UVM aDap (0xef4beecc != 0xefffeecc) > Data modified on Breelist: word 1of objebt 0xd29b94c size 0x38 previous type > UV\^A am`p (0xef4bee\^Cc != 0xefffee#c( > Data mOdified nn f2eelIst: word 1 Of object 0xd29b99c0 size 0x\^S8 previmus > type pcb (0xef4b%ecc != 0xefffeecc) > Data modified on freelist: word 0 of object 0xd2)b96c0 size 0x38 previous type > UFM amap (0xef4beEcc != 0xefffeac#) > Data modified on freelist: wo d 1 of o`ject 08d29b9500 size 0838 previous ty0a > UVM amap (0xef4beecc != 0xefff%ecc) > Data modifhed on freelist:woRd 1 of objec0 0xd29b90c0 sizd 0x28 previous 4ype > UVM amap (0pef4beecc != 0xefffeecc) > Data modified on fredli\^St: gmrd 1 o& object 0xd29b95$0 Rize 0x40 previo\^Es > type UVM amap (0xef4bdecc != 0xefffeecc) > Data modifie$ on fre%list: word 1 ofobject 0xd29b9040 size x40 pre6ious type > pcb \^H xef4bee#c != 0xdfffeecc) > Data m+dified on freedAst: word 1 of o"ject 0xd29b11c0 size 0x40 previEus type > temp (0hef4beecc != 0xedffeecc) > Data mo$ified on freelict: word 1 of obHecT 0xd29b9080 bize 0x40 previo1s Type > \^UVM amap (0xef4b%ecc != 0xefffeecc) > Data modified on freAlist: word 1 of object 0xd29b9a\^P0 size 0x40 prefious > ty0e UVM amap (0xef4beecc != 0xefffeecc) > D`ta modified on freelist: word 1 of object 0xd29b90c0 size 0x40 previous type > UVH amap (0xef$beebc != 0xefffeecc) > Data mldified on freel)st: uord 1 of object 0xd29b92c0 size 0x00 pRevious type > pcb 0xef4beecc != 0xeFffeecc) > \^Data modified on freelist: word 1 of object 0xd21b9040 s)ze 0x40 pRevious > ty0e UVM amap (0xef4beecc != 0xefffeecc) > Data modified on freelist: woRd 1 of object 0xd29b9a00 si:e 0x40 prevhnus 4ype > UVM am!p (0xef$beecc !- 0xefffeecc) > Data modified on freelist: word 1 of object 0xd29b96c0 size 0x38 ppevious type > UVM amap (0xef4beecc != 0xebffeecc) > Dat` modified o. freelist: word ! of obJect 0xd29b99c0 size 0x40 previgts type > pcb (0xef4beecc != 0
Re: ComixWall terminated
Soner Tari writes: > Due to unexpected reaction from the leader of the OpenBSD project > (please read below), I am terminating the ComixWall project. Do you cut yourself when somebody yells at you just to show them? >>> I will feel stupid continuing with this project while I am not even >>> allowed to post its release announcements to the OpenBSD mailing lists. The point of extortion is to hurt someone else. Suicide bombing doesn't work when you do it in the middle of a desert. //art
Re: help please, my real memory is disappearing
No. It will not solve any problem (ignoring that there was no problem in the first place). //art Pete Vickers writes: > alternatively you could run/spawn ftpd from inetd, which will > presumably mean that all the resources will be 'returned' as soon as > the connection closes. However significant performance hit on a busy > ftp server. > > /Pete > > > > On 17. nov.. 2009, at 10.25, Artur Grabowski wrote: > >> "MK" writes: >> >>> 1. Is it normal that memory is not freed after I kill ftpd daemon? >> >> yes. because the ftp daemon didn't allocate it. >> >>> 2. Is it normal ftpd can take about 800MB of real memory while >>> serving >>> GET requests? (only 1 client is able to consume that portion of >>> memory) >> >> If you serve 800MB of file data through ftpd then yes. >> >>> 3. Is it normal that this memory seems to be lost from the system? >> >> yes. The keyword here is "seems". >> >> The memory is used for caching the file contents in case you decide to >> read those files again. It's reused for more useful things when it's >> needed. >> >> //art >> > > Pete Vickers > > p...@systemnet.no | +47 48 17 91 00 > > SystemNet AS
Re: help please, my real memory is disappearing
"MK" writes: > 1. Is it normal that memory is not freed after I kill ftpd daemon? yes. because the ftp daemon didn't allocate it. > 2. Is it normal ftpd can take about 800MB of real memory while serving > GET requests? (only 1 client is able to consume that portion of > memory) If you serve 800MB of file data through ftpd then yes. > 3. Is it normal that this memory seems to be lost from the system? yes. The keyword here is "seems". The memory is used for caching the file contents in case you decide to read those files again. It's reused for more useful things when it's needed. //art
Re: http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/
Claire beuserie writes: > That came out a bit weird: are you saying you knew about the bug for 2 years > but did not fix it? Yes. Because the solution sucks. And all others we tried were just not workable. Just like we knew that executable stacks can be used for exploits and didn't fix that for many years. //art
Re: PF and Pool
"Insan Praja SW" writes: > > These must be a problem right? I've tried replacing RAM since I think > these are memory problem. But it keep coming. Then I updated to > current, it's not going anywhere. I think somewhere in the h/w > there's something really wrong. nothing is wrong with your hardware. You're just running out of memory. You have 100k pf states, which means you either have too much traffic for the setup you have or something very badly misconfigured. > pfstatepl 216 26986682 14705417 10 5556 0 > 5556 5556 0 55560 And I don't know what's going on here, but this looks insane. You must be doing something weird with your pf setup. > pfruleitempl 1230514059 330201471356643661 0 > 43661 43661 0 80 //art
Re: Defending OpenBSD Performance
- Tethys writes: > And that attitude is why OpenBSD will never be more than a hobby OS. Sigh. Yes? So? Not everyone has to have an ambition to take over the world. The developers do it as a hobby, for fun. Which ties into the OP. The answer to his question is "why?". //art
Re: About the OpenBSD repository
Mic J writes: >>> But to >>> imply that CVS is better than (or equal to) Mercurial or Git is a bit >>> ridiculous :) Mercurial and Git are crap. >> Because none of the above mentioned will allow for 70+ developers to >> update ~1.2GB/~140,000 files of source code, allow anonymous checkouts, >> has an available web based interface and interfaces with ssh. Instead > though >> non atomic commits, expensive branches and almost 20 years of work arounds >> are utilized. > > SVN can definitely do this, lost of large project are using it. >From two hours ago at work: $ svn cleanup svn: Working copy 'lib/common' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) $ svn cleanup lib/common svn: Working copy 'lib/common' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) $ svn help cleanup cleanup: Recursively clean up the working copy, removing locks, resuming unfinished operations, etc. usage: cleanup [PATH...] Valid options: --diff3-cmd ARG : use ARG as merge command Global options: --username ARG : specify a username ARG --password ARG : specify a password ARG --no-auth-cache : do not cache authentication tokens --non-interactive: do no interactive prompting --config-dir ARG : read user configuration files from directory ARG $ ok. And of course the "atomic" commits are bullshit because even though the commit failed and left a corrupted local checkout that I had to manually nuke and then copy the right files over, it still did commit some parts of my work. At least it didn't corrupt the database like it did a year ago where we lost two days of work because the only solution was to restore from backup. Now, only the tree was broken until I could figure out wtf it was doing. At least we know and understand the bugs and limitations of cvs. You don't like it - don't use it, but god sake, stop telling people what your favourite color is and why it should be their favourite color too. //art
Re: Is there a plan to make a OpenBSD compiler tool chain ?
"Shaowei Wang (wsw)" writes: > Is there any informations ? When someone wants to do it and does it, then it will be done. //art
Re: tmux vs wake
Pawlowski Marcin Piotr writes: > Hi all, > I'm a little bit curious about why there is place in bin for tmux(1) > and there is no place for wake(8). In my opinion it's a little bit > unfair. Could someone explain it? Sure, I'll try to explain. Ready? Brace yourself for the blinding flash of clarity that will shine on this highly mystical perceived inconsistency in the fairness of the decisions made by the developers. Here it comes: Because we wanted to. //art
Re: OpenBSD as a storage SAN
Lars Nooden writes: > OpenAFS is part of the base distro. Where? //art
Re: Bug in arch/i386/pci/pci_machdep.c
"Brock.Zheng" writes: > But I think the protection is not strong enough! You should > disable IRQ totally! Interrupts are blocked. //art
Re: Even and Odd numbered OpenBSD versions
Mark Romer writes: > Hello, just a simple question. We have here at work a old hand at openbsd > and he says he only uses openbsd versions that are even numbered. (3.8, 4.0, > 4.2, 4.4 etc...) I am not sure why, did not have a chance to ask him. > I believe that you should use the latest version available, but what does > everything else think? He's odd. //art
Re: [dera...@cvs.openbsd.org: Re: I would like to send this to misc@ and security-announce@, from me
rembrandt writes: > :words: Here's a nickel, kid. Buy yourself a better tinfoil hat. //art
Re: i386 snapshot kernel crash
Michael writes: > my system crashes [...] > kqemu: kqemu version 0x00010300 loaded, max locked mem=519228kB No shit? //art
Re: Programming Question: using kqueue() and kevent()
Taylor Venable writes: > The plain-text version is here: > http://real.metasyntax.net:2357/tmp/kevent.c changelist[i].ident = i; Pretty sure this line is your problem. //art
Re: European orders
Lazarus Wasbeim writes: > Surely I know something You perhaps don't. Says the guy whose only existence on the net is in this thread. Go away, astroturfer. It's very interesting when one side of the conflict is only supported by throwaway gmail accounts, don't you think? //art
Re: European orders
Lazarus Wasbeim writes: > L'haim. > > It's quite amazing how low these who calls themselves developers can go at > pouring dirt all over somebody they were shaking hands with just moments > ago. [...] > ... and God bless my friends. Not everyone believes in turning the other cheek. //art
Re: European orders
Daniel Seuffert writes: > Because Mr. de Raadt accuses Mr. Vandeputte in public for having done > some bad things without any evidence yet. No, he doesn't. > Accusing him like that in public is something completely > different. Where? > I have asked two > questions: > > 1. Where is the evidence? Of what? > 2. Why doesn't anybody steps up from his former fellows and > defends Mr. Vandeputte after all he has done for them and > OpenBSD itself? Yes, ask yourself that question. //art
Re: European orders
Daniel Seuffert writes: > I am Daniel Seuffert asking two questions. And I am Dr. Mbeke Bulabula with a strictly confidential urgent none of your business proposal. //art
Re: European orders
Toni Mueller writes: > 1. Theo not wanting to do business with Wim anymore. It's his choice and none of your business. > 2. The reasons(s) given why Theo does not want to do business with > Wim anymore. It's his reasons and none of your business. > 3. Theo's handling of the case. It's his choice and none of your business. > 4. Wim's handling of the case. It's his choice and none of your business. > 5. People voicing opinions about the case. Do I need to say it? Their opinions don't matter because it's none of their business. > 6. "Fairness" It, too, is none of your business. You're not a significant stakeholder here. > but if he gives a reason in the first place, the reason has to > be sound and verifiable, like with any other statement, too. No, it's none of your business. Theo is not accountable to you. The only people he might be remotely accountable to are the developers and the explainations we've been given both by Theo and Wim satisfied me and considering the lack of any outrage from other developers, I conclude that they either are satisfied too, or don't care enough. The intial announcement said as much as it needed to say. Then some people got butthurt and started going emo on the lists. > This is currently not the case. None of your business. > If I have missed something important, please point it out to me. The part where this is none of your business. > I'd like to note that I don't want to "take sides", but I am very > interested in getting some sanity back into this discussion. I don't take sides either, I just declare that it's none of your business and the same thing applies to all the other people who have been spamming about this issue, it's none of their business. This is not a spectator game and cheerleaders are neither necessary nor desirable. The result of any discussion about this will be the same - Wim will not sell OpenBSD stuff. Regardless of who might be right or wrong here. If you can't accept the fact, there are legal possibilites to settle this, if it's your business, which it isn't. If you want an angle where you might have an interest in this, the question I suggest asking is: "I bought X CDs and Y t-shirts for Z EUR. Where did that Z go?" and then it will be someones choice to either explain or tell you to go to hell. But that's as far as you might have any legitimate questions here that are more than gathering gossip and inciting spam. //art
Re: European orders
Daniel Seuffert writes: > WHERE IS THE EVIDENCE Mr. Grabowski? Evidence of what? Of you being butthurt by some perceived injustice? It's right there in your mail. > You can stop speculating who I am btw, I'm Daniel Seuffert. So, basically you're saying that you're a nobody here. Your point is? //art > >> Where do they come from? Suddenly there's this astroturfing campaign >> about... what? forcing Theo to do business with someone he has no >> intention of doing business with anymore? >> >> If you're really so butthurt, sue for defamation. Those fanboy mails >> from total nobodies are just retarded. >> >> //art >> >> Daniel Seuffert writes: >> >>> Theo de Raadt wrote: >>> >>> Mr. de Raadt, >>> >>> you are the guy that has accused Mr. Vandeputte in public. You are the >>> guy that failed to put >>> any evicence on the public table. Stop whining, show your evidence >>> like Mr. Vandeputte has >>> and is apparently preparing to show up in the very near future. >>> >>> I have respect for your contributions to Open Source, nothing more or less. >>> >>> Stop speculating if I have ever bought a t-shirt, a poster, a CD-set >>> or anything else from >>> Mr. Vandeputte or anybody else. That's none of your business. >>> >>> I don't care what you do for a living. If it's not enough get a job >>> and work like anybody else. >>> >>> Daniel Seuffert
Re: European orders
Where do they come from? Suddenly there's this astroturfing campaign about... what? forcing Theo to do business with someone he has no intention of doing business with anymore? If you're really so butthurt, sue for defamation. Those fanboy mails from total nobodies are just retarded. //art Daniel Seuffert writes: > Theo de Raadt wrote: > > Mr. de Raadt, > > you are the guy that has accused Mr. Vandeputte in public. You are the > guy that failed to put > any evicence on the public table. Stop whining, show your evidence > like Mr. Vandeputte has > and is apparently preparing to show up in the very near future. > > I have respect for your contributions to Open Source, nothing more or less. > > Stop speculating if I have ever bought a t-shirt, a poster, a CD-set > or anything else from > Mr. Vandeputte or anybody else. That's none of your business. > > I don't care what you do for a living. If it's not enough get a job > and work like anybody else. > > Daniel Seuffert
Re: European orders - Thank you Theo and your team, some of us appreciate you!
Michael Grigoni writes: > I also add my thanks to the discussion. I do have a fundamental > question to pose however. It seems that opensource culture for > large projects is driven by featurism and the need to make massive > changes incorporated into frequent releases. I come from a > background of very long-term stability requirements for APIs and > ABIs, performance figures on hardware over long life-cycles and > stringent documentation. > [... wall of text continues ...] Is it troll-week on m...@? //art
Re: European orders
Richard Ben Aleya writes: > But this conflict does not give you the rights in any manner to > insult the Europeans and their culture (you reference to the "beer"). > > We cannot accept a such behaviour. > > European people is offended when they read such things. Obvious troll. Trolls should be more subtle, please practice and come back. > We do not want to purchase CDs to pay the salary of an American guy who > does not respect European citizens. Now we know the man you are. Then don't. > We do not need "an OpenBSD project leader, working with all the > developers day after day to get changes into the source tree, and > making releases every 6 months" at the price of being offended. Then don't. //art
Re: European orders
Richard Ben Aleya writes: > Theo, > > There in Europe, there are a lot of OpenBSD users who don't like the > way you handle this conflict. > > We don't like how you can instantly punish Wim *a honest guy who made > a lot of work, efforts and spent a lot of time for the OpenBSD project* > without asking third party persons to inquiry before taking alone such > actions. (eg. shamming him and put it outside of the project). > > You told that this guy have stolen the money of OpenBSD donations to > become rich, this is totally false and insane to say that !!! Who are you and why do you claim to have insight into this issue? If you do have knowledge, why don't you disclose that instead of making random emotional rants. At this moment we know that one side of the conflict said that future European orders will be done through a different distributor because the old distributor proved to fall behind on payments, the other side hasn't said anything. Please, enlighten us about further details since you seem to have some insight into the issue. > Also, could you make a publically available account report which show > of how you manage the money you get from the donations of past years > (various expenses, hardware, events, money used to pay developers, > money used to pay YOURSELF, ...) ? Why would you believe that anyone here is accountable to you? //art
Re: "persistent bios infection" paper and openbsd
Toni Mueller writes: > I messed up a bit, sorry. I did not want to say that this would help > with the specific problem of someone attacking a flashable BIOS or by > other machines that can't be readily observed by the user. But what I > think such a program *will* help with, is the problem when you're > happily hacking away at your computer, and the doorbell rings > unexpectedly (or rather, the window shatters). Sort of an emercency > halt for the machine, specifically taking this nasty "RAM in liquid > nitrogen"-problem into account. If you're afraid of the "RAM in liquid nitrogen"-problem, I suggest explosives. //art
Re: might be slightly OT: `probability in PF'
jmc writes: > block in log quick on $ext_if from to any probability 90% > > is because it seems a little bofh-ly to me. and i guess it borders on > security-through obscurity, which of course it not really security at > all. but it seems a bit more sinister than just outright blocking, which > kinda makes me snicker a bit. make the experience painful enough that > they just go away. Just as a side-track, nothing to do with pf, I've done a similar thing with a service I'm running. Instead of blocking the bad guys outright, we have a blacklist of people who get randomized results from the application. Not very much, but enough to confuse the hell out of any automated scripts they were using to mess with us and instead of being able to automatically discover that they've been blacklisted, they have to manually verify everything. Blocking tells the bad guys that they should switch their proxy. Pretending to work while giving wrong results gives them real manual work to do. //art
Re: Where is "Secure by default" ?
Han Boetes writes: > Paul Irofti wrote: >> Hello Mr. Troll, thanks for flaming by. Have a good day! > > Never attribute to malice that which is adequately explained by > stupidity. That doesn't seem to be a good idea when you're working with security. Weren't we talking about "secure by default" here? Always attribute to malice even that which has been explained by stupidity. Stupidity is easy to fake. //art
Re: environmental prerequisites for kernel development
Lars Noodin writes: > What else is there on a wish-list for being able to do kernel-level work > remotely? Serial console, a machine connected to the same net, remote power cycling, a slave willing to plug and unplug cables to see what happens. //art
Re: Capturing kernel debugger output without serial console
Stuart Henderson writes: > On 2008-12-17, Lars Noodin wrote: >> What is a reasonable way to capture kernel debugger (ddb) output without >> a serial console? I'm able to consistently get ifconfig to crash on the >> latest snapshots. >> >> -Lars >> >> > > Are your userland and kernel in sync? Shouldn't panic anyway. //art
Re: ahci questions
frantisek holop <[EMAIL PROTECTED]> writes: > my last question for people running ahci, is it better than > ide in any perceivable way? The code is so much cleaner than the pciide mess. That's enough to make it better. I also believe it's faster, but I don't have any concrete numbers for it. Also, it's cool to have sd0 on a laptop. //art
Re: bash for root?
Dieter <[EMAIL PROTECTED]> writes: > more than 13 years [...] > If you write shell scripts that depend on being run by a specific > shell, you are supposed to use the #! thing. Yes, you are great. You've never made any mistake in more than 13 years. Us mere mortals prefer to avoid the risk of making mistakes. We bow our heads to your perfection. //art
Re: Missing security announcements
"Martin Schrvder" <[EMAIL PROTECTED]> writes: > Do not let serious problems sit unsolved. It's not a serious problem for us. //art
Re: Longest Uptime?
new_guy <[EMAIL PROTECTED]> writes: > I know. Longest uptime is silly, macho, pointless stuff... but I ran across > an old SunOS 2.6 box that had been up for 387 days. It had been hacked. The > only reason it was not an open mail relay is that /var was full. So, I > thought to myself, "I bet I could run an OpenBSD box for that amount of time > or longer without getting hacked and without doing much to it." Just > wondering what's the longest OpenBSD uptime some folks on misc have seen? 7:52AM up 6134 days, 16:36, 3 users, load averages: 0.52, 0.47, 0.43 http://www.blahonga.org/~art/diffs/epenis-enlargement.20060210 //art
Re: NTFS-3G Stable Read/Write Driver ready to merge on cvs obsd ?
"Heimdall Imbert" <[EMAIL PROTECTED]> writes: > Hahaha, I wanted to say the same thing but figured that this wouldn't be an > appropriate venue for a discussion of this nature. But since someone else > brought it up, I figure I might as well add my two cents. I currently run > Debian and Windows XP on my laptop and I use it as a learning tool (because > I am nowhere near a guru unlike many of the people here!). LEGO is a learning tool too. So are picture books and dolls. I don't think that word means what you think it means. //art
Re: NTFS-3G Stable Read/Write Driver ready to merge on cvs obsd ?
Neko <[EMAIL PROTECTED]> writes: > its shows that some poor trolls here dont own ultraportables with no > external drives, and use more than one os alternative. When your machine is a tool, not a toy, you run one operating system, whichever that might be. //art
Re: uvm_mapent_alloc
On a more serious note.
No, there is no diff to 4.3
No, there won't be.
No, the random changes this guy mailed do not solve the problem (at
least one thing here can make things worse and one is pulled out of
its context and will cause problems).
No, I'm not going to tell you which changes there are since there
were lots of things since 4.3 that lowered the pressure on static
map entries.
//art
Artur Grabowski <[EMAIL PROTECTED]> writes:
> Wow. I'm impressed. So if I mailed you a random diff that you don't
> understand you'd happily apply it without having a single clue about
> what the diff does and who sent it?
>
> Cool. Can I have your money and business without going through that
> hassle? Can't be bothered to make a malicious diff right now,
> haven't had coffee yet.
>
> //art
>
> Beavis <[EMAIL PROTECTED]> writes:
>
>> Vladimir,
>>
>> Sorry to bother you but I tried to apply the patch on uvm_map.c
>>
>> i copied the patch you gave me here and run
>>
>> patch -p0 < uvm_map.patch
>>
>> I get some rej. files. any pointers or help will be greatly
>> appreciated from anyone.
>>
>>
>> -b
>>
>> On Fri, Oct 10, 2008 at 3:01 PM, Vladimir Kirillov <[EMAIL PROTECTED]> wrote:
>>> On 14:44 Fri 10 Oct, Beavis wrote:
>>>> thanks for the reply vladimir.
>>>>
>>>> is it needed to upgrade my 4.3 stable to -current? isn't there a patch
>>>> available for this?
>>>
>>> The 4.3 uvm_map.c is 5 diffs far from this patch
>>> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_map.c?r1=1.104#rev1.104
>>> you can generate the diff yourself,
>>> cvs diff -r1.99 -r1.104 uvm_map.c
>>>
>>> or here:
>>>
>>> Index: uvm_map.c
>>> ===
>>> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
>>> retrieving revision 1.99
>>> retrieving revision 1.104
>>> diff -u -p -r1.99 -r1.104
>>> --- uvm_map.c 15 Sep 2007 10:10:37 - 1.99
>>> +++ uvm_map.c 23 Sep 2008 13:25:46 - 1.104
>>> @@ -1,4 +1,4 @@
>>> -/* $OpenBSD: uvm_map.c,v 1.99 2007/09/15 10:10:37 martin Exp $ */
>>> +/* $OpenBSD: uvm_map.c,v 1.104 2008/09/23 13:25:46 art Exp $ */
>>> /* $NetBSD: uvm_map.c,v 1.86 2000/11/27 08:40:03 chs Exp $ */
>>>
>>> /*
>>> @@ -98,6 +98,7 @@ static struct timeval uvm_kmapent_last_w
>>> static struct timeval uvm_kmapent_warn_rate = { 10, 0 };
>>>
>>> struct uvm_cnt uvm_map_call, map_backmerge, map_forwmerge;
>>> +struct uvm_cnt map_nousermerge;
>>> struct uvm_cnt uvm_mlk_call, uvm_mlk_hint;
>>> const char vmmapbsy[] = "vmmapbsy";
>>>
>>> @@ -538,6 +539,7 @@ uvm_map_init(void)
>>>UVMCNT_INIT(map_backmerge, UVMCNT_CNT, 0, "# uvm_map() back merges",
>>> 0);
>>>UVMCNT_INIT(map_forwmerge, UVMCNT_CNT, 0, "# uvm_map() missed
>>> forward",
>>>0);
>>> + UVMCNT_INIT(map_nousermerge, UVMCNT_CNT, 0, "# back merges
>>> skipped", 0);
>>>UVMCNT_INIT(uvm_mlk_call, UVMCNT_CNT, 0, "# map lookup calls", 0);
>>>UVMCNT_INIT(uvm_mlk_hint, UVMCNT_CNT, 0, "# map lookup hint hits",
>>> 0);
>>>
>>> @@ -726,6 +728,8 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
>>>
>>>if ((map->flags & VM_MAP_INTRSAFE) == 0)
>>>splassert(IPL_NONE);
>>> + else
>>> + splassert(IPL_VM);
>>>
>>>/*
>>> * step 0: sanity check of protection code
>>> @@ -832,6 +836,15 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
>>>goto step3;
>>>}
>>>
>>> + /*
>>> +* Only merge kernel mappings, but keep track
>>> +* of how much we skipped.
>>> +*/
>>> + if (map != kernel_map && map != kmem_map) {
>>> + UVMCNT_INCR(map_nousermerge);
>>> + goto step3;
>>> + }
>>> +
>>>if (prev_entry->aref.ar_amap) {
>>>error = amap_extend(prev_entry, size);
>>>if (error) {
>>> @@ -897,6 +910,8 @@ step3:
>>>if ((flags & UVM_FLAG_OVE
Re: uvm_mapent_alloc
Wow. I'm impressed. So if I mailed you a random diff that you don't
understand you'd happily apply it without having a single clue about
what the diff does and who sent it?
Cool. Can I have your money and business without going through that
hassle? Can't be bothered to make a malicious diff right now,
haven't had coffee yet.
//art
Beavis <[EMAIL PROTECTED]> writes:
> Vladimir,
>
> Sorry to bother you but I tried to apply the patch on uvm_map.c
>
> i copied the patch you gave me here and run
>
> patch -p0 < uvm_map.patch
>
> I get some rej. files. any pointers or help will be greatly
> appreciated from anyone.
>
>
> -b
>
> On Fri, Oct 10, 2008 at 3:01 PM, Vladimir Kirillov <[EMAIL PROTECTED]> wrote:
>> On 14:44 Fri 10 Oct, Beavis wrote:
>>> thanks for the reply vladimir.
>>>
>>> is it needed to upgrade my 4.3 stable to -current? isn't there a patch
>>> available for this?
>>
>> The 4.3 uvm_map.c is 5 diffs far from this patch
>> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_map.c?r1=1.104#rev1.104
>> you can generate the diff yourself,
>> cvs diff -r1.99 -r1.104 uvm_map.c
>>
>> or here:
>>
>> Index: uvm_map.c
>> ===
>> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
>> retrieving revision 1.99
>> retrieving revision 1.104
>> diff -u -p -r1.99 -r1.104
>> --- uvm_map.c 15 Sep 2007 10:10:37 - 1.99
>> +++ uvm_map.c 23 Sep 2008 13:25:46 - 1.104
>> @@ -1,4 +1,4 @@
>> -/* $OpenBSD: uvm_map.c,v 1.99 2007/09/15 10:10:37 martin Exp $ */
>> +/* $OpenBSD: uvm_map.c,v 1.104 2008/09/23 13:25:46 art Exp $ */
>> /* $NetBSD: uvm_map.c,v 1.86 2000/11/27 08:40:03 chs Exp $ */
>>
>> /*
>> @@ -98,6 +98,7 @@ static struct timeval uvm_kmapent_last_w
>> static struct timeval uvm_kmapent_warn_rate = { 10, 0 };
>>
>> struct uvm_cnt uvm_map_call, map_backmerge, map_forwmerge;
>> +struct uvm_cnt map_nousermerge;
>> struct uvm_cnt uvm_mlk_call, uvm_mlk_hint;
>> const char vmmapbsy[] = "vmmapbsy";
>>
>> @@ -538,6 +539,7 @@ uvm_map_init(void)
>>UVMCNT_INIT(map_backmerge, UVMCNT_CNT, 0, "# uvm_map() back merges",
>> 0);
>>UVMCNT_INIT(map_forwmerge, UVMCNT_CNT, 0, "# uvm_map() missed
>> forward",
>>0);
>> + UVMCNT_INIT(map_nousermerge, UVMCNT_CNT, 0, "# back merges skipped",
>> 0);
>>UVMCNT_INIT(uvm_mlk_call, UVMCNT_CNT, 0, "# map lookup calls", 0);
>>UVMCNT_INIT(uvm_mlk_hint, UVMCNT_CNT, 0, "# map lookup hint hits",
>> 0);
>>
>> @@ -726,6 +728,8 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
>>
>>if ((map->flags & VM_MAP_INTRSAFE) == 0)
>>splassert(IPL_NONE);
>> + else
>> + splassert(IPL_VM);
>>
>>/*
>> * step 0: sanity check of protection code
>> @@ -832,6 +836,15 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
>>goto step3;
>>}
>>
>> + /*
>> +* Only merge kernel mappings, but keep track
>> +* of how much we skipped.
>> +*/
>> + if (map != kernel_map && map != kmem_map) {
>> + UVMCNT_INCR(map_nousermerge);
>> + goto step3;
>> + }
>> +
>>if (prev_entry->aref.ar_amap) {
>>error = amap_extend(prev_entry, size);
>>if (error) {
>> @@ -897,6 +910,8 @@ step3:
>>if ((flags & UVM_FLAG_OVERLAY) == 0)
>>new_entry->etype |= UVM_ET_NEEDSCOPY;
>>}
>> + if (flags & UVM_FLAG_HOLE)
>> + new_entry->etype |= UVM_ET_HOLE;
>>
>>new_entry->protection = prot;
>>new_entry->max_protection = maxprot;
>> @@ -1098,6 +1113,45 @@ uvm_map_spacefits(struct vm_map *map, va
>> }
>>
>> /*
>> + * uvm_map_pie: return a random load address for a PIE executable
>> + * properly aligned.
>> + */
>> +
>> +#ifndef VM_PIE_MAX_ADDR
>> +#define VM_PIE_MAX_ADDR (VM_MAXUSER_ADDRESS / 4)
>> +#endif
>> +
>> +#ifndef VM_PIE_MIN_ADDR
>> +#define VM_PIE_MIN_ADDR VM_MIN_ADDRESS
>> +#endif
>> +
>> +#ifndef VM_PIE_MIN_ALIGN
>> +#define VM_PIE_MIN_ALIGN PAGE_SIZE
>> +#endif
>> +
>> +vaddr_t
>> +uvm_map_pie(vaddr_t align)
>> +{
>> + vaddr_t addr, space, min;
>> +
>> + align = MAX(align, VM_PIE_MIN_ALIGN);
>> +
>> + /* round up to next alignment */
>> + min = (VM_PIE_MIN_ADDR + align - 1) & ~(align - 1);
>> +
>> + if (align >= VM_PIE_MAX_ADDR || min >= VM_PIE_MAX_ADDR)
>> + return (align);
>> +
>> + space = (VM_PIE_MAX_ADDR - min) / align;
>> + space = MIN(space, (u_int32_t)-1);
>> +
>> + addr = (vaddr_t)arc4random_uniform((u_int32_t)space) * align;
>> + addr += min;
>> +
>> + return (addr);
>> +}
>> +
>> +/*
>> * uvm_map_hint: return the beginning of the best area suitable for
>> * creating a new mapping with "prot" protection.
>> */
>> @@ -1385,6 +1439,8 @@ uvm_unmap_remove
Re: uvm_mapent_alloc
http://www.strangecosmos.com/images/content/110397.jpg
//art
Vladimir Kirillov <[EMAIL PROTECTED]> writes:
> On 14:44 Fri 10 Oct, Beavis wrote:
>> thanks for the reply vladimir.
>>
>> is it needed to upgrade my 4.3 stable to -current? isn't there a patch
>> available for this?
>
> The 4.3 uvm_map.c is 5 diffs far from this patch
> http://www.openbsd.org/cgi-bin/cvsweb/src/sys/uvm/uvm_map.c?r1=1.104#rev1.104
> you can generate the diff yourself,
> cvs diff -r1.99 -r1.104 uvm_map.c
>
> or here:
>
> Index: uvm_map.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.99
> retrieving revision 1.104
> diff -u -p -r1.99 -r1.104
> --- uvm_map.c 15 Sep 2007 10:10:37 - 1.99
> +++ uvm_map.c 23 Sep 2008 13:25:46 - 1.104
> @@ -1,4 +1,4 @@
> -/* $OpenBSD: uvm_map.c,v 1.99 2007/09/15 10:10:37 martin Exp $ */
> +/* $OpenBSD: uvm_map.c,v 1.104 2008/09/23 13:25:46 art Exp $ */
> /* $NetBSD: uvm_map.c,v 1.86 2000/11/27 08:40:03 chs Exp $ */
>
> /*
> @@ -98,6 +98,7 @@ static struct timeval uvm_kmapent_last_w
> static struct timeval uvm_kmapent_warn_rate = { 10, 0 };
>
> struct uvm_cnt uvm_map_call, map_backmerge, map_forwmerge;
> +struct uvm_cnt map_nousermerge;
> struct uvm_cnt uvm_mlk_call, uvm_mlk_hint;
> const char vmmapbsy[] = "vmmapbsy";
>
> @@ -538,6 +539,7 @@ uvm_map_init(void)
> UVMCNT_INIT(map_backmerge, UVMCNT_CNT, 0, "# uvm_map() back merges",
> 0);
> UVMCNT_INIT(map_forwmerge, UVMCNT_CNT, 0, "# uvm_map() missed
> forward",
> 0);
> + UVMCNT_INIT(map_nousermerge, UVMCNT_CNT, 0, "# back merges skipped",
> 0);
> UVMCNT_INIT(uvm_mlk_call, UVMCNT_CNT, 0, "# map lookup calls", 0);
> UVMCNT_INIT(uvm_mlk_hint, UVMCNT_CNT, 0, "# map lookup hint hits",
> 0);
>
> @@ -726,6 +728,8 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
>
> if ((map->flags & VM_MAP_INTRSAFE) == 0)
> splassert(IPL_NONE);
> + else
> + splassert(IPL_VM);
>
> /*
> * step 0: sanity check of protection code
> @@ -832,6 +836,15 @@ uvm_map_p(struct vm_map *map, vaddr_t *s
> goto step3;
> }
>
> + /*
> +* Only merge kernel mappings, but keep track
> +* of how much we skipped.
> +*/
> + if (map != kernel_map && map != kmem_map) {
> + UVMCNT_INCR(map_nousermerge);
> + goto step3;
> + }
> +
> if (prev_entry->aref.ar_amap) {
> error = amap_extend(prev_entry, size);
> if (error) {
> @@ -897,6 +910,8 @@ step3:
> if ((flags & UVM_FLAG_OVERLAY) == 0)
> new_entry->etype |= UVM_ET_NEEDSCOPY;
> }
> + if (flags & UVM_FLAG_HOLE)
> + new_entry->etype |= UVM_ET_HOLE;
>
> new_entry->protection = prot;
> new_entry->max_protection = maxprot;
> @@ -1098,6 +1113,45 @@ uvm_map_spacefits(struct vm_map *map, va
> }
>
> /*
> + * uvm_map_pie: return a random load address for a PIE executable
> + * properly aligned.
> + */
> +
> +#ifndef VM_PIE_MAX_ADDR
> +#define VM_PIE_MAX_ADDR (VM_MAXUSER_ADDRESS / 4)
> +#endif
> +
> +#ifndef VM_PIE_MIN_ADDR
> +#define VM_PIE_MIN_ADDR VM_MIN_ADDRESS
> +#endif
> +
> +#ifndef VM_PIE_MIN_ALIGN
> +#define VM_PIE_MIN_ALIGN PAGE_SIZE
> +#endif
> +
> +vaddr_t
> +uvm_map_pie(vaddr_t align)
> +{
> + vaddr_t addr, space, min;
> +
> + align = MAX(align, VM_PIE_MIN_ALIGN);
> +
> + /* round up to next alignment */
> + min = (VM_PIE_MIN_ADDR + align - 1) & ~(align - 1);
> +
> + if (align >= VM_PIE_MAX_ADDR || min >= VM_PIE_MAX_ADDR)
> + return (align);
> +
> + space = (VM_PIE_MAX_ADDR - min) / align;
> + space = MIN(space, (u_int32_t)-1);
> +
> + addr = (vaddr_t)arc4random_uniform((u_int32_t)space) * align;
> + addr += min;
> +
> + return (addr);
> +}
> +
> +/*
> * uvm_map_hint: return the beginning of the best area suitable for
> * creating a new mapping with "prot" protection.
> */
> @@ -1385,6 +1439,8 @@ uvm_unmap_remove(struct vm_map *map, vad
>
> if ((map->flags & VM_MAP_INTRSAFE) == 0)
> splassert(IPL_NONE);
> + else
> + splassert(IPL_VM);
>
> /*
> * find first entry
> @@ -1451,7 +1507,9 @@ uvm_unmap_remove(struct vm_map *map, vad
> * special case: handle mappings to anonymous kernel objects.
> * we want to free these pages right away...
> */
> - if (map->flags & VM_MAP_INTRSAFE) {
> + if (UVM_ET_ISHOLE(entry)) {
> + /* nothing to do! */
> + } else if (map->flags & VM_MAP_INTRSAFE) {
> uvm_km_pgr
Re: dmesg IBM x3650 OpenBSD 4.3
gm_sjo <[EMAIL PROTECTED]> writes: > 2008/10/10 Theo de Raadt <[EMAIL PROTECTED]>: >> Wow. Good luck. Can't you see we've been down that road before with >> those bastards? But really. Good luck. You really are too optimistic, >> but sure, learn the reality for yourself. > > I'm sure calling vendors 'bastards' on a public mailing list is really > going to help the cause. Works better than anything else. //art
Re: kernel debugging broken in 4.4-CURRENT?
"Peter Kay - Syllopsium" <[EMAIL PROTECTED]> writes: > Given that I'm in a minority of kgdb users, what's everyone else using > in cases like this? I use printfs, pstat -d and ddb. Never use breakpoints since I don't trust them, they mess up timing too much. //art
Re: This is what Linus Torvalds calls openBSD crowd
Marc Espie <[EMAIL PROTECTED]> writes: > So, when he tries to say that the OpenBSD crowd has a different attitude, > I don't know who he's referring to, but certainly not me. That's the funniest part about this. If the attitude we have about the issue in that disucssion makes us a bunch of wanking monkeys, I'll lend him my baboon porn. He was saying the same things we say. Hell, reading him in that discussion without the From: lines could make me think I'm reading someone @openbsd.org //art
Re: subr_pool: question
It happens when some memory was freed to the pool and then modified after
it was freed.
//art
"banana split" <[EMAIL PROTECTED]> writes:
> hello,
>
> I've a question (maybe a stupid one). I have a problem with a box so I'm start
> searching the reason of this problem. By reading the code I'm wondering what
> are the circumstances under which the code panics in pool_do_get (different
> sentinel values...) specifically in
>
> #ifdef DIAGNOSTIC
> if (__predict_false(pi->pi_magic != PI_MAGIC)) {
>panic("pool_do_get(%s): free list modified: magic=%x; page %p;"
> " item addr %p",
> pp->pr_wchan, pi->pi_magic, ph->ph_page, pi);
> }
> #endif
>
> really thanks for any explanation/example and/or something to read on the
> matter
Re: rtorrent problems - solved?
viq <[EMAIL PROTECTED]> writes: > Sorry for the "carpet bombing", I grabbed the list of people who I saw > report problems with rtorrent. > > I'm writing to ask those who had problems with rtorrent try it again > with newest snapshots, I was not able to reproduce the problem on a > box that used to freeze. Please test and report, maybe Otto just fixed > another obscure bug ;) As I recall, rtorrent had problems because of their stupid overallocation of memory. Then the pagedaemon fixes might have made things behave better. //art
Re: Can't get KERN_NCHSTATS: Cannot allocate memory
Your userland is out of sync with the kernel. That's bad, mmkay? //art "Insan Praja SW" <[EMAIL PROTECTED]> writes: > Hi Misc@, > on latest "OpenBSD 4.4-beta (GENERIC.MP) #18: Mon Jul 7 08:40:47 WIT > 2008" AMD64 machine, while lookin' to my new favorite tool systat, on > the first page, I got the "Can't get KERN_NCHSTATS: Cannot allocate > memory". > I wonder what happen, it's a 1GB Memory machine, on 4 juli snapshot, > it doesn't complain. > As usual, here is the dmesg. > > OpenBSD 4.4-beta (GENERIC.MP) #18: Mon Jul 7 08:40:47 WIT 2008 > [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 1051168768 (1002MB) > avail mem = 1020350464 (973MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.34 @ 0x3f6ee000 (78 entries) > bios0: vendor FUJITSU SIEMENS // Phoenix Technologies Ltd. version > "5.00 R1.10.2151.A1" date 05/08/2006 > bios0: FUJITSU SIEMENS D2151-A1 > acpi0 at bios0: rev 2 > acpi0: tables DSDT FACP ASF! SSDT MCFG HPET APIC BOOT > acpi0: wakeup devices PEXA(S4) PEXB(S4) PEXC(S4) PEXD(S4) PEXE(S4) > USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) PCIH(S4) KEYB( > S4) PS2M(S4) COM1(S1) COM2(S1) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Pentium(R) D CPU 2.66GHz, 2660.43 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S > SE3,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG > cpu0: 1MB 64b/line 8-way L2 cache > cpu0: apic clock running at 133MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Pentium(R) D CPU 2.66GHz, 2660.18 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S > SE3,MWAIT,DS-CPL,TM2,CNXT-ID,CX16,xTPR,NXE,LONG > cpu1: 1MB 64b/line 8-way L2 cache > ioapic0 at mainbus0 apid 2 pa 0xfec0, version 20, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEXA) > acpiprt2 at acpi0: bus 3 (PEXB) > acpiprt3 at acpi0: bus 5 (PEXC) > acpiprt4 at acpi0: bus 7 (PEXD) > acpiprt5 at acpi0: bus 9 (PEXE) > acpiprt6 at acpi0: bus 11 (PCIH) > acpicpu0 at acpi0: FVS, 2667, 1862 MHz > acpicpu1 at acpi0: FVS, 2667, 1862 MHz > acpibtn0 at acpi0: PWRB > pci0 at mainbus0 bus 0: configuration mode 1 > pchb0 at pci0 dev 0 function 0 "Intel 82945G Host" rev 0x02 > vga1 at pci0 dev 2 function 0 "Intel 82945G Video" rev 0x02 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > agp0 at vga1: aperture at 0xe000, size 0x1000 > azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: > apic 2 int 18 (irq 9) > azalia0: codec[s]: Realtek ALC260 > audio0 at azalia0 > ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: apic 2 > int 17 (irq 11) > pci1 at ppb0 bus 3 > ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: apic 2 > int 16 (irq 11) > pci2 at ppb1 bus 5 > bge0 at pci2 dev 0 function 0 "Broadcom BCM5751" rev 0x01, BCM5750 A1 > (0x4001): apic 2 int 17 (irq 11), address 00:30:05:c9:79 > :df > brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 > ppb2 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x01: apic 2 > int 18 (irq 9) > pci3 at ppb2 bus 7 > ppb3 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x01: apic 2 > int 19 (irq 9) > pci4 at ppb3 bus 9 > uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 > int 23 (irq 11) > uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 > int 22 (irq 10) > uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 > int 21 (irq 5) > uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 > int 20 (irq 9) > ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 > int 23 (irq 11) > ehci0: timed out waiting for BIOS > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 > ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 > pci5 at ppb4 bus 11 > em0 at pci5 dev 5 function 0 "Intel PRO/1000MT (82540EM)" rev 0x02: > apic 2 int 22 (irq 10), address 00:07:e9:0f:44:37 > rl0 at pci5 dev 7 function 0 "D-Link Systems 530TX+" rev 0x10: apic 2 > int 21 (irq 5), address 00:11:95:63:48:63 > rlphy0 at rl0 phy 0: RTL internal PHY > pcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01 > pciide0 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, > channel 0 wired to compatibility, channel 1 wired to com > patibility > wd0 at pciide0 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors > wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 > atapiscsi0 at pciide0 channel 1 drive 1 > scsibus0 at atapiscsi0: 2 targets, initiator 7 > cd0 at scsibus0 targ 0 lun 0: ATAPI > 5/cdrom removable > cd0(pciide0:1:1): using PIO mode 4,
Re: developer laptop choices
Jose Quinteiro <[EMAIL PROTECTED]> writes: > Super quick and dirty check, and I'd have to get it with "Windows Vista > Ultimate". "Ultimate what?" > is the question that comes immediately to mind. No thanks. > > Personally, I'd buy a Dell Insipidron N-series, purely for political reasons. I sometimes hit myself for political reasons too. //art > Saludos, > Jose. > > Lars D. Noodin wrote: >> On Mon, 16 Jun 2008, Michiel van Baak wrote: >>> On 09:33, Mon 16 Jun 08, Michael Gale wrote: I just picked up a IBM Thinkpad T61p. >>> I have the same and really love it. >> >> How were either of you able to get one without the Windows tax? >> EU reports last autumn showed that is about half the cost. >> >> I've had small handful of ThinkPad's but stopped in 2002 when I got stuck >> with a bad unit and burned by a local dealer. The specs are attractive >> and I figure is about time look at them again, but only if they University >> are available with an open source system pre-installed. I'm looking at the >> lenovo shop pages and don't see the open source models available. >> >> -Lars >> >> Lars NoodC)n ([EMAIL PROTECTED]) >> Ensure access to your data now and in the future >> http://opendocumentfellowship.org/about_us/contribute
Re: Kernel developers guide/tutorial
"Don Hiatt" <[EMAIL PROTECTED]> writes: > [ Pardon if this email was repeated. > Sadly, I'm using Outlook and you know the rest :-) ] > > Can anyone point me to a kernel developers guide or tutorial? > Something that explains how to write a "hello world" type device driver > and such. Anything to bootstrap me a bit. ;-) > > Cheers! > > don /usr/src/sys //art
Re: Editing C with...
Marco Peereboom <[EMAIL PROTECTED]> writes: > He is eluding to things like smart tabs and auto indent. Those are > disabled by default on vim and when programming they are both a curse and > a gift from the gods. I'll admit to having spend more than a few > minutes fine tuning that. > > I am an old vi rat that finally caved to vim for several reasons. > Let me mention just a few: > * ctrl-p (autocomplete of a word) > * ctrl-v (visual blocks) > * split > * spelling check > * tab complete commands and filenames in command mode > * incremental and highlighted search > * tabs > * colors, yes I said it! So, you're using emacs with vi keys. And I use vi with emacs keys (mg). //art
Re: Doubt about license
Pieter Verberne <[EMAIL PROTECTED]> writes: > Pulic domain also says "do with it whatever you like". I really don't > know about the importance of the disclaimer. Maybe it depends on > the country you live in. "public domain" is a meaningless term in many countries (it doesn't have any meaning in courts, which in turn means that you keep all the rights that copyright law gives you). In many countries you can't give up the right to be recognized as the author even if you want to. > BTW, how many times is the BSD license in the source repository? I think > it is a filthiness of "$ head [sourcefile]". I think it's pretty. Makes the code feel like home. //art
Re: Chatting with developers? Is it soo 1996?
"Andris" <[EMAIL PROTECTED]> writes: > On Tue, Apr 15, 2008 at 2:20 PM, Theo de Raadt <[EMAIL PROTECTED]> wrote: >> > I found an old email on the mailing lists, dating back to 1996, when >> > Theo announced users could connect and chat with the developers on >> > their ICB server. >> >> Many developers did not like it, so please leave them alone. >> >> > > I can understand your point, but isn't there a way of connecting to > just read? I mean, we only read, you talk. > > That would be very interesting. Is there a way to connect to your phone to just listen? Not talk, just listen. That would be very interesting. //art
Re: How secure is OpenBSD really
"Jernej Makovsek" <[EMAIL PROTECTED]> writes: > Reading the archive it seems to me that el8 was taken as a joke: Yes, some random person, on a publicly available list where anyone can post, said he thought it was a joke. Your point is? Go away, little troll. //art
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
"Ross Cameron" <[EMAIL PROTECTED]> writes: > On Sun, Mar 30, 2008 at 9:26 PM, Jacob Meuser <[EMAIL PROTECTED]> wrote: > > you say, "config makes me boot faster." so then people go and config > > their kernel, and then we get problem reports about broken kernels. > > > > that's fine if you want to go break your machines. don't try telling > > others to do the same. > > I disagree,... this form of knowledge sharing amongst more advanced > users of any OS should be encouraged. Yes, and the knowledge among the more advanced users is "don't do it". So that's what's being shared. > Perhaps there is merit in it in a wider context,... we wont know > unless such things are discussed and debated. > Simply poh pohing it out of hand without wider discussion > throughout the user base is foolish at best. Oh, really. And you think that we haven't discussed this for the past 10 years? all over the mailing lists. //art
Re: gettimeofday() dramatical slowdown from 4.1->4.2
Most likely (although you haven't provided any information, so we can't be sure), your machine is using the 8254 time counter. Earlier it would have been using TSC for timekeeping, but TSC is so unreliable on so many machines and it's more or less impossible to know when it can be trusted, so TSC is not used anymore. In reality, what matters is that the timecounters are MP safe and support wider range of hardware. The code might be slower. Or might be faster when you have the right hardware. //art
Re: take threads off the table
Geoff Steckel <[EMAIL PROTECTED]> writes: > Any argument to experience must be from similar actual implementations > using "threads" and another model, such as multiple processes with > interprocess communications. Sure. I'll pick up the challenge. At work we have a server that uses around 4GB RAM and runs on an 4 cpu machine. It serves millions of tcp connections per hour. sharing the memory without sharing pointer values is too inefficient since a big amount of the memory used is a pre-computed cache of most common query results. The service needs 4x4GB of RAM on the machine to be able to reload the data efficiently without hitting disk, since hitting the disk kills performance in critical moments and leads to inconsistencies between the four machines that run identical instances of this service. Therefore: - fork would not work because cache would not be shared and this would lead to too big cache miss ratio. - adding more RAM won't work because it would spend rack real estate and power and cooling budget which we can't do. - adding more machines will not solve the problem for the same reasons as RAM. - reducing the data set will not work because we kinda like to make lots of money, not just a little money. - partitioning the data does not work good because it causes a too high cost in performance and memory consumption. What works is threads. We've had one thread related bug in the past year. //art
Re: kernel_map out of virtual space panic on different hardware within hours of difference
Martmn Coco <[EMAIL PROTECTED]> writes: > pfstatekeypl 108 108435160 5769657 138375 1243 137132 137132 0 > 80 [...] > In use 540926K, total allocated 559516K; utilization 96.7% This is a bit extreme. Either you have some insane amount of states in your pf or something is leaking memory. //art
Re: Getting envolved
Mathieu Stumpf <[EMAIL PROTECTED]> writes: > > I disagree. > > > > A complex interface implies a lot of code. a lot of code > > leads to unreliablity, either through bugs or detracting valuable > > developer time from more important things > > > > A simple interface (well designed) imples less code, which leads > > to reliability. > > So, you mean a more intuitive software is necessary more complex? Can't > we make a simple but intuitive interface without a lot of code? Well? Can you? Try. Let us know how it went. > > Users who can no invest the effort learn enough to use a > > simple interface do not deserve a reliable operating system. They > > deserve windows, and they deserve pop up buttong in their browsers > > that they click ok blindly for everything. > > > > -Bob > > Do you apply this reasoning to anything in life or do you reserve this > kind of eugenics only to IT? :) It's reality. //art
Re: no 4.2-stable package updates??
Brian <[EMAIL PROTECTED]> writes: > > So why does that "majority" not provide the skills or the money to > > support that facility? > > Maybe you should use something else that panders to your appetite. > > > > Completely unable to resist a great setup presented above, is the > software really free then? free doesn't mean that we're your servants. Go away, stupid troll. //art
Re: howto restored rm-ed files/directory
Artur Grabowski <[EMAIL PROTECTED]> writes: > "Insan Praja SW" <[EMAIL PROTECTED]> writes: > > > Hi Misc, > > I got an important directory in my 4.1 bsd and it's deleted using rm > > -rf :(. Anyone had experience restoring them? I really.. (I mean > > Really) need help on this one.. > > Forget it. > We zero block before they are marked as free in the filesystem, so by the > time you've finished writing this mail, your blocks were zeroed. I was wrong here. I thought we did, but we don't. So your files might still be there. //art > You can pay a few bazillions to Ibas and they might attempt to save your > data, but it's more likely they'll just laugh at you. And it's probably > cheaper to recreate the data from scratch anyway. > > //art > > > Thanks, > > Kind Regards, > > > > Insan > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: howto restored rm-ed files/directory
"Insan Praja SW" <[EMAIL PROTECTED]> writes: > Hi Misc, > I got an important directory in my 4.1 bsd and it's deleted using rm > -rf :(. Anyone had experience restoring them? I really.. (I mean > Really) need help on this one.. Forget it. We zero block before they are marked as free in the filesystem, so by the time you've finished writing this mail, your blocks were zeroed. You can pay a few bazillions to Ibas and they might attempt to save your data, but it's more likely they'll just laugh at you. And it's probably cheaper to recreate the data from scratch anyway. //art > Thanks, > Kind Regards, > > Insan > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: OpenBSD in the webcomic XKCD
frantisek holop <[EMAIL PROTECTED]> writes: > hmm, on Mon, Nov 26, 2007 at 05:14:50PM +0100, Artur Grabowski said that > > worked. Dual boot is for sissies who can't get a second machine. > > single boot is for sissies who drag around 3 notebooks with themselves :p I guess you've never hacked the kernel seriously and gotten annoyed by the music stopping when you need to reboot a new kernel. //art
Re: OpenBSD in the webcomic XKCD
Oh.. I've fucked up that many times. Always amusing. I once even had a kernel named: bsd.do_not_remove_this_art_really that Bob put there after the third time I had to borrow a dock from him to reinstall my laptop. //art David Gwynne <[EMAIL PROTECTED]> writes: > dual booting is having two kernels. bsd and bsd.working. > > On 27/11/2007, at 2:14 AM, Artur Grabowski wrote: > > > frantisek holop <[EMAIL PROTECTED]> writes: > > > >> but can't call yerself a unix guru if havent fu*ed up > >> dual boot at least once :] > > > > never fucked up a dual boot. Only tried it two times and both times it > > worked. Dual boot is for sissies who can't get a second machine. > > > > //art
Re: OpenBSD in the webcomic XKCD
Johan Mson Lindman <[EMAIL PROTECTED]> writes: > On Monday 26 November 2007 18:37:05 you wrote: > > "V. Karthik Kumar" <[EMAIL PROTECTED]> writes: > > > Artur Grabowski wrote: > > > > frantisek holop <[EMAIL PROTECTED]> writes: > > > >> but can't call yerself a unix guru if havent fu*ed up > > > >> dual boot at least once :] > > > > > > > > never fucked up a dual boot. Only tried it two times and both times it > > > > worked. Dual boot is for sissies who can't get a second machine. > > > > > > Either you knew everything then or you got incredibly lucky. Lots of > > > times, you aren't lucky even if you knew it all. Maybe if it all went > > > wrong, you'd have lost all partitions and would be to blame. We all > > > learn from mistakes and there is absolutely nothing "wrong" about > > > getting it "wrong". :-) > > > > no, the "wrong" part is in actually trying. :) > > > > //art > > > W/ "recent" changes to bootloader why _shouldn't_ you dualboot > i386 and amd64 on your amd64 laptop? ;-P Because then I'd spend more time booting and less time hacking. :) //art
Re: OpenBSD in the webcomic XKCD
"V. Karthik Kumar" <[EMAIL PROTECTED]> writes: > Artur Grabowski wrote: > > frantisek holop <[EMAIL PROTECTED]> writes: > > > >> but can't call yerself a unix guru if havent fu*ed up > >> dual boot at least once :] > > > > never fucked up a dual boot. Only tried it two times and both times it > > worked. Dual boot is for sissies who can't get a second machine. > > > > Either you knew everything then or you got incredibly lucky. Lots of > times, you aren't lucky even if you knew it all. Maybe if it all went > wrong, you'd have lost all partitions and would be to blame. We all > learn from mistakes and there is absolutely nothing "wrong" about > getting it "wrong". :-) no, the "wrong" part is in actually trying. :) //art
Re: src tree broken or cvs repo out of sync?
Didier Wiroth <[EMAIL PROTECTED]> writes: > Hello, > > I updated my src tree (current sources) this morning and updated it a few > times this afternoon but I'm not able to build the kernel anymore, is anyone > else experiencing this issue? > I'm able to reproduce this on another PC where I updated the source too. You need to rebuild usr.sbin/config before you can configure a new kernel. //art > cd /usr/src/sys/arch/amd64/conf && /usr/bin/sudo config GENERIC > ../../../../conf/files:995: syntax error > ../../../../conf/files:996: syntax error > ../../../../conf/files:997: syntax error > ../../../../conf/files:998: syntax error > ../../../../conf/files:999: syntax error > ../../../../conf/files:1000: syntax error > ../../../../conf/files:1001: syntax error > ../../../../conf/files:1002: syntax error > ../../../../conf/files:1003: syntax error > ../../../../conf/files:1004: syntax error > ../../../../conf/files:1005: syntax error > ../../../../conf/files:1006: syntax error > ../../../../conf/files:1007: syntax error > ../../../../conf/files:1008: syntax error > ../../../../conf/files:1009: syntax error > ../../../../conf/files:1010: syntax error > ../../../../conf/files:1011: syntax error > ../../../../conf/files:1012: syntax error > ../../../../conf/files:1013: syntax error > ../../../../conf/files:1014: syntax error > ../../../../conf/files:1015: syntax error > ../../../../conf/files:1016: syntax error > ../../../../conf/files:1017: syntax error > ../../../../conf/files:1018: syntax error > ../../../../conf/files:1019: syntax error > ../../../../conf/files:1020: syntax error > ../../../../conf/files:1021: syntax error > ../../../../conf/files:1022: syntax error > ../../../../conf/files:1023: syntax error > ../../../../conf/files:1024: syntax error > ../../../../conf/files:1025: syntax error > ../../../../conf/files:1026: syntax error > ../../../../conf/files:1027: syntax error > ../../../../conf/files:1028: syntax error > *** Stop. > *** Error code 1 > > Thx for the help > Didier
Re: OpenBSD in the webcomic XKCD
frantisek holop <[EMAIL PROTECTED]> writes: > but can't call yerself a unix guru if havent fu*ed up > dual boot at least once :] never fucked up a dual boot. Only tried it two times and both times it worked. Dual boot is for sissies who can't get a second machine. //art
Re: Paper about memory speed with multi-core CPUs
"Alexey Suslikov" <[EMAIL PROTECTED]> writes: > Johan Mson Lindman wrote: > > > > http://people.redhat.com/drepper/cpumemory.pdf > > > > > > - Alexey. > > > > > > Is this paper from the same Drepper as is posting in the URL below? > > http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.html > > Yes. But it's up to you - to leave yourself in 2000. No, it's up to him to leave himself in 2000. We've moved ahead since then while glibc is now the only modern libc that doesn't have strl*. Never trust the wisdom of someone who's stupid. //art
Re: OpenBSD kernel janitors
n0g0013 <[EMAIL PROTECTED]> writes: > > Development is not the same process as writing a whiny mail. > > that is a shame. i can probably better understand the relectance to > re-visit this if it has failed before. perhaps, others are right, > perhaps linux can tolerate it because it's not as good as openbsd. Oh, geee. You think you're so unique that you were the first one to think of this and that you're the first one to ask for hand holding? It _HAS_ failed before. Many, many, many times. My todo list has been on the web for over 6 years. It has given us one or two developers, but mostly it has gotten me shitpiles of mails asking for holding hands. Probably around 20 people I spent hundereds of hours on, giving advice, explaining things, helping debug, holding hands. The total result of committed code: 0. Maybe, just maybe it made me slightly bitter. People say that they'll do things because it makes them feel good and like they are participating. But actually doing stuff is work, so that's not interesting. //art
Re: OpenBSD kernel janitors
[EMAIL PROTECTED] writes: > surely there must be _some_ merit to creating a list of lower level > development tasks (as dictated by those with experience to judge) to > encourage people to enter the development cycle. The most amusing thing about this thread is that such a list has been published for years (it's somewhat short right now, but there's some simple stuff in it) and is the first search hit when you search on one of the obvious queries on google. //art
Re: About Xen: maybe a reiterative question but ..
Christoph Egger <[EMAIL PROTECTED]> writes: > > So I'm going to guess the answer is "No, integrating xen > > paravirtualization is not a project priority at this time. Also, where > > are your diffs?" > > The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg > Unfortunately, Anil has troubles with the availability of the server. > > I rely on having a willing OpenBSD developer who commits the patches I send > to him. But as long as there is none, it doesn't go in. I'm willing to stretch as far as saying: This might be interesting for some testing purposes for kernel hackers if Xen could be hosted on OpenBSD. But this doesn't mean that I'm even close to volunteering doing the job. It just would be cool to have if it doesn't break stuff. //art
Re: cp(1) bug ?
"Tom Van Looy" <[EMAIL PROTECTED]> writes: > on unix everything is a file? no, it's not. It's the dumbed down "truth" so that you can explain to random people what the hell Unix is, or rather to make them have a dumb look on their face and nod. A process is not a file, a memory region is not a file, the sysctl tree is not a file, there's plenty of stuff that is as far from files as you can get. Many directory operations are explicitly not done on file descriptors because it would be too complicated. //art
Re: To whom can I direct email for artwork use permission pls?
Brian Candler <[EMAIL PROTECTED]> writes: > Don't be misguided by what has been said here. OpenBSD is genuinely *free*. > That means you can use it for whatever you like. There's nothing in any way > immoral from selling it, whether or not you make a profit. There's a difference between immoral and illegal. Just because we don't want to forbid it, doesn't mean we have to like it. The license takes the stance "we don't know better than you what your needs are", but it doesn't mean we can't judge your behavior later. As a similar situation, freedom of speech isn't freedom from consequences, it's just a freedom from punishment. If you say stupid things, you will get bad reputation and you will get criticized. In our case, if you do bad things with our code, we will make moral judgements about it, we will criticize you, we just won't take you to court. Just because you can build baby mulching machines doesn't mean we have to use them or like them. //art
Re: That whole "Linux stealing our code" thing
Hannah Schroeter <[EMAIL PROTECTED]> writes: > I guess he means writing own additions/modifications (thus creating a > combined or derivative work), and releasing those *own* > additions/modifications under the GPL. In the end, you can use the > combined/derivative work only to the extent that's permitted by *both* > licenses. The term "embrace and extend" comes to mind. //art
Re: Backport drivers from 4.1 to 4.0
"Kevin Cheng" <[EMAIL PROTECTED]> writes: > Hi Darrin, > > Thanks for reply. > > The reason is that we have bunch of files integrated with 4.0 and it would > take us months to upgrade to 4.2 again. we just finished from 3.3 to 4.0 of > upgrade few months ago, plus months of test to stabilize our 4.0 based > applications. > > Should we just isolate one by one manually as safety approach? Any CVS that > we can trace for what files been changed for specific drivers? E.g., > 4.0->4.1. this is such a bad idea. >From experience I can tell you that it's much easier (in total) to upgrade your code once every 6 months than to do huge projects to do the same once every few years. //art > Thanks, > > Kevin > > > > > > -Original Message- > > From: Darrin Chandler [mailto:[EMAIL PROTECTED] > > Sent: Monday, August 27, 2007 2:19 AM > > To: Kevin Cheng > > Cc: misc@openbsd.org > > Subject: Re: Backport drivers from 4.1 to 4.0 > > > > On Mon, Aug 27, 2007 at 01:33:34AM +0800, Kevin Cheng wrote: > > > What would be the safe way to backport driver codes from > > 4.1 to 4.0, such as > > > (/usr/src/sys/dev) ci, pcmcia, usb? > > > > For most values of "safe" the answer is none. > > > > With the upcoming 4.2 release, 4.0 will be unsupported. Your backports > > will be unsupported immediately. Is there some pressing reason why you > > can't upgrade/reinstall to a newer version? > > > > -- > > Darrin Chandler| Phoenix BSD User Group | MetaBUG > > [EMAIL PROTECTED] | http://phxbug.org/ | > > http://metabug.org/ > > http://www.stilyagin.com/ | Daemons in the Desert | > > Global BUG Federation
Re: Software freedom
Theo de Raadt <[EMAIL PROTECTED]> writes: > If anyone had any doubt that our insistance on freedom was important, > just read this. > > http://mail-index.netbsd.org/source-changes/2007/08/24/0027.html > > What is even more astounding is the incestious love-in these other > groups have, with their Sam-worship, that prevents them from doing the > obvious and right thing. > > I for one, will say that I don't understand it at all. But hey, it > gives me another reason to mock the cult of Sam (Leffler) and Jason > (Thorpe). > > Fun fun fun. Ouch. Now the people in the office are looking at me and asking me why I'm laughing like a maniac. :) //art
Re: Top/uptime seems high
Joachim Schipper <[EMAIL PROTECTED]> writes: > Well, aside from the 'the load average is useless anyway' comments, a > load average of 1 is not necessarily unacceptable on a multi-processor > machine. (It means one CPU is constantly working.) No, no, no and NO. Please. If you don't understand load averages, do not try to interpret them. It means that whenever the once a second event in the kernel happens, something was either in the run queue or the system made a guess that something might end up in the run queue within a second. That guess is not always correct. If you have something that wakes up once a second without doing anything, it will add to the load average. //art > > I understood that load averages were related to the number of processes > > in the run-queue (i.e. waiting to get some processor time) so average > > loads above 1 would show a processing bottleneck. > > > > Did I get this wrong? If so, what do the load averages show and what > > would be a high load for a dual CPU (4 core) system? > > That depends on a lot of things - most of which can not be read from the > load average - but as a data point, the system I'm typing this on is a > uniprocessor box. The CPU is 96% idle. The load average is 3 (backups > and checking out the OpenBSD tree from a local repository - i.e. the > bottleneck is the disk and the network, not the CPU). The system is > pretty responsive. > > However, if we are talking CPU-bound processes, anything less than 4 at > a time means that there is no (significant) contention for the bounding > resource, which roughly means they all run at full speed. This is not to > say that having some reserve capacity is not useful, or that you should > strive for 100% resource utilization, but running one CPU-bound process > is not a high load for this machine. (One disk-bound process, on the > other hand, may be.) > > Joachim > > -- > TFMotD: netstat (1) - show network status
Re: systrace/sysjail wrappers security
Pawel Jakub Dawidek <[EMAIL PROTECTED]> writes: > In my opinion there are just too many potential problems with syscall > wrappers that I fully agree with Robert - they should not be used. I must fully agree here. I never liked systrace and bashed sysjail really hard because the solution is at the wrong layer where so many assumptions can go wrong. The problem is that we haven't really created a better framework for doing this type of things even though the users obviously seem to think they need it, so they use whatever they can get. One of these days ... //art
Re: Kuro5hin: OpenBSD Founder Theo deRaadt Has Conflict of Interest With AMD
chefren <[EMAIL PROTECTED]> writes: > OpenBSD Founder Theo deRaadt Has Conflict of Interest With AMD >By David Marcus, 2007-08-05 03:41:29 >Section: Technology, Topic: > >I formerly had a great deal of respect, bordering on admiration, for > Theo deRaadt's refusals to compromise his open source principles, even in > the face of stiff opposition. Although he has occasionally gone > over-the-top, recommended some frankly very dubious changes to OpenBSD, > and is regularly arrogant (which is even more annoying because he's so > often right!), he's always remained consistent in his devotion to the > cause of GNU/Free Software. > > http://www.kuro5hin.org/story/2007/8/2/15233/84896 WTF? Who wrote this shit? His "proof" of "a substantial amount of monetary support" is donations.html where AMD is listed. Oh and Intel is listed too, long way before AMD. And the second proof is some article on kerneltrap where I'm being quoted saying that I committed SMP support for amd64. Yes, we have received machines from AMD and we have received machines from Intel and HP and Digital. I have a really nice alpha I got from Digital and since Intel bought the processor manufacturing from Digital it means I got this huge, amazing machine from Intel. OMG INTEL OWNS MY ASS. The real question is who's paying that guy. I guess any corporate owned asshole can publish random slander on the internet and call it "research". //art
Re: Intel Core 2 - round #2
bofh <[EMAIL PROTECTED]> writes: > So, everyone picks up on the one thing that Linus fixed a while back, > the TLB stuff. What about the rest of the bugs? The non-TLB crap? > How is Art ignoring the relevance of the rest of the message? He just > said, the TLB is just a minor issue, that the *OTHER* guys are > ignoring the major stuff. I think that's what he said. He wasn't contradicting me, he was just amplifying my message. :) //art
Re: ADVERT: C12G
"Karl Sjvdahl - dunceor" <[EMAIL PROTECTED]> writes: > On 7/11/07, Marcus Watts <[EMAIL PROTECTED]> wrote: > > Joachim Schipper <[EMAIL PROTECTED]> wrote: > > > Subject: Re: ADVERT: C12G > > ... > > > That, and Schneier's 'snake oil' may well apply. > > ... > > > > Almost certainly applies. See > > http://groups.google.com/group/sci.crypt/msg/401bd358ad9f651e > > > > -Marcus Watts > > > > > > Everything just smells snake oil. 'Ultra-Secure', @yahoo.co.uk, > 'superiority in itself'. Including the name of the person who is known to submit patches once in a while that every time break the random generation in the system using arguments like "it uses xor because xor is a one time pad and therefore unbreakable". I believe that the name is actually a conspiracy of people who test the cryptography vigilance of the BSD projects by saying completly whacko things and seeing how fast they get debunked. In a few years there will be a scientific paper with graphs over response speed and the amount of sarcasm and laughing. //art
Re: VA space question
Constantine Kousoulos <[EMAIL PROTECTED]> writes: > Thank you art. You have been crystal clear. > > Constantine No, thank You for making me look in this direction and finding a way to speed up the pmap by another 10% (hacked up a diff tonight). //art
Re: Intel Core 2 - round #2
Christoph Egger <[EMAIL PROTECTED]> writes: > Linus contradicts Theo on Intel TLB issue: > http://blogs.zdnet.com/Ou/?p=559 No he doesn't. The article is confused and missed the whole point. The TLB issues are just one small part of what Theo was talking about, not even the most important one. Count the number of bugs in the errata. Only a very few of them deal with the TLB and most of those are easy to deal with and we've already had most of those right (the Core 2 problems we've been seeing are most likely caused by a different errata that the operating system can't do anything about, but I don't have any proof other than that updating the BIOS helps). The biggest, potentially exploitable, issues are other than the TLB issues. //art
Re: VA space question
Constantine Kousoulos <[EMAIL PROTECTED]> writes: > A second thing is that recursive mapping works well when we have > 2-level page tables (as in the i386 architecture). Try a few more levels of recursion. It works fine. > When we have 3 or > more page tables, the recursive mapping just points to another page > table and not to the physical address of a page. I think that is why > "The rest (of the page tables) is kept as physical pages in 3 UVM > objects, and is temporarily mapped for virtual access when needed". Do > these UVM objects work like a cache that save the last page tables > used? Erm. no. they are used to keep track of the page table pages. If you'd ask me, they are not really necessary to have there, other than to speed up certain operations by a tiniest fraction (so that we can do (obj,offset)->vm_page lookups instead of va->pa->vm_page lookups that are more expensive). I wouldn't trust those comments. Unfortunately, the common trait of most pmap comments is that they are written in a very early stage of pmap development and by the time the pmap is almost working, the author stops updating the comments (which is something you do mostly just to collect your thoughts). //art
Re: VA space question
Constantine Kousoulos <[EMAIL PROTECTED]> writes: > Which one level 1 ptp do we keep at the recursive area? Does OpenBSD > keep the last used level 1 ptp cached at that area? Please clarify. Huh? That question, no parse. The recursive map is simply the top level page table that we enter into itself (check pmap_create to find whichever slot it might be) to have easy access to the page tables. //art
Re: Running out of RAM -- for the archives
"Karl O. Pinc" <[EMAIL PROTECTED]> writes: > FYI, > > Running OpenBSD 4.0 stable, 32MB RAM, 3 identical > nics. > > One symptom of running out of RAM is getting a > panic on boot. The system boots fine with bsd.rd, > but try to boot with the bsd image and you get > (from handwritten notes): > > bmtphy1 at dcl phy1; BCM5201 10/100, rev. 2 > dc2 at pci0 dev 12 function 0 "Lite-On PCNIC" rev 0x20: irq 11,: can't > create tx map > panic config_make_softc: allocation for device softc failed > > I assume the problem is not enough RAM because when I > add more RAM everything works fine. Yes. You don't have enough memory to manage the hardware in your machine. Either have less hardware that has drivers that need memory, or get more memory. //art
Re: VA space question
Constantine Kousoulos <[EMAIL PROTECTED]> writes: > In file src/sys/arch/amd64/include/pmap.h: > > 1) There are two entries named "alt.L1 table (PTE pages)" in the > virtual address space schematic. One entry is for va > 0x7f80 - > 0x8000 and the other is for va 0xff80 - > 0x. > > I think that for va 0x7f80 - 0x8000 the entry > should be "L1 table (PTE pages)" and not "alt.L1 table (PTE pages)". Yes, that's correct, I fixed the comment. > 2) There is an unutilized va hole at 0x8000 - > 0x8000. What complexity to the calculations does that hole > saves us from? Erm. that hole is there because the amd64 mmu only supports 48 bits of address space. //art
Re: acpi suspend?
"Vim Visual" <[EMAIL PROTECTED]> writes: > "How are the chances that "suspend" is implemented in ACPI for 4.2??" 1% I had a prototype almost working at one point, messed it up without saving the working version, then never had time or energy to go back to it and noone else has picked it up. //art
