[uml-devel] tls: set_thread_area failed

[uml-devel] tls: set_thread_area failed

[Antoine Martin]

I'm still trying to get a regular FC4 image to boot with the latest x86
tls support code. (since Gentoo works fine)
but this is what I get:
# fsck.ext3 -a /dev/ubda
set_thread_area failed when setting up thread-local storage
Segmentation fault

Is this glibc? Any ideas?

Thanks
Antoine



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Blaisorblade]

On Thursday 08 December 2005 03:13, Antoine Martin wrote:
> I'm still trying to get a regular FC4 image to boot with the latest x86
> tls support code.
Mainline kernel or with jdike patchset?
> (since Gentoo works fine) 
> but this is what I get:
> # fsck.ext3 -a /dev/ubda
> set_thread_area failed when setting up thread-local storage
> Segmentation fault

> Is this glibc? Any ideas?

Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread, but it 
seems to do that.

Also, different glibc are more or less happy in using modify_ldt() rather than 
set_thread_area() - it seems that latter is better.

> Thanks
> Antoine

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Antoine Martin]

On Fri, 2005-12-09 at 18:52 +0100, Blaisorblade wrote:
> On Thursday 08 December 2005 03:13, Antoine Martin wrote:
> > I'm still trying to get a regular FC4 image to boot with the latest x86
> > tls support code.
> Mainline kernel or with jdike patchset?
Latest jdike from sf
> > (since Gentoo works fine) 
> > but this is what I get:
> > # fsck.ext3 -a /dev/ubda
> > set_thread_area failed when setting up thread-local storage
> > Segmentation fault
> 
> > Is this glibc? Any ideas?
> 
> Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread, but it 
> seems to do that.
I wasn't even thinking about that! So true, why on earth would fsck
require threading!?

> Also, different glibc are more or less happy in using modify_ldt() rather than 
> set_thread_area() - it seems that latter is better.
Ahh, is it planned or do I have to make heavily modified distro images?

Antoine



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Blaisorblade]

On Friday 09 December 2005 19:39, Antoine Martin wrote:
> On Fri, 2005-12-09 at 18:52 +0100, Blaisorblade wrote:
> > On Thursday 08 December 2005 03:13, Antoine Martin wrote:
> > > I'm still trying to get a regular FC4 image to boot with the latest x86
> > > tls support code.
> >
> > Mainline kernel or with jdike patchset?

> Latest jdike from sf

> > > (since Gentoo works fine)
> > > but this is what I get:
> > > # fsck.ext3 -a /dev/ubda
> > > set_thread_area failed when setting up thread-local storage
> > > Segmentation fault

> > > Is this glibc? Any ideas?

> > Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread,
> > but it seems to do that.

> I wasn't even thinking about that! So true, why on earth would fsck
> require threading!?

> > Also, different glibc are more or less happy in using modify_ldt() rather
> > than set_thread_area() - it seems that latter is better.

> Ahh, is it planned 
What?
> or do I have to make heavily modified distro images? 
I'm not suggesting that...

And, hold on this - Jeff has made a big progress on this, diagnosing what had 
been happening.

I'm not sure how well it works, but in the incrementals page there's the new 
result. Give it a run and tell us the result, if it works it might go in 
2.6.15-bs and 2.6.16.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Antoine Martin]

> > > Also, different glibc are more or less happy in using modify_ldt() rather
> > > than set_thread_area() - it seems that latter is better.
> 
> > Ahh, is it planned 
> What?
I was wondering if this was being worked on, (you answered this below)
> > or do I have to make heavily modified distro images? 
> I'm not suggesting that...
Good!

> And, hold on this - Jeff has made a big progress on this, diagnosing what had 
> been happening.
> 
> I'm not sure how well it works, but in the incrementals page there's the new 
> result. Give it a run and tell us the result, if it works it might go in 
> 2.6.15-bs and 2.6.16.
I've tried these patches:
* there was one suspicious offset on:
patching file arch/um/kernel/skas/process_kern.c
Hunk #1 succeeded at 126 (offset 3 lines).

* CC      arch/um/os-Linux/tls.o
arch/um/os-Linux/tls.c: In function `os_set_thread_area':
arch/um/os-Linux/tls.c:22: error: dereferencing pointer to incomplete
type
arch/um/os-Linux/tls.c: In function `os_get_thread_area':
arch/um/os-Linux/tls.c:36: error: dereferencing pointer to incomplete
type
make[1]: *** [arch/um/os-Linux/tls.o] Error 1
make: *** [arch/um/os-Linux] Error 2

