headers
Carlos O'Donell | 17 Nov 02:31

64-bit long double support.

The HP-PARISC processor has no 128-bit hardware floating point
support. In HPUX the 128-bit long double support is all in software.
After years of trying we have come to the conclusion that the HPUX
128-bit long double support will never be released into the public.

It was the conclusion of the community that we would use 64-bit long
double, a type which would be identical to double.

The goal is to get `long double' fixed for hppa-linux. You might ask
what is broken?

1. GCC at one point assumed `long double' was 96-bits (fixed, 64-bits)
2. GLIBC at one point asumed `long double' was 128-bits (fixed, 64-bits)
3. GLIBC headers do not export `xxxxl' (long double) variants of the
math functions.
     = The fix is to undef __NO_LONG_DOUBLE_MATH in your own version
of mathdefs.h
4. GLIBC doesn't test `long double' support.
     = Hack up math/Makefile to have a finer control over building and
testing long doubles.

I have patches for 3, and 4. The patch for 3 will "turn on" 64-bit
`long double' math functions in our headers. The patch for 4 will
reveal that "lrintl" and "lroundl" are probably broken in some
rounding cases.

There was mention of using gcc to support "double double" and use 2x
64-bit doubles. Unfortunately I think this road would be paved with
lots of debugging, a new ABI, and more headaches for little reward.
Remember our goal "fix long double support."
(Continue reading)

Permalink | Reply | 0 comments |
headers
John David Anglin | 17 Nov 02:48
Picon

Re: 64-bit long double support.

> Is there any opposition to checking in the fix for 3?
> Speak now or forever hold your peace.

Do it before I change my mind...

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
Adrian Bunk | 21 Nov 21:34
Picon
Favicon

[2.6 patch] parisc: "extern inline" -> "static inline"

"extern inline" generates a warning with -Wmissing-prototypes and I'm 
currently working on getting the kernel cleaned up for adding this to 
the CFLAGS since it will help us to avoid a nasty class of runtime 
errors.

If there are places that really need a forced inline, __always_inline 
would be the correct solution.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
Acked-by: Kyle McMartin <kyle <at> parisc-linux.org>

---

This patch was already sent on:
- 19 Aug 2006

 arch/parisc/lib/memcpy.c       |    4 +--
 include/asm-parisc/io.h        |    2 -
 include/asm-parisc/pci.h       |    2 -
 include/asm-parisc/pgtable.h   |   40 ++++++++++++++++-----------------
 include/asm-parisc/prefetch.h  |    4 +--
 include/asm-parisc/semaphore.h |   10 ++++----
 include/asm-parisc/tlbflush.h  |    3 --
 7 files changed, 32 insertions(+), 33 deletions(-)

--- linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c.old	2005-10-30 01:58:43.000000000 +0200
+++ linux-2.6.14-rc5-mm1-full/arch/parisc/lib/memcpy.c	2005-10-30 01:59:11.000000000 +0200
@@ -158,12 +158,12 @@
 #define stw(_s,_t,_o,_a,_e) 	def_store_insn(stw,"r",_s,_t,_o,_a,_e)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian Bunk | 21 Nov 21:37
Picon
Favicon

[2.6 patch] arch/parisc/Makefile: remove GCC_VERSION

This patch removes the usage of GCC_VERSION from arch/parisc/Makefile.

There are no functional changes, it simply makes it a bit shorter (and 
removes the last instance of GCC_VERSION in the kernel).

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>
Acked-by: Kyle McMartin <kyle <at> mcmartin.ca>

---

This patch was already sent on:
- 19 Aug 2006
- 12 Jan 2006

--- linux-2.6.15-mm3-hppa/arch/parisc/Makefile.old	2006-01-12 03:11:45.000000000 +0100
+++ linux-2.6.15-mm3-hppa/arch/parisc/Makefile	2006-01-12 03:12:35.000000000 +0100
@@ -35,12 +35,8 @@

 OBJCOPY_FLAGS =-O binary -R .note -R .comment -S

-GCC_VERSION     := $(call cc-version)
-ifneq ($(shell if [ -z $(GCC_VERSION) ] ; then echo "bad"; fi ;),)
-$(error Sorry, couldn't find ($(cc-version)).)
-endif
-ifneq ($(shell if [ $(GCC_VERSION) -lt 0303 ] ; then echo "bad"; fi ;),)
-$(error Sorry, your compiler is too old ($(GCC_VERSION)).  GCC v3.3 or above is required.)
+ifneq ($(shell if [ $(call cc-version) -lt 0303 ] ; then echo "bad"; fi ;),)
+$(error Sorry, your compiler is too old.  GCC v3.3 or above is required.)
 endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivory Chisholm | 29 Nov 21:25

Re: hi

to clear my head. 
_______________________________________________
parisc-linux mailing list
parisc-linux <at> lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Permalink | Reply | 0 comments |
headers
Guy Martin | 30 Nov 10:18
Picon
Gravatar

Re: K410 SCSI 53c700 issue with PLEXTOR PX-R820T


Hi Matthew,

I've been doing some more troubleshooting to find out what was going wrong.

I've found out that the SCSI driver detects a phase mismatch for READ_CAPACITY and READ_TOC as it should.
But the main difference between the working driver and the non working one is the fact that it doesn't handle
this mismatch as an expected one.

Working READ_TOC command :

[42949512.830000] 53c700: scsi2, command sr 2:0:2:0: 
[42949512.890000]         command: cdb[0]=0x43: 43 00 00 00 00 00 00 00 0c 40
[42949512.970000]  scatter block 0: move 12[0900000c] from 0xf38e00
[42949513.040000]  SETTING 001c0528 to 90080000
[42949513.090000]  script, patching short field MessageCount at 30 to 0xe000001
[42949513.180000]  script, patching ID field Device_ID at 0 to 0x41040000
[42949513.250000]  script, patching CommandAddress at 121 to 0xf407a4
[42949513.330000]  script, patching short field CommandCount at 120 to 0xa00000a
[42949513.410000]  script, patching SGScriptStartAddress at 191 to 0x1c0520
[42949513.490000]  script, patching SGScriptStartAddress at 207 to 0x1c0520
[42949513.570000] scsi2: istat 01 sstat0 00 dstat 84 dsp 012a[001c04a8] dsps 0x401
[42949513.570000] scsi2: (2:0) ====>SCRIPT INTERRUPT<====
[42949513.570000]   COMMAND COMPLETE, status=02
[42949513.570000]  script, patching short field MessageCount at 30 to 0xe000006
[42949513.570000]  script, patching ID field Device_ID at 0 to 0x41040000
[42949513.570000]  script, patching CommandAddress at 121 to 0xf407a4
[42949513.570000]  script, patching short field CommandCount at 120 to 0xa000006
[42949513.570000]  script, patching SGScriptStartAddress at 191 to 0x1c0520
[42949513.570000]  script, patching SGScriptStartAddress at 207 to 0x1c0520
[42949513.570000] scsi2: Issuing saved command slot 4fd40520, cmd 4f995760      
[42949514.350000] scsi2: istat 09 sstat0 00 dstat 84 dsp 00ba[001c02e8] dsps 0x250
[42949514.350000] scsi2: (2:0) ====>SCRIPT INTERRUPT<====
[42949514.350000] scsi2 (2:0): message before command phase: 01 03 01 3b 08 
[42949514.350000] Attempting to resume at 1c02e8
[42949514.630000] scsi2: istat 0a sstat0 c0 dstat 00 dsp 014a[001c0528] dsps 0xf48808
[42949514.630000] scsi2: (2:0) Expected phase mismatch in slot->SG[1], transferred 0x4e
[42949514.630000] sr 2:0:2:0: 
[42949514.630000]         command: cdb[0]=0x3: 03 00 00 00 60 00
[42949514.630000] DATA TRANSFER MISMATCH, count = 96, transferred 18
[42949514.630000] Attempting to resume at 1c0218
[42949515.040000] scsi2: istat 01 sstat0 00 dstat 84 dsp 012a[001c04a8] dsps 0x401
[42949515.040000] scsi2: (2:0) ====>SCRIPT INTERRUPT<====
[42949515.040000]   COMMAND COMPLETE, status=00
[42949515.040000]  ORIGINAL CMD 4f995760 RETURNED 2, new return is 0 sense is
[42949515.040000] 53c700: Current: sense key=0x2
[42949515.040000]     ASC=0x3a ASCQ=0x0

Broken READ_TOC command :

[42949427.280000] 53c700: scsi2, command sr 2:0:2:0: 
[42949427.280000]         command: cdb[0]=0x43: 43 00 00 00 00 00 00 00 0c 40
[42949427.280000]  scatter block 0: move 12[0900000c] from 0x1d48e00
[42949427.280000]  SETTING 001c0528 to 90080000
[42949427.280000]  script, patching short field MessageCount at 30 to 0xe000001
[42949427.280000]  script, patching ID field Device_ID at 0 to 0x41040000
[42949427.280000]  script, patching CommandAddress at 121 to 0x1d508f8
[42949427.280000]  script, patching short field CommandCount at 120 to 0xa00000a
[42949427.280000]  script, patching SGScriptStartAddress at 191 to 0x1c0520
[42949427.280000]  script, patching SGScriptStartAddress at 207 to 0x1c0520
[42949427.290000] scsi2: istat 01 sstat0 00 dstat 84 dsp 012a[001c04a8] dsps 0x401
[42949427.290000] scsi2: (2:0) ====>SCRIPT INTERRUPT<====
[42949427.290000]   COMMAND COMPLETE, status=02
[42949427.290000]  script, patching short field MessageCount at 30 to 0xe000006
[42949427.290000]  script, patching ID field Device_ID at 0 to 0x41040000
[42949427.290000]  script, patching CommandAddress at 121 to 0x1d58c20
[42949427.290000]  script, patching short field CommandCount at 120 to 0xa00000a
[42949427.290000]  script, patching SGScriptStartAddress at 191 to 0x1c0520
[42949427.290000]  script, patching SGScriptStartAddress at 207 to 0x1c0520
[42949427.290000] scsi2: Issuing saved command slot 4f6b8520, cmd 4f23b8c0      
[42949427.300000] scsi2: istat 09 sstat0 00 dstat 84 dsp 00ba[001c02e8] dsps 0x250
[42949427.300000] scsi2: (2:0) ====>SCRIPT INTERRUPT<====
[42949427.300000] scsi2 (2:0): message before command phase: 01 03 01 3b 08 
[42949427.300000] Attempting to resume at 1c02e8
[42949427.320000] scsi2: istat 0a sstat0 c0 dstat 00 dsp 007a[001c01e8] dsps 0x1d58c20
[42949427.320000] scsi2: (2:0) phase mismatch at 01e8, phase IO BSY DATA_IN
[42949427.330000] scsi2: istat 02 sstat0 06 dstat 00 dsp 007a[001c01e8] dsps 0x1d58c20
[42949427.330000] scsi2: Bus Reset detected, executing command 4f23b8c0, slot 4f6b8520, dsp 001c01e8[01e8]
[42949427.330000]  failing command because of reset, slot 4f6b8520, cmnd 4f23b8c0
[42949427.330000] 53c700: sync 1 async 2
[42949427.340000] sr0: Hmm, seems the drive doesn't support multisession CD's

As far as I can see in the source code, those two lines decide if the phase mismatch is expected or not :
                        } else if(dsp >= to32bit(&slot->pSG[0].ins) &&
                                  dsp <= to32bit(&slot->pSG[NCR_700_SG_SEGMENTS].ins)) {

This part of the code is really cryptic to me. If you have some doc or explaination for me, I'll be glad to
continue to troubleshoot this.

The working verbose dmesg can be found here :
https://www.tuxicoman.be/temp/dmesg-2.6.17-53c700-verbose

And the non working one here :
https://www.tuxicoman.be/temp/dmesg-2.6.18-53c700-verbose

Regards,
  Guy

On Mon, 27 Nov 2006 08:37:14 -0700
Matthew Wilcox <matthew <at> wil.cx> wrote:

> On Mon, Nov 27, 2006 at 11:58:32AM +0100, Guy Martin wrote:
> > Some more detail on this issue.
> > This burner still works at commit 6391a11375de5e2bb1eb8481e54619761dc65d9f but breaks at commit 0f13fc09db68de92585558984bff1c51b87db72f.
> 
> Thanks for narrowing it down so much!
> 
> > commit 0f13fc09db68de92585558984bff1c51b87db72f
> > Author: James Bottomley <James.Bottomley <at> steeleye.com>
> > Date:   Thu Jun 29 13:02:11 2006 -0400
> > 
> >     [SCSI] 53c700: fix breakage caused by the autosense update
> >     
> >     A bit of a brown paper bag issue.  The previous patch to remove the soon
> >     to be ripped out fields that were used in autosense actually broke the
> >     driver.  This patch fixes it and has been tested (honestly).
> 
> If James says he tested it, I believe him.  I *think* we're in the
> situation where it works on machines without an IOMMU and breaks on
> machines with an IOMMU.  Joel, Guy, do I have that right?
> _______________________________________________
> parisc-linux mailing list
> parisc-linux <at> lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Permalink | Reply | 8 comments |
headers
Mariusz Kozlowski | 30 Nov 10:20
Picon

[PATCH] parisc: pdcpat remove extra brackets

Hello,

	This patch removes extra brackets.

Signed-off-by: Mariusz Kozlowski <m.kozlowski <at> tuxland.pl>

 include/asm-parisc/pdcpat.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.19-rc6-mm2-a/include/asm-parisc/pdcpat.h	2006-11-16 05:03:40.000000000 +0100
+++ linux-2.6.19-rc6-mm2-b/include/asm-parisc/pdcpat.h	2006-11-30 01:09:47.000000000 +0100
@@ -250,7 +250,7 @@ struct pdc_pat_pd_addr_map_entry {
 #define PAT_GET_ENTITY(value)	(((value) >> 56) & 0xffUL)
 #define PAT_GET_DVI(value)	(((value) >> 48) & 0xffUL)
 #define PAT_GET_IOC(value)	(((value) >> 40) & 0xffUL)
-#define PAT_GET_MOD_PAGES(value)(((value) & 0xffffffUL)
+#define PAT_GET_MOD_PAGES(value) ((value) & 0xffffffUL)

 
 /*
@@ -330,7 +330,7 @@ extern int pdc_pat;     /* arch/parisc/k
 #define PAT_GET_ENTITY(value)	(((value) >> 56) & 0xffUL)
 #define PAT_GET_DVI(value)	(((value) >> 48) & 0xffUL)
 #define PAT_GET_IOC(value)	(((value) >> 40) & 0xffUL)
-#define PAT_GET_MOD_PAGES(value)(((value) & 0xffffffUL)
+#define PAT_GET_MOD_PAGES(value) ((value) & 0xffffffUL)

 #endif /* __ASSEMBLY__ */

--

-- 
Regards,

	Mariusz Kozlowski
Permalink | Reply | 0 comments |
headers
Keaton Kauffman | 30 Nov 07:46
Picon

Re: hi

Head-up, Jim! Think positive and get ready to improvise. 
_______________________________________________
parisc-linux mailing list
parisc-linux <at> lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
Permalink | Reply | 1 comment |
headers
John David Anglin | 30 Nov 16:46
Picon

Re: [PATCH] hppa-linux-gas binutils patch

> It will only allow the case of:
> 		.equ VAR,VALUE
> which was printing an error message before.
> So, it doesn't change any currently existing behavior. 

It adds new behavior which was previously invalid.  The above syntax
isn't valid using HP as and previously gas syntax mirrored the HP
syntax.  So, you have to convince the binutils maintainers that the
above extension is compatible with what exists now.  For example,

LABEL:	.equ VALUE
	.equ VAR,VALUE
LABEL1: .equ VAR,VALUE	; ???

Do these all work correctly?

> As a background story:
> Originally I wanted to add support for
> VAR		.equ  VALUE
> as it's e.g. documented here: http://docs.hp.com/en/92432-90012/ch02.html
> (JAN   .equ  1).
> But this is in contrast to what gas (in as.info) states, since it does not end with a colon:
> "  For HPPA targets, labels need not be immediately followed by a
> "colon, but the definition of a label must begin in column zero.  This
> "also implies that only one label may be defined on each line.
> "    label:     .directive    followed by something
> ...
> Sadly I until now failed to get  this working as well :-(

I believe the labels must be followed by followed by a colon on linux.
On hpux, the colon is optional.  HP as wants no colon.  Note that labels
don't have to be on the same line as the directive.  Thus, I believe that

label:	.equ	VALUE

should work on linux.

I'm not sure the in comment in as.info about only one label per line
is correct.  There's a line termination character that allows multiple
directives per line.  It's useful in macros.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |
headers
John David Anglin | 30 Nov 17:13
Picon

Re: [PATCH] hppa-linux-gas binutils patch

> deller <at> c3000:~/binutils/run/bin$ cat test.s
> AA       .equ  4
> BB      .equ  6
> deller <at> c3000:~/binutils/run/bin$ as test.s
> test.s: Assembler messages:
> test.s:1: Error: Unknown opcode: `aa'
> test.s:2: Error: Invalid operands

This is because the linux target was changed to require colons after
labels.  As a result, operands can start in the first column of a line.
Under hpux, there needs to be at least one white space character before
an operand and labels have to start in the first column.

> although as.info states:
> 
> 7.37 `.equ SYMBOL, EXPRESSION'
> ==============================
> 
> This directive sets the value of SYMBOL to EXPRESSION.  It is
> synonymous with `.set'; see *Note `.set': Set.
> 
>    The syntax for `equ' on the HPPA is `SYMBOL .equ EXPRESSION'.

This doesn't reflect that SYMBOL needs to be followed by a colon
on HPPA linux.  So, the documentation needs updating.

Probably, the linux should have been updated to use the normal GNU
syntax when it was introduced.  Now, updating the syntax involves a
potential compatibility break with GCC and existing assembler code.
At the moment, I don't see a strong need to do the update.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 4 comments |

Gmane