Re: Problem with tcgetattr

From: Peter T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 09/05/03 

Date: Fri, 5 Sep 2003 20:03:18 +0200

Laurent H. <l.huge@nospam.wanadoo.fr> wrote:
> Peter T. Breuer a crit :
>> Your file descriptor was no good or the struct termios address was
>> nonsensical (afair it was fine).

> I apologize for my english, but I don't understand "nonsensical".

That's OK.

>>Check with strace for more clues.
> I'm not very familiar with strace. Here's the result I suppose linked
> to the problem (I've suppressed the beginning) :

Well done.

> munmap(0x40012000, 49402) = 0
> open("/dev/ttyS0", O_RDWR) = 3
> ioctl(3, SNDCTL_TMR_TIMEBASE, 0xbffff830) = -1 EINVAL (Invalid argument)

Well, that's your ioctl, no? It failed horribly. You might want to
look at the serial kernel driver code and see what the
SNDCTL_TMR_TIMEBASE ioctl does and why it fails.

> dup(2) = 4

Hmm ... but the libc code goes on to try some other stuff.

> fcntl64(4, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)

yow! Somebidy just tried to get a lock on the device :-).

> brk(0) = 0x80498a4
> brk(0x8049a24) = 0x8049a24
> brk(0x804a000) = 0x804a000
> fstat64(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 3), ...}) = 0

And then they statted it. They found it was a char device. Mjor 4,
minor 3. Uh. That's not what I have!!

  nbd:/usr/oboe/ptb% ll /dev/ttyS0
  crw--w--w- 1 root root 4, 64 Sep 5 18:06 /dev/ttyS0

Mine is minor 64. Would you mind checking with devices.txt in the
kernel source that YOU have it right?

At the moment, I would guess that there is nothing attached to your
device file.

> ioctl(4, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0

And then we try the same ioctl a different way. And are happy. We can
read it?

> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0x40012000
> _llseek(4, 0, 0xbfffeea0, SEEK_CUR) = -1 ESPIPE (Illegal seek)

Well, we can't seek it!

> write(4, "tcgetattr: Invalid argument\n", 28) = 28
> close(4) = 0
> munmap(0x40012000, 4096) = 0
> _exit(1) = ?

> So I think the fd is ok, but the ioctl fails. I suspect its third

It looks like the device is wrong.

  4 char TTY devices
                  0 = /dev/tty0 Current virtual console

                  1 = /dev/tty1 First virtual console
                    ...
                 63 = /dev/tty63 63rd virtual console
                 64 = /dev/ttyS0 First UART serial port
                    ...
                255 = /dev/ttyS191 192nd UART serial port

> argument to have to be something like {B115200 opost isig icanon echo
> ...} as with the ioctl of fd 4 (tty to write the error message ?)
> Do you see something relevant ?

yes.

Peter

Relevant Pages

  • Re: [patch] inotify.
    ... >> You are using ioctl as an really bad syscall multiplexer. ... >> not using the file descriptor it's called on at all, ... It maps back to the inotify device. ...
    (Linux-Kernel)
  • Re: One problem about ioctl during porting from Solaris to Linux
    ... > would be that the very bad idea of supplying the file descriptor as a ... > variable to your ioctl call. ... just needs Linux specific pseudo terminal code. ...
    (comp.os.linux.embedded)
  • Re: fanotify as syscalls
    ... I think these two can be merged into one without adding complexity, ... in the same way that sys_utimensat can take a file descriptor or ... Please don't use an ioctl here. ... int fanotify_ignore_sb(int fanotify_fd, unsigned int flag, ...
    (Linux-Kernel)
  • Re: Writing Linux Device Driver
    ... John wrote: ... pass the relevant data in the ioctl? ... But the answer is "yes - the kernel can do anything". ... Peter ...
    (comp.os.linux.development.system)