Questions about task, thread, and tss _struct

Questions about task, thread, and tss _struct

[Donald Dade]

I have a few points of confusion, and I would deeply appreciate any 
clarifications. They concern the three primary structures task_struct, 
thread_struct, and tss_struct. (in kernel 2.4.x)

1) I am having a difficult time understanding how tss_struct could be moved 
out of task_struct (per process basis, as one would expect) to a statically 
allocated array (per CPU basis, ???). How can these registers be saved 
across context switches, when there are only as many such structures as 
there are CPUs? I did not follow the explanation in UTLK.

2) Why the multiple stack pointers and stack segments in tss_struct?

3) What is esp0 in thread_struct?

4) What are the members suffixed with 'h' in tss_struct? I thought they were 
the segment shadow registers until I saw the member __ldth, because I didn't 
believe that ldt had a shadow register.

5) Is there a particular reason for the double underscore convention 
prefixing certain members?

Thank you so much for the clarifications that I've received in the past, and 
no doubt this one also,

Don Dade

>From: Vojtech Pavlik <vojtech@suse.cz>
>To: Greg Ward <gward@python.net>
>CC: bugs@linux-ide.org, linux-kernel@vger.kernel.org
>Subject: Re: "hde: timeout waiting for DMA": message gone, same behaviour
>Date: Fri, 21 Sep 2001 20:53:56 +0200
>
>On Fri, Sep 21, 2001 at 01:44:02PM -0400, Greg Ward wrote:
> > Having problems with an ATA/100 drive under Linux 2.4.{2,9}.
> >
> > drive: Seagate Barracuda IV 80 GB (ST380021A)
> > motherboard: ASUS A7V (VIA Apollo KT133 chipset)
> > ide0, ide1: VIA VT82C686A
> > ide2, ide3: Promise PDC20265 (these are the ATA/100 interfaces)
> >   (all four IDE interfaces are right on the motherboard)
> >
> > I have tried connecting the drive to both ide0 and ide2, with both a
> > 40-conductor and 80-conductor cable.
> >
> > Under 2.4.2, there was a very lengthy delay at boot time with this
> > output:
> >   Partition check:
> >    hda:hda: timeout waiting for DMA
> >   ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> >   hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> >   [...repeat 2 times...]
> >   hda: DMA disabled
> >   ide0: reset: success
> >    hda1
> >
> > Eventually the system booted, but the drive was really slow (no DMA).
> > When I forced DMA on ("hdparm -d1 /dev/hda"), I got the same lengthy
> > sequence of output as I had at boot time, and eventually the kernel
> > turned DMA off again.
> >
> > So far nothing new -- from the linux-kernel archive, I'm not the first
> > person to report this problem in early 2.4 kernels.
> >
> > Under 2.4.9, the boot-time delay is not quite as long, but it's still
> > there.  And it's not nearly as noisy.  However, the end-result is the
> > same: DMA is disabled for this drive; it's a lot slower than an ATA/100
> > drive ought to be; if I force DMA back on, the first access to the drive
> > has another looong delay that results in the kernel turning DMA back
> > off.  Grumble.
> >
> > This is a brand-new drive and brand-new cable.  The motherboard's only
> > about 9 months old.
> >
> > So: is this in fact a kernel problem? or is it more likely to be a cable
> > problem, a motherboard problem, or a hard drive problem?
>
>Do you have the VIA IDE support enabled?
>
>--
>Vojtech Pavlik
>SuSE Labs
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: Questions about task, thread, and tss _struct

[Brian Gerst]

Donald Dade wrote:
> 
> I have a few points of confusion, and I would deeply appreciate any
> clarifications. They concern the three primary structures task_struct,
> thread_struct, and tss_struct. (in kernel 2.4.x)

task_struct contains architecture independant process information.
thread_struct contains architecture dependant process information.
tss_struct is x86-specific, defined by the hardware.

> 1) I am having a difficult time understanding how tss_struct could be moved
> out of task_struct (per process basis, as one would expect) to a statically
> allocated array (per CPU basis, ???). How can these registers be saved
> across context switches, when there are only as many such structures as
> there are CPUs? I did not follow the explanation in UTLK.

The TSS (Task State Segment) structure is defined by the processor for
hardware task switching.  Earlier versions of Linux on the x86 used one
TSS for each process and used hardware task switching.  This effectively
limited the number of processes to about 500.  We now have one TSS per
cpu, and do software task switching.

> 2) Why the multiple stack pointers and stack segments in tss_struct?

The x86 architecture has 4 priviledge levels (aka rings), with Linux
only using ring 3 (user) and ring 0 (kernel).  When moving to a higher
privilege level (smaller numerically), a new stack pointer is loaded
fron the corresponding pointer in the TSS.

> 3) What is esp0 in thread_struct?

The kernel stack pointer for the current process.  This is copied into
tss->esp0 when the process becomes current on a cpu.

> 4) What are the members suffixed with 'h' in tss_struct? I thought they were
> the segment shadow registers until I saw the member __ldth, because I didn't
> believe that ldt had a shadow register.

Segment registers are only 16 bits.  the __*h values are the high 16
bits that are filler.

> 5) Is there a particular reason for the double underscore convention
> prefixing certain members?

To avoid any namespace collisions.

I suggest that you read the Intel documentation:
http://developer.intel.com/design/pentium4/manuals/245472.htm
In particular Chapter 6 Task Management

--

				Brian Gerst