Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Athol Mullen]

Willy Tarreau <willy@w.ods.org> wrote:
> On Sat, Feb 07, 2004 at 05:00:18PM +1100, Athol Mullen wrote:
(Don't CC.  I read lkml via linux.kernel newsgroup.)

>> After looking through the Intel specs for the ICH5, I discovered that they 
>> specify that the BIOS is supposed to initialise bit flags for the presence 
>> of 80-core ribbon for each drive.

> that could explain why I recently discovered that a 2.4.25-rc1 on a
> supermicro MB with ICH5 was limiting hda and hdb to 30 MB/s at UDMA33 while
> an old 2.4.20 + many patches including IDE gave me about 64 MB/s at UDMA100.

Before I modified eighty_ninty_three(), it returning 0 caused the _indicated_ 
mode to drop to UDMA33.  Check in /proc/ide/piix to see what mode the driver 
tells you.  IIRC (could be wrong), dmesg and hdparm both believe it to be in 
UDMA33 while the init code and /proc/ide/piix both showed it as UDMA5.

I'm starting to wonder if my ICH5 _is_ actually running UDMA5...  It's doing 
21MB/s, which I've been blaming on the old 30G Quantum, whereas the ICH4 with 
a 120G drive is doing 56MB/s...  I think I checked the bit flags in 
/proc/ide/ide0/config and it showed up as UDMA5.

>> I'm not certain exactly how this would be implemented, but I'd like to see 
>> eighty_ninty_three() check for chipset-specific detection code, and use the 
>> existing word93 validation otherwise.

>> I have written and tested code for the intel ICH chipsets, but can't post a 
>> patch until I know where to stick it.  :-)

> well, why not in piix:piix_ratemask() around line 315 ?

I could put it there, but I was actually intending to use it to also return a 
value properly for eighty_ninty_three(), and figured that it would need to be 
a separate routine - I expect that the module structure needs to change, and 
that's where I'm not sure - it could affect _all_ ide drivers.  There might 
be others that have their own specific detection code, and what I'm looking 
to do is establish the framework for that.

Yes, there was a fairly stupid stuff-up on my part in my previous message - my 
business .sig wasn't supposed to get tacked on after my usenet .sig...  It 
_was_ a spam-free email address.  :-(

-- 
Athol
<http://cust.idl.com.au/athol>
Linux Registered User # 254000
I'm a Libran Engineer. I don't argue, I discuss.

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Willy Tarreau]

On Sun, Feb 08, 2004 at 11:45:18AM +1100, Athol Mullen wrote:
> Before I modified eighty_ninty_three(), it returning 0 caused the _indicated_ 
> mode to drop to UDMA33.  Check in /proc/ide/piix to see what mode the driver 
> tells you.  IIRC (could be wrong), dmesg and hdparm both believe it to be in 
> UDMA33 while the init code and /proc/ide/piix both showed it as UDMA5.

I captured dmesg and /proc/ide/piix, but forgot to post them. They're at work
now. But I did the change, by commenting out the call to eighty_ninety_three()
in piix.c, and my disks came back to 54 MB/s each, and 64 MB/s cumulated.
dmesg showed UDMA33 before and now displays UDMA100 again. But I obviously
cannot let it like that because if I install this kernel in a 40-pin machine,
I will get some surprizes !

> I'm starting to wonder if my ICH5 _is_ actually running UDMA5...  It's doing 
> 21MB/s, which I've been blaming on the old 30G Quantum, whereas the ICH4 with 
> a 120G drive is doing 56MB/s...  I think I checked the bit flags in 
> /proc/ide/ide0/config and it showed up as UDMA5.

I'm certain that this one changed before and after the patch, but I cannot
tell you what the differences were.

> >> I'm not certain exactly how this would be implemented, but I'd like to see 
> >> eighty_ninty_three() check for chipset-specific detection code, and use the 
> > well, why not in piix:piix_ratemask() around line 315 ?
> 
> I could put it there, but I was actually intending to use it to also return a 
> value properly for eighty_ninty_three(), and figured that it would need to be 
> a separate routine - I expect that the module structure needs to change, and 
> that's where I'm not sure - it could affect _all_ ide drivers.  There might 
> be others that have their own specific detection code, and what I'm looking 
> to do is establish the framework for that.
 