with GCC 3.4.4 and GCC 3.3.4

* another /lib vs lib32 vs lib64 issue with pcap when compiling with
SUBARCH=i386 on this Gentoo system I had to add -r /usr/lib32/libpcap.a:
ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o
arch/um/drivers/pcap_user.o  -m elf_i386
-r /usr/lib32/libpcap.a /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../lib/libpcap.a
Otherwise it moans about linking 64-bit libs with 32-bit... which is
fair enough I guess.

Antoine



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Rob Landley]

On Friday 09 December 2005 12:39, Antoine Martin wrote:

> > > Is this glibc? Any ideas?
> >
> > Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread,
> > but it seems to do that.
>
> I wasn't even thinking about that! So true, why on earth would fsck
> require threading!?

fsck -A does all filesystems in fstab in one run, and the single case 
apparently defaults to one thread.

I didn't say it was a good design... :)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Blaisorblade]

On Sunday 11 December 2005 07:34, Rob Landley wrote:
> On Friday 09 December 2005 12:39, Antoine Martin wrote:
> > > > Is this glibc? Any ideas?
> > >
> > > Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread,
> > > but it seems to do that.
> >
> > I wasn't even thinking about that! So true, why on earth would fsck
> > require threading!?
>
> fsck -A does all filesystems in fstab in one run, and the single case
> apparently defaults to one thread.
>
> I didn't say it was a good design... :)

In fact, I expect a core Unix utility to be grown up in the good old Unix 
school, i.e. fork() and exec()!

We met The One* Unix coder thinking "I like new things!".

* Every reference to "The One Ring" is purely casual and fruit of paranoid 
imagination of the reader. (Yes, you don't know that, but anyhow...)
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] tls: set_thread_area failed

[Nix]

On Sun, 11 Dec 2005, blaisorblade@yahoo.it whispered secretively:
> On Sunday 11 December 2005 07:34, Rob Landley wrote:
>> On Friday 09 December 2005 12:39, Antoine Martin wrote:
>> > I wasn't even thinking about that! So true, why on earth would fsck
>> > require threading!?

It doesn't, at least not as of e2fsprogs-1.38.

>> fsck -A does all filesystems in fstab in one run, and the single case
>> apparently defaults to one thread.
>>
>> I didn't say it was a good design... :)

e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
which invokes execute(), which does a perfectly normal fork()/exec().
No threads here. Nor is there use of aio_*(), which might use threads
(well, POSIX allows it).

> In fact, I expect a core Unix utility to be grown up in the good old Unix 
> school, i.e. fork() and exec()!

It is. :)

> We met The One* Unix coder thinking "I like new things!".

Thankfully, Ted Ts'o is not a Nazgul (despite his close involvement in
the flashy new things of Kerberos and IPSec).

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: tls: set_thread_area failed

[Sven Köhler]

> e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
> which invokes execute(), which does a perfectly normal fork()/exec().
> No threads here. Nor is there use of aio_*(), which might use threads
> (well, POSIX allows it).

Sorry, and what's the conclusion?

fork() calles set_thread_area()?



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: tls: set_thread_area failed

[Blaisorblade]

On Wednesday 14 December 2005 04:05, Sven Köhler wrote:
> > e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
> > which invokes execute(), which does a perfectly normal fork()/exec().
> > No threads here. Nor is there use of aio_*(), which might use threads
> > (well, POSIX allows it).
>
> Sorry, and what's the conclusion?
>
> fork() calles set_thread_area()?

Interesting... yep, it could.

Ok, picture down:

a) in NPTL, getpid() caches the result of the syscall in the TLS - so each new 
process at startup (i.e. after exec!) calls set_thread_area(). But that's 
normal.

b) I know that in clone()*, and I presume that in fork(), the pid cache must 
be invalidated / updated. So while fork() maybe doesn't use set_thread_area 
(and it could, seeing that no TLS setup has been done, and retrying) it wants 
to puzzle with the TLS content.

* We know that as glibc once didn't and UML was the one user of clone() + 
getpid(), and we discovered the hard way that glibc forgot that. Workarounded 
with a real getpid().

At bug report time we got an angry Ulrich saying "it's already fixed in latest 
version", luckily.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel