Re: Serial terminal (not console)
On Thu, Jan 23, 2014 at 10:47:05AM +, Zé Loff wrote:
> Sorry if it's a dumb question, but I'm stuck...
>
> I have two machines (yesterday's current, one i386, one amd64) and I can
> properly setup a serial console on the i386 and access it on the amd64
> (i.e. changes in boot.conf and /etc/ttys as per the FAQ). This tells me
> that the cable is OK, that there are no IRQ issues going on, that it all
> works at the set baud rate (9600), etc...
>
> However, I can't get a simple terminal on the same tty device (i.e. not
> the system's console). Without a /etc/boot.conf file, and an otherwise
> vanilla /etc/ttys except for the following line
>
> tty00 "/usr/libexec/getty std.9600" vt100 on secure
>
> I don't get a login prompt when connecting on the other machine, even if
> ps shows that there is a getty instance running for tty00.
>
> The ultimate goal is to be able to manage a couple of "com
> port-impaired" HP MicroServers using a couple of ATEN USB serial
> adapters, which can't be used for serial consoles for obvious reasons.
> That's why I need to get a login on a serial terminal other than the
> system's console...
>
> Any clues?
> Thanks in advance
> Zé
>
Sorry for insisting, but no one has a hint of why with this /etc/ttys
#
# $OpenBSD: ttys,v 1.18 2008/01/09 17:39:42 miod Exp $
#
# name getty typestatus comments
#
console "/usr/libexec/getty std.9600" vt100 on secure <---
ttyC0 "/usr/libexec/getty std.9600" vt220 on secure
ttyC1 "/usr/libexec/getty std.9600" vt220 on secure
ttyC2 "/usr/libexec/getty std.9600" vt220 on secure
ttyC3 "/usr/libexec/getty std.9600" vt220 on secure
ttyC4 "/usr/libexec/getty std.9600" vt220 off secure
ttyC5 "/usr/libexec/getty std.9600" vt220 on secure
ttyC6 "/usr/libexec/getty std.9600" vt220 off secure
ttyC7 "/usr/libexec/getty std.9600" vt220 off secure
ttyC8 "/usr/libexec/getty std.9600" vt220 off secure
ttyC9 "/usr/libexec/getty std.9600" vt220 off secure
ttyCa "/usr/libexec/getty std.9600" vt220 off secure
ttyCb "/usr/libexec/getty std.9600" vt220 off secure
tty00 "/usr/libexec/getty std.9600" vt220 off <---
...
and this /etc/boot.conf
stty com0 9600
set tty com0
I can remotely connect, but with this /etc/ttys
#
# $OpenBSD: ttys,v 1.18 2008/01/09 17:39:42 miod Exp $
#
# name getty typestatus comments
#
console "/usr/libexec/getty std.9600" vt220 off secure <---
ttyC0 "/usr/libexec/getty std.9600" vt220 on secure
ttyC1 "/usr/libexec/getty std.9600" vt220 on secure
ttyC2 "/usr/libexec/getty std.9600" vt220 on secure
ttyC3 "/usr/libexec/getty std.9600" vt220 on secure
ttyC4 "/usr/libexec/getty std.9600" vt220 off secure
ttyC5 "/usr/libexec/getty std.9600" vt220 on secure
ttyC6 "/usr/libexec/getty std.9600" vt220 off secure
ttyC7 "/usr/libexec/getty std.9600" vt220 off secure
ttyC8 "/usr/libexec/getty std.9600" vt220 off secure
ttyC9 "/usr/libexec/getty std.9600" vt220 off secure
ttyCa "/usr/libexec/getty std.9600" vt220 off secure
ttyCb "/usr/libexec/getty std.9600" vt220 off secure
tty00 "/usr/libexec/getty std.9600" vt100 on secure<---
...
and no /boot.conf I can't? Cluebats welcome.
Thanks in advance
Zé
dmesg:
OpenBSD 5.5-beta (GENERIC) #233: Mon Jan 20 15:47:05 MST 2014
t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 300
MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,PERF
real mem = 200765440 (191MB)
avail mem = 185614336 (177MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xfc4c0
apm0 at bios0: Power Management spec V1.2
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1320/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:05:0 ("Intel 82371FB ISA" rev
0x00)
pcibios0: PCI bus #21 is the last bus
bios0: ROM list: 0xc/0xc000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443BX" rev 0x02
vga1 at pci0 dev 4 function 0 "Neomagic Magicgraph NM2200" rev 0x12
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: scree
Re: unreliable connections
On 2014/01/26 14:53, Chris Smith wrote: > On Thu, Jan 16, 2014 at 8:26 PM, Stuart Henderson > wrote: > > This could be an MTU or RWIN-related issue. > > Could my issue have anything to with the "miscounting bug for inbound > with pf on" mentioned in the following commit? > > CVSROOT:/cvs > Module name:src > Changes by: henn...@cvs.openbsd.org 2014/01/23 16:51:29 > > Modified files: > sys/net: if_bridge.c pf.c > sys/netinet: ip_input.c ip_output.c ip_var.h tcp_input.c > tcp_var.h udp_usrreq.c udp_var.h > sys/netinet6 : ip6_output.c > > Log message: > since the cksum rewrite the counters for hardware checksummed packets > are are lie, since the software engine emulates hardware offloading > and that is later indistinguishable. so kill the hw cksummed counters. > introduce software checksummed packet counters instead. > tcp/udp handles ip & ipvshit, ip cksum covered, 6 has no ip layer cksum. > as before we still have a miscounting bug for inbound with pf on, to be > fixed in the next step. > found by, prodding & ok naddy > > > And if so was "the next step" taken and is this miscounting bug fixed? No this is just counting for statistics. > Also recently in an attempt to keep a box at -current there occurred a > kernel/userland mismatch that caused pf not to load on reboot after > installing the kernel (everything was fine after building userland). > I'm fairly certain trying to bring a box dated "OpenBSD 5.4-current > (GENERIC.MP) #5: Wed Jan 1 14:21:45 EST 2014" will have the same > issue. If I attempt to do this remotely will I still be able to shell > in in order to update userland (even though with no pf there is no nat > and therefore access to/from the inside network will not be possible) > after rebooting into the new kernel? Or might it be safe to build > userland before rebooting into the new kernel? > > Thank you, > > Chris See "Upgrading without install kernel" in the faq's upgrade guide. Note the specific order to untar sets. This isn't enough for the 5.4->-current flag day upgrade (which requires rebuilding the password database with new pwd_mkdb, but new pwd_mkdb won't run until you're on a new kernel), but since you have already passed that step, you should be ok. Obviously the install kernel method is safer if you can manage it.
Re: Question about debugging WLAN communication
Em 26-01-2014 16:26, j...@wxcvbn.org escreveu: > Eike Lantzsch writes: > > [...] > >> I just wonder why it works with my MACbook. >> The latter sends a lot of "no-data" packets which the Samsung phone >> does not. >> Does the athn driver or hardware "think" that the phone is "sleeping" >> and times out? > athn(4) doesn't mention this, but ath(4) does: > Host AP mode doesn't support power saving. Clients attempting to use > power saving mode may experience significant packet loss (disabling > power saving on the client will fix this). > Although if you disable power saving on the phone (I'm assuming this is possible, which AFAIK is not), it will drain your battery too quickly. So I believe the way is to change to another chipset that supports power saving. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Question about debugging WLAN communication
On Sun, Jan 26, 2014 at 7:26 PM, wrote: > Eike Lantzsch writes: > > [...] > >> I just wonder why it works with my MACbook. >> The latter sends a lot of "no-data" packets which the Samsung phone >> does not. >> Does the athn driver or hardware "think" that the phone is "sleeping" >> and times out? > > athn(4) doesn't mention this, but ath(4) does: This is because athn(4) does support power saving: kettenis@ added support for it some time ago...
yacc references
The diff below moves the journal volume reference into the .Rs block and adds pages. Jan --- yacc.1.orig Mon Jan 27 13:48:28 2014 +++ yacc.1 Mon Jan 27 13:53:10 2014 @@ -185,9 +185,11 @@ to the standard error. .Rs .%A F. DeRemer .%A T. J. Pennello -.%D 1982 -.%J TOPLAS .%T Efficient Computation of LALR(1) Look-Ahead Sets +.%J TOPLAS +.%V 4:4 +.%D 1982 +.%P 615-649 .Re .Sh STANDARDS The @@ -211,8 +213,7 @@ quit. .Pp Berkeley Yacc is based on the excellent algorithm for computing LALR(1) lookaheads developed by Tom Pennello and Frank DeRemer. -The algorithm is described in their almost impenetrable article in -TOPLAS 4,4. +The algorithm is described in their almost impenetrable article. .Pp Finally, much credit must go to those who pointed out deficiencies of earlier releases.
Re: NAT reliability in light of recent checksum changes
On Mon, Jan 27, 2014 at 8:19 AM, Simon Perreault < simon.perrea...@viagenie.ca> wrote: > Le 2014-01-25 14:40, Richard Procter a écrit : > > I'm not saying the calculation is bad. I'm saying it's being >> calculated from the wrong copy of the data and by the wrong >> device. And it's not just me saying it: I'm quoting the guys >> who designed TCP. >> > > Those guys didn't envision NAT. > > If you want end-to-end checksum purity, don't do NAT. > > Simon > > Relying on TCP checksums is risky - they are too weak. I live at the end of a wireless link that starts at around 7K feet elevation, goes over a 12K foot ridge, lands at my neighbors roof at 10k feet and then bounces across the street to my house. At one point I was having lots of issues with data corruption - updates failing, even images on web pages going technicolor half way through the download. The ISP ultimately determined there was a bad transmitter and replaced it. The corruption was so severe that it was overwhelming the TCP checksums to the point that as far as TCP was concerned it was delivering good data (just not the same data twice :-). Until they fixed the issue I was able to run a proxy over ssh which gave me slower but reliable network service. -N
Re: NAT reliability in light of recent checksum changes
Le 2014-01-25 14:40, Richard Procter a écrit : I'm not saying the calculation is bad. I'm saying it's being calculated from the wrong copy of the data and by the wrong device. And it's not just me saying it: I'm quoting the guys who designed TCP. Those guys didn't envision NAT. If you want end-to-end checksum purity, don't do NAT. Simon
Re: NAT reliability in light of recent checksum changes
Em 27-01-2014 14:30, Nick Bender escreveu: > On Mon, Jan 27, 2014 at 8:19 AM, Simon Perreault < > simon.perrea...@viagenie.ca> wrote: > >> Le 2014-01-25 14:40, Richard Procter a écrit : >> >> I'm not saying the calculation is bad. I'm saying it's being >>> calculated from the wrong copy of the data and by the wrong >>> device. And it's not just me saying it: I'm quoting the guys >>> who designed TCP. >>> >> Those guys didn't envision NAT. >> >> If you want end-to-end checksum purity, don't do NAT. >> >> Simon >> >> > Relying on TCP checksums is risky - they are too weak. > > I live at the end of a wireless link that starts at around 7K feet > elevation, goes over a 12K foot ridge, lands at my neighbors roof at 10k > feet and then bounces across the street to my house. At one point I was > having lots of issues with data corruption - updates failing, even images > on web pages going technicolor half way through the download. The ISP > ultimately determined there was a bad transmitter and replaced it. The > corruption was so severe that it was overwhelming the TCP checksums to the > point that as far as TCP was concerned it was delivering good data (just > not the same data twice :-). Until they fixed the issue I was able to run a > proxy over ssh which gave me slower but reliable network service. > > -N > I had the same issue on a different scenario. I traveled to a place where the internet connection was so slow and so unreliable, that almost all https handshakes would never complete. And yet checksums had a rate of almost 60% of them being ok. That's why I always have a VPN server lying around, to route my traffic to. In my experience, on very unreliable connections, a UDP vpn, such as openvpn, saves the day. NAT should (and will) have a very slow and painful death. But, then again, IPv4 is about to die for more than a decade, and it's still here. I guess the death will be very, very, very slow. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: NAT reliability in light of recent checksum changes
FWIW, you don't have to out in the sticks (the backwoods?) to have a network problem: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html However, as I understand it, in this case the TCP checksumming worked and protected the application from the corrupted data. Cheers, Robb.
Re: libpthread fifo fdlock
It was a peachy Sunday, Jan 26 2014, 22:05:25 when Marco Pfatschbacher
wrote:
> On Sun, Jan 26, 2014 at 03:44:14PM -0500, ido...@gmail.com wrote:
> > Hi misc@,
> > From http://marc.info/?l=openbsd-cvs&m=133217901415880&w=2
> >
> > "The ``sleep until we have a writer'' behaviour of an open() on a
> > fifo does so with the file descriptor table locked, so if we are
> > waiting for another thread to be our writer we will hang forever.
> >
> > Found this using zotero and firefox."
> >
> > This behavior indeed hangs latest FF+Zotero. Is it fixable?
>
>
> I've been running into this recently myself.
> What makes this worse, is that the process isn't even killable.
hmm, it agrees to die here without a fuss...
> Guenther tried to fix this, but it got backed out:
>
> http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/?id=d8a387a9a09560b65562bc317ad63427bc9cb819
>
this patch works for me. what exactly was the problem that made it
necessary to revert it?
> I was trying to look into this, but ran out of time :-(
>
> A workaround might be to patch either zotero or firefox, to
> open the fifo with O_RDWR instead of O_WRONLY.
> This way it won't block in open().
>
> Here's my test program to trigger the issue.
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
>
> void *
> open_thread(void *threadid)
> {
> int fd;
>
> sleep(1); /* delay to let main run into FIFO open first */
>
> printf("before open in thread\n");
>
> if ((fd = open("/tmp/regfile", O_CREAT| O_RDWR, 0600)) < 0)
> err(1, "open");
>
> printf("after open in thread\n");
>
> close(fd);
> pthread_exit(NULL);
> }
>
> int
> main(int argc, char** argv)
> {
> int fd;
> pthread_t thread;
> long t;
>
> if (pthread_create(&thread, NULL, open_thread, (void *)t) !=
> 0) err(1, "pthread_create");
>
> mkfifo("/tmp/block.fifo", 0600);
>
> printf("before blocking open in main\n");
>
> if ((fd = open("/tmp/block.fifo", O_WRONLY)) < 0)
> err(1, "open");
>
> printf("after blocking open in main\n");
>
> close(fd);
> pthread_exit(NULL);
> exit(0);
> }
Re: libpthread fifo fdlock
On Mon, Jan 27, 2014 at 19:27, ido...@gmail.com wrote: > It was a peachy Sunday, Jan 26 2014, 22:05:25 when Marco Pfatschbacher > wrote: > >> On Sun, Jan 26, 2014 at 03:44:14PM -0500, ido...@gmail.com wrote: >> > Hi misc@, >> > From http://marc.info/?l=openbsd-cvs&m=133217901415880&w=2 >> > >> > "The ``sleep until we have a writer'' behaviour of an open() on a >> > fifo does so with the file descriptor table locked, so if we are >> > waiting for another thread to be our writer we will hang forever. >> > >> > Found this using zotero and firefox." >> > >> > This behavior indeed hangs latest FF+Zotero. Is it fixable? >> >> >> I've been running into this recently myself. >> What makes this worse, is that the process isn't even killable. > > hmm, it agrees to die here without a fuss... > >> Guenther tried to fix this, but it got backed out: >> >> > http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit/?id=d8a387a9a09560b65562bc317ad63427bc9cb819 > >> > > this patch works for me. what exactly was the problem that made it > necessary to revert it? I have a new diff for this, which is waiting for some developers to review and then maybe we can fix this.
Re: NAT reliability in light of recent checksum changes
Em 27-01-2014 19:05, Why 42? The lists account. escreveu: > FWIW, you don't have to out in the sticks (the backwoods?) to have > a network problem: > > > http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html > > However, as I understand it, in this case the TCP checksumming worked > and protected the application from the corrupted data. > > Cheers, > Robb. > I wasn't exactly in the woods, but I had a 600Kbps unreliable ADSL connection that would send the packets. But the latency and corruption was so severe that TLS handshakes would take too long. And even if complete, the connection wouldn't sustain itself. Anyway, the UDP vpn improved things quite a bit. This due, well, to UDP of course, and to the dynamic compression, reducing the amount of data sent to the wire. This case you pointed, the TCP checksumming was doing it's job. Successfully protecting the application. This kind of things, where bits "randomly" flip, proves that computer science can be anything but an EXACT science. That's one of the reasons why the machines will (hopefully) always need humans. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: NAT reliability in light of recent checksum changes
On 01/27/2014 08:07 PM, Giancarlo Razzolini wrote: > Em 27-01-2014 19:05, Why 42? The lists account. escreveu: >> FWIW, you don't have to out in the sticks (the backwoods?) to have >> a network problem: >> >> >> http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html >> >> However, as I understand it, in this case the TCP checksumming worked >> and protected the application from the corrupted data. >> >> Cheers, >> Robb. >> > I wasn't exactly in the woods, but I had a 600Kbps unreliable ADSL > connection that would send the packets. But the latency and corruption > was so severe that TLS handshakes would take too long. And even if > complete, the connection wouldn't sustain itself. Anyway, the UDP vpn > improved things quite a bit. This due, well, to UDP of course, and to > the dynamic compression, reducing the amount of data sent to the wire. > > This case you pointed, the TCP checksumming was doing it's job. > Successfully protecting the application. This kind of things, where bits > "randomly" flip, proves that computer science can be anything but an > EXACT science. That's one of the reasons why the machines will > (hopefully) always need humans. > > Cheers, > To add to the preceeding... One client of mine used a CVS repository via coast-to-coast NFS. Somewhere in the deeps, the UDP checksum was set to 0 (no checksum). Somewhere else, one bit in each packet was corrupted. If the UDP checksum had been present we would have seen the bad data a lot sooner. We had to go back at least a month, sometimes more, to find good data, and then recreate all the edits. This scenario shows a danger of silently passing corrupt packets. It would be good if when data protected by a checksum is modified, the current checksum is validated and some appropriate? action is done (drop? produce invalid new checksum?) when proceeding. Geoff Steckel
PHP SIGSEGV with Mediawiki
I am having trouble with Mediawiki which started with the latest release, occurs for the long term stable, and the version under packages. When the install script is visited which comes with Mediawiki I get an error from FPM and a 503 bad gateway error. Unfortunately I've not been able to try much information from this, there are many people with similar problems but the answers are based on the same limited information. I have suhosin has been mentioned a few times, but I want to keep using it. I am not quite sure where to find the stack trace at this point. I have an OpenBSD 5.4 system using nginx and everything it uses comes out of packages. This is why to me it is largely an OpenBSD problem, though the stack trace might reveal how related it is to suhosin. [26-Jan-2014 00:17:37] NOTICE: [pool obfuscated] child 162 started [26-Jan-2014 00:17:44] WARNING: [pool obfuscated] child 28801 exited on signal 11 (SIGSEGV) after 963030.830741 seconds from start The time in seconds is in no way related to the script, where the response is actually quite quick in the browser. I am not sure what the actual meaning of that part of the error is supposed to be. I am used to this stuff just working. The fpm pool config is pretty standard and looks as follows... [obfuscated] user = obfuscated group = obfuscated listen = 127.0.0.1:9043 listen.owner = www listen.group = www pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 All the other pools are working fine with no such problems. There is no errors related to this failed request in messages or daemon logs so all I can leave you with is the dmesg. I hope someone can help and show me where to find more information such as the stack trace. That it happens even with the OpenBSD mediawiki package leads me to believe this would be the best place to mention the problem. OpenBSD 5.4 (GENERIC.MP) #41: Tue Jul 30 15:30:02 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130640896 (2031MB) avail mem = 2066255872 (1970MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (5 entries) bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006 bios0: innotek GmbH VirtualBox acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz, 2667.60 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,NXE,LONG,LAHF cpu0: 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz, 2667.22 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,NXE,LONG,LAHF cpu1: 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0 acpicpu1 at acpi0 acpibat0 at acpi0: BAT0 not present acpiac0 at acpi0: AC unit online pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 128-sector PIO, LBA48, 204800MB, 419430400 sectors wd0(pciide0:0:0): 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: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) em0 at pci0 dev 3 function 0 "Intel 82543GC" rev 0x02: apic 2 int 19, address 08:00:27:85:37:f9 "InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not configured piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: SMBus disabled 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 spkr0 at pcppi0 mtrr: CPU supports MTRRs but not enabled vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on wd0a (784d82c953376542.a) swap on wd0b dump on wd0b -- CYRUSERV Onionland Hosting: http://cyruserv5hlagzhg.onion/ new email address: cyrus_th