I understand. But could you please post your ICH5 detection code so that I
can try it on this machine. I still can play with it for a few days before
it gets racked. And I can try with both 40 and 80-pin cables.

> business .sig wasn't supposed to get tacked on after my usenet .sig...  It 
> _was_ a spam-free email address.  :-(

Now the only thing you can do is to count how many days elapse before you
get your first spam...

Regards,
Willy

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Bartlomiej Zolnierkiewicz]

On Sunday 08 of February 2004 08:31, Willy Tarreau wrote:
> On Sun, Feb 08, 2004 at 11:45:18AM +1100, Athol Mullen wrote:
> > Before I modified eighty_ninty_three(), it returning 0 caused the
> > _indicated_ mode to drop to UDMA33.  Check in /proc/ide/piix to see what
> > mode the driver tells you.  IIRC (could be wrong), dmesg and hdparm both
> > believe it to be in UDMA33 while the init code and /proc/ide/piix both
> > showed it as UDMA5.

So host recognizes 80-wires cable correctly, but drive doesn't.
eighty_ninty_three() is for checking _drive_ side.

> I captured dmesg and /proc/ide/piix, but forgot to post them. They're at
> work now. But I did the change, by commenting out the call to
> eighty_ninety_three() in piix.c, and my disks came back to 54 MB/s each,
> and 64 MB/s cumulated. dmesg showed UDMA33 before and now displays UDMA100
> again. But I obviously cannot let it like that because if I install this
> kernel in a 40-pin machine, I will get some surprizes !

This is eighty_ninty_three() in 2.6.x (except #if 0 (...) #endif code):

u8 eighty_ninty_three (ide_drive_t *drive)
{
	return ((u8) ((HWIF(drive)->udma_four) &&
#ifndef CONFIG_IDEDMA_IVB
			(drive->id->hw_config & 0x4000) &&
#endif /* CONFIG_IDEDMA_IVB */
			(drive->id->hw_config & 0x6000)) ? 1 : 0);
#endif
}

Maybe you have accidentally enabled CONFIG_IDEDMA_IVB?
If not please send me copy of /proc/ide/hdX/identify for your drives.

--bart

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Bartlomiej Zolnierkiewicz]

On Tuesday 10 of February 2004 01:10, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 08 of February 2004 08:31, Willy Tarreau wrote:
> > On Sun, Feb 08, 2004 at 11:45:18AM +1100, Athol Mullen wrote:
> > > Before I modified eighty_ninty_three(), it returning 0 caused the
> > > _indicated_ mode to drop to UDMA33.  Check in /proc/ide/piix to see
> > > what mode the driver tells you.  IIRC (could be wrong), dmesg and
> > > hdparm both believe it to be in UDMA33 while the init code and
> > > /proc/ide/piix both showed it as UDMA5.
>
> So host recognizes 80-wires cable correctly, but drive doesn't.
> eighty_ninty_three() is for checking _drive_ side.

It is for both host and drive sides.
I should have read my mail before hitting SEND button. ;-)

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Bartlomiej Zolnierkiewicz]

