debian-users-admin | 1 Dec 10:03 2006
Picon

Subscribe request result (debian-users ML)

Hi, I am the fml ML manager for the ML <debian-users <at> debian.or.jp>.

--debian-users <at> debian.or.jp, Be Seeing You!    

************************************************************
If you have any questions or problems,
   please contact debian-users-admin <at> debian.or.jp

************************************************************
Kurt Fitzner | 1 Dec 11:51 2006
Face

Re: Debian etch rc1 & daily build install fail on C160

The Zalos driver is missing from Debian.  I feel like an idiot now.

Is this missing by design?  Anyone I can convince to add it?
Adrian Bunk | 1 Dec 12:48 2006
Picon

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

"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:
- 21 Nov 2006
- 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
 <at>  <at>  -158,12 +158,12  <at>  <at> 
 #define stw(_s,_t,_o,_a,_e) 	def_store_insn(stw,"r",_s,_t,_o,_a,_e)
(Continue reading)

Adrian Bunk | 1 Dec 12:49 2006
Picon

[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:
- 21 Nov 2006
- 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
 <at>  <at>  -35,12 +35,8  <at>  <at> 

 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)

Joel Soete | 1 Dec 16:58 2006
Picon

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


Guy Martin wrote:
> Hi James,
> 
> This is working fine ! Thanks a lot !
> 
> I was able to mount a cd without any pb.
> 
> Cheers,
>   Guy
> 
> On Thu, 30 Nov 2006 13:13:46 -0500
> James Bottomley <James.Bottomley <at> SteelEye.com> wrote:
> 
>> On Thu, 2006-11-30 at 12:17 -0500, James Bottomley wrote:
>>> And here we get a phase mismatch in the command phase because the drive
>>> transitions to data phase after six bytes and the driver still thinks it
>>> has another four to send.
>>>
>>> I'd have the maintainer shot ... he clearly forgot to set up the command
>>> length for auto request sense.
>> Try this and see if it fixes the problem
>>
>> James
> 
Sorry no yet a fix for my pb :_(
scsi1: (3:0) phase mismatch at 01e8, phase IO CD MSG BSY REQ MSG IN
scsi1: Bus Reset detected, executing command 15db93c0, slot 2ff48520, dsp 001c81e8[01e8]
  failing command because of reset, slot 2ff48520, cmnd 15db93c0
  failing command because of reset, slot 2ff4864c, cmnd 2feb03c0
(Continue reading)

Matthew Wilcox | 1 Dec 17:10 2006

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

On Fri, Dec 01, 2006 at 03:58:00PM +0000, Joel Soete wrote:
> Sorry no yet a fix for my pb :_(

It'd be useful to know if your problem was introduced at the same time.
Can you try the same git revisions that Guy tried and let us know if
that's the same commit that broke your machine?
Grant Grundler | 1 Dec 17:43 2006

Re: [2.6 patch] parisc: "extern inline" -> "static inline" (fwd)

On Fri, Dec 01, 2006 at 12:48:11PM +0100, Adrian Bunk wrote:
> "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.

John David Anglin is the hppa/parisc gcc maintainer and has
commented on inline variants last year:
    http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html

This makes me think -Wmissing-prototypes is reporting the wrong warning.
ie there is a prototype but no function and no label.
Can you check with gcc folks to see if this is a gcc bug?

The parisc point intentionally switched to "extern inline" at one
point and unless what jda wrote is now incorrect, I'm not inclined
to change it.

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

Yes, all the functions marked "extern inline" are expected to get
essentially the same treatment as "always_inline".

thanks,
grant
Adrian Bunk | 1 Dec 17:54 2006
Picon

Re: [2.6 patch] parisc: "extern inline" -> "static inline" (fwd)

On Fri, Dec 01, 2006 at 09:43:54AM -0700, Grant Grundler wrote:
> On Fri, Dec 01, 2006 at 12:48:11PM +0100, Adrian Bunk wrote:
> > "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.
> 
> 
> John David Anglin is the hppa/parisc gcc maintainer and has
> commented on inline variants last year:
>     http://lists.parisc-linux.org/pipermail/parisc-linux/2005-October/027587.html
> 
> This makes me think -Wmissing-prototypes is reporting the wrong warning.
> ie there is a prototype but no function and no label.
> Can you check with gcc folks to see if this is a gcc bug?
> 
> The parisc point intentionally switched to "extern inline" at one
> point and unless what jda wrote is now incorrect, I'm not inclined
> to change it.

If you read John David Anglin's email, you'll note that if you take the 
address you need this function provided somewhere.

Which of the functions my patch changes also have a global function 
provided within the kernel?

If none, "extern inline" didn't make any sense.

> > If there are places that really need a forced inline, __always_inline 
> > would be the correct solution.
(Continue reading)

Grant Grundler | 1 Dec 18:36 2006

Re: [2.6 patch] parisc: "extern inline" -> "static inline" (fwd)

On Fri, Dec 01, 2006 at 05:54:27PM +0100, Adrian Bunk wrote:
> If you read John David Anglin's email, you'll note that if you take the 
> address you need this function provided somewhere.

Let me turn that around.
Which of the "extern inline" functions are we taking the address?
The parisc kernel wouldn't (shouldn't) link if that were true.

> Which of the functions my patch changes also have a global function 
> provided within the kernel?
> 
> If none, "extern inline" didn't make any sense.

I expect none.

...
> Currently, "inline" is defined to be always_inline, and 
> __always_inline is for cases that produce non-compiling or non-working 
> (opposed to only suboptimal) code.

Ok.  Sounds like "extern inline" is the same as __always_inline.

Has gcc community confirmed "gcc -Wmissing-prototypes" behavior
is really correct with respect to "extern inline"?

If so, I'm ok with changing "extern inline" to __always_inline.

thanks,
grant
(Continue reading)

John David Anglin | 1 Dec 18:38 2006
Picon

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

> The parisc point intentionally switched to "extern inline" at one
> point and unless what jda wrote is now incorrect, I'm not inclined
> to change it.

The handling of "extern inline" is changing in GCC 4.3 to the C99 specified
behavior.  The attribute gnu_inline on an inline declaration results in the
old GNU C89 inline behavior even in the ISO C99 mode.

The C99 behavior allows the function being inlined to be externally
called.  As a result, conflicts will occur if the function is defined in
a header included by multiple objects.  So, code that assumed the previous
GNU treatment unfortunately needs to change.

The main difference between "static inline" and "extern inline" in the
old GNU treatment was that with "extern inline" the function was never
compiled on its own, even if its address was explicitly referenced.
With "static inline", the function would be compiled on its own in some
circumstances.  So, this is mostly a code size issue.

More details are present in extend.texi in the GCC head.  This has also
been discussed on the gcc list a few times.

Dave
--

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

Gmane