[9fans] struct problems

[9fans] struct problems

[Christopher Nielsen]

I've been working on 48-bit LBA support for ATA, and
I've run into something peculiar. I decided to rewrite
the identify array as a struct of bit fields for better
readability. As it turns out, the struct is 16 bytes
bigger than expected, which is causing all sorts of
trouble with accessing the fields properly. I am pretty
sure I copied all the fields correctly; the struct
should be 512 bytes, but it's 528 bytes. Below is the
struct definition for folks to look at. I am in the
process of rooting out where the extra bytes are
coming from, but if someone can provide some insight,
it would save me some time.


typedef struct Params {
/*000*/	union {
		ushort	config;
		ushort	pktsz:2;	/* packet command size */
		ushort	incomplete:1;
		ushort	:2;
		ushort	drq:2;	/* DRQ type */
		ushort	removable:1;	/* device is removable */
    		ushort	type:5;	/* device type */
    		ushort	:2;
    		ushort	proto:1;	/* command protocol */
	};
/*001*/	ushort	lcyl;	/* logical cylinders */
	ushort	reserved2;
/*003*/	ushort	lhead;	/* logical heads */
	ushort	obsolete4;
	ushort	obsolete5;
/*006*/	ushort	lsec;	/* logical sectors */
	ushort	reserved7;
	ushort	reserved8;
	ushort	retired9;
/*010*/	uchar	serial[20];	/* serial number */
	ushort	retired20;
	ushort	retired21;
	ushort	obsolete22;
/*023*/	uchar	firmware[8];	/* firmware revision */
/*027*/	uchar	model[40];	/* model name */
/*047*/	ushort	maxrwm:8;	/* max. read/write multiple sectors */
	ushort	:8;
	ushort	reserved48;
/*049*/	union {
		ushort	capabilities;
		ushort	retired49:8;
		ushort	dma:1;	/* DMA supported */
		ushort	lba:1;	/* LBA supported */
		ushort	noiordy:1;	/* IORDY may be disabled */
		ushort	iordy:1;	/* IORDY supported */
		ushort	softrst:1;	/* needs soft reset when bsy */
		ushort	stdby:1;	/* standby supported */
		ushort	queueing:1;	/* queueing overlap supported */
		ushort	idma:1;	/* interleaved DMA supported */
	};
/*050*/	ushort	stdbymin:1;
	ushort	:13;
	ushort	cap1:1;
	ushort	cap0:1;
	ushort	retired51;
	ushort	retired52;
/*053*/	ushort	valid;
/*054*/	ushort	ccyl;
/*055*/	ushort	chead;
/*056*/	ushort	csec;
/*057*/	ushort	cap;
	ushort	obsolete58;
/*059*/	ushort	mstc:8;	/* number of sectors ready for transfer */
	ushort	mstvalid:1;	/* multi-sector transfer enabled */
	ushort	:7;
/*060-061*/	ushort	lba0;	/* LBA size */
	ushort	lba1;	/* LBA size */
	ushort	obsolete62;
/*063*/	ushort	mwdma;	/* multiword DMA mode */
/*064*/	ushort	apio;	/* advanced PIO mode */
/*065*/	ushort	minmwdma;	/* min. multiword DMA cycle time */
/*066*/	ushort	recmwdma;	/* rec. multiword DMA cycle time */
/*067*/	ushort	minpio;	/* min. PIO cycle w/o flow control */
/*068*/	ushort	miniordy;	/* min. PIO cycle with IORDY */
	ushort	reserved69;
	ushort	reserved70;
/*071*/	ushort	pktbr;	/* time from PACKET to bus release */
/*072*/	ushort	svcbsy;	/* time for SERVICE to !bsy */
	ushort	reserved73;
	ushort	reserved74;
/*075*/	ushort	qdepth:5;	/* max. queue depth */
	ushort	:11;
	ushort	reserved76;
	ushort	reserved77;
	ushort	reserved78;
	ushort	reserved79;
/*080*/	ushort	major;	/* major version number */
/*081*/	ushort	minor;	/* minor version number */
/*082-084/085-087*/	struct {
		ushort	smart:1;
		ushort	security:1;
		ushort	removable:1;
		ushort	pwrmgmt:1;
		ushort	pkt:1;
		ushort	wcache:1;
		ushort	lookahead:1;
		ushort	relirq:1;
		ushort	svcirq:1;
		ushort	reset:1;
		ushort	protected:1;
		ushort	:1;
		ushort	wbuf:1;
		ushort	rbuf:1;
		ushort	nop:1;
		ushort	:1;

		ushort	microcode:1;
		ushort	queued:1;
		ushort	cfa:1;
		ushort	apm:1;
		ushort	notify:1;
		ushort	standby:1;
		ushort	spinup:1;
		ushort	:1;
		ushort	maxsec:1;
		ushort	autoacoustic:1;
		ushort	addr48:1;
		ushort	devconfov:1;
		ushort	flush:1;
		ushort	flush48:1;
		ushort	support1:1;
		ushort	support0:1;

		ushort	smarterror:1;
		ushort	smartselftest:1;
		ushort	mserial:1;
		ushort	mpassthrough:1;
		ushort	:1;
		ushort	logging:1;
		ushort	:8;
		ushort	supportext1:1;
		ushort	supportext0:1;
	} supported, enabled;
/*088*/	ushort	udma;	/* ultra DMA mode */
/*089*/	ushort	erase;	/* time for security erase */
/*090*/	ushort	eerase;	/* time for enhanced security erase */
/*091*/	ushort	power;	/* current advanced power management */
/*092*/	ushort	mpwrev;	/* master password revision */
/*093*/	ushort	hwres;	/* hardware config test results */
/*094*/	ushort	acoustic;	/* current automatic acoustic management */
	ushort	reserved95;
	ushort	reserved96;
	ushort	reserved97;
	ushort	reserved98;
	ushort	reserved99;
/* 100-103 */	ushort	lbaext0;	/* 48-bit LBA size */
	ushort	lbaext1;	/* 48-bit LBA size */
	ushort	lbaext2;	/* 48-bit LBA size */
	ushort	lbaext3;	/* 48-bit LBA size */
	ushort	reserved104[23];
/*127*/	ushort	remstat;	/* removable media status */
/*128*/	ushort	secstat;	/* security status */
	ushort	reserved129[31];
/*160*/	ushort	cfapwr;	/* CFA power mode */
	ushort	reserved161[14];
/*176*/	ushort	mediaserial[30];	/* current media serial number */
	ushort	reserved206[49];
/*255*/	ushort	chksum;
} Params;