On Tuesday 10 of February 2004 08:16, Athol Mullen wrote:
> Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> wrote:
> > On Monday 09 of February 2004 03:50, Athol Mullen wrote:
>
> (Don't CC.  I read lkml via linux.kernel newsgroup.)
>
> >> +     u16 cr_flag             = 0x10 << drive->dn;
> >>
> >> +                         pci_read_config_word(dev, 0x54, &reg54);
> >> +                         return ((reg54 & cr_flag) ? 1 : 0);
> >
> > This is plain wrong, piix.c already does it for you.
> > piix.c:init_hwif_piix():
>
> The penny drops...
>
> I missed this code because I was looking for cable detection on
> a drive-by-drive basis, and this is taking drives in pairs.
>
> That's why the drive was being correctly initialised as a UDMA5
> drive even though eighty_ninty_three() was returning zero.
>
> The existing code was written before the ICH5 came out, and will
> always work for ICH4 and older, but is wrong in its method of
> detecting 80-core cables on an ICH5, and could fail if SATA and
> PATA drives are mixed and used in compatability mode.  The bit
> flags should be taken on a drive-by-drive basis, because the ICH5
> is capable of logical mapping such as:
>
> SATA0 -> IDE0 Master
> SATA1 -> IDE0 Slave
> PATA0 master -> IDE1 Master
> PATA1 master -> IDE1 Slave
>
> Note that this now sees two PATA drives on different physical
> interfaces looking like master and slave on one interface.  In this
> scenario, if PATA1 has a 40-core and PATA0 an 80-core or vise versa,
> both would be detected as having 80-core with the existing code.
>
> Why do I feel like I just pulled the lid off a can of worms?

:-)

> The options are essentially that we:
> 1. Always force the SATA interfaces into native mode and PATA
>    into native or normal mode (desirable - the compatability mode
>    described above make only 2 PATA drives visible),
> 2. Modify the above code to work on a drive-by-drive basis instead
>    of interface-by-interface (according to Intel, this is the
>    correct answer),
> 3. Do nothing, and hope nobody notices.  :-)

Solution 1. is good also for other things, but changes order of the drives
so it is 2.7.x thing.  For now you can just add code for ICH5 setting
hwif->udma_four only if both drives report 80-c, something like:

	if ((reg54h & mask) == mask)
		ata66 = 1;

--bart

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Athol Mullen]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> wrote:
> On Monday 09 of February 2004 03:50, Athol Mullen wrote:
(Don't CC.  I read lkml via linux.kernel newsgroup.)

>> +     u16 cr_flag             = 0x10 << drive->dn;

>> +                         pci_read_config_word(dev, 0x54, &reg54);
>> +                         return ((reg54 & cr_flag) ? 1 : 0);

> This is plain wrong, piix.c already does it for you.
> piix.c:init_hwif_piix():

The penny drops...

I missed this code because I was looking for cable detection on
a drive-by-drive basis, and this is taking drives in pairs.

That's why the drive was being correctly initialised as a UDMA5
drive even though eighty_ninty_three() was returning zero.

The existing code was written before the ICH5 came out, and will
always work for ICH4 and older, but is wrong in its method of
detecting 80-core cables on an ICH5, and could fail if SATA and
PATA drives are mixed and used in compatability mode.  The bit
flags should be taken on a drive-by-drive basis, because the ICH5
is capable of logical mapping such as:

SATA0 -> IDE0 Master
SATA1 -> IDE0 Slave
PATA0 master -> IDE1 Master
PATA1 master -> IDE1 Slave

Note that this now sees two PATA drives on different physical
interfaces looking like master and slave on one interface.  In this
scenario, if PATA1 has a 40-core and PATA0 an 80-core or vise versa,
both would be detected as having 80-core with the existing code.

Why do I feel like I just pulled the lid off a can of worms?

The options are essentially that we:
1. Always force the SATA interfaces into native mode and PATA
   into native or normal mode (desirable - the compatability mode
   described above make only 2 PATA drives visible),
2. Modify the above code to work on a drive-by-drive basis instead
   of interface-by-interface (according to Intel, this is the
   correct answer),
3. Do nothing, and hope nobody notices.  :-)

> Please make sure you have CONFIG_IDEDMA_IVB=n in your config.
> If it is okay, please send me a copy of /proc/ide/hdX/identify.

I definately had CONFIG_IDEDMA_IVB=n.

/proc/ide/hda/identify and /proc/ide/hda/model emailed.

(Apologies if messages don't thread properly.)

-- 
Athol
<http://cust.idl.com.au/athol>
Linux Registered User # 254000
I'm a Libran Engineer. I don't argue, I discuss.

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Bartlomiej Zolnierkiewicz]

