Re: Architeture Choose
On Thu, 11 Nov 2010 12:09:19 -0700 (MST) Diana Eichert deich...@wrench.com wrote: as an aside. anyone know where you can purchase a Portwell CAM-0100 in NA? diana Diana, You might want to give Portwell (in the US) a call: 1-510-403-3399 jcr
Re: FreeBSD isn't Free
On Thu, 7 Oct 2010 01:03:42 -0500 Sam Fourman Jr. sfour...@gmail.com wrote: What does this mean? does it mean there was a mistake? http://www.listware.net/201010/freebsd-questions/19724-re-like-it-or-not-theo-has-a-point-freebsd-is-shipping-export-restricted-software-in-the-core.html No mistake. Randy said Theo has a valid point, and he does. If you ever get the chance to have a discussion with either Theo or Randy, you should realize two things immediately: 1.) They're really fucking smart, and they've done all their homework. 2.) They're probably *way* ahead of you in the discussion, and they're impatiently waiting for you to mentally catch up. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: FreeBSD isn't Free
On Tue, 05 Oct 2010 23:22:03 -0600 Theo de Raadt dera...@cvs.openbsd.org wrote: Just for fun. * 4.3. Licensee shall not export, either directly or indirectly, any of this * software or system incorporating such software without first obtaining any * required license or other approval from the U. S. Department of Commerce or * any other agency or department of the United States Government. In the * event Licensee exports any such software from the United States or * re-exports any such software from a foreign destination, Licensee shall * ensure that the distribution and export/re-export of the software is in * compliance with all laws, regulations, orders, or other restrictions of the * U.S. Export Administration Regulations. Licensee agrees that neither it nor * any of its subsidiaries will export/re-export any technical data, process, * software, or service, directly or indirectly, to any country for which the * United States government or any agency thereof requires an export license, * other governmental approval, or letter of assurance, without first obtaining * such license, approval or letter. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/dev/acpica/hardware/hwsleep.c?rev=1.2 More Fun: * 2.2. Intel grants, free of charge, to any person (Licensee) obtaining a * copy of the source code appearing in this file (Covered Code) an * irrevocable, perpetual, worldwide license under Intel's copyrights ... It seems worldwide means some other world besides this one.
Re: 4.8 Release and Download and
On Fri, 10 Sep 2010 11:19:16 -0700 Bryan Irvine sparcta...@gmail.com wrote: I also heard it said once (though I'm sure I'll be corrected if wrong) that Theo's salary comes from CD purchases but not donations. So the only way to keep him employed full-time on OpenBSD is by buying the disks. -B Curiosity is only human, but to respect the privacy of others, sometimes it must be curtailed. I do possess a very vivid imagination, and worse, a truly caustic sense of humor, so should I start publicly and wildly speculating about how *you* make a living? The result might be very entertaining for some, but it wouldn't be very polite or fair to you. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: 4.8 Release and Download and
On Fri, 10 Sep 2010 16:46:52 -0700 Bryan Irvine sparcta...@gmail.com wrote: Curiosity is only human, but to respect the privacy of others, sometimes it must be curtailed. Agreed...though I'm confused about the point you're making. The point is, in at least some places/cultures it's impolite to either ask or speculate about another person's income, particularly in an open public forum. Just because Theo has occasionally divulged *some* information about project and/or his finances doesn't mean he's obligated to provide any further details. The posts you linked to were made during a really tough situation, but worse, uninformed people were speculating wildly. Being curious which is better, buying CDs or making donations, is completely normal, but even if you politely asked Theo in private, you might not get an answer. Even if you got an answer, it might not be what you expect... --My all time favorite answer from Theo was: The choice is yours. It actually makes a lot of sense. ;-) jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: automounter
On Fri, 10 Sep 2010 22:41:43 +0200 Bret S. Lambert bret.lamb...@gmail.com wrote: On Fri, Sep 10, 2010 at 10:37:50PM +0200, Jean-Francois wrote: Hello, Do you have an idea where to look for an auto mounter in openbsd ? I installed gnome as a server for a friend and would like that his fat32 usb disks are auto mounted ... It might be useful to auto mount also other kind of file systems. And for esata, is it possible to mount without reboot, is this called a hot plug ? I eared that it's not possible yet ... is this correct ? man hotplugd, and script like a fiend. Also, ckuethe@ showed me some interesting things can be done with disklabel UID's with scripted auto-mounting. Lastly, some esata enclosures can be very dodgy, particularly if they are powered by USB (typically a Y dongle taking two powered USB ports on the system so the disk has enough power to run properly). You should do a *lot* of testing before trusting any esata setup. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: 4.8 Release and Download and
On Fri, 10 Sep 2010 00:58:40 +0100 Keith ke...@scott-land.net wrote: Seeing that orders are being taken for the 4.8 release got me thinking about purchasing a copy, I don't need a copy on CD so just a download for my architecture would be fine. In the past I've sent a small donated to the project and was wondering if there's way that I could buy the right to download the OS before the official release. Personally I would happily pay the same as the full CD costs and probably some more to just download the OS and the project would save on the production of the CD and the postage. I'd defiantly pay for 802.11G, hope that it's working in this release. Keith Keith, It seems you're kind of missing the point. The developers *GIVE* the code away free to everyone. If you appreciate all the time, effort and expense the developers sink into giving away code for free, then the right answer is to try to give back to them in some way. Donations are always welcome. Some people work at companies where they use OpenBSD in their businesses. Since it's often impossible to get their companies to make a straight forward donation, instead they *BUY* a big stack of release CDs for their company. Of course, they don't actually need a big stack of CDs, but it was the only way the could get approval from the bosses. As for pre-ordering release CDs, yes, the discs are often (but not always) delivered before the official release date. Of course, until the actual release date when the CVS and package mirrors open up to public access, having the CDs early really doesn't give you much of a head start. Some people don't want stacks and stacks of CDs around, so instead of ordering release CDs, the order T-Shirts, posters or best of all, just make donations to give back to the project and developers who give them so much. Personally, I buy the release CDs just for the stickers. ;) Either way, release CD sales and donations really do help to fund continued development of OpenBSD. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: maybe OT 6 year anniversay of Chuck Yerkes death
On Fri, 27 Aug 2010 11:01:43 -0600 (MDT) Diana Eichert deich...@wrench.com wrote: I don't think it's off topic but others might. I'm writing this post to remember Chuck Yerkes, a long time contributor to the m...@openbsd list. Chuck died 6 years ago this coming weekend while riding his motorcycle. http://web.archive.org/web/20041012235249/http://www.contracostatimes.com/mld/cctimes/news/9511974.htm http://marc.theaimsgroup.com/?l=openbsd-miscm=109385676632581w=2 Just wanted to remember you Chuck, take it easy wherever you are. diana Thank You Diana. Shirt, Shoes, Sober... --Pick Two Chuck Yerkes jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: cwm keybindings and autogroup issues
On Mon, 23 Aug 2010 14:54:44 +0100 Owain Ainsworth zer...@googlemail.com wrote: 2. I just adopted XXXterm as my default web-browser. I used to have autogroup 3 opera,Opera which I replaced with autogroup 3 xxxterm,XXXterm however xxxterms do NOT get autogrouped. Note that I do have xxxterm in my menu because of x,y syntax is for name,class pairs, not class,class pairs (see cwmrc (5)). autogroup 2 XXXTerm is confirmed to work fine here (as of about two minutes ago on a current built yesterday). note: xprop WM_CLASS on xxxterm gives: WM_CLASS(STRING) = xxxterm, XXXTerm and for xxxterm the window name is the title of the webpage in question. Predrag, Also note the difference in capitalization, namely XXXterm in yours versus XXXTerm in Owain's. You should probably check the code to see if capitalization makes a difference. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: undeadly article
On Wed, 18 Aug 2010 16:28:57 +0300 Mihai Popescu B.S. mihai...@gmail.com wrote: I like the humour on undeadly, but this article was not for me. I saw a guy who was tried to get as more attention as he can. Mihai, You still don't understand. http://en.wikipedia.org/wiki/Sarcasm In writing, I had the choice between complaining about all of my time wasted by the various security people, or joking about how much time I could waste. The latter is called sarcasm. It's no different than joking about the sun being too bright at night (hint: the sun doesn't shine at night). jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: undeadly article
On Wed, 18 Aug 2010 11:21:19 -0700 Noah Pugsley noa...@bendtel.com wrote: I thought the writeups from jcr were great. A little lighter and more fun than the usual fare. To be honest, if I had to choose between them and the developer interviews I choose developer interviews. But they are a welcome supplement for sure. I hope they continue. mtu@ and I are working on the individual developer interview articles. There's a lot of them, so it will take some time, but we'll publish them as we get them completed. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: undeadly article
On Mon, 16 Aug 2010 19:22:55 +0300 Mihai Popescu B.S. mihai...@gmail.com 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. Hi Mihai, I wanted to thank you for both reading the articles on www.undeadly.org but more importantly, I wanted to thank you for voicing your opinion. You could have voiced your opinion on undeadly in the comments, rather than here on misc@ but I somewhat understand why you decided to use the mailing list instead. Comparing me to insane antics of Richard Stallman is an extremely offensive opinion, so you probably worried your opinion would have been deleted from undeadly. You didn't need to worry. On undeadly, we let conflicting opinions stand. Only with reluctance will we delete the most blatant spam/libel (i.e. trolls) to keep the site usable. My article was just a humorous retelling of the very typical problems seen by people traveling. The trouble with humor is it can make no sense across language or cultural barriers. I like to think the world is a better place when we can laugh, but unfortunately, due to cultural and language differences, some people will not understand or appreciate all of the jokes. If you asked me to understand a language other than English, I would fail miserably, but if you asked me to understand jokes in another language or from another culture, I would fail even worse. You would have to explain the jokes to me, and even then I might not get them due to lack of experience. If you really want to understand all of the pointed humor in the article, you'll need to do a lot of reading and learning. For example, the phrase U.S. Department of Homeland Theatrics I used in the article is pointed joke referring to the phrase Security Theater originated by Bruce Schneier. http://en.wikipedia.org/wiki/Security_theater http://en.wikipedia.org/wiki/Bruce_Schneier http://www.schneier.com The complete nonsense Jacob Meuser (jakemsr@), Jim Razmus (jim@) and I went through at Canadian Customs not only highlights ineffective and fake security measures, but also shows the lack of understanding most people have of open source software. All of us were very glad to be done wasting our time with pointless questions from ignorant people. We did not cause or prolong their nonsense, instead we complied their requests and suffered through their nonsense like all rational people do. As for laughing about it and laughing at them afterwards, as well as laughing publicly, this is a good and even beneficial response. The more people who openly laugh at fake security, the better everyone will be. I'm sorry you did not see the humor or the points in the article, but it was better for me to try to write an entertaining but pointed article involving the issues everyone faces when traveling. I will agree it was not a typical, highly technical article for undeadly, but I hope you realize we work on undeadly for fun, so occasionally breaking up the technical bits with joking around should be expected. kind regards, jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: undeadly article
On Tue, 17 Aug 2010 19:30:55 +0300 Paul Irofti p...@irofti.net wrote: jcr, please forgive my fellow romanian as us gypsies don't get to travel much and don't know the mysteries of these flying birds and their inner workings. It's really not a big deal, and Mihai's criticism (or any criticism) is worth consideration. Instead of being offended, I tried to see what went wrong. I'm still terribly new to writing articles, but I'm trying to learn from any feedback I receive, positive or negative. On a lighter note, if you and Mihai want to send me your best Romanian jokes in Romanian, I'm sure I can misinterpret them. ;) jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: network access controller like medusa ?
On Fri, 16 Jul 2010 14:57:27 +0200 Leonardo Lombardo l.lomba...@jwizard.it wrote: You're right Michal, I try to make a better answer. Medusa is a software that can control switches so that the operator can manage vlan, routes and network access (and many other things) from a single control panel. Operator can assign bandwith and priority to vlans and can have some report about network utilization. Is there some software (that runs on openbsd) that can do this ? Thanks Leonardo All of this exists in the base operating system. Please read: ifconfig(8) vlan(4) hostname.if(5) pf(4) pfctl(8) pf.conf(5) route(8) networks(5) If you're looking for some kind of pointy-clicky-gui nonsense to dumb things down, then you're probably using the wrong operating system. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: request help with tip and serial port problem
On Tue, 13 Jul 2010 06:47:18 -0600 fred f...@blakemfg.com wrote: I restored the dialer group to /dev/tty01 and added the user to the dialer group as Nick suggested. It still doesn't work but the response is different now. I believe there is a cable problem now. The cable works with a Sun Ultra 10 but not with the PC running openbsd. Thank you for the help. Keeping with Nick's suggestion of not doing this as root or sudo, another option is to use /etc/fbtab to *temporarily* change ownership or permissions. -- The OpenBSD Journal - http://www.undeadly.org
Re: Question about moving system to different hardware
On Mon, 12 Jul 2010 20:51:34 -0400 Nick Holland n...@holland-consulting.net wrote: 2. I note that in the example for backing up and restoring that raw devices are used. In my situation, I will be going from ide to a usb drive, and then from the usb drive to scsi disks. So, the ide drive I can't access raw, but I don't think this is an issue. Is it? And, if I don't read from the raw device with dump, it's still okay to write to the raw device with restore, right? actually, if you are going to an interim device, you will be dumping to a file (on a file system on that device), so you will go raw device to file, then file to raw device. Not necessarily. You can backup a directory to a file, so you do not need to backup a raw device. This is not a common way to do backups, but it works great. As for easiest and fastest, just do a new install. If the new machine has an IDE interface, then you can physically connect the old drive into the new machine, and copy over the files. jcr -- The OpenBSD Journal - http://www.undeadly.org
OpenBSD Speakers Wanted At MeetBSD California 2010
I was asked by Denise Ebery (denise _AT_ ixsystems.com) and Matt Olander (matt _AT_ ixsystems.com) about having OpenBSD speakers at the upcoming MeetBSD California 2010 conference in November. http://meetbsd.org I went to the '08 conference hosted at Google and it was a lot of fun, save for the fact there was no representation of OpenBSD there. It would be great if any of the OpenBSD developers would be willing to speak at the MeetBSD 2010 conference. thanks, jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Perl problems in -current
On Tue, 06 Jul 2010 11:26:42 +0100 Tom Murphy open...@pertho.net wrote: This error does not occur in 4.7-release. Has there been something up with the Perl packages in -current lately? Marc Espie (espie@) has been doing tons and tons of work on the ports system. The packages in question are actually parts of the ports system. -- The OpenBSD Journal - http://www.undeadly.org
Re: usb memory stick failing
On Fri, 9 Jul 2010 17:29:18 +0200 Renzo rfabr...@nerdshack.com wrote: On Friday 09 July 2010 08:54:15 patrick keshishian wrote: Hi, I recently attempted an installation from a usb memory stick, where installation of xfont47.tgz failed consistently due to crc error[0]. The stick was prepared following steps from OBSD FAQ[1]. I recopied xfont47.tgz file to the stick, and confirmed (or so I thought) that the source and new copy of this file were identical using cmp(1). Restarting the install bombed on the same file. So I stuck the stick in my source computer and mounted it and ran md5(1) on it. Sure enough the checksum is different from the source. I did a umount(8) and a mount(8), then ran md5(1) again, and this time yet a new value was reported. While mounted, running md5(1) again reports the same value -- i assume this is because the file is cached at this point -- explaining why cmp(1) initially failed to raise a flag. Every umount(8), mount(8) and md5(1) gives a new result: In adition to previous answers: http://www.undeadly.org/cgi?action=articlesid=20100404103735 The article didn't stress enough how important it is to fsck. Hmmm... I should probably rephrase that, but it's true either way. ;) jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Sierra Wireless MC5720 Modem
On Mon, 14 Jun 2010 20:17:44 -0500 Marco Peereboom sl...@peereboom.us wrote: Anyone got: umsm0 at uhub7 port 2 configuration 1 interface 0 Sierra Wireless Sierra Wireless MC5720 Modem rev 1.10/0.01 addr 2 ucom0 at umsm0 To work on OpenBSD? I get basically no output from the modem using this in /etc/remote: mobile:\ :at=hayes:dv=/dev/cuaU0:dv=/dev/ttya:tc=direct:tc=unixhost: # sudo tip remote connected And then I can type AT all day long and get no response. The modem isn't activated but I don't want to go spend money on activating it unless I know if that is what is causing it to not respond. Something else weird is that if I fart enough with tip and stuff to get to the modem and reboot with it on it hangs the IO subsytem. Not sure why a serial port is sitting on IPL_BIO but that is a different story. I spotted something interesting that I've never seen myself... It seems some of these mobile data cards require some kind of mode switch for them to be in a usable state (read: the serial port that accepts AT Commands is only visible/usable in a certain mode). Some of the linux folks have been working on mode switching code: http://blogger.ziesemer.com/2008/10/alltel-um175al-usb-evdo-ubuntu.html http://www.draisberghof.de/usb_modeswitch/ As you can read in the links above, the mode switching magic seems to be at least somewhat device dependent. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Sierra Wireless MC5720 Modem
On Mon, 14 Jun 2010 20:17:44 -0500 Marco Peereboom sl...@peereboom.us wrote: Anyone got: umsm0 at uhub7 port 2 configuration 1 interface 0 Sierra Wireless Sierra Wireless MC5720 Modem rev 1.10/0.01 addr 2 ucom0 at umsm0 To work on OpenBSD? I get basically no output from the modem using this in /etc/remote: mobile:\ :at=hayes:dv=/dev/cuaU0:dv=/dev/ttya:tc=direct:tc=unixhost: # sudo tip remote connected And then I can type AT all day long and get no response. The modem isn't activated but I don't want to go spend money on activating it unless I know if that is what is causing it to not respond. Something else weird is that if I fart enough with tip and stuff to get to the modem and reboot with it on it hangs the IO subsytem. Not sure why a serial port is sitting on IPL_BIO but that is a different story. As mentioned off list, a vast number of the early data card designs actually have *multiple* serial ports, but only one of them is usable as a typical AT-Command modem. The other serial ports on the device(s) can only speak proprietary protocols and are used for BS Management and Monitoring functions (e.g. constantly checking/reporting signal strength). The umsm man page clearly mentions these other unusable ports since there's no definitive way to tell which port is usable as a modem. If a serial port on the device does not respond to AT commands, you have the wrong port. If it's the only available port on the device, then you need to tweak the umsm sources to make it look for multiple ports on your device. If after finding all the available ports on a device, you cannot find a port that talks AT commands, then either the device is broken or you need some secret sauce to make the device go back to speaking normal AT commands (rather being in proprietary mode). Additionally, many modems support profiles which is a fancy way to say the firmware in the device remembers the settings you previously gave it. Clearing the various types of profiles/settings is often vendor/device specific. Some of the more common AT commands for resetting a device are: ATZ ATF AT+CFUN=1 Since you will need access to a MS-windows system to do the required activation nonsense before the device will work with a given providers network, you should look at the device to see what *.inf file is being used to define how the device is controlled. For example, the Pantech (ZTC) UMW190 I have here uses the C:\windows\inf\oem33.inf file as its definition (seeable through device properties or Modem/PPP logging if enabled). Look in said file for the Reset entry to figure out the proper AT command.. By comparison, Sierra Wireless is one of the most open source friendly of all the data card vendors so digging around for their docs or looking how the specific device shows up (number/type of ports) in linux might be real helpful. Dan Williams has done a lot of work on the various data card devices in linux, including some degree of reverse engineering of the proprietary protocols which the unusable ports typically speak. http://blogs.gnome.org/dcbw/ Ya, ya, I know... (insert linux rant), but they do have some good info and it may be helpful. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Huawei E1750
I don't have time to dig up the specs on this specific device, and you
didn't provide a link to them. None the less, *some* (but of course not
all) data card devices actually contain flash storage like a USB
stick. The umass0 reported seems to indicate this is the case with the
E1750. Unfortunately, the flash storage on data cards can
occasionally make a real mess of things. You can trying to disable
'umass' via UKC ('boot -c') and then plug in the device to see if the
ucom ports are discovered.
jcr
On Sat, 12 Jun 2010 18:59:18 +0200 David Zeillinger
david.zeillin...@gmx.at wrote:
Hello,
I have a Huawei E1750 which shares its ID with the E161, which is in
-current.
I tried a snapshot from June 10, but ucom does not attach to umsm.
Any hints?
Regards,
David
umsm0 and umsm1 belong to an E220
umsm2 and umsm3 belong to the E1750
OpenBSD 4.7-current (GENERIC) #28: Thu Jun 10 00:17:32 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache)
335 MHz cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE
real mem = 133709824 (127MB) avail mem = 120410112 (114MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/15/01, BIOS32 rev. 0 @
0xf06c0, SMBIOS rev. 2.3 @ 0xf1f50 (45 entries) bios0: vendor Award
Software, Inc. version ASUS P3B-F ACPI BIOS Revision 1008 Beta 004
date 10/15/2001 bios0: ASUSTeK Computer INC. P3B-F apm0 at bios0:
Power Management spec V1.2 (BIOS management disabled) apm0: APM power
management enable: unrecognized device ID (9) apm0: APM engage
(device 1): power management disabled (1) apm0: AC on, battery charge
unknown acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf/0xf22
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf0e80/160 (8 entries)
pcibios0: PCI Interrupt Router at 000:04:0 (Intel 82371FB ISA rev
0x00) pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x800 0xcc000/0x800
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0xe400, size 0x400
ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 Matrox MGA G200 AGP rev 0x03
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
piixpcib0 at pci0 dev 4 function 0 Intel 82371AB PIIX4 ISA rev 0x02
pciide0 at pci0 dev 4 function 1 Intel 82371AB IDE rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: TRANSCEND wd0: 1-sector PIO, LBA,
1946MB, 3985632 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA
mode 2 pciide0: channel 1 disabled (no drives)
uhci0 at pci0 dev 4 function 2 Intel 82371AB USB rev 0x01: irq 5
piixpm0 at pci0 dev 4 function 3 Intel 82371AB Power rev 0x02: SMI
iic0 at piixpm0
lm1 at iic0 addr 0x2d: AS99127F rev 2
iic0: addr 0x2f d0=00 d1=00 d2=00 d3=00 d4=00 e0=00 e1=00 e2=00 e3=00
e4=00 e5=00 e6=00 e7=00 e8=00 e9=00 ea=00 eb=00 f6=f8 f7=10 words
00= 01= 02= 03= 04= 05= 06= 07= xl0
at pci0 dev 10 function 0 3Com 3c905C 100Base-TX rev 0x74: irq 12,
address 00:01:02:a4:ed:a8 bmtphy0 at xl0 phy 24: 3C905C internal PHY,
rev. 6 xl1 at pci0 dev 11 function 0 3Com 3c905C 100Base-TX rev
0x74: irq 10, address 00:04:76:e8:41:30 bmtphy1 at xl1 phy 24: 3C905C
internal PHY, rev. 6 isa0 at piixpcib0 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
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1
biomask eb65 netmask ff65 ttymask
mtrr: Pentium Pro MTRR support
umsm0 at uhub0 port 1 configuration 1 interface 0 HUAWEI
Technologies HUAWEI Mobile Modem rev 1.10/0.00 addr 2 ucom0 at umsm0
umsm1 at uhub0 port 1 configuration 1 interface 1 HUAWEI
Technologies HUAWEI Mobile Modem rev 1.10/0.00 addr 2 ucom1 at umsm1
umass0 at uhub0 port 1 configuration 1 interface 2 HUAWEI
Technologies HUAWEI Mobile Modem rev 1.10/0.00 addr 2 umass0: using
SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0
cd0 at scsibus0 targ 1 lun 0: HUAWEI, Mass Storage, 2.31 SCSI2
5/cdrom removable umsm2 at uhub0 port 2 configuration 1 interface 0
HUAWEI Technology HUAWEI Mobile rev 2.00/0.00 addr 3 umsm3 at uhub0
port 2 configuration 1 interface 1 HUAWEI Technology HUAWEI Mobile
rev 2.00/0.00 addr 3 vscsi0 at root
Re: libiberty
On Mon, 7 Jun 2010 12:57:06 +0300 Gregory Edigarov g...@bestnet.kharkov.ua wrote: no excuse, you say well... # cat /root/build.sh rm -rf /usr/obj/* rm -rf /usr/include/g++/* cd /usr/src make obj cd /usr/src/etc env DESTDIR=/ make distrib-dirs cd /usr/src make build # sh build Just running `rm -rf /usr/include/g++/*` is *_ONLY_* sufficient for those who are upgrading via snapshots. For those upgrading via source (i.e. *YOU*), there are a lot more steps listed in current.html http://www.openbsd.org/faq/current.html All of this is due to the recent upgrading of gcc3 to gcc4 on the amd64 and sparc64 archs. If you don't follow the procedures in current.html, then you can be reasonably sure things will become a real mess. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: libiberty
On Sat, 5 Jun 2010 13:25:26 +0300 Gregory Edigarov g...@bestnet.kharkov.ua wrote: Stop in /usr/src/gnu/lib/libiberty (line 92 of /usr/share/mk/sys.mk). # uname -a OpenBSD edigarov.sa.net.ua 4.7 GENERIC#16 amd64 This happen while i am trying to build from sources. The system is the latest binary snapshot as found on ftp.openbsd.org. Upgraded from snapshot, done cvs up -Pd in /usr/src; rm -rf /usr/obj/*; make obj; make build build process stops with above error. Just want to learn how to struggle this. Here's what i tryed: cd /usr/src/gnu/lib/libiberty make -f Makefile.bsd-wrapper cleandir make -f Makefile.bsd-wrapper depend make -f Makefile.bsd-wrapper no success... It seems you forgot to run sysmerge after upgrading via snapshot, and you didn't follow current.html http://www.openbsd.org/faq/current.html -- The OpenBSD Journal - http://www.undeadly.org
Re: i7-720QM one more time
On Thu, 3 Jun 2010 18:31:05 -0400 (EDT) Charlie Root r...@sugarloafshores.net wrote: Thanks for your looking at my post. Come to think about the wsmouse, I believe that Xorg -configure set it to wsmouse0, so I tried wsmouse1 (no joy, niether the trackpad or the wireless mouse worrked. I don't believe is has ever been set to simply wsmouse. I'll give that a try. Kyle, It seems you misread tedu@'s post. He asked you to check to see if your X is using '/dev/wsmouse0' or '/dev/wsmouse' ? Though your /etc/X11/xorg.conf file might designate something, the way to figure out what you're actually using is look at /var/log/Xorg.0.log When X doesn't get what it wants, it can sometimes fall back to something else (e.g. intenral default config), so what you're actually using could be different from what you've defined in /etc/X11/xorg.conf via `Xorg -configure` or manually. As for whether or not you even need to have an xorg.conf file, that's a somewhat different matter. Often (as is the goal), you can run without a configuration and let X set itself up automatically. This doesn't always work, but works most of the time. Also, I remember seeing the evil word nvidia in your dmesg: vga1 at pci1 dev 0 function 0 vendor NVIDIA, \ unknown product 0x0a75 rev 0xa2 Sadly, I don't have total recal, so I'm not sure which nvidia graphics chip that is. The thing you need to know is support for the newer nvidia crap namely GeForce 8xxx, GeForce 9xxx and GeForce GTX (G80, G84, G86, G92, G94, G96, G98, GT200) is only available in -current. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: No Video/X server issue
On Wed, 26 May 2010 09:28:37 -0700 (PDT) Norm Legare normleg...@yahoo.com wrote: OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP ... vga1 at pci2 dev 0 function 0 NVIDIA GeForce 9100 rev 0xa2 GeForce 8xxx and 9xxx support is not available in 4.7-Release/Stable. It is only available in 4.7-current. Oddly enough, today is a flag day for amd64 due to replacing GCC3 with GCC4 in base. You might want to wait a few days until new snapshots become available. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re:
I realize you must be frustrated while learning something new, but I am
frustrated by you not paying attention. Now let's look at what I wrote
one more time:
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
part#1 part#2 part#3 part#4
The first chunk of part#1, namely '10.0.0.1', says I want my IP address
to be 10.0.0.1 but the second chunk of part#1, namely the '/0', is a
netmask which says I will accept any IP address the remote system wants
me to use on my side.
The first chunk of part#2, namely '10.0.0.2', says I want the remote
side to use IP address 10.0.0.2 but the second chunk of part#2, namely
the '/0', says I will accept any IP address the remote system wants to
use on their side.
The IP addresses (and netmasks) stated in part#1 and part#2 are
important. They should never be the same, and they should never be set
to default route address ('0.0.0.0'). This is why two separate private
IP addresses are used in the above (10.0.0.1 and 10.0.0.2), and also why
the netmask '/0' in CIDR notation allows for the remote side to pick any
address it wants to use for *both* your IP address and its IP address.
If you forget the CIDR notation netmask on part#1 or part#2, you are
DEMANDING that the specified address be used, and if the other side
disagrees, your side will disconnect.
The part#3 is the netmask assigned on my side to the resulting
connection after we negotiate addresses. Links between two systems made
with Point to Point Protocol (ppp) are weird in comparison to typical
network links, and some operating systems do not have a specific
PointToPoint netmask in the network stack, so the netmask must be
faked. Using '0.0.0.0' as the part#3 netmask tells the ppp program to
use what is available and the result is ppp will typically set the
netmask to '255.255.255.255' automatically.
The part#4 is the trigger address which controls when ppp will try to
establish a connection. Since we set part#4 to the equivalent of any
address namely '0.0.0.0' any attempt to contact another system will
result in ppp automatically establishing the connection. The thing to
realize is 0.0.0.0 is roughly equivalent to a default route.
The stuff you are doing is just plain wrong:
set ifaddr 0.0.0.0/0 0.0.0.0-255.255.255.254 0.0.0.0 0.0.0.0
part#1 part#2 part#3 part#4
Prior to negotiating address, you are saying your IP address will
initially be 0.0.0.0 and the remote IP address will also initially be
0.0.0.0 The problem is, when two systems have the same IP address you
have a conflict. Additionally, since 0.0.0.0 equates to the default
route, this is very bad. Needless to say, the ppp(8) software is
compensating for your mistakes and doing the best it can with your
broken config.
In the second chunk of your part#1, namely '/0', this netmask says that
you will accept any IP address the other side wants you to use. This is
good.
In the second chunk of part#3, namely '-255.255.255.254' is using the
wrong syntax. The ppp(8) program might interpret this as a range of
addresses, or might interpret it as a pair of addresses, or it might
interpret it as a netmask. You should use simple CIDR notation as
described in the ppp man page.
If ppp(8) is interpreting this bad second chunk of part#3 as a netmask,
the you are *DEMANDING* that the remote system use 0.0.0.0 or 0.0.0.1 as
its IP address, and if the remote side refuses to use one of those two
addresses, then you will disconnect.
jcr
Re:
On Tue, 25 May 2010 00:54:53 +0200 patrick kristensen
kristensenpatri...@gmail.com wrote:
2010/5/24, J.C. Roberts list-...@designtools.org:
I realize you must be frustrated while learning something new, but
I am frustrated by you not paying attention. Now let's look at what
I wrote one more time:
set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0
part#1 part#2 part#3 part#4
The first chunk of part#1, namely '10.0.0.1', says I want my IP
address to be 10.0.0.1 but the second chunk of part#1, namely the
'/0', is a netmask which says I will accept any IP address the
remote system wants me to use on my side.
The first chunk of part#2, namely '10.0.0.2', says I want the remote
side to use IP address 10.0.0.2 but the second chunk of part#2,
namely the '/0', says I will accept any IP address the remote
system wants to use on their side.
The IP addresses (and netmasks) stated in part#1 and part#2 are
important. They should never be the same, and they should never be
set to default route address ('0.0.0.0'). This is why two separate
private IP addresses are used in the above (10.0.0.1 and 10.0.0.2),
and also why the netmask '/0' in CIDR notation allows for the
remote side to pick any address it wants to use for *both* your IP
address and its IP address.
If you forget the CIDR notation netmask on part#1 or part#2, you are
DEMANDING that the specified address be used, and if the other side
disagrees, your side will disconnect.
The part#3 is the netmask assigned on my side to the resulting
connection after we negotiate addresses. Links between two systems
made with Point to Point Protocol (ppp) are weird in comparison
to typical network links, and some operating systems do not have a
specific PointToPoint netmask in the network stack, so the netmask
must be faked. Using '0.0.0.0' as the part#3 netmask tells the ppp
program to use what is available and the result is ppp will
typically set the netmask to '255.255.255.255' automatically.
The part#4 is the trigger address which controls when ppp will try
to establish a connection. Since we set part#4 to the equivalent of
any address namely '0.0.0.0' any attempt to contact another
system will result in ppp automatically establishing the
connection. The thing to realize is 0.0.0.0 is roughly equivalent
to a default route.
The stuff you are doing is just plain wrong:
set ifaddr 0.0.0.0/0 0.0.0.0-255.255.255.254 0.0.0.0 0.0.0.0
part#1 part#2 part#3 part#4
Prior to negotiating address, you are saying your IP address will
initially be 0.0.0.0 and the remote IP address will also initially
be 0.0.0.0 The problem is, when two systems have the same IP
address you have a conflict. Additionally, since 0.0.0.0 equates to
the default route, this is very bad. Needless to say, the ppp(8)
software is compensating for your mistakes and doing the best it
can with your broken config.
In the second chunk of your part#1, namely '/0', this netmask says
that you will accept any IP address the other side wants you to
use. This is good.
In the second chunk of part#2, namely '-255.255.255.254' is using
the wrong syntax. The ppp(8) program might interpret this as a
range of addresses, or might interpret it as a pair of addresses,
or it might interpret it as a netmask. You should use simple CIDR
notation as described in the ppp man page.
If ppp(8) is interpreting this bad second chunk of part#2 as a
netmask, the you are *DEMANDING* that the remote system use 0.0.0.0
or 0.0.0.1 as its IP address, and if the remote side refuses to use
one of those two addresses, then you will disconnect.
jcr
I didn't get the importance of having different addresses in part#1
and #2 and assumed from 'ifconfig tun0' [ ... ] inet 95.124.11.167 --
10.0.0.2 netmask 0xfff [ ... ] that HISADDR did not change to a
valid one. I should have understood you were telling me the correct
syntax literally. I see that this configuration works and i understand
the syntax.
Sorry this took longer time than it should and thanks for following
through. I have found a great resource in 'Absolute OpenBSD: UNIX for
the Practical Paranoid' (ISBN 1886411999) and of course this was a
great first impression from this mailing list. I will try not to
abuse it. All the best to you
Heck, in my last two paragraphs I put part#3 instead of part#2
(corrected above) but you still understood it. ;)
The Absolute OpenBSD is good but parts of it are now outdated, but this
is to be expected.
As for ppp(8), the ppp.conf file gives you full control of a a fairly
complex Finite State Machine (FSM), so the man page is long and takes
some effort to understand. Once you know the basics, ppp(8) becomes
*REALLY* useful for debugging and monitoring connections.
There are still a few minor problems with your chat
Re:
On Mon, 24 May 2010 00:00:07 +0200 patrick kristensen kristensenpatri...@gmail.com wrote: I have managed to get a working connection with the following script /etc/ppp/ppp.conf default: set log Phase Chat LCP IPCP CCP tun command set device /dev/cuaU0 set speed 460800 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT esp: set device /dev/cuaU0 set speed 460800 set timeout 0 set dial ABORT BUSY TIMEOUT 5 \ \\ \ AT OK-AT-OK \ AT+CPIN=\\\7291\\\ OK-AT-OK \ AT+CFUN=1 OK-AT-OK \ AT+CGDCONT=1,\\\IP\\\,\\\movistar.es\\\ OK-AT-OK \ \\dATDT*99***1# TIMEOUT 30 CONNECT set ifaddr 0 81.47.192.13 255.255.255.255 add default HISADDR enable dns # ./. Setting 'set ifaddr to 0.0.0.0/0 0.0.0.0/0 255.255.255.255' gave me an ipadress to MYADDR but i did not get a route. Setting 'set ifaddr 0.0.0.0/0 194.179.1.100 (which was DNS) 255.255.255.255' made it possible to nslookup movistar.es. After nslookup the APN and hardcoding the ip to HISADDR i got a working connection. The APN (Movistar (Telefonica) Spain) is correct (http://www.vysoo.com/apn.php#415 and other sources). (I have not been able to find other data networks for movistar as with your example with Verizon) This setup works so far (i can ping external addresses). My understanding of ppp(8) is that it should have been enough to 'set ifaddr 0 0 255.255.255.255 (0)' and 'add default HISADDR' (if the CGDCONT is correct). I appreciate any input on the script and log. It seems your routing is hosed. As the ppp(8) manual states, if you use add it will not overwrite your default route (typically stored in /etc/mygate). When you want to overwrite the default route, you need to use add! such as: add! default HISADDR Typically, you want to overwrite the default route, but note, you'll probably see some harmless warnings for routes that ppp cannot overwrite (such as IPv6 when it's not supported by your provider). As for setting up the interface addresses, you should define all four parts, rather than defining only three as you have done above. set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 part#1 part#2 part#3 part#4 In your script above, your part#1 of 0 is *DEMANDING* that your address be 0.0.0.0/32 and nothing else, or in other words, you are *DEMANDING* that you become the default route for the remote system. Needless to say the remote system will just laugh at you and refuse to change it's default route (i.e. address your end as 0.0.0.0). Setting the netmask (part#3) to 0.0.0.0 forces ppp to assign an appropriate netmask. Since it is a point-to-point link and some operating systems/kernels do not understand a POINTTOPOINT netmask, you'll typically end up with 255.255.255.255 or 255.255.255.0 for the netmask of your tun0 interface *even* if the remote gateway address is outside of the netmask. Using part#4 is important. This the address you *SUGGEST* that your side should be, but you *DEMAND* your side gets and address defined by part#1 (the /0 netmask on part#1 says any IP address). Additionally, part#4 is also the trigger address when using '-auto' mode to connect or reconnect. Lastly, there's no point in defining 'device' 'speed' and 'dial' in the default: section of your config file since you are redefining them in the esp: section. Once you have the above corrected, look at your CHAP settings. Though you were able to negotiate IP addresses (according to the log), it seems your provider wanted to use CHAP authentication. If you made the previous corrections and you still cannot connect, then you may need to use CHAP: set authname myusername set authkey mypassword set login Not all providers require PAP/CHAP authentication through 'authname' 'authkey' and 'login' because the real authentication is being done by device identifiers (MEID and/or IMEI). jcr -- The OpenBSD Journal - http://www.undeadly.org
Re:
On Sat, 22 May 2010 22:08:57 +0200 patrick kristensen kristensenpatri...@gmail.com wrote: Thanks for taking the time to answer and your fast replies. Actually, ppp and TDMA/CDMA are nice break from the other headaches I've been trying to solve. ;) First of all, you either haven't mentioned the name of your service provider, or I forgot what it was. Either way, it matters. From what I can tell, you're in Spain, and I'm not familiar with the providers there. Ted Roby recently posted his config for Virgin Mobile: http://marc.info/?l=openbsd-techm=127285929411780w=2 The above may not help, but it's nice to see working examples. In absence of cdce (using ue0 as ethernet interface (and minicom) to connect to isp) i have tried several ppp and pppd configurations to get a working internet connection on -release with no success. The following is my ppp (# ppp -auto movistar) and pppd (# pppd call movistar) attempts. Since pppd(8) is in the kernel, it can be faster, but since ppp(8) is in userland, it can be much easier to work with when figuring things out. Once you figure out how to make things work with ppp(8), you can easily write a new config for pppd(8). /etc/ppp/ppp.conf (appended to ppp.conf.sample) movistar: set device /dev/cuaU0 set speed 460800 set timeout 0 set dial ABORT BUSY TIMEOUT 5 \ \\ \ AT OK-AT-OK \ AT+CFUN=1 OK-AT-OK \ AT+CPIN? +CPIN:\\sREADY-AT+CPIN\\\\\\-OK \ The above looks wrong. Not all wireless service providers and not all cellular wireless devices require using the Personal Identification Number (PIN) when making a connection. And worse, the responses you can get varies from device to device. (see below) Also, it is unwise to post your PIN to a public mailing list. It's not too dangerous without the IMEI and MEID device, but it's still not a good idea. AT+CGDCONT=1,\\\IP\\\,\\\movistar.es\\\ OK \ The above is most likely wrong. The AT+CGDCONT= command sets the primary CONText of the device and the network it is attaching to. The first value argument states whether or not the device can be reconfigured (1), or cannot be reconfigured (3). The second argument is a string which defines the protocol used on the network. The third argument is also a string and it defines the Packet Data Network (PDN) name or Access Point Name (APN). As far as I know movistar.es is not the proper name of any Packet Data Network (PDN) or Access Point Name (APN). For example Virgin Mobile uses VDATA as the APN/PDN name, while AirTel uses airtelgprs.com as the name and of course, what your provider uses is unknown. You need to be careful with this setting since many providers have multiple data networks. With Verizon here in the silicon valley, I can choose from three different data networks (actually four if you count EVDO Rel. 0 as a different network than EVDO Rev. A). ATDT*99***1# The above is wrong because it has no timeout or 'CONNECT'. Also, you should have noticed the leading double quote () which is prematurely ending your chat script *BEFORE* the required number is dialed. The above should be: \\dATDT*99***1# TIMEOUT 30 CONNECT The leading \\d gives a two second delay before calling. It may or may not be necessary with your hardware/provider. set mtu maximum 750 The above is most likely wrong. resolv rewrite The above is often unnecessary to get things working, but rewriting /etc/resolv.conf is mostly a matter of personal choice/needs. The command you have below, namely `enable dns` should suffice. set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0. add default HISADDR enable dns # ./. /var/log/ppp.log May 22 17:57:51 x200s ppp[8742]: Phase: Using interface: tun0 May 22 17:57:51 x200s ppp[8742]: Phase: deflink: Created in closed state May 22 17:57:51 x200s ppp[8742]: tun0: Command: default: set device /dev/cuaU0 May 22 17:57:51 x200s ppp[8742]: tun0: Command: default: set speed 460800 May 22 17:57:51 x200s ppp[8742]: tun0: Command: default: set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: set device /dev/cuaU0 May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: set speed 460800 May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: set timeout 0 May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: set dial ABORT BUSY TIMEOUT 5 AT OK-AT-OK AT +CFUN=1 OK-AT-OK AT+CPIN? +CPIN:\\sREADY-AT+CPIN\\7291\\-OK AT +CGDCONT=1,\\IP\\,\\movistar.es\\ OK ATDT*99***1# May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: set mtu maximum 750 May 22 17:57:51 x200s ppp[8742]: tun0: Command: movistar: resolv rewrite May 22 17:57:51 x200s ppp[8742]: tun0: IPCP: Primary nameserver set to 255.255.255.255 May 22
www.openbsd cvsweb off by 1 hour
On Mon, 17 May 2010 23:14:17 -0600 (MDT) David Coppa
Date: Mon, 17 May 2010 23:14:17 -0600 (MDT)
From: David Coppa dco...@! cvs.openbsd.org
CVSROOT: /cvs
Module name: ports
Changes by: dco...@! cvs.openbsd.org2010/05/17 23:14:17
Modified files:
x11/mplayer: Makefile
x11/mplayer/files: README.OpenBSD
Log message:
mention x11/smplayer in README.OpenBSD
OK edd@, sthen@
--
The above commit log shows the local time for dcoppa@, and when adjusted
to UTC, it's correct.
--
# cd /usr/ports/x11/mplayer
# cvs diff -u -r 1.163 -r 1.164 Makefile
Index: Makefile
===
RCS file: /cvs/ports/x11/mplayer/Makefile,v
retrieving revision 1.163
retrieving revision 1.164
diff -u -r1.163 -r1.164
--- Makefile23 Feb 2010 19:59:13 - 1.163
+++ Makefile18 May 2010 05:14:17 - 1.164
@@ -1,4 +1,4 @@
-# $OpenBSD: Makefile,v 1.163 2010/02/23 19:59:13 phessler Exp $
+# $OpenBSD: Makefile,v 1.164 2010/05/18 05:14:17 dcoppa Exp $
# May not be hard to add more.
ONLY_FOR_ARCHS=amd64 i386 powerpc sparc64 arm mips64 mips64el
@@ -10,7 +10,7 @@
V= 20090708
N= mplayer
DISTNAME= mplayer-export-snapshot-${V}
-PKGNAME= ${N}-${V}p4
+PKGNAME= ${N}-${V}p5
CATEGORIES=x11 multimedia
EXTRACT_SUFX= .tar.bz2
--
cvs gives me the correct date/time in UTC format.
--
http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/mplayer/Makefile
Revision 1.164: download - view: text, markup, annotated - select for diffs
Tue May 18 05:14:17 2010 UTC (3 days, 3 hours ago) by dcoppa
--
The cvsweb listing of revisions gives the correct date/time
But using diff to previous ...
--
http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/mplayer/Makefile.diff?r1=1.163;r2=1.164
--- ports/x11/mplayer/Makefile 2010/02/23 19:59:13 1.163
+++ ports/x11/mplayer/Makefile 2010/05/18 06:14:17 1.164
@@ -1,4 +1,4 @@
-# $OpenBSD: Makefile,v 1.163 2010/02/23 19:59:13 phessler Exp $
+# $OpenBSD: Makefile,v 1.164 2010/05/18 05:14:17 dcoppa Exp $
# May not be hard to add more.
ONLY_FOR_ARCHS=amd64 i386 powerpc sparc64 arm mips64 mips64el
@@ -10,7 +10,7 @@
COMMENT= movie player supporting MPEG, DivX, AVI, ASF
V= 20090708
N= mplayer
DISTNAME= mplayer-export-snapshot-${V}
-PKGNAME= ${N}-${V}p4
+PKGNAME= ${N}-${V}p5
CATEGORIES=x11 multimedia
EXTRACT_SUFX= .tar.bz2
--
The second line of the above shows a date 1 hour ahead. This is consistent
regardless of which diff you look at.
It may not matter, but couldn't find anything on it in the archives, and
it doesn't hurt to ask.
jcr
--
The OpenBSD Journal - http://www.undeadly.org
Re: Is that Theo showing of his server rack again on the OBSD home page ?
On Fri, 21 May 2010 12:02:53 +0200 Christer Solskogen christer.solsko...@gmail.com wrote: Just a wild guess, but what about primary (.p) and slave (.s)? There are at least two build machines for each supported arch, one for src and the other for ports. If you want to see a new arch supported, then you donate at least two machines to Theo's basement, plus donate whatever additional machines are needed for interested developers. Machines are always needed: http://www.openbsd.org/want.html Considering the massive volume of work the machines do and the cost/value of developer time, they should be as fast as feasible. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Resilient RAID
On Fri, 21 May 2010 10:13:33 -0700 Siju George sgeorge...@gmail.com wrote: On Fri, May 21, 2010 at 7:11 AM, Marco Peereboom sl...@peereboom.us wrote USB sticks primary cause of death is the washing machine and/or dryer. Second one probably is sitting out in the sun. I have yet to see the USB stick that dies because it was written to. A bit confusing :-( http://www.mail-archive.com/us...@crater.dragonflybsd.org/msg08923.html thanks --Siju It's mornings like this when I wonder why I bother to chew through the restraints. (sigh) This stuff is neither difficult nor confusing if you take the time to learn *just* the basics of how things actually work. 1.) How is data stored? (sectors? pages? ...) 2.) What is a Partial Storage Failure? (including Bad Sectors and Write Exhaustion and similar)? 3.) What is Storage Allocation (i.e. internally to the disk/device)? 4.) What is Remapping? 5.) What is Wear Leveling? Start with understanding rotating, magnetic hard disk storage, and then figure out the equivalents for flash based storage. -- The OpenBSD Journal - http://www.undeadly.org
Re:
On Thu, 20 May 2010 23:17:25 +0200 patrick kristensen kristensenpatri...@gmail.com wrote: 2010/5/17 J.C. Roberts list-...@designtools.org: On Fri, 14 May 2010 17:11:16 +0200 patrick kristensen kristensenpatri...@gmail.com wrote: Hi I have 4.6-RELEASE on a lenovo x200s system with Ericsson F3507g Mobile Broadband Module installed (mini-pci express wwan adapter). On FreeBSD the device is detected by the cdce(4) driver which creates an ue0 ethernet interface. On 4.6-RELEASE install this does not happen. The cdce(4) appeared in openBSD 4.1 and following the changelog from 4.1 to -current, cdce(4) should be in generic. Do I need to modload anything for cdce to load? It seems you forgot to post your dmesg and the output of `usbdevs -vd` -- The OpenBSD Journal - http://www.undeadly.org I have upgraded to 4.7-release and later 4.7-current but cdce does not load. The output from dmesg and usbdevs for -release and -current is: ... OpenBSD 4.7-current (GENERIC.MP) #229: Wed May 12 02:02:27 MDT 2010 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP ... umodem0 at uhub1 port 4 configuration 1 interface 1 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 2 umodem0: data interface 2, has CM over data, has break umodem0: status change notification available ucom0 at umodem0 umodem1 at uhub1 port 4 configuration 1 interface 3 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 2 umodem1: data interface 4, has CM over data, has break umodem1: status change notification available ucom1 at umodem1 umodem2 at uhub1 port 4 configuration 1 interface 9 Ericsson Ericsson F3507g Mobile Broadband Minicard Composite Device rev 2.00/0.00 addr 2 umodem2: data interface 12, has CM over data, has break umodem2: no data interface ... usbdevs -vd (4.7-current) ... Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 uhub1 port 1 powered port 2 powered port 3 powered port 4 addr 2: high speed, power 20 mA, config 1, Ericsson F3507g Mobile Broadband Minicard Composite Device(0x1900), Ericsson(0x0bdb), rev 0.00, iSerialNumber 3541430209963360 umodem0 umodem1 umodem2 port 5 powered port 6 powered Though I have and have read the mostly useless marketing material touting the features of the Erricsson F3507g, I haven't been able to find any real specs. It seems to be very similar feature-wise to the Qalcomm Gobi-1000 and Gobi-2000 (MDM1000 and MDM2000 chipsets), but I am yet to find any claim that the Erricson F3507g uses Qaulcom parts, or for that matter, uses Qualcomm logic cores. It doesn't matter all that much since the above tells me the device is most likely usable in OpenBSD as is. Two of the three umodem(4) have serial ports attached (ucom(4)) so all you need to do is configure ppp(8) or pppd(8) to talk to one of those serial ports (/dev/cuaU?). You should probably read the umsm(4) for more info and an example chat script. A lot of similar EVDO/HSPA devices are built in the same way in the sense of providing more than one serial port, but only one of them is usable with ppp/pppd. The other supposed serial port speaks a proprietary protocol and is used for management purposes. Typically, the proprietary protocol is either Qualcomm QMI or Qualcomm DM. Due to various leaks (read: google android), portions of the proprietary protocol have been figured out by the linux camp, but it's still a work in progress. Some details were posted here: http://blogs.gnome.org/dcbw/2010/04/ jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Some secure way of updating sources?
On Wed, 19 May 2010 16:18:53 +0800 QIU Quan jac...@gmail.com wrote: On Wed, May 19, 2010 at 15:52, Martin SchrC6der mar...@oneiros.de wrote: Qiu: AFAIK no. Well, I see. Thank you! And thanks for all that answered. Have a nice day! :-) First of all you need to realize SSL is not as cool or secure as you seem to think it is. There are many applications which fail to do proper revocation and/or authority checks, but even if all applications were perfect, you'd still face the issue of, Why trust the cert authorities? Anyhow, if you insist... 1.) Get a free shell account at https://devio.us 2.) Access your devio.us account over ssh. 3.) Use lynx to read html page with the ssh keys for the anoncvs servers. 4.) Manually chech the ssh keys of the anoncvs servers before adding them to your ~/.ssh/known_hosts Also, check out the StrictHostKeyChecking option of ssh. We had an article on undeadly.org recently about the new free shell provider at http://devio.us -- The OpenBSD Journal - http://www.undeadly.org
Re: 4.7 off the FTP, Should I wait to install?
On Wed, 19 May 2010 12:54:56 -0500 Don Reis reisd...@gmail.com wrote: The 4.7 directory on ftp.openbsd.org just disappeared after I downloaded install47.iso. Should I wait to do my fresh install? Anyone know what's going on? i.e., are changes being made that will necessitate another download and install? Why aren't you using a mirror as suggested? The main site is probably being hammered by people who are too lazy to look up and use a local mirror. http://www.OpenBSD.org/ftp.html jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: 4.7 off the FTP, Should I wait to install?
On Wed, 19 May 2010 13:17:50 -0500 dontek don...@gmail.com wrote: I hit three different mirrors in my area and they all either didn't have 4.7 yet or I got access denied, so I went to the main... http://spacehopper.org/up2date.html -- The OpenBSD Journal - http://www.undeadly.org
Re: Openbsd 4.6 bash and email notification
On Tue, 18 May 2010 22:45:27 +0200 Hect tagah...@email.it wrote: I can't get to disable email notification with bash. You know the message that says You have new mail in /var/mail/user. I tried, as bash manual says, to add variable MAILPATH to profile but doesn't do the job. There's no biff in ps command output, anyway i tried also with biff n. no way. Can anybody help me? Thanks a lot Hect $ man comsat $ man inetd $ man inetd.conf -- The OpenBSD Journal - http://www.undeadly.org
Re:
On Fri, 14 May 2010 17:11:16 +0200 patrick kristensen kristensenpatri...@gmail.com wrote: Hi I have 4.6-RELEASE on a lenovo x200s system with Ericsson F3507g Mobile Broadband Module installed (mini-pci express wwan adapter). On FreeBSD the device is detected by the cdce(4) driver which creates an ue0 ethernet interface. On 4.6-RELEASE install this does not happen. The cdce(4) appeared in openBSD 4.1 and following the changelog from 4.1 to -current, cdce(4) should be in generic. Do I need to modload anything for cdce to load? It seems you forgot to post your dmesg and the output of `usbdevs -vd` -- The OpenBSD Journal - http://www.undeadly.org
Re: pf change in upgrade47.html
On Wed, 12 May 2010 21:28:03 +1000 Rod Whitworth glis...@witworx.com wrote: Have you actually written and tested a ruleset using either of those documents? If so please show us. Particularly seeing I referenced both of those in my original post as not being helpful and I've been trying to get somebody - anybody - to write a minimal NAT ruleset and show me. Creating a minimal rule set for a firewall doing NAT is very simple; basically, it's a one-liner 'match' rule, but with 4.7-RELEASE/STABLE you should be more verbose if you're using ppp(8) and possibly pppd(8), and create the typical interface-based rules. - # $OpenBSD: pf.conf,v 1.49 2009/09/17 06:39:03 jmc Exp $ # # See pf.conf(5) for syntax and examples. # Remember to set net.inet.ip.forwarding=1 and/or net.inet6.ip6.forwarding=1 # in /etc/sysctl.conf if packets are to be forwarded between interfaces. ext_if = tun0 int_if = xl0 set skip on lo # set block-policy drop # default block block in log all # block log quick inet6 # filter rules and anchor for ftp-proxy(8) # anchor ftp-proxy/* # pass in log on $int_if proto tcp to port ftp rdr-to 127.0.0.1 port 8021 # anchor for relayd(8) # anchor relayd/* # nat for local network match out on $ext_if from ($int_if:network) nat-to ($ext_if:0) pass in on $int_if pass out on $ext_if # rules for spamd(8) #table spamd-white persist #table nospamd persist file /etc/mail/nospamd #pass in on egress proto tcp from any to any port smtp \ #rdr-to 127.0.0.1 port spamd #pass in on egress proto tcp from nospamd to any port smtp #pass in log on egress proto tcp from spamd-white to any port smtp #pass out log on egress proto tcp to any port smtp #block in quick from urpf-failed to any # use with care # By default, do not permit remote connections to X11 block in on ! lo0 proto tcp to port 6000:6010 - NOTE: I don't know enough about interface groups or how they work with pf, and I'm still testing and learning, so my advice is *VERY* dodgy. ;) One of the issues is not well stated, namely, the improvements in pf ruleset syntax have a goal of simplification such as hardware-independent rules. This is being accomplished by using interface groups as noted in ifconfig(8). You'll note how the default pf.conf ruleset *intentionally* avoids using the previously typical hardware-dependent syntax such as defining 'ext_if' and 'int_if' then using them in the rules. The more complex hardware-dependent syntax still works fine if used (as above), and providing an example might be useful for the short term. Long term, it is better to use hardware-independent rules. The previously mentioned one-liner would simply be: match out on egress from ! egress nat-to egress Though the above *mostly* works, the trouble is, 'egress' is actually a *GROUP* of interfaces, so what pf is really doing is less than crystal clear unless you've worked with it a bit. I don't know how well the above one-liner works on 4.7-RELEASE/STABLE but I *just* started testing it on -CURRENt with a rather unstable ppp connection (via umodem EVDO/Verizon). With -CURRENT I've found one bug with using 'egress' NAT and it seems to be due to the tun0 interface being destroyed and recreated by ppp(8) so pf loses track of the (only) 'egress' interface. Manually reloading the pf ruleset after ppp(8) recreates the tun0 interface and reestablishes the connection, fixes the problem, so I could easily put the pf reload in /etc/ppp/ppp.linkup to solve the problem. Since manually reloading pf rules is not necessary when using the full interface-based ruleset above, it also should not be necessary when using a hardware independent group-based ruleset (i.e. with 'egress'). I haven't gotten to testing how pppd(8) behaves, but the 'egress group bug' might be there as well. NOTE: I just discovered the above bug a few minutes ago, but the -CURRENT on that box is stale (Mar9) so I'll update and retest to see if it's already fixed before filing a PR. None the less, it might also exist in 4.7-RELEASE or 4.7-STABLE and I'll try to get that tested as well. I don't have RELEASE installed anywhere, so I'll have to build up a new box. Luckily, my 4.7 set was pre-ordered and is sitting right next to me. Ya, our new super-simple-syntax seems to have a show stopper bug on release because you, me, and everyone else, have failed to do adequate testing. -- The OpenBSD Journal - http://www.undeadly.org
Re: pf change in upgrade47.html
On Wed, 12 May 2010 07:46:59 -0700 J.C. Roberts list-...@designtools.org wrote: Long term, it is better to use hardware-independent rules. The previously mentioned one-liner would simply be: match out on egress from ! egress nat-to egress Though the above *mostly* works It seems the ppp issue is because I botched the syntax. It should be: match out on egress from !(egress) nat-to (egress:0) Now I need to figure out why... -- The OpenBSD Journal - http://www.undeadly.org
Re: X exiting after update (inteldrm error)
On Wed, 12 May 2010 02:28:36 -0300 Alan R. S. Bueno alan@gmail.com wrote: I'm not sure if misc@ is the right place to send this... After update kernel + userland + X (yesterday, in the morning (here in Brazil)... but with all the latest relevant changes in the trees src/ and xenocara/ applied), X exited (today, tonight, here in Brazil... yeah! :) with the following error: Both INTELDRM_GEM kernel and the corresponding new X intel driver were recently committed. Due to mirrors being out of sync, your cvs update may have only caught a portion of the needed changes. You should try again with cvs update of src and xenocara. Though not entirely relevant, you might also want to note: http://www.openbsd.org/faq/current.html#20100510 jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: X exiting after update (inteldrm error)
On Wed, 12 May 2010 17:20:28 -0300 Alan R. S. Bueno alan@gmail.com wrote: On Wed, May 12, 2010 at 3:41 PM, J.C. Roberts list-...@designtools.org wrote: Both INTELDRM_GEM kernel and the corresponding new X intel driver were recently committed. Due to mirrors being out of sync, your cvs update may have only caught a portion of the needed changes. You should try again with cvs update of src and xenocara. No. The latest change that my cvs update caught was: http://marc.info/?l=openbsd-cvsm=127357649215000w=2 After that change, no *relevant* change was made (neither in src/ nor xenocara/) that can be the cause of the error; so, cvs update now is irrelevant. If you are subscribed to source-changes@, check the latest changes; if not, check here: I think you're right about the *relevant* changes since the intagp stuff committed today seems to be for pineview from the commit logs. Today my machine froze again in the same condictions. (I had to use the power button.) :-( Bummer. I've been testing the new intel driver (with GEM) for a few weeks and it still has a few bugs with old 82845G. In my case, the screen gets corrupted, but X doesn't actually crash. This happens repeatably when switching to/from virtual terminals, and happens occasionally when flipping between xterms and gtk-based apps in X. Of course, once it's corrupted, a subsequent VT switch will crash X, but the corruption alone does not. The best thing you can do is enable DRM Debug in the kernel and try to get a core dump. $ cat /usr/src/sys/conf/GENERIC | grep DEBUG= makeoptions DEBUG=-g # compile full symbol table $ cat /usr/src/sys/arch/i386/conf/GENERIC_DRMDEBUG include arch/i386/conf/GENERIC option DRMDEBUG option DRMLOCKDEBUG And then follow the instructions in xenocara/README for how to set up and run the system to get a core file. -- The OpenBSD Journal - http://www.undeadly.org
Re: pf change in upgrade47.html
On Wed, 12 May 2010 20:18:14 + (UTC) Stuart Henderson s...@spacehopper.org wrote: I don't think that line is complete, is it? that one's okay. $ echo 'pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021' | pfctl -nvf - pass in quick inet proto tcp from any to any port = ftp flags S/SA keep state rdr-to 127.0.0.1 port 8021 It's valid, but if uncommented in the default pf.conf ruleset, it would allow anyone to use your ftp-proxy due to the following 'pass' rule. http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.conf?rev=1.49;content-type=text%2Fplain It would be better to prevent such potential abuse by using the egress interface group. The trouble is the 'on ...' will not allow the use of parenthesis since it's denoting a group of interfaces rather than a group of addresses assigned to interfaces. But this is easily overcome by using 'from (...)' so when the underlying address(es) change on any interface in the group, the rule will reevaluated. NOTE: At present, I don't understand how pf reacts when interface groups are changed (interfaces added or deleted). Index: pf.conf === RCS file: /cvs/src/etc/pf.conf,v retrieving revision 1.49 diff -N -u -p pf.conf --- pf.conf 17 Sep 2009 06:39:03 - 1.49 +++ pf.conf 12 May 2010 22:25:59 - @@ -8,7 +8,8 @@ set skip on lo # filter rules and anchor for ftp-proxy(8) #anchor ftp-proxy/* -#pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021 +#pass in quick on !egress proto tcp from !(egress) to port ftp \ +# rdr-to 127.0.0.1 port 8021 # anchor for relayd(8) #anchor relayd/*
Re: pf change in upgrade47.html
On Thu, 13 May 2010 09:45:47 +1000 Rod Whitworth glis...@witworx.com wrote: What is wrong with the old rule: rdr pass on $int_if proto tcp to port ftp - 127.0.0.1 port 8021 being converted to: pass in quick on $int_if proto tcp to port ftp rdr-to 127.0.0.1 port 8021 put in a location above any other rule applying to $inf_if ?? The reason I queried whether the 4.7 construct was correct is that it applies to traffic from any to any. Even my suggested rule would not be universal. Maybe there's an ftp server on the LAN. Yep, the 'pass in quick' with 'any to any' in the default pf.conf ruleset is bad juju, and hence the patch I posted. If deemed acceptable and committed, I'll patch update47.html accordingly. But to answer your question, the interface names such as int_if were intentionally removed since we can now create hardware independent rulesets by using interface groups. If you're overly accustomed to using interface names like '$int_if' it takes a bit to wrap your head around the new interface groups, but they're really cool. -- The OpenBSD Journal - http://www.undeadly.org
Re: SAS RAID Controller of SunFire X4150 causes trouble
On Fri, 7 May 2010 09:35:06 + (UTC) Stuart Henderson s...@spacehopper.org wrote: On 2010-05-06, Schafhauser, Florian fschafhau...@arri.de wrote: Hello, the RAID Controller causes trouble with OpenBSD 4.5 and 4.6. First off, for mpi(4) you want one of these patches: ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.5/common/015_mpi.patch ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/009_mpi.patch ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.7/common/002_mpi.patch Also, if you decide to run -current to get all the newest mpi goodness, the following was committed just a few hours ago: On Sun, 9 May 2010 16:03:57 -0600 (MDT) David Gwynne dlg cvs.openbsd.org wrote: CVSROOT: /cvs Module name: src Changes by: dlg cvs.openbsd.org 2010/05/09 16:03:57 Modified files: sys/dev/ic : mpi.c Log message: back out 1.143, it causes data corruption on the mpis in sun v20z boxes, but i suspect it is common to all SPI mpi parts. problem found and problem diff verified by landry. ok krw@ landry@ jasper@ I'm not sure when this will hit snapshots, but if you have a snap between Apr 19 and now, then you should wait until a new snapshot has been created including the above, or build your own. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Java 1.6 thinkorswim from TDAmeritrade
On Thu, 6 May 2010 17:42:32 -0700 Marcel Dan marcel...@nwvd.org wrote: I'm running i386 4.7 current (as of last week) with jdk 1.6 installed from cvs/ports. I found the error. 06.05.10 17:24:22 ERROR util.PerformanceMonitor - Error creating snapshot: java.lang.UnsupportedOperationException: Thread CPU Time Measurement is not supported. at sun.management.ThreadImpl.getThreadCpuTime(ThreadImpl.java:196) at com.devexperts.tos.util.JvmStateSnapshot.getCurrentCpuTimes (JvmStateSnapshot.java:45) at com.devexperts.tos.ui.user.util.PerformanceMonitor.createSnapshot (PerformanceMonitor.java:292) at com.devexperts.tos.ui.user.util.PerformanceMonitor.run (PerformanceMonitor.java:495) I will keep working on it and post any successful results. You should report this upstream to ToS, but ya, wait until next week since they'll be hellishly busy with the crash/rectification. Though previously ToS made false claims about supported java versions, now they don't make any claims at all. Just Lovely. I only found one outstanding and confirmed bug in the specific class mentioned in your error message: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6933325 It may, or may not, be related to your problem, but the bug report does mention authentication. As reported, the above bug effects 1.5 and 1.6, (specifically jdk-1.6.0_18-b07) but there's no mention if the bug is in the current jdk-1.6.0_21, or if it is present in the current openjdk-6-src-b19 (not in ports, but openjdk is a different beast than jdk). If the problem is caused by a bug in java itself like the one above, then you're totally hosed. Our jdk 1.6 version in ports is jdk-1.6.0_03-b05 from Sep 2007, so it's a few years old but according to the infamous marketing claims of their right once, ruin everywhere motto, it should work. Our openjdk 1.7 port *might* work for you (i386 or amd64), but realize 1.7 is a work in progress and Kurt Miller (kurt@) had to put a ton of effort into openjdk 1.7 to make it run. The easy way to look at is, the jdk-1.6 port has 22 patches and the openjdk-1.7 port has 308 patches. I just started building 1.6 from ports on -current to look at this a bit deeper, but my initial guess is the version we have in the ports tree is too old for something fancy they're trying to do. -- The OpenBSD Journal - http://www.undeadly.org
Re: USB Controller Causing Issues
On Fri, 7 May 2010 13:21:39 -0700 Ben Niccum be...@bendtel.com wrote: Also, is there a setting for USB mode in the BIOS? Sometimes listed as USB Drive emulation, or similar. There is a USB Emulation mode. If I turn USB Emulation off, then all the problems of the USB drives freezing the system go away, but it still leaves me with the first issue of the bootable device. Without USB emulation on, it actually won't boot from any USB devices. It often depends on the *type* of emulation, and sometimes the USB Emulation/Mode setting must be used in conjunction with specific boot device settings. Depending on vendor, the USB Emulation Mode can be set to silly names like Auto or Removable or HDD or FDD or Floppy or whatever. With some systems, when set to Auto USB flash drives that are less than 530 MB in size are automatically emulated as floppy disk drives, while USB flash drives larger than 530 MB in size will be treated like hard disk drives. Needless to say, the 530 MB cut-off can vary depending on vendor/chipset/whatever, but however it's done, it can cause a whole lot of headaches. Your emulation mode seems to be stuck on Auto without any way to change it that I've found. In your case, the USB Emulation mentioned in your BIOS settings is basically *misnamed* since this setting actually defines Legacy Mode for all attached USB devices. It seems VIA defines legacy mode as supporting legacy (read: ancient) USB keyboard, mouse and storage devices under DOS, but what they actually mean by this statement is a bit vague. Typically when support for Legacy Mode is On you can support ancient USB devices that barf when used with newer modes, but in doing so, you can be causing problems for newer (USB v1.1 and above) devices, such as the newer bootable USB sticks you're probably trying to use. ;) Unless you have a damn good reason to force *ALL* USB devices to use legacy mode, you should probably have this turned Off --If you're using an ancient keyboard or mouse that *requires* legacy mode to work properly, then try use the KB/MS setting. Some systems and some USB devices refuse to be bootable or refuse to be treated as disks when used in the ancient Legacy Mode since booting to USB, and even USB storage itself, were invented long after USB was first created. --My comprehension of early/ancient USB devices kinda sucks because they were first released, I did everything I possibly could to avoid them... To this day there are still unresolved problems when using USB keyboards with debuggers. As for the obvious question of, WTF Is Legacy Mode? sadly, there is no single universal answer since it varies depending on chipset, implementation and vendor whims. The closest thing to an answer you'll find is, Legacy Mode forces modern USB to work with ancient USB devices, but the details of how? are a mystery. It might be crippling the EHCI logic core (or chip), or it may be disabling some unknown portion of EHCI, or it may be forcing the UHCI logic core (chip) to behave in certain ways, or any combination thereof. Considering where you put the It Dies Here note in your posted dmesg (thanks) and your subsequent successful boots with USB Emulation set to Off, it seems Legacy Mode is at least part of your problem, if not the entire problem. On Fri, 7 May 2010 13:57:32 -0700 Ben Niccum be...@bendtel.com wrote: On Fri, 7 May 2010 22:06:57 +0200 Tobias Ulmer tobi...@tmux.org wrote: Try setting Plug and play OS in the BIOS to yes. I was unable to find such a setting in the BIOS. You obviously did not even bother to check... RTFM! (And I wonder why I bothered when you didn't?) See page #51 of the VB7001 User Manual (PNP == Plug and Play) http://www.via.com.tw/servlet/downloadSvl?id=490download_file_id=3693 If the manual is showing the default state (No), then it's wrong. You should set it to Yes and you should also enable Reset Configuration Data if you change hardware around. Keep in mind there are two places in the system BIOS settings where you control boot device selection. The first handles the typical stuff, namely specific types of devices, specific devices, or specific sets of devices. The second is where you define the priority of sets of devices such as all the hard drive devices (including USB-HDD == USB Hard Disk Drive == your USB stick). With the BIOS on some x86 systems, you need to have the USB storage device attached when you power up the system and change the BIOS settings or else the options for booting to USB are either disabled, or worse, not even visible in the BIOS. There are even some systems out there that have absolutely no mention of being able to boot to USB devices, but can still boot to them if you select the correct, but painfully vague, setting typically named something like Removable or similar. --In your case, you need to make sure to have USB-HDD0 through whatever (USB-HDD3?) in your Hard Disk set. Similar to the above, you may need to set Reset Configuration
Re: Java 1.6 thinkorswim from TDAmeritrade
On Wed, 5 May 2010 20:27:33 -0700 Marcel Dan marcel...@nwvd.org wrote: Hi, I have been unable to get thinkorswim connected to the TDAmeritrade server on OpenBSD. Has anyone used thinkorswim from TDAmeritrade on OpenBSD? thanks, Marcel You need to provide more information. What *exactly* are you trying to do, how are you trying to do it, what is your configuration, and what if any error messages do you get in your xterm? It's been a few years (2007), but yes, I had ThinkOrSwim running on OpenBSD at one point in time. It was only running with a demo account, so I doubt TDAmeritrade was involved, but I'm not certain (e.g. TDAmeritrade *might* have been the source of the quote streams for demo accounts, but I really don't know for certain). If you're not running from a xterm, you should be. $ cd /place/where/tos/is/installed $ java -jar launcher.jar If you want more debug info: $ java -debug -jar launcher.jar Though the above should get you the vast majority of status/error messages, you should also keep an eye on the output of your console (VT1). You'll need the typical java settings in your environment (or in your ~/.kshrc). You'll need to ln(1) whatever java version you're using to /usr/local/java and /usr/lcoal/share/java if you have multiple versions of java installed, as well as set up your classpath. A little shell script can handle it: # Java Stuff export JAVA_HOME=/usr/local/java CLASSPATH=./ CLASSPATH=$CLASSPATH:$JAVA_HOME/jre/lib CLASSPATH=$CLASSPATH:$JAVA_HOME/lib CLASSPATH=$CLASSPATH:$JAVA_HOME/jre/lib/rt.jar CLASSPATH=$CLASSPATH:/usr/local/share/java/classes export CLASSPATH export PATH=$PATH:$JAVA_HOME/jre/bin In 2007 the ThinkOrSwim folks liked to claim compatibility with ancient java versions (e.g. v1.1), but they really don't do proper testing to make sure their claims are accurate. From my testing in 2007, at least Java 1.5 was actually required. My notes also mention needing to run $ touch thinkorswim.lax in the ./TOS/ directory to get rid of an error message on startup since the file was not created by default. This bug was reported, but I'm not sure if it was ever fixed. NOTE: Though TOS ran fine for me with a demo account, things have undoubtedly changed in their software since 2007. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: pcmcia serial card sometimes recognized, sometimes not
On Wed, 5 May 2010 12:01:59 -0500 Ted Wynnychenko ted@comcast.net wrote: Hello: I am trying to understand why this is happening. I have an older laptop and a new old pcmcia serial interface card (Quatech Inc, RS-232 Serial Port PC Card, SSP-100). So, when I first booted the 4.6 stable image with the pcmcia card in the slot, it would not recognize it (com3 at pcmcia0 function 0: can't allocate i/o space). Then, I did a bunch of searching, and eventually, figured out how to change the i/o memory space for pcic0 using config; and, it worked. But then, then next day, it didn't (I booted the modified kernel, but again got the same i/o space error). So, I played with config some more, disable com0,1,2,3; played with the settings for i/o address and size; and eventually, it worked again. But, again, the next day, it went unrecognized. So, I played with config some more, changed i/o address/size, made a new pcmcia com0, disabled pcic1,2, and maybe something more, and got it to work. Are you modifying your kernel with `# config /bsd` or are you booting into UKC and configuring the kernel there? http://www.openbsd.org/faq/faq5.html#BootConfig If you don't make the changes permanent, then every time you reboot you'll have the same problem. Is the system BIOS up to date? Does the BIOS have any way to allocate/reserve resources? (namely the mem/irq for the PCMCIA serial port/card). Dose the BIOS have any mention of on-board serial port configuration? (Systems that don't provide serial ports often still have internal serial ports which are/were used for debugging by the mfg. Hence you could have a conflict with an internal/hidden serial port that doesn't seem to exist.) jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: State of multiprocessing and multithreading in OpenBSD
On Thu, 6 May 2010 20:28:31 -0500 Ed Ahlsen-Girard eagir...@cox.net wrote: From: Noah Pugsley noah.p () bendtel ! com Date: 2010-05-06 17:03:28 Tony Abernethy wrote: Stas Miasnikou wrote: Marco Peereboom wrote: Wouldn't it be adorable if people learned to program FSMs instead of java in those fancy universities? Seconded. Do you seriously expect programmers to learn to program? Finite Sex Machine? James Brown would never tolerate a *Finite* sex machine. Bit Up. Bit On Up -- The OpenBSD Journal - http://www.undeadly.org
Re: Serial port programming problems
On Sun, 2 May 2010 16:45:44 +0100 Neil O'Brien nsob...@googlemail.com wrote: On Sun, May 02, 2010 at 20:56:36 +1000, Aaron Mason wrote: On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien nsob...@googlemail.com wrote: On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: status = tcsetattr(fd, TCSANOW, options); How does it behave if you use TCSAFLUSH rather than TCSANOW ? I made that substitution and added a #define DEBUG 1 The resulting binary sometimes fails to return and I then have to hit ctrl-c. I've tried it several times, and not seen any (repeating) pattern in terms of when it works and when it fails. Is the system running Linux running on the same type of board as your OpenBSD system? If not, try running Linux on a system identical to the one you're using - see if it's the board causing the problem. Hi Aaron, No, they are very different machines. I don't have a spare ALIX system that I can load Linux onto for testing. If I can't resolve it any other way I will switch my current machine to Linux; but having just got everything set up in OpenBSD, I'd like to avoid that if possible. I have however tried the code in my initial email on a different OpenBSD machine (a Dell Optiplex Pentium II, dmesg is at http://www.tigerturnings.dyndns.dk/dmesg-dell) In this case I used cua0, the onboard serial port, on an ns16550a controller. Running the example from my initial post, with #define DEBUG 1 added and /dev/ttyU0 replaced by /dev/cua00, I get sporadic failures: # time ./ex_obsd_now_cua0 ; sleep 3 ; time ./ex_obsd_now_cua0 Port has been opened and set up 1 bytes available, read: 6 0m0.12s real 0m0.00s user 0m0.00s system Port has been opened and set up ^C0m7.00s real 0m0.00s user 0m0.00s system If I replace TCSANOW with TCSAFLUSH on this machine, it doesn't help, though the instrument does sometimes send 21 (NAK) which I've never seen it do when using TCSANOW. # time ./ex_obsd_flush_cua0 Port has been opened and set up 1 bytes available, read: 6 0m0.14s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush_cua0 Port has been opened and set up ^C0m3.97s real 0m0.00s user 0m0.01s system # time ./ex_obsd_flush_cua0 Port has been opened and set up ^C0m3.65s real 0m0.00s user 0m0.00s system # time ./ex_obsd_flush_cua0 Port has been opened and set up 1 bytes available, read: 21 Expecting ACK, got 21 0m0.23s real 0m0.00s user 0m0.00s system I think that this should rule out any problems with the USB-RS232 converter or its drivers, and with the USB controller on the ALIX system. I'd be grateful for any further ideas or suggestions. -- Neil I should be able to figure this out, but my C language serial port hacking skills are a bit rusty. These days, C is only used for time-critical portions of instrument automation for test/mfg environments, but for everything else, languages like perl, tcl or custom/proprietary LabView executables are used. Lots of instruments speak skippy (SCPI) otherwise known as Standard Commands for Programmable Instruments. Your *UNNAMED* instrument might speak a custom protocol as you claimed, or it might also speak skippy either natively or with some configuration. http://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instrumentation If your instrument can speak skippy then your life gets a whole lot easier, so it's definitely worth checking. I'm not sure why you failed to post the make and model number details of your instrument, but they would be really helpful. As I mentioned off list, TCSAFLUSH is often required, but more than that, it's just good practice to flush the buffers to make sure you're starting in a known state (e.g. no crap in the buffers). Both your C code, and not understanding the behavior and output you posted seems to indicate you followed one of the countless (poorly written) how-to pages or books like: http://www.easysw.com/~mike/serial/serial.html The above has some good spots but it also has plenty of errors and unfortunately, it is highly ranked by search engines. In your code you seem to have inherited one of the mistakes, namely you think read(2) gives you bytes available rather than bytes read as stated (twice) in the read(2) man page. $ man 2 read ... Upon successful completion, read(), readv(), pread(), and preadv() return the number of bytes actually read and placed in the buffer. The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of- file, but in no other case. ... The other problem is understanding what is happening. Unless you specifically configured the descriptor to return immediately, your read(2) call will sleep until it gets the requested number of bytes from the descriptor, until
Re: Serial port programming problems
On Sun, 2 May 2010 12:01:59 -0700 J.C. Roberts
list-...@designtools.org wrote:
The other problem is understanding what is happening. Unless you
specifically configured the descriptor to return immediately, your
read(2) call will sleep until it gets the requested number of bytes
from the descriptor, until an interval timer expires, or until an
error occurs. Since the instrument is not sending you any data, it
sleeps until you lose your patience and hit CTL-C to end the program.
--This should not be a surprise. ;)
I should have referenced your code so the above makes sense.
int open_port(void)
{
int fd;
fd = open(/dev/ttyU0, O_RDWR | O_NOCTTY | O_NDELAY);
if (fd 0)
{
errx(1,open_port: Unable to open /dev/ttyS0.);
}
else
{
fcntl(fd, F_SETFL, 0);
}
return (fd);
}
Setting O_NDELAY (or better said O_NONBLOCK) on open gets wiped out
when you run fcntl(fd, F_SETFL, 0)
I have no idea why you're doing that (probably just mistyped example
code), but if you insist, then you'd actually want:
fcntl(fd, F_SETFL, FNDELAY);
or
fcntl(fd, F_SETFL, FNONBLOCK);
Hence the reason why you're actually blocking on read.
--
The OpenBSD Journal - http://www.undeadly.org
Re: /usr directory: a system or user place?
On Sat, 1 May 2010 22:52:54 +0200 Harrell elbibliotecarioci...@gmail.com wrote: Hi list, Not no off-topic, but a little unix history oriented question. In hier(7) OpenBSD describe /usr as Contains the majority of user utilities and applications. In http://www.usna.edu/Users/cs/delooze/teaching/IC221/Lectures/LN02/class02.html they say that /usr Stands for Unix System Resources. Contains system utilities. In wikipedia they say /usr is *Secondary hierarchy* for read-only user data; contains the majority of (multi-http://en.wikipedia.org/wiki/Multi-user)user utilities and applications http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard So my doubt is: Is usr an abbreviation of user? If that is so (as as hier(7) can be understood), why /usr contains mainly system resources and not user resources? In fact only root has w permission inside /usr, so it seems more a system directory. I know that a system directory contains resources for the user, but, just for curiosity, what is the origin of this directory name? A user place o a unix system place? Thanks. Harrell In many situations knowing where a name comes from is really helpful, but in other situations, knowing where a name came from is completely misleading since over time, definitions change. The name of the /usr directory is the latter. At one point in time in the ancient past, the /usr directory is where user directories were once stored, but over time the usage of this directory changed. The claim of 'usr' being an abbreviation for Unix System Resources is a backronym, (i.e. an abbreviation created after the fact). jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: current on HP EliteBook 8530w
On Fri, 30 Apr 2010 14:47:35 +0200 Markus Bergkvist markus.bergkv...@telia.com wrote: Looks like the same problem I have on my hp 6730b. The diff makes it boot, but if I plug or unplug the ac I get the panic below and the only way to leave ddb is hard reboot. From ddb, does 'boot reboot' not work? You can set 'kern.nosuidcoredump' in /etc/sysctl.conf to save core dumps from in /var/crash. Then try using 'boot dump' in ddb. You need to be patient. On some systems the reboot will happen within a few minutes, but on others it might take a half hour or so to reboot. -- The OpenBSD Journal - http://www.undeadly.org
Re: ktrace pppd errno 25 Was: pppd- unable to set non-blocking mode
On Thu, 29 Apr 2010 17:43:02 -0700 dave d...@deldebbio.org wrote:
The first few lines of a ktrace to the pppd process with a umodem
detected card reveals:
31129 pppd EMUL native
31129 pppd RET nanosleep 0
31129 pppd CALL ioctl(0x5,TIOCMBIS,0x7f7eee64)
31129 pppd RET ioctl -1 errno 25 Inappropriate ioctl for
device
ioctl -1 errno 25 Inappropriate ioctl for device
Isn't umodem supposed to make it behave as a tty? Again this is
behavior seen on the last two snapshots. It is not something I have
seen before...
Original Message
Subject: pppd- unable to set non-blocking mode
Date: Wed, 28 Apr 2010 07:20:07 -0700
From: dave d...@deldebbio.org
To: misc@openbsd.org
Hi there,
For the last two snapshots, I have started receiving the following
output in /var/log/daemon:
Apr 28 06:17:07 puffy pppd[5388]: Couldn't set device to non-blocking
mode: Inappropriate ioctl for device
A search of both @tech and @misc reveals only the suggestion that the
poster's kernel and pppd are out of sync but that is not the case
here.
A google search and reading Stevens Advanced Programming in the Unix
Environment Terminal IO lead me to believe that a successful
connection to the isp would cause the DCD to be detected and the
serial terminal to be opened with O_RDWR...
I know that output is that is pasted above comes from
/usr/src/usr.sbin/pppd/sys-bsd.c. Unfortuately, I cannot trace the
code using the kdebug 2 option with pppd, so I don't know how to
correct the inappropriate ioctl message.
Pppd still works with this output, but I don't understand what would
have changed; I have not had this output before. The configuration
files have not changed either.
/var/log/daemon
Apr 28 06:16:55 puffy pppd[5388]: pppd 2.3.5 started by dave, uid 0
Apr 28 06:17:06 puffy pppd[5388]: Serial connection established.
Apr 28 06:17:07 puffy pppd[5388]: Couldn't set device to non-blocking
mode: Inappropriate ioctl for device
Apr 28 06:17:07 puffy pppd[5388]: Using interface ppp0
Apr 28 06:17:07 puffy pppd[5388]: Connect: ppp0 -- /dev/cuaU0
Apr 28 06:17:07 puffy pppd[5388]: Remote message: Congratulations!
Apr 28 06:17:10 puffy pppd[5388]: local IP address 166.128.66.34
Apr 28 06:17:10 puffy pppd[5388]: remote IP address 72.215.255.9
Apr 28 06:19:37 puffy pppd[5388]: Connection terminated.
Apr 28 06:19:37 puffy pppd[5388]: Couldn't restore device fd flags:
Inappropriate ioctl for device
Apr 28 06:19:37 puffy pppd[5388]: ioctl(TIOCSETD): Inappropriate ioctl
for device
Apr 28 06:19:37 puffy named[18899]: shutting down
Apr 28 06:19:37 puffy named[18899]: stopping command channel on
127.0.0.1#953
Apr 28 06:19:37 puffy named[18899]: no longer listening on
127.0.0.1#53 Apr 28 06:19:37 puffy named[18899]: no longer listening
on ::1#53 Apr 28 06:19:37 puffy named[18899]: exiting
Apr 28 06:19:38 puffy pppd[5388]: tcsetattr: Inappropriate ioctl for
device
/etc/ppp/peers/umts
cuaU0
921600
:72.215.255.9
noipdefault
defaultroute
crtscts
modem
modem_chat
passive
asyncmap 0
lock
passive
noauth
user i...@cingulargprs.com
connect '/usr/sbin/chat -e -f /etc/ppp/peers/umts.chat'
/etc/ppp/peers/umts.chat
ABORT BUSY ABORT NO ANSWER ABORT NO DIALTONE ABORT NO CARRIER
'' AT
TIMEOUT 30
'' AT+CFUN=1 T+CFUN=1
'' OK
'' '+PACSP0'
'AT+CGDCONT=1,IP,isp.cingular,0.0.0.0,0,1'
OK\r\n 'ATDT*99***1#'
\r\n \c
CONNECT \c
I start pppd with the following function:
function pppup {
if [[ $# -ne 0 ]]; then
echo 'Usage: pppup' 2
return 2
fi
if [[ -n $(netstat -nrf inet | grep default) ]]; then
sudo ifconfig trunk0 down sudo route -q delete default
fi
sudo ifconfig ppp0 create
sudo cp /etc/resolv.conf /etc/resolv.conf.bk
sudo cp /etc/resolv.localhost /etc/resolv.conf
sudo named pppd call umts
}
Here is the dmesg:
OpenBSD 4.7-current (GENERIC.MP) #225: Tue Apr 27 11:25:08 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3177910272 (3030MB)
avail mem = 3079602176 (2936MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version 6EET50WW (3.10 ) date 03/16/2010
bios0: LENOVO 2777CTO
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT
TCPA SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4)
EXP2(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5
(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU U9600 @ 1.60GHz, 1596.23 MHz
cpu0:
FPU,VME,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,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG
cpu0: 3MB 64b/line
Re: current on HP EliteBook 8530w
On Fri, 30 Apr 2010 22:34:31 + Miod Vallat m...@online.fr wrote: You can set 'kern.nosuidcoredump' in /etc/sysctl.conf to save core dumps from in /var/crash. Then try using 'boot dump' in ddb. This sysctl value has no relation to the ability to create kernel crash dumps. Miod uggh. I was thinking X crash dumps as noted in xenocara/README. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: need a umsm that works
On Mon, 26 Apr 2010 23:03:39 -0500 Marco Peereboom sl...@peereboom.us wrote: I need a umsm dongle that works in the USA. Can someone tell me exactly what device and what network provider they use? Preferably with some config scripts so that I can get an idea how they work. Please mail me privately. Since I already posted it to list... With some carriers, you don't need to worry about private details being posted in config scripts. Identification of the device/user/account is done through the IMSI (International Mobile Subscriber Identity) so there's no user/pass to be divulged. At worst, some providers require using the phone number assigned to the device with the ppp login, but since the phone number is basically unusable, it doesn't matter much. You're probably thinking usb dongle but internally they're not much different from the an older kyocera KPC650 EVOD Rev0 pcmcia card I'm using with verizon (e.g. it's just usb wrapped in a pcmcia form factor). Details, ppp.conf and dmesg are on list here: http://marc.info/?l=openbsd-miscm=127208707206345w=2 jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: OpenBSD and KVM switch.
On Tue, 27 Apr 2010 16:31:02 +0930 David Walker davidianwal...@gmail.com wrote: Hiya JCR. A snapshot also re-attaches with the default layout (QWERTY). It doesn't matter if I use wsconsctl.conf or the kbdtype file. uname -rv 4.7 GENERIC#628 Bummer. Now we need to figure out why. BTW, is there still the 3 minute attach delay as seen/mentioned with 4.6-release? Thanks for the heads up on hotplug. :) It's just a work-around. Finding and fixing the root cause is still important. -- The OpenBSD Journal - http://www.undeadly.org
Re: OpenBSD and KVM switch.
On Tue, 27 Apr 2010 22:05:37 +0930 David Walker davidianwal...@gmail.com wrote: Thanks for the heads up on hotplug. :) It's just a work-around. Finding and fixing the root cause is still important. I wasn't sure if it was a bug or a known feature - i.e. it was decided to not make guesses about what people were plugging/unplugging. BTW, hotplug works great. In case anyone has the same issue and can't work it out (I am a script noob so keep the laughter to a minimum or tell me what I could do better): #!/bin/sh DEVCLASS=$1 DEVNAME=$2 case $DEVNAME in wskbd0) kbd us.dvorak ;; esac Make the script executable. Don't forget to switch on hotplug in rc.conf.local: hotplugd_flags= With the fact the keyboard is setup by /etc/rc and the work-around being this easy, it's tough to call this a bug. But the reattach ignoring the /etc/wsconsctl.conf settings is annoying. The confusing part is the keyboard encoding is actually setup *twice* in /etc/rc first by kbd(1) and then (possibly) again by wsconsctl(8) if you have a keyboard.encoding= entry in /etc/wsconsctl.conf. Your script above is nice and simple, but would have trouble if you're doing any customizing through /etc/wsconsctl.conf. If you're doing anything custom in /etc/wsconsctl.conf, then your hotplugd script should borrow the portion of /etc/rc which handles executing wsconsctl with all the conf file goodness. It's all in one little function wsconsctl_conf() but you'd also need the stripcom () function and handle IFS properly. -- The OpenBSD Journal - http://www.undeadly.org
Re: need a umsm that works
On Mon, 26 Apr 2010 23:03:39 -0500 Marco Peereboom sl...@peereboom.us wrote: I need a umsm dongle that works in the USA. Can someone tell me exactly what device and what network provider they use? Preferably with some config scripts so that I can get an idea how they work. This is just for the archives. I've been meaning to upgrade my EVDO Rev.0 Kyocera KPC650 to something that supports EVDO Rev.A and this was the perfect excuse to get it done. The device I wanted to buy was the ZTC AD3700 (a.k.a Verizon AD3700) since internally it has the Qualcomm GOBI 1000 chipset. Unfortunately, none of the local stores had it in stock. The local (corporate not reseller) Verizon store had some at their warehouse, but they wouldn't sell me any hardware without also buying a(nother) two year contract. Bastards! I settled on getting a Pantech UMW190 (a.k.a. Verizon UMW190) from another store since it also has a GSM sim slot and hsdp support. As usual, the UMW190 had to be activated in ms-windows, but after that, it Just Works in OpenBSD. It comes up as a umodem(4) device with attached ucom(4) in 4.7-current, and the previously posted ppp.conf works without changes. If I find the time, I'll probably go on a knob turning spree in ppp.conf to see what I can make it do, but it's already faster than the EVDO Rev.0 device it replaced. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Texas Tea (Testing)
On Mon, 26 Apr 2010 03:12:03 +0100 Owain Ainsworth zer...@googlemail.com wrote: As for building a lot quicker by not setting XENOCARA_RERUN_AUTOCONF, well, then you would not be testing to make sure gnu autoshit is still working properly. In short, it's a no-win situation. I leave it turned off unless there's a new driver I am playing with. Then I turn it on for that driver build and that one only. Regenning configure really buys you nothing. I mostly agree. It buys me little more than being able to say it was tested completely, and at the price of much annoyance. It's like picking at a scab to see if it's healed or if it will bleed again. -- The OpenBSD Journal - http://www.undeadly.org
Re: OpenBSD and KVM switch.
On Mon, 26 Apr 2010 16:44:55 +0930 David Walker davidianwal...@gmail.com wrote: Apr 27 01:00:25 compaq /bsd: uhub2 detached Apr 27 01:03:03 compaq /bsd: uhub2 at uhub1 @ three minutes is where it re-attaches. I suspect this is a feature and not a hardware issue, however dmesg follows. Any ideas welcome. cat /var/run/dmesg.boot OpenBSD 4.6 (GENERIC) #58: Thu Jul 9 21:24:42 MDT 2009 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC A ton of work has been done since 4.6-Release (July 9th). The first thing you want to do is install the -current snapshot and see if you can repeat the problem with more recent code. If the problem persists, a work-around you could use is hotplugd (8). jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Printing schemas
On Sat, 24 Apr 2010 17:56:14 -0500 Ed Ahlsen-Girard eagir...@cox.net wrote: On Sat, 24 Apr 2010 16:19:23 -0500 Todd Alan Smith tas-misc-open...@puesnada.us wrote: On Sat, Apr 24, 2010 at 3:47 PM, Ed Ahlsen-Girard eagir...@cox.net wrote: I'm looking specifically ay how to print to a USB printer that is hanging off an XP box. Then why didn't you mention that in your first post? Because I wanted the more general information. Printing is one of those Black Magic topics where the people who know it think it's easy, and the people who don't know it cower in fear. In your case, you've got four options: 1.) If supported by the printer, attach the printer to the network. 2.) Use a print sever device to attach the USB/parallel printer to your network. 3.) Use windows file/printer sharing and samba to access it. 4.) Use LPR Service on windows, but be cautious about pass-through http://support.microsoft.com/kb/150930 There's also a the fifth option of attaching the printer directly to your UNIX box (parallel, serial, or USB), but that was outside of your request, and often requires packages to get non-postscript printers working correctly. The first option above is usually the easiest, particularly if the printer understands postscript. The first two requirements for purchasing a printer should be supporting postscript, and having a network connection. Unfortunately, most consumer-level printers do not have these options. If you have consumer-level junk, then an option is a cheap print server device. These typically have an RJ-45 (either 10Mbit or 10/100Mbit) along with one or more parallel, serial and USB ports. It's a nice answer if you don't want a workstation running all the time and they typically provide LPD and ms-windows shares. The third option is use a workstation running windows along with windows print/file sharing. On the unix side, use samba to access the share. You may or may not need additional packages depending on the printer itself. The last option is using the microsoft LPD Service but you need to be cautious about how it is configured. At times, windows makes the wrong decision and actually prints the raw postscript text out. It really depends on how the LPD client is sending data to the LPD Service, and some LPD clients are not very standards compliant. Considering all the strange consumer-level devices out there, and all the vendor provided crapware they often require to run correctly, the topic is difficult to cover beyond the basics above. You might need packages like CUPS, apsfilter, enscript, ghostscript, and others to get consumer-level printers working correctly regardless of how they are connected. --Avoiding this nonsense is why network and postscript support in the printer is *REALLY* desirable. Lastly, if you want to use a windows client system with a networked LPD-only printer (e.g. no windows shares), configuring windows is entirely anti-intuitive. You have to select local printer then add port and then fill in the details, even though the printer is not local by any stretch of the imagination. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Premature end of archive
On Thu, 22 Apr 2010 17:56:48 +0700 sonjaya sonj...@gmail.com wrote: Length: 1516336 (1.4M), 1139856 (1.1M) remaining 24% [ ] 376,480 38.8K/s in 9.6s 2010-04-22 17:53:34 (38.1 KB/s) - Data connection: Connection reset by peer; Control connection closed. Retrying. then i check in sonicwall 12 UTC 04/22/2010 10:52:56.032 Alert Security Services Gateway Anti-Virus Alert: Mytob.Crypter (Worm) blocked 78.41.115.130, 51671, X3 192.168.xxx.10, 13305, X5 ha ha so the trouble maker is sonicwall Signature based detection has always been flawed, and worse, as the volume of malware increases, so does the number of illegal byte sequences. The result is obvious; more and more stuff will be blocked due to false positives. Using encryption (ssh, scp, ssl) is a way around this problem, and if it does happen when using encryption, then just change to using a different cypher (resulting in a different byte sequence). jcr -- The OpenBSD Journal - http://www.undeadly.org
Texas Tea (Testing)
This is a story about a man named Jeb, a poor mountaineer barely kept his family fed, and then one day when he was shootin' at some food, when up from the ground came a'bublin crude... Black Gold. Texas Tea. Actually, this is a story about what *should* happen when a developer asks you to redo something you've already done. Of course, the above quote is from the Beverly Hillbillies since making fun of Texans is one of the favorite pastimes of Californians. ;) I'm certainly not an expert when it comes to testing or debugging in a UNIX environment, but you don't have to be an expert to help. With all the recent posts about users looking for a place to start helping and learning, testing is a great place to get rolling. The following is a long read with complete (overly verbose) details, so fetch a fresh cup of coffee and get comfortable. It's may not be the right or best way to do things, but it's what I did. Though the snapshot info and steps used to set up the system were posted to the intel testing thread on tech@ or set to oga@ directly, marco@ asked me to make sure I got it right. Here's an excerpt of the of the exchange: marco jcr are you dead sure you got all the bits and pieces for that intel driver thing? jcr marco: After cvs update, I built the kernel, then built xenocara, and finally built the new driver. jcr If there were any missing bits after that, then I'm not even aware of them. marco well you kind of forgot to make build marco and more importantly make includes marco would you mind retrying? marco i'll give you the exact commands jcr sure marco first you go to /usr/obj marco rm -rf * marco cd ../xobj marco rm -rf * marco that gives you a clean slate marco update both /usr/src and /usr/xenocara to -current marco then cd /usr/src marco make -j4 obj make -j4 depend make -j4 includes make -j4 tags make -j4 build marco btw all this as root marco once that completes cd ../xenocara marco make bootstrap make -j8 obj make -j 4 build marco once that completes build a kernel with the GEM_INTELDRM thing enabled marco and make install that marco reboot and test marco this is more than one hour on my laptop that is fast marco easily 4 hours on something slow jcr will do. I'll start on it now. Though I had probably done things right the first time, eliminating the possibility that one unknowing got it wrong is sometimes required. I had installed the then recent April 15 snapshot, then followed oga@'s instructions, updated src and xenocara, built the kernel with GEM support, built xenocara, and then finally built the new intel driver. Of course, the changes on current.html had been followed to date. http://www.openbsd.org/faq/current.html As far as *I* knew, everything was perfect. Of course, what I supposedly know could always be wrong. It isn't that I lack the skill to do things correctly and thoroughly, instead it's just that mistakes happen to everyone. It's far better to spend the time to validate a bug by rebuilding the test setup than it is to have one of more developers wasting their time chasing shadows. I usually build without X running (less resources in use and less task switching). Since I've seen two unprovoked crashes with the new intel driver building from a normal terminal (without X) is how I'm doing all of the following. Ahhh the joys of a dedicated test/build box. Before starting on rebuilding everything to make sure it was done right, backup the existing files so I can recreate the error as it exists now. Though it was only the 24th when I started this redo, there have been plenty of commits since the April 15 snapshot and April 17th xenocra cvs update. If one of the changes fixed the issue, being able to recreate the issue might be the only way to figure out what change made the difference. The April 15th snap and GEN enabled kernel used are already saved, so I just need to keep a copy of the current /usr/X11R6 directory which includes the new intel driver I built. # cd /usr # mkdir X11R6-old # cp -R X11R6/* X11R5-old/. Show the relevant configuration: # cat /etc/mk.conf XENOCARA_RERUN_AUTOCONF=Yes SUDO=/usr/bin/sudo ACCEPT_JRL_LICENSE=Yes CHECK_LIB_DEPENDS=Yes # echo MALLOC_OPTIONS # ls /etc/malloc.conf ls: /etc/malloc.conf: No such file or directory # grep nosuidcoredump /etc/sysctl.conf kern.nosuidcoredump=2 # 2=Put suid coredumps in /var/crash # grep allowaperture /etc/sysctl.conf machdep.allowaperture=2 # see xf86(4) # alias mean alias mean='sudo nice -n -16' # Clean out object cruft: # rm -fr /usr/obj/* # rm -fr /usr/xobj/* Deleting the xenocara tree and restoring from an archive of a fresh update is the easiest way to avoid the dumbfuckery of gnu autotools. This is particularly true if you have XENOCARA_RERUN_AUTOCONF set in your /etc/mk.conf since it results in tons and tons of files being modified which results
Re: Texas Tea (Testing)
On Sun, 25 Apr 2010 15:22:31 -0700 Philip Guenther guent...@gmail.com wrote: On Sun, Apr 25, 2010 at 2:49 PM, J.C. Roberts list-...@designtools.org wrote: ... # cat /usr/src/sys/arch/i386/conf/GENERIC_GEM # GENERIC with INTELDRM_GEM include arch/i386/conf/GENERIC option INDELDRM_GEM option DRMDEBUG Please tell us the actual file doesn't misspell INTELDRM_GEM... Sorry about that typo. That's just a typo in my notes which were written out on a separate system. The test system has it right. Also, the gem enabled driver won't work with an non-gem kernel. -- The OpenBSD Journal - http://www.undeadly.org
Re: Texas Tea (Testing)
On Sun, 25 Apr 2010 23:55:35 +0100 Owain Ainsworth zer...@googlemail.com wrote: On Sun, Apr 25, 2010 at 05:27:26PM -0500, Chris Bennett wrote: I am glad to see someone else agreeing that rm-ing xenocara and getting it again is a good choice. I had to build a few debugging versions and I found the instructions for getting it clean to use again extremely confusing. I was concerned I would get it wrong and mess everything new up. To get a completely clean tree with nothing unrecognised by cvs, assuming that no files known by cvs are corrupted (do not do this if you have testing drivers in the tree that are not related to cvs). If it breaks, you keep the pieces. $ cvs up | grep ^\? | tr -d '\?' | xargs rm -rf $ cvs up # just in case Those who are better at awk than I could come up with something shorter, I bet. For me at least, the problem is not 'unrecognized' files, instead it is *modified* files. With XENOCARA_RERUN_AUTOCONF=Yes set in mk.conf, half the damn tree is molested by gnu autoshit resulting supposedly modofied files. Since the `cvs up -C` flag is currently broken in both gnu cvs and opencvs (BUG: user/6363 -- copies modified files rather than moving them out of the way and fetching a fresh copy from cvs, resulting in a merge M rather than U update/fetch of the now missing file), there is no way to simply overwrite the modified files. Anyhow, whether or not '-C' works, you'd still be refetching half (or more) of the xenocara tree since a vast portion of it is gnu autoshit files which have been modified. As for building a lot quicker by not setting XENOCARA_RERUN_AUTOCONF, well, then you would not be testing to make sure gnu autoshit is still working properly. In short, it's a no-win situation. -- The OpenBSD Journal - http://www.undeadly.org
Re: 19' rack mini appliance for OpenBSD
On Fri, 23 Apr 2010 09:44:01 -0400 Chris Dukes pak...@pr.neotoma.org wrote: On Fri, Apr 23, 2010 at 01:32:57PM +0100, FRLinux wrote: I use a variety of servers with OpenBSD mostly for DNS. Recently I have been luring into systems such as Alix Boards to build a small power system with a 19' rack enclosure. Anyone would have suggestions on that type of boards (ALIX) or any other equivalent to perform as a server on compact flash? (I used to use soekris but not sure I want to do down that road again). If it's a 19 foot rack, I don't think you need anything compact. Maybe you can find some of the washing machine sized harddrives for a VAX. I've always wanted a washing machine sized hard drive! Get some folks together and some beer, then write assembly code to see who can make it walk across the floor the fastest! Of course, the people at PARC figure this out eons ago by accident. A particular sequence or reads/seeks/writes caused such a beast to walk across the floor and block the only door, and they had to cut a hole in the wall to get back into the datacenter. Afterwards, they used to hold races with it after work. -- The OpenBSD Journal - http://www.undeadly.org
Re: Novatel MC760 Virgin Mobile Broadband2Go
On Thu, 22 Apr 2010 07:44:04 -0600 Ted Roby ted.r...@gmail.com wrote: Novatel (0x1410) makes an MC760 (0x6002) used by Virgin Mobile in their BroadBand2Go card. First things first. You will probably need to put it into a ms-windows machine with the vendor/carrier provided software to do the initial device configuration (e.g. activation including getting the prl and similar downloads). As mentioned, there are typically more than one serial ports on these devices. Only one of the serial ports is used for the connection, while the others are for undocumented management purposes. You'll need to experiment to figure out which is the right port. These cards can attach to different networks, such as QNC, RTT, EVDO Rev0, EVDO RevA, GSM. GPRS, UTMS, HSDPA, ... and you can control the network via the AT commands. Unfortunately, some devices will uncontrollably float between networks depending on usage and/or signal strength. With some providers, you need to use the correct phone number in your ppp.conf, typically #777 but with other providers, this doesn't matter. Similarly, with some providers the authname and authkey matter (some use the device phone number), but with other providers they don't matter, or need to be set to known values. One thing to note is the setting for 'speed' only matters on some devices while other devices ignore the provided value. I've got no clue how the MC760 works. From what I've read, Virgin Mobile Broadband uses PAP and CHAP must be disabled, but I'm thousands of miles away from being able to test it, so I'm uncertain if it's true. From the file content and file names, it seems you've found hints from the linux users like: http://forums.whirlpool.net.au/forum-replies-archive.cfm/808806.html The good thing about the above link is it seems to show the AT commands for controlling which network you connect to with virgin. Reformatting the information into a simple ppp.conf should not be too difficult. Below is my ppp.conf and dmesg for an EVDO device running on Verizon here in the states. Yours will obviously be different, but it might be a helpful reference. jcr --- # Default Settings # set log debug async connect Phase Chat LCP IPCP CCP tun command default: set log connect Phase Chat LQM LCP IPCP CCP tun command # NOTE: need to document AT codes for QNC, RTT, EVDO, etc. # For old 14.4K QNC Network # AT$QCMDR=2;AT$QCQNC=1 # For 128K144K RTT Express Network # AT$QCMDR=3;AT$QCQNC=0 # For EVDO # AT (unknown) # VerizonWireless 1xEVDO/1xRTT vzw: set device /dev/cuaU0 set speed 230400 set phone #777 set authname vzw3g.com set authkey vzw set server /var/run/ppp.pid 0177 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ \ AT OK \ ATZ0 OK \ ATQ0 OK \ ATV1 OK \ ATE1 OK \ AT+EFCS=2 OK \ ATV OK \ \\dATDT\\T TIMEOUT 30 CONNECT set login set redial 3 0 set timeout 0 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 add! default HISADDR enable dns disable ipv6cp enable lqr accept lqr set cd off # set mru 2048 # set mtu 2048 # set mru 2048 # set mtu 2048 # set ctsrts off # set escape 0xff # set accmap 000a # enable echo # set echoperiod 30 # disable vjcomp # deny vjcomp # disable deflate pred1 vjcomp acfcomp chap chap81 mppe # deny deflate pred1 vjcomp acfcomp chap chap81 mppe # disable vjcomp pred1 deflate lqr # deny vjcomp pred1 deflate lqr # disable vjcomp pred1 deflate # deny vjcomp pred1 deflate # disable lqr # deny lqr #EOF --- OpenBSD 4.7 (GENERIC) #556: Tue Mar 9 09:46:59 MST 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 400 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real mem = 133783552 (127MB) avail mem = 120979456 (115MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/01/01, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.2 @ 0xfb410 (64 entries) bios0: vendor Dell Computer Corporation version A10 date 08/01/01 bios0: Dell Computer Corporation OptiPlex GX1 400MTbr+ apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc670/176 (9 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371AB PIIX4 ISA rev 0x00) pcibios0: PCI bus #3 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x8000 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 intelagp0 at pchb0 agp0 at intelagp0: aperture at 0xf400, size 0x400 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Rage Pro rev 0x5c wsdisplay0 at vga1 mux 1: console (80x25,
Re: TRIM support?
On Tue, 20 Apr 2010 16:22:32 -0500 Marco Peereboom sl...@peereboom.us wrote: On Tue, Apr 20, 2010 at 03:01:58PM -0500, Marco Peereboom wrote: On Tue, Apr 20, 2010 at 03:48:23PM -0400, Ted Unangst wrote: On Tue, Apr 20, 2010 at 3:11 PM, Marco Peereboom sl...@peereboom.us wrote: And no, TRIM isn't supported. The problem is that we're copying the entire disk, so, as far as the disk (i.e., SSDs) is aware, that disk is 100% full-- all blocks are marked as used even if they're empty. If I understand correctly, how the controller handles block reallocation in this scenario depends how it is You are. The whole not write so often is really really really uninteresting. It's not about writing too often, it's about the performance hit doing a read/modify/write when there's no free blocks. Like the 4k sector problem, but potentially even worse. On the other hand, it depends on how much writing your server will do in service. If you aren't writing large files, you won't notice much difference, and the benefit of ultra fast random access is more than worth it. I am 100% unconvinced. I *was* 100% unconvinced. I am much better educated now. Yes this could be neat :-) Heck, that didn't take long. ;) The impact of read/modify/write can be significant on SSD's, and performance of these devices degrades over time/use. The percent of the over-time degradation attributed to the read/modify/write issue is typically unknown, so TRIM just helps but doesn't solve the whole enchilada. Unfortunately, just getting TRIM support implemented in the low levels doesn't solve the entire problem, you also have to teach the filesystems to use it. At this point, even if TRIM was supported, using currently available SSD's on a mail server with tons of small writes means you're doomed to constantly baby sitting the performance of the system since it will degrade. You might be better off in the long run using multiple rotating disks that are half as fast, and half the price, but won't degrade. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: TRIM support?
On Wed, 21 Apr 2010 18:40:10 +0200 Jurjen Oskam jur...@stupendous.org wrote: On Tue, Apr 20, 2010 at 11:03:30PM -0700, J.C. Roberts wrote: degrade. You might be better off in the long run using multiple rotating disks that are half as fast, and half the price, but won't degrade. It's my understanding that if you have a decent SSD, write response times can (under some workloads) degrade but never below the performance of even a very fast rotating disk. So, i've stopped worrying about things like TRIM and trying to avoid writes. I'll align my partitions, but apart from that I just enjoy the extremely low read response times, and my almost-always-quite-low write response times. :) I agree. If your application does not require pushing things to their limits, TRIM and degradation can be a non-issue. When you have the budget to over-allocate with SSD's to exceed your requirements (e.g. a plan to compensate for increased demand as well as degradation over time), then they are an excellent choice. The problems only arise when you don't have the budget, don't understand your workload, don't do adequate testing, and don't plan for the eventual degradation. Since all of these issues except degradation also effect rotating storage, it's mostly a planing problem where SSD's just add other variables to the analysis. The trouble is SSD vendors are not particularly forthcoming about the limitations, so they are not well understood by integrators and this can result in poor planing. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: Source Overview
On Tue, 20 Apr 2010 11:58:02 +0800 Artur Grabowski a...@blahonga.org wrote: On Tue, Apr 20, 2010 at 2:02 AM, Christiano F. Haesbaert haesba...@haesbaert.org wrote: I also know he (as every developer) is busy with more important things, so publishing these small tasks would also give the developers more time to focus on the big/important issues. There are a bunch of assumptions here that are wrong. Small tasks are the most fun to do because they satisfy the instant gratification needs all of us have. I won't give you my list of the fun and easy stuff, I want to keep it to myself. The lists that are published will contain dull, heavy and not very important tasks. The kind that gets you burned out the quickest. Also, todo lists have been published in the past leading to either no reaction whatsoever or a bunch of people offering help and vampiring the energy from whoever published the list without leading to any code committed. It's easy to become slightly bitter about the whole thing after spending hundreds of hours helping people who then don't follow through when they realize that it actually requires work. //art Well said Art! Additionally, some of the most dull and heavy tasks are not coding, but instead, they are testing code/patches. There is no joy of coding involved, and little gratification when at the end of your efforts all you can say is, It worked fine on X. The closest thing to excitement you'll get is *if* you can find a bug. Does anyone really rely on a 486 with an ISA bus? What about a vax or similar esoteric system? Let alone use one regularly? Do these ancient and odd systems really matter? Having code run on multiple archs and lots of different hardware is a well proven way to find important bugs. The developers *CONSTANTLY* *ASK* *FOR* *YOUR* *HELP* with testing, but this dull and heavy work is somehow below most people who just talk about wanting to become developers and are looking for shortcuts to becoming one. Since validity is critical, if you cannot test properly and hopefully help in the debugging, then you'll never be any good at writing code. jcr -- The OpenBSD Journal - http://www.undeadly.org
Re: errata RSS feeds
On Mon, 19 Apr 2010 17:07:28 +0300 Kapetanakis Giannis bil...@edu.physics.uoc.gr wrote: Hi, The last few weeks http://www.undeadly.org/cgi?action=errata is not working. Is there any other official RSS feed for security errata? Giannis Thanks. I'll look into it. -- The OpenBSD Journal - http://www.undeadly.org
Re: 4k sector disks
On Thu, 8 Apr 2010 17:40:17 +1000 David Gwynne l...@animata.net wrote: ola, ive recently made a start on better supporting disks in openbsd that present 512 byte logical sectors, but actually use 4096 byte physical sectors on the platter. the best examples of these are the western digital advanced format SATA drives which have been mention on misc@ before. it was noted at the time that performance on these disks is much better if you can align your partitions and filesystems onto the 4k boundaries the physical sectors are on. the process of being able to better use 4k physical sectors relies on changes at many layers of the kernel and in the partitioning and filesystem utilities, beginning with fetching the details off the hardware, and then propagating it up the storage stack into the disk and block layers, and then out to userland to make smart decisions with. the tragedy of this situation is that i cannot find a disk that implements the parts of ATA specification that describe logical vs physical sector layouts. i have bought a couple of the WD advanced format drives, and some other people have bought me different models in the same family of drives, but none of them include the bits of the spec required to be useful. i dont know of any other manufacturers claiming to have disks with different sized logical and physical sectors, so this work has kinda stalled before it really began. however, as users we should know that the hardware has the 4k sector feature, so we should be able to configure machines to take advantage of it. i have talked to a few people who have tried to use these drives, but have had trouble setting them up as bootable disks. if you want to install onto one of these disks and line the / filesystem up on a 4k boundary, the trick is to modify the start of the openbsd partition (not slice) in fdisk (not disklabel) so it begins on sector 64, not sector 63. lining the rest of the partitions up in disklabel is then an easy exercise left up to the reader. if you line the partition up properly then things will Just Work(tm). there are western digital drives that do implement the correct parts of the ATA spec, i just dont know how to get hold of them. it appears that drives with models beginning with WD??EARS-00Z have the spec implemented, but drives with -00Y or before in their model name dont. all the local sellers only have -00Y revisions of these drives :( dlg A pair of WD15EARS-00Z5B1 (Rev: 80.00A80, Jan 31 2010) disks were found here in the Silicon Valley and a patch from dlg@ is being tested to determine if they will meet his requirements (e.g. specific parts of the ATA spec are implemented). You might want to note the suggestion above from dlg@ about installing the root filesystem (the 'a' partition) at sector 64 rather than the default sector 63 was not necessary with these very new disks. At present, the reason why they just work is unknown, but it is possibly due to commits like: http://marc.info/?l=openbsd-cvsm=127044093310329w=2 http://marc.info/?l=openbsd-cvsm=127042894602052w=2 http://marc.info/?l=openbsd-cvsm=127027862308889w=2 which have been made without having access to the needed hardware. -jcr
Re: updating packages with ports binaries
On Mon, 12 Apr 2010 00:44:50 +0200 Marc Espie es...@nerim.net wrote: On Sun, Apr 11, 2010 at 12:26:41PM -0400, Arnaud Bergeron wrote: Normally, as long as you do not use -F something as an option to pkg_add, everything you do with it is safe. (caveat: sometimes there are major upgrades, like for postgresql that require extra actions, but those are when you change releases) Hopefully, we'll deal with this before 4.8 as well. I have a mechanism to recognize those and actually check with the user if everything is fine. If you want to know about some of the improvements to pkg_* tools, Marc gave us some more details in the following article: http://www.undeadly.org/cgi?action=articlesid=20100323141307 -- The OpenBSD Journal - http://www.undeadly.org
Re: licensing
On Thu, 15 Apr 2010 11:57:40 -0600 Ted Roby ted.r...@gmail.com wrote: Now, did umplawny have the original right to put his restricted code into a project that was much more loosely licensed? If he did not, can I use his improperly licensed code (ie. does he forfeit his license by superseding restrictions of the previous license, or by not having permission to modify the source, and add his own?) There's a tricky difference here I'm trying to get at. Either his code must be removed (most likely), or there is a loophole which allows me to circumvent his license in favor of the Diku or Merc licenses. Also, umplawny did not go so far as to create a license file representing his interests. He merely pasted his declaration directly into the source (farther down than the header text) like this: /* NOT TO BE USED OR REPLICATED WITHOUT EXPLICIT PERMISSION OF AUTHOR */ Again, this code umplawny introduced is commonly referred to as snippets. It adds features for users and admins alike, but it is not critical to the functioning of the code as it was created by the Diku and Merc teams. Ted, 1.) A license declaration within a source file takes precedence over a license in an accompanying file. 2.) Even if you could trace how the file got into the Diku or Merc project, the author still holds the rights, so it makes no difference if he gave permission to the *_DIKU/MERC_project_* (or some member thereof) to include his work. Rights are reserved *UNLESS* granted, so nothing is forfeit by its inclusion with the DIKU/MERC project sources. 3.) Since an OpenBSD port can be created to neither distribute a resulting package, nor mirror the distribution file (distfile --i.e. DIKU/MERC source code archive), a port is feasible. 4.) Even when no package is being distributed, since an OpenBSD port can include patches, things can very messy when modification is required and the license somehow forbids modification/distribution or requires special conditions for modification/distribution. If you started distributing a patch set for Microsoft Windows, they'd come down on you like a ton of bricks. A similar sad fate is potentially possible for patches against any work using a wonky licenses with (e)strange(d) conditions regarding modification or distribution. You should read up in the misc@ archives on the endless debates, headaches, and eventual resolution (removed from the OpenBSD ports tree) caused by the wonky modification/distribution conditions of original DJB license. 5.) As for your previous comment about you personally taking all the risks of any license issues, the answer is no, you cannot. Copyright law doesn't work that way. Any user of your port is potentially vulnerable to litigation, and if your port was included in the OpenBSD ports tree, then the OpenBSD project itself would be potentially vulnerable to litigation. All of the above means you only have two choices: A.) Contact the rights holder and convince them to change the license. B.) Maintain a port on your own, posting your updates to ports@, and do *NOT* expect (or ask for) it to be added to the OpenBSD ports tree. Sure, you could have figured all this out on your own with enough study, but even if you did, you'd still need a good lawyer to look it over, as well as *still* need to pay said good lawyer to defend you if a rights holder disagrees with your interpretation of reality. -jcr
Re: licensing
On Fri, 16 Apr 2010 06:35:03 -0600 Ted Roby ted.r...@gmail.com wrote: All of the above means you only have two choices: A.) Contact the rights holder and convince them to change the license. B.) Maintain a port on your own, posting your updates to ports@, and do *NOT* expect (or ask for) it to be added to the OpenBSD ports tree. What about a completely unrelated project? I do not understand your question. If I have clean licensing on everything, can I then ask for addition to the tree? Of course you can ask, and if the port is both well done and well tested, then someone else might have enough interest to take the time to commit it. But of course, there are no guarantees. You'll never know if something is useful or interesting to others until you say, Here's what I brought to the party. Or should I just neatly post to ports@ and see what happens? Assuming a good port without caustic licensing, whether a port only lives on the ports@ list archives or lives in the official project ports tree, is highly subjective. You've showed up at a party where people are having fun. You were told drinks and snacks can be found in both the refrigerator and in the ice chests on the porch. --Does it really matter if someone important like the host of the party decides to move your favorite beverage or snack from the ice chest to the fridge? Do you think you'd look like an ass if you *INSISTED* that the host of the part spend his free time moving your favorite drinks or snacks from the icebox to the fridge? If you fail to maintain and support your supposedly favorite whatever after it's been moved into the fridge, we'll eventually have yet another moldy OpenBSD Culture rotting in the fridge. The very same kind folks who wasted their time putting it in the fridge for you, will now need to waste more time removing the crud. -jcr
Re: httpd segmentation fault
On Wed, 31 Mar 2010 22:10:08 +0300 (EEST) Ozgur Kazancci ozgur.kazan...@info.uvt.ro wrote: cd /usr cvs -d$CVSROOT checkout -r OPENBSD_4_6 -P ports but; # make search name=php5-core Port: php5-core-5.2.10 Still 5.2.10.. Might be an outdated cvs server, maybe? As sthen@ mentioned, your ports/INDEX is out of date, and this is to be expected. With lots of commits made every day, it just doesn't make sense to update ports/INDEX continuously. If you use `make search key=value` you will want to rebuild your local ports/INDEX after you `update` or `checkout` through cvs. # cd /usr/ports # make index The use of `make search key=value` is less fashionable these days compared to some of the alternatives like databases/sqlports
Re: aucat: default: can't open device
On Sat, 27 Mar 2010 15:12:42 + Jacob Meuser jake...@sdf.lonestar.org wrote: On Sat, Mar 27, 2010 at 01:02:44PM +, Jacob Meuser wrote: unfortunately, fixing this is not exactly trivial. I have an idea, but I really would need a machine (I have the cards, just nothing that can use them) to work it out. not exactly elegant (I don't think there is an elegant way to handle it without bigger changes) but it should work (only compile tested). With this card: FCC ID: IBACT-SB32PNP49 Model#: CT3620 You patch works perfectly. `aucat -l -m play` runs without a fuss and both `aucat -i track01.wav` and `cdio cdplay` run very well. I'll start testing the other four SB cards soonish. As for not having a working system with an ISA bus for testing the ancient stuff, I'll quite happily send you one, but I'm afraid you'd quite begrudgingly receive it. ;) If you want one, let me know. jcr
Re: aucat: default: can't open device
On Mon, 29 Mar 2010 00:39:46 + Jacob Meuser jake...@sdf.lonestar.org wrote: With this card: FCC ID: IBACT-SB32PNP49 Model#: CT3620 You patch works perfectly. `aucat -l -m play` runs without a fuss and both `aucat -i track01.wav` and `cdio cdplay` run very well. excellent. As for not having a working system with an ISA bus for testing the ancient stuff, I'll quite happily send you one, but I'm afraid you'd quite begrudgingly receive it. ;) yeah, I don't really need/want an old i386 ... maybe if ISA DMA worked on alpha or the hp* platforms ... I figured you'd hold a grudge for sending a gift like that. ;) I think the fastest things here with an ISA bus are Pentium II 400MHz to 600MHz dell boxes. I know we have ISA for alpha, hp300, loongson, and possibly others, but I've got no clue about the status of DMA on them. I'll start testing the other four SB cards soonish. if you (or anyone else) have any other working ISA audio devices, it would probably be a good time to make similar changes in other drivers. I tested everything in my box of ISA audio cards. There are probably other ISA audio cards around here sitting in systems, but digging the systems out would be painful, very painful. All of the following tests were done with your sb(4) patch, as well as the ISA related patches from oga@ and ariane@ from t...@. The testing was fairly simple and used a good quality recording: # aucat -l -m play # aucat -i track01.wav It's the same ancient P54C Pentium 133MHz system which I posted the dmesg for previously. It has has a noisy 50-pin SCSI disk, and the expected ancient (dirty) power supply. --Perfect for abusive testing. *** MODEL_: Creative SoundBlaster 32 PnP-ISA MODEL#: CT3620 FCC_ID: IBACT-SB32PNP49 CHIPS_: CT1745A CHIPS_: CT1749-DAQ CHIPS_: CT1971-TDQ Like many older PnP-ISA devices, it shows up a bit wonky, namely as sb1 rather than sb0. It has an IDE interface (shows as wdc0) and two SIMM slots (no mem installed). It works fine. As expected, `aucat -l` failed but `aucat -l -m play` worked fine. The default mixerctl output volume is a bit low. outputs.output=128,128 outputs.master=128,128 Bumping these up to 192 works well enough, although there's the typical light hiss (with nothing playing) when volume is increased. The light hiss is more quiet than the hard drive or power supply, so I doubt anyone will complain. ;) The IDE interface on this card (wdc(4)) is a pain in the ass and likes to conflict with anything it can find. IDE interface was not tested. *** MODEL_: Creative SoundBlaster 16 ISA (jumper config) MODEL#: CT1750 FCC_ID: IBACT-SB16MCD CHIPS_: CT1746B-6 CHIPS_: CT1748A CHIPS_: CT1745A It shows up as expected as sb0. It has an IDE interface but it is not detected. This card has a manual volume control on the card itself (e.g. external wheel). It works fine. As expected, `aucat -l` failed but `aucat -l -m play` worked fine. Again the defualt mixerctl output volume is a bit low, even when the manual volume wheel is maxed. outputs.output=128,128 outputs.master=128,128 Bumping these up 192 results in minimal (but expected) light hiss. This older card actually sounds better than the newer SB32 card above. IDE interface was not tested. *** MODEL_: Creative SoundBlaster Vibra 16XV PnP-ISA MODEL#: CT4170 FCC_ID: ? CHIPS_: CT2511-SBT It works fine. Sound quality is much better than the previous two cards (more headroom). As expected, `aucat -l` failed but `aucat -l -m play` worked fine. Again, the default mixerctl output volume is a bit low. Bumbing it up from 128,128 to 192,192 results a very tiny amount of light hiss. What's that little thumping noise? -Oh, it's a helicopter outside. ;) Flase alarm. Sorry. But it actually happened and I thought it was funny. *** MODEL_: Creative Soundblaster AWE64 PnP-ISA MODEL#: CT4520 FCC_ID: ? CHIPS_: CT1972-NAS CHIPS_: CT8920-NBQ Whooo! This even has a subwoofer output. It works fine. Again the sound quality is better than the older cards. And again, `aucat -l` failed but `aucat -l -m play` worked fine. Again, the default mixerctl output volume is a bit low. Bumbing it up from 128,128 to 192,192 results an almost unnoticeable amount of light hiss. *** MODEL_: ESS AudioDrive PnP-ISA MODEL#: ? FCC_ID: E5X1835 1833/5 CHIPS_: ES1688F VBA2393A CHIPS_: ES968F U6213 By the chip numbers, this card is not supported by ess(4). The ESS cards have a soundblaster compatibility mode and can show up as sb(4) devices. When this card comes up as sb0, it does not work. If I disable sb(4) in the kernel, the card doesn't show up at all.
Re: aucat: default: can't open device
On Sat, 27 Mar 2010 05:05:49 + Jacob Meuser
jake...@sdf.lonestar.org wrote:
On Fri, Mar 26, 2010 at 06:03:47PM -0700, J.C. Roberts wrote:
One of the (supposedly) working ISA devices I have here is an old
Creative SoundBlaster card, but I can't seem to get it working.
# AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -l
man sb. look for duplex.
The sb(4) man pages mentions a (potentially optional) configuration
file but gives no further details about it? --I think this needs to
get documented.
does `aucat -l -m play` work?
no joy.
# aucat -l -m play
aucat: default: can't open device
BIOS PNP detects and configures the card properly (no jumpers).
The label on the card reads:
FCC ID: IBACT-SB32PNP49
Model#: CT3620
The output of audioctl shows:
config=SB_16
Should the above show up as SB_32 ?
For fun, I grabbed second, slightly different (older), Creative
SoundBlaster ISA card and gave it a try. The results were the same. The
card comes up properly (IRQ DRQ) but aucat and midicat have issues.
The label on the second card reads:
FCC ID: IBACT-SB16MCD
Model#: CT750
If you need me to test them, I've also got a SB-AWE64, SB-ViBRA, ESS,
and a few other ISA based audio cards around.
It's not like I actually *use* these cards at all (for anything but
testing), and I wonder how many (if any) people are still using ISA
audio cards?
jcr
# AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -l -m play
sio_open_aucat: trying 0 - 0.default
sio_open_aucat: connect: No such file or directory
sun_setpar: 0: trying pars = 48000/16/6
sun_setpar: couldn't set linear encoding
aucat: default: can't open device
# audioctl
name=SoundBlaster
version=4.12
config=SB_16
encodings=ulinear:8,mulaw:8*,alaw:8*,slinear:8,slinear_le:16,ulinear_le:16,slinear_be:16*,ulinear_be:16*
properties=mmap,independent
full_duplex=0
fullduplex=0
blocksize=200
hiwat=163
lowat=1
output_muted=0
monitor_gain=0
mode=
play.rate=8000
play.sample_rate=8000
play.channels=1
play.precision=8
play.encoding=mulaw
play.gain=128
play.balance=32
play.port=0x0
play.avail_ports=0x0
play.seek=0
play.samples=0
play.eof=0
play.pause=0
play.error=0
play.waiting=0
play.open=0
play.active=0
play.buffer_size=32768
play.block_size=200
play.errors=0
record.rate=8000
record.sample_rate=8000
record.channels=1
record.precision=8
record.encoding=mulaw
record.gain=0
record.balance=32
record.port=0x1
record.avail_ports=0x7
record.seek=0
record.samples=0
record.eof=0
record.pause=0
record.error=0
record.waiting=0
record.open=0
record.active=0
record.buffer_size=65536
record.block_size=400
record.errors=0
# mixerctl -v
outputs.master=128,128 volume
inputs.fmsynth=128,128 volume
inputs.fmsynth.mute=off [ off on ]
inputs.fmsynth.swap=off [ off on ]
inputs.cd=128,128 volume
inputs.cd.mute=off [ off on ]
inputs.cd.swap=off [ off on ]
outputs.cd.mute=off [ off on ]
inputs.dac=128,128 volume
inputs.mic=0 volume
inputs.mic.mute=off [ off on ]
inputs.mic.swap=off [ off on ]
outputs.mic.mute=off [ off on ]
inputs.line=0,0 volume
inputs.line.mute=off [ off on ]
inputs.line.swap=off [ off on ]
outputs.line.mute=off [ off on ]
record.source=mic { mic cd line fmsynth }
equalization.treble=128,128 treble
equalization.bass=128,128 bass
inputs.pc_speaker=128 volume
inputs.input=128,128 volume
outputs.output=128,128 volume
inputs.agc=off [ off on ]
dmesg
OpenBSD 4.7-current (GENERIC) #561: Wed Mar 24 20:41:50 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) (GenuineIntel 586-class) 133 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
real mem = 133791744 (127MB)
avail mem = 120848384 (115MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/08/96, BIOS32 rev. 0 @ 0xfbcf0
pcibios0 at bios0: rev 2.1 @ 0xf/0x638
pcibios0: PCI BIOS has 4 Interrupt Routing table entries
pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev
0x00) pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x2800
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 82437FX rev 0x02
pcib0 at pci0 dev 7 function 0 Intel 82371FB ISA rev 0x02
pciide0 at pci0 dev 7 function 1 Intel 82371FB IDE rev 0x02: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no
drives) vga1 at pci0 dev 10 function 0 S3 86C968-0 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ahc0 at pci0 dev 11 function 0 Adaptec
Re: heads up - softraid metadata change
On Fri, 26 Mar 2010 18:31:59 +0100 Mitja MuEeniD mi...@muzenic.net wrote: Joel Sing (jsing@) has just commited to -current a softraid update that bumps the softraid metadata version - see the commit mail and the brief article on Undeadly. The new kernel will not assemble the existing softraid volumes, so special caution is required BEFORE upgrading your -current kernel or moving to next snapshot. http://www.openbsd.org/faq/current.html#20100326 http://marc.info/?l=openbsd-cvsm=126960262412653w=2 http://www.undeadly.org/cgi?action=articlesid=20100326172808 Mitja (looking forward to more softraid goodies! :) Excellent! --It seems we're moving closer to bootable softraid. Thanks Mitja, Joel, and Marco. jcr
Re: trouble showing a kernel dmesg
On Fri, 26 Mar 2010 11:26:01 -0700 patrick keshishian pkesh...@gmail.com wrote: On Fri, Mar 26, 2010 at 3:36 AM, Nick Holland n...@holland-consulting.net wrote: Andreas Gerdd wrote: Hello. I've an Intel E6300 Dual Core 2.8 system. Whenever I try to see such a dmesg output, I get the following: # dmesg -N /bsd.sp dmesg: pread: Bad address dmesg: kvm_read: invalid address (0) (0) However, typing just dmesg works fine, shows the output for GENERIC.MP, but i try to see a dmesg output for the GENERIC kernel as well, so i can send them both to dm...@openbsd.org dmesg is a property of a running kernel, not of a kernel sitting on the disk. If you are running snapshot or release kernels, we know what is in your kernel file, we want to see how it works with your hardware (of course, we also want to see the first few lines which show us what version you are running). So, to get a dmesg from GENERIC.MP, you run bsd.mp, for GENERIC, you run bsd. You can't pull a dmesg out of a kernel that wasn't run [...] If I'm reading this correctly, what you are saying is the -N option to dmesg can be considered to a bug? Nope. The *values* are read from /dev/kmem, or alternatively from a core file via the -M flag. On the other hand the *names* of those values are typically read from /bsd, or alternatively from another kernel file via the -N flag. In other words, you're looking at name-value pairs, where the symbolic names are stored in one place (a kernel file), and the values are stored in another place (typically /dev/kmem of the running kernel, or saved to a core file on a crash). Think about it this way; you use the boot prompt to boot up your experimental kernel named /bsd.exp. It dumps core before you can get a dmesg, so you want to see what the heck was going on. You reboot with your normal kernel /bsd and use dmesg on the core file, and tell it where to find the corresponding names (i.e. in your experimental kernel) # dmesg -M bsd.exp.core -N /bsd.exp Obviously, the default input for values, /dev/kmem, will only give values of the currently running kernel, hence to get those values you either need to running a particular kernel, or crash it to dump core. As for dmesg picking the right kernel file for getting the names of the currently running kernel, there is either some magic in demsg which picks the right kernel from disk, or a properly running kernel does not need to read names from the kernel file since they're already in memory. jcr
Re: trouble showing a kernel dmesg
On Fri, 26 Mar 2010 13:45:44 -0700 Philip Guenther guent...@gmail.com wrote: As for dmesg picking the right kernel file for getting the names of the currently running kernel, there is either some magic in demsg which picks the right kernel from disk, or a properly running kernel does not need to read names from the kernel file since they're already in memory. It's simpler than that: when run without the -N or -M options, dmesg gets the info via sysctl() instead of trying to read from /dev/kmem. This makes it ABI-proof against various kernel or libkvm changes that break code that reads /dev/kmem. That's true not just of dmesg but of all the other programs that need kernel info: ps, netstat, fstat, ipcs, systat, etc. $ sysctl -A kern 21 /dev/null | grep 'use ' | head sysctl: use pstat to view kern.vnode information sysctl: use ps to view kern.proc information sysctl: use pstat to view kern.file information sysctl: use pstat -t to view kern.tty.ttyinfo information sysctl: use dmesg to view kern.msgbuf sysctl: use netstat to view kern.mbstat sysctl: use ps to view kern.proc2 information sysctl: use fstat to view kern.file2 information sysctl: use vmstat or systat to view vm.vmmeter information sysctl: use vmstat or systat to view vm.uvmexp information $ Make sense? Yep. Thank you. I knew at least some of the data was available through sysctl, but I didn't know how, or more importantly, why. The ABI-proffing makes sense. jcr
aucat: default: can't open device
I'm trying to (eventually) test ISA devices with oga@'s and ariane@'s
patches, but for the moment, I'm just getting things working with the
default March 24th snapshot.
One of the (supposedly) working ISA devices I have here is an old
Creative SoundBlaster card, but I can't seem to get it working.
# audioctl {play,record}.block_size
play.block_size=200
record.block_size=400
The above mismatch is not good according to the archives (ratchov@)
http://www.mail-archive.com/misc@openbsd.org/msg70462.html
# audioctl record.block_size=200
record.block_size: 400 - 192
This may, or may not be normal, namely the rounding to 192.
# audioctl play.block_size=192
play.block_size: 200 - 192
# AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -l
sio_open_aucat: trying 0 - 0.default
sio_open_aucat: connect: No such file or directory
sun_setpar: 0: trying pars = 48000/16/6
sun_setpar: couldn't set linear encoding
aucat: default: can't open device
# AUCAT_DEBUG=4 SIO_DEBUG=4 aucat -l -r 8000
sio_open_aucat: trying 0 - 0.default
sio_open_aucat: connect: No such file or directory
sun_setpar: 0: trying pars = 48000/16/6
sun_setpar: couldn't set linear encoding
aucat: default: can't open device
#
Needless to say, I need to get this card working normally before being
able to see if the ISA/DMA patches break it. ;)
I did go through all of the various src/sys/dev/isa/sb* files looking
for something similar to Jake's patch in the link above, but found
nothing.
Any hints would be appreciated. If I missed any needed details below,
let me know what you need.
jcr
***
# mixerctl -v
outputs.master=128,128 volume
inputs.fmsynth=128,128 volume
inputs.fmsynth.mute=off [ off on ]
inputs.fmsynth.swap=off [ off on ]
inputs.cd=128,128 volume
inputs.cd.mute=off [ off on ]
inputs.cd.swap=off [ off on ]
outputs.cd.mute=off [ off on ]
inputs.dac=128,128 volume
inputs.mic=0 volume
inputs.mic.mute=off [ off on ]
inputs.mic.swap=off [ off on ]
outputs.mic.mute=off [ off on ]
inputs.line=0,0 volume
inputs.line.mute=off [ off on ]
inputs.line.swap=off [ off on ]
outputs.line.mute=off [ off on ]
record.source=mic { mic cd line fmsynth }
equalization.treble=128,128 treble
equalization.bass=128,128 bass
inputs.pc_speaker=128 volume
inputs.input=128,128 volume
outputs.output=128,128 volume
inputs.agc=off [ off on ]
***
# audioctl
name=SoundBlaster
version=4.13
config=SB_16
encodings=ulinear:8,mulaw:8*,alaw:8*,slinear:8,slinear_le:16,ulinear_le:16,slinear_be:16*,ulinear_be:16*
properties=full_duplex,mmap,independent
full_duplex=0
fullduplex=0
blocksize=200
hiwat=163
lowat=1
output_muted=0
monitor_gain=0
mode=
play.rate=8000
play.sample_rate=8000
play.channels=1
play.precision=8
play.encoding=mulaw
play.gain=128
play.balance=32
play.port=0x0
play.avail_ports=0x0
play.seek=32600
play.samples=0
play.eof=0
play.pause=0
play.error=0
play.waiting=0
play.open=0
play.active=0
play.buffer_size=32768
play.block_size=200
play.errors=0
record.rate=8000
record.sample_rate=8000
record.channels=1
record.precision=8
record.encoding=mulaw
record.gain=0
record.balance=32
record.port=0x1
record.avail_ports=0x7
record.seek=0
record.samples=0
record.eof=0
record.pause=0
record.error=0
record.waiting=0
record.open=0
record.active=0
record.buffer_size=65536
record.block_size=400
record.errors=0
***
OpenBSD 4.7-current (GENERIC) #561: Wed Mar 24 20:41:50 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium (P54C) (GenuineIntel 586-class) 133 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8
real mem = 133791744 (127MB)
avail mem = 120848384 (115MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 02/08/96, BIOS32 rev. 0 @ 0xfbcf0
pcibios0 at bios0: rev 2.1 @ 0xf/0x638
pcibios0: PCI BIOS has 4 Interrupt Routing table entries
pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev
0x00) pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x2800
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 82437FX rev 0x02
pcib0 at pci0 dev 7 function 0 Intel 82371FB ISA rev 0x02
pciide0 at pci0 dev 7 function 1 Intel 82371FB IDE rev 0x02: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no
drives) vga1 at pci0 dev 10 function 0 S3 86C968-0 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ahc0 at pci0 dev 11 function 0 Adaptec AHA-2940 rev 0x03: irq 9
scsibus0 at
Re: newbie question OpenBSD and Ekiga
On Tue, 23 Mar 2010 16:27:17 +0100 igor igor.k...@zg.t-com.hr wrote: outputs.hp.mute=on inputs.phone.mute=on inputs.mic.mute=on inputs.line.mute=on inputs.cd.mute=on inputs.aux.mute=on Sound recorder in gnome is working, but I usualy use external mic headphones, but I dont have mic headphones here, right now. You didn't really mention how things are wired, but you have mute=on for hp (headphones e.g. 1/8 inch jack) for phone for mic for line (line-in e.g. another 1/8 inch jack) for aux (auxiliary e.g. another 1/8 inch jack) If you flip the correct one to mute=off then it will probably work.
Re: RouterBOARD RB600A support
On Tue, 23 Mar 2010 16:45:51 -0500 Ahlsen-Girard, Edward F CTR USAF AFSOC AFSOC/A6OK edward.ahlsen-girard@hurlburt.af.mil wrote: On Tue, Mar 23, 2010 at 20:50:18, Otto Moerbeek wrote: If two things happen after another, it does not imply that the first caused the second. -Otto Post hoc propter hoc is in fact a logical fallacy, but there's a reason that it's so popular. -- Ed Ahlsen-Girard, Contractor (EITC) AFSOC/A6OK email: edward.ahlsen-girard@hurlburt.af.mil 850-884-2414 DSN: 579-2414 Theo makes one tiny public mention of UFO's and someone with the US Air Force shows up claiming logical fallacy And you call this a coincidence? That's It! I'm going back to Atlantis.
Re: recent hardware with older OpenBSD versions
On Sun, 21 Mar 2010 11:34:14 -0400 Nick Holland n...@holland-consulting.net wrote: The great fantasy of many people in the IT world is lots of identical hardware and software. Sorry, this is completely unrealistic, or at least completely unhealthy, in the big picture. Until they understand reality and finally achieve enlightenment, they should stare at the contents of the drawer where they keep their socks. jcr
Re: freenas-like solution for aoe?
On Sat, 20 Mar 2010 10:48:39 +0100 Vadkan Jozsef jozsi.avad...@gmail.com wrote: Does anybody know a FreeNAS-like solution, that supports AoE? - Ata over Ethernet? Thank you! OpenBSD softraid does have an AoE discipline in the works, but I do not know the status of it. Also, AsiaBSDCon 2010 last week had an OpenBSD presentation on iSCSI which you might want to check out. http://www.openbsd.org/papers.html http://www.ustream.tv/channel/asiabsdcon-2010 http://www.ustream.tv/channel/asiabsdcon-2010-track2 As for the required magic to make the ustream.tv streaming shit work properly, I'm still at a loss. jcr
Re: Need advice re: Wistron CM9 and Net 4501
On Thu, 18 Mar 2010 13:25:35 -0400 daniel d...@redmountainfarm.net wrote: Well, after _way_ too much messing around, I've determined that the mini-pci slot on _my_ (at least) Net 4501 is pretty much useless. Both a new Wistron CM9 and an OEM Intersil Prism (pgt) (taken from an SMC barricade) fail. Don't quote me on these numbers, but the CM9 will draw something like 430ma and the pgt something like 290ma and they both behave the same way. I tried OpenBSD 4.6 (release and patch branch) and 4.7 (various snaps): the cards, once configured and/or are connected to, cause the kernel to spew errors on the console continually and won't stop until a reboot. I'm assuming they are starved for current. Apparently other people have gotten mini-pci wlan cards to work in their Net 4501s, but not me. I'm making my employer buy me a TimeCapsule that I'll put behind my Net 4501 for now. In the future, I'll have to investigate other options like a Net 5501 or even one of the nice RouterBoards mentioned here recently. Thanks to all who chimed in. Daniel http://marc.info/?l=openbsd-miscw=2r=1s=CM9q=b http://marc.info/?l=openbsd-miscm=126891871332534w=2 Though it could be your choice of mini-pci devices, if there really is a problem in your Sokris (such as the slot really is starved of power), then talk to Sokris about it. They'll want to know one way or another about a potential defect and could lead you through proper testing.
Re: format of i386/index.txt
On Wed, 17 Mar 2010 11:34:16 +0100 Jan Stary h...@stare.cz wrote: http://marc.info/?l=openbsd-miscm=126678113118214w=2 Has the format of ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/i386/index.txt changed again? It seems to be 'ls -l' now. Hi Jan, I think this is the second time I've seen you mention the format of the index.txt file... so it seems you're mistakenly trying to parse index.txt to get the file/path names of the stuff you need to download. (pardon me if my mind reading skills are slightly off) --- #!/bin/ksh ftp_host=ftp.openbsd.org basepath=pub/OpenBSD/snapshots arch=`uname -m` ftp -i -n EOF ftp.log open $ftp_host user anonymous none@ nlist $basepath/$arch ftp.files EOF # exclude floppy*.fs and *.iso for FNAME in `grep -v -e \.iso -e \.fs ftp.files | sed -e s:$basepath/$arch/::`; do if [[ -z $FLIST ]]; then FLIST=$FNAME; else FLIST=$FLIST FNAME fi done --- NOTE the for ... is wrapped, The result is $FLIST contains just a list of all the file names of the stuff on the ftp server in the given directory excluding the *.fs and *.iso files. The real magic in the above is in the nlist command of ftp, and you don't necessarily need to do it in a shell script. perl would work equally well. If my mind reading skills are off, and you're trying to check the time stamp of files on the ftp server, then check out the ftp modtime command, and point it at the SHA256 file (that should be there). In other words, the format of index.txt should not matter since there are better ways to get the information you want. jcr
Re: format of i386/index.txt
On Wed, 17 Mar 2010 15:02:19 +0100 Jan Stary h...@stare.cz wrote: Anyway, what really is the purpose of index.txt being there then? To tell the times and sizes? To break scripts? ;) To put it bluntly, index.txt seems pointless, or more likely, there is some super double secret reason for it to still exist that I simply don't know... My only *GUESS* is, some mirrors are HTTP, but due to brainless accountants mindlessly running security auditing tools, they forbid real directory listings, and are configured to only return an existing /index.* file to the useragent. Hopefully, someone who actually has a clue (not me) will chime in with the real reason why index.txt exists. jcr
Re: installing amd64 using i386 to boot then amd64 for install?
On Tue, 16 Mar 2010 14:59:01 +1100 Cameron Simpson c...@zip.com.au wrote: I have the apparently common problem of CD2 (amd64) from the OpenBSD distro not booting on an IBM x336. And of course there's no floppy and the box won't boot off a USB device at all. apparently common ? --Never heard of it. If there is something wrong with your install media for amd64, then download the ISO and burn a new copy. ftp://ftp.openbsd.org/pub/OpenBSD/4.6/amd64/install46.iso Even better, since we're right next to 4.7 release, install the most recent -current snapshot: ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/install47.iso Your subsequent upgrade to 4.7 -release in a month or two will go a lot more smoothly. One of the avenues I'm considering is booting off the i386 CD1 and then using the CD2 disc for the install data. Will that work, or will the i386 install still load up some inappropriate i386 items (eg the boot sector)? Why shoot yourself in the foot? A better and supported alternative is to netboot the system with the correct bsd.rd kernel and install the sets via ftp. this isn't rocket surgery
Re: installing amd64 using i386 to boot then amd64 for install?
On Tue, 16 Mar 2010 12:30:15 + (UTC) Stuart Henderson s...@spacehopper.org wrote: On 2010-03-16, Cameron Simpson c...@zip.com.au wrote: I have the apparently common problem of CD2 (amd64) from the OpenBSD distro not booting on an IBM x336. And of course there's no floppy and the box won't boot off a USB device at all. One of the avenues I'm considering is booting off the i386 CD1 and then using the CD2 disc for the install data. Will that work, or will the i386 install still load up some inappropriate i386 items (eg the boot sector)? Has anyone done this? if it doesn't boot at all, follow the basic method in 4.2 errata 003 http://www.openbsd.org/errata42.html The VMware August Surprise approach keeps looking better and better. ;)
Re: How to make FTP work from the firewall system?
On Tue, 16 Mar 2010 12:39:01 -0400 (EDT) Dave Anderson d...@daveanderson.com wrote: I see two options: 1. pass out This can work for passive FTP if one is willing to allow outbound connections to all non-privileged ports, but is useless for active FTP. Yes. 2. ftp-proxy(8) Unless I've missed something, this is useless when the FTP connection originates on the system where ftp-proxy is running -- the control connection packets must traverse some interface in the inbound direction for PF to be able to redirect them to ftp-proxy. No. Just configure your app to use the proxy bound to localhost:port. Many apps can pick this up automatically when you have FTP_PROXY= defined in your shell, but others might require further configuration.
Re: How to make FTP work from the firewall system?
On Tue, 16 Mar 2010 13:24:21 -0400 (EDT) Dave Anderson d...@daveanderson.com wrote: A clarification: I do know that ftp-proxy can be used as an explicit proxy as well as transparently via PF redirection, and that the FTP_PROXY environment variable can be set to specify an explict proxy for many programs/scripts. But since (as stated in my original message) I'd really like FTP to 'just work' and AFAIK some programs/scripts ignore FTP_PROXY and some others don't allow for an explicit proxy at all, I believe that ftp-proxy can't currently do what I want (though it may come closer than anything else currently available). Dave There are two things I need to do 1.) Sleep 2.) install the latest snap on my firewall for figuring this out. *if* what you want is possible with ftp-proxy(8) and redirection, then the magic rule you're looking for will look something like this. match out on ? proto tcp from ? to any port ftp \ rdr-to 127.0.0.1 port 8021 Without testing it, I don't know how the potential loop can be avoided, or if it even needs to be avoided (note the match out example for isakmp in the pf.conf(5) man page).
Re: OpenBSD 4.7 pre-orders are live!
On Sat, 13 Mar 2010 19:53:12 -0700 Ted Roby ted.r...@gmail.com wrote: On Sat, Mar 13, 2010 at 7:42 PM, Jason Dixon ja...@dixongroup.net wrote: https://https.openbsd.org/cgi-bin/order?CD47=1CD47%2b=Add -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/ You're late! I already put my order in with the USA distributor as soon as I saw Theo's post. Their automated service says they'll be shipping it to me this coming Monday. Somehow, I think I'll be getting a follow-up email instead. heh, I still think I beat you. Order number 2010/3/13-17:22:5-7789: :) jcr
Re: breeding developers
On Sun, 14 Mar 2010 08:52:29 +0100 (CET) Antoine Jacoutot ajacou...@bsdfrog.org wrote: Hi. I'm usually not very active on misc@ but since pre-order for 4.7 have started, I think it is the right time to remind us all that CD sales are not only important but critical to the project. First, lack of money means less hackathons, which renders hacking less fun, and fun is the number 1 motivation for most people imho. No money - no hackathon - no fun - no hack... you see the point. Also a project this big (yes, a hobby can be huge) does not rules itself out of the air and money is needed for infrastructure, administration, hardware and tons of other things. So if you like OpenBSD, don't forget its biannual bithday and buy CDs. If you don't like OpenBSD, then buy even more CDs because having competition is good for other projects. Thank you all. -- Antoine Antoine, Though supporting the project with purchases is always very important, your thoughts on developing developers or as you said breeding developers are equally important. As Theo taught me a decade ago, the project is code. There are people like me, normal users, who support the project in simple ways like purchases, and then there are people like you who do the real work of writing great code, maintaining steelix, and similar. The difference is substantial, but not very well understood. jcr
Re: Opteron 250 Overheating
On Sun, 14 Mar 2010 17:10:07 -0400 Steve Shockley steve.shock...@shockley.net wrote: On 3/14/2010 4:11 PM, Bruce O'Neel wrote: Seriously, 40s should feel hot. 80s should burn. 100s should leave a blister. True, but even with 100C core temps the heat sink will probably be nowhere close to that. My apologies if following my advice would have changed your thumbprint. And I thought your suggestion was intentional... http://www.popsci.com/technology/article/2009-12/chinese-woman-surgically-switches-fingerprints-evade-japanese-immigation-officers
