Re: record off of uaudio device (help?)
patrick keshishian wrote: I should have been more specific with my question and subject line: I don't see where aucat's -f device values are documented. I suppose you overlooked sndio(7). Googling finds old (google-cached) current.html pages, circa 2009, suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at first failed: $ aucat -f sun:1 -m rec -o /tmp/test.wav sio(sun:1|): busy loop, disconnecting This should work, unfortunately (according to ratchov@) there's possibly a bug in the (obscure) buffering of USB audio devices which makes this fail for some devices. (Mine happens to be 2-ch, 24-bit @ 44100 Hz, in case that matters) A bit more googling finds this post[1] suggesting addition of -z 256 to aucat, which seems to make things work. $ aucat -z 256 -f sun:1 -o /tmp/test.wav ^C So, yes, in this case it's necessary to specify a buffer size. (in my experience many buffer sizes will work, the one aucat calculates just doesn't)
Re: support needed with traffic shaping
On 2012-02-18, Michael Seiwald mich...@mseiwald.at wrote:
Hello all,
I've been playing around with pf's altq feature for the last two days. I
want to achieve that my server ($srv) always has 50 % of the bandwidth
for downloading available and can also borrow the other 50 % if they
are not needed by other clients in the LAN. Currently I have the
following pf.conf:
http://pastie.org/3406858
From what I have read in the documentation and seen in examples this
should do what I want. The problem is that I only get about 0.33 Mbps on
speedtest.net in the std_in queue instead of 50% of my downstream.
The firewall rule creating state (and assigning the queue) for
connections initiated by the server is probably not the one you
expect. pfctl -ss -v will show you the rule number then you can
lookup the rule with pfctl -sr -R (number). 'sudo systat q .5'
is also good as a fast-updating display of queue use.
Simplest way to fix is probably to use 'match' instead e.g.:
match from $srv queue srv
match to $srv queue srv
No need for specific assignments for traffic which will go in
the default queue anyway.
I normally put these at the top of the ruleset with the altq
definitions.
Also SSH connections from a LAN client to the OpenBSD gateway lag and are
almost unusable.
I would appreciate any advice to fix my pf.conf...
There's no reason these wouldn't be affected by the queue too.
You could use a higher bandwidth queue on the interface, have
a child queue for the internet traffic containing your std_in and
srv_in queues, and another local queue alongside it, then match
traffic from/to the gateway and assign it to the local queue.
interface
|
+-- local (say 50Mb)
|
+-- internet (3.5Mb, *not* borrow)
|
+-- srv (1.75Mb borrow)
|
+-- std (1.75Mb)
If you later want to add queueing for *upstream* traffic (which
is really where queueing works best) then just use the same queue
names ('queue std on $int_if...' and 'queue std on $ext_if'),
don't use separate std_out/srv_out queues.
Re: record off of uaudio device (help?)
On Sun, Feb 19, 2012 at 12:54 AM, Remco re...@d-compu.dyndns.org wrote: patrick keshishian wrote: I should have been more specific with my question and subject line: I don't see where aucat's -f device values are documented. I suppose you overlooked sndio(7). Nope, I read that page. There is no mention of 'sun:x' in that page. There is, however, a reference to 'rsnd/0' being 'First hardware audio device', but trying it and having it fail (before learning of '-z nframes' option) brought me to misc@. I think this can be documented better in aucat(1) with a concrete example or two. --patrick Googling finds old (google-cached) current.html pages, circa 2009, suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at first failed: $ aucat -f sun:1 -m rec -o /tmp/test.wav sio(sun:1|): busy loop, disconnecting This should work, unfortunately (according to ratchov@) there's possibly a bug in the (obscure) buffering of USB audio devices which makes this fail for some devices. (Mine happens to be 2-ch, 24-bit @ 44100 Hz, in case that matters) A bit more googling finds this post[1] suggesting addition of -z 256 to aucat, which seems to make things work. $ aucat -z 256 -f sun:1 -o /tmp/test.wav ^C So, yes, in this case it's necessary to specify a buffer size. (in my experience many buffer sizes will work, the one aucat calculates just doesn't)
Re: record off of uaudio device (help?)
On Sunday 19 February 2012 11:32:25 you wrote: On Sun, Feb 19, 2012 at 12:54 AM, Remco re...@d-compu.dyndns.org wrote: patrick keshishian wrote: I should have been more specific with my question and subject line: I don't see where aucat's -f device values are documented. I suppose you overlooked sndio(7). Nope, I read that page. There is no mention of 'sun:x' in that page. There is, however, a reference to 'rsnd/0' being 'First hardware audio device', but trying it and having it fail (before learning of '-z nframes' option) brought me to misc@. I think this can be documented better in aucat(1) with a concrete example or two. --patrick I missed that you're running CURRENT (I was referring to 5.0). AFAICT the sun:x names are deprecated in CURRENT though they may still work. I think you should be able to access the device by the 'rsnd/1' name, albeit specifying the buffer size would still be a necessity.
Re: alix2d2 LM86, no hw.sensors
On Sun, Feb 19, 2012 at 00:06 +0100, Mike Belopuhov wrote: On Sat, Feb 18, 2012 at 03:09 +1100, Jonathan Gray wrote: On Fri, Feb 17, 2012 at 04:20:25PM +0100, Michal Mazurek wrote: I have an alix2d2 running OpenBSD 5.0. There are no hw.sensors. The producer says there is an LM86 on board, which is supported by the maxtmp driver. It appears the driver is present in generic. I tried starting sensorsd but got: daemon:Feb 17 13:12:04 T1 sensorsd[10445]: startup, system has 0 sensors How can I read the temperature of my alix2d2 running OpenBSD 5.0? There is no driver for the CS5535/CS5536 I2C controller the chip is connected to, it won't work till that is written. [un]surprisingly it's actually the same as gscsio(4). here's a port of that code to glxpcib(4). i don't have the hardware at hand, but i encourage you to test (: cheers Index: dev/pci/files.pci === RCS file: /cvs/src/sys/dev/pci/files.pci,v retrieving revision 1.281 diff -u -p -r1.281 files.pci --- dev/pci/files.pci 15 Nov 2011 22:27:53 - 1.281 +++ dev/pci/files.pci 18 Feb 2012 23:03:52 - @@ -807,6 +807,6 @@ attachitherm at pci file dev/pci/itherm.citherm # AMD Geode CS5536 PCI-ISA bridge -device glxpcib: isabus, gpiobus +device glxpcib: isabus, gpiobus, i2cbus attach glxpcib at pci file dev/pci/glxpcib.c glxpcib and i forgot to mention that kernel config has to be patched too. thanks to shadchin@ for reminding. Index: arch/i386/conf/GENERIC === RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v retrieving revision 1.730 diff -u -p -r1.730 GENERIC --- arch/i386/conf/GENERIC 28 Jan 2012 00:39:15 - 1.730 +++ arch/i386/conf/GENERIC 19 Feb 2012 12:10:56 - @@ -91,6 +91,7 @@ gscpcib* at pci? # NS Geode SC1100 PCI- gpio* at gscpcib? glxpcib* at pci? # AMD CS5536 PCI-ISA bridge gpio* at glxpcib? +iic* at glxpcib? kate* at pci? # AMD K8 temperature sensor km*at pci? # AMD K10 temperature sensor amas* at pci? disable # AMD memory configuration Index: arch/loongson/conf/GENERIC === RCS file: /cvs/src/sys/arch/loongson/conf/GENERIC,v retrieving revision 1.36 diff -u -p -r1.36 GENERIC --- arch/loongson/conf/GENERIC 7 Jul 2011 23:41:09 - 1.36 +++ arch/loongson/conf/GENERIC 19 Feb 2012 12:10:56 - @@ -39,6 +39,7 @@ pci* at bonito? # Lemote Lynloong, Lemote Fuloong 2F and Lemote Yeeloong devices glxpcib* at pci? gpio* at glxpcib? +iic* at glxpcib? isa0 at glxpcib? mcclock0 at isa? port 0x70 pckbc0 at isa? # Yeeloong only
Re: record off of uaudio device (help?)
On Feb 18 16:59:32, patrick keshishian wrote: Can someone point me to some docs explaining how I can record off of a uaudio device I plugged in? Same as with any other device: http://www.openbsd.org/faq/faq13.html#recordaudio [after plugging in uaudio device] uaudio0 at uhub0 port 3 configuration 1 interface 0 E-MU Systems, Inc. E-MU 0202 | USB rev 2.00/1.00 addr 3 uaudio0: audio rev 1.00, 3 mixer controls audio1 at uaudio0 now what? man aucat man sndio, see DEVICE NAMES aucat -f snd/1 -o /tmp/rec.wav On Feb 18 22:36:45, patrick keshishian wrote: I should have been more specific with my question and subject line: I don't see where aucat's -f device values are documented. In man sndio(7), which man aucat(1) tells you to read. Googling finds old (google-cached) current.html pages, circa 2009, Howls of derisive laughter, Bruce! A bit more googling finds this post[1] suggesting addition of -z 256 [1] http://old.nabble.com/aucat-bug-in-4.8-beta-i386---td29333138.html to aucat, which seems to make things work. $ aucat -z 256 -f sun:1 -o /tmp/test.wav -z specifies the blocksize; that alone doesn't make the audio device record or not. Also, a lot has changed in sndio since 4.8 beta. Don't google around, just read the FM.
eng.takgold
eng.takgold Ola, Se os outros produtos da Polishop sco considerados faceis de serem vendidos, esse daqui, entco, i brincadeira. Basta combinar TAK GOLD antes das 2 principais refeigues diarias, com atividades fmsicas e uma alimentagco balanceada, para vocj poder eliminar ati 2.000 calorias de gordura ingerida em apenas 8 dias. Vocj vai adorar! Esse i um produto que as pessoas vco te ligar pedindo mais. Quem i que nco quer os resultados de um produto desse? Entco, aproveite logo para fazer o seu cadastro e poder ser o responsavel pela colocagco de um produto como esse no mercado. I muito simples efetuar as suas vendas. Quando vocj faz o cadastro ja recebe uma Loja Virtual com a cara da Polishop. Ora, basta enviar o link da sua loja para as pessoas adquirirem os seus produtos. Veja mais detalhes desse maravilhoso produto: Conhega tambim nossa proposta de negscio e todos os detalhes do projeto atravis das nossas Conferjncias on-line: De segunda a sexta feira, `s 15 horas, e todos os dias, `s 21 horas (horario de Brasmlia), neste link: http://www.gvolive.com/conference,99038583 Identifique-se na sala desta forma: C - Seu Nome - Valdemir FAGA O CADASTRO CLICANDO NO LINK ABAIXO: http://www.polishop.com.vc/vcaraujo Valdemir Araujo E-mail: valdemir.araujo2...@yahoo.com.br MSN: valdemirvcara...@hotmail.com Skype: valdemirvcaraujo (62) 8205-5794 - Celular - Tim (62) 3085-2400 - Residencial Gostou desta mensagem? Indique para seus amigos. Compartilhe: Sistema Winner - Polishop, Polishop com voce, o melhor negscio para vocj, Nco perca e saiba mais. Brazil You may unsubscribe or change your contact details at any time. -- Esta mensagem foi verificada pelo sistema de antivmrus e acredita-se estar livre de perigo.
Hidden Long Filenames and mount_cd9660
Hiya misc@, Upfront: if you have something useful to say, CC me, please. I haven't been on this list in a while, managing to solve my own shit before having to mail the hivemind, but today I am at a loss. I have some old DVD backups from the days when backing up to DVD sort of made sense, and now I'm trying to extricate them from their prison. Some have broken down and are full of I/O errors or won't mount at all, but others work fine. The trouble I'm having is that, in those that will mount, some (but only -some-!) show up with 8.3 (aka short aka DOS) filenames. I've booted my server into Linux and confirmed that, all else being equal, Linux gives long file names and OpenBSD doesn't for these disks, so *the metadata is* there and OpenBSD is doing it wrong. The head-scratching thing is that for some disks OpenBSD works like you'd expect, it's only some disks which teleport it to the stone age. I expect there's something weird about the metadata (having or not having proper Joliet or Rock Ridge attributes, I guess?), but I'm damned if I know what they are (I made these disks on Windows, with Nero probably, before I was on the path of enlightenment). I don't really care the cause, I just want my data: is there a way to -force- OpenBSD to pay attention to the long file names? mount_cd9660's -e, -g, -j and -R, much like the goggles, do nothing. Halpp! Here's what cd-info(1) (for the archives: this is from package libcdio) has to say about a DVD that OpenBSD shows LFNs for: ~$ cd-info --dvd cd-info version 0.80 i386-unknown-openbsd4.9 Copyright (c) 2003, 2004, 2005, 2007, 2008 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CD location : /dev/rcd0c CD driver name: OpenBSD access mode: READ_CD Vendor : TSSTcorp Model : CD/DVDW TS-H652D Revision: GA01 Hardware : CD-ROM or DVD Can eject : Yes Can close tray: Yes Can disable manual eject : Yes Can select juke-box disc : No Can set drive speed : No Can read multiple sessions (e.g. PhotoCD) : Yes Can hard reset device : Yes Reading Can read Mode 2 Form 1 : Yes Can read Mode 2 Form 2 : Yes Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes Can read C2 Errors : Yes Can read IRSC : Yes Can read Media Channel Number (or UPC) : Yes Can play audio : Yes Can read CD-DA : Yes Can read CD-R : Yes Can read CD-RW : Yes Can read DVD-ROM: Yes Writing Can write CD-RW : Yes Can write DVD-R : Yes Can write DVD-RAM : Yes Can write DVD-RW: No Can write DVD+RW: No __ Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (501) truncated to 99. 170: 99:24:74 447224 leadout (1003 MB raw, 873 MB formatted) __ CD An alysis Report CD-ROM with ISO 9660 filesystem and joliet extension level 3 ISO 9660: 2256224 blocks, label `GOSHA_DOCUMENTS ' Application: NERO BURNING ROM Preparer : Publisher : System : Volume : GOSHA_DOCUMENTS Volume Set : ~$ and one that OpenBSD shows SFNs for: ~$ cd-info --dvd [snip common drive info] Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (507) truncated to 99. 170: 99:16:26 446576 leadout (1001 MB raw, 872 MB formatted) __ CD Analysis Report ISO 9660: 2279017 blocks, label `G Save B 6 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 6 Volume Set : UDF: version 0.00 and another: Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (505) truncated to 99. 170: 99:57:63 449688 leadout (1008 MB raw, 878 MB formatted) __ CD Analysis Report ISO 9660: 2269454 blocks, label `G Save B 7 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 7 Volume Set : UDF: version 0.00 So, obviously, the clue is that Roxio obviously
ALIX segfaulting on current/i386
On a recent install of current/i386 on an ALIX (see dmesg below), processes (such as a simple 'ls') started to magically segfault and die. Feb 19 14:43:17 www /bsd: pid 26001 (bogofilter): user write of 4096@0x3d5b000 at 1776 failed: 14 Feb 19 14:44:08 www /bsd: pid 7571 (bogofilter): user write of 4096@0x2cfe000 at 1360 failed: 14 Feb 19 14:45:04 www /bsd: pid 9409 (sh): user write of 4096@0x8434b000 at 99760 failed: 14 Feb 19 14:45:12 www /bsd: pid 18943 (cron): user write of 4096@0x7c23e000 at 165360 failed: 14 Feb 19 14:46:38 www /bsd: pid 18781 (error): user write of 118784@0x2eddd000 at 145008 failed: 14 Feb 19 14:47:39 www /bsd: pid 10912 (flush): user write of 4096@0xb0dc000 at 1360 failed: 14 Feb 19 14:47:52 www /bsd: pid 13255 (cleanup): user write of 4096@0x66 at 1872 failed: 14 What does this indicate? Is my RAM bad? Is my CF card bad? Could someone more knowledgeable please explain the above messages in detail? The system acts as a NAT router, and in that respect, nothing wrong happens to the clients - I browse the web and everything from behind this machine. But when it does something IO related (such as opening my mailbox when I launch mutt), it _sometimes_ segfaults now. For example: I tried to run 'file file.core' in a ktrace. That ended in a segfault. The kdump ends with 22449 file CALL sigprocmask(SIG_BLOCK,0x) 22449 file RET sigprocmask 0 22449 file CALL mprotect(0x3c005000,0x1000,0x3PROT_READ|PROT_WRITE) 22449 file RET mprotect 0 22449 file CALL mprotect(0x3c005000,0x1000,0x1PROT_READ) 22449 file RET mprotect 0 22449 file CALL sigprocmask(SIG_SETMASK,0) 22449 file RET sigprocmask -65793/0xfffefeff 22449 file PSIG SIGSEGV SIG_DFL code SEGV_MAPERR1 addr=0x87fb313c trapno=2 22449 file NAMI file.core Thank you for you time Jan OpenBSD 5.1-beta (GENERIC) #140: Sat Jan 21 00:40:23 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 432 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 133758976 (127MB) avail mem = 121544704 (115MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:12:9f:2c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:12:9f:2d ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:0d:b9:12:9f:2e ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 12 function 0 Ralink RT2560 rev 0x01: irq 9, address 00:11:09:0d:d3:36 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: LEXAR ATA FLASH CARD wd0: 1-sector PIO, LBA, 15263MB, 31260096 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 mtrr: K6-family MTRR support (2 registers) nvram: invalid checksum vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (5bea3261eefd6b7e.a) swap on wd0b dump on wd0b clock: unknown CMOS layout
Re: Hidden Long Filenames and mount_cd9660
Why not find a Windows box to dump the data to a Linux server? Problem solved. On Feb 19, 2012 8:54 AM, Nick Guenther n...@kousu.ca wrote: Hiya misc@, Upfront: if you have something useful to say, CC me, please. I haven't been on this list in a while, managing to solve my own shit before having to mail the hivemind, but today I am at a loss. I have some old DVD backups from the days when backing up to DVD sort of made sense, and now I'm trying to extricate them from their prison. Some have broken down and are full of I/O errors or won't mount at all, but others work fine. The trouble I'm having is that, in those that will mount, some (but only -some-!) show up with 8.3 (aka short aka DOS) filenames. I've booted my server into Linux and confirmed that, all else being equal, Linux gives long file names and OpenBSD doesn't for these disks, so *the metadata is* there and OpenBSD is doing it wrong. The head-scratching thing is that for some disks OpenBSD works like you'd expect, it's only some disks which teleport it to the stone age. I expect there's something weird about the metadata (having or not having proper Joliet or Rock Ridge attributes, I guess?), but I'm damned if I know what they are (I made these disks on Windows, with Nero probably, before I was on the path of enlightenment). I don't really care the cause, I just want my data: is there a way to -force- OpenBSD to pay attention to the long file names? mount_cd9660's -e, -g, -j and -R, much like the goggles, do nothing. Halpp! Here's what cd-info(1) (for the archives: this is from package libcdio) has to say about a DVD that OpenBSD shows LFNs for: ~$ cd-info --dvd cd-info version 0.80 i386-unknown-openbsd4.9 Copyright (c) 2003, 2004, 2005, 2007, 2008 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CD location : /dev/rcd0c CD driver name: OpenBSD access mode: READ_CD Vendor : TSSTcorp Model : CD/DVDW TS-H652D Revision: GA01 Hardware : CD-ROM or DVD Can eject : Yes Can close tray: Yes Can disable manual eject : Yes Can select juke-box disc : No Can set drive speed : No Can read multiple sessions (e.g. PhotoCD) : Yes Can hard reset device : Yes Reading Can read Mode 2 Form 1 : Yes Can read Mode 2 Form 2 : Yes Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes Can read C2 Errors : Yes Can read IRSC : Yes Can read Media Channel Number (or UPC) : Yes Can play audio : Yes Can read CD-DA : Yes Can read CD-R : Yes Can read CD-RW : Yes Can read DVD-ROM: Yes Writing Can write CD-RW : Yes Can write DVD-R : Yes Can write DVD-RAM : Yes Can write DVD-RW: No Can write DVD+RW: No __** Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (501) truncated to 99. 170: 99:24:74 447224 leadout (1003 MB raw, 873 MB formatted) __** CD An alysis Report CD-ROM with ISO 9660 filesystem and joliet extension level 3 ISO 9660: 2256224 blocks, label `GOSHA_DOCUMENTS ' Application: NERO BURNING ROM Preparer : Publisher : System : Volume : GOSHA_DOCUMENTS Volume Set : ~$ and one that OpenBSD shows SFNs for: ~$ cd-info --dvd [snip common drive info] Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (507) truncated to 99. 170: 99:16:26 446576 leadout (1001 MB raw, 872 MB formatted) __** CD Analysis Report ISO 9660: 2279017 blocks, label `G Save B 6 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 6 Volume Set : UDF: version 0.00 and another: Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (505) truncated to 99. 170: 99:57:63 449688 leadout (1008 MB raw, 878 MB formatted) __** CD Analysis Report ISO 9660: 2269454 blocks, label `G Save B 7 ' Application:
Re: smartphones and managing openbsd servers
Hello Marcos, What newer smartphones do you recommend for using also as a tool for managing OpenBSD servers (maybe windogs too) ? What experiences had you had with smartphones and OpenBSD managing? I use iSSH on an iPhone. But only in an emergency when I don't have anything else. I wouldn't make regular use of it. (ie, twice in the last year) Luke
Re: Hidden Long Filenames and mount_cd9660
Nick Guenther wrote: Here's what cd-info(1) (for the archives: this is from package libcdio) has to say about a DVD that OpenBSD shows LFNs for: ~$ cd-info --dvd cd-info version 0.80 i386-unknown-openbsd4.9 Copyright (c) 2003, 2004, 2005, 2007, 2008 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CD location : /dev/rcd0c CD driver name: OpenBSD access mode: READ_CD Vendor : TSSTcorp Model : CD/DVDW TS-H652D Revision: GA01 Hardware : CD-ROM or DVD Can eject : Yes Can close tray: Yes Can disable manual eject : Yes Can select juke-box disc : No Can set drive speed : No Can read multiple sessions (e.g. PhotoCD) : Yes Can hard reset device : Yes Reading Can read Mode 2 Form 1 : Yes Can read Mode 2 Form 2 : Yes Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes Can read C2 Errors : Yes Can read IRSC : Yes Can read Media Channel Number (or UPC) : Yes Can play audio : Yes Can read CD-DA : Yes Can read CD-R : Yes Can read CD-RW : Yes Can read DVD-ROM: Yes Writing Can write CD-RW : Yes Can write DVD-R : Yes Can write DVD-RAM : Yes Can write DVD-RW: No Can write DVD+RW: No __ Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (501) truncated to 99. 170: 99:24:74 447224 leadout (1003 MB raw, 873 MB formatted) __ CD Analysis Report CD-ROM with ISO 9660 filesystem and joliet extension level 3 ISO 9660: 2256224 blocks, label `GOSHA_DOCUMENTS ' Application: NERO BURNING ROM Preparer : Publisher : System : Volume : GOSHA_DOCUMENTS Volume Set : ~$ and one that OpenBSD shows SFNs for: ~$ cd-info --dvd [snip common drive info] Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (507) truncated to 99. 170: 99:16:26 446576 leadout (1001 MB raw, 872 MB formatted) __ CD Analysis Report ISO 9660: 2279017 blocks, label `G Save B 6 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 6 Volume Set : UDF: version 0.00 and another: Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (505) truncated to 99. 170: 99:57:63 449688 leadout (1008 MB raw, 878 MB formatted) __ CD Analysis Report ISO 9660: 2269454 blocks, label `G Save B 7 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 7 Volume Set : UDF: version 0.00 So, obviously, the clue is that Roxio obviously didn't put Joliet data on the discs (grrr), which Nero did on the other one. But nevertheless the long file names *are* there because linux reads them. Is there any way to make OpenBSD find the long names anyway? Thanks to all you lovely misc@ers, -Nick If I'm not mistaken your LFN disc only show ISO9660, the SFN discs have an additional UDF: version 0.00 marker. I've never used it so I don't know if it's the right tool for the job but there is mount_udf(8) on OpenBSD. I'll leave it to you if you want to risk trying it, or wait for more knowledgeable people to chime in.
Re: smartphones and managing openbsd servers
What newer smartphones do you recommend for using also as a tool for managing OpenBSD servers (maybe windogs too) ? What experiences had you had with smartphones and OpenBSD managing? BlackBerry has built in VPN and you can also buy a few different SSH and SFTP apps.
Re: ALIX segfaulting on current/i386
Try with the last snapshot: OpenBSD 5.1 (GENERIC) #160: Sun Feb 12 09:46:33 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC I have the same machine and no problems. On Sun, 19 Feb 2012 15:17:41 +0100, Jan Stary wrote: On a recent install of current/i386 on an ALIX (see dmesg below), processes (such as a simple 'ls') started to magically segfault and die. Feb 19 14:43:17 www /bsd: pid 26001 (bogofilter): user write of 4096@0x3d5b000 at 1776 failed: 14 Feb 19 14:44:08 www /bsd: pid 7571 (bogofilter): user write of 4096@0x2cfe000 at 1360 failed: 14 Feb 19 14:45:04 www /bsd: pid 9409 (sh): user write of 4096@0x8434b000 at 99760 failed: 14 Feb 19 14:45:12 www /bsd: pid 18943 (cron): user write of 4096@0x7c23e000 at 165360 failed: 14 Feb 19 14:46:38 www /bsd: pid 18781 (error): user write of 118784@0x2eddd000 at 145008 failed: 14 Feb 19 14:47:39 www /bsd: pid 10912 (flush): user write of 4096@0xb0dc000 at 1360 failed: 14 Feb 19 14:47:52 www /bsd: pid 13255 (cleanup): user write of 4096@0x66 at 1872 failed: 14 What does this indicate? Is my RAM bad? Is my CF card bad? Could someone more knowledgeable please explain the above messages in detail? The system acts as a NAT router, and in that respect, nothing wrong happens to the clients - I browse the web and everything from behind this machine. But when it does something IO related (such as opening my mailbox when I launch mutt), it _sometimes_ segfaults now. For example: I tried to run 'file file.core' in a ktrace. That ended in a segfault. The kdump ends with 22449 file CALL sigprocmask(SIG_BLOCK,0x) 22449 file RET sigprocmask 0 22449 file CALL mprotect(0x3c005000,0x1000,0x3PROT_READ|PROT_WRITE) 22449 file RET mprotect 0 22449 file CALL mprotect(0x3c005000,0x1000,0x1PROT_READ) 22449 file RET mprotect 0 22449 file CALL sigprocmask(SIG_SETMASK,0) 22449 file RET sigprocmask -65793/0xfffefeff 22449 file PSIG SIGSEGV SIG_DFL code SEGV_MAPERR1 addr=0x87fb313c trapno=2 22449 file NAMI file.core Thank you for you time Jan OpenBSD 5.1-beta (GENERIC) #140: Sat Jan 21 00:40:23 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 432 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 133758976 (127MB) avail mem = 121544704 (115MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 12/10/07, BIOS32 rev. 0 @ 0xfceb2 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x31 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:12:9f:2c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:12:9f:2d ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:0d:b9:12:9f:2e ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 12 function 0 Ralink RT2560 rev 0x01: irq 9, address 00:11:09:0d:d3:36 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: LEXAR ATA FLASH CARD wd0: 1-sector PIO, LBA, 15263MB, 31260096 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 mtrr: K6-family MTRR support (2 registers) nvram: invalid checksum vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (5bea3261eefd6b7e.a) swap on wd0b dump on wd0b clock: unknown CMOS layout -- Sending from my VCR
Re: ALIX segfaulting on current/i386
On Sun, Feb 19, 2012 at 6:17 AM, Jan Stary h...@stare.cz wrote: On a recent install of current/i386 on an ALIX (see dmesg below), processes (such as a simple 'ls') started to magically segfault and die. Feb 19 14:43:17 www /bsd: pid 26001 (bogofilter): user write of 4096@0x3d5b000 at 1776 failed: 14 14 == EFAULT. Those are generated when the kernel tries to write out a process's memory image for a coredump and the indicated range of memory couldn't be faulted in so that it could be written to the filesystem. What does this indicate? Is my RAM bad? Is my CF card bad? Could someone more knowledgeable please explain the above messages in detail? The inability to fault in memory that the kernel thinks should be there makes me wonder if you're swapping and the device you're swapping to is failing. Your dmesg suggests you might be swapping to your CF card and you (only?) have 128MB of real memory. When this is happening, what's the output of swapctl -l? If that shows you are indeed into swap, then a failing CF card would be my guess. (Swapping to CF seems like a bad idea to me, but I'm not expert in that sort of hardware...) Philip Guenther
Re: ALIX segfaulting on current/i386
On Feb 19 15:00:18, Gonzalo L. R. wrote: Try with the last snapshot: OpenBSD 5.1 (GENERIC) #160: Sun Feb 12 09:46:33 MST 2012 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC I have the same machine and no problems. This machine has been running for five years without problems; that's why I am speculating about a HW failure ... On Sun, 19 Feb 2012 15:17:41 +0100, Jan Stary wrote: On a recent install of current/i386 on an ALIX (see dmesg below), processes (such as a simple 'ls') started to magically segfault and die. Feb 19 14:43:17 www /bsd: pid 26001 (bogofilter): user write of 4096@0x3d5b000 at 1776 failed: 14 Feb 19 14:44:08 www /bsd: pid 7571 (bogofilter): user write of 4096@0x2cfe000 at 1360 failed: 14 Feb 19 14:45:04 www /bsd: pid 9409 (sh): user write of 4096@0x8434b000 at 99760 failed: 14 Feb 19 14:45:12 www /bsd: pid 18943 (cron): user write of 4096@0x7c23e000 at 165360 failed: 14 Feb 19 14:46:38 www /bsd: pid 18781 (error): user write of 118784@0x2eddd000 at 145008 failed: 14 Feb 19 14:47:39 www /bsd: pid 10912 (flush): user write of 4096@0xb0dc000 at 1360 failed: 14 Feb 19 14:47:52 www /bsd: pid 13255 (cleanup): user write of 4096@0x66 at 1872 failed: 14 What does this indicate? Is my RAM bad? Is my CF card bad? Could someone more knowledgeable please explain the above messages in detail?
Re: ALIX segfaulting on current/i386
On Feb 19 10:12:03, Philip Guenther wrote: On Sun, Feb 19, 2012 at 6:17 AM, Jan Stary h...@stare.cz wrote: On a recent install of current/i386 on an ALIX (see dmesg below), processes (such as a simple 'ls') started to magically segfault and die. Feb 19 14:43:17 www /bsd: pid 26001 (bogofilter): user write of 4096@0x3d5b000 at 1776 failed: 14 14 == EFAULT. Those are generated when the kernel tries to write out a process's memory image for a coredump and the indicated range of memory couldn't be faulted in so that it could be written to the filesystem. Thank you for the explanation. So, firstly, the kernel decides a proccess needs to be coredumped. (That alone is a problem for me - why would that happen?) And secondly, the attempt to coredump the process fails. Right? What does this indicate? Is my RAM bad? Is my CF card bad? Could someone more knowledgeable please explain the above messages in detail? The inability to fault in memory that the kernel thinks should be there makes me wonder if you're swapping and the device you're swapping to is failing. Your dmesg suggests you might be swapping to your CF card and you (only?) have 128MB of real memory. When this is happening, what's the output of swapctl -l? If that shows you are indeed into swap, then a failing CF card would be my guess. Yes, the machine only has 128MB of memory - which I think should be enough for what it does: NATing pf, dhcpd and resolver for the internal network, and postfix and httpd for my domain (which amounts to almost no traffic). It does not have any swap configured. In fact, I try to design my systems so that they don't ever need to swap. $ swapctl -l swapctl: no swap devices configured Would you please care to explain further how the swapping is related to the coredumping EFAULTs? (Swapping to CF seems like a bad idea to me, but I'm not expert in that sort of hardware...) I don't swap to the CF. If it so happens that there is not enough memory for some running process (a situaion I cannot rule out now), and there is no swap to deal with this, is that a reason for a process to be coredumped? (I think that I have seen processes just die with ENOMEM in that situaion.) Thank you for your time Jan
Re: ALIX segfaulting on current/i386
On Sun, Feb 19, 2012, Jan Stary wrote: If it so happens that there is not enough memory for some running process (a situaion I cannot rule out now), and there is no swap to deal with this, is that a reason for a process to be coredumped? (I think that I have seen processes just die with ENOMEM in that situaion.) ENOMEM is somewhat unlikely even in low memory situations, because the kernel allows overcommit. A process can allocate memory that's not technically available, then when it tries to use that memory and the kernel can't find anything to provide, segfault. ENOMEM is an error code, but not a signal, so a process cannot strictly speaking die from it.
Re: ALIX segfaulting on current/i386
On Sun, Feb 19, 2012 at 11:24 AM, Jan Stary h...@stare.cz wrote: On Feb 19 10:12:03, Philip Guenther wrote: On Sun, Feb 19, 2012 at 6:17 AM, Jan Stary h...@stare.cz wrote: On a recent install of current/i386 on an ALIX (see dmesg below), processes (such as a simple 'ls') started to magically segfault and die. Feb 19 14:43:17 www /bsd: pid 26001 (bogofilter): user write of 4096@0x3d5b000 at 1776 failed: 14 14 == EFAULT. Those are generated when the kernel tries to write out a process's memory image for a coredump and the indicated range of memory couldn't be faulted in so that it could be written to the filesystem. Thank you for the explanation. So, firstly, the kernel decides a proccess needs to be coredumped. (That alone is a problem for me - why would that happen?) And secondly, the attempt to coredump the process fails. Right? Yep. What does this indicate? Is my RAM bad? Is my CF card bad? Could someone more knowledgeable please explain the above messages in detail? The inability to fault in memory that the kernel thinks should be there makes me wonder if you're swapping and the device you're swapping to is failing. Your dmesg suggests you might be swapping to your CF card and you (only?) have 128MB of real memory. When this is happening, what's the output of swapctl -l? If that shows you are indeed into swap, then a failing CF card would be my guess. Yes, the machine only has 128MB of memory - which I think should be enough for what it does: NATing pf, dhcpd and resolver for the internal network, and postfix and httpd for my domain (which amounts to almost no traffic). Have you monitored the memory usage to confirm or deny your belief that it's sufficient? It does not have any swap configured. In fact, I try to design my systems so that they don't ever need to swap. $ swapctl -l swapctl: no swap devices configured Would you please care to explain further how the swapping is related to the coredumping EFAULTs? It was a hypothesis based on the available evidence. Your additional evidence rules it out, so I see no reason to waste our time explaining it. At this point, I suggest you gather data about the system and see if there's a correlation between the data and when this occurs. Then make a hypothesis from that, figure out a way to test it, etc. In short, use *SCIENCE* on it! Philip Guenther
xlock segfault only with certain users
I am running snapshot from right before ports unlock on i386. I can use xlock just fine, however when another user logs in, it segfaults saying need to relink program. Both using scrotwm. Any ideas? Fixes? I do not intend to upgrade this machine again as I am leaving for a long time and it seems fairly stable. Thanks Chris Bennett
Re: smartphones and managing openbsd servers
On Sun, Feb 19, 2012 at 7:14 AM, Luke Tymowski l...@veldt.ca wrote: I use iSSH on an iPhone. But only in an emergency when I don't have anything else. I wouldn't make regular use of it. (ie, twice in the last year) I've grown to like Panic's Prompt, and found it does really well with tmux, etc as well. On the iPad, it's almost a pleasure to use. It works really well off of the iPhone as well. http://itunes.apple.com/us/app/prompt/id421507115?mt=8
Re: smartphones and managing openbsd servers
On Sun, Feb 19, 2012 at 9:14 AM, Anonymous cri...@ecn.org wrote: BlackBerry has built in VPN and you can also buy a few different SSH and SFTP apps. If you're cheap, there's also BBSSH. While it's not perfect, it is under active -if slow- development. As of November 2011, the developer claims there's an scp client coming as well. When I still had a Blackberry, I pretty actively used the app for emergency work. My only real complaint was the small type. http://bbssh.org/
Re: smartphones and managing openbsd servers
I often use successfully Irris connect to access my BSD's boxes on android smartphones it is easy to use, even with the virtual keyboard. From: Johan Beisser j...@caustic.org Sent: Sun Feb 19 21:49:54 CET 2012 To: Luke Tymowski l...@veldt.ca Subject: Re: smartphones and managing openbsd servers On Sun, Feb 19, 2012 at 7:14 AM, Luke Tymowski l...@veldt.ca wrote: I use iSSH on an iPhone. But only in an emergency when I don't have anything else. I wouldn't make regular use of it. (ie, twice in the last year) I've grown to like Panic's Prompt, and found it does really well with tmux, etc as well. On the iPad, it's almost a pleasure to use. It works really well off of the iPhone as well. http://itunes.apple.com/us/app/prompt/id421507115?mt=8 Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 ToulouseB FranceB +33 6 17 230 820 B +33 5 34 365 269 fpussa...@contactoffice.fr
Re: smartphones and managing openbsd servers
HTC Desire Z (physical qwerty keyboard) with CyanogenMod. Dropbear is the standard ssh client in cm 7, works good. //Johan Ryberg Den 19 feb 2012 18:14 skrev Anonymous cri...@ecn.org: What newer smartphones do you recommend for using also as a tool for managing OpenBSD servers (maybe windogs too) ? What experiences had you had with smartphones and OpenBSD managing? BlackBerry has built in VPN and you can also buy a few different SSH and SFTP apps.
Re: smartphones and managing openbsd servers
On Sat, Feb 18, 2012 at 3:06 PM, Marcos Ariel Laufer mar...@ipversion4.com wrote: What newer smartphones do you recommend for using also as a tool for managing OpenBSD servers (maybe windogs too) ? What experiences had you had with smartphones and OpenBSD managing? Your experience really depends on a few things: the phone network's bandwidth, CPU speed, and the ability to read the returned output without strain. Everything else is just extras and features. Bandwidth and lag can make your session unusable. Almost all modern smartphones have WiFi capability built in, which helps reduce your data rate during the SSH session, and decreases lag. That throughput will also make a big difference in receiving data from the server. In my experience if there's any amount of retransmission happening due to packet loss, the clients hang up abruptly. So, ideally, the client will emulate a modern terminal well enough to use tmux or screen really well. Most modern phones have more than enough CPU power to handle SSH. The problem is that few have the ability to offload the crypto from the CPU, and so SSH chews up already precious battery time. To help offset typing lag some clients permit you to queue a longer string to send to the session. The advantage of this is that fewer packets are sent, and the block of data can be sent out as (hopefully) a single chunk. I believe some Android Market clients support this feature, and I know at least one SSH client on blackberry has it, and at least two of the clients on iOS (iPhone/iPad) have the ability to assign shortcuts. Phone form-factor is a major issue you should consider. I know a few people who regularly use their phones for SSH, and are unwilling to up a physical keyboard. Slider and flip configurations permit you to use most of the screen real estate for your session, but the overall market is moving toward the touchscreen candybar configuration. Because of this, the SSH client has to be able to either 'shadow' the keyboard, allowing you to look through it, or permit you to hide the keyboard and read scrollback easily. As far as what's superior? None of them are really any better than the others. What works for you will matter more. Most modern smartphones are roughly the same, just with a different level of hype or features people want.* - jb * although, I'll be damned if I could find a GSM/LTE, CDMA and wifi capable Android phone with a physical keyboard that didn't utterly suck. I settled on an iPhone 4s, with a decent SSH client.
Re: ALIX segfaulting on current/i386
On Feb 19 10:12:03, Philip Guenther wrote: 14 == EFAULT. Those are generated when the kernel tries to write out a process's memory image for a coredump and the indicated range of memory couldn't be faulted in so that it could be written to the filesystem. The inability to fault in memory that the kernel thinks should be there makes me wonder if you're swapping and the device you're swapping to is failing. Your dmesg suggests you might be swapping to your CF card and you (only?) have 128MB of real memory. When this is happening, what's the output of swapctl -l? If that shows you are indeed into swap, then a failing CF card would be my guess. Yes, the machine only has 128MB of memory - which I think should be enough for what it does: NATing pf, dhcpd and resolver for the internal network, and postfix and httpd for my domain (which amounts to almost no traffic). It does not have any swap configured. In fact, I try to design my systems so that they don't ever need to swap. $ swapctl -l swapctl: no swap devices configured If it so happens that there is not enough memory for some running process (a situaion I cannot rule out now), and there is no swap to deal with this, is that a reason for a process to be coredumped? On Feb 19 12:26:03, Philip Guenther wrote: Have you monitored the memory usage to confirm or deny your belief that it's sufficient? I have now (and should have before of course). The memory is _not_ sufficient because of a single process (a demanding user's tomcat installation) eating all the memory. Specifically, the user is in the 'default' login class, which entitles him to 512M on this 128M machine. His java process requires about 180M (says top). On Feb 19 15:17:31, Ted Unangst wrote: If it so happens that there is not enough memory for some running process (a situaion I cannot rule out now), and there is no swap to deal with this, is that a reason for a process to be coredumped? (I think that I have seen processes just die with ENOMEM in that situaion.) ENOMEM is somewhat unlikely even in low memory situations, because the kernel allows overcommit. A process can allocate memory that's not technically available, This must be what's happening on my machine now: a java process getting 180M on a 128M machine. then when it tries to use that memory and the kernel can't find anything to provide, segfault. What puzzles me that it's the other processes that are segfaulting; the java process that ate the (nonexistent) memory keeps running, but an innocent vi(1) gets killed later, or a ntpd trying to sync. Is this how the memory overcommit functionality works? I have killed the java process about an hour ago, and limited the memory usage in login.conf to :datasize-max=100M:\ :datasize-cur=100M:\ which makes the java process fail to start: Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. None of the symptoms has occured since. At any rate, thank you for the hints. What can I do to further test my current suspicion that the memory insuficiency is what was causing it? Jan
ath driver returns “unable to reset hardware” when attempting to use Atheros AR5424 on 5.0-stable
Hello, I'm trying to install OpenBSD 5.0-stable using bsd.rd on my Acer Aspire One ZG5/AOA150. The AAO contains an Atheros AR5424 (note: ath5k on Linux claims that this is a AR2425 instead) wireless networking device (PCI ID: 168c:001c, subsystem PCI ID: 105b:e008). Upon trying to use this device to connect to my home network, the ath driver returns unable to reset hardware and a HAL status code. The man page for ath gives the ominous this should not happen notice and points to the source at /sys/dev/ic/ar5xxx.h, but the HAL status codes that are returned by ath are not contained within the header file listed, at least, as far as I can see. The device works fine using the ath5k driver available for Linux. Here is the relevant output from the installer: ath0: unable to reset hardware; hal status 3497684308 ath0: unable to reset hardware; hal status 3688045980 ath0: no link . sleeping Issuing free-roaming DHCP request for ath0. ath0: unable to reset hardware; hal status 204 ath0: no link . sleeping The second HAL status changes each reboot (it stays the same during the same session); the first and last statuses stay the same, however. The first unable to reset hardware appears *only* the first time that I bring the network interface up. It is always 3497684308. The second occurs both the first time that I bring the network interface up, and subsequent times. I have not yet been able to determine how to trigger the third HAL status manually (I tried using dhclient, but it returns 3687943580 instead). If I run dhclient more than once, it starts to return Can't find free bpf: No such file or directory. If I try to bring up ath0 without giving any information about the network, I get the following output: ath0: unable to reset hardware; hal status 3497684308 ath0: unable to reset hardware; hal status 1 Bringing the network interface down afterwards does not result in any errors, but bringing it back up again returns another HAL status: ath0: unable to reset hardware; hal status 0 Here is the dmesg: OpenBSD 5.0 (RAMDISK_CD) #36: Wed Aug 17 10:27:31 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD RTC BIOS diagnostic error 80clock_battery cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH ,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3 ,xTPR,PDCM,MOVBE real mem = 1060130816 (1011MB) avail mem = 1035788288 (987MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/09/08, SMBIOS rev. 2.4 @ 0xe8ce0 (32 entries) bios0: vendor Acer version v0.3301 date 05/09/2008 bios0: Acer AOA150 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT HPET APIC MCFG ASF! SLIC BOOT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 132MHz cpu at mainbus0: not configured ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 4 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 5 (P32_) acpiprt2 at acpi0: bus 1 (EXP1) acpiprt3 at acpi0: bus 2 (EXP2) acpiprt4 at acpi0: bus 3 (EXP3) acpiprt5 at acpi0: bus 4 (EXP4) bios0: ROM list: 0xc/0xec00! 0xcf000/0x1000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured Intel 82801GB HD Audio rev 0x02 at pci0 dev 27 function 0 not configured ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 4 int 16 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: apic 4 int 17 pci2 at ppb1 bus 2 re0 at pci2 dev 0 function 0 Realtek 8101E rev 0x02: RTL8102EL (0x2480), apic 4 int 17, address 00:1e:68:e4:2b:ca rlphy0 at re0 phy 7: RTL8201L 10/100 PHY, rev. 1 ppb2 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 4 int 18 pci3 at ppb2 bus 3 ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 4 int 18 ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR5_ETSIC, address 00:23:4d:14:14:82 ppb3 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: apic 4 int 19 pci4 at ppb3 bus 4 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 4 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 4 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 4 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 4 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 4 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb4 at pci0 dev 30 function 0
Re: ath driver returns “unable to reset hardware” when attempting to use Atheros AR5424 on 5.0-stable
On Sun, Feb 19, 2012 at 4:31 PM, Christopher Down christopher.d...@iofc.org wrote: I have read conflicting reports about OpenBSD's support for this chip. If it is not supported (yet), is there a practical way for me to help (bearing in mind that I am not experienced with driver programming on OpenBSD at this point in time)? Otherwise, is there some other solution other than having to resort to buying a new card to put in the machine? Thanks, Christopher Down It's unsupported, I had one, trashed it, and bought a new card...
Re: ath driver returns “unable to reset hardware” when attempting to use Atheros AR5424 on 5.0-stable
Christopher Down christopher.d...@iofc.org writes:
Hello,
Hi.
ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic
4 int 18 ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR5_ETSIC, address
00:23:4d:14:14:82
The problem probably lies in these two lines, imho at least the
radio isn't properly detected (the rf 0.0 part above). I have
a similar card and similar problems. If you read the misc@
archive, you'll find someone with the same card but a different
radio chip has managed to get it working, using bits from the
Linux and NetBSD drivers.
I tried to take his modifications and add support for my card too,
one year ago, but I'm not knowledgeable about kernel / hw
programming. I rapidly gave up, after having obtained this:
[snip]
Jul 9 06:41:58 moo /bsd: ath0: received beacon from
00:17:33:c5:a9:f0 rssi 19 mode 11g Jul 9 06:41:58 moo /bsd: ath0:
received beacon from 00:17:33:c5:a9:f0 rssi 20 mode 11g Jul
9 06:41:59 moo /bsd: ath0: end passive scan Jul 9 06:41:59 moo
/bsd: ath0: sending auth to 00:17:33:c5:a9:f0 on channel 11 mode
11g Jul 9 06:42:02 moo /bsd: ath0: received auth from
00:17:33:c5:a9:f0 rssi 19 mode 11g Jul 9 06:42:02 moo /bsd: ath0:
sending assoc_req to 00:17:33:c5:a9:f0 on channel 11 mode 11g Jul
9 06:42:03 moo /bsd: ath0: received assoc_resp from
00:17:33:c5:a9:f0 rssi 21 mode 11g Jul 9 06:42:03 moo /bsd: ath0:
associated with 00:17:33:c5:a9:f0 ssid NEUF_A9EC channel 11
start 1Mb long preamble short slot time Jul 9 06:42:03 moo /bsd:
ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:03 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:04 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:04 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:05 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:05 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:06 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:06 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:07 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:07 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:08 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:08 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:09 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:09 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:10 moo
/bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0 Jul 9 06:42:10 moo /bsd: ath0: sending msg 2/4
of the 4-way handshake to 00:17:33:c5:a9:f0 Jul 9 06:42:11 moo
/bsd: ath0: received deauth from 00:17:33:c5:a9:f0 rssi 21 mode
11g Jul 9 06:42:11 moo /bsd: ath0: sending auth to
00:17:33:c5:a9:f0 on channel 11 mode 11g Jul 9 06:42:16 moo /bsd:
ath0: device timeout
This looks promising, sadly I didn't take time to try further.
Since I'm really willing to get it working, though, I might spend
more time on this subject next weeks.
Here are the patch, plus unmodified -current dmesg and pcidump -v
patch:
Index: ar5212.c
===
RCS file: /home/cvsync/src/sys/dev/ic/ar5212.c,v retrieving
revision 1.51 diff -u -p -r1.51 ar5212.c --- ar5212.c 2 Jun 2009
12:39:02 - 1.51 +++ ar5212.c 9 Jul 2011 04:40:41 -
@@ -234,9 +234,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending =
AR5K_AR5212_PHY_SPENDING_AR5424; hal-ah_radio_5ghz_revision =
hal-ah_radio_2ghz_revision = AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) { + } else if
(hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) || +
hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) || +
hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending =
AR5K_AR5212_PHY_SPENDING_AR5112; +
hal-ah_single_chip = AH_TRUE; +
hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425; + } else if
((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) || +
(hal-ah_phy_revision == AR5K_SREV_PHY_5413)) { +
hal-ah_radio = AR5K_AR5413; + hal-ah_single_chip =
AH_TRUE; + hal-ah_radio_5ghz_revision =
AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision
AR5K_SREV_RAD_5112) { hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -2860,10 +2868,10 @@ ar5k_ar5212_get_capabilities(struct ath_
if (b) hal-ah_capabilities.cap_mode |=
HAL_MODE_11B;
-#if 0 +
if (g) hal-ah_capabilities.cap_mode |=
HAL_MODE_11G;
-#endif +
} /* GPIO */
Index: ar5212reg.h
Re: ath driver returns “unable to reset hardware” when attempting to use Atheros AR5424 on 5.0-stable
Argh, fscking MUA, sorry. Preparing an unmangled mail right now. -- Jeremie Courreges-Anglas GPG fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: ath driver returns “unable to reset hardware” when attempting to use Atheros AR5424 on 5.0-stable
Sorry for the line noise.
Christopher Down christopher.d...@iofc.org writes:
Hello,
Hi.
ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 4 int 18
ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR5_ETSIC, address 00:23:4d:14:14:82
The problem probably lies in these two lines, imho at least the radio isn't
properly detected (the rf 0.0 part above). I have a similar card and
similar problems. If you read the misc@ archive, you'll find someone
with the same card but a different radio chip has managed to get it
working, using bits from the Linux and NetBSD drivers.
I tried to take his modifications and add support for my card too, one
year ago, but I'm not knowledgeable about kernel / hw programming.
I rapidly gave up, after having obtained this:
[snip]
Jul 9 06:41:58 moo /bsd: ath0: received beacon from 00:17:33:c5:a9:f0 rssi 19
mode 11g
Jul 9 06:41:58 moo /bsd: ath0: received beacon from 00:17:33:c5:a9:f0 rssi 20
mode 11g
Jul 9 06:41:59 moo /bsd: ath0: end passive scan
Jul 9 06:41:59 moo /bsd: ath0: sending auth to 00:17:33:c5:a9:f0 on channel 11
mode 11g
Jul 9 06:42:02 moo /bsd: ath0: received auth from 00:17:33:c5:a9:f0 rssi 19
mode 11g
Jul 9 06:42:02 moo /bsd: ath0: sending assoc_req to 00:17:33:c5:a9:f0 on
channel 11 mode 11g
Jul 9 06:42:03 moo /bsd: ath0: received assoc_resp from 00:17:33:c5:a9:f0 rssi
21 mode 11g
Jul 9 06:42:03 moo /bsd: ath0: associated with 00:17:33:c5:a9:f0 ssid
NEUF_A9EC channel 11 start 1Mb long preamble short slot time
Jul 9 06:42:03 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:03 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:04 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:04 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:05 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:05 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:06 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:06 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:07 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:07 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:08 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:08 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:09 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:09 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:10 moo /bsd: ath0: received msg 1/4 of the 4-way handshake from
00:17:33:c5:a9:f0
Jul 9 06:42:10 moo /bsd: ath0: sending msg 2/4 of the 4-way handshake to
00:17:33:c5:a9:f0
Jul 9 06:42:11 moo /bsd: ath0: received deauth from 00:17:33:c5:a9:f0 rssi 21
mode 11g
Jul 9 06:42:11 moo /bsd: ath0: sending auth to 00:17:33:c5:a9:f0 on channel 11
mode 11g
Jul 9 06:42:16 moo /bsd: ath0: device timeout
This looks promising, sadly I didn't take time to try further.
Since I'm really willing to get it working, though, I might spend more
time on this subject next weeks.
Here are the patch, plus unmodified -current dmesg and pcidump -v
patch:
Index: ar5212.c
===
RCS file: /home/cvsync/src/sys/dev/ic/ar5212.c,v
retrieving revision 1.51
diff -u -p -r1.51 ar5212.c
--- ar5212.c2 Jun 2009 12:39:02 - 1.51
+++ ar5212.c9 Jul 2011 04:40:41 -
@@ -234,9 +234,17 @@ ar5k_ar5212_attach(u_int16_t device, voi
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5424;
hal-ah_radio_5ghz_revision = hal-ah_radio_2ghz_revision =
AR5K_SREV_VER_AR5413;
- } else if (srev == AR5K_SREV_VER_AR2425) {
+ } else if (hal-ah_mac_version == (AR5K_SREV_VER_AR2425 4) ||
+ hal-ah_mac_version == (AR5K_SREV_VER_AR2417 4) ||
+ hal-ah_phy_revision == (AR5K_SREV_PHY_2425)) {
hal-ah_radio = AR5K_AR2425;
- hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5112;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision= AR5K_SREV_RAD_2425;
+ } else if ((hal-ah_mac_version == (AR5K_SREV_VER_AR2424 4)) ||
+ (hal-ah_phy_revision == AR5K_SREV_PHY_5413)) {
+ hal-ah_radio = AR5K_AR5413;
+ hal-ah_single_chip = AH_TRUE;
+ hal-ah_radio_5ghz_revision = AR5K_SREV_RAD_5413;
} else if (hal-ah_radio_5ghz_revision AR5K_SREV_RAD_5112) {
hal-ah_radio = AR5K_AR5111;
hal-ah_phy_spending = AR5K_AR5212_PHY_SPENDING_AR5111;
@@ -2860,10 +2868,10 @@
Re: Hidden Long Filenames and mount_cd9660
On Sun, 19 Feb 2012 09:47:29 -0500, Richard Thornton wrote: Why not find a Windows box to dump the data to a Linux server? Problem solved. Because this isn't the first time I've noticed this, and last night I finally hunted down specs and guessed around enough to figure out what was going on--and also, I refuse to believe that OpenBSD is this retarded. This was one of the first things that bugged me about it, back when I first ever stuck discs into it. Also I have about 100gigs on DVD and I want to minimize the hoops the data has to go through. Also I'd have to beg friends for access to Windows. I thought about this though! My last plan before sleeping last night was to install linux in qemu on the server with sshd running and access to cd0c and dump data that way--the virtual network lag should be far less than real lag, but now thankfully I don't have to because Remco has stumbled into the proper solution. On Sun, 19 Feb 2012 16:41:44 +0100, Remco wrote: Nick Guenther wrote: Here's what cd-info(1) (for the archives: this is from package libcdio) has to say about a DVD that OpenBSD shows LFNs for: ~$ cd-info --dvd [snip] Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (501) truncated to 99. 170: 99:24:74 447224 leadout (1003 MB raw, 873 MB formatted) __ CD Analysis Report CD-ROM with ISO 9660 filesystem and joliet extension level 3 ISO 9660: 2256224 blocks, label `GOSHA_DOCUMENTS ' Application: NERO BURNING ROM Preparer : Publisher : System : Volume : GOSHA_DOCUMENTS Volume Set : ~$ and one that OpenBSD shows SFNs for: ~$ cd-info --dvd [snip common drive info] Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (507) truncated to 99. 170: 99:16:26 446576 leadout (1001 MB raw, 872 MB formatted) __ CD Analysis Report ISO 9660: 2279017 blocks, label `G Save B 6 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 6 Volume Set : UDF: version 0.00 and another: Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (505) truncated to 99. 170: 99:57:63 449688 leadout (1008 MB raw, 878 MB formatted) __ CD Analysis Report ISO 9660: 2269454 blocks, label `G Save B 7 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 7 Volume Set : UDF: version 0.00 So, obviously, the clue is that Roxio obviously didn't put Joliet data on the discs (grrr), which Nero did on the other one. But nevertheless the long file names *are* there because linux reads them. Is there any way to make OpenBSD find the long names anyway? Thanks to all you lovely misc@ers, -Nick If I'm not mistaken your LFN disc only show ISO9660, the SFN discs have an additional UDF: version 0.00 marker. I've never used it so I don't know if it's the right tool for the job but there is mount_udf(8) on OpenBSD. I'll leave it to you if you want to risk trying it, or wait for more knowledgeable people to chime in. Ahhh! You win!! ~$ sudo mount_cd9660 /dev/cd0c /mnt/cd0/ ~$ ls /mnt/cd0/ AUDIOCOMICS FONTSPROGRAMS ~$ mount | grep cd0 /dev/cd0c on /mnt/cd0 type cd9660 (local, read-only, norrip) ~$ #ALLCAPS is a symptom of 8.3 filenames on OpenBSD (n.b. part of Linux's spec is ~$ #that it tolower()s 8.3 filenames to make them less scary, but also less obvious) ~$ sudo umount /mnt/cd0 ~$ sudo mount_udf /dev/cd0c /mnt/cd0/ ~$ ls /mnt/cd0 AudioComics FontsPrograms ~$ mount | grep cd0 /dev/cd0c on /mnt/cd0 type udf (local, read-only) (again, for the records, because this confused me and isn't documented anywhere) norrip means no rock ridge interchange protocol, which is OpenBSD complaining that your ISO is ghetto. I just mounted the same disk on Linux and got this: [kousu@splaat ~]$ sudo mount /dev/sr1 /mnt/cd1 Password: mount: block device /dev/sr1 is write-protected, mounting read-only [kousu@splaat ~]$ mount /dev/sr1 on /mnt/cd1 type udf (ro,relatime,utf8) So, conclusion: if you don't force it, Linux's mount(1) prefers to mount as UDF, whereas OpenBSD falls back to cd9660. AND THE BELLS RANG OUT. Thanks a lot for your eyes, I probably would have given up and done the qemu thing and then maybe next year noticed mount_udf and made the connection. -Nick
Re: smartphones and managing openbsd servers
On 2012-02-19 22.33, Johan Beisser wrote: On Sat, Feb 18, 2012 at 3:06 PM, Marcos Ariel Laufer mar...@ipversion4.com wrote: What newer smartphones do you recommend for using also as a tool for managing OpenBSD servers (maybe windogs too) ? What experiences had you had with smartphones and OpenBSD managing? snip Phone form-factor is a major issue you should consider. I know a few people who regularly use their phones for SSH, and are unwilling to up a physical keyboard. Slider and flip configurations permit you to use most of the screen real estate for your session, but the overall market is moving toward the touchscreen candybar configuration. Because of this, the SSH client has to be able to either 'shadow' the keyboard, allowing you to look through it, or permit you to hide the keyboard and read scrollback easily. As far as what's superior? None of them are really any better than the others. What works for you will matter more. Most modern smartphones are roughly the same, just with a different level of hype or features people want.* - jb * although, I'll be damned if I could find a GSM/LTE, CDMA and wifi capable Android phone with a physical keyboard that didn't utterly suck. I settled on an iPhone 4s, with a decent SSH client. I'm also using an iPhone 4S and have tried a couple of ssh clients: * SSH2GO is basically crap. Crashes on connect to some servers, works decently with others but random crashes are to be expected, whenever you need them the least (which is always). * Prompt from Panic, Inc is really good on the other hand. Works well, seems stable, has good emulation, is mostly intuitive to use and has sane defaults. Works even better on an iPad, of course. But the best part is, I also bought a small, portable Bluetooth keyboard, similar in size to the 4S. Bought it on a whim, but it turned out to be an excellent piece of hardware: http://www.zoweetek.com/product_show.asp?id=381 (Though mine's got swedish layout.) Works perfectly with the iPhone out of the box, and changes the task of running an ssh client from only-in-absolute-emergencies to being almost a pleasure. It's always in the inner pocket of my jacket now, just in case. The keyboard makes all the difference, and I now rarely feel the need to carry a laptop when I'm away from the office, because I can always get to - and use - a shell from anywhere. When the phone detects that I've turned on the keyboard, it automatically removes the screen keyboard, and the resulting screen real estate becomes fairly decent (in landscape mode). Unfortunately that particular model keyboard is said not to work with Android, at least without 3rd party drivers. Can't comment on that though, since I don't have access to any Android devices. Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
WARNING: CHECK AND RESET THE DATE! [not installation]
Hello, I want to install OpenBSD 5.0 on a very old laptop with 16 mb ram and a 500mhz celeron processor. I start the boot from the cd starts to load but then appears on the screen a writing that is repeated ad infinitum WARNING: CHECK AND RESET THE DATE! clock time much less time than file sytem using file system time I set the clock from the bios, but do not solve the problem. There's one thing to point out, the battery does not work then when you turn off the time you just saved. How do I fix this problem to continue the installation? -- Cardi Francesco alias Il Parente Free Software activist Diaspora*: https://joindiaspora.com/u/ilparente Identi.ca: https://identi.ca/cardifrancesco Jabber: ilpare...@jabber.org
Re: WARNING: CHECK AND RESET THE DATE! [not installation]
On 02/19/12 20:41, Francesco Cardi wrote: Hello, I want to install OpenBSD 5.0 on a very old laptop with 16 mb ram and a 500mhz celeron processor. I start the boot from the cd starts to load but then appears on the screen a writing that is repeated ad infinitum WARNING: CHECK AND RESET THE DATE! clock time much less time than file sytem using file system time I set the clock from the bios, but do not solve the problem. There's one thing to point out, the battery does not work then when you turn off the time you just saved. How do I fix this problem to continue the installation? 1) replace the battery for the NVRAM/clock on the laptop. 2) put more RAM in it. You won't be using a 16M i386 productively for much of anything other than watching it swap. I haven't tested the 16M install in quite a few releases; last I saw, it was swapping before you even logged in, and a LOT has happened since. There was some talk about making 32M absolute minimum, though I don't believe it happened deliberately...it has long been true by default. I'm not sure if the RAM is the reason the Check and reset the date error is repeating, but 16M just won't cut it for i386 in 2012. 32M will. I'm mystified how you got a 500mhz machine with 16M RAM. I've got a low-end 366MHz celeron laptop that has 32M on the main board, and I thought that was pretty low for the day. You may have other problems with the machine you are using -- normally the clock time error is not fatal...just a hey, your RTclock is hosed and as time is pretty important to a unix machine, you might want to know this type warning and move on. Nick.
scim-fcitx yes to i386 no to amd64
recent snapshot i386 OpenBSD 5.1 (GENERIC.MP) #188 amd64 OpenBSD 5.1 (GENERIC.MP) #207 install OpenBSD amd64 and i386 as normal, default # pkg_add firefox # pkg_add scim-fcitx # pkg_add zh-wqy-zenhei-ttf only 6 lines in /root/.xinitrc export GTK_IM_MODULE=scim export QT_IM_MODULE=scim export XMODIFIERS=@im=SCIM /usr/local/bin/scim -d firefox fvwm # startx problem: i386 platform, start firefox (command # firefox) , in firefox Search bar we can active scim-fcitx input method through ctrl+space or ctrl+shift. amd64 platform, start firefox (command # firefox) , in firefox Search bar we can't active scim-fcitx input method through ctrl+space or ctrl+shift.
Re: smartphones and managing openbsd servers
On 2012-02-18 20:06, Marcos Ariel Laufer wrote: Hello list, This might not be OpenBSD specific, but maybe users can share their experiences with smartphones an managing OpenBSD servers. So far, my smartphone has been a very usefull tool to manage my OpenBSD servers. Currently i am using a Palm Treo 680 with some lousy ssh application to access my servers, it is usefull, but this is getting pretty ancient, doesn't have wifi for exaple, and i would like that feature on a smartphone. I also love the touch screen. What newer smartphones do you recommend for using also as a tool for managing OpenBSD servers (maybe windogs too) ? What experiences had you had with smartphones and OpenBSD managing? Best regards, Marcos I use a Nokia N900 for this. It's a real GNU/Linux, so you you get ssh out-of-the-box, and there's other stuff you might occasionally use (like rsync). It also has a pretty good hardware keyboard, which I feel is a must in order to use ssh comfortably, and makes the real difference. I log into OpenBSD servers on a daily basis (well, just two servers actually), and it's pretty good. -- Hugo Osvaldo Barrera
Re: xlock segfault only with certain users
On Sun, Feb 19, 2012, Chris Bennett wrote: I am running snapshot from right before ports unlock on i386. I can use xlock just fine, however when another user logs in, it segfaults saying need to relink program. Actually, it says you need to relink it, then it segfaults some time after. The solution, of course, is to relink the program. Or install a snapshot where it was properly linked.
Re: xlock segfault only with certain users
On Sun, Feb 19, 2012, Chris Bennett wrote: I am running snapshot from right before ports unlock on i386. I can use xlock just fine, however when another user logs in, it segfaults saying need to relink program. Actually, it says you need to relink it, then it segfaults some time after. The solution, of course, is to relink the program. Or install a snapshot where it was properly linked. Or in future releases we could remove that important message from ld.so, so that it would just crash silently.