--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] struct problems

[Christopher Nielsen]

I forgot to add that my guess as to what is happening
is due to alignment issues.

On Tue, May 06, 2003 at 09:36:33PM -0700, Christopher Nielsen wrote:
> I've been working on 48-bit LBA support for ATA, and
> I've run into something peculiar. I decided to rewrite
> the identify array as a struct of bit fields for better
> readability. As it turns out, the struct is 16 bytes
> bigger than expected, which is causing all sorts of
> trouble with accessing the fields properly. I am pretty
> sure I copied all the fields correctly; the struct
> should be 512 bytes, but it's 528 bytes. Below is the
> struct definition for folks to look at. I am in the
> process of rooting out where the extra bytes are
> coming from, but if someone can provide some insight,
> it would save me some time.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

RE: [9fans] struct problems

[Nigel Roles]

structs and unions are aligned on 4 byte boundaries.
bit fields are never portable. are you sure they will
work on any Plan 9 platform (not just x86)?

> -----Original Message-----
> From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
> Of Christopher Nielsen
> Sent: 07 May 2003 06:34
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] struct problems
>
>
> I forgot to add that my guess as to what is happening
> is due to alignment issues.
>
> On Tue, May 06, 2003 at 09:36:33PM -0700, Christopher Nielsen wrote:
> > I've been working on 48-bit LBA support for ATA, and
> > I've run into something peculiar. I decided to rewrite
> > the identify array as a struct of bit fields for better
> > readability. As it turns out, the struct is 16 bytes
> > bigger than expected, which is causing all sorts of
> > trouble with accessing the fields properly. I am pretty
> > sure I copied all the fields correctly; the struct
> > should be 512 bytes, but it's 528 bytes. Below is the
> > struct definition for folks to look at. I am in the
> > process of rooting out where the extra bytes are
> > coming from, but if someone can provide some insight,
> > it would save me some time.
>
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] struct problems

[Christopher Nielsen]

Doh! I should know that bit fields aren't portable.
No, I'm not sure; in fact, I'm pretty sure they won't
work across platforms. I didn't think about that. I'll
come up with a different method that _is_ portable.
Thanks.

On Wed, May 07, 2003 at 06:36:51AM +0100, Nigel Roles wrote:
> structs and unions are aligned on 4 byte boundaries.
> bit fields are never portable. are you sure they will
> work on any Plan 9 platform (not just x86)?

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] struct problems

[northern snowfall]

Structures are aligned to the underlying platform's
specifications which may cause problems if you
expect raw data to align to your C structure bit-
for-bit: it won't happen. IIRC, this is the reason
why plan9 code uses the convX2Y() functions,
making sure data represented in a struct is
represented properly by the underlying architecture.
Some people go the B route and use uchar[] for
every structure member, which causes more CPU
cycles later when analyzing data. In my experience
it's just better to parse the raw data into the specific
structure using a conversion routine, possibly
inlined. Bitfields will only augment this issue in
your code and decrease portability.
Don

Re: [9fans] struct problems

[Bruce Ellis]

what other justification for #pragma hjdicks
can you think of?

----- Original Message -----
From: "northern snowfall" <dbailey27@ameritech.net>
To: <9fans@cse.psu.edu>
Sent: Wednesday, May 07, 2003 5:32 PM
Subject: Re: [9fans] struct problems


> Structures are aligned to the underlying platform's
> specifications which may cause problems if you

Re: [9fans] struct problems

[Bruce Ellis]

pragmatism and a silly discussion over dinner.
hj were dicks for assuming that they could
lay out structs in an architecture independant way.
we had to live with it.

----- Original Message -----
From: "northern snowfall" <dbailey27@ameritech.net>
To: <9fans@cse.psu.edu>
Sent: Wednesday, May 07, 2003 11:06 PM
Subject: Re: [9fans] struct problems

> Bruce Ellis wrote:
>
> >what other justification for #pragma hjdicks
> >can you think of?
> >
> Extreme intoxication?

Re: [9fans] struct problems

[northern snowfall]

Bruce Ellis wrote:

>what other justification for #pragma hjdicks
>can you think of?
>
Extreme intoxication?

>

Re: [9fans] struct problems

[northern snowfall]

Bruce Ellis wrote:

>pragmatism and a silly discussion over dinner.
>hj were dicks for assuming that they could
>lay out structs in an architecture independant way.
>we had to live with it.
>
Hey, I never said I *liked* the idea... :) but, thats how
it is...

>

[9fans] acme/sam problem

[ron minnich]

another newbie question:

cpu% src date
B: can't find sam server file
cpu%

What should I start looking for to find out what's up?

Also, on drawterm, I am getting rio and acme windows with text which is
not visible. I can type, cursor moves, you just don't see anything. Is
there some place I should start looking for why this is happening?

thanks

ron

Re: [9fans] acme/sam problem

[Russ Cox]

You're not running a plumber, so src falls
back on trying to find an instance of sam
posted in /srv.  Start a plumber before you
start rio.  Presumably this is in a drawterm
session.

Re: [9fans] acme/sam problem

[andrey mirtchovski]

> Also, on drawterm, I am getting rio and acme windows with text which is
> not visible. I can type, cursor moves, you just don't see anything. Is
> there some place I should start looking for why this is happening?
>

I know now! This is the same laptop I had (and reported exactly the same
issue some time ago). Now that you have it you're experiencing the same
problem. The difference now is that you're running RedHat (I had FreeBSD
installed) and drawterm-linux (I had drawterm-freebsd).. What's the same
is XFree86 and the video hardware -- S3.

I believe it was assumed to be a race in XFillRectangle somewhere...

So we blame XF86 and S3 for it -- I haven't had any problems running
drawterm with either Radeon 7500 or NVidia TNT2...

andrey

Re: [9fans] acme/sam problem

[ron minnich]

On Wed, 7 May 2003, Russ Cox wrote:

> You're not running a plumber, so src falls
> back on trying to find an instance of sam
> posted in /srv.  Start a plumber before you
> start rio.  Presumably this is in a drawterm
> session.


yes, silly of me to even ask that, I just had to do a ps and notice ... no
plumber. arg.

ron

[9fans] snapshots -> archives

[rog]

i'm using venti on my laptop and haven't done snap -a very often (it
needs to be done manually if the machine's not on all the time).

i do however have lots of snapshots taken over the last month or so.

question: is it possible to convert some of these snapshots to entries
in archive.  it would mean that i wouldn't lose all that history,
which currently i will.

the only other alternative that i can see is to vac the snapshots and
store the scores somewhere, but that wouldn't give nearly such a
seamless result.

if there's no current way to do it, is there some fundamental reason
why i won't be able to hack fossil to be able to do it?

  cheers,
    rog.

Re: [9fans] snapshots -> archives

[Russ Cox]

> i'm using venti on my laptop and haven't done snap -a very often (it
> needs to be done manually if the machine's not on all the time).
>
> i do however have lots of snapshots taken over the last month or so.
>
> question: is it possible to convert some of these snapshots to entries
> in archive.  it would mean that i wouldn't lose all that history,
> which currently i will.
>
> the only other alternative that i can see is to vac the snapshots and
> store the scores somewhere, but that wouldn't give nearly such a
> seamless result.
>
> if there's no current way to do it, is there some fundamental reason
> why i won't be able to hack fossil to be able to do it?

there's no current way to do it.  it should be easy enough.
you need to move the snapshots into the /archive tree
(some coding required) and then just run snap -a.

Re: [9fans] struct problems

[boyd, rounin]

Christopher Nielsen" <cnielsen@pobox.com>
> Doh! I should know that bit fields aren't portable.

it's worse than that, a 32 bit int access on a 16 bit device register _may_
get 'optimised' into an 'extract field' instruction which then causes a kernel
mode fault.  iirc the 8th Ed TU16 driver ... 750/780 porting issue.
--
The Beretta 92FS -- don't leave home without it ...

Re: [9fans] struct problems

[ron minnich]

On Thu, 8 May 2003, boyd, rounin wrote:

> it's worse than that, a 32 bit int access on a 16 bit device register _may_
> get 'optimised' into an 'extract field' instruction which then causes a kernel
> mode fault.  iirc the 8th Ed TU16 driver ... 750/780 porting issue.

yes, the whole bitfield thing is a total botch when it cames to real
hardware. Truly bad things happen.

ron

Re: [9fans] struct problems

[Geoff Collyer]

These two are from memory, since grep hasn't turned up the sources
(it's time to fully index all my files, I guess) and neither one is in
the fortunes file:

	Bit-fields are a botch and a blemish. - Dennis Ritchie
		(possibly from a Usenix conference)

	Only children and idiots use bit-fields. - Rob Pike

Re: [9fans] struct problems

[Scott Schwartz]

| These two are from memory, since grep hasn't turned up the sources
| (it's time to fully index all my files, I guess) and neither one is in
| the fortunes file:

The best one was something like:
	I'll use bit-fields before I use Plan 9!  - Brian Kernighan

Re: [9fans] struct problems

[boyd, rounin]

From: "ron minnich" <rminnich@lanl.gov>
> yes, the whole bitfield thing is a total botch when it cames to real
> hardware. Truly bad things happen.

they did; john mackin & i fixed 'em [sending the fixes to 1127] -- ugly ...

extract field instructions just didn't work on the 780's 16 bit UBA device
registers.

don't even get me started on the 'bitmap of free/used ram' on 32V ...

bonus points: what (and how much) did the 780 set to zero on boot?

Re: [9fans] struct problems

[boyd, rounin]

From: "northern snowfall" <dbailey27@ameritech.net>
> 1127. thats too weird.

11271

Re: [9fans] struct problems

[northern snowfall]

>
>
>they did; john mackin & i fixed 'em [sending the fixes to 1127] -- ugly ...
>
1127. thats too weird.

Re: [9fans] struct problems

[Douglas A. Gwyn]

ron minnich wrote:
> yes, the whole bitfield thing is a total botch when it cames to real
> hardware. Truly bad things happen.

Bad things sometimes happen even with access of memory-
mapped device registers via ordinary integer types.

Re: [9fans] struct problems

[boyd, rounin]

> Bad things sometimes happen even with access of memory-
> mapped device registers via ordinary integer types.

'780 extract field on a 16 bit UBA device register ....