use sndiod remote microphone
have read http://www.openbsd.org/faq/faq13.html#audioserver now two OpenBSD pc A B A add sndiod_flags=-L- to /etc/rc.conf.local, plug in a microphone. so B how to set and use the remote mic? what i want: 1. B can hear the sound from A's mic (live broadcast). 2. What program in B should I use?
Re: What should we look before buying a laptop?
On Sun, Aug 25, 2013 at 10:19:11PM -0600, Michael Paul Zamot wrote: Hello, my name is Michael Paul Zamot, I'm from Costa Rica. I'm using OpenBSD since two months ago and I'm in love with it. I'm planning buying a laptop, perhaps a screen of 11 or 12 inches. I would like to know if you know about a compatible model, under $400. What should I look before buying one? Any recommendations? With recent addition of AMD KMS and Intel KMS I don't think video would be an issue. Thanks! In my experience, now that video is out of the way, the thing to look out most for is getting a well supported built-in wireless card. That's starting to become difficult when buying new laptops because most drivers are lacking support for newer hardware variants. If the built-in wireless card doesn't work, your options are to replace it with a supported card or get a supported USB-based one. If you shop around for used minipci cards or USB wifi sticks with names matching the ones listed in driver man pages, you should get lucky. Note that some laptops (e.g. Thinkpads) do not allow the built-in cards to be replaced unless the new card matches a whitelist stored in the BIOS. There are various hacks around this, but it's a nuisance. Some card readers in newer laptops might not be supported either, especially if they're realtek ones (these don't look like standard SD host controllers). OpenBSD currently supports one realtek card reader version, the RTS5209. But there are other versions out there, which may also be supported in the future.
Re: use sndiod remote microphone
On Mon, Aug 26, 2013 at 11:47:03AM +0800, Fung wrote: have read http://www.openbsd.org/faq/faq13.html#audioserver now two OpenBSD pc A B A add sndiod_flags=-L- to /etc/rc.conf.local, plug in a microphone. so B how to set and use the remote mic? on host B, any program using snd@hosta/0 as audio device will record sound from the microphone of A rather than the local microphone (hosta is hostname or address of A). Example, on B: aucat -f snd@hosta/0 -o /tmp/foo.wav would record from the microphone of host A into /tmp/foo.wav what i want: 1. B can hear the sound from A's mic (live broadcast). 2. What program in B should I use? you need a program that records and then plays what it recorded, the following could somewhat work: aucat -f snd@hosta/0 -o - | aucat -i - does it? The sound may skip periodically because A's sampling rate is not strictly the same as B's sampling rate. -- Alexandre
Re: Developing device driver for parallel lcd dispaly modules
Hi Alexander, Yes, i'm talking about 2*20 character LCD display connected to 24 pin parallel port on motherboard. I've tried to access this device simply via this command: # echo Test /dev/lpt0 ksh: cannot create /dev/lpt0: Device busy Yeah, failed. Do you suggest any other method/code to try if /dev/lpt0 accessable? I had thought that a driver would be needed cause the vendor had Linux and FreeBSD driver included in CD. By the way that the vendor is Lanner INC and device is FW-7581A. Thanks. Denis
Re: Developing device driver for parallel lcd dispaly modules
On Monday, August 26, 2013 10:41 CEST, Denis Maros denisalima...@gmail.com wrote: Hi Alexander, Yes, i'm talking about 2*20 character LCD display connected to 24 pin parallel port on motherboard. I've tried to access this device simply via this command: # echo Test /dev/lpt0 ksh: cannot create /dev/lpt0: Device busy Yeah, failed. Do you suggest any other method/code to try if /dev/lpt0 accessable? I had thought that a driver would be needed cause the vendor had Linux and FreeBSD driver included in CD. By the way that the vendor is Lanner INC and device is FW-7581A. I don't know if comms/lcdproc supports LCD displays on parallel port, but it may worth give it a try. cheers, Sebastian Thanks. Denis
Re: Developing device driver for parallel lcd dispaly modules
Hi Sebastian, I've already tried lcdproc but got no success. 2013/8/26 Sebastian Reitenbach sebas...@l00-bugdead-prods.de On Monday, August 26, 2013 10:41 CEST, Denis Maros denisalima...@gmail.com wrote: Hi Alexander, Yes, i'm talking about 2*20 character LCD display connected to 24 pin parallel port on motherboard. I've tried to access this device simply via this command: # echo Test /dev/lpt0 ksh: cannot create /dev/lpt0: Device busy Yeah, failed. Do you suggest any other method/code to try if /dev/lpt0 accessable? I had thought that a driver would be needed cause the vendor had Linux and FreeBSD driver included in CD. By the way that the vendor is Lanner INC and device is FW-7581A. I don't know if comms/lcdproc supports LCD displays on parallel port, but it may worth give it a try. cheers, Sebastian Thanks. Denis
Re: Developing device driver for parallel lcd dispaly modules
Hi, On 26 August 2013 14:11, Denis Maros denisalima...@gmail.com wrote: Yes, i'm talking about 2*20 character LCD display connected to 24 pin parallel port on motherboard. I've tried to access this device simply via this command: # echo Test /dev/lpt0 If it's one of the common Hitachi-compatible LCDs (and it almost certainly is) https://en.wikipedia.org/wiki/Hitachi_HD44780_LCD_controller You can't just send characters at it like that; the dance is a little more complicated. Strongly recommend reading the datasheet that came with the device. You shouldn't need a kernel driver. As long as you've got it wired up correctly you should be able to do everything in userspace. John
Re: IPSec and routing of IPv6
On 2013-08-25, Gregor Best g...@ring0.de wrote: Hi people, I am having a few problems getting routing of IPv6 over IPSec to work. I have two nodes, one is a server, one is my laptop. On the server, I have IPv6 access over a gif interface. There is a /64 routed to the server, which I want to use on my laptop. I have now set up an IPSec tunnel between my laptop and the server, with the following configuration, in /etc/ipsec.conf: # on my laptop unobtanium_v6 = 2001:470:1f0b:1d3::/64 ike esp from any to $unobtanium_v6 peer unobtanium.de \ main auth hmac-sha1 enc aes-256 \ quick auth hmac-sha1 enc aes-256 \ psk secretkey \ tag IPSEC-UNO # on the server unobtanium_v6 = 2001:470:1f0b:1d3::/64 ike passive esp from $unobtanium_v6 to any \ main auth hmac-sha1 enc aes-256 \ quick auth hmac-sha1 enc aes-256 \ psk Sahpeque2quieC8e \ tag IPSEC-UNO On the laptop you would usually have something like ike dynamic esp from $laptop_ip to any [...], and on the server ike passive esp from $server_network to any [...]. The link between both machines seems to be up and running. On both machines, I have configured a bridge with the link2 flag set, which according to the manpage causes IPSec traffic to be sent over the bridge. The bridges each have a vether device in them, with addresses in the subnet in the ipsec.conf. I don't see why you would use bridge/vether here. vether is for special cases (the original scenario it was developed for was to have a gif/ethernet bridge on one network, and gif/vether bridge on a box running bgpd, to save using a separate box bridging gifethernet), for what you're doing, a standard ipsec tunnel should be sufficient. Pinging the other side of the tunnel works fine, as does other direct traffic, but only if it does not originate from the link-local address of the vether device. Your configuration doesn't deal with link-local addresses. Using tcpdump on pflog0 with a pass log inet6 in /etc/pf.conf, does not show anything. Shouldn't traffic at least show up in pf? What did I miss? Using from any to any does not change the situation at hand. Are you allowing ip6 forwarding (sysctl net.inet6.ip6.forwarding=1)?
Re: In some man pages Mb means MB, in others it means Mb/s
On 2013-08-24, Jason McIntyre j...@kerhand.co.uk wrote: as far as packages, i doubt the man pages would be changed. i guess you could talk to the individual port maintainer if you wanted. this type of patch wouldn't be appropriate for the ports tree. sometimes you will have success if you contact upstream, but I am sure you will then end up with some of them switching to dreadful MiB etc. ;)
Re: Developing device driver for parallel lcd dispaly modules
On 26/08/2013 09:41, Denis Maros wrote: Yes, i'm talking about 2*20 character LCD display connected to 24 pin parallel port on motherboard. I've tried to access this device simply via this command: # echo Test /dev/lpt0 ksh: cannot create /dev/lpt0: Device busy Yeah, failed. Do you suggest any other method/code to try if /dev/lpt0 accessable? I had thought that a driver would be needed cause the vendor had Linux and FreeBSD driver included in CD. By the way that the vendor is Lanner INC and device is FW-7581A. I suspect an LCD module is unlikely to work while driving it as if it were a parallel port printer. The issue is the protocol. A printer uses the Centronics interface e.g.: http://retired.beyondlogic.org/epp/epp.htm LCD modules vary, but tend to use some variation of the following: http://www.newbiehack.com/MicrocontrollersABeginnersGuideIntroductionandInterfacinganLCD.aspx For one thing, an LCD module has commands (to set the mode, clear the display, configuration etc) - it doesn't just take ASCII characters. Using the parallel port however is often just a convenient way of getting some logic-level signals in and out... but you're probably going to need to bit-bang them (i.e. control them individually) yourself, rather than using a parallel-port protocol. HTH, Steve
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Kinda off topic and I take it you were being sarcastic, but your mentioning of the dreadful MiB reminded me about the LibreOffice spreadsheet I'm using to calculate from GiB/GB to sectors so that I can have disklabel(8) partition my harddisks according to standard units. Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? After all it's been a while since it was logical (!) to infer that since 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must *almost* be 1000^3 (giga).. ;) Personally I would love to see disklabel(8) default to display sizes in base-10 and with something like an optional -i or -2 switch to display information in the old (current) base 2 definition. At least it would be nice if it were using proper units - like GiB instead of GB. Cheers, Erling
Re: What should we look before buying a laptop?
On 2013-08-26 00:42, Stefan Sperling wrote: In my experience, now that video is out of the way, the thing to look out most for is getting a well supported built-in wireless card. That's starting to become difficult when buying new laptops because most drivers are lacking support for newer hardware variants. If the built-in wireless card doesn't work, your options are to replace it with a supported card or get a supported USB-based one. If you shop around for used minipci cards or USB wifi sticks with names matching the ones listed in driver man pages, you should get lucky. Note that some laptops (e.g. Thinkpads) do not allow the built-in cards to be replaced unless the new card matches a whitelist stored in the BIOS. There are various hacks around this, but it's a nuisance. Some card readers in newer laptops might not be supported either, especially if they're realtek ones (these don't look like standard SD host controllers). OpenBSD currently supports one realtek card reader version, the RTS5209. But there are other versions out there, which may also be supported in the future. Thanks Stefan. Are there any particular laptop model you can recommend? Regards, Michael Zamot
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 03:06:22PM +0200, Erling Westenvik wrote: On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Kinda off topic and I take it you were being sarcastic, but your mentioning of the dreadful MiB reminded me about the LibreOffice spreadsheet I'm using to calculate from GiB/GB to sectors so that I can have disklabel(8) partition my harddisks according to standard units. Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? After all it's been a while since it was logical (!) to infer that since 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must *almost* be 1000^3 (giga).. ;) Personally I would love to see disklabel(8) default to display sizes in base-10 and with something like an optional -i or -2 switch to display information in the old (current) base 2 definition. At least it would be nice if it were using proper units - like GiB instead of GB. Imo you are introducing a new meaning of proper. Disk sizes have been in base 2 units since forever. The fact that marketing material uses base 10 units does not change what's proper. -Otto
Re: In some man pages Mb means MB, in others it means Mb/s
On 2013-08-26, Erling Westenvik erling.westen...@gmail.com wrote: On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Kinda off topic and I take it you were being sarcastic, but your mentioning of the dreadful MiB reminded me about the LibreOffice spreadsheet I'm using to calculate from GiB/GB to sectors so that I can have disklabel(8) partition my harddisks according to standard units. disklabel(8) already understands standard units, no need for spreadsheets. The built-in label editor (fourth form) provides a simple interactive label editor. Some commands or prompts take an optional unit. Available units are `b' for bytes, `c' for cylinders, `k' for kilobytes, `m' for megabytes, `g' for gigabytes, and `t' for terabytes. If no unit is given, the default is to use sectors (usually 512 bytes). Quantities will be rounded to the nearest cylinder when units are specified for sizes (or offsets). Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? After all it's been a while since it was logical (!) to infer that since 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must *almost* be 1000^3 (giga).. ;) Personally I would love to see disklabel(8) default to display sizes in base-10 and with something like an optional -i or -2 switch to display information in the old (current) base 2 definition. At least it would be nice if it were using proper units - like GiB instead of GB. IMHO: damn the hard drive vendors. Traditional terminology in computing has always been to use powers of two...
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? I have a strong opinion against it. The benefits are overstated. I believe When in Unix, ... After all it's been a while since it was logical (!) to infer that since 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must *almost* be 1000^3 (giga).. ;) Almost has never been the problem in real life, or to bring it closer to home -- in real system administration. The question we face is enough. As the capacity of equipment grows faster than the needs for data storage, enough is easy to satisfy. These new units create as much harm by requiring more comprehension space -- ie. concern is not just about having the space, but you need to remember which of the two units you are in, so that you don't accidentally convert backwards once in a while. It becomes critical to show the actual unit visibly, in every step, like in a column or on a label. That is a step backwards. Disk: wd0 geometry: 155061/16/63 [156301488 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 1 - 16382 15 63 [ 63:16514001 ] OpenBSD If the argument was about almost enough space, now it is about not enough space to put the unit letters. Personally I would love to see disklabel(8) default to display sizes in base-10 and with something like an optional -i or -2 switch to display information in the old (current) base 2 definition. At least it would be nice if it were using proper units - like GiB instead of GB. And then we can modify the installer to ask which unit people prefer? Not a step forward.
Re: In some man pages Mb means MB, in others it means Mb/s
Imo you are introducing a new meaning of proper. Disk sizes have been in base 2 units since forever. The fact that marketing material uses base 10 units does not change what's proper. Here's a suggestion for new prefixes in use of these units. Full prefix plus unit shown for example. Kaybytes Maybytes Gaybytes Taybytes Basically, you're allowed to be sloppy, and numbers can range roughly between the pow2 and pow10 values. The result is less exactness (bummer), but there is less confusion because there is less expectation of accuracy and exactness. The prefixes are intentionally silly as a result. we'll need support in the disklabel and fdisk programs, more questions in the install script. I'll send off a note to ICWM/CGPM/CCU/SI, hmm, which commitee do I send it to... The lesson? Any agency in control of rules that are simple and good, will soon forget that simple is one of the things that makes it good, and thus ruin it.
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 07:29:24AM -0600, Theo de Raadt wrote: On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? I have a strong opinion against it. The benefits are overstated. Dammit, I'll create a fork called BiKiNiBSD! ;) I believe When in Unix, ... After all it's been a while since it was logical (!) to infer that since 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must *almost* be 1000^3 (giga).. ;) Almost has never been the problem in real life, or to bring it closer to home -- in real system administration. The question we face is enough. As the capacity of equipment grows faster than the needs for data storage, enough is easy to satisfy. Agreed. Of course. My concern is not about tweaking space. These new units create as much harm by requiring more comprehension space -- ie. concern is not just about having the space, but you need to remember which of the two units you are in, so that you don't accidentally convert backwards once in a while. It becomes critical to show the actual unit visibly, in every step, like in a column or on a label. That is a step backwards. Disk: wd0 geometry: 155061/16/63 [156301488 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 1 - 16382 15 63 [ 63:16514001 ] OpenBSD (So it is true about the backdoors in OpenBSD? How else did you get access to my disk!?!) Okay, as for any need to understand how (why) disk space should (must) be understood in terms of base-2 sizes, I'm really way out of my league. Lets say I'm happening to have lots of smaller disks that I'd like to create partitions for on larger disks. Reading on the label on one such small disk that it has a capacity of 160GB, and knowing that this means 160 * 1000^3 bytes, makes it easy to create a partition that big on a larger disk without having to remember the 9 or 10 digit sector size or to look up the size in GB (eg. GiB) on the MBR or disklabel for the smaller disk. Maybe a stupid example, perhaps, but still. It's just about the potential mess with confusing unit values. I guess all it boils down to is the question why OpenBSD shouldn't use standard unit names, that is GiB for gigabytes and GB for gibibytes? http://en.wikipedia.org/wiki/Gigabyte http://en.wikipedia.org/wiki/Orders_of_magnitude_(data Wouldn't it be according to OpenBSD's goal to follow standards, avoiding ambiguities? I don't think users will have problems remembering what units they are in, at least not if the units are correct. If the argument was about almost enough space, now it is about not enough space to put the unit letters. Personally I would love to see disklabel(8) default to display sizes in base-10 and with something like an optional -i or -2 switch to display information in the old (current) base 2 definition. At least it would be nice if it were using proper units - like GiB instead of GB. And then we can modify the installer to ask which unit people prefer? Not a step forward. Forget that I asked about having optional switches. However, I do feel that my above question about using proper (!) unit names is relevant. It's not a big issue and I may not be binary enough to understand the importance of these matters. Cheers, Erling
Re: What should we look before buying a laptop?
On Sun, Aug 25, 2013 at 10:19:11PM -0600, Michael Paul Zamot wrote: Hello, my name is Michael Paul Zamot, I'm from Costa Rica. I'm using OpenBSD since two months ago and I'm in love with it. I'm planning buying a laptop, perhaps a screen of 11 or 12 inches. I would like to know if you know about a compatible model, under $400. What should I look before buying one? Any recommendations? With recent addition of AMD KMS and Intel KMS I don't think video would be an issue. Stilll must avoid nvidia. Ken Thanks!
Re: In some man pages Mb means MB, in others it means Mb/s
On 2013 Aug 26 (Mon) at 16:55:33 +0200 (+0200), Erling Westenvik wrote: :I guess all it boils down to is the question why OpenBSD shouldn't use :standard unit names, that is GiB for gigabytes and GB for gibibytes? We *are* using the standard unit names. Marketting droids aren't allowed to create standards, especially when they are utterly stupid. -- In Devon, Connecticut, it is unlawful to walk backwards after sunset.
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 07:53:55AM -0600, Theo de Raadt wrote: Imo you are introducing a new meaning of proper. Disk sizes have been in base 2 units since forever. The fact that marketing material uses base 10 units does not change what's proper. Here's a suggestion for new prefixes in use of these units. Full prefix plus unit shown for example. Kaybytes Maybytes Gaybytes Taybytes LOL! :D Basically, you're allowed to be sloppy, and numbers can range roughly between the pow2 and pow10 values. The result is less exactness (bummer), but there is less confusion because there is less expectation of accuracy and exactness. The prefixes are intentionally silly as a result. we'll need support in the disklabel and fdisk programs, more questions in the install script. I'll send off a note to ICWM/CGPM/CCU/SI, hmm, which commitee do I send it to... The lesson? Any agency in control of rules that are simple and good, will soon forget that simple is one of the things that makes it good, and thus ruin it. Okay, I'll take it is a proposal for unit names for the upcoming quantum arch..? Anyway, I'll rest my case, shut up and just continue to USE OpenBSD! :)
Re: What should we look before buying a laptop?
On 2013-08-26 00:42, Stefan Sperling wrote: If the built-in wireless card doesn't work, your options are to replace it with a supported card or get a supported USB-based one. If you shop around for used minipci cards or USB wifi sticks with names matching the ones listed in driver man pages, you should get lucky. Note that some laptops (e.g. Thinkpads) do not allow the built-in cards to be replaced unless the new card matches a whitelist stored in the BIOS. There are various hacks around this, but it's a nuisance. I don't know what I will buy for my next laptop. It used to be a no-brainer, buy a thinkpad, but the newer lenovo models are of distinctly shoddy quality compared to what IBM used to put out. Proof being my latest laptop, which happens to have the same keyboard model as the old IBM thinkpad, except that it's mostly plastic instead of metal, and it stopped working properly fairly soon (I did actually replace it with the keyboard from the older laptop, which is how I noticed the abysmal drop in component quality there)...
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 10:07:01AM -0400, Kenneth R Westerback wrote: On Mon, Aug 26, 2013 at 03:06:22PM +0200, Erling Westenvik wrote: On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Kinda off topic and I take it you were being sarcastic, but your mentioning of the dreadful MiB reminded me about the LibreOffice spreadsheet I'm using to calculate from GiB/GB to sectors so that I can have disklabel(8) partition my harddisks according to standard units. Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? There are violent and possibly homicidal opinions against such a move. Mine being one. gibi is gibberish. At least I did not ask which shell is best or why gimp can't be part of base.. I agree that unit names like kibi, mibi and gibi may seem somewhat ridiculous, but the point, in my view, is that kilo and giga are base-10 (metric) values. Maybe the JEDEC/IEC units will make sense the day we have disks with capacities in the excess of 2^1000 bytes?
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 03:06:22PM +0200, Erling Westenvik wrote: On Mon, Aug 26, 2013 at 11:27:36AM +, Stuart Henderson wrote: you will then end up with some of them switching to dreadful MiB etc. ;) Kinda off topic and I take it you were being sarcastic, but your mentioning of the dreadful MiB reminded me about the LibreOffice spreadsheet I'm using to calculate from GiB/GB to sectors so that I can have disklabel(8) partition my harddisks according to standard units. Are there strong opinions against following standards and start converting to the proper terms for gigabytes (decimal, base 10, 1GB = 1000^3 bytes) and gibibytes (binary, base 2, 1 GiB = 1024^3 bytes)? There are violent and possibly homicidal opinions against such a move. Mine being one. gibi is gibberish. Ken After all it's been a while since it was logical (!) to infer that since 1024^1 (kibi) is *almost* 1000^1 (kilo), then 1024^3 (gibi) must *almost* be 1000^3 (giga).. ;) Personally I would love to see disklabel(8) default to display sizes in base-10 and with something like an optional -i or -2 switch to display information in the old (current) base 2 definition. At least it would be nice if it were using proper units - like GiB instead of GB. Cheers, Erling
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 04:55:33PM +0200, Erling Westenvik wrote: I guess all it boils down to is the question why OpenBSD shouldn't use standard unit names, that is GiB for gigabytes and GB for gibibytes? Now, that was kinda embarrasing. Of course I meant GB for gigabytes and GiB for gibibytes. I'll just go and kill myself...
Re: In some man pages Mb means MB, in others it means Mb/s
On 08/26/2013 10:55 AM, Erling Westenvik wrote: ... Lets say I'm happening to have lots of smaller disks that I'd like to create partitions for on larger disks. Reading on the label on one such small disk that it has a capacity of 160GB, and knowing that this means 160 * 1000^3 bytes, makes it easy to create a partition that big on a larger disk without having to remember the 9 or 10 digit sector size or to look up the size in GB (eg. GiB) on the MBR or disklabel for the smaller disk. Maybe a stupid example, perhaps, but still. It's just about the potential mess with confusing unit values. if you are designing your file systems based on marketing stickers on the drive, you have a bigger problem, really. (hint: what happens when your new 2TB disk is actually a very tiny bit smaller than your original 2TB disk? A friend of mine once spent a lot of time trying to figure out a RAID Rebuild problem because Seagate sold drives with the same model number...but different numbers of usable sectors...in this case, they were off one sector smaller than the first batch of drives!) I guess all it boils down to is the question why OpenBSD shouldn't use standard unit names, that is GiB for gigabytes and GB for gibibytes? you keep using this word standard. I do not think it means what you think it means. I've been following computers since the late 1970s. At that time, it was not decided if the 8080 and z80 CPUs could access 64K or 65K of RAM. Really, no one cared. We generally knew it was the same thing, and no one had the money for that much RAM in a computer anyway. Sure, a few idiots went for a computer advertising a 65k capacity because it was 1k more than the 64k computers, even more comical because they would never put more than 16k RAM in 'em (by the time people actually started maxing out the 8bit computers, we'd pretty well settled on 64k. Standard set. When 'k' got absurdly small, we adopted M and G and now T. Disk makers, in spite of the fact that their drives are accessed in binary, and the file systems on those drives generally have structures with limits based in binary, decided that as the computer industry went mass market, they would switch to using non-binary data units for binary data to make their drives look bigger to the novices. May I suggest you instead spend your time trying to persuade the drive manufacturers to revert their drives to appropriate data processing units of measure? At least that would be a positive change for the world, unlike codifying committee crap standards. http://en.wikipedia.org/wiki/Gigabyte http://en.wikipedia.org/wiki/Orders_of_magnitude_(data Wouldn't it be according to OpenBSD's goal to follow standards, avoiding ambiguities? I don't think users will have problems remembering what units they are in, at least not if the units are correct. no, this is just plain stupid, a bunch of people spent someone else's money to come up with a unneeded and non-accepted standard that doesn't need to be there. And a few more people feel the need to make a name for themselves by pushing this nonstandard on those that actually make things happen in this business. Repeat bull enough times, some people might start thinking it is fertilizer. But not here. Nick.
Re: What should we look before buying a laptop?
On 08/26/2013 09:24 AM, Michael Paul Zamot wrote: ... Are there any particular laptop model you can recommend? Regards, Michael Zamot same advices as always... Load OpenBSD on a flash drive. Go to the store, boot from the flash drive, see how it runs OpenBSD...and put your fingers on the keyboard, use the mouse-replacement-device, and see how the screen looks FOR YOU. Hearing that Fred loves his model XYZ laptop doesn't matter one bit to you if you get to the store and all they have is the XYZrev2. All you can be fairly sure of is the Rev2 is probably cheaper to build than the original. But I'm buying it mail order I do not understand buying laptops mail order. If my desktop comes with a crappy keyboard or mouse, I go grab one of my Model M's from my pile, and a different mouse. But that defeats the purpose of a laptop. I want a good keyboard, I want a good mouse-like-device. And I want it to run my OS. There's no good way to test for that without putting YOUR hands on the device. But...I don't have a local retailer! better get a good return policy, then. I don't care what OS you are running...a crappy keyboard or a crappy mouse-like device is still not going to be good to use. You also have to worry about how the OS runs on it, that's just one more reason. Personally, I used to be really picky. But, as my current life requires I be passably proficient on a lot of different keyboards, I gave up my obsession with the best devices, and have settled on sufficiently good. But there is still a lot of crap I hate (i.e., this laptop I'm working on now with a useless trackpad, backed up by a stick mouse that makes the trackpad look almost usable. There's an external mouse plugged into it. So much for portability). Nick.
Installation on EdgeRouter Lite
Hello, I'm just reading through Octeon installation instructions: http://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon What caught my attention is a statement: There is no USB support yet, which means that there is no storage (no onboard CompactFlash), and Ethernet isn't supported either. If neither storage nor network work, how is one supposed to install the OS? -- Twoje radio
Re: In some man pages Mb means MB, in others it means Mb/s
On Mon, Aug 26, 2013 at 12:01:25PM -0400, Nick Holland wrote: On 08/26/2013 10:55 AM, Erling Westenvik wrote: ... Lets say I'm happening to have lots of smaller disks that I'd like to create partitions for on larger disks. Reading on the label on one such small disk that it has a capacity of 160GB, and knowing that this means 160 * 1000^3 bytes, makes it easy to create a partition that big on a larger disk without having to remember the 9 or 10 digit sector size or to look up the size in GB (eg. GiB) on the MBR or disklabel for the smaller disk. Maybe a stupid example, perhaps, but still. It's just about the potential mess with confusing unit values. if you are designing your file systems based on marketing stickers on the drive, you have a bigger problem, really Please. happens when your new 2TB disk is actually a very tiny bit smaller than your original 2TB disk? A friend of mine once spent a lot of time trying to figure out a RAID Rebuild problem because Seagate sold drives with the same model number...but different numbers of usable sectors...in this case, they were off one sector smaller than the first batch of drives!) I guess all it boils down to is the question why OpenBSD shouldn't use standard unit names, that is GiB for gigabytes and GB for gibibytes? you keep using this word standard. I do not think it means what you think it means. I've been following computers since the late 1970s. At that time, it was not decided if the 8080 and z80 CPUs could access 64K or 65K of RAM. Really, no one cared. We generally knew it was the same thing, and no one had the money for that much RAM in a computer anyway. Sure, a few idiots went for a computer advertising a 65k capacity because it was 1k more than the 64k computers, even more comical because they would never put more than 16k RAM in 'em (by the time people actually started maxing out the 8bit computers, we'd pretty well settled on 64k. The best would perhaps have been if they back then realizied how sloppy it was to state that 1000 = 1024 -- for computers, and instead took the relativly small effort it would have been to create a logical set of genuine computing units for the future? As I wrote in my answer to Theo, I may not be binary enough since I happen to be more loyal to the word kilo than to the word byte. It feels like being forced to say that a kilometre is 1609 meters in the US and 1000 meters in Europe. And that's all there is to it from my point of view. The use of kilobyte as meaning 1024 bytes lacks rationale (at least when honoring the meaning of kilo) and appears to be based on old convention backed up by habit. But I admit that there is more to this than I first realized and that I'm probably doing hair-splitting by now. I'll try to read myself up on the subject. Meanwhile I rest my case. Thanks for the discussion! Standard set. When 'k' got absurdly small, we adopted M and G and now T. Disk makers, in spite of the fact that their drives are accessed in binary, and the file systems on those drives generally have structures with limits based in binary, decided that as the computer industry went mass market, they would switch to using non-binary data units for binary data to make their drives look bigger to the novices. May I suggest you instead spend your time trying to persuade the drive manufacturers to revert their drives to appropriate data processing units of measure? At least that would be a positive change for the world, unlike codifying committee crap standards. http://en.wikipedia.org/wiki/Gigabyte http://en.wikipedia.org/wiki/Orders_of_magnitude_(data Wouldn't it be according to OpenBSD's goal to follow standards, avoiding ambiguities? I don't think users will have problems remembering what units they are in, at least not if the units are correct. no, this is just plain stupid, a bunch of people spent someone else's money to come up with a unneeded and non-accepted standard that doesn't need to be there. And a few more people feel the need to make a name for themselves by pushing this nonstandard on those that actually make things happen in this business. (How could I know this was a topic considered banned? I noticed that IEC has defined a base-10 standard which is adopted by most harddisk manufacturers and it made sense to me, that's all. For all I know this could have been an issue of interest, just with low priority.) Repeat bull enough times, some people might start thinking it is fertilizer. But not here. (I guess. Hopefully such people don't try to make fertilizer bombs. Whoops, there I accidentally triggered PRISM and surely will have NSA on the door later tonight...)
PF+ALTQ and real time monitoring
Hi, can anyone tell me the best or at least the most used real time bandwith monitoring tool, when using the PF+ALTQ solution please? thanks in advance.
EuroBSDCon 2013 early bird rates through August 31
EuroBSDCon 2013, set in sunny Malta, is only a month away. The main program is at http://2013.eurobsdcon.org/eurobsdcon-2013/talks-and-schedule/ Register via http://2013.eurobsdcon.org/eurobsdcon-2013/registration/, early bird rates apply through August 31. See you in Malta! - Peter (Program committee member and speaker) -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: PF+ALTQ and real time monitoring
On Mon, 26 Aug 2013 14:24:12 -0400, Andres Chavez
fluxboxtrem...@gmail.com wrote:
Hi, can anyone tell me the best or at least the most used real time
bandwith monitoring tool, when using the PF+ALTQ solution please?
thanks in advance.
We use Graphite for the display of data received by statsd, we then run
the following script using cron every 60 seconds to transmit the PF queues
to statsd (I'm not a great coder by any stretch of the imagination so
please feel free to clean/optimise/improve it (pls share and let me know if
you do ;)
NB; test_master is a check to exit the script if it is not the CARP
master, as this script also runs on all our remote office firewalls which
have IPSec VPNs to head office (where the graphite/statsd server is
located). Currently if a CARP backup firewall tries to send data back, it
will try and send the data itself (and not via the CARP master) even
thought the IPSec tunnel is only valid on the CARP master, this causes the
firewalls back at head office to immediately distrust the IPSec VPN and so
break it completely due to receiving the IPSec payload from the backup. I
have mentioned this before on here and think I need to build a gif tunnel
or do something else (someone gave a good suggestion for this but I haven't
had time to fix it).
NB; phys_iface is generated by a 'puppet facter' in our case, this can of
course be replaced with a manual string.
NB; The drop_rates_file_base file is monitored by Nagios to provide us an
Alarm if a particular queue is saturating and dropping packets heavily.
NB; Replace %=@hostname-% with the servers hostname or let puppet do it
#!/usr/local/bin/python
# Script to extract queue stats from the ALTQ PF Queues, and transmit to
statsd for graphite graphing, and local logging for Nagios alerting
# Written and maintained by Andrew Lemin
import re
import subprocess
import socket
import logging
from subprocess import Popen, PIPE
from time import sleep, time
logging.basicConfig(filename='/var/log/pf_queue_monitor.log',
level=logging.DEBUG, format='%(asctime)s %(levelname)s %(name)s
%(message)s')
logger=logging.getLogger(__name__)
# Check is 'master'
import sys
def test_master():
p1 = subprocess.Popen(str(/sbin/ifconfig).split(),
stdout=subprocess.PIPE)
p1.wait()
p2 = subprocess.Popen([grep,status: master], stdin=p1.stdout,
stdout=subprocess.PIPE)
p2.wait()
p3 = subprocess.Popen(str(wc -l).split(), stdin=p2.stdout,
stdout=subprocess.PIPE)
p1.stdout.close()
p2.stdout.close()
master = int(p3.communicate()[0])
if master == 0: sys.exit()
test_master()
## all_iface set by puppet from 'facter interfaces'
#all_iface = %=@interfaces%.split(',')
all_iface =
lo0,em0,em1,em2,em3,em4,em5,enc0,pflog0,pflog1,pflog2,pflow0,pfsync0,carp0,carp1,carp2,carp3,carp4.split(',')
regex = re.compile('lo|pf|carp|enc')
phys_iface = [x for x in all_iface if not regex.match(x)]
drop_rates_file_base=/var/spool/pf_queue_drop_rate
run_time=55
graphite=IP ADDRESS of STATSD
def netcat(hostname, port, content):
s = socket.socket(family=socket.AF_INET,type=socket.SOCK_DGRAM)
s.settimeout(3)
try:
s.sendto(content,(hostname,port))
except socket.error as err:
logger.error(err)
#print(content)
s.close()
s = None
def get_queue_stats(iface):
try:
p1 = subprocess.Popen(str(/sbin/pfctl -s queue
-v).split(), stdout=subprocess.PIPE)
p1.wait()
p2 = subprocess.Popen(str(grep -A1 %s %
(iface)).split(), stdin=p1.stdout, stdout=subprocess.PIPE)
p2.wait()
p3 = subprocess.Popen(str(sed -e s/^q/Zq/;).split(),
stdin=p2.stdout, stdout=subprocess.PIPE)
p3.wait()
p4 = subprocess.Popen([tr,\n, ], stdin=p3.stdout,
stdout=subprocess.PIPE)
p4.wait()
p5 = subprocess.Popen([tr,Z,\n], stdin=p4.stdout,
stdout=subprocess.PIPE)
p5.wait()
p6 = subprocess.Popen([sed,-e,s/ */ /g],
stdin=p5.stdout, stdout=subprocess.PIPE)
p6.wait()
p7 = subprocess.Popen(str(grep _wan_).split(),
stdin=p6.stdout, stdout=subprocess.PIPE)
p7.wait()
p8 = subprocess.Popen(str(grep -v root_).split(),
stdin=p7.stdout, stdout=subprocess.PIPE)
p8.wait()
p9 = subprocess.Popen(str(grep -v {.*}).split(),
stdin=p8.stdout, stdout=subprocess.PIPE)
p1.stdout.close()
p2.stdout.close()
p3.stdout.close()
p4.stdout.close()
p5.stdout.close()
p6.stdout.close()
p7.stdout.close()
p8.stdout.close()
output = p9.communicate()[0]
except Exception as err:
logger.error(err)
stats={}
for entry in output[1:].splitlines():
Re: how to aggregate a single TCP connection, is posible?
This is a question with many solutions, each with their own benefits and disadvantages and is a subject of some history. If you are connecting two servers directly together without using a switch in-between them, then round-robin is for you. However if you need to have switches in the mix there are many things that need to be considered. The most limiting factor is you have to connect both cables to the same single switch to use trunks, or purchase multiple very expensive switches which support sharing MAC address tables between them if you want to connect a cable to each one to achieve improved redundancy as well as aggregated performance. If this is to connect through a Core-Distribution tiered setup then again you are going to need some decent kit. The cheap, and I personally think, awesome new solution which is a very hot topic at the moment is 'Multi-Path TCP'. This is a technology where no trunks are needed, and 'dumb' cheap switches can be used. The paths don't even need to be the same networks. Each interface is configured like a standard single interface with its own IP address. mptcp builds individual sessions using each of the interfaces and then aggregates the traffic in the kernel stack. This technology is designed to allow aggregation of 'any' type of IP interface including 3G, WiFI and LAN for example. The extra optional TCP headers are used to achieve it all, and keep processing/reordering overhead to a minimum etc. mptcp is currently still in late beta stages but is under heavy development and already being used across Amazon's data centres. It is not long from being included into the Linux kernel as standard (you can add it manually very easily). Hopefully OpenBSD will also include the algorithms at some point. It was announced and demonstrated at RIPE's last conference and has been presented at many other prestigious forums, and is being contributed to by many other big providers as well as Amazon. We are planning to roll mptcp out across all our data-centres in 2014. Anyway, hope this gives you some useful ideas. Andrew Lemin On Fri, 23 Aug 2013 18:39:29 -0500, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: Not yet, will test. On Thu, Aug 22, 2013 at 7:05 AM, Stuart Henderson s...@spacehopper.org wrote: On 2013-08-22, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: Is there a way to duplicate the throughput of a single TCP connection using two servers having two gigabit NICs? I have tried using LACP but I cannot get more than 900MB of throughput... LACP uses a hash over IP addresses/vlan tags/flowlabel to avoid problems with out-of-order packet delivery. (Similar for equal-cost multipath). Have you tried a roundrobin trunk yet?
Re: X reverts to vesa driver with 2013-AUG-24 snapshot
On Mon, Aug 26, 2013 at 12:35:18PM -0700, patrick keshishian wrote:
help?
should I wait for next snapshot?
Some of the integrated graphics parts were previously disabled
due to various issues. The radeondrm code we have now is a
complete re-port though so try this:
Index: radeon_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.3
diff -u -p -r1.3 radeon_kms.c
--- radeon_kms.c16 Aug 2013 19:53:53 - 1.3
+++ radeon_kms.c27 Aug 2013 00:38:49 -
@@ -345,7 +345,6 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS300|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_IGP9100,
CHIP_RS300|RADEON_IS_IGP|RADEON_IS_MOBILITY},
-#if 0
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS480,
CHIP_RS480|RADEON_IS_IGP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS480_B,
@@ -354,14 +353,12 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS480|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS482_B,
CHIP_RS480|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_IS_IGPGART},
-#endif
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280_PRO, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280_B, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280_SE_S, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_FIREMV_2200, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_ES1000, CHIP_RV100},
-#if 0
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS400,
CHIP_RS400|RADEON_IS_IGP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS400_B,
@@ -370,7 +367,6 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS400|RADEON_IS_IGP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RC410_B,
CHIP_RS400|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_IS_IGPGART},
-#endif
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X300,
CHIP_RV380|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X600_RV370,
@@ -611,14 +607,12 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS300|RADEON_IS_IGP|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS350IGP,
CHIP_RS300|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
-#if 0
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1250_1,
CHIP_RS690|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1250_2,
CHIP_RS690|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1250IGP,
CHIP_RS690|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART},
-#endif
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_FIREGL_V4000,
CHIP_RV610|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_FIREMV_2260,
Re: X reverts to vesa driver with 2013-AUG-24 snapshot
On 8/26/13, Jonathan Gray j...@jsg.id.au wrote:
On Mon, Aug 26, 2013 at 12:35:18PM -0700, patrick keshishian wrote:
help?
should I wait for next snapshot?
Some of the integrated graphics parts were previously disabled
due to various issues. The radeondrm code we have now is a
complete re-port though so try this:
Thanks for the reply. I'll give this a go as soon as I get
a breather.
Curious, the snapshot from Aug 17th worked just fine.
I didn't scrutinize it too much then, but the X session seemed
fine to me, vs. the VESA one now that looks just wrong.
Cheers,
--patrick
Index: radeon_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.3
diff -u -p -r1.3 radeon_kms.c
--- radeon_kms.c 16 Aug 2013 19:53:53 - 1.3
+++ radeon_kms.c 27 Aug 2013 00:38:49 -
@@ -345,7 +345,6 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS300|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_IGP9100,
CHIP_RS300|RADEON_IS_IGP|RADEON_IS_MOBILITY},
-#if 0
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS480,
CHIP_RS480|RADEON_IS_IGP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS480_B,
@@ -354,14 +353,12 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS480|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS482_B,
CHIP_RS480|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_IS_IGPGART},
-#endif
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280_PRO, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280_B, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RV280_SE_S, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_FIREMV_2200, CHIP_RV280},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_ES1000, CHIP_RV100},
-#if 0
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS400,
CHIP_RS400|RADEON_IS_IGP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS400_B,
@@ -370,7 +367,6 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS400|RADEON_IS_IGP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RC410_B,
CHIP_RS400|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_IS_IGPGART},
-#endif
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X300,
CHIP_RV380|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X600_RV370,
@@ -611,14 +607,12 @@ const struct drm_pcidev radeondrm_pciidl
CHIP_RS300|RADEON_IS_IGP|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_RS350IGP,
CHIP_RS300|RADEON_IS_IGP|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
-#if 0
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1250_1,
CHIP_RS690|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1250_2,
CHIP_RS690|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1250IGP,
CHIP_RS690|RADEON_IS_IGP|RADEON_NEW_MEMMAP|RADEON_IS_IGPGART},
-#endif
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_FIREGL_V4000,
CHIP_RV610|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_FIREMV_2260,
Re: X reverts to vesa driver with 2013-AUG-24 snapshot
On Mon, Aug 26, 2013 at 10:45:00PM -0700, patrick keshishian wrote: On 8/26/13, Jonathan Gray j...@jsg.id.au wrote: On Mon, Aug 26, 2013 at 12:35:18PM -0700, patrick keshishian wrote: help? should I wait for next snapshot? Some of the integrated graphics parts were previously disabled due to various issues. The radeondrm code we have now is a complete re-port though so try this: Thanks for the reply. I'll give this a go as soon as I get a breather. Curious, the snapshot from Aug 17th worked just fine. I didn't scrutinize it too much then, but the X session seemed fine to me, vs. the VESA one now that looks just wrong. xf86-video-ati was updated to version 7.2.0 which no longer supports userland modedesetting. So if a device doesn't match radeondrm it won't have any way of doing modesetting and will fall back to using vesa. I think I'll just commit the diff to enable the igp devices as it should work. Let us know how it goes, and remember to install the radeon firmware if you haven't already.