On Monday 09 of February 2004 03:50, Athol Mullen wrote:
> Willy Tarreau <willy@w.ods.org> wrote:
> > On Sun, Feb 08, 2004 at 11:45:18AM +1100, Athol Mullen wrote:
> >
> > I captured dmesg and /proc/ide/piix, but forgot to post them. They're at
> > work now. But I did the change, by commenting out the call to
> > eighty_ninety_three() in piix.c, and my disks came back to 54 MB/s each,
> > and 64 MB/s cumulated.  dmesg showed UDMA33 before and now displays
> > UDMA100 again. But I obviously cannot let it like that because if I
> > install this kernel in a 40-pin machine, I will get some surprizes !
>
> That's what worries me...
>
> > I understand. But could you please post your ICH5 detection code so that
> > I can try it on this machine. I still can play with it for a few days
> > before it gets racked. And I can try with both 40 and 80-pin cables.
>
> This patch inserts the piix code into eighty_ninty_three() - obviously
> this is for testing purposes only.  The patch was diff'd against 2.4.22,
> but patches okay to 2.6.1 with:
>     Hunk #1 succeeded at 719 (offset -10 lines).
>
> --- ide-iops.c.orig	2004-01-18 15:04:24.000000000 +1100
> +++ ide-iops.c	2004-01-18 16:41:16.000000000 +1100
> @@ -729,6 +729,34 @@
>
>  #else
>
> +#ifdef CONFIG_BLK_DEV_PIIX
> +	/* ICH BIOSes are supposed to set a bit flags for us */
> +
> +	ide_hwif_t *hwif	= HWIF(drive);
> +	struct pci_dev *dev	= hwif->pci_dev;
> +	u16 cr_flag		= 0x10 << drive->dn;
> +	u16			reg54;
> +
> +	if (hwif->pci_dev->vendor == PCI_VENDOR_ID_INTEL) {
> +		switch(hwif->pci_dev->device) {
> +			case PCI_DEVICE_ID_INTEL_82801BA_8:
> +	    		case PCI_DEVICE_ID_INTEL_82801BA_9:
> +	    		case PCI_DEVICE_ID_INTEL_82801CA_10:
> +	    		case PCI_DEVICE_ID_INTEL_82801CA_11:
> +	    		case PCI_DEVICE_ID_INTEL_82801E_11:
> +	    		case PCI_DEVICE_ID_INTEL_82801DB_10:
> +			case PCI_DEVICE_ID_INTEL_82801DB_11:
> +			case PCI_DEVICE_ID_INTEL_82801EB_11:
> +			case PCI_DEVICE_ID_INTEL_82801AA_1:
> +			case PCI_DEVICE_ID_INTEL_82372FB_1:
> +			    {
> +			    pci_read_config_word(dev, 0x54, &reg54);
> +			    return ((reg54 & cr_flag) ? 1 : 0);
> +			    }
> +		}
> +	}
> +#endif /* CONFIG_BLK_DEV_PIIX */
> +

This is plain wrong, piix.c already does it for you.
piix.c:init_hwif_piix():

(...)
	u8 mask = hwif->channel ? 0xc0 : 0x30;
(...)
			pci_read_config_byte(hwif->pci_dev, 0x54, &reg54h);
			pci_read_config_byte(hwif->pci_dev, 0x55, &reg55h);
			ata66 = (reg54h & mask) ? 1 : 0;
(...)
	if (!(hwif->udma_four))
		hwif->udma_four = ata66;

So you could just add:
	return hwif->udma_four;
for testing purposes.

