Re: sensorsd says the sensor is within limit, but it's not...
On Wednesdayen den 4 July 2007 04.17.30 you wrote:
On 03/07/07, Per-Olov Sjvholm [EMAIL PROTECTED] wrote:
Hi Misc
I am probably missing something, but what..
sensorsd says in the syslog that the sensor is within limits even
though a sysctl -a|grep sensor shows that it is not.
Are there any known bugs? I have checked the list and cannot find
anything related to this... I run a Dell PE830 on OpenBSD 4.0 stable
(latest update in May 25:th). I have these sensors which appears to
always show the correct values running a sysctl -a|grep sensor.
hw.sensors.0=ipmi0, Temp, 43.00 degC, OK
hw.sensors.1=ipmi0, Planar Temp, 38.00 degC, OK
hw.sensors.2=ipmi0, CMOS Battery, 3.13 V DC, OK
hw.sensors.3=ipmi0, Back Fan, 2204 RPM, OK
hw.sensors.4=ipmi0, Intrusion, Off, OK
hw.sensors.5=ami0, sd0, drive online, OK
From sensords.conf
hw.sensors.0:high=42C:command=/bin/echo test test|/usr/bin/mailx -s
Sensor warning: CPU temp over %2 bla bla bla MYEMAIL
hw.sensors.1:high=39C:command=/bin/echo test test|/usr/bin/mailx -s
Sensor warning: Chassie temp over %2 bla bla bla MYEMAIL
Starting sensorsd and look at /var/log/daemon
Jul 3 16:12:22 xanadu sensorsd[14634]: hw.sensors.0: within limits,
value: 43.00 degC
Jul 3 16:12:22 xanadu sensorsd[14634]: hw.sensors.1: within limits,
value: 38.00 degC
I assume I receive no reports as the daemon say the sensor wrongly is
within the limits
Please, check the manual page for your system [0], specifically, the
following:
Sensors that provide status (such as from bio(4), esm(4), or ipmi(4))
do not require boundary values specified (that otherwise will be ignored)
and simply trigger on status transitions.
In other words, for those sensors that provide the status themselves,
the keywords high and low in sensorsd.conf have no effect. This
limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
4.1-current allows you to set your own limits for any sensor, and
ignore the status that the sensor device itself provides.
So if you need this functionality, you may wish to upgrade to OpenBSD
4.1-current.
Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework, and then manually update sensorsd to
4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
compiling and installing it afterwards -- sensorsd in 4.1-current as
of today is source-code-compatible with 4.1-stable (note that it is
not binary compatible). However, please be warned that mixing
4.1-stable and 4.1-current is not officially supported, so use it at
your own risk! (Even though it works for me in this specific case with
sensorsd.)
Cheers,
Constantine. :)
[0]
http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.confsektion=5manpat
h=OpenBSD+4.0
[1]
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1
.32
Thanks for the answer
So I only need the command with %1-%4 and no low/high specs in
sensorsd.conf? The trigger will come when Dell think the temp i to low or
high? If so... Is there a way of knowing at what temperature this happends. I
mean, could you ask the hardware itself with any software, or do I have to
dig into some of Dell:s docs? That is not super important, but it would be
nice to know at what value it happends, and if possible test it.
Also, isn't it possible then to have different commands for low and high if
low and high has no meanings? I mean, do I have to take care of if it's a low
or a high warning in the command script. If low and high have meanings (as in
OBSD 4.1-current) I could have one sensor row in sensorsd.conf for high and
one for low with different commands. Right?
You said that:
Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework Why do I need to go to -CURRENT if it's included
in 4.1-STABLE? Isn't 4.1-STABLE ok? I want to avoid -current on production
servers. But after looking at
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c it
seems I am *not* OK with just 4.1 STABLE, and that I need -CURRENT if I want
this functionality...
Per-Olov
--
GPG keyID: 4DB283CE
GPG fingerprint: 45E8 3D0E DE05 B714 D549 45BC CFB4 BBE9 4DB2 83CE
GPG key:
http://keyserv.nic-se.se:11371/pks/lookup?op=getsearch=0xCFB4BBE94DB283CE
Re: trunk, carp
I will send a PR later, the machine is not connected to Internet. // Fredrik After some more testing I think this has do to with MP, if I use a kernel without MP it seems to work, but if I use a MP kernel the system hangs as soon as i attach more than one carp device. This is just after some initial testing, I will do more extensiv later in the week. // Fredrik
Re: HP proliant DL140-G3 install problems
Thanks for the reply's guys. I need to setup 2 machine's to use as a pf + carp firewall by august. My understanding is that 4.1-current has solved the axe and uberry problems and that will go into 4.2-stable. I don't know if it's a good idea to install 4.1-current on a production firewall and it looks like it's going to be difficult to get 4.1-stable to run on it. Any suggestions on what to do? If necessary I could provide access to the machine for a developer to try things out if this will help. Doros
Re: IPSec Road Warriors
Hi, --snip-- Von: Stuart Henderson [EMAIL PROTECTED] On 2007/07/03 15:33, Georg Buschbeck wrote: sounds like it may need DPD, is this an option on the draytek? --snap-- --snip-- Von: Warren J. Beckett [EMAIL PROTECTED] Does the draytek realise the VPN is down after the IP change? I think you may want to try enabling on the OBSD side, Dead Peer Detection, if not done so already. No idea how this is done on the Draytek side but I think the draytek 2700 does support it. Hope that helps, Warren. --snap--- Hi, i think it does so, because in most cases this happens, when the draytek is switched on, and the draytek tryies to establish the connection. my suggestion is, that the openbsd box, doesn't resolve the new ip of the draytek, in the logfiles i can see the openbsd systems trying to reestablish the connection to the old ip of the draytek. the dyndns-name of the draytek does not have a correct reverse lookup. Thanks ... Georg
Re: IPSec Road Warriors
On 2007/07/04 10:36, Georg Buschbeck wrote: my suggestion is, that the openbsd box, doesn't resolve the new ip of the draytek, in the logfiles i can see the openbsd systems trying to reestablish the connection to the old ip of the draytek. That's not how DPD works, it should just pull down the SA when it can't contact the other side. This would happen at both sides, the dynamic side would see the SA is down, then try and reconnect when it gets another packet that should traverse the vpn. The static side (i.e. OpenBSD) should be configured passive without listing the peer address, something like this: ike passive esp \ from 192.168.64.0/21 to any \ main auth hmac-sha1 enc aes group grp2 \ quick auth hmac-sha1 enc aes group grp2 \ tag ipsec-$id (to any is magic). If you use PSK rather than public-key, specify it here (same psk for all dynamic endpoints). the dyndns-name of the draytek does not have a correct reverse lookup. You don't need dyndns for this (though it may be useful for other things).
Re: : HP proliant DL140-G3 install problems
Why not run 4.1 stable and disable axe and uberry in the kernel configuration for the GENERIC kernel. On Wed, Jul 04, 2007 at 09:51:46AM +0100, Doros Eracledes wrote: Thanks for the reply's guys. I need to setup 2 machine's to use as a pf + carp firewall by august. My understanding is that 4.1-current has solved the axe and uberry problems and that will go into 4.2-stable. I don't know if it's a good idea to install 4.1-current on a production firewall and it looks like it's going to be difficult to get 4.1-stable to run on it. Any suggestions on what to do? If necessary I could provide access to the machine for a developer to try things out if this will help. Doros -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Vos fichiers d'entreprise sur mesure
Si ce message ne s'affiche pas correctement, vous pouvez le visualiser en cliquant ici Fichier de prospection B to B : 6 millions d'entitis professionnelles frangaises ! Pour plus d'informations, cliquez ici. Avec MANAGEO.fr, votre prospection commerciale assurera votre diveloppement en 2007 ! Publiciti sans obligation de consultation destinie aux sociitis et aux professionnels. Manageo.fr est un service de renseignements privi sur les entreprises frangaises. SA ` conseil d'administration au capital de 48620 ⬠- RCS 423 315 597 CS 10546 13594 Aix-en-Provence cedex 03 Tel : 0826 88 77 66 (0,15â¬TTC/mn). Voir les conditions sur le site. MA_070625_6005_1 Disabonnement : Vous disposez d'un droit d'acchs, de modification, de rectification et de suppression des donnies qui vous concernent (art. 34 de la loiInformatique et Libertis). Fichier de diffusion Arawak, enregistri ` la CNIL, sous le N01026477 Pour vous disabonner : cliquez sur ce lien
how to clear dmesg outpout
How to clear kern msg buffer (dmesg output ) without restart system On FreeBSD i have 'sysctl kern.msgbuf_clear' bu OpenBSD don't have this options
Re: Re: how to clear dmesg outpout
WiadomoED Oryginalna Od: Timo Schoeler [EMAIL PROTECTED] Do: smonek [EMAIL PROTECTED] Data: 4 lipca 2007 16:00 Temat: Re: how to clear dmesg outpout Thus smonek [EMAIL PROTECTED] spake on Wed, 04 Jul 2007 15:50:52 +0200: How to clear kern msg buffer (dmesg output ) without restart system On FreeBSD i have 'sysctl kern.msgbuf_clear' bu OpenBSD don't have this options find a clean one here: /var/run/dmesg.boot HTH, Timo This now work
Re: Re: how to clear dmesg outpout
WiadomoED Oryginalna Od: Timo Schoeler [EMAIL PROTECTED] Do: smonek [EMAIL PROTECTED] Data: 4 lipca 2007 16:50 Temat: Re: how to clear dmesg outpout Thus smonek [EMAIL PROTECTED] spake on Wed, 04 Jul 2007 16:40:17 +0200: WiadomoE D Oryginalna Od: Timo Schoeler [EMAIL PROTECTED] Do: smonek [EMAIL PROTECTED] Data: 4 lipca 2007 16:00 Temat: Re: how to clear dmesg outpout Thus smonek [EMAIL PROTECTED] spake on Wed, 04 Jul 2007 15:50:52 +0200: How to clear kern msg buffer (dmesg output ) without restart system On FreeBSD i have 'sysctl kern.msgbuf_clear' bu OpenBSD don't have this options find a clean one here: /var/run/dmesg.boot HTH, Timo This now work cool! :) sorry not work :-(
Re: how to clear dmesg outpout
smonek wrote: How to clear kern msg buffer (dmesg output ) without restart system Turn computer off. Breathe out calmly for a few minutes. Turn computer on.
Re: sensorsd says the sensor is within limit, but it's not...
On 04/07/07, Per-Olov Sjvholm [EMAIL PROTECTED] wrote:
On Wednesdayen den 4 July 2007 04.17.30 you wrote:
Please, check the manual page for your system [0], specifically, the
following:
Sensors that provide status (such as from bio(4), esm(4), or
ipmi(4))
do not require boundary values specified (that otherwise will be ignored)
and simply trigger on status transitions.
In other words, for those sensors that provide the status themselves,
the keywords high and low in sensorsd.conf have no effect. This
limitation was removed at c2k7 [1], and the newest sensorsd in OpenBSD
4.1-current allows you to set your own limits for any sensor, and
ignore the status that the sensor device itself provides.
So if you need this functionality, you may wish to upgrade to OpenBSD
4.1-current.
Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework, and then manually update sensorsd to
4.1-current (files /usr/src/{etc/sensorsd.conf,usr.sbin/sensorsd/*}),
compiling and installing it afterwards -- sensorsd in 4.1-current as
of today is source-code-compatible with 4.1-stable (note that it is
not binary compatible). However, please be warned that mixing
4.1-stable and 4.1-current is not officially supported, so use it at
your own risk! (Even though it works for me in this specific case with
sensorsd.)
Cheers,
Constantine. :)
[0]
http://www.openbsd.org/cgi-bin/man.cgi?query=sensorsd.confsektion=5manpat
h=OpenBSD+4.0
[1]
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c#rev1
.32
Thanks for the answer
So I only need the command with %1-%4 and no low/high specs in
sensorsd.conf?
yes
The trigger will come when Dell think the temp i to low or
high?
yes, it will trigger whenever there is any transition in state. I.e.
when you start sensorsd, sensors state in sensorsd goes from undefined
to whatever it is for every sensor, and this also triggers the
command.
If so... Is there a way of knowing at what temperature this happends. I
mean, could you ask the hardware itself with any software, or do I have to
dig into some of Dell:s docs? That is not super important, but it would be
nice to know at what value it happends, and if possible test it.
not that I'm aware of, however, I've never used ipmi
Also, isn't it possible then to have different commands for low and high if
low and high has no meanings? I mean, do I have to take care of if it's a
low
or a high warning in the command script. If low and high have meanings (as
in
OBSD 4.1-current) I could have one sensor row in sensorsd.conf for high and
one for low with different commands. Right?
No, if you read the man-pages, you'll see that every sensor is matched
by at most one entry in the config file. You can have a shell script
as the command, which can compare sensor values to the limits and take
appropriate decision on which command to execute.
You said that:
Alternatively, you may upgrade to OpenBSD 4.1-stable that has the new
two-level sensor framework Why do I need to go to -CURRENT if it's
included
in 4.1-STABLE? Isn't 4.1-STABLE ok? I want to avoid -current on production
servers. But after looking at
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/sensorsd.c it
seems I am *not* OK with just 4.1 STABLE, and that I need -CURRENT if I
want
this functionality...
In 4.1-stable we have the new two-level sensors framework, but no
changes in sensorsd other then the way sensors are addressed --
however, this change in sensor addressing is a huge improvement for
sensorsd in itself. ;)
In -current, we have the new sensorsd functionality, which is based on
the new framework. Hence my suggestion to use -current sensorsd with a
4.1-stable system -- it's not officially supported, but it works as of
today without any problems.
If you don't want to copy and compile sensorsd sources from -current
to 4.1-stable, then I'd suggest you wait until 4.2 is released. :)
Cheers,
Constantine.
cvs verify question
I was wondering if there is any way to 'verify' a download via cvs. I track stable so after i do my update, I'm just wondering if there is some way to verify the files i downloaded are correct, not tampered with. I guess I'm thinking of how you can download the file sets and then compare MD5s or something like that. Or is the rsa fingerprint of the cvs server we connect to the verification? Thanks. Aaron
Re: Intel xeon fails to boot with 4.1 release
Hey Chris, It's of interest that, when there is a problem even booting up, the patch branch is not that useful for the ordinary user who doesn't yet have a separate machine to do a build on, and to make a release with. The patch branch has no associated set of binaries to download, or iso boot image to get started with. And no previous release works with this machine. Austin On Tue, 3 Jul 2007, Chris Kuethe wrote: On 7/3/07, Austin Hook [EMAIL PROTECTED] wrote: Hi Chris, Thanks! What kind of an issue was it? You just had to increase the VM_PHYSSEG_MAX definition, or was that a misdirection? Just had to increase VM_PHYSSEG_MAX. BTW, way, how long does it take for such patches to show up in either the 4.1 or patch branch corrections lists on the web site? That's a manual process to put patches and errata up. It wasn't clear that we needed to actually issue a separate patch for this, since we haven't heard of very many machines being affected by this... only two reported machines so far that need more than 5 segments. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: WRAP board IIC port
On Sat, Jun 30, 2007 at 10:46:55AM +0200, Leon Komlo?i wrote:
I'm trying to connect various IC's to IIC port on WRAP.1E board.
Without any success. IC's are Dallas DS1621,DS1631,DS1624.
Here is dmesg line:
DS1621:
iic1: addr 0x48 22=0a 40=0a 41=0f 42=0a 43=0a 44=0a 45=0a 46=0a 47=0a
48=0c 49=10 4a=c4 4b=01 4c=0e 4d=00 4e=d6 4f=00 51=0f a1=0f a2=0a a8=0c
a9=10 aa=c4 ac=8e ee=08
DS1631
iic1: addr 0x48 22=0a 40=0a 41=0f 42=0a 43=0a 44=0a 45=0a 46=0a 47=0a
48=0c 49=10 4a=c4 4b=01 4c=0c 4d=00 4e=00 4f=00 51=0f a1=0f a2=0a a8=0c
a9=10 aa=c4 ac=8c ee=08
DS1624
iic1: addr 0x48 a2=da a3=eb a4=30 a5=6e a6=9f a7=72 a8=00 a9=31 aa=c9
ab=00 ac=0a ad=c7 ae=1f
Any idea ???
well, some of these did work a while ago tho multiple commits to
i2c_scan.c might break it. you can figure out how to fix i2c_scan.c or
just try another chip (like lm).
To use LPC port on WRAP.1E board as GPIO is necessary to clear 14 and 16
bit at location 0x09030.
Any idea how to do that ???
If *ANYONE* actuall read the code they would see this:
#if 0
/*
* XXX This probe needs to be improved; the driver does some
* dangerous writes.
*/
if (name == NULL (addr 0x7c) == 0x48 /* addr 0b1001xxx */
(iicprobew(0xaa) 0x0007) == 0x
(iicprobew(0xa1) 0x0007) == 0x
(iicprobew(0xa2) 0x0007) == 0x
(iicprobe(0xac) 0x10) == 0x00) {
if ((iicprobe(0xac) 0x7e) == 0x0a
iicprobe(0xab) == 0x00 iicprobe(0xa8) == 0x00)
name = ds1624;
else if ((iicprobe(0xac) 0x7e) == 0x0c)
name = ds1631;/* terrible probe */
else if ((iicprobe(0xac) 0x2e) == 0x2e)
name = ds1721;/* terrible probe */
}
#endif
There is no support for any of the other varients, and even the ones
that there is code for are disabled -- because the stupid chips don't
supply enough unique information in their registers, and the code
above will false-positive on other chips. Doing it right is something
that must be done by someone who cares enough to do it right.
Re: Intel xeon fails to boot with 4.1 release
On Wednesday, July 4, 2007 at 09:17:48 -0700, Austin Hook wrote: Hey Chris, It's of interest that, when there is a problem even booting up, the patch branch is not that useful for the ordinary user who doesn't yet have a separate machine to do a build on, and to make a release with. The patch branch has no associated set of binaries to download, or iso boot image to get started with. And no previous release works with this machine. There are regular builds of the stable tree made available at ftp://ftp.su.se/pub/mirrors/openbsd_stable/ But that's not an official part of the project, just a build by some enthousiasts (I'm one of them). Perhaps usefull to test or to get started and build a release for yourself when the machine is up and running. Maurice
Re: how to clear dmesg outpout
Thus Dimitry Andric spake: smonek wrote: How to clear kern msg buffer (dmesg output ) without restart system Turn computer off. Breathe out calmly for a few minutes. Turn computer on. maybe /var/run/dmesg.boot can be of help? remember to breath...
Re: Intel xeon fails to boot with 4.1 release
Thanks for the pointer to some stable binaries, however it's too old for me. I guess I will try with current snapshot and build stable 4.1 if I need it. Austin
i386 - ramdiskA full again?
Using a July 3 checkout, make release fails with file system full -- is it
just me?
Excerpt from the output, and a dmseg follow. The dmesg shows a custom kernel,
which is GENERIC plus RAIDFrame.
--
rm -f bsd
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd ${SYSTEM_OBJ} vers.o
textdatabss dec hex
1359958 1988404 198188 3546550 361db6
cp /usr/src/distrib/i386/ramdiskA/../../../sys/arch/i386/compile/RAMDISK/bsd bsd
cc -DDEBUG -o rdsetroot
/usr/src/distrib/i386/ramdiskA/../../common/elfrdsetroot.c
cp bsd bsd.rd
/usr/src/distrib/i386/ramdiskA/obj/rdsetroot bsd.rd mr.fs
segment 0 rd_root_size_off = 0x151da0
rd_root_image_off = 0x151dc0
rd_root_size val: 0x001DB000 (3800 blocks)
copying root image...
...copied 1945600 bytes
cp bsd.rd bsd.strip
strip bsd.strip
strip -R .comment bsd.strip
gzip -c9n bsd.strip bsd.gz
dd if=/dev/zero of=/var/tmp/image.27428 bs=512 count=2880
2880+0 records in
2880+0 records out
1474560 bytes transferred in 0.018 secs (80511057 bytes/sec)
vnconfig -v -c svnd0 /var/tmp/image.27428
svnd0: 1474560 bytes on /var/tmp/image.27428
disklabel -w svnd0 floppy3
newfs -m 0 -o space -i 524288 -c 2880 /dev/rsvnd0a
/dev/rsvnd0a: 1.4MB in 2880 sectors of 512 bytes
1 cylinder groups of 1.41MB, 360 blocks, 32 inodes each
super-block backups (for fsck -b #) at:
32,
mount /dev/svnd0a /mnt
cp /usr/dest/usr/mdec/boot /usr/src/distrib/i386/ramdiskA/obj/boot
strip /usr/src/distrib/i386/ramdiskA/obj/boot
strip -R .comment /usr/src/distrib/i386/ramdiskA/obj/boot
dd if=/usr/src/distrib/i386/ramdiskA/obj/boot of=/mnt/boot bs=512
84+1 records in
84+1 records out
43028 bytes transferred in 0.000 secs (91548936 bytes/sec)
dd if=bsd.gz of=/mnt/bsd bs=512
/mnt: write failed, file system is full
dd: /mnt/bsd: No space left on device
2712+1 records in
2712+0 records out
1388544 bytes transferred in 0.021 secs (63855783 bytes/sec)
*** Error code 1
--
OpenBSD 4.1-current (JGGIMI) #47: Tue Jul 3 21:57:14 EDT 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/JGGIMI
cpu0: AMD Sempron(tm) 2600+ (AuthenticAMD 686-class, 256KB L2 cache) 1.84 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 502820864 (479MB)
avail mem = 478142464 (455MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/07/05, BIOS32 rev. 0 @ 0xfb9b0, SMBIOS
rev. 2.2 @ 0xf (44 entries)
bios0: ASUS A7VT
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xf/0xda84
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfda10/112 (5 entries)
pcibios0: PCI Exclusive IRQs: 3 5 10 11
pcibios0: PCI Interrupt Router at 000:17:0 (VIA VT82C596A ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x7e00 0xc8000/0x8000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 VIA VT8378 PCI rev 0x00
ppb0 at pci0 dev 1 function 0 VIA VT8377 AGP rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 VIA VT8378 VGA rev 0x01: aperture at
0xe400, size 0x1000
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
dc0 at pci0 dev 8 function 0 Lite-On PNIC-II rev 0x25: irq 10, address
00:a0:cc:e3:42:d6
dcphy0 at dc0 phy 31: internal PHY
uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x80: irq 11
uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x80: irq 10
uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x80: irq 5
ehci0 at pci0 dev 16 function 3 VIA VT6202 USB rev 0x82: irq 3
usb0 at ehci0: USB revision 2.0
uhub0 at usb0: VIA EHCI root hub, rev 2.00/1.00, addr 1
viapm0 at pci0 dev 17 function 0 VIA VT8235 ISA rev 0x00
iic0 at viapm0
pciide0 at pci0 dev 17 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel
0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: ExcelStor Technology J880
wd0: 16-sector PIO, LBA48, 78533MB, 160836480 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: LITE-ON, DVDRW SHW-160P6S, PS01 SCSI0 5/cdrom
removable
wd1 at pciide0 channel 1 drive 1: Maxtor 6Y080P0
wd1: 16-sector PIO, LBA, 78167MB, 160086528 sectors
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4
wd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 6
auvia0 at pci0 dev 17 function 5 VIA VT8233 AC97 rev 0x50: irq 5
ac97: codec id 0x41445368 (Analog Devices AD1888)
ac97: codec features headphone, 20 bit DAC, No 3D Stereo
audio0 at auvia0
vr0 at pci0 dev 18 function 0 VIA RhineII-2 rev 0x74: irq 11, address
00:11:2f:85:b1:90
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 10: OUI
0x004063, model 0x0032
usb1 at uhci0: USB revision 1.0
uhub1 at usb1: VIA UHCI root hub, rev 1.00/1.00, addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2: VIA UHCI root
Re: i386 - ramdiskA full again?
Using a July 3 checkout, make release fails with file system full -- is it just me? Kind of. Things like this will happen, and then they will be fixed. Then they will happen again. That's just the process. Noone really needs to alert us, since we have to cope with this on our own already.
Re: i386 - ramdiskA full again?
On Wed, Jul 04, 2007 at 11:37:20AM -0600, Theo de Raadt wrote: Using a July 3 checkout, make release fails with file system full -- is it just me? Kind of. Things like this will happen, and then they will be fixed. Then they will happen again. That's just the process. Noone really needs to alert us, since we have to cope with this on our own already. OK, thank you for the clarification. But I was concerned it might have been just me, since a July 2 snap exists.
Re: how to clear dmesg outpout
On 7/4/07, smonek [EMAIL PROTECTED] wrote: On FreeBSD i have 'sysctl kern.msgbuf_clear' bu OpenBSD don't have this options find a clean one here: /var/run/dmesg.boot HTH, Timo This now work cool! :) sorry not work :-( I think what he's getting at is that there's no way to clear the dmesg buffer, but that if you need a clean dmesg from-boot, you can open /var/run/dmesg.boot Why do you need to clear the dmesg?
Re: Intel xeon fails to boot with 4.1 release
On Wed, Jul 04, 2007 at 10:03:20AM -0700, Austin Hook wrote: Thanks for the pointer to some stable binaries, however it's too old for me. I guess I will try with current snapshot and build stable 4.1 if I need it. If the problem is entirely a kernel issue, until 4.2-beta you should be able to boot from -current install media but install a 4.1-release userland with a 4.1-current kernel. Boot the system, then download your -stable source and build a -stable kernel with the fix in it. Or just run the -current snapshot :-)
KVM and OpenBSD 4.1 on UltraSparc
1. Sun Blade 1002. OpenBSD 4.1 installed. 3. OpenSolaris b66 installed. 4. TrendNet USB KVM. 5. NumLock+NumLock to switch consoles.
Re: KVM and OpenBSD 4.1 on UltraSparc
Sean Hafeez wrote: 1. Sun Blade 100 2. OpenBSD 4.1 installed. 3. OpenSolaris b66 installed. 4. TrendNet USB KVM. 5. NumLock+NumLock to switch consoles. Let me try this again as for some reason the msg was cut off: 1. Sun Blade 100 w/Type 6 USB Keyboard 2. OpenBSD 4.1 installed. 3. OpenSolaris b66 installed. 4. TrendNet USB KVM. 5. NumLock+NumLock to switch consoles. 6. Switching consoles works fine under OpenSolaris however under OpenBSD nothing happens. Any ideas why? Thanks! Sean
Re: how to clear dmesg outpout
I think it is a pretty valid question(request?), you have to relay on external mechanisms, like syslog, or to compare differences from previous outputs of dmesg. On HP-UX dmesg has the optional parameter '-' which: system tables overflow or the system crashes). If the - argument is specified, dmesg computes (incrementally) the new messages since the last time it was run and places these on the standard output. This is typically used with cron (see cron(1)) to produce the error log /var/adm/messages by running the command: On FreeBSD and Linux it can be cleared. I think it is a feature that can help a lot. On 7/4/07, Nick Guenther [EMAIL PROTECTED] wrote: On 7/4/07, smonek [EMAIL PROTECTED] wrote: On FreeBSD i have 'sysctl kern.msgbuf_clear' bu OpenBSD don't have this options find a clean one here: /var/run/dmesg.boot HTH, Timo This now work cool! :) sorry not work :-( I think what he's getting at is that there's no way to clear the dmesg buffer, but that if you need a clean dmesg from-boot, you can open /var/run/dmesg.boot Why do you need to clear the dmesg? -- You should be the change that you want to see in the world. - Gandhi
Re: Intel xeon fails to boot with 4.1 release
Hi Ryan, Intriging thinking there! Thanks! A. On Thu, 5 Jul 2007, Ryan McBride wrote: On Wed, Jul 04, 2007 at 10:03:20AM -0700, Austin Hook wrote: Thanks for the pointer to some stable binaries, however it's too old for me. I guess I will try with current snapshot and build stable 4.1 if I need it. If the problem is entirely a kernel issue, until 4.2-beta you should be able to boot from -current install media but install a 4.1-release userland with a 4.1-current kernel. Boot the system, then download your -stable source and build a -stable kernel with the fix in it. Or just run the -current snapshot :-)
Re: how to clear dmesg outpout
How is this any worse? On 7/4/07, Jose H. [EMAIL PROTECTED] wrote: I think it is a pretty valid question(request?), you have to relay on external mechanisms, like syslog, or to compare differences from previous outputs of dmesg. On HP-UX dmesg has the optional parameter '-' which: system tables overflow or the system crashes). If the - argument is specified, dmesg computes (incrementally) the new messages since the last time it was run and places these on the standard output. This is typically used with cron (see cron(1)) to produce the error log /var/adm/messages by running the command: On FreeBSD and Linux it can be cleared. I think it is a feature that can help a lot.
Re: how to clear dmesg outpout
Jose H. wrote: I think it is a pretty valid question(request?), you have to relay on external mechanisms, like syslog, or to compare differences from previous outputs of dmesg. Or just look at /var/run/dmesg.boot. Really, what's the point of clearing the buffer? I think it is a feature that can help a lot. Help a lot with what? --- Lars Hansson
