dc(1): keep reading stdin after file
Hello! I noted that the manpage of dc(1) reports a detail which is inconsistent with the actual behaviour. Right at the beginning, it states the following: 'If an argument is given, input is taken from that file until its end, then from the standard input.' In fact though, when started with an argument, the file is read and dc then exits. The attached patch fixes this. Cheers, s//un --- dc.c.orig Mon Aug 6 11:41:34 2012 +++ dc.cMon Aug 6 11:41:36 2012 @@ -99,11 +99,6 @@ reset_bmachine(src); eval(); (void)fclose(file); - /* -* BSD and Solaris dc(1) continue with stdin after processing -* the file given as the argument. We follow GNU dc(1). -*/ -return (0); } src_setstream(src, stdin); reset_bmachine(src);
Re: vim and CTRL+] doesnt work
* Christian Barthel on Sun, Nov 06, 2011 at 07:04:28PM +0100: I try to use ctags and vim but I cant use the CTRL+] command to follow a function to its declaration. I tried the tags file and the c-program on another host and it works there. Does anyone know how to fix this? * Vi IMproved 7.3 * OpenBSD 4.9 * ctags * T61 notebook (I tried the internal keyboard as well as an external keyboard. Does CTRL+] work in the help files? Do you have any mappings active which may map CTRL+] to something else? X11 or console? Keyboard layout? What does happen if you do CTRL+V, CTRL+] say, on the shell prompt or in Vim itself? If in X11, what does xev(1) say if you press CTRL+]? s//un -- Securing an environment of Windows platforms from abose---external or internal---is akin to trying to install sprinklers in a fireworks factory where smoking on the job is permitted. -- Gene Spatford
Re: ThinkPad 600 screen size.
* David Walker on Fri, Nov 04, 2011 at 07:20:43PM +1030: This BIOS is ... sad. It's mouse driven - the cursor is a bird that flaps its wings. :[ Some people at IBM really had too much time at their hands... There is a video option but it only disables the external monitor - I tried it anyway. There should be an option that reads like 'H/V expansion'. I have had several Thinkpads of that vintage myself (including a 600) and remember that all of them had this kind of BIOS setting. Some models also had an utility program (Windows-only, of course) that did it in software---don't remember if this was also the case for the 600, though. s//un -- Frauen hinter den Herd? Blvdsinn, wo die Schalter doch alle vorne sind!
Re: lpd printing problem
* Pascal Stumpf on Wed, Oct 12, 2011 at 05:39:48PM +0200: Check your /var/log/lpd.errs. Doesn't contain anything but restarted messages. Also, ktracing lpd with the the -i flag might give a clue to what the lpd child is doing. Apparently, it segfaults: I remembered I had the S malloc flag set, so I removed /etc/malloc.conf, and ta-daaa, works. So this is a bug in the lpd code. I suspect it is somewhere in the common code for all lp programs, as I've also experienced SIGSEGVs in lpc. I'll see if I can hunt it down further if I have time ... I've had a very similar problem after last upgrading to -current. lpr'ing new jobs would spool them, but complaining about 'unable to start daemon'. Restarting lpd, purging the queue and some other hocuspocus eventually got the printing going again, but this was pretty much at random -- sometimes, it'd just work. (All that without the 'S' flag to malloc.conf, though.) The patches from Otto and Todd (i.e., today's snapshot) made the problem disappear -- many thanks! The rest of the message is just for the archives (Googling for this kind of problem is an exercise in frustration...). The log was basically useless (the lpd master process _did_ see and log the new jobs, but then apparently did nothing about them). After digging through the code, it seems to be the same problem as Pascal's, that the lpd childs were dying instead of working, and from then on the whole system gets out of sync. What stymied me was that the whole lpr/lpd code wasn't touched in years (except for mandoc stuff); since I'd upgraded from 4.7 in theory nothing should have changed, so everything should have still been working -- until I stumbled over this thread. Now that I've already waded through that code (and if my meagre C skills allow it), I'll try to gently add a few lines of diagnostic messages for the log, so that it isn't that difficult to hunt down this kind of problem in the future. So in this regard, what's the established practice in this situations? Is code for those kinds of base daemons expected to be correct or should there be a degree of 'mistrust'? Or in other words: Should lpd assume that its children will never segfault, or should it assume that sometimes, something may happen and try to restart? Up until recently (I've not yet taken a look at the new rc-scripting stuff yet) the way daemons were started suggested the former. Cheers, s//un -- When I read about the evils of drinking, I gave up reading. -- Henry Youngman
Unbreak fortune/unstr
Hi! I've noticed that the unstr utility from games/fortune does not work properly. When reading the header of .dat files, all the other utilities do some endianness correction, but unstr does not. Therefore, it gets wrong information, and produces garbage. The diff below fixes this symptom. Using the unpatched unstr on any datfile previously generated by strfile aborts quickly since the flags are not interpreted correctly. By commenting out the flag processing code, unstr works to some degree, but doesn't get the right number of entries and runs in a pseudo-endless loop. The patched version doesn't exhibit those symptoms. Still, I don't understand the reason why strfile does htonl (strfile.c at line 220 onwards) for all the header fields in the first place, only for fortune then to undo it (and for unstr to forget doing it, therefore not working). Also, fortune.c at line 1107 does ntohl to undo the htonl of strfile.c for every header field but for tbl.str_version, which is explicitely commented out. This seems rather odd -- looking at fortune's behaviour in the debugger shows that without ntohl the str_version comes in in reverse byte order, as expected. According to CVS, this oddity comes all the way from the initial import. The second diff fixes that. Last, I'd like to suggest that strfile and unstr be included in the base distribution. It seems strange that their source is there and the fortune(6) manpage loops through hoops to mention that they can be compiled if one wishes so -- but before I try to patch that, I'd like to hear whether there are some non-obvious reasons why they are kept out. Cheers, s//un Index: unstr/unstr.c === RCS file: /cvs/src/games/fortune/unstr/unstr.c,v retrieving revision 1.10 diff -u -r1.10 unstr.c --- unstr/unstr.c 27 Oct 2009 23:59:24 - 1.10 +++ unstr/unstr.c 21 Oct 2011 17:26:11 - @@ -79,6 +79,12 @@ (void) fread(tbl.str_shortlen, sizeof(tbl.str_shortlen), 1, Dataf); (void) fread(tbl.str_flags,sizeof(tbl.str_flags),1, Dataf); (void) fread( tbl.stuff,sizeof(tbl.stuff),1, Dataf); + tbl.str_version = ntohl(tbl.str_version); + tbl.str_numstr = ntohl(tbl.str_numstr); + tbl.str_longlen = ntohl(tbl.str_longlen); + tbl.str_shortlen = ntohl(tbl.str_shortlen); + tbl.str_flags = ntohl(tbl.str_flags); + if (!(tbl.str_flags (STR_ORDERED | STR_RANDOM))) errx(1, nothing to do -- table in file order); Delimch = tbl.str_delim; Index: fortune/fortune.c === RCS file: /cvs/src/games/fortune/fortune/fortune.c,v retrieving revision 1.30 diff -u -r1.30 fortune.c --- fortune/fortune.c 3 Jan 2011 17:38:24 - 1.30 +++ fortune/fortune.c 21 Oct 2011 17:26:11 - @@ -1104,7 +1104,7 @@ exit(1); } - /* fp-tbl.str_version = ntohl(fp-tbl.str_version); */ + fp-tbl.str_version = ntohl(fp-tbl.str_version); fp-tbl.str_numstr = ntohl(fp-tbl.str_numstr); fp-tbl.str_longlen = ntohl(fp-tbl.str_longlen); fp-tbl.str_shortlen = ntohl(fp-tbl.str_shortlen); -- squeak!
Re: Unbreak fortune/unstr
* Theo de Raadt on Fri, Oct 21, 2011 at 11:49:22AM -0600: Last, I'd like to suggest that strfile and unstr be included in the base distribution. It seems strange that their source is there and the fortune(6) manpage loops through hoops to mention that they can be compiled if one wishes so -- but before I try to patch that, I'd like to hear whether there are some non-obvious reasons why they are kept out. I am not a fan of filling the binary distribution with tools which noone will use. Perhaps the code for these could be merged into fortune itself, as options. That sounds like a sensible idea. I will give it a try. -- When we transitioned from 32-bit offsets, we did so *without* the abominable hack that StunOS uses that requires -DDONT_SCREW_ME_WITH_A_SPLINTERY_TIMBER_FOR_USING_64_BIT_OFF_T or whatever it is. -- Thor Lancelot Simon; comp.unix.bsd.netbsd.misc
Re: Volunteer project to implement wireless in a school
* Hugo Osvaldo Barrera on Wed, Oct 19, 2011 at 08:13:47PM -0300: Note, however, the downside is openbsd does not support 802.11n (it DOES however, support 802.11n cards running on 802.g or older modes). Another thing that you might want to keep in mind is that OpenBSD's HostAP doesn't support power-saving (see e.g. the ral(4) manpage). In a project as large as this, I don't think that you'll get all clients to deactivate it. s//un --
[resolved] smtpd mangles IPv6 addresses when using smarthost
* Stefan Unterweger on Tue, Oct 18, 2011 at 12:38:56AM +0200: Instead of using the full IPv6 address, it only uses the subnet prefix of the smarthost. This of course fails horribly, leading to a two-minute timeout, and then finally the mail goes through using IPv4 only. Did this work before you updated ? The regression must have crept in between the 4.8 and 4.9 releases. Both 4.7 and 4.8 do just fine, and with 4.9 I get the behaviour shown above. I'll try with a recent snapshot too, once the download is done. I've just tested it with yesterday's snapshot: Now it is handled correctly: | mta: getting datafd | mta: connect IPv6:2001:1418:153::260:8ff:fe0b:35c7 | mta: entering smtp phase | client: ssl handshake started | client: ssl handshake completed And the mail gets delivered. Thanks for your work -- it looks like every time I touch it, it improves. :o) s//un -- squeak!
Re: Printing (well anything) using lpd...
I know this thread is very old, but I thought this might be useful for the archives -- and maybe for the original poster as well. * Bryan on Sat, Jan 29, 2011 at 10:48:58PM -0600: it was easier to copy the file to a Windows box and print. But I'm tired of having to do this, and have begun researching how to print to a printer on the network. I recently bought a Brother 9840CDW, which supports lpd and postscript. It also allows for FTP of files to queue among other things. It's probably more printer (scanner, fax, copier) than I need, but I'm tired of HP printers and the toner issues they have. It is a really nice printer in Windows, and the scanner is most excellent and fast. And according to the LInux foundation site (http://www.linuxfoundation.org/collaborate/workgroups/openprinting) it works perfectly. Of course, I have to take this with a grain of salt, because of Linux's willingness to add proprietary drivers, firmware, etc. Your printer seems very similar to mine, which is a MFC8380DN. I've combed through the manual, and network-wise it supports everything mine does and some more. As Christian correctly said, BRScript3 is just Brother's fancy name for Postscript -- your printer definitely supports it, and I'm convinced that it supports hassle-free lpd operation as well. Since I detest cups with a fiery vengeance, I'm running my printer on my network with lpd only, and it works like a charm. The crucial point is that you have to use a specific lpd queue for the printer to accept the input as Postscript and not just as generic plain text. The manual for your printer omits this passage, but in several others (including mine) it is given. The manual states (look for LPD+Mac operation) that you have to construct the queue name like this: 'BRN_AT', with the x'es replaced by the MAC address of your printer. In my case, the printcap recipe looks like this: | brother|Brother MFC-9840CDW:\ | :lp=:rm=172.23.13.150:rp=BRN001BA968596A_AT:sd=/var/spool/output/brother:lf=/var/log/lpd-errs Obviously, you have to replace IP address and MAC address by your own. If you know your printer's IP address, then ping it and use `arp -a` to get the MAC address. An even simpler recipe is the JetDirect emulation at Port 9100. There you don't have to fiddle around with print queues, and the printer basically just prints everything it sees on that port, as somebody else already mentioned in this thread: | brother|Brother MFC-9840CDW:\ | :lp=9100@172.23.13.150:sd=/var/spool/output/brother:lf=/var/log/lpd-errs As I said, my printer works perfect with both configurations, using OpenBSD's lpd, and if I feed Postscript via lpr it just prints it. It won't eat PDF, but that's just a manner of using `pdf2ps $file - | lpr` I hope somebody might find this still useful and won't disturb the ashes of this thread anymore. :o) s//un
Re: Printing (well anything) using lpd...
* Bryan on Mon, Oct 17, 2011 at 10:38:57AM -0500: In my case, the printcap recipe looks like this: | brother|Brother MFC-9840CDW:\ | :lp=:rm=172.23.13.150:rp=BRN001BA968596A_AT:sd=/var/spool/output/brother:lf=/var/log/lpd-errs Obviously, you have to replace IP address and MAC address by your own. If you know your printer's IP address, then ping it and use `arp -a` to get the MAC address. I did not know this... how did you find this out? I read through all the manuals that came with the printer, but didn't see anything about this even on the brother website. I've looked through the manual of your printer as well, and indeed there is no mention of this at all. I've actually found it in the manual of my own printer, and only after a thorough search in some obscure footnote. Can you supply a link for me, and others? It's in here: - http://welcome.solutions.brother.com/BSC/public/files/dlf/doc002447/cv_dcp8080n_ukeng_net_b.pdf Search for 'lpd', then you'll find a section of how to get a Mac to print through LPD, and there I found this obscure queue name. (What on earth where they thinking anyway? Something like 'postscript' would have sufficed and would have been much less weird...) s//un -- squeak!
Re: smtpd mangles IPv6 addresses when using smarthost
Hello! Sorry that it took so long, but I got sidetracked by other projects and haven't had the time to set up a test machine until now. * Gilles Chehade on Fri, Aug 05, 2011 at 04:50:59PM +0200: | startup [debug mode] | [...] | smtp: will accept at most 246 clients | [...] | mta: getting datafd | mta: connect IPv6:2001:1418:153::: | mta: new status for me.mys...@example.com: 110 connect error: Host is down | mta: connect IPv6:2001:1418:153::: | mta: new status for me.mys...@example.com: 110 connect error: Host is down | mta: connect 94.95.177.106 | mta: entering smtp phase | [...] Instead of using the full IPv6 address, it only uses the subnet prefix of the smarthost. This of course fails horribly, leading to a two-minute timeout, and then finally the mail goes through using IPv4 only. Did this work before you updated ? The regression must have crept in between the 4.8 and 4.9 releases. Both 4.7 and 4.8 do just fine, and with 4.9 I get the behaviour shown above. I'll try with a recent snapshot too, once the download is done. s//un -- squeak!
Re: pre-orders for 5.0
* Theo de Raadt on Wed, Sep 07, 2011 at 06:35:05AM -0600: I have activated pre-orders for the 5.0 release -- it is scheduled for official release on Nov 1 on the FTP sites. As usual, we try to get CDs in people's hands slightly a few days before that. http://www.openbsd.org/orders.html I think the link to OpenCompany (Italy) should be dropped. They list OpenBSD 4.5 as the current version and mention being out of stock until that one arrives. The last update to the front page was somewhere in 2008 -- it looks rather abandoned... s//un
Re: ext42fs support?
* Benny Lofgren on Mon, Aug 22, 2011 at 11:47:01AM +0200: Otherwise, it sounds more like what you need is NFS... or is the machine you're trying to do this on a dual-boot machine and you want access to the file system in question from both environments? In that case, I suggest you reformat the file system to ufs which would be usable by both systems. A few months ago on some other mailing list it was suggested to use UDF as a lingua franca filesystem -- at least in theory every major operating system should be able to use it. I've always wanted to try it, but I've never been able to find something akin to newfs_udf or something similar, and mkhybrid also does not seem to be able to generate UDF filesystems. Allegedly, Macs have a newfs_udf command, but that of course does not help much. Has anybody tried something similar and got it to work? I do not depend on such a thing, I'm merely curious. And also, it would be very nice for USB sticks. Bye, Stefan
smtpd mangles IPv6 addresses when using smarthost
Hi! I've just seen a rather weird behaviour with smtpd on my box (recently updated to OpenBSD-4.9). The setup is very simple: All mail gets forwarded using my smarthost. The only problem: The smarthost in question is also reachable by IPv6, and accordingly has an record. smtpd sees this, tries to connect using IPv6, but seemingly botches the attempt in a particularily strange way: | startup [debug mode] | [...] | smtp: will accept at most 246 clients | [...] | mta: getting datafd | mta: connect IPv6:2001:1418:153::: | mta: new status for me.mys...@example.com: 110 connect error: Host is down | mta: connect IPv6:2001:1418:153::: | mta: new status for me.mys...@example.com: 110 connect error: Host is down | mta: connect 94.95.177.106 | mta: entering smtp phase | [...] Instead of using the full IPv6 address, it only uses the subnet prefix of the smarthost. This of course fails horribly, leading to a two-minute timeout, and then finally the mail goes through using IPv4 only. The configuration is basic, no surprises here: | listen on lo0 | accept for all relay via mailin.aleturo.com First, I thought it might be a DNS problem, but manual lookups are ok: | mailin.aleturo.com has address 94.95.177.106 | mailin.aleturo.com has IPv6 address 2001:1418:153::260:8ff:fe0b:35c7 Also, specifying the literal IPv6 address in smtpd.conf doesn't help, and produces the exact same result as above (minus the IPv4 connection at the end). I find it difficult to imagine that this is standard behaviour for smtpd, so I'm assuming that something on my machine might be misconfigured in some obscure way -- but I have no clue to what this might be. Is this a true and genuine bug -- in which case, I can stop worrying and trying to find configuration errors on my part -- or might there be something that I've overlooked? Thanks, Stefan
Re: smtpd mangles IPv6 addresses when using smarthost
* Gilles Chehade on Fri, Aug 05, 2011 at 04:50:59PM +0200: Instead of using the full IPv6 address, it only uses the subnet prefix of the smarthost. This of course fails horribly, leading to a two-minute timeout, and then finally the mail goes through using IPv4 only. Did this work before you updated ? The update was from something ancient like 4.5 or so, which didn't yet have smtpd. Among other things, getting smtpd was one of the reasons for the update, so unfortunately I can't tell. I might still have one other computer still running 4.7 for which I've long been planning to install a similar setup; as soon as I get there I can give it a try. Since that one will need upgrading anyway, I can then also do a quick test with 4.8 as well. Is this a true and genuine bug -- in which case, I can stop worrying and trying to find configuration errors on my part -- or might there be something that I've overlooked? Do not underestimate my ability to write buggy (inet6?) code ;-) It is very likely a bug in smtpd, and the fact that it also happens when you specify the literal ipv6 address excludes the asynchronous resolver. I'll investigate this and let you know when I have a diff you can test. Thanks for the quick reply -- I'll stay tuned. :o) Stefan
[PATCH] chat(8) manpage clarification
Hi! I've recently tried debugging a pppd(8) connection and noticed that the information in the chat(8) manpage was a little imprecise with regard to how logging is done. According to chat.c (lines 304 onward, from 4.9-release), it will log using facility LOCAL2 and level WARNING. If -v is specified, it will also log up to level INFO. I think it might be useful to include this information in the manpage as well; see patch below. Regards, s//un Index: chat/chat.8 === RCS file: /cvs/src/usr.sbin/pppd/chat/chat.8,v retrieving revision 1.18 diff -u -r1.18 chat.8 --- chat/chat.8 28 Oct 2010 18:34:44 - 1.18 +++ chat/chat.8 25 Jul 2011 15:08:18 - @@ -58,8 +58,12 @@ .It Fl S Do not use .Xr syslog 3 . -By default, error messages are logged via -.Xr syslog 3 . +By default, error messages are logged through +.Xr syslog 3 +with facility +.Ar local2 +and level +.Ar warning . The use of .Fl S will prevent both log messages from @@ -110,8 +114,10 @@ .Nm program will then log the execution state of the chat script as well as all text received from the modem and the output strings sent to the modem. -The default is to log via -.Xr syslog 3 ; +The default is to log through +.Xr syslog 3 +with level +.Ar info ; the logging method may be altered with the .Fl S and [demime 1.01d removed an attachment of type application/pgp-signature]
Patching kernel to work around buggy ACPI BIOS
* Stefan Unterweger on Tue, May 04, 2010 at 12:43:22AM +0200: As far as I understood from some ancient [FreeBSD] mailinglist threads, in theory it should be possible to somehow do something such that the kernel loads patched ACPI tables which have those particular bugs corrected. Finally I've found that particular post again, and have been able to fix the broken DSDT to some extent. With some dirty patchwork acpi_load_dsdt now loads my custom table, and `shutdown -p -h` succeeds in turning off the machine, without any more warnings. A few questions'd remain, though: - I don't suppose that there would be some official point in the ACPI driver where such workarounds would belong? The code looks clear enough to me, but I speak neither enough C nor ACPI to be sure... - The patch seems almost too easy to me, but I'm not yet made that much progress in learning C. With all that memcpy going around, I have the uneasy feeling that I might be introducing some nasty memory holes... The patch is against 4.6-release, since that's the version I was planning to put on the machine. Regards, s//un --- acpi.c.orig Tue May 11 18:07:10 2010 +++ acpi.c Tue May 11 17:59:56 2010 @@ -48,6 +48,8 @@ #define APMDEV_NORMAL 0 #define APMDEV_CTL 8 +#include custom_dsdt.h + #ifdef ACPI_DEBUG int acpi_debug = 16; #endif @@ -889,6 +891,11 @@ } memcpy((*dsdt)-q_data, handle.va, len); (*dsdt)-q_table = (*dsdt)-q_data; + + /* 5AEb+sk: Override the Tyan Tiger S2466's corrupt DSDT */ + printf(Trying to override broken DSDT table...\n); + (*dsdt)-q_table = (struct acpi_table_header *)AmlCode; + acpi_unmap(handle); } }
Re: Trying to set diskless(8) -- hanging in RPC timeout for server
* Fred Crowson on Tue, May 11, 2010 at 10:43:09PM +0100:
What does your dhcpd.conf look like on your server?
I have several subnets served via DHCP, so I have reported only
the relevant one together with the global options:
| server-name Neu-Sorpigal;
| option domain-name intranet.aleturo.com;
| default-lease-time 86400;
|
| shared-network wired {
| option domain-name wired.intranet.aleturo.com;
| option domain-name-servers 172.23.12.2;
| option netbios-name-servers 172.23.12.2;
| option routers 172.23.12.2;
|
| filename pxeboot;
| next-server 172.23.12.2;
| option root-path /export/client/;
|
| subnet 172.23.0.0 netmask 255.255.0.0 {
| allow unknown-clients;
| range 172.23.13.128 172.23.13.254;
| }
| }
I've added the options next-server and root-path just now,
since I've seen mention of it in pxeboot(8). Prior to that, only
the filename directive was there. Everything else however,
including the tcpdumps, is not impressed by that.
It might be worth having -vv and -X on your tcpdump it might provide
more info as to the problem.
I didn't include the dump from phase 2, where pxeboot and the
kernel are served by tftp and whatelse, since that's an insane
amount of data. This tcpdump was started just before the kernel
tried to connect to NFS, that is, before the second burst.
| $ tcpdump -X -vv -n -s 160 -i em0 host 172.23.13.138
| tcpdump: listening on em0, link-type EN10MB
| 00:19:48.612571 rarp reply 00:00:e2:87:e8:76 at 172.23.13.138
| : 0001 0800 0604 0004 000e 0c06 be26 ac17 ,.
| 0010: 0c02 e287 e876 ac17 0d8ab.hv,...
|
| 00:19:48.613207 arp who-has 172.23.13.138 tell 172.23.13.138
| : 0001 0800 0604 0001 e287 e876 ac17 ..b.hv,.
| 0010: 0d8a ac17 0d8a ,...
| 0020: ..
|
| 00:19:48.630322 172.23.13.138.718 172.23.255.255.111: [udp sum ok] udp 96
(ttl 64, id 65499, len 124)
| : 4500 007c ffdb 4011 14dd ac17 0d8a E..|...@..],...
| 0010: ac17 02ce 006f 0068 eac4 90ad 0bca ,..N.o.hjD.-.J
| 0020: 0002 0001 86a0 0002 ...
| 0030: 0005 0001 0014
| 0040:
| 0050: 0001 86ba 0001 ...:
| 0060: 0001 0014 0001 00ac ...,
| 0070: 0017 000d 008a
|
| 00:19:49.620480 172.23.13.138.718 172.23.255.255.111: [udp sum ok] udp 96
(ttl 64, id 60019, len 124)
| : 4500 007c ea73 4011 2a45 ac17 0d8a E..|j...@.*e,...
| 0010: ac17 02ce 006f 0068 eac4 90ad 0bca ,..N.o.hjD.-.J
| 0020: 0002 0001 86a0 0002 ...
| 0030: 0005 0001 0014
| 0040:
| 0050: 0001 86ba 0001 ...:
| 0060: 0001 0014 0001 00ac ...,
| 0070: 0017 000d 008a
|
| 00:19:51.620513 172.23.13.138.718 172.23.255.255.111: [udp sum ok] udp 96
(ttl 64, id 63711, len 124)
| : 4500 007c f8df 4011 1bd9 ac17 0d8a E..|x...@..y,...
| 0010: ac17 02ce 006f 0068 eac4 90ad 0bca ,..N.o.hjD.-.J
| 0020: 0002 0001 86a0 0002 ...
| 0030: 0005 0001 0014
| 0040:
| 0050: 0001 86ba 0001 ...:
| 0060: 0001 0014 0001 00ac ...,
| 0070: 0017 000d 008a
|
| 00:19:54.620566 172.23.13.138.718 172.23.255.255.111: [udp sum ok] udp 96
(ttl 64, id 635, len 124)
| : 4500 007c 027b 4011 123e ac17 0d8a E..|@..,...
| 0010: ac17 02ce 006f 0068 eac4 90ad 0bca ,..N.o.hjD.-.J
| 0020: 0002 0001 86a0 0002 ...
| 0030: 0005 0001 0014
| 0040:
| 0050: 0001 86ba 0001 ...:
| 0060: 0001 0014 0001 00ac ...,
| 0070: 0017 000d 008a
|
| 00:19:58.620632 172.23.13.138.718 172.23.255.255.111: [udp sum ok] udp 96
(ttl 64, id 40174, len 124)
| : 4500 007c 9cee 4011 77ca ac17 0d8a E..|@.wj,...
| 0010: ac17 02ce 006f 0068 eac4 90ad 0bca ,..N.o.hjD.-.J
| 0020: 0002 0001 86a0 0002 ...
| 0030: 0005 0001 0014
| 0040:
| 0050: 0001
Trying to set diskless(8) -- hanging in RPC timeout for server
Hello! I'm trying to set up my server for diskless boots, as described in the diskless(8) manpage (at the moment, more or less mostly as an academic exercise, but I was planning to take my oldish laptops to some use this way). I went along the instructions from the manpage, setting up the various pieces as I was instructed; since I was already running a limited PXE boot environment so that I can do installs more rapidly, many of the steps were already done, having to setup only rarpd and nfs. However, when I now try to get the client actually to boot from this setup, it fails quite miserably when trying to mount the root filesystem via NFS. The kernel just hangs forever, printing RPC timeout for server 172.23.255.255 (0xac17) prog 10. After some research, I came up with an old posting from misc (http://archives.neohapsis.com/archives/openbsd/2004-01/0603.html), but without any solution. The problem described there is quite similar to the one I'm experiencing here, but without all the peculiarities that were used there (i.e., I'm using a stock 4.6-release, stock-dhcpd, stock-everything). Especially, my client does the same thing as the Soekris in that old posting, i.e. trying to connect to the NFS server at the broadcast address 172.23.255.255, instead of 172.23.12.2, which would be the real public address of the server. It _does_ connect to 172.23.12.2 on the original PXE bootstrap, but that might as well be because dhcpd tells it to do so, as far as I understood the process. Since the server also runs some other services, pf is running, which I first guessed might be the culprit. However, even with pass quick for everything coming from the particular client, nothing changes. tcpdump on the pflog-interface shows the sunrpc packets to be allowed, so I don't think that it is a PF issue. Disabling PF didn't change anything, for that matter. rpcinfo(8) shows everything up and running: | % rpcinfo -p |program vers proto port | 102 tcp111 portmapper | 102 udp111 portmapper | 132 udp 2049 nfs | 133 udp 2049 nfs | 132 tcp 2049 nfs | 133 tcp 2049 nfs | 1000210 udp759 nlockmgr | 1000211 udp759 nlockmgr | 1000213 udp759 nlockmgr | 1000214 udp759 nlockmgr | 1000211 tcp776 nlockmgr | 1000213 tcp776 nlockmgr | 1000214 tcp776 nlockmgr | 1000241 udp992 status | 1000241 tcp726 status | 151 udp994 mountd | 153 udp994 mountd | 151 tcp 1011 mountd | 153 tcp 1011 mountd Especially the portmapper itself, as this one seems to be the service that the client seems unable to find. Or at least, that's how I interpret the prog 10 which scrolls continuously on the client's error message. I have already tried to have tcpdump have a look at what's going on, but unfortunately, I don't see very much in its output: | $ tcpdump -n -s 140 -i em0 host 172.23.13.138 | tcpdump: listening on em0, link-type EN10MB | 01:29:31.853178 172.23.13.138.718 172.23.255.255.111: udp 96 | 01:29:36.853392 172.23.13.138.718 172.23.255.255.111: udp 96 | 01:29:41.853479 172.23.13.138.718 172.23.255.255.111: udp 96 (ad infinitum) As far as I see it, the client sends some UDP packet to the portmapper, but does not get any response. Since it looks like a RPC/NFS issue, I tried to see if normal NFS access would yield similar issues, so I had the same client try to connect from some Linux livecd thingie. This succeeded on the first try---hence, NFS seems to work, at least in general. However, the straightforward nfs mount did connect using 172.23.13.2 (i.e., the real address of the server), not the broadcast address. Trying to do a mount to 172.23.255.255:/export/client resulted in an error message, namely Network is unreachable, but no blip comes up at the tcpdump above which was still running at this time, so it might as well have been Linux who won't allow to connect NFS on the broadcast address. The previously mentioned old mailinglist posting mentioned that rpc.bootparamd'd be needed, but starting it or not does not make any difference (and http://www.netbsd.org/docs/network/netboot/intro.i386.html kind of implies that rpc.bootparamd is not needed on i386, and the manpage actively discourages it). I'm now quite at a loss now, and don't know where to look anymore. I'm sure it's just some small thing that I'm still overlooking, or some interoperatibility issue with some parts of that setup, but I don't know where to look anymore. Thanks in advance for any hints, or for just having the patience to read through to the end. :o) s//un
Re: Kernel panic on shutdown -p -- ACPI problem?
* Mike Larkin on Wed, May 05, 2010 at 09:04:06PM -0700:
If you haven't sent an acpidump yet, send it over.
/*
RSD PTR: Checksum=20, OEMID=PTLTD, RsdtAddress=0x3fefcf28
*/
/*
RSDT: Length=44, Revision=1, Checksum=13,
OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x3fefef2e, 0x3fefefa2 }
*/
/*
DSDT=0x3fefcf54
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0x802f, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8004-0x8005
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x8020-0x8023
P_LVL2_LAT=101ms, P_LVL3_LAT=1001ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,PROC_C1}
*/
/*
DSDT: Length=8154, Revision=1, Checksum=247,
OEMID=AMD, OEM Table ID=AMDACPI, OEM Revision=0x604,
Creator ID=MSFT, Creator Revision=0x10d
*/
DefinitionBlock (
acpi_dsdt.aml,//Output filename
DSDT, //Signature
0x1,//DSDT Revision
AMD, //OEMID
AMDACPI, //TABLE ID
0x604 //OEM Revision
)
{
Scope(\_PR_) {
Processor(CPU0, 0, 0x8010, 0x6) {
}
Processor(CPU1, 1, 0x0, 0x0) {
}
}
Name(\_S0_, Package(0x4) {
0x0,
0x0,
0x0,
0x0,
})
Name(\_S1_, Package(0x4) {
0x1,
0x1,
0x1,
0x1,
})
Name(\_S4_, Package(0x4) {
0x6,
0x6,
0x6,
0x6,
})
Name(\_S5_, Package(0x4) {
0x7,
0x7,
0x7,
0x7,
})
Name(OSFL, 0x0)
Method(STRC, 2) {
If(LNot(LEqual(SizeOf(Arg0), SizeOf(Arg1 {
Return(0x0)
}
Add(SizeOf(Arg0), 0x1, Local0)
Name(BUF0, Buffer(Local0) { })
Name(BUF1, Buffer(Local0) { })
Store(Arg0, BUF0)
Store(Arg1, BUF1)
While(Local0) {
Decrement(Local0)
If(LNot(LEqual(DerefOf(Index(BUF0, Local0)), DerefOf(Index(BUF1,
Local0) {
Return(Zero)
}
}
Return(One)
}
OperationRegion(\DEBG, SystemIO, 0x80, 0x1)
Field(\DEBG, ByteAcc, NoLock, Preserve) {
DBG1, 8
}
OperationRegion(KBC_, SystemIO, 0x64, 0x1)
Field(KBC_, ByteAcc, NoLock, Preserve) {
KCMD, 8
}
OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10)
Field(EXTM, WordAcc, NoLock, Preserve) {
ROM1, 16,
RMS1, 16,
ROM2, 16,
RMS2, 16,
ROM3, 16,
RMS3, 16,
AMEM, 32
}
OperationRegion(VGAM, SystemMemory, 0x000c0002, 0x1)
Field(VGAM, ByteAcc, Lock, Preserve) {
VGA1, 8
}
OperationRegion(GRAM, SystemMemory, 0x0400, 0x0100)
Field(GRAM, ByteAcc, Lock, Preserve) {
Offset(0x10),
FLG0, 8
}
OperationRegion(ELCR, SystemIO, 0x04d0, 0x2)
Field(ELCR, ByteAcc, NoLock, Preserve) {
ELC1, 8,
ELC2, 8
}
OperationRegion(\PSC_, SystemIO, 0x8027, 0x1)
Field(\PSC_, ByteAcc, NoLock, Preserve) {
PSCC, 8
}
OperationRegion(\STUS, SystemIO, 0x8028, 0x1)
Field(\STUS, ByteAcc, NoLock, Preserve) {
G_ST, 8
}
OperationRegion(\STUB, SystemIO, 0x8029, 0x1)
Field(\STUB, ByteAcc, NoLock, Preserve) {
G_SB, 8
}
OperationRegion(\SMIC, SystemIO, 0x802f, 0x1)
Field(\SMIC, ByteAcc, NoLock, Preserve) {
SCP_, 8
}
OperationRegion(\OPS0, SystemIO, 0x21, 0x1)
Field(\OPS0, ByteAcc, NoLock, Preserve) {
IMR0, 8
}
OperationRegion(\OPS1, SystemIO, 0xa1, 0x1)
Field(\OPS1, ByteAcc, NoLock, Preserve) {
IMR1, 8
}
OperationRegion(\GSE_, SystemIO, 0x802a, 0x1)
Field(\GSE_, ByteAcc, NoLock, Preserve) {
IRQR, 8
}
OperationRegion(\FANC, SystemIO, 0x80f8, 0x2)
Field(\FANC, ByteAcc, NoLock, Preserve) {
FAN0, 8,
FAN1, 8
}
OperationRegion(\PM21, SystemIO, 0x8021, 0x1)
Field(\PM21, ByteAcc, NoLock, Preserve) {
IO21, 8
}
OperationRegion(\PM23, SystemIO, 0x8023, 0x1)
Field(\PM23, ByteAcc, NoLock, Preserve) {
IO23, 8
}
OperationRegion(\GP1_, SystemIO, 0x80c0, 0x20)
Field(\GP1_, ByteAcc, NoLock, Preserve) {
GP00, 8,
GP01, 8,
GP02, 8,
GP03, 8,
GP04, 8,
GP05, 8,
GP06, 8,
GP07, 8,
GP08, 8,
GP09, 8,
GP10, 8,
GP11, 8,
GP12, 8,
GP13, 8,
GP14, 8,
GP15, 8,
GP16, 8,
GP17, 8,
GP18, 8,
GP19, 8,
GP20, 8,
GP21, 8,
GP22, 8,
GP23, 8,
GP24, 8,
GP25, 8,
GP26, 8,
GP27, 8,
GP28, 8,
GP29, 8,
GP30, 8,
GP31, 8
}
Name(PICF, 0x0)
Method(_PIC, 1) {
Store(Arg0, PICF)
}
Scope(\) {
Method(DISD, 1) {
Store(Local0, Local0)
}
Method(CKIO, 2) {
Store(Local0, Local0)
}
Method(SLDM, 2) {
Store(Local0, Local0)
}
}
Scope(_GPE) {
Method(_L08) {
Re: Kernel panic on shutdown -p -- ACPI problem?
* Aaron Mason on Tue, May 04, 2010 at 08:48:05PM +1000:
When you get it out again, we'll also need to see an acpidump output.
Here is the output of both acpidump(8) and dmesg(8).
s//un
-8-8-8-8-8-8-8-8-
/*
RSD PTR: Checksum=20, OEMID=PTLTD, RsdtAddress=0x3fefcf28
*/
/*
RSDT: Length=44, Revision=1, Checksum=13,
OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x3fefef2e, 0x3fefefa2 }
*/
/*
DSDT=0x3fefcf54
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0x802f, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8004-0x8005
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x8020-0x8023
P_LVL2_LAT=101ms, P_LVL3_LAT=1001ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,PROC_C1}
*/
/*
DSDT: Length=8154, Revision=1, Checksum=247,
OEMID=AMD, OEM Table ID=AMDACPI, OEM Revision=0x604,
Creator ID=MSFT, Creator Revision=0x10d
*/
DefinitionBlock (
acpi_dsdt.aml,//Output filename
DSDT, //Signature
0x1,//DSDT Revision
AMD, //OEMID
AMDACPI, //TABLE ID
0x604 //OEM Revision
)
{
Scope(\_PR_) {
Processor(CPU0, 0, 0x8010, 0x6) {
}
Processor(CPU1, 1, 0x0, 0x0) {
}
}
Name(\_S0_, Package(0x4) {
0x0,
0x0,
0x0,
0x0,
})
Name(\_S1_, Package(0x4) {
0x1,
0x1,
0x1,
0x1,
})
Name(\_S4_, Package(0x4) {
0x6,
0x6,
0x6,
0x6,
})
Name(\_S5_, Package(0x4) {
0x7,
0x7,
0x7,
0x7,
})
Name(OSFL, 0x0)
Method(STRC, 2) {
If(LNot(LEqual(SizeOf(Arg0), SizeOf(Arg1 {
Return(0x0)
}
Add(SizeOf(Arg0), 0x1, Local0)
Name(BUF0, Buffer(Local0) { })
Name(BUF1, Buffer(Local0) { })
Store(Arg0, BUF0)
Store(Arg1, BUF1)
While(Local0) {
Decrement(Local0)
If(LNot(LEqual(DerefOf(Index(BUF0, Local0)), DerefOf(Index(BUF1,
Local0) {
Return(Zero)
}
}
Return(One)
}
OperationRegion(\DEBG, SystemIO, 0x80, 0x1)
Field(\DEBG, ByteAcc, NoLock, Preserve) {
DBG1, 8
}
OperationRegion(KBC_, SystemIO, 0x64, 0x1)
Field(KBC_, ByteAcc, NoLock, Preserve) {
KCMD, 8
}
OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10)
Field(EXTM, WordAcc, NoLock, Preserve) {
ROM1, 16,
RMS1, 16,
ROM2, 16,
RMS2, 16,
ROM3, 16,
RMS3, 16,
AMEM, 32
}
OperationRegion(VGAM, SystemMemory, 0x000c0002, 0x1)
Field(VGAM, ByteAcc, Lock, Preserve) {
VGA1, 8
}
OperationRegion(GRAM, SystemMemory, 0x0400, 0x0100)
Field(GRAM, ByteAcc, Lock, Preserve) {
Offset(0x10),
FLG0, 8
}
OperationRegion(ELCR, SystemIO, 0x04d0, 0x2)
Field(ELCR, ByteAcc, NoLock, Preserve) {
ELC1, 8,
ELC2, 8
}
OperationRegion(\PSC_, SystemIO, 0x8027, 0x1)
Field(\PSC_, ByteAcc, NoLock, Preserve) {
PSCC, 8
}
OperationRegion(\STUS, SystemIO, 0x8028, 0x1)
Field(\STUS, ByteAcc, NoLock, Preserve) {
G_ST, 8
}
OperationRegion(\STUB, SystemIO, 0x8029, 0x1)
Field(\STUB, ByteAcc, NoLock, Preserve) {
G_SB, 8
}
OperationRegion(\SMIC, SystemIO, 0x802f, 0x1)
Field(\SMIC, ByteAcc, NoLock, Preserve) {
SCP_, 8
}
OperationRegion(\OPS0, SystemIO, 0x21, 0x1)
Field(\OPS0, ByteAcc, NoLock, Preserve) {
IMR0, 8
}
OperationRegion(\OPS1, SystemIO, 0xa1, 0x1)
Field(\OPS1, ByteAcc, NoLock, Preserve) {
IMR1, 8
}
OperationRegion(\GSE_, SystemIO, 0x802a, 0x1)
Field(\GSE_, ByteAcc, NoLock, Preserve) {
IRQR, 8
}
OperationRegion(\FANC, SystemIO, 0x80f8, 0x2)
Field(\FANC, ByteAcc, NoLock, Preserve) {
FAN0, 8,
FAN1, 8
}
OperationRegion(\PM21, SystemIO, 0x8021, 0x1)
Field(\PM21, ByteAcc, NoLock, Preserve) {
IO21, 8
}
OperationRegion(\PM23, SystemIO, 0x8023, 0x1)
Field(\PM23, ByteAcc, NoLock, Preserve) {
IO23, 8
}
OperationRegion(\GP1_, SystemIO, 0x80c0, 0x20)
Field(\GP1_, ByteAcc, NoLock, Preserve) {
GP00, 8,
GP01, 8,
GP02, 8,
GP03, 8,
GP04, 8,
GP05, 8,
GP06, 8,
GP07, 8,
GP08, 8,
GP09, 8,
GP10, 8,
GP11, 8,
GP12, 8,
GP13, 8,
GP14, 8,
GP15, 8,
GP16, 8,
GP17, 8,
GP18, 8,
GP19, 8,
GP20, 8,
GP21, 8,
GP22, 8,
GP23, 8,
GP24, 8,
GP25, 8,
GP26, 8,
GP27, 8,
GP28, 8,
GP29, 8,
GP30, 8,
GP31, 8
}
Name(PICF, 0x0)
Method(_PIC, 1) {
Store(Arg0, PICF)
}
Scope(\) {
Method(DISD, 1) {
Store(Local0, Local0)
}
Method(CKIO, 2) {
Re: Kernel panic on shutdown -p -- ACPI problem?
* Jan Stary on Tue, May 04, 2010 at 08:31:10AM +0200: I've done some research, and it turns out that the motherboard seems to a particularly buggy ACPI tables. And just as well, if I disable ACPI, the kernel panic vanishes. However, the machine doesn't get turned off as well, so it's not really a victory. All this was done using 4.6 release, as this was a few months ago. Have you also tried with current? The download went surprisingly fast (and the install even moreso; big thanks at this point for the folks who did the installer, it seems rare that one can install an operating system in five minutes). Running the April 28 snapshot which I just grabbed from FTP this instant doesn't change a thing---as expected, I get the same AML PARSE ERROR kernel panic. Here's a pseudo-diff from the previous dmesg to the 4.7-current one, other than the vscsi stuff nothing changes: -8-8-8-8-8-8-8-8- -OpenBSD 4.6 (GENERIC.MP) #89: Thu Jul 9 21:32:39 MDT 2009 +OpenBSD 4.7-current (GENERIC.MP) #560: Wed Apr 28 11:55:01 MDT 2010 -avail mem = 1027940352 (980MB) +avail mem = 1028833280 (981MB) +vscsi0 at root +scsibus1 at vscsi0: 256 targets -8-8-8-8-8-8-8-8- acpidump(8) gives exactly the same result (well, as expected; the ACPI tables didn't change, after all...). s//un
Kernel panic on shutdown -p -- ACPI problem?
Hello!
I've recently rediscovered a computer that I'd been using as a
Linux fileserver a few years ago. Since it's hardware is
considerably better than the even older machine I'm using now as
an OpenBSD fileserver, I tried if I could make it run.
In principle, everything works fine, to some extent much smoother
than on Linux (especially getting the sensors to work back then
was a true nightmare, and I eventually gave up in defeat -- on
OpenBSD, they just work).
However, if I do `shutdown -h -p` (thus power off), I get a
kernel panic; specifically, AML PARSE ERROR (see below). This
only happens when doing '-p' is involved somehow; rebooting
works, and just '-h' without '-p' does, too.
I've done some research, and it turns out that the motherboard
seems to a particularly buggy ACPI tables. And just as well, if I
disable ACPI, the kernel panic vanishes. However, the machine
doesn't get turned off as well, so it's not really a victory.
All this was done using 4.6 release, as this was a few months
ago.
Before I do any further research or experiments with that
machine, I just wanted to ask if I'd have any chances to work
against this problems. As far as I understood from some ancient
NetBSD mailinglist threads, in theory it should be possible
to somehow do something such that the kernel loads patched ACPI
tables which have those particular bugs corrected. So, if this
would be possible on OpenBSD, I knew that I should spend some
more time on this, without it being wasted.
The motherboard in question is a Tyan Tiger S2466 dual-Athon
multiprocessor board, with both processor sockets filled. As
already said, not the most recent of mainboard imaginable, so I
don't think that trying 4.7 would be much difference, especially
as it seems that the bug is in the BIOS, not in OpenBSD.
If anyone has a pointer---a no, it won't work would be more
than helpful, too---, I'd be grateful. If I could get that thing
to work again, my poor student's budget would be saved yet
another expense. ;o)
Regards,
Stefan
Here is the kernel panic that I've recorded from the machine.
Unfortunately, I've lost the dmesg that I thought I had prepared;
if there _is_ a chance to make this work, I'll post it as soon as
I again have some floor space to set it up again.
| syscing disks... done
| ### AML PARSE ERROR (0x455): Undefined name: IO2B
| multiply freed item 0xd1d62b00
| panic: free: duplicated free
| Stopped at Debugger+0x4:leave
|
| ddb{0} trace
| Debugger(d0825e18,8,dc247d60,d1d62b00,21) at Debugger+0x4
| panic(d0717761,d1d62b00,dc247de0,d06ce12b,40) at panic+0x55
| free(d1d62b00,21,3f9,0) at free+0x40
| aml_freevalue(d1d62c44,d0817227,75d) at aml_freevalue+0xdb
| aml_xpopscope(d1d62c44,54,d0817578,d1c06504,dc247eac) at aml_xpopscope+0x81
| aml_xeval(0,d1c06504,74,1,dc247e78,dc247e72,dc247e90,d04c8555) at
aml_xeval+0x13f
| aml_evalnode(d1bfec00,d1c06544,1,dc247e78,0,1,dc247ea0,d06c90c7) at
aml_evalnode+0x57
| acpi_prepare_sleep_state(d1bfec00,5,dc247f00,d04ab607) at
acpi_prepare_sleep_state+0xfa
| acpi_powerdown(d0944b60,d6a62420,dc247f20,d035f7f8,1008) at
acpi_powerdown+0x22
| boot(1009,0,0,0,d0824a34) at boot+0x190
| __stack_smash_handler(d6a62420,dc247f68,dc247f58,d6a62420) at
__stack_smash_handler
| syscall() at syscall+0x12b
| --- syscall (number 55) ---
| 0x1c000a59:
|
| ddb{0} ps
| PIDPPID PGRP UID S FLAGS WAITCOMMAND
| *11147 111147 0 7 0x42004000 halt
| 15 00 0 3 0x2100200 bored crypto
| 14 00 0 3 0x2100200 aiodonedaiodonec
| 13 00 0 3 0x2100200 syncer update
| 12 00 0 3 0x2100200 cleaner cleaner
| 11 00 0 3 0x100200reaper reaper
| 10 00 0 3 0x2100200 pgdaemonpagedaemon
| 9 00 0 3 0x2100200 pftmpfpurge
| 8 00 0 3 0x2100200 usbtsk usbtask
| 7 00 0 3 0x2100200 usbevt usb0
| 6 00 0 3 0x2100200 acpi_idle acpi0
| 5 00 0 7 0x40100200 idle1
| 4 00 0 3 0x2100200 bored syswq
| 3 00 0 3 0x40100200 idle0
| 2 00 0 3 0x2100200 kmalloc kmthread
| 1 01 0 3 0x2004080 waitinit
| 0 -1 0 0 3 0x2080200 scheduler swapper
ntpd dies on startup if using -s option
Hello! I have noticed a rather curious behaviour of ntpd on startup. I recently started setting the '-s' option to ntpd in rc.conf.local on my machines. The sloppy hardware clocks on those machines combined with the lack of any kind of USV often leads to several minutes of clock skey on reboot (they are supposed to run 24/7, so unless I do an upgrade every reboot is unclean). Some services depend on accurate time synchronization, so they won't come up again after reboot. Thus the '-s'. As far as I understood from the manpage, it's supposed to set the clock immediately on invocation and store it back into the hardware clock, and according to my tests it just does that. Unless it is supposed to to that on boot, read: when invoked from rc(8). Watching the console, I see that ntpd fails to stay up and throws up on my feet (without having set the clock, of course). /var/log/daemon has the following to say: | Jun 17 07:38:26 knoedel ntpd[17639]: ntp engine ready | Jun 17 07:38:26 knoedel ntpd[17639]: fatal: recvfrom: Protocol not available | Jun 17 07:38:26 knoedel ntpd[27003]: dispatch_imsg in main: pipe closed (I did set a bogus time into the hardware clock on purpose to see if this would work.) If I issue 'ntpd -s' after boot has completed, everything runs fine; same thing if I run ntpd from rc.local, but somehow this feels unclean. intro(2) says the following about the error message: 42 ENOPROTOOPT Protocol not available. A bad option or level was specified in a getsockopt(2) or setsockopt(2) call. But I am not enough of a programmer to make sense of this description. Is this some kind of bug, or am I simply trying to do something that is not supposed to be done this way? Thanks for any advice, s//un
Re: ntpd dies on startup if using -s option
Sorry, I have been too fast to post: The machine in question I have been testing this with is running 4.5 release. Running `ntpd -s` from rc.local does *not* work (I must have misread the log the first time, now it defitinely does not work) -- I actually have to wait until rc is done and I can login manually until it works. s//un
re-writing RAIDframe parity asynchronously?
Hello! I am using RAIDframe (using RAID 1) on 4.5 release, and am quite satisfied with it. After an unclean shutdown, the parity status of the array expectedly shows DIRTY; the documentation (and common sense) strongly suggests that the parity be re-written as soon as possible, if the RAID shall remain of any use. Appropriately, rc(8) calls `raidctl -P all` on boot, thus automatically initializing the rewrite if necessary. Unfortunately, this process takes several hours, and rc patiently waits until raidctl returns -- only *then* continuing with fsck and so on. If I interrupt (^C) at this point, the re-writing does not stop, but transparently continues in the background (as I have read somewhere in the documentation but did not find again). rc then goes on as usual, fscking and booting and everything is fine. Most of the machines have no kind of USV (since those are deemed too expensive by the people responsible... :o/), but taking half a day to come up again after a power outage is simply too long. I am considering patching rc(8) and commenting out the `raidctl -P all` line, and running it via cron(8) at @reboot, but this seems like a hack to me. So before I venture that way, I'd rather make sure I didn't overlook a switch or option or anything of the like that would make `raidctl -P` return immediately while continuing the rewriting in the background, so that rc would continue it's work. Any hints? s//un
Re: ntpd dies on startup if using -s option
* Alexander Hall on Wed, Jun 17, 2009 at 10:40:58AM +0200: What is your network setup? The network setup is rather simple: | lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33160 | priority: 0 | groups: lo | inet 127.0.0.1 netmask 0xff00 | inet6 ::1 prefixlen 128 | inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 | em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | lladdr 00:0f:fe:de:59:49 | priority: 0 | groups: egress | media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) | status: active | inet6 fe80::20f:feff:fede:5949%em0 prefixlen 64 scopeid 0x1 | inet 10.13.130.58 netmask 0xff00 broadcast 10.13.130.255 | inet6 2001:1418:16b:0:20f:feff:fede:5949 prefixlen 64 autoconf pltime 604684 vltime 2591884 | enc0: flags=0 mtu 1536 | priority: 0 Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. any special kernel config? I have activated RAIDframe; other than that, the kernel is pure (see config file below). | include arch/amd64/conf/GENERIC.MP | pseudo-device raid | option RAID_AUTOCONFIG The system I have been testing this with is almost bare; other than vim and zsh there is next to nothing on it. dmesg too. | OpenBSD 4.5 (GENERIC.RAID) #0: Mon May 18 10:55:01 CEST 2009 | r...@kriegspire.rg-me.schule.suedtirol.it:/usr/src/sys/arch/amd64/compile/GENERIC.RAID | real mem = 2098917376 (2001MB) | avail mem = 2025533440 (1931MB) | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xea0c0 (77 entries) | bios0: vendor Hewlett-Packard version 786F1 v01.26 date 07/31/2008 | bios0: Hewlett-Packard HP Compaq dc7800p Convertible Minitower | acpi0 at bios0: rev 0 | acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR | acpi0: wakeup devices COM1(S4) COM2(S4) PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) EUS2(S3) PBTN(S4) | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.89 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,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG | cpu0: 6MB 64b/line 16-way L2 cache | cpu0: apic clock running at 332MHz | cpu1 at mainbus0: apid 1 (application processor) | cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.50 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,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG | cpu1: 6MB 64b/line 16-way L2 cache | ioapic0 at mainbus0 apid 1 pa 0xfec0, version 20, 24 pins | ioapic0: misconfigured as apic 0, remapped to apid 1 | acpihpet0 at acpi0: 14318179 Hz | acpiprt0 at acpi0: bus 0 (PCI0) | acpiprt1 at acpi0: bus -1 (PEG1) | acpiprt2 at acpi0: bus -1 (PEG2) | acpiprt3 at acpi0: bus 32 (PCX1) | acpiprt4 at acpi0: bus 48 (PCX2) | acpiprt5 at acpi0: bus -1 (PCX5) | acpiprt6 at acpi0: bus -1 (PCX6) | acpiprt7 at acpi0: bus 7 (HUB_) | acpicpu0 at acpi0: C2 | acpicpu1 at acpi0: C2 | acpibtn0 at acpi0: PBTN | cpu0: unknown Enhanced SpeedStep CPU, msr 0x061a092206000922 | cpu0: using only highest and lowest power states | cpu0: Enhanced SpeedStep 3000 MHz (1244 mV): speeds: 3000, 2000 MHz | pci0 at mainbus0 bus 0: configuration mode 1 | pchb0 at pci0 dev 0 function 0 Intel 82Q35 Host rev 0x02 | vga1 at pci0 dev 2 function 0 Intel 82Q35 Video rev 0x02 | wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) | wsdisplay0: screen 1-5 added (80x25, vt100 emulation) | intagp0 at vga1 | agp0 at intagp0: aperture at 0xe000, size 0x1000 | inteldrm0 at vga1: apic 1 int 16 (irq 5) | drm0 at inteldrm0 | Intel 82Q35 Video rev 0x02 at pci0 dev 2 function 1 not configured | Intel 82Q35 HECI rev 0x02 at pci0 dev 3 function 0 not configured | pciide0 at pci0 dev 3 function 2 Intel 82Q35 PT IDER rev 0x02: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI | pciide0: using apic 1 int 18 (irq 10) for native-PCI interrupt | pciide0: channel 0 ignored (not responding; disabled or no drives?) | pciide0: channel 1 ignored (not responding; disabled or no drives?) | Intel 82Q35 KT rev 0x02 at pci0 dev 3 function 3 not configured | em0 at pci0 dev 25 function 0 Intel ICH9 IGP AMT rev 0x02: apic 1 int 19 (irq 5), address 00:0f:fe:de:59:49 | uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x02: apic 1 int 20 (irq 10) | uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x02: apic 1 int 21 (irq 11) | ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x02: apic 1 int 22 (irq 5) | usb0 at ehci0: USB revision 2.0 | uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 | azalia0 at pci0 dev 27 function 0
Re: ntpd dies on startup if using -s option
* Alexander Hall on Wed, Jun 17, 2009 at 11:20:25AM +0200: Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Ah. Sure sounds like this could be an IPv6 issue. That's not at all my turf though, so let's hope someone more knowledgeable in that area chimes in. Now that you mentioned it, it does indeed seem like an IPv6 issue. I have set up ntpd to sync via pool.ntp.org and ntp.eu.sixxs.org. If I comment out the latter entry (or if there is no IPv6 connectivity at boot), the problem is no more... Not that it should matter here, but just for the record; Don't claim that your system is running 4.5-release when it clearly is not since you modified the kernel. Sorry, you're of course right. What I tried to say was that I am using the system as from the CDs, with the said customized kernel. s//un
Re: re-writing RAIDframe parity asynchronously?
* Raimo Niskanen on Wed, Jun 17, 2009 at 03:55:00PM +0200: I'm not sure that I understand you correctly, and don't want to make a statement about the merit of having raidctl running in the background while already operating again, but what about having raidctl -P all in /etc/rc? IIRC that works just fine if you are willing to take the risk of getting a broken raid in the event of a crash / power outage during the backgrounded parity re-write. To be honest, I didn't yet think that far... :o) For clarity: Assuming that the first crash already did happen, and raidctl is happily rewriting it's parity data (in the foreground, while rc(8) waits for it), and the second crash strikes at *this* moment, won't the RAID be broken nonetheless, be it already operating or not? s//un
Re: ntpd dies on startup if using -s option
* Paul de Weerd on Wed, Jun 17, 2009 at 11:34:38AM +0200: Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Is (one of) your ntp server(s) v6 only ? Do you have rtsol in your /etc/hostname.em0 ? Yes and yes. Do you get a lease immediately on boot or could there be some delay ? It sounds like you don't have proper connectivity yet when ntpd tries to start (either v4 or v6 (or both)). Verify this by putting something like 'ifconfig -a /tmp/ifc.out' in /etc/rc.local. As far as I glanced, the rtsol lease should already be present when ntpd tries to start, or at least the machine already knows where to reach the v6 gateway. But this is from memory; I will test it as soon as I get back to the machine in question. If I *don't* go with rtsol but e.g. let aiccu set up a gif-tunnel, ntpd get's up cleanly, sees that there's no way to reach the v6-servers (yet) (since aiccu would be invoked from rc.local, thus way after ntpd), syncs to the v4 ones, and some time later (successfully) starts connecting to the v6 ones. s//un
spamd and IPv6?
Hello! Does spamd(8) currently support IPv6? Whereas I am able to spamdb(1) -a IPv6-addresses and they show up on subsequent visits to spamdb, netstat -a suggests that spamd itself is not listening on a tcp6 socket. Unfortunately, the manpages don't mention IPv6 at all, and I'm too poor a programmer to deduct it from the source code. To be honest, I wouldn't be surprised it spamd does indeed not support IPv6, there'd be hardly a point for it. I seriously doubt that *any* current spammer'd be using IPv6, but still: now that I've got that fancy new tunnel up and running I thought I'd play around with it a bit. s//un
Re: OpenBSD on the desktop / 3D acceleration / printer
* Christopher Intemann on Mon, May 25, 2009 at 11:03:47AM +0200: Intel and some ATI cards have working DRI/DRM. See http://www.undeadly.org/cgi?action=articlesid=20081029164221 Thanks for the hint. This looks very promising to me, even though I'm not very sure how to use the driver on OpenBSD yet. Is there any good straight forward-howto I could learn from? If the card is supported, it should just work. On my box, first thing I did after a fresh 4.5 install: $ startx [...] $ xdriinfo Screen 0: i915 s//un
Re: Printing to Windows
* Ed Ahlsen-Girard on Mon, May 25, 2009 at 07:43:51AM -0500: The best answer is simply buy a good quality, postscript, network enabled printer. That might be an option once I have a job again, but even then space considerations will weigh heavily. This is at home. If it is at home, then I'd seriously suggest that you'd use LPD on Windows. This way, at least the connection from your OpenBSD box to the spooler is not cluttered by a myriad of byzantine protocols (especially of all things SMB and CUPS...), and you can concentrate on finding a way to convert your jobs to a format the printer understands (and the setup stays *much* simpler and thus much easier to debug should problems arise someday). Last time I did it, setting up LPD on Windows was almost a no-brainer, and the correspinging printcap was straightforward and worked out of the box at the first try. As for the printer driver (for lack of a better term), you might want to take a look at http://openprinting.org/printer_list.cgi?make=HP for your specific OfficeJet. On a cursory look, it seems as if the OfficeJets are quite well supported by a number of different ways, so it should be relatively easy to e.g. plug a filter programme into printcap. I believe I have a few OfficeJets around at work; if I find the time I will experiment a little bit with them. s//un
Re: Ral0, WPA2 and ASCII keys?
* woolsherpahat on Sun, May 24, 2009 at 03:25:06PM -0700: my /etc/hostname.ral0: dhcp NONE NONE NONE nwid my_ap wpa wpaprotos wpa2 wpapsk \ $(wpa-psk my_ap SECRET) When I run 'sh /etc/netstart' I get this error: ifconfig: wpapsk: bad pre-shared key length ral0: no link . sleeping ifconfig: wpa-psk blahrg SECRET: bad value I have found this in wpa-psk(1): The passphrase must be a sequence of between 8 and 63 ASCII-encoded characters. The length of the SSID must be between 1 and 32 octets. If the error message isn't just here because of the SECRET-placeholder, maybe you might want to check the lenght of your passphrase. s//un
Booting from softraid
Hello! I've recently started playing around with the softraid(4) driver, as I recently noticed that bsd.rd already comes with support for it. What I want to accomplish is to place as much as possible into the RAID set (RAID 1, of course), ideally (almost) booting from it. Up until now I have used ccd(4). Since it isn't possible to create ccd-containers at install, I've always made disklabel with some space for the root mount, then one big slice for the rest, and as soon as the base install was done bring up the ccd-container, set up the real disklabel there, and move /usr, /var, etc. there, relying on daily(8) to keep my / mirrored in /altroot. Now I'm wondering if this whole process could be simplified precisely with softraid. I've already been able to construct a mirror set at install. My first naive try was to make a sort of pseudo-disklabel on the real disks, so that the 'a' slice just spans the entire disk, typed RAID. Then I instructed bioctl to build a RAID 1-set out of those two slices. Reboot, bsd.rd still finds it, and now install into the new sd0. Of course, this didn't work and fails first thing at boot giving ERR M. Reading up about the boot process, I'm now quite sure that it coulnd't possibly work this way ever since /boot has no way of knowing about the softraid-container until the kernel is loaded, which precisely would be /boot's function. What I now tried was allocating just a very tiny boot slice (just enough space for boot and the kernel), and having installboot(8) instructed to use *this* bootloader (outside of the RAID-set) to boot. I now get the kernel to load without problem, just as expected, and the kernel also finds the RAID-set at sd0 as bsd.rd did, so in theory it could just go on and boot from there. But instead, it tries to use this boot-slice (wd0a) as it's root device, which of course must fail (and does so, quite spectacularily). The boot(8) manpage gives the hint of using '-a' to be able to specify which drive the kernel should use as it's root drive. This way, I *am* able to successfully boot into my newly installed system. So this looks like my idea could at least theoretically work. However, I have not yet found any way of somehow storing this device somewhere so that I *don't* have to physically sit there and type in 'sd0' whenever I just happen to be wanting to boot. Now, what I want to ask: Is there a way to somehow force the root device of my choice into the kernel, e.g. ` la config(8)? Or is there maybe a way of specifying it into a boot.conf-stub placed into my boot-slice? Or am I simply wasting my time and should stick to a root *outside* the RAID-set which daily mirroring into /altroot? Thanks for any advice, Stefan