>  	return ((u8) ((HWIF(drive)->udma_four) &&

Therefore this will be true.

>  #ifndef CONFIG_IDEDMA_IVB
>  			(drive->id->hw_config & 0x4000) &&

Here is your problem.

Please make sure you have CONFIG_IDEDMA_IVB=n in your config.
If it is okay, please send me a copy of /proc/ide/hdX/identify.

--bart

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Willy Tarreau]

Hi,

On Mon, Feb 09, 2004 at 02:50:31AM +0000, Athol Mullen wrote:
 
> This patch inserts the piix code into eighty_ninty_three() - obviously
> this is for testing purposes only.  The patch was diff'd against 2.4.22,
> but patches okay to 2.6.1 with:
>     Hunk #1 succeeded at 719 (offset -10 lines).

OK, I will try it ASAP on 2.4.25-rc1.

BTW, are you sure that the trick is needed for all the chipsets below,
or should it be necessary only for some of them ? perhaps word93 is already
OK for a few ones ?

> +		switch(hwif->pci_dev->device) {
> +			case PCI_DEVICE_ID_INTEL_82801BA_8:
> +	    		case PCI_DEVICE_ID_INTEL_82801BA_9:
> +	    		case PCI_DEVICE_ID_INTEL_82801CA_10:
> +	    		case PCI_DEVICE_ID_INTEL_82801CA_11:
> +	    		case PCI_DEVICE_ID_INTEL_82801E_11:
> +	    		case PCI_DEVICE_ID_INTEL_82801DB_10:
> +			case PCI_DEVICE_ID_INTEL_82801DB_11:
> +			case PCI_DEVICE_ID_INTEL_82801EB_11:
> +			case PCI_DEVICE_ID_INTEL_82801AA_1:
> +			case PCI_DEVICE_ID_INTEL_82372FB_1:
> +			    {
> +			    pci_read_config_word(dev, 0x54, &reg54);
> +			    return ((reg54 & cr_flag) ? 1 : 0);
> +			    }
> +		}

Regards,
Willy

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Athol Mullen]

Willy Tarreau <willy@w.ods.org> wrote:
> On Sun, Feb 08, 2004 at 11:45:18AM +1100, Athol Mullen wrote:

> I captured dmesg and /proc/ide/piix, but forgot to post them. They're at
> work now. But I did the change, by commenting out the call to
> eighty_ninety_three() in piix.c, and my disks came back to 54 MB/s each,
> and 64 MB/s cumulated.  dmesg showed UDMA33 before and now displays
> UDMA100 again. But I obviously cannot let it like that because if I
> install this kernel in a 40-pin machine, I will get some surprizes !

That's what worries me...

> I understand. But could you please post your ICH5 detection code so that
> I can try it on this machine. I still can play with it for a few days
> before it gets racked. And I can try with both 40 and 80-pin cables.

This patch inserts the piix code into eighty_ninty_three() - obviously
this is for testing purposes only.  The patch was diff'd against 2.4.22,
but patches okay to 2.6.1 with:
    Hunk #1 succeeded at 719 (offset -10 lines).

--- ide-iops.c.orig	2004-01-18 15:04:24.000000000 +1100
+++ ide-iops.c	2004-01-18 16:41:16.000000000 +1100
@@ -729,6 +729,34 @@
 
 #else
 
