Re: softraid mirror I/O error, cannot recover data
On Sat, Apr 06, 2013 at 10:43:13AM +, Stuart Henderson wrote: On 2013-04-04, Juha Erkkila j...@turnipsi.no-ip.org wrote: Hello misc, I am having a problem with a mirroring softraid configuration. Every time I try to access a particular partition in softraid volume I start to get I/O errors so that softraid totally breaks, that is, becomes non-operative. Note that it does very much look like that both of these disks are actually defective. Note that I said that I think both disks are defective. When the system is booted with softraid disabled and then the disks (sd0 and sd1) are read with dd if=/dev/rsd0c of=/dev/null conv=noerror,sync, dd reports several I/O errors (a few such errors every now and then). You might want to try different cables, though really it sounds like it's probably time to restore from your backups. Well I do have backups, but I did not want to go that route because my most recent backup did not have my latest files, and I wanted to recover those. Anyway, I did find out a way to recover the data. Basically I just read the other disk in the softraid mirror, stripping the softraid metadata, like this: $ dd if=/dev/sd0d of=shifted-raid.img conv=noerror,sync skip=528 Some read errors occured, though, but oh well. And then: $ vnconfig vnd0 shifted-raid.img $ fsck /dev/vnd0h $ dump -0a -f vnd0h.dump /dev/vnd0h Worked like a charm ;-) I guess there might have been an easier way, but I could not figure it out. Before giving I/O errors softraid reported ``softraid0: retrying read on block 591205648''. Perhaps this will help someone else who runs into this somewhere, later. Juha
softraid mirror I/O error, cannot recover data
Hello misc,
I am having a problem with a mirroring softraid configuration.
Every time I try to access a particular partition in softraid
volume I start to get I/O errors so that softraid totally breaks,
that is, becomes non-operative.
Note that it does very much look like that both of these
disks are actually defective.
$ disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: WDC WD3200AAKS-0
duid: 800258c4df44247f
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
boundstart: 63
boundend: 625137345
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 530082 63 4.2BSD 2048 163841 # /
b: 8401995 530145swap
c:6251424480 unused
d:616205205 8932140RAID
$ disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: WDC WD3200AAKS-0
duid: ec6572ba6b33d733
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
boundstart: 63
boundend: 625137345
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 530082 63 4.2BSD 2048 163841
b: 8401995 530145swap
c:6251424480 unused
d:616205205 8932140RAID
The situation now:
$ bioctl -i sd3
Volume Status Size Device
softraid0 0 Degraded 315496794624 sd3 RAID1
0 Online 315496794624 0:0.0 noencl sd0d
1 Offline 0 0:1.0 noencl sd1d
$ disklabel sd3
# /dev/rsd3c:
type: SCSI
disk: SCSI disk
label: SR RAID 1
duid: 80ebde8831825f63
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38356
total sectors: 616204677
boundstart: 0
boundend: 616204677
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
c:6162046770 unused
d: 125949440 4.2BSD 2048 163841 # /tmp
e:125821088 12594944 4.2BSD 2048 163841 # /usr
f: 8385920138416032 4.2BSD 2048 163841 # /var
g:125821088146801952 4.2BSD 2048 163841 # /home
h:343581632272623040 4.2BSD 4096 327681
I can use the partitions /dev/sd3{d,e,f,g} just fine. However, whenever
I try to do any of the following:
* fsck /dev/sd3h
* dd if=/dev/sd3h of=/dev/null
* dump /dev/sd3h
* bioctl -R /dev/someotherraidvolume sd3
after a few seconds I will get I/O errors from the softraid volume.
These errors are such that after it *any* operation to sd3,
for example bioctl -i sd3, or disklabel sd3 will simply
return an I/O error, and the system must be rebooted.
Note that I said that I think both disks are defective. When
the system is booted with softraid disabled and then the disks
(sd0 and sd1) are read with
dd if=/dev/rsd0c of=/dev/null conv=noerror,sync,
dd reports several I/O errors (a few such errors every now and then).
Possibly some softraid-related metadata is corrupted?
Any ideas on how to recover data from /dev/sd3h? Do the above
dd-command to some file and then use scan_ffs? Might that work?
This is 5.3, built from source.
Juha
dmesg (btw, Logitech Logitech Cordless RumblePad 2 works great with
mupen64plus,
a bit of configuration was needed though ;-)
OpenBSD 5.3 (GENERIC) #0: Sun Mar 17 21:03:56 EET 2013
bu...@iso.turnipsi.no-ip.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Sempron(tm) 140 Processor (AuthenticAMD 686-class, 1024KB L2 cache)
2.71 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,SSE3,MWAIT,CX16,POPCNT,LAHF,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,WDT,ITSC
real mem = 1878126592 (1791MB)
avail mem = 1836462080 (1751MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/14/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS
rev. 2.5 @ 0xf06d0 (63 entries)
bios0: vendor American Megatrends Inc. version 1501 date 09/14/2009
bios0: ASUSTeK Computer INC. M4A78 PRO
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4)
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) UAR1(S4) PS2K(S4) PS2M(S4)
P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD erratum 721 detected and fixed
cpu0: apic clock running at 200MHz
ioapic0 at
Re: /etc/daily bug? altroot vs DUIDs
On Thu, Feb 09, 2012 at 10:25:45AM -0500, Dave Anderson wrote: On Wed, 8 Feb 2012, Dave Anderson wrote: On Tue, 7 Feb 2012, Kenneth R Westerback wrote: On Tue, Feb 07, 2012 at 09:42:07AM -0500, Dave Anderson wrote: I've got a system running amd64/mp -current (latest source update on February 1st) and have noticed (for quite a while, actually) that the nightly backup of / to /altroot wasn't working. I finally got around to looking into this and discovered that the /etc/daily script was explicitly checking for /dev/whatever in the /altroot fstab entry -- but I've been using DUIDs (as set up by the installer). Shouldn't the daily script be updated to handle DUIDs as well as explicit devices in /etc/fstab? Dave Does this diff work for you? Test with duid and without would be nice. :-) And don't be bashful. Anybody can test! Ken That works for me, both ways. Thanks, Dave Aaargh! Not quite, it turns out. This superficially appears to work, and does seem to work in the non-DUID case, but I evidently didn't look at the results carefully enough. In the DUID case, rather than copying / to the altroot partition it copies it to /dev/rduid.partition! My bad. Apologies to all. I remember seeing a commit which sounds like it might tweak some low-level functions to translate DUIDs into devices; I'll upgrade to a current -current and see if this problem goes away. I tried latest -current (from sources), and the same problem is there as well. I think this change should be reverted, because having a copy of root partition sitting as world readable in /dev is not cool: 08:35 je@iso:~$ ls -l /dev/rec6572ba6b33d733.a -rw-r--r-- 1 root wheel 143M Feb 10 08:23 /dev/rec6572ba6b33d733.a Juha
Re: radeondrm does not appear to work on IBM Thinkpad T43
On Mon, Apr 26, 2010 at 08:09:02PM +0100, Owain Ainsworth wrote: On Mon, Apr 26, 2010 at 06:15:38PM +0300, Juha Erkkila wrote: snip OpenGL renderer string: Software Rasterizer Sometimes I wonder if anyone actually reads the logs they post to mailing lists. now: $ ls -lh /dev/drm0 crw-rw 1 root wheel 87, 0 Mar 6 01:37 /dev/drm0 So either change those permissions to allow you access the file, or the other alternative is obvious. I really should consider changing those default permissions... Changing permissions indeed fixes the issue. Thanks Owain. Juha
Re: Why not update Groff?
On Mon, Feb 18, 2008 at 02:35:01PM +0100, Pieter Verberne wrote:
Why is Groff not updated? OpenBSD 4.2 has Groff 1.15 from 1999.
Some compatability issues?
I've been thinking this too, and went ahead and tried doing it...
It's a bit of a pain actually, some problems: the directory layout
has changed, and as there are some patches in the current OpenBSD version,
one should track how those map into new files. New Groff (1.19.2)
enforces ``-R'' option for more/less for manpage viewing, that breaks
makewhatis, NetBSD tree has a fix (for Groff) for that. I tried building
release(8) with it, got some errors on mdoc-macros, as I tried using
the current mdoc-macros in OpenBSD. In short: it's not a trivial update,
brings new code into the tree (with unsafe string functions, should be
audited), and it's more GPL which some may find offensive.
As there's only two things that I want from new Groff, I figured taking
another route. One thing is a missing euro-symbol (which would be nice),
and the other issue is fixed with the following patch (haven't tested this
extensively, but seems okay and I'm building release(8) with it right now).
--
This modifies default manpage handling: one long page for ttys,
instead of with page breaks sprinkled. Default for nroff.
Code basically backported from groff 1.19.2.
cd /usr/src patch /path/to/groff_nomanpage_breaks.patch
cd gnu/usr.bin/groff
make -f Makefile.bsd-wrapper obj
make -f Makefile.bsd-wrapper
make -f Makefile.bsd-wrapper install
Index: gnu/usr.bin/groff/tmac/tmac.an
===
RCS file: /cvs/src/gnu/usr.bin/groff/tmac/tmac.an,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 tmac.an
--- gnu/usr.bin/groff/tmac/tmac.an 9 Apr 2000 07:58:30 - 1.1.1.2
+++ gnu/usr.bin/groff/tmac/tmac.an 18 Feb 2008 12:17:18 -
@@ -17,6 +17,9 @@
.\with groff; see the file COPYING. If not, write to the Free Software
.\Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
.\
+.\ -rcR=1 = Create a single, very long page instead of multiple pages.
+.\ Useful for online display. Default in nroff mode.
+.\ Deactivate with -rcR=0.
.\ -rC1 = number pages continuously, rather than start each at 1
.\ -rD1 = double-sided printing, ie different odd and even page footers
.\ -rPnnn = number first page nnn
@@ -31,6 +34,36 @@
.if !rD .nr D 0
.if !rC .nr C 0
.if rP .pn 0\nP
+.if !r cR \{\
+. ie n .nr cR 1
+. el .nr cR 0
+.\}
+.
+.nr an-first 1
+.
+.\ we redefine .ne to avoid page breaks if cR is set; instead, the page
+.\ length is increased to the necessary amount (this is needed for tables)
+.\
+.\ similarly, we redefine .bp if cR is set, adjusting the page length to
+.\ the current position so that no empty lines are inserted
+.if \n[cR] \{\
+.de ne
+. ie \\n[.$] \
+.nr an-ne (v;\\$*)
+. el \
+.nr an-ne 1v
+. if (\\n[an-ne] = \\n[.t]) \
+.pl +(\\n[an-ne]u - \\n[.t]u + 1v)
+..
+.
+.rn bp an-bp
+.de bp
+. br
+. pl \\n[nl]u
+. an-bp \\$*
+..
+.\}
+.
.de set-an-margin
. ie '\*(.T'html' \{\
.nr an-margin 0i
@@ -70,12 +103,17 @@
.nr an-no-space-flag 0
.nr an-break-flag 0
.nr an-div? 0
-.wh 0 an-header
-.wh -1i an-footer
-.wh -.5i an-p-footer
-.if \\n[nl]0 \{\
-. ie \\nC .bp \\n%+1
-. el .bp 1
+.
+.ie \\n[cR] \
+. an-header
+.el \{\
+. wh 0 an-header
+. wh -1i an-footer
+. wh -.5i an-p-footer
+. if \\n[nl]0 \{\
+.ie \\nC .bp \\n%+1
+.el .bp 1
+. \}
.\}
..
.de DT
@@ -85,16 +123,37 @@
.ie \\n[.$] .nr PD (v;\\$1)
.el .nr PD .4v?\n[.V]
..
+.de PT
+. tl
'\\*[an-title](\\*[an-section])'\\*[an-extra3]'\\*[an-title](\\*[an-section])'
+..
+.de BT
+. ie \\n[D] \{\
+.if o .tl '\\*[an-extra2]'\\*[an-extra1]'\\*[an-page-string]'
+.if e .tl '\\*[an-page-string]'\\*[an-extra1]'\\*[an-extra2]'
+. \}
+. el \
+.tl '\\*[an-extra2]'\\*[an-extra1]'\\*[an-page-string]'
+..
.de an-header
.an-init
-.ev 1
-.ie '\*(.T'html' \{\
-. tl
+.if \\n[cR] \{\
+. ie \\n[an-first] \
+.nr an-first 0
+. el \
+.sp .5i
.\}
+.ev 1
+.ps \\n[PS]
+.ie '\*(.T'html' \
+. tl
.el \{\
-. sp .5i
-. tl
'\\*[an-title](\\*[an-section])'\\*[an-extra3]'\\*[an-title](\\*[an-section])'
-. sp |1i
+. if !\\n[cR] \
+.sp .5i
+. PT
+. ie !\\n[cR] \
+.sp |1i
+. el \
+.sp .5i
.\}
.ev
.ns
@@ -105,27 +164,42 @@
.af an-page-letter a
.de an-p-footer
.ev 1
+.ps \\n[PS]
.ie '\*(.T'html' \{\
. ds an-page-string
. ds an-extra1
. ds an-extra2
.\}
-.el .ds an-page-string \\n%
-.if rX \{\
-. if \\n%\\nX \{\
-. nr an-page-letter \\n%-\\nX
-. ds an-page-string \\nX\\n[an-page-letter]
-.\}\}
-.ie \\nD \{\
-. if o .tl '\\*[an-extra2]'\\*[an-extra1]'\\*[an-page-string]'
-. if e .tl '\\*[an-page-string]'\\*[an-extra1]'\\*[an-extra2]'
+.el \{\
+. ie r X
Re: Crypto Partition Problem
On Tue, Jun 06, 2006 at 01:46:15PM -0700, Rott_En wrote: Hello again. I am not able to fix the issue, but here is the disklabel, maiby it can help you figure out a solution. ... If I change unused to 4.2BSD fsck reports serval errors like SuperBlocks are missing. Any advice is highly welcomed, as before. Thank you. at this point your best bet is probably running scan_ffs on /dev/rsvnd0c, and see if you can reconstruct the disklabel. see scan_ffs(8) manpage. i have no experience with this, though i wish you luck, Juha
Re: Crypto Partition Problem
On Mon, Jun 05, 2006 at 04:47:28AM -0700, Rott_En wrote: Is it a risk to attempt using your recommedation ? Am I risking the integrity of my cryptofile container ? It is 90GB big and I dont have any auxiliary backup medium so big, taking a backup of it is almost out of hope. I can't loose the data from this cryptofile, so please tell me if I risk using your method of repair. of course there is a risk, as doing a fsck will modify the vnd-disk contents. try first with ``fsck -n'', see fsck(8). but as it appears to me, your problem is that as the system was not shut down cleanly, the crypto disk is in a dirty state, and thus a fsck is required for its proper operation. alternatively, you might consider trying a mount with -f and -r, see mount(8), and see if you can read its contents. make sure to use ``vnconfig -k'' first, and see that you have the right key, otherwise neither will work (but should still be safe) Juha
Re: Crypto Partition Problem
On Mon, Jun 05, 2006 at 01:01:34PM -0700, Rott_En wrote: I used fsck -n and then tried to mount the /crypto/home/cryptofile partition container with no luck, same results stating: # sh cryptfs -m -p /home -f /crypto/home/cryptofile -d /dev/svnd0c Encryption key: vnconfig: VNDIOCSET: Device busy mount_ffs: /dev/svnd0c on /home: specified device does not match mounted device # mount -f /home mount: can't find fstab entry for /home. # mount -f /crypto/home/ mount_ffs: /dev/wd0g on /crypto/home: Device busy # mount -r /crypto/home/ mount_ffs: /dev/wd0g on /crypto/home: Device busy # 1. please don't top post, trim your lines under 80 2. RTFM. in this case those are: vnconfig(8), fsck(8), mount(8) 3. AFTER figuring out what these will do, try these: $ vnconfig -k svnd0 /crypto/home/cryptfile (type the correct key) $ fsck /dev/rsvnd0c $ mount /dev/svnd0c /home don't blame me if it breaks. 4. consider not using a single, huge, encrypted vnd, for data that matters 5. toss away the cryptfs-script: it doesn't do fsck, if doesn't back out from errors, it forces mounts even when it should not Juha
Re: Crypto Partition Problem
On Sun, Jun 04, 2006 at 02:07:22AM -0700, Rott_En wrote: # Important Note: Under OpenBSD's current encrypted vnd filesystem # implementation, when a system with a mounted, encrypted vnd filesystem # is shutdown uncleanly, the encrypted vnd filesystem's structures get # damaged and, since OpenBSD's fsck will not acknowledge vnd filesystems, # these damaged structures can not reasonably be repaired. i don't think this is true. just use vnconfig to attach a file to svnd0, and then do fsck /dev/rsvnd0c (maybe take a backup first?) OTOH, whether that works may depend on the disklabel on /dev/rsvnd0c, but at least i do this routinely in a similar script as yours, before mounting /dev/svnd0c, and it appears to work fine for me Juha
Re: tape,seagate,trouble
On Tue, Apr 25, 2006 at 06:00:51PM +0200, Mats wrote: Under NetBSD dump/restore works fine, but not under OpenBSD. The bios on the motherboard doesn't find the seagate, it says not detected. I have tried pnp and not pnp in bios without any differents. this is probably the atapi tape drive bug that was fixed during the 3.9 development cycle. wait for 3.9 and upgrade (or ask me for a patch if you absolutely cannot wait) Juha
Re: Privoxy lockups
On Fri, Feb 17, 2006 at 08:38:32PM +0100, Michael Frost wrote: Using OpenBSD-v3.8 and v3.9-BETA on i386 together with tor, privoxy stops working alfways after a few minutes up to a few hours. 'Stop working' means either the privoxy process isn't running anymore (so it needs to be restarted) or the process is running but no data stream is managed by privoxy (seen with tcpdump). The trouble maker is definitely privoxy and not tor. Is there anybody out here who can confirm this? Do you know a workaround to handle these lockups? for me, privoxy hangs soon after i try doing any connection through it. i could ``fix'' the problem by enabling ``single-threaded'' in /etc/privoxy/config, so it's apparently a threads issue Juha
Re: Encrypting content/filesystem on DVD?
On Thu, Jan 26, 2006 at 10:45:10AM -0500, Paul Thorn wrote: While the tar method would work if I split the data into smaller segments, retrieval would be cumbersome at best, I fear. The resulting encrypted tar files would need to be significantly 4GB for the same reasons that the large vnd filesystem can't be written to the disk (ISO doesn't like these large files). note that you can write tar-archives directly to cd (and probably dvd), if you want to. this is what i do to achieve similar stuff: (cd $CRYPTDIR pax -w .) \ | openssl bf -e -pass file:$KEYFILE \ | cdrecord blank=fast dev=/dev/rcd0c driveropts=burnfree speed=10 \ -pad -tao -v -data - where $KEYFILE is on an encrypted filesystem. and retrival: dd if=/dev/rcd0c bs=2048 2/dev/null \ | openssl bf -d -pass file:$KEYFILE 2/dev/null \ | (cd $CRYPTDIR pax -r) works pretty well for me. you may easily exchange blowfish for some some other cipher, too Juha
Re: DadOS - sys shutdown with XDM
On Tue, Jan 03, 2006 at 07:04:36PM +0100, Joachim Schipper wrote: On Tue, Jan 03, 2006 at 12:45:46PM -0500, Michael Erdely wrote: Add dad to the operator group which can run /sbin/shutdown without sudo. That's not a very good idea. $ ls -la /dev/wd* brw-r- 1 root operator0, 0 Nov 2 18:20 /dev/wd0a brw-r- 1 root operator0, 1 Nov 2 18:20 /dev/wd0b brw-r- 1 root operator0, 2 Nov 2 18:20 /dev/wd0c more brw-r- 1 root operator0, 15 Nov 2 18:20 /dev/wd0p brw-r- 1 root operator0, 16 Nov 2 18:19 /dev/wd1a and so on And operator has more priviliges; more than enough to trash the system, if he wants to, or to get root, if he is somewhat skilled. Far better to just change a single line in /etc/sudoers. while i don't disagree with your advice, could you still advice me on messing things up with operator privileges, as i'm curious... because i can't see how being able to read disks will give out enough information to do either Juha
Re: crypto disk
On Thu, Dec 22, 2005 at 07:32:27PM +0100, Ed White wrote: Quoting from: http://www.onlamp.com/lpt/a/6384 The biggest drawback of svnd is its lack of security in the general use case. It is vulnerable to an offline dictionary attack. That is, you can generate a database mapping known ciphertext blocks on the disk back into pass phrases that can be accessed in O(1) without even being in possession of the disk. What's even worse is that the same database will work on any svnd disk. It is possible--and perhaps even likely--that large agencies such as the NSA have constructed such a database and can crack a majority of the svnds in the world in less than a second. well, i'm not a developer nor a crypto expert, but basically that's just a way to do a brute force attack. it can work only with short keys, say with about 64 bits of entropy or less. that's about 16 random alphabets/digits. building lookup tables for larger keyspaces becomes rapidly unfeasible, so simply use a bigger key and you're safe from this type of attack The way that one prevents an offline dictionary attack is to use a salt in conjunction with the pass phrase, and this is what I did when I wrote CGD by using PKCS#5 PBKDF2. Offline dictionary attacks have been well-known since at least the '70s, and salting the pass phrase has been standard practice for over 30 years. well yes, salting should mitigate the issue Juha
Problem accessing ATAPI tape drive
i've been using an atapi tape drive with OpenBSD, hardware support list and manpages don't make it clear they are supported, but mine has worked fine, until upgrading to 3.8.. i use it with dump(8), so now as i try to restore something from tapes, i get this: $ restore -Nrv Verify tape and initialize maps restore: tape read error: Input/output error $ restore -i restore: tape read error: Input/output error also, syslogd doesn't get any messages from the kernel of course it's possible my tape drive has broken its contract with me, but maybe something relevant got changed between 3.7 and 3.8? suggestions? Juha dmesg follows: OpenBSD 3.8-stable (GENERIC) #0: Tue Nov 1 14:38:35 EET 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) 551 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,SER,MMX,FXSR,SSE cpu0: disabling processor serial number real mem = 133787648 (130652K) avail mem = 115462144 (112756K) using 1658 buffers containing 6791168 bytes (6632K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(75) BIOS, date 08/18/99, BIOS32 rev. 0 @ 0xf0530 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xf/0xbe2 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0b60/128 (6 entries) pcibios0: PCI Interrupt Router at 000:04:0 (VIA VT82C586 ISA rev 0x00) pcibios0: PCI bus #2 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 VIA VT82C691 PCI rev 0x22 ppb0 at pci0 dev 1 function 0 VIA VT82C598 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Rage Pro rev 0x5c wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 4 function 0 VIA VT82C596A ISA rev 0x09 pciide0 at pci0 dev 4 function 1 VIA VT82C571 IDE rev 0x06: ATA33, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: Maxtor 91021U2 wd0: 16-sector PIO, LBA, 9770MB, 20010816 sectors wd1 at pciide0 channel 0 drive 1: ST33232A wd1: 16-sector PIO, LBA, 3077MB, 6303024 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: PLEXTOR, CD-R PX-320A, 1.03 SCSI0 5/cdrom removable atapiscsi1 at pciide0 channel 1 drive 1 scsibus1 at atapiscsi1: 2 targets st0 at scsibus1 targ 0 lun 0: HP, COLORADO 8GB, 2.06 SCSI2 1/sequential removable st0: drive empty or not ready cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 st0(pciide0:1:1): using PIO mode 4, DMA mode 2 uhci0 at pci0 dev 4 function 2 VIA VT83C572 USB rev 0x02: irq 5 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: VIA UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ppb1 at pci0 dev 4 function 3 VIA VT82C596 Power rev 0x00 ppb1: not configured by system firmware eap0 at pci0 dev 9 function 0 Ensoniq AudioPCI97 rev 0x06: irq 5 ac97: codec id 0x43525913 (Cirrus Logic CS4297A rev 3) ac97: codec features headphone, 20 bit DAC, 18 bit ADC, Crystal Semi 3D audio0 at eap0 midi0 at eap0: AudioPCI MIDI UART isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 midi1 at pcppi0: PC speaker spkr0 at pcppi0 sysbeep0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 lm0 at isa0 port 0x290/8: W83781D npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec isapnp0 at isa0 port 0x279: read port 0x20b ep1 at isapnp0 3Com 3C509B EtherLink III, TCM5095, PNP80F7, port 0x210/16 irq 9: address 00:50:04:23:7a:70, utp (default utp) biomask ed65 netmask ef65 ttymask ffe7 pctr: 686-class user-level performance counters enabled mtrr: Pentium Pro MTRR support dkcsum: wd0 matches BIOS drive 0x80 dkcsum: wd1 matches BIOS drive 0x81 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302
