Re: time stops under VMWare VM
Josh Hoppes wrote: I've run into this issue as well in past versions. Set this in /etc/sysctl.conf kern.timecounter.hardware=acpitimer0 Yes, that's the sysctl I've adjusted, too. The one I mentioned earlier is not correct. I think I only used it to get valid values to set for kern.timecounter.hardware. Sorry for the confusion. Regards André
Re: pimd got me to ddb ?
On 31/01/12 16:39, Kapetanakis Giannis wrote:
Ok I'll try dmesg from ddb if that happens again.
Bad luck my dmesg is not saved through reboots, otherwise I would give
this info now...
thanx
Giannis
Hi,
I got this again after upgrading to 5.3 (two weeks ago) although I don't
think it's related since I'm getting
hungs from pimd since 5.0.
A second problem is that I couldn't do boot reboot from ddb and I had to
go there
to reset the machine.
Whole thread is in:
http://marc.info/?l=openbsd-miscm=132800134306980w=2
regards,
Giannis
uvm_fault(0xd0a977c0, 0xefffe000, 0, 1) - d
kernel: page fault trap, code=0
Stopped at pf_find_state+0x54: movl0x38(%eax),%edx
ddb{0}PID PPID PGRPUID S FLAGS WAIT COMMAND
*18955 1 18955 0 7 0pimd
ddb{0} trace
pf_find_state(d43e7700,f554dae8,2,d942ba00,d9e91822) at pf_find_state+0x54
pf_test_state_udp(f554db64,f554db54,2,2,d43e7700) at pf_test_state_udp+0xbc
pf_test(2,2,d42df000,f554dcb4,0) at pf_test+0xbae
ip_output(d942ba00,0,0,1,f554dd30) at ip_output+0x54d
mrt_ioctl(d97bce00,0,3b9aca00,2,da094a00) at mrt_ioctl+0x1b6
mrt_ioctl(40,f554de4c,2c,d046062f,40) at mrt_ioctl+0xa4a
ip_mrouter_set(d9907724,68,f554def0,68,f554def0) at ip_mrouter_set+0x7c9
sosetopt(d9907724,0,68,d942b300,246) at sosetopt+0x50
sys_setsockopt(da06eba4,f554df64,f554df84,d069f594,1) at sys_setsockopt+0xc4
syscall() at syscall+0x120
--- syscall (number 7) ---
0x2:
ddb{0}
pf_find_state(d43e7700,f554dae8,2,d942ba00,d9e91822) at pf_find_state+0x54
ddb{0} show panic
the kernel did not panic
ddb{0} machine ddbcpu 1
Stopped at Debugger+0x4: popl%ebp
ddb{1} trace
Debugger(d409b800,d08a8046,1,200202,1) at Debugger+0x4
i386_ipi_handler(b0,d0430020,d0a6,10,4d9d0010) at i386_ipi_handler+0x5f
Xintripi() at Xintripi+0x49
--- interrupt ---
__mp_lock(d0abb604,7fff,d9eef000,d0b769f4,f5554e1c) at __mp_lock+0x52
__mp_acquire_count(d0abb604,1,f5554e6c,d042f6ec,d0b769f4) at
__mp_acquire_count
+0x20
mi_switch(d0abfd3c,0,0,f5554e54,f5554e54) at mi_switch+0x1c2
sleep_finish(f5554e54,1,118,d093800f,c0) at sleep_finish+0x9e
tsleep(d0ac23e8,118,d093800f,0,f5554ea0) at tsleep+0x9b
doppoll(d9eef000,3c005260,a,0,0,f5554f84,f5554f1c,d042e172,d0abb604,286,f5554f1
c,0,f5554fa8) at doppoll+0x291
sys_poll(d9eef000,f5554f64,f5554f84,d069f594,1) at sys_poll+0x6f
syscall() at syscall+0x120
--- syscall (number 673172280) ---
0x2:
ddb{1} machine ddbcpu 2
Stopped at Debugger+0x4: popl%ebp
ddb{2} trace
Debugger(d409bc00,f5524f10,d07e64c1,0,d409bc34) at Debugger+0x4
i386_ipi_handler(0,d0430020,d0ab,10,d4090010) at i386_ipi_handler+0x5f
Xintripi() at Xintripi+0x49
--- interrupt ---
cpu_idle_cycle(d409bc00) at cpu_idle_cycle+0xf
Bad frame pointer: 0xd0c3fe28
ddb{2} machine ddbcpu 3
Stopped at Debugger+0x4: popl%ebp
ddb{3} trace
Debugger(d409c000,f5526f10,d07e64c1,0,d409c034) at Debugger+0x4
i386_ipi_handler(0,d0430020,d0ab,10,d4090010) at i386_ipi_handler+0x5f
Xintripi() at Xintripi+0x49
--- interrupt ---
cpu_idle_cycle(d409c000) at cpu_idle_cycle+0xf
Bad frame pointer: 0xd0c3fe28
ddb{3} machine ddbcpu 4
Invalid cpu 4
ddb{3} boot reboot
panic: kernel diagnostic assertion p-p_wchan == NULL failed: file
../../../../kern/kern_sched.c, line 311
Stopped at Debugger+0x4: popl%ebp
ddb{3} trace
Debugger(d0964e86,f5526a84,d09435b8,f5526a84,7fff) at Debugger+0x4
panic(d09435b8,d08b1dce,d094127c,d094124d,137) at panic+0x5d
__assert(d08b1dce,d094124d,137,d094127c,da0758b8) at __assert+0x2e
sched_chooseproc(da074858,da0758b8,f5526b48,d044a395,d409c034) at
sched_choosep
roc+0x175
mi_switch(d0abfd3c,d04487fc,da07d008,f5526b28,f5526b4c) at mi_switch+0x124
sleep_finish(f5526b4c,1,10,d090a584,d0a62380) at sleep_finish+0x9e
msleep(d40bc560,f5526b90,10,d090a584,0) at msleep+0x7b
mfi_exec(d40a9000,d40bc560,78,d0460713,0) at mfi_exec+0x94
mfi_do_mgmt(d40a9000,d40bc560,1101000,0,0) at mfi_do_mgmt+0xe9
mfi_scsi_cmd(d8af9440,d05eaf00,f5526c44,d40a8500,21) at mfi_scsi_cmd+0x1a5
scsi_xs_sync(d8af9440,3,f5526c88,0,d3f86c70) at scsi_xs_sync+0x55
sd_flush(d408b000,3,f5526cb8,d04373ad,d408b000) at sd_flush+0x5d
sd_shutdown(d408b000,1,0,4804,f5526d1c) at sd_shutdown+0x24
dohooks(d0a50464,1,f5526ce8,d0404905,d) at dohooks+0x6d
boot(4804,f5526d1c,f5526da8,d0402794,4) at boot+0x45
db_boot_reboot_cmd(4,0,,f5526d20,0) at db_boot_reboot_cmd+0x12
db_command(d0a4e4c0,d0a4e2e0,8cff7e8c,d05c91e4,f5526eb4) at db_command+0x124
db_command_loop(d05c91e4,f5526e10,f5526e18,d040ca4d,800) at
db_command_loop+0x7
f
db_trap(1,0,58,d0,1) at db_trap+0xd0
kdb_trap(1,0,f5526eb4,f5526e7c,d05da7ef) at kdb_trap+0x10b
trap() at trap+0x3d7
ddb{3} boot reboot
panic: tsleep: not SONPROC
...
OpenBSD 5.3-current (GENERIC.MP) #164: Sun Jun 2 17:36:48 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU E5640 @ 2.67GHz (GenuineIntel 686-class)
2.67 GHz
cpu0:
floods in Calgary, is the project affected?
It's all over the news (BBC, ARD) that there is floods in Calgary. And I'm wondering if the OpenBSD servers are affected since they are in a basement afaik. Is the physical location secure from these floods? Regards, -peter
Re: Fandom and dangers of Free Software
GCC 4.3: sched.c line 572: Error: PC Load Letter. Theo De Raadt stared at his screen. Another glitch, another delay. The next version of OpenBSD, 4.4, was due for release a week ago, and he was still not ready. Just another reason for a jerkoff with a DSL connection and an IRC client to think that Theo De Raadt was anything *but* the best programmer ever. He took another drag from his cigarette, another couple millimeters burned from the end. He looked into the pack (just five left - not near enough to get him through this night) and sighed. Theo De Raadt didn't need some dry plant leaf to get him through this. Theo De Raadt didn't need anything organic to reassure him he was the BEST PROGRAMMER EVER. Not that it mattered, anyways. GCC was being a joke, as always. Nobody took that cunt Stallman seriously, anyways. It wasn't the fucking OpenBSD trunk that was the problem. It was GCC. What was GCC, anyways? Just another quisinart. Well, this wasn't going to compile itself. The amber light of his terminal shown on his face, a few more photons dancing on his intent eyes, the irises opening slowly. He saw the amber spark that danced on the bottom of his screen, another of the amber sparks that waited, obeying his every command. He fired up Vim. The characters, his inspiration, his *muse*, filling the screen. The terminal stretching to accomodate the source files on which he worked. He aligned his keyboard, running his fingers slowly across the keys, feeling his index fingers sliding across into home row. 527 G return. The air, the little figment GCC was so eager to choke on, was clear as a thousand suns, yet thick with the haze smoke of dozens of cigarettes and the heat of dozens of SPARC servers. The pea soup of nicotine fog was agitated by his rack of fine Sun bozen. Now THAT was a real man's tool, he thought. It has been said that it is a poor craftsman who blames his tools. But yet, is there not more to the relationship of man and tool? Is a great craftsman not inevitably inspired by his tool. Is his tool not inevitably amused? Is it not inevitably a conduit for his inspiration... his passion... to burst out upon the face of the world? A stream of characters littered the bottom of his screen. In this dark night, in this darkest hour for the openbsd project, perhaps these symbols would bring a faint glimmer of hope. Hey Theo, just ran w on your server, noticed you. Must be getting late huh (not that I'm an expert on timezones). This wasn't the source he was looking for, but that wasn't a bad thing. Perhaps this unexpected interruption into his private coding session would provide that spark of excitement he needed to deal with GCC's numerous inadequacies. Perhaps this mysterious stranger would give him the strength he needed to deal with that stack smashing, buffer overflow generating, decidedly position dependent, poorly optimized bloated junk that open source coders like himself, men seeking to thrust their skill into this world, were forced to deal with. If no good deed goes unpunished, then all this penance ensured that Mr. Theo De Raadt had been a very, very good boy indeed. He slapped control z, bringing up that $, so eager to await his every motion. w | grep esr - he brushed gently his smallest, most delicate finger across the return key, contemplating briefly before sending the electrical pulse that would unravel the mystery in naught but a microsecond. His faithful, electric-powered steed unveiled to him the truth of the mystery. Perhaps his partner wasn't so mysterious after all. The results, not unexpected, but not unexciting. Of course. Who else could he expect to be by his side on this dark, lonely companion - esr. He paused for a bit - maybe a couple billion cycles on that little piece of silicon that made this all possible. He didn't want to waste this next reply. An encounter with esr was worth the time spent. He savored the next few moments. He wasted a few keystrokes prototyping his response. For a man like Theo, C code came easy, flowed off his delicate (but yet strong) lips like the aroma of a fine wine. Time with esr, those octets of data stringing themselves across a web of glass, was so exotic compared to the normal, monastic life of the best programmer in the world. Eventually, he released that magic combination of control and h, that little chord of keys that he was so quick to use, to ensure that any vision presented would be naught utter bliss. He shift his hands back to home row. A, E, O - that combination so familiar to a master of Dvorak, the only way a man of his stature could interface with the virtual world of his computer, a virtual world he created. esr, my friend, were you testing me with that anonymous message - concerned, perhaps, I'd slipped? But don't worry, by friend, I'd didn't need to burn a couple execution cycles to know it was you. Who else can I trust, who else can I confide in? No... Who else could I bear to admit into my private meditations
Licensing question
Hello, I'm a mail administrator for a student group at my alma mater, RIT. We're not particularly satisfied with our current greylisting software (gld), and the best alternative (hell, the best greylisting software, hands down) is spamd. Unfortunately, none of the other sysadmins want to maintain an OpenBSD, simply because they're unfamiliar with it (they only know linux). So obviously the correct solution was to port spamd to linux. I currently have an untested (I'm going to spin up some EC2 instances to do testing this weekend) start on a port to linux on GitHub: https://github.com/worr/spamd So my questions: Is there anything else I need to do to make sure that I'm kosher with the license terms? I based the LICENSE file off of the one from portable OpenSMTPD. Do I need to update any of the copyright notices at the beginning of the files? I love the software so much that I want to contribute back to spamd, is there anything special I need to do other than emailing patches to tech@? Other than following the cvs logs, tech@ and the Changes pages, is there anyway I can be updated with changes to spamd? Thanks so much for the help and for the awesome software!
Re: floods in Calgary, is the project affected?
On Sat, Jun 22, 2013 at 7:08 AM, Peter J. Philipp p...@centroid.eu wrote: It's all over the news (BBC, ARD) that there is floods in Calgary. And I'm wondering if the OpenBSD servers are affected since they are in a basement afaik. Is the physical location secure from these floods? Yes, it's secure from the floods. The power has even been okay...so far... Philip Guenther
Re: Fandom and dangers of Free Software
Btw, if anyone feels the need to reply, don't include misc@. We are not interested.
Re: 802.11n support
On 2013-06-22, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sat, Jun 22, 2013 at 10:21:10AM +1000, John Tate wrote: I have an Atheros AR9227, there is at the moment no support for 802.11n in the patch branch. Is there support in current or some unoffical patch I can apply to the source code? Support for this would be good. -- www.johntate.org No support in -current or any unoffical patch I know of. Ken There is code in FreeBSD to look at if anyone is interested in looking at it with a view to porting. Much of the net80211 layer support for 11n has been in for a while but no actual drivers were converted until relatively recently so it's still quite early days.
Re: Licensing question
On 2013-06-22, William Orr w...@worrbase.com wrote: I currently have an untested (I'm going to spin up some EC2 instances to do testing this weekend) start on a port to linux on GitHub: https://github.com/worr/spamd So my questions: Is there anything else I need to do to make sure that I'm kosher with the license terms? I based the LICENSE file off of the one from portable OpenSMTPD. Do I need to update any of the copyright notices at the beginning of the files? spamd has its own license and copyright notices, these should be kept - opensmtpd copyright notices do not apply as it is different code by different authors. I love the software so much that I want to contribute back to spamd, is there anything special I need to do other than emailing patches to tech@? Please send patches inline in the email body rather than as an attachment, preferably as cvs diff -uNp against the -current OpenBSD tree, Other than following the cvs logs, tech@ and the Changes pages, is there anyway I can be updated with changes to spamd? There's a source-changes mailing list, if you're not interested in other changes to OpenBSD then I guess maybe you could subscribe and filter out uninteresting things via sieve/procmail/etc?
