How does OpenBSD do backups?
I am a minimalist. I strongly prefer to use what is in base to do what I need to do. I know Duplicity exists, but how would I reproduce what it does with the OpenBSD base? Set up a local CVS server, and send differences off site? Thanks
Re: D-Link Wireless card not recognized
Hi, Sebastian Reitenbach wrote: On Thursday, April 11, 2013 00:02 CEST, Riccardo Mottola riccardo.mott...@libero.it wrote: I don't see it in ifconfig, dmesg says: vendor Atheros, unknown product 0x0020 (class network subclass ethernet, rev 0x01) at cardbus0 dev 0 function 0 not configured take a look at man ath(4). There are some different AR52XX device types listed. If you are lucky, you have one of those chipsets, and only the card info needs to be added to match the driver. The ath drivers says to support: The ath driver provides support for wireless network devices based on the Atheros AR5210, AR5211, and AR5212 chips. However, on linux the card gets recognized as: 07:00.0 Ethernet controller: *Atheros* Communications Inc. AR5513 802.11abg Wireless NIC (rev 01) Subsystem: D-Link System Inc DWL-G650M Super G MIMO Wireless Notebook Adapter Flags: medium devsel, IRQ 11 Memory at c800 (32-bit, non-prefetchable) [disabled] [size=128K] Capabilities: [44] Power Management version 2 thus it is a AR5513 card, which is not supported. THis is not a brand new card, but I found is a new-old-stock on Ebay, however the cards supported by OpenBSD are much older. Just for the sake, since I am running a 5.3-current kernel compiled by you, I tried if there were updates to the driver, but no new luck. Riccardo PS: just for the sake, I tried the card on a Linux computer and there I get much more information as you see above, but I couldn't really connect with it either. An intermediate status for FreeBSD too. It appears that most OpenBSD drivers are actually ports, thus if I don't have luck with FreeBSD, I need to get (yet another) card. Wow. I have 3 wireless cards now. One works on FreeBSD but not linux, one on Linux but make OpenBSD lock at boot (but appears to work if inserted later) and one which should be the fastest... in no free OS at all.
Re: open source laptop battery repair?
Battery repair soft-tools are just fake or legend for laptops, because most of batteries are using LI-ON technology so when battery has been badly used (for example still in the machine while running 100% of time on sector for about a year), the battery is chemically modified inside of itself. so it can never be repaired, you can get a few more battery time for example a battery that take charge of 50% its nominal capacity, will go up back to 60 or 75% for a short period of time (few month) (software tools will show 100% but reality will be 60 to 75%). but then will decrease it capacity very fast , faster by far, than if you didn't try to force its repair... this is worst again, for older batteries technologies. hardware tools exist that can do the job with better results but they are not cheap. From: Alan Corey alan01...@gmail.com Sent: Sun Apr 28 07:16:46 CEST 2013 To: misc@openbsd.org Subject: open source laptop battery repair? Just wondering if anyone knows about tools for laptop battery repair that might run under OpenBSD. The smart batteries have a microprocessor that interfaces to the cells and talks to the cpu over an smbus. ACPI talks to that bus, but it can't help with broken batteries or replacing cells. Google for a pdf called BH_US_11_Miller_Battery_Firmware_Public_WP.pdf if you want to read more. There's a semi-commercial program called be2works designed for cell replacement and such, but the full version is $300. Is there anything open source? BTW: Miller's bibliography at the end of the pdf above is quite good. I was able to download all the pdfs he mentions. Most are from TI. Unfortunately he was working with Apple hardware, I've got Dell. But he got in there with logic analyzers and the whole bit. Alan -- Credit is the root of all evil. - AB1JX Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr
ThinkPad 600 hdd spindown
Hi, I experience very short-cycling of the hard disk. It appears to spin down very aggressively. But what happens is that it spins up. Just type ls or so. Then it will spin down however within seconds, yielding a continuous spin-up spin down. This happens when running on mains (the battery is dead anyway). Are there settings about this? Or is it all coming from the BIOS where I don't see such settings (the older IBM BIOSes were very simple). What I find wrong is the very short time to spin down again, something like 10-15 seconds! Riccardo
Re: ThinkPad 600 hdd spindown
Hi, you can try to disable power management for it: atactl /dev/wd0c accousticdisable, or apmdisable, or apmset 253 (man atactl) kind regards, Robert On Sun, 28 Apr 2013 10:40:39 +0200 Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, I experience very short-cycling of the hard disk. It appears to spin down very aggressively. But what happens is that it spins up. Just type ls or so. Then it will spin down however within seconds, yielding a continuous spin-up spin down. This happens when running on mains (the battery is dead anyway). Are there settings about this? Or is it all coming from the BIOS where I don't see such settings (the older IBM BIOSes were very simple). What I find wrong is the very short time to spin down again, something like 10-15 seconds! Riccardo
Re: ThinkPad 600 hdd spindown
Maybe atactl can help. Riccardo Mottola riccardo.mott...@libero.it wrote: Hi, I experience very short-cycling of the hard disk. It appears to spin down very aggressively. But what happens is that it spins up. Just type ls or so. Then it will spin down however within seconds, yielding a continuous spin-up spin down. This happens when running on mains (the battery is dead anyway). Are there settings about this? Or is it all coming from the BIOS where I don't see such settings (the older IBM BIOSes were very simple). What I find wrong is the very short time to spin down again, something like 10-15 seconds! Riccardo
Re: OpenBSD freeze after DRM changes
Hi all, Following up on this: On Thu, Apr 25, 2013 at 08:50:33AM -0300, Daniel Bolgheroni wrote: Hi misc@, after one of the screenshots that include the DRM changes, my laptop began to freeze after the first boot. Sometimes it freezes at Pentium Pro MTRR support, but most of the times it freezes no more than 1 minute after login. After reboot, the system runs rock solid. dmesg and pcidump included below. Anyone experiencing the same? Thank you. This newer snapshot: OpenBSD 5.3-current (GENERIC.MP) #103: Wed Apr 24 09:33:02 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP has the same behaviour on my laptop. Maybe three more points maybe worth mentionning (they are not new to this snapshot, but I forgot to mention them in my first email): 1. Booting about one hour and a half after last shutdown leads to the freeze described. 2. When booting for the first time in a while, if I reboot before the machine freezes, the system does not subsequently freeze. 3. The system freezes after a couple of minutes when resuming from suspend. I hope this helps. Alexis
Re: How does OpenBSD do backups?
On Sat, Apr 27, 2013 at 11:38:24PM -0700, Robert Connolly wrote: I am a minimalist. I strongly prefer to use what is in base to do what I need to do. I know Duplicity exists, but how would I reproduce what it does with the OpenBSD base? Set up a local CVS server, and send differences off site? Thanks You might want to look into the manpages of dump(8) and restore(8). If you don't want to use rsh as the means for data transport between the two (Hint: you don't, at least not on a public network), they work fine in an ssh pipeline like this: dump -f - /home/gbe | ssh backuphost cat /backups/2013-04-28.dump Restoring is then a simple cd /home/gbe; ssh backuphost cat /backups/2013-04-28.dump | restore -r -f - You can also install rsync from ports, it can hardlink already existing files to the target so you get a complete tree without duplicating existing data. -- Gregor Best
panic: got error 5 while accessing filesystem
My december-current/macppc panicked tonight, saying
got error 5 while accessing filesystem
Looking at the log tails, it apparently happened
when daily.local started the nightly dumps.
These are done to an USB connected Seagate.
(see full dmesg below).
Looking at the code, this is ufs/ffs/ffs_softdep.c:
/*
* Function to handle asynchronous write errors in the filesystem.
*/
void
softdep_error(char *func, int error)
{
/* XXX should do something better! */
printf(%s: got error %d while accessing filesystem\n, func, error);
}
I wasn't able to find out what error 5 is.
I will try disabling softdeps on that filesystem.
Should I upgrade for some softdep-specific goodness?
Jan
OpenBSD 5.2-current (GENERIC.MP) #4: Wed Dec 26 15:08:07 CET 2012
r...@www.stare.cz:/usr/src/sys/arch/macppc/compile/GENERIC.MP
real mem = 1073741824 (1024MB)
avail mem = 1032146944 (984MB)
mainbus0 at root: model PowerMac10,2
cpu0 at mainbus0: 7447A (Revision 0x102): 1499 MHz: 512KB L2 cache
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0
memc0 at mainbus0: uni-n rev 0xd2
hw-clock at memc0 not configured
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
mpcpcibr0 at mainbus0 pci: uni-north, Revision 0xff
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 Apple UniNorth AGP rev 0x00
appleagp0 at pchb0
agp0 at appleagp0: aperture at 0x0, size 0x1000
vgafb0 at pci0 dev 16 function 0 ATI Radeon 9200 rev 0x01, mmio
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
mpcpcibr1 at mainbus0 pci: uni-north, Revision 0x5
pci1 at mpcpcibr1 bus 0
pchb1 at pci1 dev 11 function 0 Apple UniNorth PCI rev 0x00
bwi0 at pci1 dev 18 function 0 Broadcom BCM4318 rev 0x02: irq 52, address
00:11:24:bf:cb:2a
macobio0 at pci1 dev 23 function 0 Apple Intrepid rev 0x00
openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE
macgpio0 at macobio0 offset 0x50
modem-reset at macgpio0 offset 0x1d not configured
modem-power at macgpio0 offset 0x1c not configured
macgpio1 at macgpio0 offset 0x9 irq 47
programmer-switch at macgpio0 offset 0x11 not configured
gpio5 at macgpio0 offset 0x6f not configured
gpio6 at macgpio0 offset 0x70 not configured
extint-gpio15 at macgpio0 offset 0x67 not configured
escc-legacy at macobio0 offset 0x12000 not configured
zsc0 at macobio0 offset 0x13000: irq 22,23
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
aoa0 at macobio0 offset 0x1: irq 30,1,2
audio0 at aoa0
timer at macobio0 offset 0x15000 not configured
adb0 at macobio0 offset 0x16000 irq 25: via-pmu, 0 targets
apm0 at adb0: battery flags 0x0, 0% charged
piic0 at adb0
iic1 at piic0
maxtmp0 at iic1 addr 0xc8: max6642
kiic1 at macobio0 offset 0x18000
iic2 at kiic1
wdc0 at macobio0 offset 0x2 irq 24: DMA
ohci0 at pci1 dev 24 function 0 Apple Intrepid USB rev 0x00: couldn't map
interrupt
ohci1 at pci1 dev 25 function 0 Apple Intrepid USB rev 0x00: couldn't map
interrupt
ohci2 at pci1 dev 26 function 0 Apple Intrepid USB rev 0x00: irq 29, version
1.0, legacy support
ohci3 at pci1 dev 27 function 0 NEC USB rev 0x43: irq 63, version 1.0
ohci4 at pci1 dev 27 function 1 NEC USB rev 0x43: irq 63, version 1.0
ehci0 at pci1 dev 27 function 2 NEC USB rev 0x04: irq 63
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 NEC EHCI root hub rev 2.00/1.00 addr 1
usb1 at ohci2: USB revision 1.0
uhub1 at usb1 Apple OHCI root hub rev 1.00/1.00 addr 1
usb2 at ohci3: USB revision 1.0
uhub2 at usb2 NEC OHCI root hub rev 1.00/1.00 addr 1
usb3 at ohci4: USB revision 1.0
uhub3 at usb3 NEC OHCI root hub rev 1.00/1.00 addr 1
mpcpcibr2 at mainbus0 pci: uni-north, Revision 0x6
pci2 at mpcpcibr2 bus 0
pchb2 at pci2 dev 11 function 0 Apple UniNorth PCI rev 0x00
kauaiata0 at pci2 dev 13 function 0 Apple Intrepid ATA rev 0x00
wdc1 at kauaiata0 irq 39: DMA
atapiscsi0 at wdc1 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: MATSHITA, DVD-R UJ-825, DAND ATAPI 5/cdrom
removable
wd0 at wdc1 channel 0 drive 1: ST9808211A
wd0: 16-sector PIO, LBA, 76319MB, 156301488 sectors
cd0(wdc1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
wd0(wdc1:0:1): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
Apple UniNorth Firewire rev 0x81 at pci2 dev 14 function 0 not configured
gem0 at pci2 dev 15 function 0 Apple Uni-N2 GMAC rev 0x80: irq 41, address
00:14:51:17:42:34
bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4
umass0 at uhub0 port 1 configuration 1 interface 0 Prolific Technology Inc.
Mass Storage Device rev 2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: ST980815, A, 3.AL SCSI0 0/direct fixed
serial.067b2506
sd0: 76319MB, 512 bytes/sector, 156301488 sectors
uhidev0 at uhub1 port 1 configuration 1 interface 0 Apple Computer HID-proxy
rev 2.00/19.65 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub1 port 1
Re: rtl_sdr (was: Re: CVS: cvs.openbsd.org: ports)
On 2013-04-27, Christian Weisgerber na...@mips.inka.de wrote: $ rtl_fm -W -f 102.8M | aucat -h raw -r32000 -c0:0 -i - wav(-|): couldn't get file size Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 0001 Using device 0: Terratec T Stick PLUS Found Elonics E4000 tuner [...] Looks, I mean, _sounds_ like it works in principle. About 2650 ehci(4) interrupts per second. This has to be the most roundabout way to listen to FM radio. The main reason I got my device is so I can receive a community station which I can't pick up at home, plan is to put it at my parents' house and stream it over the net. (The station's own net stream is a pretty horrible-sounding 64K mp3). Think I'll get another device to play with though :-) For the ever popular question what device to buy, since the models keep changing and the chipsets aren't mentioned anywhere: If you are shopping in Germany, the device above is a SAT.1 co-branded Terratec ran T Stick+ available right now for ~20 EUR. I tested this with the RTL2832U+R820T sold by Hossen (in Amazon store, shipped from Singapore) - there are also various RTL2832U+E9000 devices e.g. one sold by NooElec in the US. (if you were to buy a random device from ebay, you'd be more likely to find an R820T tuner; this works fine with rtl-sdr; if you're also wanting to use it for tv on Linux, you need an updated kernel module from linuxtv.org).
Re: panic: got error 5 while accessing filesystem
I wasn't able to find out what error 5 is. EIO. There are probably horrible I/O error messages in your dmesg prior to this panic. I will try disabling softdeps on that filesystem. This will indeed avoid the panic (which occurs because at this point there is no way to propagate the I/O error up to the filesystem operation which has triggered it), but that won't fix the I/O error. I'd suggest doing backups and gettting ready to replace the disk. Miod
Re: open source laptop battery repair?
The repair I was talking about is mostly physically replacing cells with new ones and making the pack work with the laptop again. There's enough difference between the prices of cells (lithium ion) and the packs (Dell wants $110 for mine) to make that worthwhile. But there are other repairs. You can buy batteries on eBay cheap that have been refilled only sometimes they aren't that great. I'd like to know what's going on inside. Also other things: I installed a new WiFi card and in the process of finding the right Windows driver for it Windows bluescreened a few times. Now one battery isn't recognized at all, the other is permanently discharged and won't charge, either under Windows or OpenBSD. Something got written to an EEPROM somewhere, unless something popped the thermal fuse inside the pack or fried some hardware in the laptop. The 2 batteries have different symptoms. Most of these schemes use an adapter with a few transistors or an IC to connect to a disconnected battery pack over a USB or LPT port, they don't disrupt what's happening in the computer. The bus is related to iic or i2c with slight differences. There are 2 wires (clock and data) plus ground. Try sysctl | grep bat (on a laptop). How do the analog cell voltages get converted to digital values you read on the screen? It's in the battery pack itself. There's a TI gas gauge chip or similar in the pack. There's more at work than most people suspect, some are even passworded. See http://media.blackhat.com/bh-us-11/Miller/BH_US_11_Miller_Battery_Firmware_Public_WP.pdf until it gets moved. Alan On 4/28/13, Francois Pussault fpussa...@contactoffice.fr wrote: Battery repair soft-tools are just fake or legend for laptops, because most of batteries are using LI-ON technology so when battery has been badly used (for example still in the machine while running 100% of time on sector for about a year), the battery is chemically modified inside of itself. so it can never be repaired, you can get a few more battery time for example a battery that take charge of 50% its nominal capacity, will go up back to 60 or 75% for a short period of time (few month) (software tools will show 100% but reality will be 60 to 75%). but then will decrease it capacity very fast , faster by far, than if you didn't try to force its repair... this is worst again, for older batteries technologies. hardware tools exist that can do the job with better results but they are not cheap. From: Alan Corey alan01...@gmail.com Sent: Sun Apr 28 07:16:46 CEST 2013 To: misc@openbsd.org Subject: open source laptop battery repair? Just wondering if anyone knows about tools for laptop battery repair that might run under OpenBSD. The smart batteries have a microprocessor that interfaces to the cells and talks to the cpu over an smbus. ACPI talks to that bus, but it can't help with broken batteries or replacing cells. Google for a pdf called BH_US_11_Miller_Battery_Firmware_Public_WP.pdf if you want to read more. There's a semi-commercial program called be2works designed for cell replacement and such, but the full version is $300. Is there anything open source? BTW: Miller's bibliography at the end of the pdf above is quite good. I was able to download all the pdfs he mentions. Most are from TI. Unfortunately he was working with Apple hardware, I've got Dell. But he got in there with logic analyzers and the whole bit. Alan -- Credit is the root of all evil. - AB1JX Cordialement Francois Pussault 3701 - 8 rue Marcel Pagnol 31100 Toulouse France +33 6 17 230 820 +33 5 34 365 269 fpussa...@contactoffice.fr -- Credit is the root of all evil. - AB1JX
Re: panic: got error 5 while accessing filesystem
On Apr 28 12:55:58, m...@online.fr wrote: I wasn't able to find out what error 5 is. EIO. There are probably horrible I/O error messages in your dmesg prior to this panic. Actually, there are none. Could this indicate that the USB enclosure or the cable is faulty? The disk is functioning without a glitch now. I am running dd if=/dev/sd0c of=/dev/null bs=8m to see if it reports some errors. I will try disabling softdeps on that filesystem. This will indeed avoid the panic (which occurs because at this point there is no way to propagate the I/O error up to the filesystem operation which has triggered it), but that won't fix the I/O error. I'd suggest doing backups and gettting ready to replace the disk. Yes, I did a backup of those backups :-)
Re: open source laptop battery repair?
Hi Alan, Alan Corey wrote: Just wondering if anyone knows about tools for laptop battery repair that might run under OpenBSD. The smart batteries have a microprocessor that interfaces to the cells and talks to the cpu over an smbus. ACPI talks to that bus, but it can't help with broken batteries or replacing cells. Google for a pdf called BH_US_11_Miller_Battery_Firmware_Public_WP.pdf if you want to read more. There's a semi-commercial program called be2works designed for cell replacement and such, but the full version is $300. Is there anything open source? BTW: Miller's bibliography at the end of the pdf above is quite good. I was able to download all the pdfs he mentions. Most are from TI. Unfortunately he was working with Apple hardware, I've got Dell. But he got in there with logic analyzers and the whole bit. Although the document contains interesting internal details about the hardware, I don't think these are very useful when dealing with broken batteries. Most of the communication is shielded by the APM/ACPI/other power manager. Being the author of BatMon for gnustep and owner of several laptops with different operating systems, I have some empirical experience. You may try to use http://gap.nongnu.org/batmon/ and depending on the OS/BIOS/Battery you might get a little interesting information I think that when a battery goes bad, everything which is problematic is inside the battery. I also do think that the powermanagment more than often does a bad job, but there isn't much you can do. I have batteries which sometimes do run for 1 hour or more, but the power manager reports them as dead (= little internal capacity). The chip inside tries to know: 1) the design capacity 2) the maximum capacity reached after the last charge 3) current capacity. Furthermore usually it tries to count the cycles 1) is always correct for original equipment batteries. I have seen cheap oem batteries with wrong values and it might be wrong if you susbstitute the elements inside with wrong 2) and 3) are what go wrong. Usually, you should see 2) slowly decreasing with each cycle. A sane but old battery drops about a small percent each time, so that perhaps after 400 cycles you are to 80% capacity. Nothing you can do about it! Sometimes the battery thinks it has a too low capacity. In this case, weird things happen. THee best case is that you will get like 5 minutes left but actually your computer continues to operate. Most often you will get an abrupt drop and you rcomptuer goes off before giving a meaningful warning... or whatever else. Sometimes this might happen if just one of the elements goes bad. Laptop batteries do not have a balancing method, as far as I know. Anyway, the battery should recalibrate itself after a full discharge cycle (Li-Ion don't have memory, but their chip drifts). But I have noticed that more recent and smarter batteries essentially fail to do that. But essentially, other than trying to reset and force a recalibration with a tool from the host, I don't know what you else could do. Most tools are more like smart dischargers that end up trying to make the battery pack recalibrate itself. I have found a lot of voo-doo on the web.. and found many bad batteries :) One last thing. If one or more elements of a LiIon cell drop below a certain value, a circuit breaker opens the battery. No voltage out, but apparently in my experience, no way to recharge such a battery pack either! A LiIon cell should never discharge below a certain level, thus it is better to store batteries half-charged, not discharged. This is also the reason why LiOn batteries come pre-charged. Not for courtesy, but because they need to! Riccardo
OpenSSH sshd -E
I see a useful feature in OpenSSH 6.2(?) in current that is not in the release notes for 6.2. In the man page for sshd(1) in current there is this: -E log_file Append debug logs to log_file instead of the system log. But I can't find anything about it in the release notes: http://www.openssh.org/txt/release-6.2 Is this something from upcoming 6.3 or was it missed in the release notes for 6.2? Regards, /Lars
dhclient drops address on re-exec in 5.3 bsd.rd
Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david dhclient will *always* remove all existing address on interfaces it is binding a lease to. Are you saying that the 2nd time around it is not re-assigning the address? Is your easy workaround to re-run dhclient, or is it something else? As soon as some builds finish here I will try to reproduce. Ken
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david Can't reproduce on amd64 -current here. I did control-C after getting dhclient lease, entered 'upgrade' at command prompt, and re-started upgrade. dhclient worked fine. Checked 'ifconfig' and the expected address was present. So more info you what exactly you are doing, on what machine are you doing it, and perhaps anything interesting in your dhclient.conf would be helpful. Thanks. Ken
ARK-2120L
Hi, I'm intending on getting a ARK-2120L [1] to server as a gateway for my network. I've been doing some research as to whether or not it'll work on OpenBSD. So far I've evaluated: CPU (Intel Atom, should work fine). LAN (82583V, is listed as working with em). However, I'm curious as to whether I should take something else into consideration, in particular, the chipset. Do I need to check for some other driver compatibility, or should that be it? Do thing like the USB chipset require a specific driver, or is that sort of stuff standard? (sorry, I'm a bit ignorant on this regard). I'm also slightly curious about the video driver. I don't care about X, or video acceleration, since I'll only use video for OpenBSD installation, nothing else. Should video work for any modern video card, even if only at a very poor resolution? Or do I still need to be careful about driver support? [1] http://www.advantech.com/products/ARK-2120L/mod_BD7B04DE-B994-4D74-96DE-21CDB 3F8158B.aspx [2][PDF] http://cms.tempel.es//adimage.php?filename=9_015551.pdfcontenttype=pdf Thanks, -- Hugo Osvaldo Barrera [demime 1.01d removed an attachment of type application/pgp-signature]
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david Can't reproduce on amd64 -current here. I did control-C after getting dhclient lease, entered 'upgrade' at command prompt, and re-started upgrade. dhclient worked fine. Checked 'ifconfig' and the expected address was present. So more info you what exactly you are doing, on what machine are you doing it, and perhaps anything interesting in your dhclient.conf would be helpful. Thanks. Ken I would have provided output, but I haven't figured out how to log console output from VMware images. Hopefully this will suffice: i386 / 5.3-current / RAMDISK_CD #120 dhclient #1 (good) DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds dhclient #2 (bad) DHCPREQUEST on vic0 to 255.255.255.255 port 67 Active address (172.16.223.131) deleted; exiting dhclient #3 (good) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds amd64 / 5.3-current / RAMDISK_CD #132 dhclient #1 (good) DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds dhclient #2 (still good) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds /etc/dhclient.conf appears to be identical to between i386 and amd64. I am sending an identical hostname FWIW, but I am only launching only one VM at a time. initial-interval 1; send host-name vm; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; Let me know if you want me to try anything else. --david
Re: open source laptop battery repair?
On 4/28/13, Riccardo Mottola riccardo.mott...@libero.it wrote: Hi Alan, Although the document contains interesting internal details about the hardware, I don't think these are very useful when dealing with broken batteries. Most of the communication is shielded by the APM/ACPI/other power manager. Being the author of BatMon for gnustep and owner of several laptops with different operating systems, I have some empirical experience. You may try to use http://gap.nongnu.org/batmon/ and depending on the OS/BIOS/Battery you might get a little interesting information sysctl | grep bat shows me hw.sensors.acpibat1.volt0=11.10 VDC (voltage) hw.sensors.acpibat1.volt1=9.30 VDC (current voltage) hw.sensors.acpibat1.current0=0.00 A (rate) hw.sensors.acpibat1.amphour0=3.04 Ah (last full capacity) hw.sensors.acpibat1.amphour1=0.43 Ah (warning capacity) hw.sensors.acpibat1.amphour2=0.13 Ah (low capacity) hw.sensors.acpibat1.amphour3=0.00 Ah (remaining capacity), CRITICAL hw.sensors.acpibat1.raw0=2 (battery charging), OK by reading from the acpi. the hw.sensors.acpibat1.volt1 was at 10.97 2 days ago. That's the only change I've seen. This is on a CD/DVD bay battery, the other one is not recognized at all since the Windows crash, so I took it back out. What the be2works setup uses is an adapter designed by Philips to connect from a USB or parallel port to a battery pack after you take the battery pack out. It talks to the gas gauge chip directly, without acpi getting in the way. smbus is just 2 wires (plus ground), and you don't hurt anything if you get the clock and data backwards, it just doesn't work. The adapter is mostly a 74LS05 set of inverters, but you could use a few transistors to do the same job if you don't have a 74LS05. Just level translation mostly. The be2works download includes a schematic of what to build, but it's a copy of what Philips designed. I've seen that 80% figure before, it's what lithium ion batteries go to after about 400 charge/discharge cycles. NiMH would be about useless by then. This is my 4th Dell laptop. I've also got a C610 that takes the same battery as the CPIa before it, and I haven't bought a new battery for that in several years. It's down to the 80% point but still working. I don't think that's a smart battery, and this one did come from eBay. But why would Windows crashing because of a wrong driver for a WiFi card kill a battery? Neither Windows or Openbsd recognizes it, they both say the battery is absent. I think the internal fuse blew. The CD/DVD bay battery is recognized, supposedly it's charging, but it never gets anywhere. After 2 days charging it still won't boot the laptop. And both of these batteries are less than 1 month old. Or at least I bought them that recently on eBay. I don't know what's in them exactly. Could be old cells or cheap cells. I don't believe in trying to rejuvenate a battery pack any more than a CRT. There's some good information (and a lot of batteries) at http://www.batteryspace.com/ If you look at what the be2works program does and what's in the TI PDFs I think it's possible to write something that talks directly to a gas gauge chip in (an unplugged) battery with an adapter. Alan I think that when a battery goes bad, everything which is problematic is inside the battery. I also do think that the powermanagment more than often does a bad job, but there isn't much you can do. I have batteries which sometimes do run for 1 hour or more, but the power manager reports them as dead (= little internal capacity). The chip inside tries to know: 1) the design capacity 2) the maximum capacity reached after the last charge 3) current capacity. Furthermore usually it tries to count the cycles 1) is always correct for original equipment batteries. I have seen cheap oem batteries with wrong values and it might be wrong if you susbstitute the elements inside with wrong 2) and 3) are what go wrong. Usually, you should see 2) slowly decreasing with each cycle. A sane but old battery drops about a small percent each time, so that perhaps after 400 cycles you are to 80% capacity. Nothing you can do about it! Sometimes the battery thinks it has a too low capacity. In this case, weird things happen. THee best case is that you will get like 5 minutes left but actually your computer continues to operate. Most often you will get an abrupt drop and you rcomptuer goes off before giving a meaningful warning... or whatever else. Sometimes this might happen if just one of the elements goes bad. Laptop batteries do not have a balancing method, as far as I know. Anyway, the battery should recalibrate itself after a full discharge cycle (Li-Ion don't have memory, but their chip drifts). But I have noticed that more recent and smarter batteries essentially fail to do that. But essentially, other than trying to reset and force a recalibration with a tool from the host, I don't know what you else could do.
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote: On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david Can't reproduce on amd64 -current here. I did control-C after getting dhclient lease, entered 'upgrade' at command prompt, and re-started upgrade. dhclient worked fine. Checked 'ifconfig' and the expected address was present. So more info you what exactly you are doing, on what machine are you doing it, and perhaps anything interesting in your dhclient.conf would be helpful. Thanks. Ken I would have provided output, but I haven't figured out how to log console output from VMware images. Hopefully this will suffice: i386 / 5.3-current / RAMDISK_CD #120 dhclient #1 (good) DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds dhclient #2 (bad) DHCPREQUEST on vic0 to 255.255.255.255 port 67 Active address (172.16.223.131) deleted; exiting Is there a configured ip address on the interface at this point? This is a message emitted by one dhclient on noticing that another one is active and has deleted the address the first one configured. It *shouldn't* mean that no ip address is configured. Now what is different in the virtual environment you are using that makes i386 timing different than amd64 ... dunno. Ken dhclient #3 (good) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds amd64 / 5.3-current / RAMDISK_CD #132 dhclient #1 (good) DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds dhclient #2 (still good) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds /etc/dhclient.conf appears to be identical to between i386 and amd64. I am sending an identical hostname FWIW, but I am only launching only one VM at a time. initial-interval 1; send host-name vm; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; Let me know if you want me to try anything else. --david
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote: On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david Can't reproduce on amd64 -current here. I did control-C after getting dhclient lease, entered 'upgrade' at command prompt, and re-started upgrade. dhclient worked fine. Checked 'ifconfig' and the expected address was present. So more info you what exactly you are doing, on what machine are you doing it, and perhaps anything interesting in your dhclient.conf would be helpful. Thanks. Ken I would have provided output, but I haven't figured out how to log console output from VMware images. Hopefully this will suffice: i386 / 5.3-current / RAMDISK_CD #120 dhclient #1 (good) DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds dhclient #2 (bad) DHCPREQUEST on vic0 to 255.255.255.255 port 67 Active address (172.16.223.131) deleted; exiting Trying the exact same RAMDISK_CD #120 on 'real' i386 hardware with an nfe(4) interface, I cannot reproduce. So I suspect (assuming it is not just an errant log message) something is broken in the i386/vm interface you are trying. Ken dhclient #3 (good) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds amd64 / 5.3-current / RAMDISK_CD #132 dhclient #1 (good) DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds dhclient #2 (still good) DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.130 -- renewal in 900 seconds /etc/dhclient.conf appears to be identical to between i386 and amd64. I am sending an identical hostname FWIW, but I am only launching only one VM at a time. initial-interval 1; send host-name vm; request subnet-mask, broadcast-address, routers, domain-name, domain-name-servers, host-name; Let me know if you want me to try anything else. --david
Re: ARK-2120L
Hugo Osvaldo Barrera h...@osvaldobarrera.com.ar writes: Hi, Hi, I'm intending on getting a ARK-2120L [1] to server as a gateway for my network. I've been doing some research as to whether or not it'll work on OpenBSD. So far I've evaluated: CPU (Intel Atom, should work fine). LAN (82583V, is listed as working with em). However, I'm curious as to whether I should take something else into consideration, in particular, the chipset. Do I need to check for some other driver compatibility, or should that be it? The datasheet doesn't provide much information except supported by Linux 2.6. Do thing like the USB chipset require a specific driver, or is that sort of stuff standard? (sorry, I'm a bit ignorant on this regard). I wouldn't worry about USB. I'm also slightly curious about the video driver. I don't care about X, or video acceleration, since I'll only use video for OpenBSD installation, nothing else. Should video work for any modern video card, even if only at a very poor resolution? Or do I still need to be careful about driver support? This model has four serial ports, that would probably be nicer than needing a screen and a keyboard. [1] http://www.advantech.com/products/ARK-2120L/mod_BD7B04DE-B994-4D74-96DE-21CDB 3F8158B.aspx [2][PDF] http://cms.tempel.es//adimage.php?filename=9_015551.pdfcontenttype=pdf Thanks, -- Hugo Osvaldo Barrera [demime 1.01d removed an attachment of type application/pgp-signature] -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
Re: open source laptop battery repair?
If the battery doesn't want(/show) to charge, sometimes a sleazy trick can do the job: detach it while pc is running on AC and reattach it, sometimes you need to do that more than once. Sometimes after this you gotta keep'em charging some hours and then try again (it all depends on batteries, this is more likely to work on oem equipment). If this doesn't work try, as Riccardo said, changing the elements, but NEVER EVER fiddle with the electronics... if it goes bad it could set in 1/10th of a second li-ion batteries to go off as a bomb or to catch fire (google a bit for this). Good luck!
Re: dhclient drops address on re-exec in 5.3 bsd.rd
On Sun, Apr 28, 2013 at 6:39 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sun, Apr 28, 2013 at 05:29:05PM -0400, David Higgs wrote: On Sun, Apr 28, 2013 at 4:00 PM, Kenneth R Westerback kwesterb...@rogers.com wrote: On Sun, Apr 28, 2013 at 02:41:36PM -0400, David Higgs wrote: Confirmed in 5.3-current downloaded several minutes ago. Steps to reproduce: - Boot bsd.rd - Select upgrade, hit enter until dhclient gets and assigns an address - Complete upgrade or control-C, then restart the upgrade process - dhclient on 2nd run REMOVES the assigned address Probably affects the bsd.rd install option as well. This does not happen with 5.2 bsd.rd. Easy to work around, but probably not right. Thanks! --david Can't reproduce on amd64 -current here. I did control-C after getting dhclient lease, entered 'upgrade' at command prompt, and re-started upgrade. dhclient worked fine. Checked 'ifconfig' and the expected address was present. So more info you what exactly you are doing, on what machine are you doing it, and perhaps anything interesting in your dhclient.conf would be helpful. Thanks. Ken I would have provided output, but I haven't figured out how to log console output from VMware images. Hopefully this will suffice: i386 / 5.3-current / RAMDISK_CD #120 dhclient #1 (good) DHCPDISCOVER on vic0 to 255.255.255.255 port 67 interval 1 DHCPOFFER from 172.16.223.254 (mac addr) DHCPREQUEST on vic0 to 255.255.255.255 port 67 DHCPACK from 172.16.223.254 (mac addr) bound to 172.16.223.131 -- renewal in 900 seconds dhclient #2 (bad) DHCPREQUEST on vic0 to 255.255.255.255 port 67 Active address (172.16.223.131) deleted; exiting Trying the exact same RAMDISK_CD #120 on 'real' i386 hardware with an nfe(4) interface, I cannot reproduce. So I suspect (assuming it is not just an errant log message) something is broken in the i386/vm interface you are trying. Ken More simple tests on i386 follow. The every other failure is pretty repeatable but I have seen a couple cases where it worked. I wouldn't be surprised if the opposite applies to the non-zero sleep test. 1. Always OK: from bsd.rd - dhclient vic0 2. Fail: from bsd.rd - ifconfig vic0 down ; dhclient vic0 3. Fail: from bsd.rd - ifconfig vic0 down ; sleep 0 ; dhclient vic0 4. OK: from bsd.rd - ifconfig vic0 down ; sleep 0.001 ; dhclient vic0 5. Always OK: from bsd - ifconfig vic0 down ; dhclient vic0 Smells like a driver timing or hardware emulation bug to me. I am running OpenBSD as 32-bit Other, inside VMware Fusion 4.0.4 if that makes any difference. Anything else I can do or provide to help? dmesg output (apologies for gmail's line wrapping): OpenBSD 5.3-current (RAMDISK_CD) #120: Thu Apr 25 17:10:53 MDT 2013 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz (GenuineIntel 686-class) 2.40 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,NXE,LONG,SSE3,SSSE3,CX16,LAHF,PERF,ITSC real mem = 267907072 (255MB) avail mem = 256258048 (244MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/20/12, BIOS32 rev. 0 @ 0xfd780, SMBIOS rev. 2.4 @ 0xe0010 (364 entries) bios0: vendor Phoenix Technologies LTD version 6.00 date 09/20/2012 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 65MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xdc000/0x4000! 0xe/0x8000! pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x01 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x08 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: VMware Virtual IDE Hard Drive wd0: 64-sector PIO, LBA, 16384MB, 33554432 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) Intel 82371AB Power rev 0x08 at pci0 dev 7 function 3 not configured VMware Virtual Machine Communication Interface rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 VMware Virtual SVGA II rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) ppb1 at pci0 dev 17 function 0 VMware Virtual PCI-PCI rev 0x02 pci2 at ppb1 bus 2 vic0 at pci2 dev 0 function 0 AMD 79c970 PCnet-PCI rev 0x10: apic 1 int 18, address 00:0c:29:71:66:01 ppb2 at pci0 dev 21 function 0 VMware Virtual PCIE-PCIE rev 0x01 pci3 at ppb2 bus 3 ppb3 at pci0 dev 21
Re: Why does OpenBSD use CVS?
On 2013-04-20 23:32, Nick Holland wrote: On 04/20/13 03:42, Alokat MacMoneysack wrote: Hi, first, I don't want to start a flame war about why is CVS better or not better than X - it's just a question. If you say, we use it because it just works - it's okay. :) Good, 'cause it does. :) So why does OpenBSD still uses CVS and don't migrate to SVN or something like git as other OSS projekts do? * it works * migrating - and not losing history is difficult. * migrating versioning systems is something you don't want to do every few weeks (or even every few years)...so you want to make sure it is really worth it if/when you do. SVN today? GIT next week? something else next year? Please, no. * Tolerable -- and in the case of opencvs, ideal -- license. * its glitches are hated, but known (the devil you know how to subdue, vs. the devil who beats the sh*t out of you) * relatively light weight -- runs fine on a 486, hp300, or on a modern, fast machine, fits nicely into existing distribution, easy to drop into a chroot. * Infrastructure exists. To change it all would require a really good reason. * it fits the OpenBSD development model. * Many of the features of alternatives are not desired in the OpenBSD development model. Out of curiosity; what are these features? Obviously, it is possible to build a quality-focused product of Operating System magnitude using CVS. I don't think one can quite say CVS is the REASON for OpenBSD's quality, but it obviously hasn't hurt. Nick. -- Hugo Osvaldo Barrera [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Why does OpenBSD use CVS?
On 2013-04-20 12:15, Stuart Henderson wrote: On 2013-04-20, Alokat MacMoneysack mail...@alokat.org wrote: Hi, first, I don't want to start a flame war about why is CVS better or not better than X - it's just a question. If you say, we use it because it just works - it's okay. :) So why does OpenBSD still uses CVS and don't migrate to SVN or something like git as other OSS projekts do? Regards, fritjof my 2p: like all version control software CVS has bugs, but between us, developers have a reasonable idea of how to avoid them in CVS, there's less knowledge about other version control systems. Also having the repository stored in human-readable (ish) files is an advantage if there was ever any repo corruption. Some other CVS keeps checksums of every commit, and every commit contains the checksum of the last commit + this commits diff. This helps *prevent* corruption (or at least prevents it from spreading). I think that beats human-readable files to manually find corruptions (that may well spread). You might also ask why some other OS use source control software which they don't even include in the base OS ;-) -- Hugo Osvaldo Barrera [demime 1.01d removed an attachment of type application/pgp-signature]