+#ifdef CONFIG_BLK_DEV_PIIX
+	/* ICH BIOSes are supposed to set a bit flags for us */
+	
+	ide_hwif_t *hwif	= HWIF(drive);
+	struct pci_dev *dev	= hwif->pci_dev;
+	u16 cr_flag		= 0x10 << drive->dn;
+	u16			reg54;
+
+	if (hwif->pci_dev->vendor == PCI_VENDOR_ID_INTEL) {
+		switch(hwif->pci_dev->device) {
+			case PCI_DEVICE_ID_INTEL_82801BA_8:
+	    		case PCI_DEVICE_ID_INTEL_82801BA_9:
+	    		case PCI_DEVICE_ID_INTEL_82801CA_10:
+	    		case PCI_DEVICE_ID_INTEL_82801CA_11:
+	    		case PCI_DEVICE_ID_INTEL_82801E_11:
+	    		case PCI_DEVICE_ID_INTEL_82801DB_10:
+			case PCI_DEVICE_ID_INTEL_82801DB_11:
+			case PCI_DEVICE_ID_INTEL_82801EB_11:
+			case PCI_DEVICE_ID_INTEL_82801AA_1:
+			case PCI_DEVICE_ID_INTEL_82372FB_1:
+			    {
+			    pci_read_config_word(dev, 0x54, &reg54);
+			    return ((reg54 & cr_flag) ? 1 : 0);
+			    }
+		}
+	}
+#endif /* CONFIG_BLK_DEV_PIIX */
+
 	return ((u8) ((HWIF(drive)->udma_four) &&
 #ifndef CONFIG_IDEDMA_IVB
 			(drive->id->hw_config & 0x4000) &&



(Still fudging via Kmail because tin won't work properly...)

-- 
Athol
<http://cust.idl.com.au/athol>
Linux Registered User # 254000
I'm a Libran Engineer. I don't argue, I discuss.

Re: [RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Willy Tarreau]

On Sat, Feb 07, 2004 at 05:00:18PM +1100, Athol Mullen wrote:
> (Don't CC.  I read lkml via linux.kernel newsgroup.)

(sorry, it was easier to hit 'g' in mutt...)

> Specific to parallel IDE with UDMA.  Relates to code that is the same from 
> 2.4.22 to 2.6.1.
> 
> After looking through the Intel specs for the ICH5, I discovered that they 
> specify that the BIOS is supposed to initialise bit flags for the presence of 
> 80-core ribbon for each drive.  According to Intel, the OS is supposed to 
> rely upon those flags in preference to the word-93 bit.  This appears to 
> cover all ICH chipsets capable of UDMA modes that require 80-core cabling, 
> and works on both the ICH4 and ICH5 I have here.

that could explain why I recently discovered that a 2.4.25-rc1 on a supermicro
MB with ICH5 was limiting hda and hdb to 30 MB/s at UDMA33 while an old 2.4.20
+ many patches including IDE gave me about 64 MB/s at UDMA100.

I can hack piix_ratemask() to test if the limit goes away.

> I'm not certain exactly how this would be implemented, but I'd like to see 
> eighty_ninty_three() check for chipset-specific detection code, and use the 
> existing word93 validation otherwise.
> 
> I have written and tested code for the intel ICH chipsets, but can't post a 
> patch until I know where to stick it.  :-)

well, why not in piix:piix_ratemask() around line 315 ?

Cheers,
Willy

[RFC] IDE 80-core cable detect - chipset-specific code to over-ride eighty_ninty_three()

[Athol Mullen]

(Don't CC.  I read lkml via linux.kernel newsgroup.)

Specific to parallel IDE with UDMA.  Relates to code that is the same from 
2.4.22 to 2.6.1.

After looking through the Intel specs for the ICH5, I discovered that they 
specify that the BIOS is supposed to initialise bit flags for the presence of 
80-core ribbon for each drive.  According to Intel, the OS is supposed to 
rely upon those flags in preference to the word-93 bit.  This appears to 
cover all ICH chipsets capable of UDMA modes that require 80-core cabling, 
and works on both the ICH4 and ICH5 I have here.

I have a drive that fails the word93 bit test with a known 80-core cable. The 
piix driver sets the drive up to UDMA5, but dmesg reports UDMA(33) because 
eighty_ninty_three() returns 0.  If this had really been a 40-core cable, I'm 
not sure what would happen.

Proposal:

I'm not certain exactly how this would be implemented, but I'd like to see 
eighty_ninty_three() check for chipset-specific detection code, and use the 
existing word93 validation otherwise.

I have written and tested code for the intel ICH chipsets, but can't post a 
patch until I know where to stick it.  :-)

Related:

eighty_ninty_three() should only be called if there is a possibility of using 
a mode where it matters.  I intend to submit some patches that rearrange the 
logic to avoid calling it if the best mode doesn't need it.

-- 
Athol
<http://cust.idl.com.au/athol>
Linux Registered User # 254000
I'm a Libran Engineer. I don't argue, I discuss.

-- 
Regards,

Athol
-- 
Athol Mullen
Mullen Automotive Engineering
athol@idl.net.au
24 Newcastle St CARDIFF  NSW 2285
Ph/Fax (02) 4956 8030, Mob. 0414 685537
---
Confidentiality Statement:
Information in this message is provided to the intended recipient in 
confidence and is provided conditional upon its not being made available to 
any other party without the express permission of the author.  Release of any 
part of this message under freedom of information or similar legislation is 
specifically not permitted and if such release is a condition of acceptance, 
the recipient must not accept this message.