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

Previous Next

Full log

View this message in rfc822 format

From: Jim Meyering <jim <at> meyering.net>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
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: Sun, 17 Oct 2010 09:20:44 +0200

Alan Curry wrote:
> 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.

Thanks for the explanation.

Previous Next

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