GNU bug report logs - #7228
coreutils-8.6 sort-float failure on ppc

Previous Next

Full log

View this message in rfc822 format

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: jim <at> meyering.net (Jim Meyering)
Cc: 7228 <at> debbugs.gnu.org, Gilles Espinasse <g.esp <at> free.fr>
Subject: bug#7228: coreutils-8.6 sort-float failure on ppc
Date: Sat, 16 Oct 2010 18:47:25 -0500 (GMT+5)

Jim Meyering writes:
> 
> Gilles Espinasse wrote:
> > Just tested 8.6 on linux glibc-2.11.1/gcc-4.4.5 LFS build on x86, sparc and
> > ppc
> >
> > First a good news is that on sparc (32-bits), 8.6 test suite is now passing
> > I didn't report yet a failure on misc/stty which was
> > Failure was
> > + stty -icanon
> > stty: standard input: unable to perform all requested operations
> 
> Is that consistently reproducible?
> If so, you might want to investigate, but it's probably not a big deal.

I've seen that error message before, and I did investigate. It was caused by
glibc's tcsetattr()/tcgetattr() being too clever, trying to support fields
that didn't exist in the kernel's termios struct. The kernel struct is
arch-specific so it's not surprising that an arch-specific bug would show up
here.

I've only seen it with speed changes. stty 115200 </dev/ttyS0 makes the
change succesfully, but complains. The kernel termios struct may or may not
have separate speed fields for input and output, but glibc likes to pretend
that they're both there, and somehow stty gets confused by glibc's fakery.
strace doesn't give any clues because it shows the real kernel structures.

See sysdeps/unix/sysv/linux/{speed,tc[gs]etattr}.c in glibc source for the
full ugliness.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.