emily ingalls <emily@ingalls.rocks> writes: > i recently got a card that uses a Hifn 7955, and figured i'd take a > look at the driver for it while i was setting it up. i almost > immediately found issues that would likely cause hangs or crashes > (maybe even damage to the chip, not sure) on some machines, possibly > unexpectedly slow operation on others, and could have unexpected and > hard to detect side effects elsewhere due to possible clock > instability. I suspect the basic issue is that these chips are much less common than they used to be among netbsd users. I have a hifn card in a soekris net5501 that used to mostly work, but I had some trouble and disabled it and never got around to it. I have since replaced the 5501 with an apu2. However, netbsd culture is that everything ought to work well, even for older things. > i have a vested interest in having this driver work properly and > securely in NetBSD, and i'm interested in sending in patches and > possibly doing a more extensive audit/rewrite, but it looks like the > driver is currently disabled, and there's been little work the past By disabled, you probably mean "commented out in GENERIC". That's mostly a judgement about "does it work well and is the benefit to people that have the hardware enough to outweight the RAM usage on all the other boxes". For things that are rare, this tends to lead to it being commented out. So just enable it and see. > few years that hasn't been pulling changes from openbsd. so... is > anyone maintaining it at all? Probably not, but help is always welcome. > would i be better off going to OpenBSD for this, and then trying to > merge updates here once they're accepted there (despite having little > interest in OpenBSD personally)? If what you want to do is run NetBSD, then I would recommend first seeing how it works as is (unless your code reading says that's too scary), and then merging the openbsd changes since last sync. If no one speaks up and says they are paying attention, I'd expect someone here to apply your changes, and if not you can run it locally. You might also try DEBUG, LOCKDEBUG, and sanitizers to look for trouble, but it sounds like you are seeing misprogramming of the chip more than that sort of things. A message here, perhaps post sync, of what you are seeing that seems wrong is also appropriate and may get some useful comments. Greg
Attachment:
signature.asc
Description: PGP signature