| Summary: | Rocketport driver rocket.ko as included in distribution kernels does not work | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 14 | CC: | aquini, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-08-24 13:22:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
unfortunately, using their script to prepare a version of the driver against a current tree produces an enormous delta, which backs out all the upstream changes since the last time the vendor synced up (which appears to have been a very long time ago). I'd suggest trying to talk the vendor into getting actually working with the kernel community again. We can't carry a delta like this in Fedora, that isn't going upstream. (In reply to comment #1) > > I'd suggest trying to talk the vendor into getting actually working with the > kernel community again. Yes, it would be nice if they would be doing that, wouldn't it? They do not seem to be in hurry (and I do not have much pull there). Quite likely this hardware and its drivers are not the most popular items nowadays. I know that Comtrol has "in works" newer driver versions, which do not require patching for current kernels, but they are not available from their ftp site yet. An unfortunate problem is that I could not get anywhere with a driver included in Fedora kernels while their replacement worked and I failed to figure out why. Hopefully if somebody else will bump into the same issue they will find that report. As Dave said, we can't carry a delta like this in Fedora. Another alternative would be to possibly create a kmod package and get it into rpmfusion. Either way, Fedora doesn't have the resources to fix this at this time. |
Description of problem: More precisely a driver for a Comtrol multiline serial Rocketport card partially does work because with agetty running on corresponding devices it does show /etc/issue and a 'login: ' prompt. Only when comes to asking for a password it falls apart. 'strace' shows that the following happens: ..... 3237 write(2, "Password: ", 10) = -1 EIO (Input/output error) 3237 read(0, 0x7fff0fb5b830, 511) = -1 EIO (Input/output error) 3237 ioctl(0, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {B19200 opost isig icanon echo ...}) = 0 3237 write(2, "\n", 1) = -1 EIO (Input/output error) ..... That makes /bin/login to fail, does not matter if you try to type something or not, agetty respawns and that quickly fills /var/log/messages with failed/respawned messages while it is impossible to log in. Replacing rocket.ko with a module compiled from, currently available, ftp://ftp.comtrol.com/rport/drivers/isa_pci/linux/rocketport-linux-3.13.tar.gz does resolve the issue. Additional info: Note: to compile rocketport-linux-3.13.tar.gz for 2.6.35 kernels and above one has to replace in sources one occurence of 'pci_find_device' with 'pci_get_device' and a kernel does not load that module automatically anymore. Explicitely inserting it on a startup makes all required devices to appear. Quite likely the problem will be present also in Fedora 15 and rawhide kernels but I had a chance to observe that myself on Fedora 14 installation. I do not have affected hardware (Rockeport serial card and terminals) myself.