Re: goodbye to some isa devices
On 03/27/2013 03:06 PM, Chris Cappuccio wrote: OpenBSD/i386 isn't likely to change major platform support any time soon, if ever. The port for dropping legacy crap would be OpenBSD/amd64. Now, look at its kernel config. You'll see, that was already done. ta-da! I bought an old, high-end 80386 system from a Goodwill store for $5 some 6 or 7 years ago. I was kinda depressed that it wouldn't boot OpenBSD anymore, but then I wet my pants when I got KA9Q NOS working on it. That sounds pretty good--most of my EDA and other stuff is run on AMD64. Didn't most of the Linuces drop pre-P2 support some time ago (ie.g. P1, AMD K6, etc.)? It could be that getting the older architectures to work is as simple as recompiling the kernel, but I haven't checked into it. Maybe it would be handy to have a minimum binary distro just sufficient to boot and recompile from source, if need be. So if you've got a 486 or P1 K5, K6, Crusoe or whatever, you could still get there without searching out a more-up-to-date system. --Chuck
Re: goodbye to some isa devices
On 03/27/2013 01:01 PM, Creamy wrote: Or, more realistically, perhaps you could just choose to maintain the -patch branch of a particular version that was of interest to you. For example, if we stopped supporting 486 in 6.0, by way of example, what is to stop you taking 6.0 and maintaining a -patch branch of it for ever more, backporting any new security and other important patches? Frankly, that would probably benefit the community much more than trying to keep the main distribution working on ancient kit forever more. Please don't put too much weight on a comment which was said quite casually as a small part of a much wider discussion. That's probably the best approach--as long as basic things such as networking protocols don't change too much, I can deal with the build-from-source-branch issue. You can sort of see this business of deprecation creeping in, even though no broad consensus seems to be behind it. For example, the current Linux X86 kernel apparently does not support some VIA IDE controllers (IIRC, VIA 8237?), so my Via Esther thin clients won't boot using it (OpenBSD runs fine, however). So my hat's off to the community for keeping what it does keep. --Chuck
Re: goodbye to some isa devices
On 03/27/2013 09:35 AM, Alexey G. Khramkov wrote: Please, don't do this. I've jumped from OpenBSD to NetBSD boat when SCSI driver were rewritten to the "new" version (between 3.1-stable and 3.2-stable), and my "very branded" HP NetServer with AIC-7770 (which can work on IRQ 14 when primary IDE channel is disabled or IRQ 15 when IDE channel is enabled, no other IRQs are possible) ceased to work. For now, my old Acer netbook with AMD Turion processor is "too old" for NetBSD (my touchpad doesn't work "out of the box"). That's why I'm reading this mail list. Just FYI. I've got to join my voice with Alexey here. A good part of my work is resurrecting and keeping old specialized industrial equipment going. This is the world where 8" floppies are not uncommon and I get requests to retrieve data from old DC300XL QIC carts. Since the controller (and any interface cards) are part of what makes the equipment go, it just isn't a matter of getting a new commodity box and installing new software. If you have a quarter-million invested in a specialized tool, it pays to keep it going as long as possible. My point (and I think, Alexey's) is that not everyone uses BSD for browsing the web and exchanging email. There are still some applications out there that are still running on the same equipment from 20 years ago. I find that NetBSD's "Of course it runs NetBSD" slogan rings a little hollow these days. Perhaps expecting software to run on both new and old gear isn't practical. If that's the case, I'll continue to hang onto my old copies of distros, the same way that I hang onto copies of MS-DOS, Windows 3.1 and Windows 98. All the best, Chuck Guzis Eugene, OR
HG2F09 "mystery" USB-to-ethernet adapter fix
Lately, a bunch of cheap Chinese USB-to-Ethernet dongles have been
making their appearance in various parts of the world by a Chinese
vendor. Often these can be gotten for around USD$2 or less. They're
frequently referred to as "HG2f09" adapters.
The VID/PID is 066b/20f9, which would lead one to think that the maker
is Linksys--except the PID doesn't appear in any Linksys registry. So
we've got a counterfeit. (Why pay good money to IF-USB when you can
just "borrow" a VID? I've seen the same thing in cheap USB flash drives. )
A bit of probing shows the operative device is the Asix AX88772B (and
has been verified by others).
The pragmatic approach would be to reprogram the serial configuration
EEPROM in this thing to match something better known, say, the Linksys
USB200, but Asix Taiwan is not forthcoming with their programming
utility, citing "confidential, restricted to verified customers".I'm
not inclined to tear my hair out trying to write a utility for a $2 part
(there are some pretty good hints in the Asix datasheet).
Mine arrived with a mini-CD containing Windows drivers (uncertified, of
course) and Linux source (no good for OpenBSD).
At any rate, a stopgap solution for me was to simply add the following
line to the 5.2 USB if_axe.c axe_devs[] structure:
{ { USB_VENDOR_LINKSYS, 0x20f9}, AX772 | AX772B}, // Fake Linksys
HG20f9
It's an ugly hack, but it seems to work just fine. I have a bit of a
dilemma tagging the code as if this really were a Linksys-badged
device. I'll leave the symbolic definitions to those official
custodians of OpenBSD source for a cleaner version, should the need for
this arise.
You can see the extent of the problem, just by searching the web for
"HG2f09".
Perhaps there should be some sort of USB VID/PID "aliasing" capability
to avoid having to rebuild the kernel for this sort of thing.
Submitted for whatever it's worth...
Cheers,
Chuck Guzis
Sydex, Inc.
