Date: Sun, 22 Oct 2006 13:30:28 GMT From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/104675: Apparently there is a clash between two ioctls Message-ID: <200610221330.k9MDUSMu007528@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/104675; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: "Jukka A. Ukkonen" <jau@iki.fi> Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/104675: Apparently there is a clash between two ioctls Date: Sun, 22 Oct 2006 23:24:10 +1000 (EST) On Sun, 22 Oct 2006, Jukka A. Ukkonen wrote: >> Description: > It seems that the bktr driver cannot change the input connector > used when using a card with multiple connectors. > When I used ktrace to see what happens at the kernel API level > I got somewhat disturbing output... > > 56314 try CALL ioctl(0x3,METEORGINPUT,0xbfbfed24) > 56314 try RET ioctl 0 > 56314 try CALL ioctl(0x3,SERIAL_SETINVCLK,0xbfbfed20) > 56314 try RET ioctl 0 > 56314 try CALL ioctl(0x3,METEORGINPUT,0xbfbfed20) > 56314 try RET ioctl 0 > > It seems that METEORGINPUT is recognized properly but its > complement METEORSINPUT is not. Instead METEORSINPUT gets > mapped to something completely unrelated (SERIAL_SETINVCLK). This is probably not the real problem. There are too many ambiguous ioctls for kdump to fix, so kdump carefully avoids seeing the problem by not invoking mkioctls with -s. But this is only a debugging problem. The ioctl numbers are unique for each device, so device drivers have no problems with their ambiguity. To do the same for just the above, kdump would have to determine that fd 0x3 is for bktr and use bktr's ioctl switch statement instead of Cronyx serial's one. It now just uses an elseif ladder that has all the ioctls but only finds the first match. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610221330.k9MDUSMu007528>