for consideration: patch: feh(1) build without gtk, outside the ports tree
#?patch
#
# These patches, derived from the OpenBSD 6.6 ports tree (encumbered by
# their copyright!), enable installation of feh(1) 3.2.1 outside the
# ports tree, and without gtk.
#
# Me tried to make this a patch to ports, but some "clever" perl code in
# there decided that, since the feh tree contains an icon file, it must
# be dependent on gtk. grr.
#
# Built this way, feh(1) still requires the following prerequisites to
# run:
#
# graphics/imlib2
# graphics/libexif
# graphics/png
# net/curl
#
# To build: it also needs, at least:
#
# devel/gmake
#
# And finally, to test:
#
# devel/p5-Test-Command
#
# Take care,
#
# --zeurkous, Sat Oct 24 14:18:57 UTC 2020.
#
--- ..v/3.2.1/config.mk Mon Jul 22 18:26:34 2019
+++ config.mk Sat Oct 24 14:01:45 2020
@@ -4,9 +4,9 @@
app ?= 0
curl ?= 1
debug ?= 0
-exif ?= 0
+exif ?= 1
help ?= 0
-verscmp ?= 1
+verscmp ?= 0
xinerama ?= 1
# Prefix for all installed files
@@ -35,11 +35,7 @@
# default CFLAGS
CFLAGS ?= -g -O2
-CFLAGS += -Wall -Wextra -pedantic
-# Settings for glibc >= 2.19 - may need to be adjusted for other systems
-CFLAGS += -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
-
ifeq (${curl},1)
CFLAGS += -DHAVE_LIBCURL
LDLIBS += -lcurl
@@ -102,3 +98,5 @@
-DPACKAGE=\"${PACKAGE}\" -DVERSION=\"${VERSION}\"
LDLIBS += -lm -lpng -lX11 -lImlib2
+
+LDFLAGS +=-L/usr/X11R6/lib/ -L/usr/local/lib/
--- src/..v/3.2.1/deps.mk Mon Jul 22 18:26:34 2019
+++ src/deps.mk Sat Oct 24 14:02:00 2020
@@ -6,7 +6,7 @@
filelist.o: filelist.c feh.h gib_hash.h gib_list.h gib_imlib.h \
gib_style.h structs.h menu.h utils.h getopt.h debug.h filelist.h \
signals.h options.h
-getopt.o: getopt.c
+getopt.o: getopt.c getopt.h
getopt1.o: getopt1.c getopt.h
gib_hash.o: gib_hash.c gib_hash.h gib_list.h utils.h debug.h
gib_imlib.o: gib_imlib.c gib_imlib.h gib_style.h gib_list.h utils.h \
--- src/..v/3.2.1/getopt.c Mon Jul 22 18:26:34 2019
+++ src/getopt.cSat Oct 24 13:57:06 2020
@@ -36,6 +36,7 @@
#endif
#include
+#include
/* Comment out all this code if we are using the GNU C Library, and are not
actually compiling the library itself. This code is part of the GNU C
FU: RE: dmesg memory not match spdmem and bios
[before someone starts shooting me...]
me wrote:
> i386 is limited to 4G of memory.
In reality, of course, it's 4G of address space... which is not
exclusively devoted to main memory. But, while that observation does
suggest a theoretical, partial work-around (reducing the amount of
address space taken up by other devices), it likely won't help OP much.
--zeurkous.
--
Friggin' Machines!
RE: dmesg memory not match spdmem and bios
Haai, "man Chan" wrote: > Hello, > I just got a second Gaga-H97N-wifi motherbroad and installed openbsd6.6 > Stable. The dmesg shows real and avail memory does not match with the > spdmem. Anyone know how to solve this problem ? Please help. > Thanks > Clarence > OpenBSD 6.6-stable (GENERIC.MP) #1: Sun Jun 7 14:00:04 HKT 2020 > r...@dell.my.domain:/usr/src/sys/arch/i386/compile/GENERIC.MP i386 is limited to 4G of memory. Try amd64. (In theory, there's PAE, but the developers appear to find it more trouble than it's worth.) > real mem = 3634733056 (3466MB)<<<<<<<<<<<<<<<<<<<<<<<< > avail mem = 3552747520 (3388MB)<<<<<<<<<<<<<<<<<<<<<<<<<<<< >[snip] > spdmem0 at iic0 addr 0x50: 8GB DDR3 SDRAM PC3-12800 > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Good luck, --zeurkous. -- Friggin' Machines!
RE: writing aucat output
Haai, "Peter J. Philipp" : Hi, I'm wondering how I can write to stdout on aucat? Here is what I have: beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o - | hexdump -C stdout: failed to seek back to header beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o /dev/stdout | hexdump - /dev/stdout: failed to seek back to header It doesn't seem to work for me. I'm a little distracted too. Anyone want to lift me on their shoulders? My intention is to resample input audio to 44100 and output it to a wav. Normally me'd recommend Sun format... but try the attached program: beta$ /usr/bin/aucat -r 44100 -h wav -i ewhist2.wav -o - | page hexdump -C You won't see it in real-time, but since you're using a static input (me'll presume that ewhist2.wav is *not* a named pipe :), that'll hopefully not be a problem for you. Cheers, -peter HTH, --zeurkous. -- Friggin' Machines! page.tar.gz Description: page.tar.gz
RE: More than 16 partitions
"Martin Schröder" wrote: > Am Do., 23. Apr. 2020 um 21:31 Uhr schrieb : >> No problem. Would it be too crude a suggestion that we go back to the >> content now...? > > You didn't provide any patch. That is entirely correct. --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
"Christian Groessler" wrote: > On 4/23/20 7:57 PM, zeurk...@volny.cz wrote: > >> theo wrote: >>> You made it all up. >> That's an easy accusation, with an easy response: No, medid not make any >> of it up > > > Could you refrain from using your idiotic "me.."-words? Fine, me'll try and keep the idiotic ones out. > Thanks No problem. Would it be too crude a suggestion that we go back to the content now...? --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
"Jan Betlach" wrote: > For a non-native English speaker like myself, it is very difficult to > read your mestuff... Your point is well-taken (though this is just the way mespeaks); yet, Theo is a native speaker, and he seems to have completely missed the content of merecent responses. Weird, isn't it? Anyway, as this would appear to be quite OT, me'd suggest we continue this (if at all) in private mail... > Jan Take care, --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
theo wrote:
> You made it all up.
That's an easy accusation, with an easy response: No, medid not make any
of it up.
--zeurkous.
--
Friggin' Machines!
RE: More than 16 partitions
theo wrote: > That is a rewriting of history. It's history the way meknows it. Mecertainly predates some of it. > The disklabel format predates the PC. Indeed. Mewasn't sure where and when exactly it appeared, so meleft that bit out. But medid know it was older, and metried to communicate that fact (obviously mefailed -- meapologizes). > It came from the the ancient attempt to handle things in CSRG's > 4.3reno/4.4 work on the hp300. It was probably a rewrite of the > native HPUX disk format. Hmm, hp300, eh? > This was then put on all the other architectures, as a unified > view of the disk. It was modified and extended on as as-needed > basis. > > Rewriting the history like this is pathetic inaccurate and > narrowminded. Your history is absolutely false and you've made > up a bunch of balony. So, what did memake up? Did mepresent a timeline? An exact order of events? Did mepresent a scientific study? Or didmejust try to give an overview of things in terms that Groot (and many others, mesuspects) may just understand? > It is not true, and even a elementary > review of the history of disklabel.h back into the early NetBSD > tree will make it clear what's going on. Like mesaid, it's the history the way meknows it. Me's not a bloody authority on the history of either BSD or the IBM pee-cee, *at all*. Perhaps meshould've made that clearer. > OH, and I did most of the early work post-CSRG, because we needed > to "emulate" this on SunOS, and I ported Torek's sparc code into > NetBSD. Mehas _no doubt at all_ that you know BSD (including its history) better than me (that is, of course, an understatement). > I urge you to stop posting such balony. Then it's me turn to urge you to not read me overview as an historical account of any exactness. After all, the goal, for me, was trying to help Groot understand the relationships he sought clarification for. Perhaps meindeed should've included a disclaimer. Then again, mehas no offical role here (nor does mewant one), and in no way are me words to be taken for the one and universal truth. Can we please just assume that Groot is mature enough to be able to form his own view based on our individual contributions? Me'd like that. --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
"Groot" wrote: > I've tried and failed to create more than 16 > partitions on OpenBSD. First of all I don't > understand the difference between the operations > performed by fdisk and disklabel. Is it that > OpenBSD sees partitions differently? First we > create an OpenBSD partition with fdisk and then > with disklabel we can create at the most 16 more > filesystem partitions within it. Traditionally, BSD has used only its own disklabel(5). Unfortunately, mess-dos on the IBM pee-cee set a competing standard, the "Master Boot Record", with a separate partition table (and a lot of kludging to support more than 4 partitions). While it was (and AFAIK remains) possible to use the whole disk the traditional way (only a BSD disklabel, as on e.g. sparc64), it has become common practice to wrap the BSD stuff in a mess-dos partition, with the caveat that some of the mess-dos partition entries are duplicated in the BSD label. Thus, the BSD label is essentially OpenBSD's version of the structure of things on the disk. But is an imperfect version: 16 partitions *is* the limit for an OpenBSD label, and, of course, mess-dos partition identifiers (which are more *ahem* fine-grained) are not used. To top it off, partitions which rest within the mess-dos OpenBSD partition are not necessarily represented on the mess-dos level (this would count, from the mess-dos perspective, as overlap between partitions and thus confuse a great many tools). Then GPT entered the story to make the mess complete. But me'll remain blissfully unaware of the inner workings of that particular clusterfsck, if you don't mind ;) It's no shame to be confused by this garbage. Almost all of us'd like better, but for the above hysterical raisins, it's not so easy to make it so. --zeurkous. -- Friggin' Machines!
RE: More than 16 partitions
Haai, theo wrote: > Groot wrote: > >> I've tried and failed to create more than 16 >> partitions on OpenBSD. First of all I don't >> understand the difference between the operations >> performed by fdisk and disklabel. Is it that >> OpenBSD sees partitions differently? First we >> create an OpenBSD partition with fdisk and then >> with disklabel we can create at the most 16 more >> filesystem partitions within it. >> >> But if I want more than 16 filesystem partitions >> on a single disk naturally I try to create more >> fdisk partitions and then within it lay more fs- >> partitions. When I try that OpenBSD doesn't >> recognize those partitions and I can't even run >> 'newfs' on those partitions. Is there a way for >> OpenBSD to deal with more than 16 partitions? >> > > Sorry, there is no way. > > You can create a vnd, on a file, and then that vnd can contain > partitions. But it might suck. Me's configured a pair of consecutive softraid(4) partitions in concat mode. Sees relatively light use, but performance has been adequate. Previously, meused crypto w/ a passphrase of '0' (automagically read from a file at boot), but that was just needlessly complicated. Fixing vnd(4) to work on devices, or just adding a 'concat-of-1-volume' (perhaps call it 'L'ayer) "level" to softraid, is what me'd recommend. But that doesn't seem to help Groot (right now). Hope the above helps, --zeurkous. -- Friggin' Machines!
RE: sndioctl double behaviour
"Alexandre Ratchov" wrote:
>
> It looks like caused by unveil(2) usage in chrome. According to
> unveil(2):
>
> Directories are remembered at the time of a call to unveil().
> This means that a directory that is removed and recreated after a
> call to unveil() will appear to not exist.
>
> so, unveil("~/.sndio") is called, if chrome is the first program to
> use audio, the directory doesn't exist so it's not unveiled. Then,
> chrome connects to sndiod, creates "~/.sndio" directory and tries to
> save the cookie, which fails. Then, other programs (like sndioctl)
> will be rejected by sndiod until chrome disconnects.
>
> Adding the full cookie path wouldn't help as the directory doesn't
> exist yet.
>
> Hmm.
Yes, "Hmm." is right. Aren't you badly duplicating NAS here...?
MIT-MAGIC-COOKIE-1! MIT-MAGIC-COOKIE-1! SCNR.
--zeurkous.
P.S.: If you want advice, you know who to ask.
--
Friggin' Machines!
RE: sndioctl and USB HID keyboard
theo wrote:
> You don't know your place.
Your opinion is well-considered.
--zeurkous.
--
Friggin' Machines!
RE: sndioctl and USB HID keyboard
theo wrote: > wrote: > >> > usbhidaction runs as root, given /dev/uhidN permissions, it's clearly >> > not intended to run "high level" user commands. >> >> The keys, however frivolous memight find them, are clearly to apply to >> the output belonging to the terminal that the kbd is attached to. > > You are welcome to stick with 6.6, or even a newer release. TYCO. > Know your place. Yeah well, even w/ the best advice, some people just can't be helped. --zeurkous. -- Friggin' Machines!
RE: sndioctl and USB HID keyboard
Morning Theo, theo wrote: > Alexandre Ratchov wrote: >> Hi, >> >> mixerctl is still the appropriate tool here, sndioctl is not inteded >> to be run as root. >> >> usbhidaction runs as root, given /dev/uhidN permissions, it's clearly >> not intended to run "high level" user commands. For instance it makes >> no sense to run "audiocious -u" when Pause/Play key is hit, it's the >> similar for sndioctl. The mixerctl utility remains for such "low >> level" use cases. > > Since all audio control methods are now available inside sndioctl, I > have a hard time seeing why mixerctl has to remain. sndiod(8) may not even be running. A simple mixer set operation becomes an exercise in complexity. If you really want relative simplicitly: implementing loopback audio devices would seem to be a start. It's been done w/ midi(4), why not w/ audio(4)? >> Any program using sndiod is intended to be used one user at a time for >> obvious privacy reasons, this is quickly explained in the last >> section of sndio(7). > > What are the chances that isn't the user on the USB bus? > > Requiring people to use doas? Honestly, I find that offensive. Me, too. . --zeurkous. -- Friggin' Machines!
RE: sndioctl and USB HID keyboard
Morning, "Alexandre Ratchov" wrote: > Hi, > > mixerctl is still the appropriate tool here, sndioctl is not inteded > to be run as root. Oh, really? > usbhidaction runs as root, given /dev/uhidN permissions, it's clearly > not intended to run "high level" user commands. The keys, however frivolous memight find them, are clearly to apply to the output belonging to the terminal that the kbd is attached to. Your design is flawed, on multiple levels. Read my message from yesterday to find out why. > For instance it makes > no sense to run "audiocious -u" when Pause/Play key is hit, it's the > similar for sndioctl. The mixerctl utility remains for such "low > level" use cases. Again, just like scroll lock (and just about every other key), it's to apply (by default) to the current terminal (mesupposes X as a whole, taking up a single ttyC, counts as one). They're software keys, not hardware buttons. The latter are not generally attached to the keyboard interface, to prevent exactly this kind of confusion of levels. > Any program using sndiod is intended to be used one user at a time for > obvious privacy reasons, this is quickly explained in the last > section of sndio(7). The privacy concern is legitimate; the solution you have implemented is needlessly restrictive. At the very least, socket permissions can be relied on to provide access control. root will ignore such permissions, making access by root always work (as it should). --zeurkous. -- Friggin' Machines!
RE: Problem with mixerctl on latest snapshot
"Alexandre Ratchov" wrote:
> On Sun, Apr 19, 2020 at 09:11:16AM +0200, zeurk...@volny.cz wrote:
>>
>> > Now programs connect to sndiod which does the hardware access for
>> > them, this has other advantages as well:
>> > - programs control the volume of the right device on systems with
>> > multiple audio devices (ex. usb head sets)
>> > - there's always a volume control, even if the hardware lacks one, as
>> > may usb devices.
>> > - unified view of hardware and software controls, network
>> > transparency, etc
>>
>> That may all be, but like xenodm(1), memight find (future tense, as me's
>> not running -current or snapshots) the above proposed solution
>> inadequate for me needs.
>
> Hi,
>
> I'm curious, what use-case is not handled and still requires access to
> the device nodes?
To begin w/, some ports (such as emulators/snes9x) doesn't support sndio
(as of 6.6). But in general, read "memight" as "mecan imagine that
me'd" :) Stay tuned until megets to confront the new situation (prolly
when meupgrades to 6.7 when it's out).
On the X front: duplicating the functions of login(1) and getty(8), but
then w/in the pile of bloat that is X, is a flagrant layer violation
that mecannot support.
The two issues have in common, for me, that audio and video belong in
the terminal; instead, after all this time, they are *still* treated
specially, and it shows. No wayland or NeWS or w/ever is going to help:
they are incompatible w/ the textual nature of UNIX. What *would* help
is to treat {audio samples,pixels,...} as mere characters (yet another
sensible development that is obstructed by the Unicode "Pit of Babel"),
thereby making {audio,video,...} an integral part of the system -- just
like it should be in 2020 (for fsck's sake).
Until then, the use case "UNIX" remains unhandled.
--zeurkous.
--
Friggin' Machines!
RE: Problem with mixerctl on latest snapshot
Haai, "Alexandre Ratchov" wrote: > On Sat, Apr 18, 2020 at 03:53:19PM -0700, Renato Aguiar wrote: >> Hi, >> >> After updating to latest snapshot, mixerctl stopped working with non-root >> user: >> >> $ mixerctl >> mixerctl: /dev/audioctl0: Permission denied >> $ ls -l /dev/audioctl0 >> crw-rw 1 root _sndiop 42, 192 Apr 18 14:29 /dev/audioctl0 >> $ >> >[snip] > > Access to audio and MIDI related device nodes is now disabled for > security reasons. We don't want programs we run, possibly processing > untrusted input, to be allowed to directly access low level drivers > and attempt to exploit kernel bugs. Mefinds this issue to be analogous to the X(7) permission one (the one that led to -s for Xorg(1)). > Now programs connect to sndiod which does the hardware access for > them, this has other advantages as well: > - programs control the volume of the right device on systems with > multiple audio devices (ex. usb head sets) > - there's always a volume control, even if the hardware lacks one, as > may usb devices. > - unified view of hardware and software controls, network > transparency, etc That may all be, but like xenodm(1), memight find (future tense, as me's not running -current or snapshots) the above proposed solution inadequate for me needs. Right now, for both X(7) and the parts of audio not covered for me by sndio(7), me's somewhat working around the security issues by having the relevant device nodes only accessible (and Xorg(1) only executable) by me as a luser (via groups 'x11' and 'audio', respectively). Me's not propagating the above as a solution; yet, as a workaround, me's found it to be a life-saver. Take care, --zeurkous. -- Friggin' Machines!
at(1) and cron(8) (was: Re: Regarding randomized times in crontab)
Just as a note for the future: mefeels that it'd be great (for clarity
as well as simplicity) if cron(8) would be merged into at(1) at some
point:
% echo make-coffee | at teatime every day
(Or similar.)
Such a change would allow each job to be individually manipulated, as
well.
--zeurkous.
P.S.: No patch for UNIX, at least from me: you folks'll have to do w/
me advice :)
--
Friggin' Machines!
RE: I see you guys are full of shit when it comes to one thing:
"zap" wrote:
> Also, by all means, please do ban me if you want.
Me's never seen anyone on the list outright banned... However, replies
to at least one thread have been (and are perhaps still being) filtered
out. That thread involved a {loonie,troll} excessively cross-posting
rather explosive allegations (wy worse than your outburst).
Medoesn't really agree w/ the filtering, though meunderstands it.
> I really couldn't care
> less. you guys need to get off your own pedestal.
Yeah well, lots of humans put themselves on pedestals... that's far from
unique to the OpenBSD project.
Again, please calm down. Even if theo & co. can't be nice, *we* can be
nice and thus make things nicer for everyone.
Take care,
--zeurkous.
--
Friggin' Machines!
RE: I see you guys are full of shit when it comes to one thing:
"zap" wrote: > you think proprietary softwatre is secure as much as linux loves being > shit. > >[and it just went downhill from there...] Please calm down. Somtimes mefeels the way you do, so meunderstands... however, me'd advise not to make a public scene. --zeurkous. P.S.: Things *are*, currently, shit. -- Friggin' Machines!
RE: passive-aggressive questions
theo wrote: > Nothing you are saying has any relevance to the use of OpenBSD. As much as one might wish it were, OpenBSD is *not* an island: the place of OpenBSD in the world *is* a relevant issue. Real life, y'know. > The chatter is useless. You just can't stand to see yourself being criticised (no news there). > Stop it. Ah, you've come out of 'denial' and passed into 'anger'. Anyone wanna bet when he moves on to 'bargaining'? Theo: you are free not take notice of any of this. Mesuggests that you consider using that freedom (aka: just plonk it if it you don't like it). Your position is not under attack (at least not by me). --zeurkous. -- Friggin' Machines!
RE: passive-aggressive questions
"j3s" wrote: > On 4/14/20 11:02 PM, zap wrote: >> I'll be honest, i like libre software, but, libre software that is >> insecure, aka redhat's bs, openssl, java, etc... is barely better than >> proprietary software. > > this is crap. That stuff sure shares a lot of traits w/ one's typical proprietary product: fluffy obscurity, bugginess, ridiculous design flaws, lack of plain common sense, etc. >> unix philosphy should have been kept in linux. Because it wasn't, >> well... Linux and GNU for that matter are going to take a hit again and >> again, till they learn their damn lessons. > > GNU isn't a collective of children to be punished. They're programmers > volunteering their time and you sound like a sad person for treating > them this way. ,s/programmers/advocates/ > But also, Theo is right, none of this relates to OpenBSD; Doesn't it, really? Comparison w/ the outside world is on of the most useful critical tools that me's aware of. > it seems like > you just want a pedestal to piss on others from. This is not that place. Medidn't observe zap do that (at least not yet). --zeurkous. P.S. to zap: the courtesy copy of the prev msg got rejected by your mail swerver; either you do not exist (as it claims), or volny is fscking up somehow. Either way, consider yourself informed. -- Friggin' Machines!
RE: passive-aggressive questions
Haai, "zap" wrote: > > I think theo is about the same as Linus in how foul he can get... As meobserved, Theo's agression is more of passive kind. Dunno if that's an improvement... > but on the other hand, he at least doesn't wreck his software with > pointless things like redhat's crap, systemd for example, he seems to > prefer the keep it simple stupid approach from what I have seen. I much > prefer security over complexity. No argument from me there. > I'll be honest, i like libre software, but, libre software that is > insecure, aka redhat's bs, openssl, java, etc... is barely better than > proprietary software. Me first question is always: if it breaks, can me feasibly fix it? Only if so, me's satisfied (that still means that most of BSD fails the test, but it ain't exactly a perfect world... it has humans in it, after all). > unix philosphy should have been kept in linux. Because it wasn't, > well... Linux and GNU for that matter are going to take a hit again and > again, till they learn their damn lessons. Learn their lessons? They won't. Just like Theo won't (me'll be glad to be proven wrong). > Very few linux people have learned this lesson. Hyperbola is the only > one I know of that realizes linux is a dead end. I would hope you guys > would feel honored by this fact, but oh well. No, he's not the only one. But UNIX has become a dead end as well (me'll spare you that rant), for different reasons. > Either way, I do have respect for you guys. Even if you don't realize it. Mehasn't doubted that. --zeurkous. -- Friggin' Machines!
RE: GNU+Linux corporate takeover, was: Wine for OpenBSD?
theo wrote: > What do thsi have to with OpenBSD? Drat. Someone discovered The Homoheterothropic Society for the Intermezzanic! Mesupposes we'll have to disband. --zeur. -- Friggin' Machines!
passive-aggressive questions (was: RE: GNU+Linux corporate takeover, was: Wine for OpenBSD?)
theo wrote:
> What does this have to do with OpenBSD?
Alright, let's talk about leadership. Do you folks think Linus is a
better leader than Theo here?
There, OpenBSD angle restored.
(Yes, medoes wish that discussion about lunix et al. be toned down. Even
so, mealso wishes that the passive-aggressive behaviour that theo just
displayed here would stop.)
Love && cuddles,
--zeurkous.
P.S.: Be careful what you wish for.
--
Friggin' Machines!
webmaster@ (was: RE: openbsd.org down?)
Haai, mewrote: > Cc'ing webmaster@ (assuming it exists). That didn't go so well: a "mailing list expansion problem", apparently on the side of mail.openbsd.org. Since it ain't an obvious rejection, me's informed postmaster@. --zeur. -- Friggin' Machines!
RE: openbsd.org down?
"Durial EB" wrote: > Still down for me. Appears intermittent. Cc'ing webmaster@ (assuming it exists). --zeurkous. > On Sun, Apr 12, 2020 at 5:44 PM wrote: > >> > Hello. >> > >> > What happened to the openbsd.org? >> > I seems to be down for 10+ hours for now. >> >> WFM. Empty your name swerver cache, it might help. >> >> > Regards, >> > >> > Roman >> >> --zeur. >> >> -- >> Friggin' Machines! -- Friggin' Machines!
RE: openbsd.org down?
> Hello. > > What happened to the openbsd.org? > I seems to be down for 10+ hours for now. WFM. Empty your name swerver cache, it might help. > Regards, > > Roman --zeur. -- Friggin' Machines!
RE: strncasecmp
"Stuart Longland" wrote: > On 12/4/20 11:39 am, zeurk...@volny.cz wrote: >> "Stuart Longland" wrote: >>> On 11/4/20 2:30 am, zeurk...@volny.cz wrote: >>>> https://doomwiki.org/wiki/Absurd texture name in error message >> >> No, what I wrote is: >> >>> 'https://doomwiki.org/wiki/Absurd texture name in error message' >> >> World of difference. To a UNIX guy. > > Ohh, I did see the quotes, that's what made me try the URI with spaces > after seeing the 404 page. You initially thought that the final component was 'Absurd'? :x >> Seems like some people eat everything the WWW n00bs emit, right up to >> and including a turd. >> >> What's next? All list messages in quoted-unreadable? C'mon. > > doomwiki should not be using such characters in their URIs. I'm not > blaming you for their presence by the way. Had they done the right > thing in the first place, the quotes would never have been needed. :-) Actually, metyped that URL from memory. lynx(1) DTRT's when invoked w/ a (properly-quoted) address w/ space in it, even as it's 'g'oto command does not (meconsiders the latter a bug). To me, a file name containing spaces is a natural thing, and thus meconsiders it absurd to require everyone to expand them to a somewhat unintuitive 3-character sequence just to quote them. That's why we have dedicated quoting characters, but the W3C et al. still have to discover those. After ~50 years. (The issue could also be solved by giving names a special format (for example, by underlining them) in order to distinguish them even w/ spaces present. Such an approach has other benefits as well, but has nothing to do with UNIX-as-we-know-it.) --zeurkous. -- Friggin' Machines!
RE: strncasecmp
"Stuart Longland" wrote: > On 11/4/20 2:30 am, zeurk...@volny.cz wrote: >> https://doomwiki.org/wiki/Absurd texture name in error message No, what I wrote is: > 'https://doomwiki.org/wiki/Absurd texture name in error message' World of difference. To a UNIX guy. > https://doomwiki.org/wiki/Absurd%20texture%20name%20in%20error%20message > > Seems some people don't understand URIs... Seems like some people eat everything the WWW n00bs emit, right up to and including a turd. What's next? All list messages in quoted-unreadable? C'mon. --zeurkous. -- Friggin' Machines!
RE: Does Intel driver supports 3d acceleration?
"Anton Karpov" wrote: > Ty vseh zaebal. Amen. --zeur. > > On Sat, 11 Apr 2020 at 13:28, Nikita Stepanov > wrote: >> >> Does Intel driver supports 3d acceleration? -- Friggin' Machines!
RE: Does Intel driver supports 3d acceleration?
"Ingo Schwarze" wrote: >[about Mr. Stepanov] > > Replying to him was clearly a mistake, sorry for that. > I suggest we now stop feeding that obvious troll. You do sometimes identify people as trolls a little too easily. This is clearly a common-and-garden variety n00b. Indeed no use replying, though. Let him learn to do his homework. > Yours, > Ingo Take care, --zeurkous. -- Friggin' Machines!
RE: Openbsd supports pae?
"Nikita Stepanov" > Why? 'Cause the sun went dry, and the flowers said "bye". Nasty of them, isn't it? --zeur. > 1:34, 11 aprelya 2020 g., Nikita Stepanov > : -- Friggin' Machines!
RE: Nvidia driver for OpenBSD?
"Nikita Stepanov" wrote:
> I found https://man.openbsd.org/man4/nv.4
Then WTH did you ask?
Nevermind; n00bs gonna n00b, meguesses.
--zeurkous.
--
Friggin' Machines.
RE: strncasecmp
Haai,
> From the man page:
>
> """""
> These functions compare the NUL-terminated strings s1 and s2 and
> return an [...].
>
> strncasecmp() and strncasecmp_l() compare at most len characters.
> """""
>
> Why NULL-terminated when comparing at most len characters?!
Since, by design, one's not supposed to be aware of the actual length of
the string, only of the buffer containing it (if that).
The 'NUL' vs 'NULL' can be confusing; indeed, mealways describes such
strings as 'zero-terminated' in nnx (exactly what that means is
described in a manual page for the type).
Though nnx tends to use bounded arrays { char *a, *e; bool v; } instead
(this has the pleasant side effect that a 0 may occour inside a string,
and the seperate 'bool v' allows for use of the complete address space,
NULL included).
(Here, me's using the nnx stuff as a vehicle to point out design
problems in UNIX: as always, YMMV, and no ad intended).
> Rod.
Hope the above has enlightened,
--zeurkous.
P.S.: Please don't address misc@ blindly: instead, address it in 'To:'
or 'Cc:'.
--
Friggin' Machines!
on "underpowered" machines (was: Re: i386 kernel relinking)
theo wrote: > I think this conversation is ridiculous: > > If a machine is too small, then it is too small. Do I have to paypal > a $0.05 to some users? Yes, me! Pretty please? *kitty eyes* Seriously: sometimes, a machine is perfectly adequate, except for one task that eats disproportionate amounts of resources. Questioning the apropriateness of that task would seem to be a reasonable step to undertake, before running to the store waving your credit card (not to speak of the waste problem). Apart from the fact that many people on this planet *are* really-terribly-out-of-pocket, there are still other issues than money. --zeurkous. -- Friggin' Machines!
RE: strncasecmp
"Roderick" wrote: > > On Fri, 10 Apr 2020, Theo de Raadt wrote: > >> Because either string could be shorter than len. > > Thanks. I get it. :) My non-strings do not have a '\0' in the > first len bytes and I need a case insensitive comparison. > Of course I could ignore strncasecmp and use tolower() to write > the trivial function, ... UNIX, in its current form, is just messy like that... >> "NUL-terminated string" is firmly explaining to people that in C, >> a string is only a string if it ends in a NUL. There's a large >> contingent of folk who don't get it. > > The word "string" is also found in the man pages of bcmp and memcmp. > Wrote by that large contingent? Hysterical confusion (akin to the 'tty' confusion: terminal or simple serial port?). They would better be changed to speak of arrays. > Rod. Baai, --zeurkous. -- Friggin' Machines!
RE: strncasecmp
theo wrote: > Because either string could be shorter than len. > > strncasecmp() and strncasecmp_l() compare at most len characters. > ^^^ > > "NUL-terminated string" is firmly explaining to people that in C, > a string is only a string if it ends in a NUL. There's a large > contingent of folk who don't get it. As an example of what happens when folks don't get it: [0]. In general, me'd strongly suggest that we speak of an 'array' when it's not zero-terminated (that again should be redundant information here, but yeah). Baai, --zeurkous. [0] 'https://doomwiki.org/wiki/Absurd texture name in error message' -- Friggin' Machines!
RE: news from my hacked box
Haai, "Theo de Raadt" wrote: > Cord wrote: > >> You are free to believe or not to believe, but you are not free to insult me. >> Is that clear ? > > Or what.. you'll throw your tinfoil hat at them? Haven't you yet been diagnosed w/ ODD? :) Cord: you're prolly being overly paranoid, and your assertions are somewhat vague. Many people here have trouble dealing w/ that, me included. Thus: please excuse us if we cannot give you the answers you seek. What mecan say is that some of the problems you identified are a natural consequence of the unreliability of IP. No reason to be a jerk, though. HTH, --zeurkous. -- Friggin' Machines!
RE: Unusual threading behavior on single processes
Haai, Just to make a more-or-less general point (or two)... "Otto Moerbeek" wrote: > On Fri, Mar 27, 2020 at 09:03:40PM +, Stefmorino wrote: > >> I have tested many applications, the behavior is the same in all of them, but >> I'll talk about OpenMW (an open-source game engine for morrowind) since I >> have >> the most useful information about how this program is threaded. By default, >> OpenMW uses 4 threads (cited here: >> https://openmw.readthedocs.io/en/stable/reference/modding/settings/cells.html), >> one for main/generic processing, one for graphics, one for audio, and one for >> preloading terrain. >>[snip] >> >> Is it a lock (spin is at 0)? A placeholder? A limitation of how Ryzen SMP is >> implemented? >[snip] > > Wild guess: it could be that you program actually does not do real > threading, but userland threading. "Fibering", in other words. > Check with top -H if it really > creates threads. You should see multiple threads having the same PID. > or all thraeds are using a resource that cannot be shared. Likely the latter. It's always funny, isn't it... A coder thinks "hey, I want a multi-threading 'cause its 1337, I'll just neatly run these subsystems within seperate threads and I'm done!". The fact that such is a frequently a naive proposition should be clear to the more clueful reader. Games tend to be heavy on global state, and are more likely to benefit from a multi-process model w/ carefully thought-out boundaries, than from a shared-everything thread model. While that need not be the case here, mestrongly suspects it is. Take heed, and measure. Always measure. Take care, --zeurkous. > -Otto -- Friggin' Machines!
RE: Hardening browser
Haai, "Tomasz Rola" wrote: > On Thu, Mar 05, 2020 at 12:25:56PM +0100, zeurk...@volny.cz wrote: >> > > I use lynx a lot, very nice tool. It also helped me to restart my > browsing of gopher sites. There was plenty of them 20+ years ago, now > it is just a handful of servers. But still, better than nothing. Menever quite was into Gopher, but mereally should try and have a look someday... >> Occasionally, when really pressed, meruns 'tails', a specialized Lunix >> distro, from a DVD on a spare craptop; at least that way, mecan get rid >> of the bloated, buggy shit by simply turning off the machine. > > I do not know tails, only read about it. > > Using separate computers for different roles might be a way of the > future. A very convoluted way. But one cannot count too much on > security offered by modern popular cpus and there is always a chance > to be struck by something unexpected: I have just read that bmp file > from game server might make buffer overflow on client side. So, one > machine for gaming, one for reading, one for shopping and one for > work. And one for listing the music. 2003 came calling ;) Seriously: what you fear has already come to pass, for many people, long ago. It's even in the mainstream now: there, it's considered good practice to design an "app" so that a luser can seamlessly use it across the various "devices" in its possession. Or is merunning behind and did that idea die? > I will never propose this kind of solution to normal people. :-) Thankfully, we're not normal here =) >> -- >> Friggin' Machines! > > Oh no, it is not the machines. It is their masters. And their creators. The phrase is from an old Quake map that me's long since forgotten the name of. --zeurkous. -- Friggin' Machines!
RE: Hardening browser
Me's been following this discussion w/ some interest. Personally, meuses lynx(1) (w/o the ports patches, as they interfere w/ text field editing among other things), in image_links mode w/ feh(1). Works like a charm :) Mecan only agree with the sentiment that if something does not work in a normal (i.e. not overly bloated, and without ``backdoors'' like javashit) browser, it's the fault of the webmaster, not us as readers. Occasionally, when really pressed, meruns 'tails', a specialized Lunix distro, from a DVD on a spare craptop; at least that way, mecan get rid of the bloated, buggy shit by simply turning off the machine. Not that me's too impressed w/ 'tails': it does, but the maintainers appear to have mostly a broad, and thus not very deep, grasp of security. If me'd know of a similar, OpenBSD-based alternative, me'd of course use it. But, to me, anything is better than installing and maintaining a load of overweight, clumsy, not-very-UNIXy packages *just* to do the occasional javashit-bloated thing. Just me half-stiver :) --zeurkous. -- Friggin' Machines!
RE: man to render pure text? (or a pipe in vi macros ?)
Haai, "Ingo Schwarze" wrote: >[about a flag to make mandoc(1) omit backspace stuff:] > In 2014, i already wrote a patch to do that because the question > came up repeatedly. But demand wasn't that high after all, so i > never committed it. Now, i updated the patch to -current, see > below. Medoesn't run -current, so meprolly can't test it, but... > On the one hand, the UNIX phlosophy is to have each tool do one > thing well, then use pipes to connect tools as needed. Then again, > arguably, you maybe shouldn't need another tool to just revert > something that the first tool does. Why would *not* adding backspace > formatting require a pipe to another program, rather than not adding > it in the first place? > > Also, the patch that would be required is very small and straightforward. > > So, what do people think? Should i test the patch below in more > depth and commit it? Or do people consider this bloat? While mecan see much merit in both sides of the argument, me'd say: can't hurt, will help people, go! > Yours, > Ingo Baai, --zeurkous. -- Friggin' Machines!
RE: size of size_t (diff angle)
Haai,
"Claudio Jeker" wrote:
>>> Now if SIZE_MAX is the highest address is a different thing.
>>> On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
>>> it covers actually more then what is possible). The highest valid
>>> address is in most cases less than SIZE_MAX.
>>
>> Yes, the {,in}famous halfway split... for calculations involving
>> already valid {addresse,offset,size}s that hardly matters, however.
>>
>> What *does* matter, is the potential lack of equivalence of the types.
>> Which, as you pointed out, does not affect OpenBSD (at this time), yet
>> might be a portability issue. Hence me raising it.
>
> The times of non ILP32 or I32LP64 UNIX systems is over (at least when it
> comes to userland processes).
This just adds fuel to me argument that we should ditch size_t,
uintptr_t, et al., in favour of a simple 'char *' (by that or any other
name (such as caddr_t)).
> If you want a UNIX-like OS where code will
> work then those are your only options. The ecosystem is not able to handle
> anything else anymore. All the other discussions are theortical and will
> not result in anything that is usable to run UNIX software.
Then me'd say that it's high time the relevant standards are updated to
reflect that reality.
The latter is, of course, outside the purview of OpenBSD. (But we can
set a good example.)
Thank you.
Baai,
--zeurkous.
--
Friggin' Machines!
RE: size of size_t (diff angle)
Haai,
"Claudio Jeker" wrote:
> This has not much to do with OpenBSD.
On the contrary: these issues touch the fundaments of UNIX programming.
> As for OpenBSD, it only runs on two types of machines: ILP32 and I32LP64.
> Any other type of machine that is not covered by these two types will
> not run OpenBSD.
Oh yes, this is not NetBSD, me's well aware... And yet, metries hard to
satisfy basic portability when feasible. This is consistent with OpenBSD
practice, at least if the manual pages are anything to go by.
> In both cases size_t is defined as unsigned long which is the same as
> uintptr_t and the same size as pointer.
Of course, in practice that's the case. You'll really get no argument
from me there.
> Now if SIZE_MAX is the highest address is a different thing.
> On OpenBSD 0..SIZE_MAX will cover the address room (in most cases
> it covers actually more then what is possible). The highest valid
> address is in most cases less than SIZE_MAX.
Yes, the {,in}famous halfway split... for calculations involving
already valid {addresse,offset,size}s that hardly matters, however.
What *does* matter, is the potential lack of equivalence of the types.
Which, as you pointed out, does not affect OpenBSD (at this time), yet
might be a portability issue. Hence me raising it.
Baai,
--zeurkous.
--
Friggin' Machines!
RE: size of size_t (diff angle)
Haai,
"Marc Espie" wrote:
>>> You're looking at the wrong type. size_t is very good for what it does.
>>
>> Yes; meproblem is with the 'what it does' part.
>
> It represents memory sizes. It works on anything with a sane
> memory model.
The way meunderstands it, it's just an offset, plain and simple. Which
on a sane machine is indeed of the same type as an address[0].
Unfortunately, C99 does not appear to reflect that. Now, to what degree
(if!) we should respect C99, or take it much seriously at all, is
another matter...
>>> Try uintptr_t
>>
>> Are you proposing a change to struct iovec?
>
> Why should I ? readv works with sizes, so size_t is adequate.
Yes, why should you? That was me implied question. You told me to use
uintptr_t, but that will hardly solve things on the exact problem mewas
working on (medidn't specify what it was, and you didn't ask), unless we
change struct iovec (cue an 'over my dead body' response from theo, and
with respect to compat, he'd be damn right).
> You were mentionning caddr_t earlier. intptr_t and uintptr_t are
> the adequate types for working with addresses. size_t is the adequate
> family for working with sizes.
Me's found that such statements emerge from a shallow understanding of
the nature of C. C doesn't know sizes: indeed, it barely knows indices
and offsets. If sizeof() would have been defined to return the index
of the final byte, instead of the count of bytes, then the C99
definition for size_t would've been pre-empted.
> POSIX kind-of implies readv, which means that both realms tend of
> mesh.
Yes, that's an obvious layer error. C as a language should not be
confused with libc, or UNIX in general. In fact, C and UNIX appear to
only have two concrete things in common: ASCII, and the byte as the
fundamental type. That's it.
> If you're on something where they don't, you're fucked.
Me's never been the type to play it safe. The path forward is not blind
obedience to the ravings of committees, especially those that pretend to
set a universal standard.
> Good luck.
Thanks. Me's decided to ditch the {read,write}v compat wrappers and take
the performance hit. It's all preperation for a real OS, after all:
me'll do it right in there.
> What are you doing asking questions on an OpenBSD list, btw ?
nnx runs on OpenBSD. You must be confusing it with NetNIX, which is the
OS that will eventually emerge.
NetNIX will not have size_t.
Baai,
--zeurkous.
[0] Except, of course, it's an 'offset + 1'. Oops. But that's the least
of the problems if SIZE_MAX is not guaranteed to be the highest
address...
--
Friggin' Machines!
RE: size of size_t (diff angle)
Haai, "Marc Espie" wrote: > On Tue, Feb 25, 2020 at 08:56:06AM +0100, zeurk...@volny.cz wrote: > > You're looking at the wrong type. size_t is very good for what it does. Yes; meproblem is with the 'what it does' part. > Try uintptr_t Are you proposing a change to struct iovec? --zeurkous. -- Friggin' Machines!
RE: size of size_t (diff angle)
Haai, "Anders Andersson" wrote: > On Tue, Feb 25, 2020 at 12:14 PM wrote: >> >> First of all, let us reflect upon the definition of size_t in C99. >> >> > size_t >> > which is the unsigned integer type of the result of the sizeof >> > operator; >> >> That's not very specific. It kind-of implies that SIZE_MAX (defined >> later in the standard) is the largest possible offset, but not >> necessarily the largest possible address. This reeks of i86 real mode >> semantics, obsolete (for general-purpose machines) already when the >> PDP-11 was new. > > I think it's pretty clear, size_t is for the size of objects, not for > offsets or pointers. At least in C, the difference between sizes, offsets, and addresses are semantic in nature. Even B, as meunderstands, treats memory as a flat array (just of words instead of bytes). > The C standard frowns upon mixing up pointers and > integers, to much grief from low-level developers. Menoticed that too. Given the nature and background of C, it's pretty weird (not to say inappropriate) for 'the standard'(tm) to do so. >> Is SIZE_MAX guaranteed to *not* be greater than the highest address? > > I'm almost certain that C99 offers no such guarantees, since a pointer > to a float does not have to be the same size as a pointer to int, for > example. Maybe if you're being a little more specific. There are some > exceptions for void * and char *. > > In fact, the standard only *recommends* that implementations keep > SIZE_MAX as small as possible but not smaller. Since it is only a > recommendation, it can be inferred that the standard acknowledges that > an implementation with SIZE_MAX > highest address is valid. Mesupposes that's tolerable, as long as sizeof() indeed never returns a value greater than the largest address... mehas observed no such guarantee either, however. > "The types used for size_t and ptrdiff_t should not have an integer > conversion rank greater than that of signed long int unless the > implementation supports objects large enough to make this necessary." Yes, menoticed. Strange for the standard to suddenly group sizes and addresses (address "diffs" even!) together. Quite schizophrenic if you ask me... > Or my interpretation: "Just because there is now a new and fancy > 64-bit long long in C99 doesn't mean that you should make size_t a > long long just because you can, because it's pointless if your > compiler/target only has a 32-bit address space." The issue mebumped into was that SIZE_MAX being an arbitrary value, with no specified relation to the highest address, makes some compat code pretty messy. Hence mehoped that there was some kind of guarantee; megot the answer mefeared. Thanks, your answer was quite helpful. Baai, --zeurkous. -- Friggin' Machines!
size of size_t (diff angle)
Haai, The definition of size_t keeps biting me. Some background: in nnx, me's been using the equiv of caddr_t for counts. This works well; yet, while writing against existing code that uses size_t, an issue has surfaced. First of all, let us reflect upon the definition of size_t in C99. > size_t > which is the unsigned integer type of the result of the sizeof > operator; That's not very specific. It kind-of implies that SIZE_MAX (defined later in the standard) is the largest possible offset, but not necessarily the largest possible address. This reeks of i86 real mode semantics, obsolete (for general-purpose machines) already when the PDP-11 was new. POSIX is even less helpful: > size_t > Used for sizes of objects. (Let me note in passing that medisapproves of the significant overlap between C99 and POSIX, and the shameless disregard, in both, of the byte-oriented nature of UNIX and C). So, as meknows of no better place to ask (take that as a compliment folks!), mehas the following question *cue drums*: Is SIZE_MAX guaranteed to *not* be greater than the highest address? Me'd be grateful for any insight anyone can offer. Thanks in advance, Baai, --zeurkous. -- Friggin' Machines!
oops (was: unsubscription from misc@)
Fsck, me sleepy head typed 'isc' instead of the intended 'ajordomo'... Suffice is to say that mehad enough of the bickering for a while. --zeur. -- Friggin' Machines!
RE: mdoc(7) syntax and semantics, was: axe(4) ...
ot;' | mandoc -mdoc
> [...]
> -x;
>
> $ echo '.Fl x \&;' | mandoc -mdoc
> [...]
> -x -;
>
> Quoting punctuation with "" only affects argument parsing. The macro
> still sees a bare semicolon and treats it as punctuation, not as text,
> like it would when the semicolon were escaped with \&.
Thanks, that it useful.
>>> But such a command would be weirdly named indeed, and appending
>>> an internal command to a variable name would make no sense either.
>
>> Well, what do you suggest? Just include C syntax elements as plain text?
>
> Fot syntax elements that are mere punctuation, yes. Usually,
> punctuation is not marked up in mdoc(7), not even when it has a
> syntactic meaning in the language being documented.
Weird, me's never thought of it as 'punctuation'... but mesupposes
you're not quite wrong w/ that classification. Again, mehas to give this
some thought.
>> Interesting. It would appear that both and Va and Vt have the capacity
>> for conflating type and variable names.
>
> Yes, by historic accident.
>
>> Unless me's seriously mistaken: the whole point of mdoc(7) is to not do
>> that kind of thing anymore.
>
> Yes, mdoc(7) is supposed to do semantic markup.
>
>>> Note that the trailing semicolon is just punctuation, so it is
>>> actually important to *not* escape or quote it.
>
>> You suggest depending on the overlap between C and roff to handle the
>> semicolon properly? Or is memissing something?
>
> I don't understand what you mean by "overlap" and by "handle",
> so i can't answer this question.
Overlap in the sense that both in "natural language" and in C, the
semicolon has a similar meaning, so they can be treated ("handled"), by
roff and by us, the same way.
>>> The forms
>>>
>>> .Va struct blaat scaahp ;
>>> .Vt struct blaat Va scaahp ;
>>>
>>> are also acceptable albeit less common.
>>> No quoting or escaping either way...
>
>> Strange, this would really seem to fly in the face of the idea behind
>> mdoc(7).
>
> It seems you have a point.
>
> Right now, mdoc(7) is documenting existing practice.
Of course.
> But it appears there would likely be no downside in encouraging
> authors to always write ".Vt struct blaat Va scaahp" in new pages
> and fix the markup when they come across ".Va int i" or ".Vt int
> i" in old pages.
And then please to quote "struct blaat" so that the underlining will be
unbroken (at least in the future, should the macros be fixed).
> Maybe i should suggest a stricter wording for .Vt and .Va in mdoc(7)
> and groff_mdoc(7) and maybe we should improve existing manuals.
> But it needs some thought because in the SYNOPSIS, .Vt is a block
> macro, so ".Vt extern char * Ns Va optarg ;" puts the .Va inside
> the .Vt block. I need to check that doesn't have detrimental side
> effects.
Yes. Perhaps it was a mistake to make macros have different effects
depending on the section...
> For now, i have made a note in the mandoc
> https://cvsweb.bsd.lv/mandoc/TODO :
>
> - Can the distinction between .Vt and .Va be made stricter,
> recommending .Vt extern char * Ns Va optarg ; ?
> What about the block macro properties of .Vt in the SYNOPSIS?
> zeurkous 25 Dec 2019 08:48:36 +0100
>
Very good, we'll let this percolate further.
>>> Quoting with "" *is* needed in cases where it matters that two words
>>> are kept together in a single macro argument even though there is
>>> a space character between them in the source:
>>>
>>> .Sh SYNOPSIS
>>> .Ft double
>>> .Fn sin "double x"
>>>
>>> But that certainly isn't needed for .Vt. Relatively few macros
>>> care, most prominently .Fa and .Fn.
>
>> Yet they might care one day. What if someone'd decide to make variable
>> type names appear in a different way from the variable names themselves?
>
> That is already possible with user-defined CSS in HTML output mode,
> see https://cvsweb.bsd.lv/mandoc/mandoc.css for the defaults.
Mesees me point proven .
> Yours,
> Ingo
Good holidays (assuming you celebrate),
--zeurkous.
--
Friggin' Machines!
RE: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] > Hi, Haai, "Ingo Schwarze" wrote: > just FYI: > > zeurk...@volny.cz wrote on Tue, Dec 17, 2019 at 08:10:10PM +0100: >> jmc@ wrote: > >>> Dq produces "", so use either Dq or "". > >> Medoes it for consistency with cases like: >> >> .Vt "struct blaat" Va scaahp Ns Ic ";" >> >> where the quotes are part of the invocation syntax. > > Not really. > > The arguments of .Vt almost never need quoting, not even if there > are other macros before or after it on the same input line. *shrugs* To me, there is a real difference between "struct blaat" and "struct" "blaat" (the latter would imply two separate types), but obviously YMDV :) In fact, it's an old peeve of mine that even when quoting the arguments, the underlining in the output is not applied to the spaces. > The usual way to quote punctuation is by prepending a zero-width > space, so if you really wanted to talk about a command called ";", > you would write: .Ic \&; Me'll give that some thought, although me'll already argue that ";" is (to me) a little more readable. > But such a command would be weirdly named indeed, and appending > an internal command to a variable name would make no sense either. Well, what do you suggest? Just include C syntax elements as plain text? > If "scaahp" is a global variable, the best way to mention it is > simply > > .Vt struct blaat scaahp ; Except that scaahp is not a type, not a syntax element, but a variable: we have Va for that. > as documented in the mdoc(7) manual: > > https://man.openbsd.org/mdoc.7#Vt_2 Interesting. It would appear that both and Va and Vt have the capacity for conflating type and variable names. Unless me's seriously mistaken: the whole point of mdoc(7) is to not do that kind of thing anymore. > Note that the trailing semicolon is just punctuation, so it is > actually important to *not* escape or quote it. You suggest depending on the overlap between C and roff to handle the semicolon properly? Or is memissing something? > The forms > > .Va struct blaat scaahp ; > .Vt struct blaat Va scaahp ; > > are also acceptable albeit less common. > No quoting or escaping either way... Strange, this would really seem to fly in the face of the idea behind mdoc(7). > Quoting with "" *is* needed in cases where it matters that two words > are kept together in a single macro argument even though there is > a space character between them in the source: > > .Sh SYNOPSIS > .Ft double > .Fn sin "double x" > > But that certainly isn't needed for .Vt. Relatively few macros > care, most prominently .Fa and .Fn. Yet they might care one day. What if someone'd decide to make variable type names appear in a different way from the variable names themselves? Me'd hate the poor sod having to fix lots of manual pages *just* to get a trivial change in the pretty-printing to work correctly. It would make sense to presume that, when mdoc(7) was still new, the implications of moving away from the "as long as it looks good on my terminal" approach hadn't completely sunk in yet. But as it'll be 2020 in a matter of days, we really ought to either honor its basic ideas, or come up with something better. The latter could take the form of a generic C pretty-printer that can be called as a roff macro, and produces roff output. > Yours, > Ingo Baai, --zeurkous. -- Friggin' Machines!
RE: RE: RE: RE: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] theo wrote: > wrote: > >> [not subscribed, please Cc, thanks.] >> >> theo wrote: >> > wrote: >> > >> >> [not subscribed, please Cc, thanks.] >> >> >> >> theo wrote: >> >> > wrote: >> >> > >> >> >> [not subscribed, please Cc, thanks.] >> >> >> >> >> >> "Jason McIntyre" wrote: >> >> >> > >> >> >> > hi. the "asix chipset" bit seems unneccessary, since the driver is >> >> >> > only >> >> >> > for asix chips (as far as i can tell) and quickly skimming online >> >> >> > fails >> >> >> > to turn up such a model with a different chipset. >> >> >> >> >> >> Dunno, there might well be a "plain" version with another (unspecified) >> >> >> chipset, in which case we'd be confusing people... >> >> > >> >> > How true. Except there might also be two completely difference ones >> >> > which look identical in the box. And your description might not >> >> > differentiate >> >> > between them! >> >> >> >> It does, however, constitute a hint that all might not be what it seems. >> > >> > No, because you've been too precis and claim others don't exist. >> >> Menever made that claim. Indeed, meput the double qotes there to signify >> a *lack* of precision (thought merealizes not everyone might understand >> that meaning). > > i'm out of arguments so i think i'll stamp on the floor FTFY. --zeur. -- Friggin' Machines!
RE: RE: RE: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] theo wrote: > wrote: > >> [not subscribed, please Cc, thanks.] >> >> theo wrote: >> > wrote: >> > >> >> [not subscribed, please Cc, thanks.] >> >> >> >> "Jason McIntyre" wrote: >> >> > >> >> > hi. the "asix chipset" bit seems unneccessary, since the driver is only >> >> > for asix chips (as far as i can tell) and quickly skimming online fails >> >> > to turn up such a model with a different chipset. >> >> >> >> Dunno, there might well be a "plain" version with another (unspecified) >> >> chipset, in which case we'd be confusing people... >> > >> > How true. Except there might also be two completely difference ones >> > which look identical in the box. And your description might not >> > differentiate >> > between them! >> >> It does, however, constitute a hint that all might not be what it seems. > > No, because you've been too precis and claim others don't exist. Menever made that claim. Indeed, meput the double qotes there to signify a *lack* of precision (thought merealizes not everyone might understand that meaning). --zeur. -- Friggin' Machines!
RE: RE: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] theo wrote: > wrote: > >> [not subscribed, please Cc, thanks.] >> >> "Jason McIntyre" wrote: >> > >> > hi. the "asix chipset" bit seems unneccessary, since the driver is only >> > for asix chips (as far as i can tell) and quickly skimming online fails >> > to turn up such a model with a different chipset. >> >> Dunno, there might well be a "plain" version with another (unspecified) >> chipset, in which case we'd be confusing people... > > How true. Except there might also be two completely difference ones > which look identical in the box. And your description might not differentiate > between them! It does, however, constitute a hint that all might not be what it seems. > The point is our manual pages cannot be overly exact and proscriptive when > we aren't in position of 100% of the facts. Of course -- mehas no objection to leaving it out. --zeur. -- Friggin' Machines!
RE: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] > On Tue, Dec 17, 2019 at 06:12:12PM +, Jason McIntyre wrote: > > i committed this without the asix chipset part. Thanks! > for future reference: >[snip] >> > .\" >> > -.Dd $Mdocdate: July 16 2013 $ >> > +.Dd $Mdocdate: December 17 2019 $ > > don;t bump Mdocdate. it updates on commit. Oh, sorry, meupdated a ton of nnx man pages in the past few days and is still kind of in the flow =) > Dq produces "", so use either Dq or "". Medoes it for consistency with cases like: .Vt "struct blaat" Va scaahp Ns Ic ";" where the quotes are part of the invocation syntax. --zeurkous. > jmc -- Friggin' Machines!
RE: axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] "Jason McIntyre" wrote: > > hi. the "asix chipset" bit seems unneccessary, since the driver is only > for asix chips (as far as i can tell) and quickly skimming online fails > to turn up such a model with a different chipset. Dunno, there might well be a "plain" version with another (unspecified) chipset, in which case we'd be confusing people... > unless you have any more info, i guess we could commit without that > part. Up to you :) --zeur. > > jmc -- Friggin' Machines!
axe(4) success with 'Delock Gigabit USB 2.0 Ethernet Adapter, "ASIX chipset"' (w/ manual patch)
[not subscribed, please Cc, thanks.] Haai, Mewas actually looking for a Cardbus adapter, but availability issues made me have to go with USB again... at least it works :) > axe0 at uhub0 port 2 configuration 1 interface 0 "ASIX Electronics AX88178" > rev 2.00/0.01 addr 2 > axe0: AX88178, address XX:CE:NS:OR:ED:XX > rgephy0 at axe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 2 The box only specifies "ASIX chipset", but after studying the manual pages, it did make me take the plunge. Given that most manufacturers apparently refuse to specify even that much, mesupposes we're lucky in this case... ...manual patch below. --zeurkous. Index: src/share/man/man4/axe.4 === RCS file: /cvs/src/share/man/man4/axe.4,v retrieving revision 1.45 diff -u -p -u -r1.45 axe.4 --- src/share/man/man4/axe.416 Jul 2013 16:05:48 - 1.45 +++ src/share/man/man4/axe.417 Dec 2019 11:20:12 - @@ -31,7 +31,7 @@ .\" $FreeBSD: /repoman/r/ncvs/src/share/man/man4/axe.4,v 1.3 2003/05/29 21:28:35 ru Exp $ .\" $OpenBSD: axe.4,v 1.45 2013/07/16 16:05:48 schwarze Exp $ .\" -.Dd $Mdocdate: July 16 2013 $ +.Dd $Mdocdate: December 17 2019 $ .Dt AXE 4 .Os .Sh NAME @@ -58,6 +58,7 @@ following: .It Buffalo(MELCO) LUA-U2-KTX .It Corega FEther USB2-TX .It D-Link DUB-E100 +.It Delock Gigabit USB 2.0 Ethernet Adapter, Dq "ASIX chipset" .It Good Way GWUSB2E .It Hawking UF200 .It Intellinet USB 2.0 to Ethernet (rev A)
FU: RE: 6.6/packages/i386/SHA256.sig to be verified with 'openbsd-65-pkg.pub'?
Evening, mewrote: > theo wrote: >> >> These files have now been replaced. Does it look right? > > Me's afraid not: SHA256.sig is now rather short, ending at the hash of > aqsis-1.8.2p10.tgz (tried to fetch it from both ftp.eu and the CDN: same > result). ...which now appears to have been fixed. Thanks! --zeurkous. -- Friggin' Machines!
RE: 6.6/packages/i386/SHA256.sig to be verified with 'openbsd-65-pkg.pub'?
Morning, theo wrote: > wrote: > >> That doesn't seem right. Did you folks use the wrong key when signing >> the file, or is there a particular reason to do it this way that me's >> not aware of...? > > These files have now been replaced. Does it look right? Me's afraid not: SHA256.sig is now rather short, ending at the hash of aqsis-1.8.2p10.tgz (tried to fetch it from both ftp.eu and the CDN: same result). It's a bad week over here, too *sigh*. --zeur. -- Friggin' Machines!
6.6/packages/i386/SHA256.sig to be verified with 'openbsd-65-pkg.pub'?
That doesn't seem right. Did you folks use the wrong key when signing the file, or is there a particular reason to do it this way that me's not aware of...? --zeur. -- Friggin' Machines!
dmesg of OpenBSD 6.6 (GENERIC.MP) on 'Thinkpad R60e (type 9461)'
[not subscribed, please Cc, thanks.]
> OpenBSD 6.6 (GENERIC.MP) #304: Sat Oct 12 11:18:21 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> real mem = 3219472384 (3070MB)
> avail mem = 3145039872 (2999MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 10/13/06, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @
> 0xe0010 (68 entries)
> bios0: vendor LENOVO version "7CETB5WW (2.05 )" date 10/13/2006
> bios0: LENOVO 9461DXG
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4)
> PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
> GHz, 06-0f-06
> cpu0:
> FPU,V86,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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF,SENSOR,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
> GHz, 06-0f-06
> cpu1:
> FPU,V86,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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF,SENSOR,MELTDOWN
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus 4 (EXP2)
> acpiprt5 at acpi0: bus 12 (EXP3)
> acpiprt6 at acpi0: bus 21 (PCI1)
> acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> "PNP0A08" at acpi0 not configured
> acpicmos0 at acpi0
> acpibat0 at acpi0: BAT0 model "92P1139" serial 5142 type LION oem "Panasonic"
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> acpidock0 at acpi0: GDCK not docked (0)
> acpivideo0 at acpi0: VID_
> acpivout0 at acpivideo0: LCD0
> acpivideo1 at acpi0: VID_
> acpivout at acpivideo1 not configured
> bios0: ROM list: 0xc/0xfc00 0xd/0x1600 0xd1800/0x1000 0xdc000/0x4000!
> 0xe/0x1!
> cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility X1400" rev 0x00
> drm0 at radeondrm0
> radeondrm0: apic 1 int 16
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
> azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog
> Devices AD1981HD
> audio0 at azalia0
> ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
> pci2 at ppb1 bus 2
> bge0 at pci2 dev 0 function 0 "Broadcom BCM5751M" rev 0x21, BCM5750 C1
> (0x4201): msi, address XX:CE:NS:OR:ED:XX
> brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
> pci3 at ppb2 bus 3
> ath0 at pci3 dev 0 function 0 "Atheros AR5212" rev 0x01: apic 1 int 17
> ath0: AR5424 10.3 phy 6.1 rf5424 10.2 eeprom 5.3, WOR2W, address
> XX:CE:NS:OR:ED:XX
> ppb3 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
> pci4 at ppb3 bus 4
> ppb4 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
> pci5 at ppb4 bus 12
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
> addr 1
> ppb5 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
> pci6 at ppb5
dmesg of OpenBSD 6.6 (GENERIC) on 'Thinkpad R60e (type 9461)'
[not subscribed, please Cc, thanks.]
> OpenBSD 6.6 (GENERIC) #298: Sat Oct 12 11:06:10 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 3219472384 (3070MB)
> avail mem = 3145138176 (2999MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 10/13/06, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @
> 0xe0010 (68 entries)
> bios0: vendor LENOVO version "7CETB5WW (2.05 )" date 10/13/2006
> bios0: LENOVO 9461DXG
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4)
> PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
> GHz, 06-0f-06
> cpu0:
> FPU,V86,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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF,SENSOR,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus 4 (EXP2)
> acpiprt5 at acpi0: bus 12 (EXP3)
> acpiprt6 at acpi0: bus 21 (PCI1)
> acpicpu0 at acpi0: !C3(250@17 mwait.3@0x20), !C2(500@1 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 100 degC
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: SLPB
> "PNP0A08" at acpi0 not configured
> acpicmos0 at acpi0
> acpibat0 at acpi0: BAT0 model "92P1139" serial 5142 type LION oem "Panasonic"
> acpiac0 at acpi0: AC unit online
> acpithinkpad0 at acpi0
> acpidock0 at acpi0: GDCK not docked (0)
> acpivideo0 at acpi0: VID_
> acpivout0 at acpivideo0: LCD0
> acpivideo1 at acpi0: VID_
> acpivout at acpivideo1 not configured
> bios0: ROM list: 0xc/0xfc00 0xd/0x1600 0xd1800/0x1000 0xdc000/0x4000!
> 0xe/0x1!
> cpu0: Enhanced SpeedStep 1829 MHz: speeds: 1833, 1333, 1000 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
> pci1 at ppb0 bus 1
> radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility X1400" rev 0x00
> drm0 at radeondrm0
> radeondrm0: apic 1 int 16
> azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
> azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog
> Devices AD1981HD
> audio0 at azalia0
> ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
> pci2 at ppb1 bus 2
> bge0 at pci2 dev 0 function 0 "Broadcom BCM5751M" rev 0x21, BCM5750 C1
> (0x4201): msi, address XX:CE:NS:OR:ED:XX
> brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
> pci3 at ppb2 bus 3
> ath0 at pci3 dev 0 function 0 "Atheros AR5212" rev 0x01: apic 1 int 17
> ath0: AR5424 10.3 phy 6.1 rf5424 10.2 eeprom 5.3, WOR2W, address
> XX:CE:NS:OR:ED:XX
> ppb3 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
> pci4 at ppb3 bus 4
> ppb4 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
> pci5 at ppb4 bus 12
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
> addr 1
> ppb5 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
> pci6 at ppb5 bus 21
> cbb0 at pci6 dev 0 function 0 "TI PCIXX12 CardBus" rev 0x00: apic 1 int 16
> "TI PCIXX12 FireWire" rev 0x00 at pci6 dev 0 function 1 not configured
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0
> pcmcia0 at cardslot0
> ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
> pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA,
Thinkpad R40 varia (1)
[not subscribed, please Cc, thanks.] Me's retiring the R40 in its current capacity, so let me wind up a couple of things: There was nothing wrong with the CMOS battery; the seller gave me the impression that the machine had been used recently, but menow suspects that quite not to be the case, hence me confusion. The general battery, which is an original, still lasts about an hour despite its age. Mefound this out 'cause at one point it got unplugged by accident, by a family member, shortly after a call from nature ensured me momentary absence. In the midst of the summer heat, the hdd got sick and had to be replaced with a spare, which is now also breaking down (granted, both hdds are about equally old...). It appears characteristic even of the 'new' R60e to be inadequate at cooling the hdd; merecommends a cooling pad when not underway. (A metal desk may also be effective as a workaround, but one does not always have that luxury.) The USB sockets continue to provide power when the machine is otherwise off; given the above, this is a good thing(tm). While lacking any of the 'windoze' or menu keys, the card keys have been useful to provide me with 24 virtual terminals (courtesy of me own wscons(4) patches; see tech@). Menever got the ipw(4) to work, but the seller (who ran windoze...) warned me of that before the sale, so mefigures it's a hardware problem. The R40 will now be used for odds and ends only, but it has certainly served me well. --zeurkous. -- Friggin' Machines!
dmesg of OpenBSD 6.6 (RAMDISK_CD) on 'Thinkpad R60e (type 9461)'
[not subscribed, please Cc, thanks.]
> OpenBSD 6.6 (RAMDISK_CD) #294: Sat Oct 12 11:29:03 MDT 2019
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> real mem = 3219439616 (3070MB)
> avail mem = 3151642624 (3005MB)
> mainbus0 at root
> bios0 at mainbus0: date 10/13/06, BIOS32 rev. 0 @ 0xfd690, SMBIOS rev. 2.4 @
> 0xe0010 (68 entries)
> bios0: vendor LENOVO version "7CETB5WW (2.05 )" date 10/13/2006
> bios0: LENOVO 9461DXG
> acpi0 at bios0: ACPI 3.0
> acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET BOOT SSDT SSDT SSDT SSDT
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class) 1.83
> GHz, 06-0f-06
> cpu0:
> FPU,V86,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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu at mainbus0: not configured
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus 4 (EXP2)
> acpiprt5 at acpi0: bus 12 (EXP3)
> acpiprt6 at acpi0: bus 21 (PCI1)
> acpicpu at acpi0 not configured
> acpipwrres at acpi0 not configured
> acpitz at acpi0 not configured
> acpitz at acpi0 not configured
> "PNP0C0D" at acpi0 not configured
> "PNP0C0E" at acpi0 not configured
> "PNP0A08" at acpi0 not configured
> acpicmos0 at acpi0
> "PNP0C0A" at acpi0 not configured
> "ACPI0003" at acpi0 not configured
> "IBM0068" at acpi0 not configured
> bios0: ROM list: 0xc/0xfc00 0xd/0x1600 0xd1800/0x1000 0xdc000/0x4000!
> 0xe/0x1!
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
> ppb0 at pci0 dev 1 function 0 "Intel 82945GM PCIE" rev 0x03: apic 1 int 16
> pci1 at ppb0 bus 1
> vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility X1400" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> "Intel 82801GB HD Audio" rev 0x02 at pci0 dev 27 function 0 not configured
> ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 1 int 20
> pci2 at ppb1 bus 2
> bge0 at pci2 dev 0 function 0 "Broadcom BCM5751M" rev 0x21, BCM5750 C1
> (0x4201): msi, address XX:CE:NS:OR:ED:XX
> brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
> ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 1 int 21
> pci3 at ppb2 bus 3
> ath0 at pci3 dev 0 function 0 "Atheros AR5212" rev 0x01: apic 1 int 17
> ath0: AR5424 10.3 phy 6.1 rf5424 10.2 eeprom 5.3, WOR2W, address
> XX:CE:NS:OR:ED:XX
> ppb3 at pci0 dev 28 function 2 "Intel 82801GB PCIE" rev 0x02: apic 1 int 22
> pci4 at ppb3 bus 4
> ppb4 at pci0 dev 28 function 3 "Intel 82801GB PCIE" rev 0x02: apic 1 int 23
> pci5 at ppb4 bus 12
> uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 1 int 19
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
> addr 1
> ppb5 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
> pci6 at ppb5 bus 21
> cbb0 at pci6 dev 0 function 0 "TI PCIXX12 CardBus" rev 0x00: apic 1 int 16
> "TI PCIXX12 FireWire" rev 0x00 at pci6 dev 0 function 1 not configured
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 22 device 0 cacheline 0x8, lattimer 0xb0
> pcmcia0 at cardslot0
> pcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02
> pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x02: DMA, channel
> 0 configured to compatibility, channel 1 configured to compatibility
> atapiscsi0 at pciide0 channel 0 drive 0
> scsibus0 at atapiscsi0: 2 targets
> cd0 at scsibus0 targ 0 lun 0: removable
> cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI" rev 0x02: msi, AHCI 1.1
> ahci0: port 0: 1.5Gb/s
> scsibus1 at ahci0: 32 targets
> sd0 at scsibus1 targ 0 lun 0:
> naa.CENSOREDCENSORED
> sd0: 305245MB, 512 bytes/sector, 625142448 sectors
> "Intel 82801GB SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
> addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
> addr 1
> usb3 at uhci2: USB revision 1.0
> uhub3 at usb
RE: dmesg: 6.5 i386 GENERIC on 'Thinkpad R40 (type 2722)'
Haai, i...@openbsd.org wrote: > > Thank you for your dmesg, however, in the future would you mind sending > these to dm...@openbsd.org instead of the mailing lists? dmesg@ is a > special mailbox that will automatically add your dmesg to our archives > in a more helpful way. Of course, me's sorry, mewas unaware :) --zeur. -- Friggin' Machines!
dmesg: 6.5 i386 GENERIC on 'Thinkpad R40 (type 2722)'
[not subscribed, please Cc, thanks.]
OpenBSD 6.5 (GENERIC) #1338: Sat Apr 13 15:07:04 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 535707648 (510MB)
avail mem = 510660608 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/15/03, BIOS32 rev. 0 @ 0xfd7b0, SMBIOS rev. 2.31 @
0xe0010 (53 entries)
bios0: vendor IBM version "1PET46WW (1.14 )" date 07/15/2003
bios0: IBM 27223DG
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA BOOT
acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) PCI0(S3) PCI1(S4) USB0(S3)
USB1(S3) USB2(S3) AC9M(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (PCI1)
acpipwrres0 at acpi0: PUBS, resource for USB0, USB1, USB7
acpitz0 at acpi0: critical temperature is 97 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpicmos0 at acpi0
"IBM0071" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "IBM-02K6928" serial 2694 type LION oem
"Panasonic"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
"PNP0A03" at acpi0 not configured
acpivideo0 at acpi0: VID_
bios0: ROM list: 0xc/0x1 0xe/0x1
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Pentium(R) M processor 1300MHz ("GenuineIntel" 686-class) 1.30
GHz, 06-09-05
cpu0:
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: Enhanced SpeedStep 1300 MHz: speeds: 1300, 1200, 1000, 800, 600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xd000, size 0x1000
ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00
drm0 at radeondrm0
radeondrm0: irq 11
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
pci2 at ppb1 bus 2
cbb0 at pci2 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: irq 11
ipw0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq 11,
address XX:CE:NS:OR:ED:XX
"TI TSB43AB21 FireWire" rev 0x00 at pci2 dev 7 function 0 not configured
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x81, i82562: irq 11,
address XX:CE:NS:OR:ED:XX
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
ichpcib0 at pci0 dev 31 function 0 "Intel 82801DBM LPC" rev 0x01
pciide0 at pci0 dev 31 function 1 "Intel 82801DBM IDE" rev 0x01: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 38154MB, 78140160 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
ichiic0 at pci0 dev 31 function 3 "Intel 82801DB SMBus" rev 0x01: irq 11
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 256MB DDR SDRAM non-parity PC2100CL2.5
spdmem1 at iic0 addr 0x51: 256MB DDR SDRAM non-parity PC2100CL2.5
auich0 at pci0 dev 31 function 5 "Intel 82801DB AC97" rev 0x01: irq 11, ICH4
ac97: codec id 0x41445374 (Analog Devices AD1981B)
ac97: codec features headphone, 20 bit DAC, No 3D Stereo
audio0 at auich0
"Intel 82801DB Modem" rev 0x01 at pci0 dev 31 function 6 not configured
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt2 at isa0 port 0x3bc/4: polled
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (b96d3e13d99e46ea.a) swap on wd0b dump on wd0b
initializing kernel modesetting (RV200 0x1002:0x4C57 0x1014:0x0527).
radeon_cp: Failed to
RE: When will be created a great desktop experience for OpenBSD?
[responding to this little gem I just found in the archives...] Ingo wrote on 2019-05-14 13:54:38: > That's entirely a matter of taste. >[snip rant] Ingo, we don't often seem to agree, but mecouldn't have said what you just did any better. In particular, me'd like to reinforce this point: > Automation is precisely the main advantage of CLIs over GUIs. with a translated quote from Gerrit Krol (I only know the quote, not him, and not his books), as it used to appear in the front of every book written or published by the somewhat legendary Pim Oets: "Computers are needed where the work becomes boring. Work that is boring and yet has to be done, can be done by a computer. It is therefore good that computers exist." Amen. --zeurkous. -- Friggin' Machines!
dmesg: 6.5 i386 RAMDISK_CD on 'ASUS K52F'
[not subscribed, please Cc, thanks]
OpenBSD 6.5 (RAMDISK_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem = 3066560512 (2924MB)
avail mem = 3001561088 (2862MB)
mainbus0 at root
bios0 at mainbus0: date 10/30/09, SMBIOS rev. 2.6 @ 0xec3d0 (77 entries)
bios0: vendor American Megatrends Inc. version "K52F.210" date 08/30/2010
bios0: ASUSTeK Computer Inc. K52F
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC DBGP ECDT SLIC MCFG HPET SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz ("GenuineIntel" 686-class) 2.40
GHz, 06-25-05
cpu0:
FPU,V86,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,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT,MELTDOWN
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG3)
acpiprt3 at acpi0: bus -1 (PEG5)
acpiprt4 at acpi0: bus 5 (P0P1)
acpiprt5 at acpi0: bus 1 (RP01)
acpiprt6 at acpi0: bus 2 (RP02)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus 4 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiprt12 at acpi0: bus 3 (RP03)
acpicpu at acpi0 not configured
acpitz at acpi0 not configured
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"ETD0001" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"PNP0A03" at acpi0 not configured
"ATK0100" at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
bios0: ROM list: 0xc/0xfc00! 0xd/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x18
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x18
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
"Intel 3400 HD Audio" rev 0x06 at pci0 dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel 3400 PCIE" rev 0x06: apic 2 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 3400 PCIE" rev 0x06: apic 2 int 17
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 2 int 17
athn0: AR9285 rev 2 (1T1R), ROM rev 13, address xx:xx:xx:xx:xx:xx
ppb2 at pci0 dev 28 function 2 "Intel 3400 PCIE" rev 0x06: apic 2 int 18
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 5 "Intel 3400 PCIE" rev 0x06: apic 2 int 17
pci4 at ppb3 bus 4
"JMicron SD/MMC" rev 0x80 at pci4 dev 0 function 0 not configured
sdhc0 at pci4 dev 0 function 2 "JMicron SD Host Controller" rev 0x80: apic 2
int 18
sdhc0: SDHC 2.0, 50 MHz base clock
sdmmc0 at sdhc0: 4-bit, dma
"JMicron Memory Stick" rev 0x80 at pci4 dev 0 function 3 not configured
"JMicron xD" rev 0x80 at pci4 dev 0 function 4 not configured
jme0 at pci4 dev 0 function 5 "JMicron JMC250" rev 0x03: msi, address
xx:xx:xx:xx:xx:xx
jmphy0 at jme0 phy 1: JMP211 10/100/1000 PHY, rev. 1
ehci1 at pci0 dev 29 function 0 "Intel 3400 USB" rev 0x06: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xa6
pci5 at ppb4 bus 5
pcib0 at pci0 dev 31 function 0 "Intel HM55 LPC" rev 0x06
ahci0 at pci0 dev 31 function 2 "Intel 3400 AHCI" rev 0x06: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 1.5Gb/s
ahci0: PHY offline on port 4
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed
xxx.
sd0: 305245MB, 512 bytes/sector, 625142448 sectors
cd0 at scsibus0 targ 1 lun 0: ATAPI 5/cdrom
removable
"Intel 3400 SMBus" rev 0x06 at pci0 dev 31 function 3 not configured
"Intel 3400 Thermal" rev 0x06 at pci0 dev 31 function 6 not configured
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
pci6 at mainbus0 bus 255
pchb1 at pci6 dev 0 function 0 "Intel QuickPath" rev 0x05
pchb2 at pci6 dev 0 function 1 "Intel QuickPath" rev 0x05
pchb3 at pci6 dev 2 function 0 "Intel QPI Link" rev 0x05
pchb4 at pci6 dev 2 function 1 "Intel QPI Physical" rev 0x05
pchb5 at pci6 dev 2 function 2 "Intel Reserved" rev 0x05
pchb6 at pci6 dev 2
dmesg: 6.5 i386 RAMDISK_CD on 'Thinkpad R40 (type 2722)'
[not subscribed, please Cc, thanks.]
OpenBSD 6.5 (RAMDISK_CD) #1326: Sat Apr 13 15:26:51 MDT 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem = 535752704 (510MB)
avail mem = 516853760 (492MB)
mainbus0 at root
bios0 at mainbus0: date 07/15/03, BIOS32 rev. 0 @ 0xfd7b0, SMBIOS rev. 2.31 @
0xe0010 (53 entries)
bios0: vendor IBM version "1PET46WW (1.14 )" date 07/15/2003
bios0: IBM 27223DG
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT TCPA BOOT
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (AGP_)
acpiprt2 at acpi0: bus 2 (PCI1)
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
acpicmos0 at acpi0
"IBM0071" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"IBM0068" at acpi0 not configured
"PNP0A03" at acpi0 not configured
bios0: ROM list: 0xc/0x1 0xe/0x1
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Pentium(R) M processor 1300MHz ("GenuineIntel" 686-class) 1.30
GHz, 06-09-05
cpu0:
FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,EST,TM2,PERF,MELTDOWN
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82855PM Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82855PM AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "ATI Radeon Mobility M7" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
uhci0 at pci0 dev 29 function 0 "Intel 82801DB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801DB USB" rev 0x01: irq 11
uhci2 at pci0 dev 29 function 2 "Intel 82801DB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801DB USB" rev 0x01: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0x81
pci2 at ppb1 bus 2
cbb0 at pci2 dev 0 function 0 "TI PCI1510 CardBus" rev 0x00: irq 11
ipw0 at pci2 dev 2 function 0 "Intel PRO/Wireless 2100" rev 0x04: irq 11,
address xx:xx:xx:xx:xx:xx
"TI TSB43AB21 FireWire" rev 0x00 at pci2 dev 7 function 0 not configured
fxp0 at pci2 dev 8 function 0 "Intel PRO/100 VE" rev 0x81, i82562: irq 11,
address xx:xx:xx:xx:xx:xx
inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0
cardslot0 at cbb0 slot 0 flags 0
cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0
pcmcia0 at cardslot0
pcib0 at pci0 dev 31 function 0 "Intel 82801DBM LPC" rev 0x01
pciide0 at pci0 dev 31 function 1 "Intel 82801DBM IDE" rev 0x01: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 38154MB, 78140160 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
"Intel 82801DB SMBus" rev 0x01 at pci0 dev 31 function 3 not configured
"Intel 82801DB AC97" rev 0x01 at pci0 dev 31 function 5 not configured
"Intel 82801DB Modem" rev 0x01 at pci0 dev 31 function 6 not configured
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00
addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
softraid0 at root
scsibus1 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
--
Friggin' Machines!
