Re: sed vs gsed and \+ difference
On Thu, 28 Jul 2016, Jiri B wrote: Hi, I can't understand a difference between OpenBSD and GNU sed when handling '\+' (one or more). Example: $ echo 'tzdata-2016a-1.el7.noarch.rpm' | sed 's/\(tzdata\)\+.*/\1/' tzdata-2016a-1.el7.noarch.rpm $ echo 'tzdata-2016a-1.el7.noarch.rpm' | gsed 's/\(tzdata\)\+.*/\1/' tzdata $ echo '1123456' | sed -n '/1\+23456/p' $ echo '1123456' | gsed -n '/1\+23456/p' 1123456 A bug or some hidden trick? A bug in you example. Character '\+' is a plus, not "one or more". For "one or more" you need '+' and extended regular expressions turned on with option -E. GNU sed probably has a different opinion about what operators are basic RE. See re_format(7). Regards, David
Re: Interesting error message from disk testing
On Tue, 28 Jun 2016, STeve Andre' wrote: I am testing some new 8TB disks. I've taken to doing dd if=/dev/zero of=/dev/rsd3c bs=64k and dd if=/dev/rsd3c of=/dev/null bs=64k as a first test. It's depressing how often I've found problems on big disks. Today, the read test produced an error in the messages file I've not seen before: Jun 28 16:17:39 paladin /bsd: sd3(umass0:1:0): Check Condition (error 0x70) on opcode 0x28 Jun 28 16:17:39 paladin /bsd: SENSE KEY: Aborted Command Jun 28 16:17:39 paladin /bsd: ASC/ASCQ: Information Unit iuCRC Error Detected So it isn't a soft read error -- what is it? It might be useful to indicate where the error occurred? This is the second of three disks to be tested. It's connected to a Thermaltake USB 3.0 disk enclosure. I have seen CRC errors number of times when working with different USB enclosures. My guess is that either the connectors inside the boxes aren't 100% tight, the electronics is not shielded properly or it has some flaws. If I am not mistaken, it is the transfer between the HDD electronics and the controller (ie. the bridge chip) that failed. Also see this thread: http://marc.info/?t=10989807768&r=1&w=2 I would also monitor the drive with smartctl from sysutils/smartmontools. Regards, David
Re: where is the image of openbsd arm ?
On Fri, 24 Jun 2016, Christian Weisgerber wrote: On 2016-06-24, "Jacob L. Leifman" wrote: Is it possible to add more wired NICs to the APU? Not really. You could add more ports with a mini-PCIe dual/quad NIC, but you would have to build your own case. As there are two USB ports, any USB-attached ethernet adapter should work. With a powered USB hub, probably a number of them. Am I right? Of course, performance of such a setup can't match that of a mini-PCIe ethernet adapter. Regards, David
Re: Is true that the BSD developers were inspired to make their code free software by the example of the GNU Project, and explicit appeals from GNU activists helped persuade them?
On Tue, 16 Feb 2016, Alexey Suslikov wrote: Jorge Luis gmail.com> writes: Is true that the BSD developers were inspired to make their code free software by the example of the GNU Project, and explicit appeals from GNU activists helped persuade them? If no, what is the true story of BSD developers? http://www.openbsd.org/lyrics.html#44 Also, for better understanding don't forget to read this too: http://www.openbsd.org/lyrics.html#43 Regards, David
Re: Backup of OpenBSD to Linux box
On Mon, 15 Jun 2015, Nick Holland wrote: On 06/15/15 12:54, Liviu Daia wrote: The other downside, if you use the --link-dest option, is that there's always only one copy of each file. A few days ago there was a post on SO by somebody who used that system, and found out that his backup disk had bad sectors in the middle of some large files. He wasn't amused. This has nothing to do with --link-dest, really. If your disk has bad spots, you will hope it was only one large file...usually, it's the whole disk you can't read. For any disk-to-disk system -- rsync, dump/restore, etc, you need some kind of "more than one copy, more than one place" solution, too. Disk-to-Disk doesn't change the rules of backups: multiple copies, off-site, etc. I kinda hoped that was understood, but that was probably my error. Moreover, that risk isn't related to --link-dest, it's a downside of any incremental backup system. Except when the backup medium itself is already redundant. An incremental backup solution was what the OP asked for. Regards, David
ASF, AMT and PCIe cards (Re: WOL support for bge driver)
On Mon, 18 May 2015, Stefan Sperling wrote: OTOH, many laptops nowadays ship with Intel AMT and suffer the same issue or worse. Yet we still run on them. Current AMT versions have an attack surface that dwarfs ASF's. Perhaps this is a lost cause and we'll simply have to accept that a lot of hardware is insecure by design. (I have borrowed another thread from tech@ for start this one.) This brings other questions. Are standalone PCIe cards safe from this? Many specification documents mention that they support at least ASF too. Don't they contain the same firmware (or most of it) as their onboard variants? What PCIe gigabit ethernet cards that are supported in OpenBSD are considered secure? Does anyone have a recommendation? Thank you. Regards, David
Re: disk change-out and packages
On Wed, 4 Mar 2015, Ed Ahlsen-Girard wrote: I decided to upgrade the internal drive, so I hooked up the new on on the CD's usual SATA channel and installed, having adjust the disklabel more to suit me (the auto partition of /usr left it really tight on space, and home was not big enough). First method: mount all the slices in /tree and run a series of cp -R as root. Files seemed to get there but something was not right with permissions when I tried booting the new disk, so I dropped back and did some research. Reinstalled, mounted the new slices as before, and ran: #!/bin/sh tar -cXf - /* | tar -xpf - -C /tree tar -cXf - /home/* | tar -xpf - -C /tree/home tar -cXf - /usr/* | tar -xpf - -C /tree/usr tar -cXf - /usr/X11R6/* | tar -xpf - -C /tree/usr/X11R6 tar -cXf - /usr/local/* | tar -xpf - -C /tree/usr/local tar -cXf - /usr/obj/* | tar -xpf - -C /tree/usr/obj tar -cXf - /usr/src/* | tar -xpf - -C /tree/usr/src tar -cXf - /var/* | tar -xpf - -C /tree/var I had copied the new disk's fstab so that the duids were right when I started from it. Results were interesting. I got another copy of /home inside /tree/home, as well as what I wanted in it, and youtube-dl turns out to make filenames too long for tar. Nevertheless, I could log in as myself. But running my usual packages at login didn't work: file not found. Should I have not tried to save that much time? I thought tar | tar would get everything. Do I need to install the packages on the new disk? Is this a time that pkg_check is my friend? pax -rw -pe was what you wanted. Possibly with the -k option too. Regards, David
Re: vnconfig crypto alternative
On Tue, 25 Nov 2014, Jason Tubnor wrote: With crypto being deprecated (and possibly removed in future versions - depending on dev direction) from vnconfig, would the following be assumed one way of providing an encrypted container? To create 200MB encrypted container: sudo dd if=/dev/zero of=/var/encrypt/container.encrypt bs=1m count=200 sudo chmod 600 /var/encrypt/container.encrypt sudo vnconfig vnd0 /var/encrypt/container.encrypt printf "a\n\n\n\nRAID\nw\nq\n\n" | sudo disklabel -E vnd0 sudo bioctl -c C -l vnd0a softraid0 ## Enter your secret passphrase here sudo dd if=/dev/zero of=/dev/rsd1c bs=1m count=1 printf "a\n\n\n\n4.2BSD\nw\nq\n\n" | sudo disklabel -E sd1 sudo newfs /dev/rsd1a sudo mount /dev/sd1a /encrypt ## When I tried this a couple of months ago I saw double figure of written bytes to the host device (where /var/encrypt resides in your case) than what I was actually writing to the softraid volume (/dev/sd1c in your case). It did not look neither efficient, nor healthy. Try dd if=/dev/zero of=/dev/rsd1c bs=1m while watching systat/iostat at the same time. Is it still the case? Regards, David
Re: 5.6 on Axiomtek NA570: BIOS freeze on reboot
On Mon, 27 Oct 2014, Harald Dunkel wrote: Hi folks, I've got 2 NA570 (a network appliance from Axiomtek). Problem: OpenBSD 5.6 installs fine, but this seems to poison the installation target disk somehow. It doesn't boot. :-( I have to overwrite the MBR just to make the BIOS work again. Or I have to use a 4GB CF card for booting. Surely not OpenBSD's fault; the BIOS should work no matter what. But I wonder what the is going on? Anybody got an idea? Have you seen something similar? This quite recent thread comes to mind: http://marc.info/?t=13988430601&r=1&w=2 Are your symptoms similar? AMI BIOS versions dated close to each other, maybe. Regards, David
Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On Mon, 18 Aug 2014, Jason Tubnor wrote: On 2 June 2014 10:23, Ted Unangst wrote: Part of the deprecation / migration process is identifying the weird ways people use vnd and finding solutions for them. But as we've seen, people never move forward without the occasional push. So the most appropriate way to use vnd(4) as an encrypted container going forward would be to lay down softraid(4) CRYPTO inside it to achieve a like-for-like outcome or would this be over-complicating things? I have had success in testing this use case but I am aware it may not be supported. To revive this old thread again (I missed the recent post): I tesed the same or similar (softraid(4) crypto volume on top of unencrypted vnd(4) device in my case) in July this year and I saw some kind of write amplification effect by a factor of two. The resulting effective writing speed was quite low. The sector size of the underlying hard drive was 4K bytes. Regards, David
piping password to vnconfig(8)
Hello, I see this question appeared a few times in the past, but without a complete answer. Is there a trick, preferrably a simple one, to make vnconfig(8) read the password from stdin? Thank you. Regards, David
Re: FFS1: already clean, but inconsistent
On Sat, 9 Aug 2014, Philip Guenther wrote: [...] Is there any explanation for the two additional links in the reference count? Should I be worried that I've lost two subdirectories somehow? Maybe? It could have been a bogus duplicated increment from some bug and everything is fine, or it could have been a missing chain of other writes and you lost stuff. Without knowing exactly what bug you hit it's impossible to say. There have been ffs fixes since 5.3 that might be involved, so you should certainly upgrade from that old (ahem, no longer supported) release. Thanks for your response. More likely (and hopefully) it is the former, as I fsck'd the drive about a month or two ago and no errors were reported. I don't miss any new data since then. Thus the missing chain of other writes seems unlikely. Since the previous fsck, I didn't remove any files or subdirectories and the use of that filesystem for writing was very light. Unless I was copying new data to that filesystem, it was mounted as read-only, but most of the time the disk was off. (To my surprise) I was able to compare the subdirectories with my backups. It is highly improbable that I would have lost any of the subdirectories. As for the slightly older release, I am in the process of sorting and moving the data, an upgrade will follow. Regards, David
FFS1: already clean, but inconsistent
Hello, I encountered the following issue on my FFS1 data filesystem. It didn't suffer any unclean shutdown since at least last fsck(8) run (yes, it is already clean), nonetheless fsck(8) reports incorrect link count of one of the directories. It didn't complain before and the filesystem never experienced any unclean shutdown when being written to. # /sbin/fsck -nf /dev/rsd5a ** /dev/rsd5a (NO WRITE) ** File system is already clean ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT DIR I=7362198 OWNER=1005 MODE=40755 SIZE=19968 MTIME=Jul 23 16:47 2014 COUNT 574 SHOULD BE 572 ADJUST? no ** Phase 5 - Check Cyl groups 926687 files, 479312280 used, 1183201 free (91681 frags, 136440 blocks, 0.0% fragmentation) # /bin/ls -ldi /mnt/photo/ 7362198 drwxr-xr-x 574 1005 1005 19968 Jul 23 16:47 /mnt/photo The /mnt/photo/ directory (inode 7362198) currently lists 570 subdirectories as fsck(8) suggests (572-2) and there shouldn't be any extraordinary hardlinks to that directory. I didn't delete any subdirectory from that directory. The filesystem is FFS1, the device is a regular 512 bytes/sector external USB hard drive. Write operation are usually done while this filesystem is mounted with -o softdep. The filesystem was handled by this snapshot: OpenBSD 5.3 (GENERIC.MP) #53: Fri Mar 1 09:34:37 MST 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP I also verified filesystem integrity with recent ramdisk kernels, with the same result. Is there any explanation for the two additional links in the reference count? Should I be worried that I've lost two subdirectories somehow? (I can't verify that.) Thanks for any hints. Regards, David
Re: openbsd and badusb
Hello, I have already met something of that kind. Not exactly, but very close. A USB flash drive that changes its vendor and model on the fly. Both strings and IDs changed. Light intensity of the blinking LED also changed at the same time. Just plug and unplug. I think that in a similar way as some fish can change their sex, some USB devices can change their manufacturer during their life. Originally it was: umass1 at uhub0 port 4 configuration 1 interface 0 "Kingston DT Elite 3.0" rev 2.10/1.00 addr 3 umass1: using SCSI over Bulk-Only scsibus4 at umass1: 2 targets, initiator 0 sd4 at scsibus4 targ 1 lun 0: SCSI4 0/direct removable serial.0951168cAC90909F sd4: 15008MB, 512 bytes/sector, 30736384 sectors , umass1 at uhub0 port 4 configuration 1 interface 0 "SKYMEDI USB Drive" rev 2.10/1.00 addr 2 umass1: using SCSI over Bulk-Only scsibus4 at umass1: 2 targets, initiator 0 sd4 at scsibus4 targ 1 lun 0: SCSI4 0/direct removable , umass1 at uhub0 port 4 configuration 1 interface 0 " " rev 2.10/1.00 addr 3 umass1: using SCSI over Bulk-Only scsibus4 at umass1: 2 targets, initiator 0 sd4 at scsibus4 targ 1 lun 0: <, , 1.00> SCSI4 0/direct removable sd4: 15008MB, 512 bytes/sector, 30736384 sectors It stays with that blank vendor so far, only ocassionaly it reports itself as SKYMEDI. I never saw Kingston again. The stored data remained untouched, at least I didn't encounter any problem. I think it is more likely a buggy firmware from Kingston (or from Skymedi, who apparently is the real OEM manufacturer of the controller) rather than a failing hardware. Regards, David
Re: Weird disk problem
On Sun, 8 Jun 2014, Christian Weisgerber wrote: On 2014-06-05, David Vasek wrote: Did you try smartctl from smartmontools for a more detailed report? I assume there is a 1000-page SMART spec somewhere that would come in handy for interpreting the responses? I'm not an expert. But I believe there are some reading this mailing list. There is a description of the interface available, but I don't think it can help you to interpret the numbers. ftp://ftp.t10.org/t13/docs2004/D1699-ATA8-ACS.pdf http://www.hgst.com/tech/techlib.nsf/techdocs/EF593BD721D5D2768825782D000B8111/$file/DS7K3000_US7K3000_SATA_OEMSpecRev1.3.pdf (beware of the $ character in the url) What I usually care about are attributes like Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector, Offline_Uncorrectable, Spin_Retry_Count, UDMA_CRC_Error_Count. I monitor my drives in the long term and watch if any of these values rises. And of course, the SMART Error Log is important. As for the other attributes such as Raw_Read_Error_Rate, Throughput_Performance and Seek_Error_Rate, every vendor seem to use it in a different way. Btw, the model of Hitachi drive you have problems with is said to be one of the most reliable hard drives. http://blog.backblaze.com/2014/01/21/what-hard-drive-should-i-buy/ http://www.hgst.com/tech/techlib.nsf/techdocs/EC6D440C3F64DBCC8825782300026498/$file/US7K3000_ds.pdf. http://www.hgst.com/tech/techlib.nsf/products/Ultrastar_7K3000 smartctl -t short /dev/sd1c Not supported, it seems. It is surprising, all Hitachi hard drives I have support short test. If it isn't a secret, could I get the 'smartctl -a' output from your drive for comparison? Thanks. Regards, David
Re: Price of Unix
On Tue, 10 Jun 2014, Nick Holland wrote: "UNIX System V, Release 2.0, Source Code (1) .. $43,000.00" "Each Additional CPU .. $16,000.00" And so on.. :-) OpenBSD: Unix, now more than 99.8% off!! AND free additional CPUs! What a deal! Go buy a cd set now! It's an unfair advertisment. You are trying to conceal that the buyer will get by at least 99.8% less bugs. Regards, David
Re: Weird disk problem
On Thu, 5 Jun 2014, Christian Weisgerber wrote: I have a 3TB disk here... sd1 at scsibus1 targ 1 lun 0: SCSI3 0/direct fixed naa.5000cca225c5fbeb sd1: 2861588MB, 512 bytes/sector, 5860533168 sectors ... that's serving as a general media dump with a single FFS2 file system on it. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1d 2.7T2.5T 63.7G98%/export Yesterday, I experienced the odd effect that reading some files, or parts of files, from that disk became excruciatingly slow. We're talking a few kB/s here. Other files were fine. There were no kernel errors/warnings whatsoever. There were no read errors, the disk was just 100% busy and appeared to be returning data drip by drip. # atactl sd1 smartstatus No SMART threshold exceeded No change on reboot. dd(1) from the raw device was initially fast, then slowed to a crawl as it progressed. I eventually "fixed" it all by powering off the machine, jiggling the SATA connectors (all fine), and powering the machine back up. Tonight the problem is back. Something is very wrong. Given that dd if=/dev/rsd1c also seems affected, the filesystem layer can be excluded. I won't cry too much over a dying disk, but why the heck are there no error indications of any kind? Any other ideas? Did you try smartctl from smartmontools for a more detailed report? My favourite are: smartctl -a /dev/sd1c smartctl -l scttemp /dev/sd1c smartctl -t short /dev/sd1c smartctl -t long /dev/sd1c (will take several hours!!!) smartctl -a /dev/sd1c (again after each of the tests) Regards, David
Re: encrypted vnd Fwd: CVS: cvs.openbsd.org: src
On Fri, 30 May 2014, Theo de Raadt wrote: Robert [info...@die-optimisten.net] wrote: On Fri, 30 May 2014 12:19:35 -0400 Ted Unangst wrote: WARNING: Encrypted vnd is insecure. Migrate your data to softraid before 5.7. Will 5.6 softraid support block sizes other than 512 byte? marc.info/?l=openbsd-misc&m=139524543706370 There are no plans for it right now. They way I read the original message (and please correct me if this is wrong!), is that something will happen in 5.7 that will disable encrypted vnd. Which means that people with recent internal/external HDs, that use 4k blocks, will have a problem. (Some disks allow you to use jumper settings for 512b, but not all external ones) Wow, don't know where you got that from. Sometimes it is just a simple explanation. Could you please provide a little bit more information? What causes encrypted vnd to be insecure and what will happen to vnd(4) before 5.7 if it isn't removal of crypto? Also, are there any options remaining to encrypt non-512-byte/sector devices, data on NFS filesystems ("NAS" boxes) and removable/backup media other than hard drives (or that pretend to be hard drives)? Thank you. Regards, David
another CPU frequency bug
Hello misc@ every time hw.setperf crosses the border between 50 and 49 in direction from higher to lower value, the MP kernel on this machine reports: CPU1: acpicpu setperf failed to alter frequency It only occurs with the MP kernels and the reported CPU is always CPU1. I see the performance indeed drops, but the pollution of the system console, dmesg and logs caused by this in conjunction with "apmd -C" is quite annoying. Does anybody know what's wrong and what can be done to fix it? Thank you. Regards, David OpenBSD 5.5-current (GENERIC.MP) #54: Sun Apr 20 03:46:09 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF real mem = 526807040 (502MB) avail mem = 505761792 (482MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/24/08, BIOS32 rev. 0 @ 0xfa080, SMBIOS rev. 2.4 @ 0xf (34 entries) bios0: vendor Phoenix Technologies, LTD version "MS7336 1.14" date 11/24/2008 bios0: Hewlett-Packard HP Compaq dx2300 Microtower acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET MCFG APIC SSDT SSDT acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S5) UAR2(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S3) AC97(S5) AZAL(S5) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 2 (HUB0) acpicpu0 at acpi0: FVS, 1800, 1200 MHz acpicpu1 at acpi0: FVS, 1800, 1200 MHz acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xb000! 0xcc000/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82946GZ Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82946GZ PCIE" rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 "Intel 82946GZ Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x1024 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi azalia0: codecs: Realtek ALC888 audio0 at azalia0 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 4 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 4 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 4 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 4 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 pci2 at ppb1 bus 2 fxp0 at pci2 dev 8 function 0 "Intel 82801GB LAN" rev 0x01, i82562: apic 4 int 20, address xx:xx:xx:xx:xx:xx inphy0 at fxp0 phy 1: i82562ET 10/100 PHY, rev. 0 ichpcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01: PM disabled pciide0 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using apic 4 int 19 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 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 5 ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 4 int 19 iic0 at ichiic0 iic0: addr 0x2f 00=c0 01=07 02=00 03=00 04=07 05=00 06=00 07=00 14=14 15=62 16=03 17=04 words 00=c0f
root.mail - a minor correction
Hello. Be consistent in what terms are used. Regards, David Index: etc/root/root.mail === RCS file: /cvs/src/etc/root/root.mail,v retrieving revision 1.101 diff -u -p -u -r1.101 root.mail --- etc/root/root.mail 26 Feb 2014 17:58:04 - 1.101 +++ etc/root/root.mail 9 May 2014 21:54:34 - @@ -22,7 +22,7 @@ the popular emacs editor.) Again, PLEASE READ THE MANUAL PAGES. Our developers have spent countless hours improving them so that they are clear and precise. -If you have installed the X11 packages during the install process, you can +If you have installed the X11 file sets during the install process, you can find further information regarding configuration in the file /usr/X11R6/README. Several popular binary packages (pre-compiled applications) are available
Re: Weird disklabel problem
On Wed, 30 Apr 2014, Martijn Rijkeboer wrote: Hello, I've got a weird disklabel related problem (or so it seems). When I partition my harddisk with fdisk and add an OpenBSD (A6) primary partition the system can still boot, but once I place a disklabel on the partition (disklabel -E sd0) I can't boot the system anymore (it freezes during the post). Your MBR OpenBSD partition is not flagged as active. (from your other e-mail:) fdisk after === Disk: /dev/rsd0cgeometry: 121601/255/63 [1953523055 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] -- 0: A6 0 32 33 - 121601 25 24 [2048: 1953519616 ] OpenBSD 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused Regards, David
Re: Dell PE R210 won't boot from install54.iso CD
On Tue, 22 Apr 2014, Mike Grau wrote: Not necessarily but possibly related, FreeBSD also cannot currently boot or run on many Dell R-series systems. It's an ongoing issue over there. -Adam I see ... Yes, it will not boot a FreeBSD 10.0 either. Guess I'm out of luck for now. You are giving up too early. I have a P4 Optiplex where I was never able to boot OpenBSD from a flash drive. But PXE for the kernel together with the filesystem from the flash drive always worked. Regards, David
4k-sectors: growfs(8) fails
growfs(8) also fails on a 4k-byte/sector disk. Simple patch for the man page added. Connected >> OpenBSD/i386 BOOT 3.21 boot> boot kernel/i386/bsd.mp -a booting hd0a:kernel/i386/bsd.mp: -\|/-\|/-9831612\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\! |/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\+1082924 [72+407248|/-\|/-\|/-\|/-\|/-\|/-\|+400515/-\|/-\|/-\|/-\|/-\|/-\|]=0xb2e020 entry point at 0x200120 [ using 808248 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5-current (GENERIC.MP) #54: Sun Apr 20 03:46:09 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF real mem = 526807040 (502MB) avail mem = 505761792 (482MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/24/08, BIOS32 rev. 0 @ 0xfa080, SMBIOS rev. 2.4 @ 0xf (34 entries) bios0: vendor Phoenix Technologies, LTD version "MS7336 1.14" date 11/24/2008 bios0: Hewlett-Packard HP Compaq dx2300 Microtower acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET MCFG APIC SSDT SSDT acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S5) UAR2(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S3) AC97(S5) AZAL(S5) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 2 (HUB0) acpicpu0 at acpi0: FVS, 1800, 1200 MHz acpicpu1 at acpi0: FVS, 1800, 1200 MHz acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xb000! 0xcc000/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82946GZ Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82946GZ PCIE" rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 "Intel 82946GZ Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x1024 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi azalia0: codecs: Realtek ALC888 audio0 at azalia0 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int 23 uhci1
4k-sectors: dump(8) fails
Hello, some more 4k-bytes/sector fun today. dump(8) doesn't like the 4k-byte/sectors source devices. There is an output below as an example and also related patch for the man page. With restore(8), i did't encounter any problems when restoring dumps of regular 512-byte/sectors filesystems to a filesystem residing on a 4k-byte/sector device. (I silently suppose that all sector sizes other than 512 bytes are affected.) Connected >> OpenBSD/i386 BOOT 3.21 boot> boot kernel/i386/bsd.mp -a booting hd0a:kernel/i386/bsd.mp: -\|/-\|/-9831612\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\! |/-\ |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\+1082924 [72+407248|/-\|/-\|/-\|/-\|/-\|/-\|+400515/-\|/-\|/-\|/-\|/-\|/-\|]=0xb2e020 entry point at 0x200120 [ using 808248 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.5-current (GENERIC.MP) #54: Sun Apr 20 03:46:09 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF real mem = 526807040 (502MB) avail mem = 505761792 (482MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/24/08, BIOS32 rev. 0 @ 0xfa080, SMBIOS rev. 2.4 @ 0xf (34 entries) bios0: vendor Phoenix Technologies, LTD version "MS7336 1.14" date 11/24/2008 bios0: Hewlett-Packard HP Compaq dx2300 Microtower acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET MCFG APIC SSDT SSDT acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S5) UAR2(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S3) AC97(S5) AZAL(S5) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 2 (HUB0) acpicpu0 at acpi0: FVS, 1800, 1200 MHz acpicpu1 at acpi0: FVS, 1800, 1200 MHz acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xb000! 0xcc000/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82946GZ Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82946GZ PCIE" rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 "Intel 82946GZ Video" rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 intel
4k-sectors: installboot(8) wipes the disklabel(5)
Hello, the new installboot(8) wipes the disk label on a 4k-byte/sector drive - a valid disk label becomes binary zeros after /usr/sbin/installboot -r /mnt sd4 To be more precise, the "boot sector" (the first 512 bytes) gets installed, but the disk label (the next 512 bytes) is overwritten with zeros. OpenBSD 5.5-current (RAMDISK_CD) #48: Sun Apr 20 03:50:37 MDT 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD Regards, David
Re: crypto vnd(4) question
On Mon, 24 Mar 2014, Chris Cappuccio wrote: Keep in mind, vnd emulates 512 byte sectors because that's the default disklabel that it uses (You probably mean a disktab, not a disklabel.) I am aware of it. As vnd(4) is a descendant of svnd(4), mixing different sector sizes should not be a big problem. I think that the danger of hidden bugs is higher in the crypto code when used together with emulated 4k-byte sectors, which is used (read: tested) much less. I will try both variants, nonethless. Thank you. Regards, David
Re: crypto vnd(4) question
On Sun, 23 Mar 2014, Robert wrote: Hi, I have two external USB disks, 3TB and 4TB, in use like that. So far no problems, even after hard reboots (power outage). They are used for backups, and it's USB 2.0 - so I can't really say much about "intense writing"... Hi, thanks for your response. Did you tune the host filesystem in any way? What mount options do you use for both the host filesystem and the one on the vnd image? By intensive writing I mean usage like "tar xzf ports.tar.gz" and such. It is not "so much" intensive, but it possibly may cause problems nonetheless. I already did some experiments with a 40 GB vnd image. I saw a little slow tranfers over NFS (~ 6 MB/s and less when reading from the filesystem on a vnd) and one complete lock up when the vnd was under read/write load. But I was not able to reproduce the lock up later. Regards, David
crypto vnd(4) question
Hello, I would like to ask you. Does anybody have a real life experience with a few TB large encrypted vnd(4) image which hosts a filesystem which is intensively written to and read from? In such a setup where the host device is a 4k-byte sector drive and the vnd(4) emulates a 512-byte sector device, is it robust enough? I suppose the vnd sectors would be used in groups of eight or more (4096-byte fragments) and would be aligned to the host drive sectors. Are there any issues? Is the double filesystem overhead and double buffering a problem? AFAIK, it is the only alternative to softraid crypto discipline for 4k-byte sector drives now. Thank you. Regards, David
Re: new to OpenBSD and have a few questions
On Sun, 9 Feb 2014, d...@genunix.com wrote: Actually, I didn't. The "install" process did. I didn't see any other options presented and from the install log : What platform is it on actually? Do you need to care about MBR and fdisk(8) at all? question one is easy : # uname -r 5.4 # uname -m sparc64 question two is honestly : I don't know. Yet. :-\ One of the Frequently Asked Questions, apparently. :-) http://www.openbsd.org/faq/faq14.html#fdisk The rest of the FAQ will help you too. Regards, David
Re: new to OpenBSD and have a few questions
On Sun, 9 Feb 2014, d...@genunix.com wrote: :: David Vasek said :: You do not have any MBR partitions on your drive, you used whole raw drive sd0c. Actually, I didn't. The "install" process did. I didn't see any other options presented and from the install log : What platform is it on actually? Do you need to care about MBR and fdisk(8) at all? Regards, David
Re: Help troubleshooting performance problem
On Mon, 2 Dec 2013, Erling Westenvik wrote: On Mon, Dec 02, 2013 at 03:39:17PM +0100, Jan Lambertz wrote: I m not sure if you already investigated this but s.m.a.r.t. has quite many diagnostic info. Even if the drive has not actually been marked as broken. This is somewhat vendor dependent. I did not check these info with openbsd but it should be possible. You have smartmontools in packages. ... and atactl(8) in the base system. Regards, David
newfs_msdos(8) creates faulty filesystems
Hello, a filesystem created by newfs_msdos(8) is reported as faulty by fsck_msdos(8). And it is indeed. Repeatable. There must be something wrong. The media itself (a USB flash drive) doesn't have any issues. # newfs -t msdos /dev/rsd4i /dev/rsd4i: 31224352 sectors in 3903044 FAT32 clusters (4096 bytes/cluster) bps=512 spc=8 res=32 nft=2 mid=0xf8 spt=63 hds=255 hid=8064 bsec=31285376 bspf=30493 rdcl=2 infs=1 bkbs=2 # fsck -n /dev/rsd4i ** /dev/rsd4i (NO WRITE) ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Check Directories ** Phase 4 - Check for Lost Files Free space in FSInfo block (-1) not correct (3903043) fix? no Next free cluster in FSInfo block (2) not free fix? no 1 files, 3029260 free (3903043 clusters) # fsck /dev/rsd4i ** /dev/rsd4i ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Check Directories ** Phase 4 - Check for Lost Files Free space in FSInfo block (-1) not correct (3903043) fix? [Fyn] y Next free cluster in FSInfo block (2) not free fix? [Fyn] y 1 files, 3029260 free (3903043 clusters) # fsck /dev/rsd4i ** /dev/rsd4i ** Phase 1 - Read and Compare FATs ** Phase 2 - Check Cluster Chains ** Phase 3 - Check Directories ** Phase 4 - Check for Lost Files 1 files, 3029260 free (3903043 clusters) OpenBSD 5.3 (GENERIC.MP) #53: Fri Mar 1 09:34:37 MST 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP umass1 at uhub0 port 4 configuration 1 interface 0 "Kingston DT 101 G2" rev 2.00/1.00 addr 3 umass1: using SCSI over Bulk-Only scsibus4 at umass1: 2 targets, initiator 0 sd4 at scsibus4 targ 1 lun 0: SCSI0 0/direct removable serial.09511642BC81D71A0189 sd4: 15280MB, 512 bytes/sector, 31293440 sectors # fdisk sd4 Disk: sd4 geometry: 1947/255/63 [31293440 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- *0: 0C 0 128 1 - 1947 236 17 [8064:31285376 ] Win95 FAT32L 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused # disklabel sd4 # /dev/rsd4c: type: SCSI disk: SCSI disk label: DT 101 G2 duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1947 total sectors: 31293440 boundstart: 0 boundend: 31293440 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 312934400 unused i: 31285376 8064 MSDOS Regards, David
Re: ntfs with big files
On Thu, 17 Oct 2013, David Vasek wrote: On Fri, 11 Oct 2013, Joel Sing wrote: On Thu, 10 Oct 2013, Manuel Giraud wrote: Hi, I have a ntfs partition with rather large (about 3GB) files on it. When I copy these files on a ffs partition they are corrupted. When I try to checksum them directly from the ntfs partition the checksum is not correct (compared to the same file on a fat32 partition copied with Windows). I tried this (with same behaviour) on i386 5.3 release and on i386 last week current. I'm willing to do some testing to fix this issue but don't really know where to start. See if you can isolate the smallest possible reproducable test case. If you create a 3GB file with known content (e.g. the same byte repeated), does the same issue occur? If so, how small do you need to go before the problem goes away? Also, what operating system (and version) was used to write the files to the NTFS volume? Hello, I encountered the same issue. Anything over the 2 GB limit is wrong. I mean, first exactly 2 GB of the file are read correctly, following that I get wrong data till the end of the file. It is reproducible with any file over 2 GB in size so far. Smells like int somewhere... I get the same wrong data with any release since at least 5.0, didn't test anything older, but I bet it is the same. The filesystem is a Windows XP NTFS system disk, 32-bit, the files were copied there with explorer.exe. Some additional notes and findings: (1) The data I receive after first 2 GB are not part of the file, the data is from another file (from the same directory, if that fact could be important). The data is taken in uninterrupted sequence and the starting offset of that sequence is way less than 2 GB in the other file where the data belong. (2) While reading past 2 GB in larger blocks gives me just wrong data, reading in smaller blocks (2kB and less) gives me kernel panic in KASSERT immediately when I read past the 2 GB limit. It is 100% reproducible with any file larger than 2 GB so far. # mount -r /dev/wd0i /mnt # ls -lo /mnt/DATA/ntfs_2gb_test.bin -rwxr-xr-x 1 root wheel - 3054813184 Oct 17 22:11 /mnt/DATA/ntfs_2gb_test.bin # cat /mnt/DATA//ntfs_2gb_test.bin > /dev/null # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=4k of=/dev/null 745804+0 records in 745804+0 records out 3054813184 bytes transferred in 108.518 secs (28150083 bytes/sec) # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=2k count=1m of=/dev/null 1048576+0 records in 1048576+0 records out 2147483648 bytes transferred in 78.783 secs (27258052 bytes/sec) # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=1k count=2m of=/dev/null 2097152+0 records in 2097152+0 records out 2147483648 bytes transferred in 81.210 secs (26443280 bytes/sec) # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=4k skip=512k of=/dev/null 221516+0 records in 221516+0 records out 907329536 bytes transferred in 32.314 secs (28077667 bytes/sec) # dd if=/mnt/DATA/ntfs_2gb_test.bin bs=2k skip=1m of=/dev/null panic: kernel diagnostic assertion "cl == 1 && tocopy <= ntfs_cntob(1)" failed: file "../../../../ntfs/ntfs_subr.c", line 1556 Stopped at Debugger+0x4: popl%ebp RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb> trace Debugger(d08fdcbc,f544fb88,d08dc500,f544fb88,200) at Debugger+0x4 panic(d08dc500,d085fc0e,d08dfe60,d08e00b0,614) at panic+0x5d __assert(d085fc0e,d08e00b0,614,d08dfe60,8) at __assert+0x2e ntfs_readntvattr_plain(d1a2d200,d1a36200,d1a5bc00,8800,0) at ntfs_readntvat tr_plain+0x2e6 ntfs_readattr_plain(d1a2d200,d1a36200,80,0,8800) at ntfs_readattr_plain+0x1 41 ntfs_readattr(d1a2d200,d1a36200,80,0,8800) at ntfs_readattr+0x156 ntfs_read(f544fddc,d64e5140,d6522a60,f544fea0,0) at ntfs_read+0xa8 VOP_READ(d6522a60,f544fea0,0,d6599000,d64e5140) at VOP_READ+0x35 vn_read(d65290a8,d65290c4,f544fea0,d6599000,0) at vn_read+0xb5 dofilereadv(d65365d4,3,d65290a8,f544ff08,1) at dofilereadv+0x13a sys_read(d65365d4,f544ff64,f544ff84,106,d653f100) at sys_read+0x89 syscall() at syscall+0x227 --- syscall (number 0) --- 0x2: ddb> ps PID PPID PGRPUID S FLAGS WAIT COMMAND *19967 9961 19967 0 7 0dd 9961 1 9961 0 30x88 pause sh 14 0 0 0 30x100200 aiodoned aiodoned 13 0 0 0 30x100200 syncerupdate 12 0 0 0 30x100200 cleaner cleaner 11 0 0 0 30x100200 reaperreaper 10 0 0 0 30x100200 pgdaemon pagedaemon 9 0 0 0 30x100200 bored crypto 8 0 0 0 30x100200 pftm pfpurge 7 0 0 0 30x100200 usbtskusbtask 6 0 0 0 30x100200 usbatsk usb
Re: ntfs with big files
On Fri, 11 Oct 2013, Joel Sing wrote: On Thu, 10 Oct 2013, Manuel Giraud wrote: Hi, I have a ntfs partition with rather large (about 3GB) files on it. When I copy these files on a ffs partition they are corrupted. When I try to checksum them directly from the ntfs partition the checksum is not correct (compared to the same file on a fat32 partition copied with Windows). I tried this (with same behaviour) on i386 5.3 release and on i386 last week current. I'm willing to do some testing to fix this issue but don't really know where to start. See if you can isolate the smallest possible reproducable test case. If you create a 3GB file with known content (e.g. the same byte repeated), does the same issue occur? If so, how small do you need to go before the problem goes away? Also, what operating system (and version) was used to write the files to the NTFS volume? Hello, I encountered the same issue. Anything over the 2 GB limit is wrong. I mean, first exactly 2 GB of the file are read correctly, following that I get wrong data till the end of the file. It is reproducible with any file over 2 GB in size so far. Smells like int somewhere... I get the same wrong data with any release since at least 5.0, didn't test anything older, but I bet it is the same. The filesystem is a Windows XP NTFS system disk, 32-bit, the files were copied there with explorer.exe. Regards, David
Re: 4k-sector drives
On Sat, 3 Aug 2013, Robert wrote: While some disks emulate their 4k sectors as 512b, some don't. E.g., I have a WD "My Book 1140" 3TB external USB disk, which reports 4k. Softraid doesn't work with it, I have to use vnd instead (for encryption). Some new WD My Book models alegedly allow you to select sector size (512 bytes or 4096 bytes) with WD Quick Formatter software. You must ``format'' the drive as Factory Default (as opposite to XP Compatible) for 512-byte blocks. I don't know what happens with the data already on the disk, though. Be aware, that many recent WD My Book drives also silently encrypt everything on the disk with unique encryption key stored in the enclosure electronics. They encrypt data sectors *always*, you don't need to set a password. Once the enclosure electronics dies or you move the disk out of the enclosure, you won't get your data back. I also believe that in case of your disk, data are stored as 4096-byte sectors on platters, drive electronics emulates 512-byte sectors (512e) on the SATA interface and the enclosure groups those 512-byte sectors back again to emulate 4096-byte sectors on the USB interface. So your disk likely emulates 512-byte sectors, while the enclosure emulates 4096-byte sectors, even if you had used a real 512-byte sector drive in it. Regards, David
Re: 4k-sector: wrong sector size in disk label
On Mon, 22 Jul 2013, Kenneth R Westerback wrote: On Mon, Jul 22, 2013 at 01:56:16PM +0200, David Vasek wrote: Hello. From the experiment below it seems that the kernel modifies its knowledge of a sector size of a disk hardware according to what can be found in the disk label sector. It does so even if the value found does not make sense hardware-wise and in spite of a sector size the hardware device driver works with. It can make the device completly inaccessible. The disklabel(8) command doesn't allow to set/change the sector size value even if it were accessible. The kernel obtains the sector size from the hardware device whenever the disklabel is created. It does trust the disklabel it reads from the disk. People can abuse that trust. The interesting gyrations to automatically convert all the fields in the disklabel from one sector size to another are, well, *interesting*. And have never been considered useful since there is no general mechanisms for the kernel to read incorrectly blocked data from the disk. Well, it trusts the disk label in what it says the sector size is, but on the other hand it ignores what the disklabel says about the total number of sectors (and the size of the 'c' partition). Strange. Such situation also occurs if the disk label is read from a sector where a disk label is not expected - this was already a subject of my previous report. Still working on puzzling out that report. Don't hesitate to ask if anything is not clear in that report. It effectively means that if there is wrong data on the drive, you don't have a chance to analyze the situation or fix it. You can't even view the fdisk (MBR) partition table. Correct. One would hope there is a chance to edit (fix) the sector size value with disklabel(8). But obviously, once it has been changed, the disk label cannot be written to disk again. Bits directly plopped from a device with one sector size to another device with a different sector size all pass through a gate having a large sign over it containing the words: "Lasciate ogne speranza, voi ch'intrate". In some cases disks can be connected to computers in more than on way and in each way its host will be presented with a different sector size. I made an attemt to simulate it. I just didn't expect it could silently influence hardware drivers. My guess is that this issue could be related to this one about a year ago: http://marc.info/?l=openbsd-misc&m=134027998905971&w=2 Nope. That problem had to do with wd(4) not supporting 4K sectors. Only sd(4) will even make an attempt to handle sector sizes other than 512 bytes. I don't think so. If I see the number of sector the drive reported both when inside an USB enclosure and connected directly to SATA controller, I believe that it was a standard 512-byte sector SATA hard drive and only the kernel got fooled by the disk label it found on it. In fact, that was the real life situation I wanted to model in my experiments - what will happen if the disk is taken out from a USB enclosure which pretends it to be a 4k-sector drive and is connected to a SATA controller as a standard 512-byte/sector drive. Regards, David
4k-sector: wrong sector size in disk label
Hello. From the experiment below it seems that the kernel modifies its knowledge of a sector size of a disk hardware according to what can be found in the disk label sector. It does so even if the value found does not make sense hardware-wise and in spite of a sector size the hardware device driver works with. It can make the device completly inaccessible. The disklabel(8) command doesn't allow to set/change the sector size value even if it were accessible. Such situation also occurs if the disk label is read from a sector where a disk label is not expected - this was already a subject of my previous report. It effectively means that if there is wrong data on the drive, you don't have a chance to analyze the situation or fix it. You can't even view the fdisk (MBR) partition table. In the following example I copied an image of a 512-byte sector USB drive (sd5) to a clean 4k-sector USB drive (sd4). The source drive contained an OpenBSD fdisk partition with a disklabel partition and a functional filesystem. After that, kernel can't read any data from that 4k-sector drive, causing errors at umass(4) driver level. Please note the output of "disklabel sd4" before and after copying the image and the difference in sector size there. My guess is that this issue could be related to this one about a year ago: http://marc.info/?l=openbsd-misc&m=134027998905971&w=2 Regards, David Connected OpenBSD/i386 BOOT 3.21 boot> kernel/i386/bsd.rd booting hd0a:kernel/i386/bsd.rd: /-\|/-\|/6043500-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+433856 [52+235056\|/-\|/-\|/-\|/+223307-\|/-\|/-\|/-]=0x69d650 entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.4 (RAMDISK_CD) #28: Sun Jul 21 19:26:53 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF real mem = 526839808 (502MB) avail mem = 510959616 (487MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/24/08, BIOS32 rev. 0 @ 0xfa080, SMBIOS rev. 2.4 @ 0xf (34 entries) bios0: vendor Phoenix Technologies, LTD version "MS7336 1.14" date 11/24/2008 bios0: Hewlett-Packard HP Compaq dx2300 Microtower acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET MCFG APIC SSDT SSDT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 199MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 2 (HUB0) bios0: ROM list: 0xc/0xb000! 0xcc000/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82946GZ Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82946GZ PCIE" rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 "Intel 82946GZ Video" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 82801GB HD Audio" rev 0x01 at pci0 dev 27 function 0 not configured uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 4 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 4 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 4 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 4 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 pci2 at ppb1 bus 2 fxp0 at pci2 dev 8 function 0 "Intel 8
Re: 4k-sector NTFS can't be mounted
On Sun, 21 Jul 2013, Kenneth R Westerback wrote: A 4k-sector NTFS filesystem can't be mounted as of 5.3/i386. At least one person is using a 4K-sector disk with NTFS partition(s) without problems. So I suspect something local to your setup is causing the problem by traversing new and exciting code paths. The filesystem was on external USB hard drive, as it came from the manufacturer, which is HGST, formerly Hitachi GST, now part of WD. The filesystem didn't work with OpenBSD 5.3/i386, but Windows XP seemed happy with it. The filesystem was empty and from original 4 TB it could be compressed with bzip2 to under 3 MB. I can send the compressed image to you if you want to play with it and have extra disk space. Regards, David
4k-sector NTFS can't be mounted
Hello, I guess this one is something expected. A 4k-sector NTFS filesystem can't be mounted as of 5.3/i386. OTOH, it works with Windows XP. Can't say if it is a bug since there is no public NTFS specifications. But Windows people are using such filesystems. Regards, David dmesg: -- umass2 at uhub0 port 5 configuration 1 interface 0 "HGST Touro Desk 3.0" rev 2.10/0.00 addr 4 umass2: using SCSI over Bulk-Only scsibus5 at umass2: 2 targets, initiator 0 sd5 at scsibus5 targ 1 lun 0: SCSI4 0/direct fixed serial.49711015110B1677 sd5: 3815446MB, 4096 bytes/sector, 976754431 sectors fdisk: -- Disk: sd5 geometry: 60800/255/63 [976754431 4096-byte Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 07 0 1 1 - 60799 254 63 [ 63: 976751937 ] NTFS 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused disklabel: -- # /dev/rsd5c: type: SCSI disk: SCSI disk label: HGST duid: flags: bytes/sector: 4096 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60800 total sectors: 976754431 boundstart: 0 boundend: 976754431 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c:9767544310 unused i:976751937 63NTFS
Re: 4k-sector drives
Hello again. disklabel(8) writes its label sector outside of A6 partition, possibly into other partitions and overwrites data there. Looks like 512-byte sectors are silently expected somewhere here, but I didn't check the code. In the example below the label sector has been written to offset 1000 (4096-bytes sectors, byte 0x3e8200) and overwrote data in fdisk partition 0 (see the hexdump output below). The offset in bytes from the beginning of the disk is the same as would be if 512-byte sectors were used instead of 4k-sectors. Filesystem /dev/sd4a starts where fdisk(8) and disklabel(8) say, at sector 8000 (4096-bytes sectors), which is visible from the hexdump. Label sector is definitly not expected where it is written to. From disklabel(5): The label is located in sector number LABELSECTOR of the drive, usually sector 0 where it may be found without any information about the disk geometry. It is at an offset LABELOFFSET from the beginning of the sector, to allow room for the initial bootstrap. Also note wrong number of used sectors newfs(8) reported in this example: "100.0MB in 204800 sectors of 4096 bytes". The number would be correct if the sectors were 512-bytes in size. I'm not usually using mixture of OS's on a system or even a drive, but there are people who do and this can bite them. Also don't forget service partitions and so on. (fxp0 MAC number and sd4 serial were modified.) OpenBSD/i386 BOOT 3.21 boot> bsd.rd booting hd0a:kernel/i386/bsd.rd: /-\|/-\|/6043500-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-+433856 [52+235056\|/-\|/-\|/-\|/+223307-\|/-\|/-\|/-]=0x69d650 entry point at 0x200120 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.4 (RAMDISK_CD) #25: Wed Jul 17 10:11:20 MDT 2013 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz ("GenuineIntel" 686-class) 1.80 GHz 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,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF real mem = 526839808 (502MB) avail mem = 510959616 (487MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/24/08, BIOS32 rev. 0 @ 0xfa080, SMBIOS rev. 2.4 @ 0xf (34 entries) bios0: vendor Phoenix Technologies, LTD version "MS7336 1.14" date 11/24/2008 bios0: Hewlett-Packard HP Compaq dx2300 Microtower acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC HPET MCFG APIC SSDT SSDT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 199MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 2 (HUB0) bios0: ROM list: 0xc/0xb000! 0xcc000/0x1800 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82946GZ Host" rev 0x02 ppb0 at pci0 dev 1 function 0 "Intel 82946GZ PCIE" rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 "Intel 82946GZ Video" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 82801GB HD Audio" rev 0x01 at pci0 dev 27 function 0 not configured uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 4 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 4 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 4 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 4 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 4 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 pci2 at ppb1 bus 2 fxp0 at pci2 dev 8 function 0 "Inte
Re: 4k-sector drives
On Sun, 21 Jul 2013, Theo de Raadt wrote: are disks with logical sector sizes other than 512-bytes supported? I can get basic functionality with a 4k-sector drive, still there are some flaws. Does it make sense to report these bugs now, or is it too early? Thanks for your very detailed question. Detailed answer follows: Detailed question once again: Does it makes sense to report bugs concerning disks with other sector sizes then 512 bytes now? Explanation: I met quite a few flaws when working with 4k-sector drives. I am not sure if such drives are supported. If they are not supported yet and that what works with these drives it works just by pure luck then it would be a waste of developers' time and bandwith to report such shortcomings. If the OS needs a complex work on non-512-bytes sector sizes a everybody knows it, then reporting those bugs (which in fact would not be bugs, becasue there is no "bug of unsupported feature") would not help anybody. Simply put: shall I send any reports concerning 4k-sectors on -cuurent? Thank you. Regards, David
4k-sector drives
Hello misc@, are disks with logical sector sizes other than 512-bytes supported? I can get basic functionality with a 4k-sector drive, still there are some flaws. Does it make sense to report these bugs now, or is it too early? Regards, David
Re: My OpenBSD 5.0 installation experience (long rant)
On Wed, 7 Mar 2012, Amit Kulkarni wrote: On Wed, Mar 7, 2012 at 11:19 AM, David Vasek wrote: On Wed, 7 Mar 2012, Donald Allen wrote: "While the FAQ is indeed clear, the installer's simplicity appears at that point a little deceptive, in that one (I know I was) is tempted to think that such a user-friendly installer would not harm one so easily..." I disagree. I think the installer is fine the way it is and it was not the problem here. The problem was the original poster's too-cavalier approach to something that is well-known to be dangerous. What happened here is somewhat analogous to texting while driving or flying an airplane drunk and, when disaster occurs, being upset (assuming survival) that the equipment didn't prevent it. Except that the equipment shoudn't direct people to behave in such a disasterous way. And this the case. Regards, David what about this Use (W)hole disk or (E)dit the MBR? [edit] while the OP did make a mistake, he could modify the default to be edit the MBR. so he would be forced to pay attention while staring at the partition table. i would be paying attention to the instructions. stuart is right, there's a point where if you add confirmations, where would you stop? Not confirmations, but saner defaults. No default value here is another option - it doesn't take from precious floppy size. I never had a problem with the current installer, but I really do think that is should not direct people to disasters. Yes, people should be careful, but only one press of Enter is too close. Defaults should be sane. Regards, David
Re: My OpenBSD 5.0 installation experience (long rant)
On Wed, 7 Mar 2012, Donald Allen wrote: "While the FAQ is indeed clear, the installer's simplicity appears at that point a little deceptive, in that one (I know I was) is tempted to think that such a user-friendly installer would not harm one so easily..." I disagree. I think the installer is fine the way it is and it was not the problem here. The problem was the original poster's too-cavalier approach to something that is well-known to be dangerous. What happened here is somewhat analogous to texting while driving or flying an airplane drunk and, when disaster occurs, being upset (assuming survival) that the equipment didn't prevent it. Except that the equipment shoudn't direct people to behave in such a disasterous way. And this the case. Regards, David
Re: Is fdisk partition a must for a non-system disk on i386
On Thu, 16 Feb 2012, Stuart Henderson wrote: On 2012-02-15, David Vasek wrote: In contrast, Marco, as the author of softraid(4), says the opposite about use of fdisk, even on the physical disks. And what he says is more recent than the example in the softraid(4) man page. http://marc.info/?l=openbsd-misc&m=128847054226289&w=2 My thought is that MBR partition (DOS partition) is only needed for compatibility with other OS's in case they come in touch with the disk. And probability of such encounter in case of softraid disks and vnd's is... quite low at best. Not certain but isn't the fdisk partition needed in order that you can boot from them? (Bootable softraid appeared after that post, of course). Don't know and can't check it currently. But wouldn't it be better if all OpenBSD platforms are consistent except the situations where a difference from the rest is enforced by the platform as such? Regards, David
Re: Is fdisk partition a must for a non-system disk on i386
On Wed, 15 Feb 2012, Nick Holland wrote: On 02/15/12 03:23, David Vasek wrote: On Tue, 7 Feb 2012, Nick Holland wrote: Just put the fdisk partition in place on every disk you want to use on an i386/amd64 and all other fdisk platforms. There are no good reasons not to, there are a lot of good reasons to do so. All the tools assume this is how the system is laid out...they are not tested otherwise. ... Do softraid disks and vnd's count as disks here too? Thanks. Regards, David the softraid(4) man page says so, so guess what my answer is? :) What's the issue with doing things as advised? What is the goal? Bragging rights? "look what I got away with!"? Not worth it. [note: there is some question if this is desired in non-fdisk platforms, but that's not the OP's question...and the man page still says use it] The man page does not say anything about fdisk, it only appears in the example. Not everything that appears in examples is advisable to follow. In contrast, Marco, as the author of softraid(4), says the opposite about use of fdisk, even on the physical disks. And what he says is more recent than the example in the softraid(4) man page. http://marc.info/?l=openbsd-misc&m=128847054226289&w=2 My thought is that MBR partition (DOS partition) is only needed for compatibility with other OS's in case they come in touch with the disk. And probability of such encounter in case of softraid disks and vnd's is... quite low at best. Regards, David
Re: Is fdisk partition a must for a non-system disk on i386
On Tue, 7 Feb 2012, Nick Holland wrote: Just put the fdisk partition in place on every disk you want to use on an i386/amd64 and all other fdisk platforms. There are no good reasons not to, there are a lot of good reasons to do so. All the tools assume this is how the system is laid out...they are not tested otherwise. ... Do softraid disks and vnd's count as disks here too? Thanks. Regards, David
Re: How to add new non-continuous A6 partition after install
On Mon, 23 Jan 2012, Marc Espie wrote: On Mon, Jan 23, 2012 at 05:26:33AM +, lbvvbooo lbvvbooo wrote: For kinds of reasons, my disk is partitionized like this: 1st partition is for Windows system(Primary) 2nd is for OpenBSD(Primary) 3rd is Windows extended partition(Extended) 4th is originally not used, now I created a new one and mark it as "A6".(Primary) Question is after I created the 4th partition, I can get the partition information using fdisk, but can't see anything using disklabel. How do I use the 4th partition? Will it be helpful if I just reformat it to fat32 or ext3? I used to ask this question before, as far as I know, it's not a support config in bsd 4.5. Is bsd 5.0 support this now? ??? it has worked in OpenBSD for a very long time, possibly forever, though I recall using it in 3.3. You should read disklabel documentation more closely. Pay particular attention to the b (set OpenBSD disk boundaries) command. I agree, I had been using something similar with older releases too. Still I don't think everything works with more than one A6 parition. It didn't work for me. Putting single FFS file system directly in the other fdisk partition works, but there is no standard fdisk partition ID for such a partition. To avoid many risks, I solved it by some undefined partition ID. Is there any recommended ID to use for the "FFS partition"? Regards, David
Re: ufs journal ?
On Tue, 27 Dec 2011, Otto Moerbeek wrote: There are several way to speedup fsck which are available now: - Use larger block and fragment sizes when doing a newfs, of course this requires rebuilding the file system - Recent versions of OpenBSd have some improvements with fsck that kick in when the file systems was using softupdates when the system crashed. - Use a smaller file system Hello Otto, is use of lower inode density while keeping the rest as default possible alternative or not? It seems to work. Does it have any adverse effect? Provided one doesn't have several-TB file system full of hundreds millions tiny files, of course, but then it is not any better than larger blocks and fragments. And both solutions reduce memory needed for fsck. Thanks for your answer. Regards, David
Re: Upgrading AMD64 4.9-stable to 5.0
On Mon, 19 Dec 2011, Christiano F. Haesbaert wrote: On 19 December 2011 16:20, Richard Thornton wrote: Do a simple clean 5.0 install. One would assume any browser package in the packages folder would install. None do for me on sparc, but with a clean 4.9 install all 4.9 packages install. I am not a Unix specialist by any means but I do know how to type pkg_add . So stop spreading lies and read the documentation before taxing things as "toy". With most toys children are not expected to read documentation, you know. Regards, David
Re: Copy root partition to another machine
On Sun, 6 Nov 2011, Benny Lofgren wrote: On 2011-11-06 18.00, Bambero wrote: Thanks, but without skip=1 dd will copy partition table and mbr too (first block 521b). So it may damage my partition table on second machine. I'm I wrong ? No, you will not copy the partition table with your command, since you are using wd0a. That partition starts after the boot sector(s) and partition table, so what you're in fact doing is skipping the first blocks of the file system that is on partition a of wd0. Which you don't want to do. (If you had used wd0c on the other hand, you would have gotten the disk partition metadata as well. But you don't want that either.) By the way, seek= and skip= gets multiplied by whatever block size you set (in your case, 16b == 16 x 512 == 8 Kb) so you're not even skipping the first sector which you think but the first 16 sectors. Also, don't use the block device when doing this, use the raw (character) device. And, and I hope this goes without saying, DON'T DO THIS ON A MOUNTED DEVICE. So, skip the skip. Just do the following: On the source machine: Boot from something other than your root disk, or boot into single user mode and remount root read-only. Then: dd if=/dev/rwd0a of=/tmp/root.img bs=16m On the target machine, booted from some install media: dd if=/your/tmp/drive/root.img of=/dev/rwd0a bs=16m Benny, with this you will overwrite the disklabel of whole target disk, as the disklabel in a typical case indeed resides at the beginning of the wd0a. See disklabel(5). Regards, David
Re: kernel panic on openbsd i386 snapshot 20111103
On Sat, 5 Nov 2011, Norman Golisz wrote: On Sat Nov 5 2011 09:13, Forman, Jeffrey wrote: Am I barking up the wrong tree trying to deduce if I really do have a hardware problem? I am open to accepting diffs and compiling from source if other developers think there might be a bug to fix here. It seems to be a hardware fault. To trap memory issues, you could try memtest86+ [1]. [1] http://www.memtest.org/ Or ports/sysutils/memtest86+, which is the same and as a package it is easier to deal with - it can be loaded by boot(8) directly from /stand on your root filesystem. No CDs, floppies etc. are needed. As a sidenote, memtest (www.memtest.org) an memtest86+ (www.memtest86.com) are not exactly the same. Regards, David
Re: Laptop hard drive and emergency unload
On Sun, 4 Sep 2011, Benny Lofgren wrote: On 2011-09-04 07.39, David Vasek wrote: No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. That used to be true in the dark ages, when disk drives were as large as washing machines and the actual disk packs were removable and 14" in diameter. But in this day and age, what Marco says is entirely correct. No. What Marco says was correct in 90's and early 2000's when disks employed CSS (Contact Start-Stop) mechanism. In recent years all laptop drives and almost all desktop and "server" drives (with exception of some lower end Seagates) use parking on a ramp. This is the docs for the drive Steve (the OP) has in his Acer laptop. Please look at the chapter 6.3 (pages 29, 30). http://www.hgst.com/tech/techlib.nsf/techdocs/1F70FDFFB4DE1EBB86257538007E4CFE/$file/TS5K500.B_OEM_Specification_R18.pdf The same is true for other modern Hitachi drives and for drives from other vendors probably too, but they do not provide any useful documentation for their drives. There is some more detailed description of ramp parking: http://www.hgst.com/tech/techlib.nsf/techdocs/9076679E3EE4003E86256FAB005825FB/$file/LoadUnload_white_paper_FINAL.pdf Regards, David The OP can safely ignore this from a disk durability standpoint, although it may of course be a nuisance that the disk doesn't power down when shutting down OpenBSD (if that's indeed what happens, I'm not sure I fully understood the description). Also, "emergency retract" is a misnomer, the SMART attribute in quesetion is actually called "Power-off Retract Count". Only Fujitsu (to my knowledge) for some reason calles it Emergency Retract Cycle Count. In any case it's a bullshit value to base any reliability predictions on, unless maybe, MAYBE if it runs into the tens or hundreds of thousands. Regards, /Benny On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an "emergency unload" according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 "Power-off Retract" events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller
Re: Laptop hard drive and emergency unload
No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. Regards, David On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an "emergency unload" according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 "Power-off Retract" events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller
Re: 'real mem' in dmesg much lower than expected?
On Sat, 20 Aug 2011, Dave Anderson wrote: Thanks to all who've replied. It seems kind of disgusting that a modern video card can grab 1/4 of the available physical address space on i386, but I suppose that pretty much everyone with such a card is running amd64 instead. If you want to feel disgusted even more: some popular and frequently used chipsets for amd64 CPU's, such as Intel 82945GM, address memory with 32 bits only. With such a chipset you suffer similar limitation with amd64 as you would with i386 (available RAM minus devices' address space minus shared video memory etc.). But these chipsets are not produced anymore, I hope. Regards, David
Re: Load average question
On Mon, 8 Aug 2011, Rikky Taylor wrote: I am a little puzzled by how openbsd calculated load avaerage. I have a server running 4.9 i386 that should be doing very little indeed yet has a consistent load average of 0.6-0.9 Other similar servers have consisten load averages of 0.05-0.1 when i do a "ps aux" it shows a small number of processes using 0.0 CPU and very little memory. Where is the "load" coming from? I am not sure where to look. There are also kernel processes which some other OS's do not include in load average calculation. It's a different quantity. For more detailed explanation read the article below or try to search a mailing list archive. http://www.undeadly.org/cgi?action=article&sid=20090715034920&mode=expanded Nick, this is probably the single most frequently asked question... :-) Regards, David
Re: installing OpenBSD 4.9 to external USB harddisk: Disk does not boot
On Mon, 8 Aug 2011, David Vasek wrote: On Sun, 7 Aug 2011, Ted Unangst wrote: On Mon, Aug 08, 2011, Michael Treibton wrote: is there a cleverer way of doing this? i just do not have the infrastructure here to attempt a serial capture, despite the well-documented instructions in the OBSD docs. i can get the output you want, although because the installer doesn't have scp or anything, i have no means of copying these files. is there another means at my disposal to get these files off? You booted the installer somehow, right? Boot from that disk to the boot> prompt, then boot hd1:/bsd or hd0:/bsd or something as appropriate. If you can boot from the install CD, try at the bootloader prompt: boot> boot /4.9/i386/bsd -a -s replace i386 with amd64 and bsd with bsd.rd if needed Ooops, I meant bsd.mp, of course. But SP kernel should be enough anyway. Regards, David
Re: installing OpenBSD 4.9 to external USB harddisk: Disk does not boot
On Sun, 7 Aug 2011, Ted Unangst wrote: On Mon, Aug 08, 2011, Michael Treibton wrote: is there a cleverer way of doing this? i just do not have the infrastructure here to attempt a serial capture, despite the well-documented instructions in the OBSD docs. i can get the output you want, although because the installer doesn't have scp or anything, i have no means of copying these files. is there another means at my disposal to get these files off? You booted the installer somehow, right? Boot from that disk to the boot> prompt, then boot hd1:/bsd or hd0:/bsd or something as appropriate. If you can boot from the install CD, try at the bootloader prompt: boot> boot /4.9/i386/bsd -a -s replace i386 with amd64 and bsd with bsd.rd if needed (there is no BIOS on other platforms, isn't it?), watch what your external drive is (possibly sd0), and enter your root and swap partitions (sd0a and sd0b in that case). After you verify that your disk as recognised by the kernel match your /etc/fstab, you can exit the single user shell and even go multiuser. Then you will have anything you need for report, diagnostics and possibly for repair too. Regards, David
Re: installing OpenBSD 4.9 to external USB harddisk: Disk does not boot
On Mon, 8 Aug 2011, Michael Treibton wrote: is there a cleverer way of doing this? i just do not have the infrastructure here to attempt a serial capture, despite the well-documented instructions in the OBSD docs. i can get the output you want, although because the installer doesn't have scp or anything, i have no means of copying these files. is there another means at my disposal to get these files off? Mount a USB flash drive, a floppy, even an internal drive partition with FAT or EXT2/3 filesystem there and copy the files. Regards, David
Re: installing OpenBSD 4.9 to external USB harddisk: Disk does not boot
On Sun, 7 Aug 2011, Michael Treibton wrote: If there's a means of providing more information to help with this, please say. I guess the devs would like to see the output from OpenBSD fdisk(8) and disklabel(8), rather than from Linux. You can obtain those by selecting the (S)hell in the install program and using the commands above. The key part probably is what, if anything, is being displayed by the bootloader before the BIOS boots from the internal disk and in what state was the disk and the MBR table prior the install. Regards, David
Re: hibernation with APM
Hi Marco. Thanks, but I'm not asking about suspend. apmd -z starts suspend, at least with my Thinkpad and Compaq, both with Phoenix APM BIOSes. Hibernation is sometimes called "save to disk" suspend, while suspend is then called "save to RAM" suspend. Regards, David On Sat, 6 Aug 2011, Marco Peereboom wrote: run apmd at startup then type apm -z to initiate it. Works like a charm on most laptops of quality. On Sun, Aug 07, 2011 at 12:54:22AM +0200, David Vasek wrote: Hello all, does anybody please know if there is a way to initiate hibernation on APM equipped laptops that support it *from software*? Thanks for answers. Regards, David
hibernation with APM
Hello all, does anybody please know if there is a way to initiate hibernation on APM equipped laptops that support it *from software*? Thanks for answers. Regards, David
Re: Building kernel outside /usr/src/sys -- from the FAQ
On Fri, 29 Jul 2011, Gilles Chehade wrote: On Fri, Jul 29, 2011 at 10:43:52AM +0200, David Vasek wrote: On Fri, 29 Jul 2011, Amarendra Godbole wrote: Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section "Variation on above process: Read-only source tree", which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean && make depend && make # make install "config -e" displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a "dmesg" is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. It loses the arch too. It is not easy to distinguish between i386 and amd64 then. Regards, David can't you actually do: # mkdir -p /home/foo/bar/testbuild/`uname -m`/GENERIC.MP # cd /home/foo/bar/testbuild/`uname -m`/GENERIC.MP which would keep the arch and kernel name in the build path just as with a build from the "regular" path ? It is what I actually do. I am not complaining. But it is sometimes hard to read dmesgs that come to misc@ from other people right. Regards, David
Re: Building kernel outside /usr/src/sys -- from the FAQ
On Fri, 29 Jul 2011, Amarendra Godbole wrote: Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section "Variation on above process: Read-only source tree", which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean && make depend && make # make install "config -e" displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a "dmesg" is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. It loses the arch too. It is not easy to distinguish between i386 and amd64 then. Regards, David
Re: PC for assembly learning purposes
Again, I am not the right to answer, but try to guess it yourself. It is a different architecture, but... http://www.openbsd.org/pegasos.html Regards, David On Sun, 24 Jul 2011, Tomas Vavrys wrote: > This looks also promising... http://www.genesi-usa.com/products > Are there any plans to support this architecture? > > 2011/7/24 David Vasek : >> Hi! >> >> I am not the right person to answer this and don't want to spread any >> nonsense. There are others here who are. >> >> What I can say is, any m68k CPU in its era was much much saner than any >> member of the x86 family. Today, I would rather look for more sanity at >> sparc64 (which survives in rather small niche market) or alpha (which has >> been violently murdered). But hey, I don't have assembler level experience >> with neither of these two. >> >> Nonetheless, as I said earlier, I would focus on the platform which is the >> target of my development efforts. >> >> Regards, >> David >> >> >> On Sun, 24 Jul 2011, Billy wrote: >> >>> David, >>> >>> If "learning a sane and proper computer architecture" is the perpose, what >>> system do you recommend from the list of platform that OBSD supports? >>> >>> thanks and regards, >>> >>> bill >>> >>> David Vasek )s 2011&~7$k24$i $U$H7:52 >> >>>> On Sun, 24 Jul 2011, Tomas Vavrys wrote: >>>> >>>>> This device will be used only for my learning purposes. I would like >>>>> to jump on C and compilers later. Is it better to start with RISC or >>>>> CISC? Should I buy rather x86? >>>> >>>> Buy the platfrom you want to learn. x86 architecture is full of its >>>> design issues and is quite different from others, but if you want to >>>> develop >>>> for x86, then it does not make sense to learn anything else instead of it. >>>> >>>> Regards, >>>> David
Re: PC for assembly learning purposes
Hi! I am not the right person to answer this and don't want to spread any nonsense. There are others here who are. What I can say is, any m68k CPU in its era was much much saner than any member of the x86 family. Today, I would rather look for more sanity at sparc64 (which survives in rather small niche market) or alpha (which has been violently murdered). But hey, I don't have assembler level experience with neither of these two. Nonetheless, as I said earlier, I would focus on the platform which is the target of my development efforts. Regards, David On Sun, 24 Jul 2011, Billy wrote: > David, > > If "learning a sane and proper computer architecture" is the perpose, > what system do you recommend from the list of platform that OBSD > supports? > > thanks and regards, > > bill > > David Vasek )s 2011&~7$k24$i $U$H7:52 >> On Sun, 24 Jul 2011, Tomas Vavrys wrote: >> >>> This device will be used only for my learning purposes. I would like >>> to jump on C and compilers later. Is it better to start with RISC or >>> CISC? Should I buy rather x86? >> >> Buy the platfrom you want to learn. x86 architecture is full of its >> design issues and is quite different from others, but if you want to >> develop for x86, then it does not make sense to learn anything else >> instead of it. >> >> Regards, >> David
Re: PC for assembly learning purposes
On Sun, 24 Jul 2011, Tomas Vavrys wrote: This device will be used only for my learning purposes. I would like to jump on C and compilers later. Is it better to start with RISC or CISC? Should I buy rather x86? Buy the platfrom you want to learn. x86 architecture is full of its design issues and is quite different from others, but if you want to develop for x86, then it does not make sense to learn anything else instead of it. Regards, David
Re: Absurdly high temperature reading - system shutdown
On Thu, 16 Jun 2011, Michal Mazurek wrote: After moving my old laptop around I got home, booted it and got a very distressing message: messages.2.gz:Jun 14 22:40:09 hopek /bsd: acpitz2: Critical temperature 4938C (52112K), shutting down Shouldn't the sc_tmp, sc_crt and other variables be divided by 10 before being displayed as Kelvins? Even if the OS runs on Sun hardware. ;-) Regards, David
Re: How do I exclude a directory using tar in OpenBSD?
On Thu, 2 Jun 2011, Nico Kadel-Garcia wrote: GNU tools have become the industry standard, for a stack of reasons. I've had similar issues with the "cp" command, and its lack of "cp -a". I've had similar issues with pax(1) command missing from systems based on "GNU industry standard", and their lack of "pax -rw". But why should one care about POSIX if we can choose to follow that great "GNU industry standard" now. Regards, David
Re: putty or ssh, screen $cmd
On Sat, 28 May 2011, gilbert.fernan...@orange.fr wrote: If you try screen on some machines, you will crash so badly that even DDB inside the kernel is frozen after displaying one or two lines of panic. At first, you wonder. Then you try tmux, and it no longer crashes. Never blame an application for OS crashes, btw. Regards, David
Re: Things to do with a Pentium 166MHz cpu - 32 MB of RAM - 1.5 GB disk
On Wed, 18 May 2011, David Coppa wrote: On Wed, May 18, 2011 at 12:16 PM, David Vasek wrote: On Sun, 15 May 2011, Nick Holland wrote: What dissapoints me the most, is that there don't exist USB ports and they might not even be supported, the pc is from 1998. I could use rtorrent with screen to download stuff to an external hard drive.. But I will check on that when I find the time to open the case. Regarding USB ports -- if you find an old USB 1.0 card laying around, I bet it would work fine. USB2.0 cards...you might find the card expects a newer version of the PCI bus than your machine has...but you may get lucky or I may be completely wrong. :) You are right. Some PCI USB 2.0 controller cards work pretty well in my 486 and Pentium machines. Other do not. If it works, the transfer speed are lower than in newer systems because of slower CPU. Hi, What vendor and product IDs those cards have? Can I have the dmesg snippet? Some others could be interested in this too, so I am posting it on the list. It is a Belkin F5U219 PCI REV:4, the chip is NEC JAPAN D720101GJ. NEC USB host controllers usually work. It is a 3-port card (2+1 internal), there is also a 5-port (4+1) variant existing. The important part about its specs is: it is PCI 2.1 compatible, while many others list only PCI 2.2. In my experience, most common cheap USB 2.0 PCI cards do not work as USB 2.0, but run well as USB 1.1. You have to disable the ehci(4) driver in the kernel, otherwise the USB 2.0 device attaches to ehci* and fails. See the VIA VT6212L as an example below. Belkin F5U219 PCI REV:4 / NEC USB = OpenBSD 4.9-current (GENERIC) #75: Mon May 16 11:43:42 MDT 2011 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium (P54C) ("GenuineIntel" 586-class) 100 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8 real mem = 33091584 (31MB) avail mem = 22515712 (21MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/17/96, BIOS32 rev. 0 @ 0xf6bd1 pcibios0 at bios0: rev 2.1 @ 0xf6b30/0xa20 pcibios0: PCI BIOS has 5 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 11 pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371SB ISA" rev 0x00) pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 cpu0 at mainbus0: (uniprocessor) cpu0: F00F bug workaround installed pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82439HX" rev 0x03 vendor "Siemens", unknown product 0x0005 (class undefined unknown subclass 0x00, rev 0x01) at pci0 dev 3 function 0 not configured vendor "Siemens", unknown product 0x0005 (class undefined unknown subclass 0x00, rev 0x01) at pci0 dev 3 function 1 not configured pcib0 at pci0 dev 7 function 0 "Intel 82371SB ISA" rev 0x01 pciide0 at pci0 dev 7 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 1549MB, 3173184 sectors wd0(pciide0:0:0): using PIO mode 4, 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, DMA mode 2 vga1 at pci0 dev 8 function 0 "Cirrus Logic CL-GD5436" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xl0 at pci0 dev 18 function 0 "3Com 3c905B 10/100Mbps-Combo" rev 0x00: irq 9, address 00:01:02:a2:9a:09 exphy0 at xl0 phy 24: 3Com internal media interface ohci0 at pci0 dev 19 function 0 "NEC USB" rev 0x43: irq 9, version 1.0, legacy support ohci1 at pci0 dev 19 function 1 "NEC USB" rev 0x43: irq 11, version 1.0, legacy support ehci0 at pci0 dev 19 function 2 "NEC USB" rev 0x04: irq 9 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo 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 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 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 0x203 com3 at isapnp0 "Rockwell 56K Plug & Play Modem, GVC0330, , " port 0x3e8/8 irq 5: ns16550a, 16 byte fifo com3: probed fifo depth: 0 bytes sb1 at isapnp0 "Creative ViBRA16C PnP, CTL0001, , Audio" port 0x220/16,0x330/2,0x388/4 irq 5 drq 1,5: dsp v4.13 midi0 at sb1: audio0 at sb1 opl at sb1 no
Re: Things to do with a Pentium 166MHz cpu - 32 MB of RAM - 1.5 GB disk
On Sun, 15 May 2011, Nick Holland wrote: What dissapoints me the most, is that there don't exist USB ports and they might not even be supported, the pc is from 1998. I could use rtorrent with screen to download stuff to an external hard drive.. But I will check on that when I find the time to open the case. Regarding USB ports -- if you find an old USB 1.0 card laying around, I bet it would work fine. USB2.0 cards...you might find the card expects a newer version of the PCI bus than your machine has...but you may get lucky or I may be completely wrong. :) You are right. Some PCI USB 2.0 controller cards work pretty well in my 486 and Pentium machines. Other do not. If it works, the transfer speed are lower than in newer systems because of slower CPU. Regards, David
Re: uaudio
On Sun, 8 May 2011, Jan Stary wrote: Is it OK for an uaudio(4) device to have 0 mixer controls? I can control the respective inputs/outputs with the device's (hardware) knobs, but having 0 (software) mixerctl variables still seems a bit strange. Is it possible that the device really has 0 controls to expose via USB audio (and uaudio just correctly reports that), or is this a sign that the dovice is not fully supported (or possibly not class-compliant)? Accidentaly, I am recording at this very moment from a firewire audio interface (using another OS) and the device does not provide any mixer controls in software. Only the hardware buttons on the box. This fact is confirmed by the docs of the device. So, I would not be surprised that this is possible with USB audio devices too. Regards, David
Re: dmesg for notebooks useful?
On Thu, 28 Apr 2011, Jonathan Gray wrote: Yes, this would help. Though a bunch of things affecting recent laptops have gone in during the last few weeks so you should update to a newer snapshot if possible. Btw, is the dmesg enough as a general survey, or is the sendbug(1) output more desired by the devs? Regards, David On Wed, Apr 27, 2011 at 11:25:20AM -0400, Dave Anderson wrote: I'm working on buying a notebook which will run OpenBSD, and have been grabbing the dmesg from whatever I find in stores to look at hardware compatibility (I've got a 4.9-current snapshot from 2011/4/13 on a USB stick which I boot on them). Would it be useful to also send what I collect to dm...@openbsd.org? Dave -- Dave Anderson
Re: vnconfig wd1 disklabel dissapearing
On Tue, 19 Apr 2011, Kevin Chadwick wrote: On Tue, 19 Apr 2011 10:18:20 + Kevin Chadwick wrote: /sbin/disklabel -E wd1 /sbin/vnconfig -ck svnd0 /dev/wd1a /sbin/disklabel -E svnd0 /sbin/newfs /dev/rsvnd0a /sbin/newfs /dev/rsvnd0d /sbin/disklabel -E wd0 /sbin/vnconfig -ck svnd1 /dev/wd0l /sbin/disklabel -E svnd1 /sbin/newfs /dev/rsvnd1a reboot, I guess disklabel -c would do the same wd0l and svnd1 work fine (disklabels visible and work fine) I have to recreate the disklabel for wd1 and svnd0 after which it works fine untill the next reboot (data accessed). Anyone got even a hunch why wd1a and wd0l as used above behave repeatably differently. The disklabel of the disk is located at the very beginning of the disk (or at the beginning of an fdisk partition on some archs), that means at the beginning of the physically first partition. This partition usually is the 'a' partition. If you overwrite the beginning of the first partition, you overwrite the disklabel. On the other hand, if you overwrite disklabel area of any of the following partitions (structured as FFS), like wd0l, you usually cause no harm. It is not used there. As for svnd, if I remeber it right, you should not use a partition for svnd, but a file instead. But don't know why it is necessary. Regards, David
Re: top man page, clarification of interactive command 1
On Thu, 24 Mar 2011, Jason McIntyre wrote: On Thu, Mar 24, 2011 at 06:02:15PM +, Glen Anderson wrote: I liked the idea of using an adjective when talking about the combined statistics however cumulative isn't really an accurate term and while ostensibly mean seems appropriate I'm unsure how top calculates that line on machines with CPUs of varying speeds. If it takes a mean of the percentages it's clearly misleading, if it does something a it cleverer use of the term mean is wrong. With this in mind I think the following tweak to Jason's suggestion would be best. i'm fine with this. anyone object? I am not in position to object or not. What I meant was to make it clear right from the man page that "single line for all processors" is indeed *combined* statistics for all CPU's in one set of numbers, not statistics for all individual processors somehow condensed to a single line. Perhaps word "combined" can be used there? Anyway, it was only a suggestion, if you think it is not relevant, simply ignore it. Glen's version is good too. Have a nice day. Regards, David $ diff -u top.1 top.1.new --- top.1 Thu Mar 24 12:39:45 2011 +++ top.1.new Thu Mar 24 17:59:30 2011 @@ -75,7 +75,8 @@ The options are as follows: .Bl -tag -width Ds .It Fl 1 -Display CPU statistics on a single line instead of a line per CPU. +Display CPU statistics for all processors on a single line instead of one +line per CPU. .It Fl b Use .Em batch @@ -282,7 +283,8 @@ .Sq P interactive command. .It 1 -Display CPU statistics on a single line instead of a line per CPU. +Toggle CPU statistics between a single line for all processors and one line +per CPU. .It C Toggle the display of process command line arguments. .It d Ar count
Re: top man page, clarification of interactive command 1
On Thu, 24 Mar 2011, Glen Anderson wrote: A small change to the interactive commands section to make the description of the 1 command more accurate. $ diff -u top.1 top.1.new --- top.1 Thu Mar 24 12:39:45 2011 +++ top.1.new Thu Mar 24 13:10:45 2011 @@ -282,7 +282,7 @@ .Sq P interactive command. .It 1 -Display CPU statistics on a single line instead of a line per CPU. +Toggle between a single line of CPU statistics and one line per CPU. .It C Toggle the display of process command line arguments. .It d Ar count Accidentaly, I have been playing with top(1) yesterday and today too. What would you think about pointing out that in the first mentioned case the statistics are cumulative? Regards, David $ diff -u top.1 top.1.new --- top.1 Thu Mar 24 12:39:45 2011 +++ top.1.new Thu Mar 24 13:10:45 2011 @@ -282,7 +282,7 @@ .Sq P interactive command. .It 1 -Display CPU statistics on a single line instead of a line per CPU. +Toggle between a single line of cumulative CPU statistics and one line per CPU. .It C Toggle the display of process command line arguments. .It d Ar count
Re: Bind Package
On Tue, 1 Mar 2011, Eric Kom wrote: On 3/1/2011 7:31 AM, David Vasek wrote: On Tue, 1 Mar 2011, Eric Kom wrote: hi please i'm a new on openbsd, someone can give me the name of bind dns package? base49.tgz bind is provided by base49 package or named package? Well no, I meant it as a joke. BIND is a part of the base system and as such it is included in the base49.tgz distribution set. You do not need any package for BIND. Regards, David
Re: Computer stops responding (freezes up) during uncorrectable data error
On Thu, 27 Jan 2011, Gordon Ferris wrote: 2. What utilities will show which sectors are occupied by specific files? Ideally I could specify a range of sectors and a list of files using those sectors would be provided. It would also be nice to specify files and be shown which sectors they occupy. I've heard of the Coroner's Toolkit; are there any other recommendations? Try looking at sleuthkit. Handy set of tools. Hopefully it could be used in your case too. Sleuthkit seems to have some limitations on OpenBSD. I needed to use it recently, but it did not recognise the FFS filesystem size when run on OpenBSD. I had to compile and run it on some linux live CD and it worked well (on OpenBSD FFS) from there. I was able to get a listing of blocks occupied by individual files. Regards, David
Re: How many cores into the processor?
On Sat, 18 Dec 2010, Theo de Raadt wrote: #sysctl hw.ncpu #sysctl hw.ncpufound I got the same response, and it's the number of processors, but I don4t know anything about the cores. Any idea how to get that info? You look at dmesg, and then at your processor manual. We do not expose these concepts, since there is so much variation between machines of different architectures (ie. not just i386). If I remember it right, there was some work in this area (CPUID and CPU model detection for i386 and amd64) done by Toby some time ago. Has it been used somewhere? http://marc.info/?l=openbsd-tech&m=120415522019563&w=2 http://marc.info/?l=openbsd-tech&m=122445269904389&w=2 http://undeadly.org/cgi?action=article&sid=20081019225434 Regards, David
Re: Freeze with Western Digital Caviar Green HDD
On Fri, 10 Dec 2010, Nick Holland wrote: Me? I usually buy whatever is cheap and on sale. Some manufacturers have the advantage of providing good documentation for their drives, some others do not have any at all. Regards, David
Re: Lenovo
On Thu, 2 Dec 2010, Jean-Francois wrote: Hi All, Are Lenovo, say for example T410 or equivalent professional laptops ok with OpeNBSD in terms of compatibility ? Any things to take care about ? Yes. Nvidia. Avoid it. Regards, David
Re: Advice on learning C as first language
On Wed, 24 Nov 2010, James Hozier wrote: I have to learn ASM anyway (to learn about buffer overflows and other related topics in the family of memory-related security). Would there be any advantage to learning Assembly first or would that just be an unneccessary headache? Soon you will be glad to write in C. /* Sorry for the noise, I simply couldn't resist. */ Write in C ("Let it Be") When I find my code in tons of trouble, Friends and colleagues come to me, Speaking words of wisdom: "Write in C." As the deadline fast approaches, And bugs are all that I can see, Somewhere, someone whispers: "Write in C." Write in C, Write in C, Write in C, oh, Write in C. LOGO's dead and buried, Write in C. I used to write a lot of FORTRAN, For science it worked flawlessly. Try using it for graphics! Write in C. If you've just spent nearly 30 hours, Debugging some assembly, Soon you will be glad to Write in C. Write in C, Write in C, Write in C, yeah, Write in C. BASIC's not the answer. Write in C. Write in C, Write in C Write in C, oh, Write in C. Pascal won't quite cut it. Write in C. Regards, David
Re: laptop disk shows wierd contents when moved to external enclosure
On Sun, 17 Oct 2010, Jonathan Thornburg wrote: Summary --- My primary laptop ("nitrogen") died, so I moved its disk to a backup laptop ("oxygen"). That laptop then died. :( I have now moved the former-nitrogen-disk to an external enclosure so that I can access my files via USB from still another laptop ("silver"). When I connect the USB cable to silver I see the usual dmesg lines. But the former-nitrogen-disk contents are "wierd": * fdisk and disklabel look fine, but * if I mount any one of the partitions, * 'df -i' looks fine (shows lots of space & inodes used) * but 'ls -a' and 'echo *' say there are no files present If I try to fsck any of the partitions, I get the following error # fsck -p /dev/rsd1a CANNOT READ: BLK 128 /dev/rsd1a: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY. # fsck -n /dev/rsd1a ** /dev/rsd1a (NO WRITE) CANNOT READ: BLK 128 CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, LOOK FOR ALTERNATE SUPERBLOCKS? no # What's suspicious is that I get this identical message (including the exact same sector numbers) for *any* partition. While I could certainly imagine that whatever broke nitrogen and oxygen managed to corrupt the disk contents, it seems implausible that it would garble the exact same list of sectors on each of several different FFS partitions. Instead, my symptoms look more like a disk-addressing mixup between oxygen/nitrogen and the external enclosure. Can anyone suggest (in more detail) what's going on here, and/or what I can do to fix it (i.e., access the former-nitrogen-disk filesystems from another laptop)? I'd at least like to understand the problem a bit before I go blindly poking around with fsck... Hi Jonathan! There are some USB <-> ATA bridge chips on the market that do not work well (or better to say: they do not work at all). Nonetheless, they are frequently used in cheap enclosures and adapters, especially in the very cheap ones. JMicron JM20337 is well known for this. In my experience - there were no visible problems when this bridge was connected to Toshiba drives, but it did not work with IBM/Hitachi and WD drives, both when powered through USB or independently. Symptoms were similar to what you see. Avoid it at all costs. It also flooded the disk's SMART tables with a lot of ATA CRC Errors. If the bridge in your enclosure can do a known SCSI-to-ATA translation, you could try smartmontools from ports to check for such (or other) errors, something like # smartctl -a -d usbjmicron /dev/rsd1c You can also check readability of the sectors directly with dd(1) or install the drive inside the laptop. For basic checks, booted install CD could be sufficient, both fsck(8) and dd(1) are there. Regards, David
Re: undeadly article
On Mon, 16 Aug 2010, Mihai Popescu B.S. wrote: Hello, I have read the undeadly.org article about how to "play" with airport security. I don't know who is the guy acting like this on an airport, but my brain triggered something I read in the past, about a well known guy from open source who was throw out from an airplane by the security team. Just my thought, maybe not related to misc ... but I think this story is not in the line of good old undeadly. Are you looking for this? http://www.openbsd.org/lyrics.html#43 Regards, David
Re: mount ffs as msdos, system hangs
On Mon, 26 Jul 2010, frantisek holop wrote: since my first email, i see what i did wrong... that was the point of writing to the mail list in the first place, to see if i was doing something silly. turns out i was. does that warrant abuse? of course it does, i am not new here. i also see, that now this problem became simply a "should we babysit root" issue, and i dont want root to be babysit either. but regardless of that, i think leaving old garbage after newfs-ing a partition is not a good idea in any case and it's one of those things i wouldn't except either. my mistake again. Finish your homework first. If ffs had overwritten the beginning of the partition you would have ended with a *different* error message and the kernel would not have => Your homework is to figure out what the other error message would be and why. it would be the same error message ffs gives when given a non-ffs partition: mount_msdos: /dev/sd1a on /mnt: Invalid argument No, it would not be. Try harder. Regards, David
Re: mount ffs as msdos, system hangs
On Mon, 26 Jul 2010, frantisek holop wrote: hmm, on Mon, Jul 26, 2010 at 12:12:32AM +0200, David Vasek said that It is not what happened. The -t msdos was forced by you. But you ah shit. you are right :] and it worked because ffs does not overwrite the beginning of the partition. i misinterpreted what happened, but this is still a problem, right? :] If ffs had overwritten the beginning of the partition you would have ended with a *different* error message and the kernel would not have crashed. But more likely, the situation you describe could have never ever occurred. Nobody else wants it this way, for a reason. You still haven't thought about it enough nor you haven't learnt enough. => Your homework is to figure out what the other error message would be and why. (Trying to create a diff would help you to learn too, sending a bug report will not.) Regards, David
Re: mount ffs as msdos, system hangs
On Sun, 25 Jul 2010, frantisek holop wrote: hmm, on Sun, Jul 25, 2010 at 02:29:25PM -0600, Theo de Raadt said that i think it doesnt matter what the user is, this shouldnt be happening. We make the source code available, and yet noone here has even sat down for 30 seconds and gone and checked the kernel msdos mount code and realized that it almost nothing it can validate a filesystem on. does that almost nothing include the partition type number? because i dont see why would the kernel msdos mount code even try to start mounting an msdos filesystem with type of A6. Hi Frantisek. It is not what happened. The -t msdos was forced by you. But you were not trying to mount a filesystem with type A6. A typo can happen but your mistake is in your interpretation of what has happened after the typo. Take a break and then think about it carefully. Regards, David
Re: power management of USB-connected disks
On Tue, 20 Jul 2010, David Gwynne wrote: On 20/07/2010, at 2:48 AM, Jan Stary wrote: I run a small server using an ALIX box and a CF card (wd0) plus two external disks (sd0, sd1) - see the dmesg at bottom. The CF card holds the system, while the two external disks are big storages that are only used sparsely; one of them is a (NFS exported) /backup dir that is only used for about an hour a night, for example. I wonder whether there is something like atactl(8) that I could use to control the power management of these disks - spin them down when not used etc, to reduce noise and heat (I have yet to measure if it would also mean a nontrivial power saving). I understand that atactl only works with ATA drives, which my disks dmesgly are not, being connected through sd(4) - although what's inside the external USB boxes is actually a Seagate Momentus (SATA) and a a Samsung Spinpoint (SATA). there is a (very very) slight chance that the chip that translates from scsi over usb to ata on the actual drive supports the ATA PASSTHRU scsi commands, which the openbsd kernel will now try. this means you might be able to run atactl against those disks. Maybe I don't read it right what you wrote, but the chip is part of an enclosure, not the actual drive. The chances are better than it might seem. Some vendors support SAT ATA PASSTHRU (like new chips from Oxford Semiconductor/PLX or Initio), some other vendors support their own proprietary (and mostly undocumented) "ATA PASSTHRU" (Cypress, JMicron, Sunplus) and the rest don't support anything at all. Not all chips from each mentioned vendor work though. you will need a -current system to try that with though. If you don't want to use atactl(8) or can't use -current, talking directly to drive with scsi(8) works well for this purpose, even with OS version couple of years old. You need to prepare the ATA PASSTHROUGH command yourself then. With Oxford 934DSB, I use the following commands to put the drive to: STOP: /sbin/scsi -f /dev/rsd0c -c "1b 00 00 00 00 00" STANDBY: /sbin/scsi -f /dev/rsd0c -c "a1 06 00 00 00 00 00 00 a0 e0 00 00" SLEEP: /sbin/scsi -f /dev/rsd0c -c "a1 06 00 00 00 00 00 00 a0 e6 00 00" IDLE: /sbin/scsi -f /dev/rsd0c -c "a1 06 00 00 00 00 00 00 a0 e1 00 00" FLUSH CACHE: /sbin/scsi -f /dev/rsd0c -c "a1 06 00 00 00 00 00 00 a0 e7 00 00" Wih JMicron, the following command should put the drive to Standby, but in my case it fails with JM20336. JMicron tech people are reluctant to provide any documentation about their proprietary "ATA PASSTHRU" command. STANDBY: /sbin/scsi -f /dev/rsd0c -c "df 00 00 00 00 00 00 00 00 00 a0 e0" or /sbin/scsi -f /dev/rsd0c -c "df 00 00 00 01 00 00 00 00 00 a0 e0" For Cypress, tech specs is available. considering how budget those usb to ata chips are, i wouldnt hold much hope. I am very happy with Oxford 934DSB, works reliably for me (i.e. with scsi(8) and SAT ATA PASSTHRU). It is quite frequent, even with (better quality) consumer USB drives. Look for USB 2.0 + FireWire + eSATA. Regards, David
Re: whiteboard over the net
On Tue, 30 Mar 2010, Marco Peereboom wrote: Drawing shit with the mouse. Not typing stuff with the keybored. A drawing app of your choice + a VNC of your choice? I used such a setup several times with various OS's. Regards, David
Re: RouterBOARD RB600A support
On Tue, 23 Mar 2010, P. Souza wrote: On 23/03/2010, David Vasek wrote: Hi all, there are bad news about RB600A. As everybody can read on MicroTik's website, RB600A has suddenly been discontinued: ... There's a [new-ish] RB800. It's probably due to that. Could be. It has more RAM, on the other hand it comes with a fan and costs about twice as much. At least its listed power rating isn't higher. I have no insight in PowerPC and can't tell if MPC8544 could be made to run with OpenBSD easily. Regards, David
Re: RouterBOARD RB600A support
On Tue, 23 Mar 2010, Theo de Raadt wrote: Hi all, there are bad news about RB600A. As everybody can read on MicroTik's website, RB600A has suddenly been discontinued: http://www.routerboard.com/pricelist.php?showProduct=55 They also removed the case for this board. Why did this happen? It comes to mind if that could possibly be related to Mark's work on OpenBSD support of this device? Don't know. Regards, David If two things happen after another, it does not imply that the first caused the second. True. Thus my words "it comes to mind if", "possibly" and "don't know". The fact is that this board was quite knew model and its withdrawal seems sudden and unexpected, at least for myself. There were also possibly alien landings around that time it and it comes to mind that they could possibly have interfered in the production of the machines. Don't know. I have no knowledge if there were any alien landings anywhere. Sorry. Mark announced his work to support RB600A in OpenBSD, which was a great news. Sadly, production of this board was withdrawn within about a week after the Mark's announcement. Bad luck. RB600A seemed to be a succesful product, with OpenBSD or not. Now it's gone, bad luck. There is nothing to argue about. It's a pity. Regards, David
Re: RouterBOARD RB600A support
On Tue, 23 Mar 2010, Otto Moerbeek wrote: On Tue, Mar 23, 2010 at 09:36:59PM +0100, David Vasek wrote: On Mon, 8 Mar 2010, Mark Kettenis wrote: I recently finished the support for the MicroTik RouterBOARD RB600A by giving OpenBSD/socppc a miniroot image that one can simply write to Compact Flash and stick onto the board. Detailed instructions have been added to INSTALL.socppc. All essential hardware on the board is now supported (with lots of contributions from dms@). Hi all, there are bad news about RB600A. As everybody can read on MicroTik's website, RB600A has suddenly been discontinued: http://www.routerboard.com/pricelist.php?showProduct=55 They also removed the case for this board. Why did this happen? It comes to mind if that could possibly be related to Mark's work on OpenBSD support of this device? Don't know. Regards, David If two things happen after another, it does not imply that the first caused the second. True. Thus my words "it comes to mind if", "possibly" and "don't know". The fact is that this board was quite knew model and its withdrawal seems sudden and unexpected, at least for myself. Regards, David
Re: RouterBOARD RB600A support
On Mon, 8 Mar 2010, Mark Kettenis wrote: I recently finished the support for the MicroTik RouterBOARD RB600A by giving OpenBSD/socppc a miniroot image that one can simply write to Compact Flash and stick onto the board. Detailed instructions have been added to INSTALL.socppc. All essential hardware on the board is now supported (with lots of contributions from dms@). Hi all, there are bad news about RB600A. As everybody can read on MicroTik's website, RB600A has suddenly been discontinued: http://www.routerboard.com/pricelist.php?showProduct=55 They also removed the case for this board. Why did this happen? It comes to mind if that could possibly be related to Mark's work on OpenBSD support of this device? Don't know. Regards, David
Re: errata46.html update
On Fri, 12 Mar 2010, Christopher Ahrens wrote: You aren't missing anything, these are 2 different webservers: OpenBSD.org [199.185.137.3, IP registered to Theos Software] Perhaps Theo swapped it with them for theos.com. Good joke! Regards, David
Re: How to create an installation image of OpenBSD for a USB stick?
On Thu, 4 Mar 2010, Ilya Ilembitov wrote: Hi, all. I have a pretty tricky challenge before me. My main (and only) machine is a Lenovo Thinkpad X200s. The problem is that it doesn't have an optical drive. Second problem is that I live in a dorn, so I only have access to wireless connection, not wired. And I want to install OpenBSD to a laptop that is currently running Debian Linux. With Thinkpad, the following has never dissapointed me: dd if=floppy47.fs of=/dev/rsd0c (or whatever your USB flashdrive is) and then just boot off it. This procedure either works or not with machines from other manufacturers, but if a Thinkpad is your only concern, it's damn quick. In fact, I haven't tried it with recent Lenovo branded Thinkpads, but I hope they didn't change the BIOS to worse. You have to try. If the RAMDISK kernel won't give you a working network driver, copy the installation sets to another USB flashdrive (or even the same, you won't need it after the boot), mount it and install. Regards, David
Re: How to create an installation image of OpenBSD for a USB stick?
On Thu, 4 Mar 2010, David Vasek wrote: On Thu, 4 Mar 2010, Ilya Ilembitov wrote: Hi, all. I have a pretty tricky challenge before me. My main (and only) machine is a Lenovo Thinkpad X200s. The problem is that it doesn't have an optical drive. Second problem is that I live in a dorn, so I only have access to wireless connection, not wired. And I want to install OpenBSD to a laptop that is currently running Debian Linux. With Thinkpad, the following has never dissapointed me: dd if=floppy47.fs of=/dev/rsd0c (or whatever your USB flashdrive is) Of course, it should be obvious, but with Debian Linux use an appropriate device for of=. It should be /dev/sda if they didn't change their mind recently. Regards, David
Re: current on HP EliteBook 8530w
On Fri, 22 Jan 2010, Jan Stary wrote: This is a fresh -current on an HP EliteBook 8530w ("Mobile Workstation"). Thank you all who make be able to run this. /bsd panics when booting when ACPI is enabled; boots and works just fine once ACPI is disabled (via UKC). See full dmesgs below. It is similar to all the other HP EliteBook and HP ProBook I have seen so far. They do not run with whole ACPI enabled. What puzzles me is that /bsd.rd (who does the install) has ACPI enabled, yet runs fine - unlike the /bsd that in installs The sets of ACPI devices supported in GENERIC and RAMDISK_CD kernels differ, RAMDISK_CD supports only a subset. See: diff /usr/src/sys/arch/i386/conf/GENERIC /usr/src/sys/arch/i386/conf/RAMDISK_CD) Regards, David
Re: Another question: device naming convention
On Fri, 22 Jan 2010, Otto Moerbeek wrote: On Thu, Jan 21, 2010 at 11:34:48PM -0800, Johan Beisser wrote: You could makefs on /dev/sd0c instead. Nothing really forces you to create other slices (or partitions) on the device. Bad advice. disklabel does not record some redundant information for the c partitiion. Which may bite you in case of a superblock corruption due to power loss, for example. In that case, fsck_ffs is not able to reconstruct some vital data needed to do its work. Never use the c partition for a file system. The other reason for it being a bad advice is that you should newfs(8) on a raw device, not a block device. In this otherwise wrong case it should be /dev/rsd0c (or /dev/rsd0a, /dev/rsd0d or whatever) rather than /dev/sd0c. The same applies to fdisk(8), disklabel(8), fsck(8), etc., but never to mount(8), where you should always use a block device (for example /dev/sd0a). Plus, there isn't anything like 'makefs' in OpenBSD, is it? Regards, David
Re: writing to usb very slow
On Tue, 19 Jan 2010, T. Tofus von Blisstein wrote: Hello David, thanks. You're welcome. # mount /dev/sd1a /mnt # date && cp -r TEST/ /mnt && umount /mnt && date Tue Jan 19 23:11:27 CET 2010 Tue Jan 19 23:29:12 CET 2010 So it's reduced a lot, but still it is much slower than... sorry guys, the penguin. Still, from 50 minutes to 18 to copy 256M is a significant improvement Try using "softdep" option for mount, possibly even the "async" option, if you like the risk, otherwise you are comparing two completely different modes of filesystem operation. Regards, David