Date: Sat, 22 Jul 2000 00:39:32 -0700 From: "Lawrence Cotnam Jr." <larry@pkunk.net> To: "Matthew N. Dodd" <winter@jurai.net>, <sos@freebsd.org>, <freebsd-hardware@freebsd.org> Subject: RE: Legacy Device Support (Was RE: No help...) Message-ID: <MKEOLDIJFGDJKDLHGFEGGEFOCBAA.larry@pkunk.net> In-Reply-To: <Pine.BSF.4.21.0007220226050.610-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
| -----Original Message----- | From: Matthew N. Dodd [mailto:winter@jurai.net] | Sent: Friday, July 21, 2000 11:34 PM | To: Lawrence Cotnam Jr. | Cc: Josh Paetzel; freebsd-questions@FreeBSD.ORG; | freebsd-hardware@FreeBSD.ORG | Subject: Re: Legacy Device Support (Was RE: No help...) | | > I certainly agree, more effort should be applied toward writing code and | > support for the new devices out there, but at the same time, I think a | > strong commitment to maintaining legacy code for older devices, | especially | > when such devices had code in the system before wouldn't be | very difficult. | | So who is supposed to have this "strong commitment"? My desire to play | with old hardware only covers so much commitment before I get frusterated | or bored or distracted with something else. Are you suggesting that this | "strong commitment" be expressed in a staffing budget and if so who's | budget? I don't have all the answers. I'm just a frustrated user with legacy hardware. In the past, that frustration has been with hardware that drivers existed for, then future releases discontinued support for such hardware. I'm just confused and don't understand exactly why code that was functional, usable, was later removed from the distributions. Honestly, I've taken a whole lot of flak for writing about my frustration. Maybe I deserve it, or maybe I don't. But I'm just giving everyone else my opinion, my experience, and what I felt was the only way to get things here, in my home office, back on track, so I can get back to work and not have to worry about it anymore. As far as patches go, I have here, on my system, the Linux 3COM 3C515 driver code. *IF* I had some fixed up SiS 5591 support, I could probably port this code into the FreeBSD kernel. Can't be *THAT* hard to adapt the code to FreeBSD. I feel up to doing it. But I already took a stab at fixing the problems with the SiS 5591 and ended up with a corrupted HD as a result, so I don't think I can figure out what's going on in there, not on my own, at least. Poking the kernel source is something I've done.. maybe 2 or 3 times. But this frustration is a direct result of just plain being ignored. Waving my hands around and going 'Look guys, I'm frustrated, so I'm going to run something else' got a helluv a lot of attention. I'm a little disappointed that's what it took, but now that I have your attention, can we work together to resolve some of these problems? I'll list them again. First, the 3COM 3C509 driver seems to have a problem. What? I don't know. I have symptoms and no answers. Running MTU 1500 on my LAN results in stalling.. the server periodically chokes for a few moments every few moments, during sustained data transfer. This seems to much more strongly affect transmission, than reception. I've seen usually that things go fine if my workstation sends, and server receives, but stalling occurs when its the other way around. Dropping MTU to 1000 (or lower) cures this problem, but introduces new ones. My Hub's collision light stays lit solid during any sustain transfers, in either direction, and twice I experienced a total freeze of the network layer, where no communication would occur. Coming in from the console, pinging out returned 'No buffer space available.' This stayed true for about 5 minutes. I did kill all server daemons and any active transfers processes. That's the information I have. If there's ways I can provide more, please advise and I'll take the necessary steps to collect additional diagnostic data. The 3C515 has zero support. There is no driver. Second, SiS 5591 Bus Mastering IDE controller. Previously, I ran laptop 1.5G drive on this system. This drive did not support UDMA. Everything ran _PERFECTLY_. Good performance, no problems, no corruptions. Then, I pulled a 13G drive out of my workstation because my server was out of space and put it in. The nightmare began. First, booting GENERIC build of the kernel results in a total FREEZE of the system just after device probing is complete and its going to mount the root file system. Removing the IDE_ATAPI_DMA_SUPPORT (I might have this spelled not quite right) directive from the kernel config file and rebuilding does not change anything, the drivers still detect and enable UDMA. I modified the source for ata-dma.c, forcing the UDMA detection to be bypassed myself, and tried that. Worked, but HARD WRITE errors began to randomly occur and the drive became corrupted. I disabled all ATA drivers in the kernel and used older WD drivers. This works, but its slow and makes my server time warp occasionally (goes backwards, guess because its spending too much time being interrupted.) I just wish I had better hardware, but I don't. The system is a ProTech Single Board computer on an ISA backplane. Everything is on that one card except the NIC, and I have to use ISA NIC's. I have 3 of them. 3C515, 3C509, and an ancient SMC8000. So I've put the two problems back on the table here. I'll do anything anyone tells me to get more diagnostic data in an effort to cure these two problems. If I can get the SiS problem resolved, I can probably port that 3C515 driver over and not even worry about the 3C509, but I'm sure someone would like it if that got fixed too, so I'd happily offer my help to figure out what the heck is going on in there that causes the problems I was seeing. BTW, I'm dropping this thread from the freebsd-questions group, doesn't feel like it needs to be in there anymore. And I'd love to work with you guys to figure this stuff out and do what I can to help. That's all I wanted in the first place, but no one said a thing. I've also included the people listed as responsible for these pieces of code. Lawrence Cotnam Jr. (775) 337-2536 email: larry@pkunk.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?MKEOLDIJFGDJKDLHGFEGGEFOCBAA.larry>