LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x_tables: fix alignment on [at least] ppc32 (was Re: 2.6.16-rc1: iptables broken on ppc32?)
From: Harald Welte @ 2006-01-20  0:45 UTC (permalink / raw)
  To: netfilter-devel, Mikael Pettersson, linuxppc-dev, linux-kernel
  Cc: David Miller
In-Reply-To: <20060118150158.GL4603@sunbeam.de.gnumonks.org>

[-- Attachment #1: Type: text/plain, Size: 2476 bytes --]

Hi,

the patch below fixes the problem on ppc32. Dave: Please apply.

[NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32

To keep backwards compatibility with old iptables userspace programs,
the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
IP6T_ALIGN or ARPT_ALIGN in previous kernels.

However, in those kernels the macro was defined in dependency to the
respective layer3 specifi data structures, which we can no longer do with
x_tables.

The fix is an ugly kludge, but it has been tested to solve the problem. Yet
another reason to move away from the current {ip,ip6,arp,eb}tables like
data structures.

Signed-off-by: Harald Welte <laforge@netfilter.org>

---
commit 470faeb379560fe877b685ca69be6a7e4f0e91ed
tree 5732ecd9bcab28469805752514e5c57ba26189a1
parent 44718bbfa186d58477163418d37df173aa2dd079
author Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100
committer Harald Welte <laforge@netfilter.org> Fri, 20 Jan 2006 01:44:24 +0100

 include/linux/netfilter/x_tables.h |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/linux/netfilter/x_tables.h b/include/linux/netfilter/x_tables.h
index 472f048..65f9cd8 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -19,7 +19,20 @@ struct xt_get_revision
 /* For standard target */
 #define XT_RETURN (-NF_REPEAT - 1)
 
-#define XT_ALIGN(s) (((s) + (__alignof__(void *)-1)) & ~(__alignof__(void *)-1))
+/* this is a dummy structure to find out the alignment requirement for a struct
+ * containing all the fundamental data types that are used in ipt_entry, ip6t_entry
+ * and arpt_entry.  This sucks, and it is a hack.  It will be my personal pleasure
+ * to remove it -HW */
+struct _xt_align
+{
+	u_int8_t u8;
+	u_int16_t u16;
+	u_int32_t u32;
+	u_int64_t u64;
+};
+
+#define XT_ALIGN(s) (((s) + (__alignof__(struct _xt_align)-1)) 	\
+			& ~(__alignof__(struct _xt_align)-1))
 
 /* Standard return verdict, or do jump. */
 #define XT_STANDARD_TARGET ""
-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply related

* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: David S. Miller @ 2006-01-20  0:56 UTC (permalink / raw)
  To: laforge; +Cc: linuxppc-dev, netfilter-devel, linux-kernel, mikpe
In-Reply-To: <20060120004512.GT4603@sunbeam.de.gnumonks.org>

From: Harald Welte <laforge@netfilter.org>
Date: Fri, 20 Jan 2006 01:45:12 +0100

> [NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
> 
> To keep backwards compatibility with old iptables userspace programs,
> the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
> IP6T_ALIGN or ARPT_ALIGN in previous kernels.
> 
> However, in those kernels the macro was defined in dependency to the
> respective layer3 specifi data structures, which we can no longer do with
> x_tables.
> 
> The fix is an ugly kludge, but it has been tested to solve the problem. Yet
> another reason to move away from the current {ip,ip6,arp,eb}tables like
> data structures.
> 
> Signed-off-by: Harald Welte <laforge@netfilter.org>

Harald, I'm going to modify this to just use u_int64_t as that
should be totally sufficient.

It is the largest type, and will produce the desired results without
the silly structure.

Some malloc() implementations use "long double" to figure out the
largest type size and alignment requirements any C type might have
on the machine.  But there is no reason to use that here.

^ permalink raw reply

* FEC ERROR
From: feng @ 2006-01-20  4:14 UTC (permalink / raw)
  To: Linuxppc-embedded


Hi,

sometimes,  My PowerPC(852T) get the following message:

FEC ENET: rcv is not +last
FEC ERROR 43200000
FEC ENET: rcv is not +last
FEC ERROR 43200000
FEC ENET: rcv is not +last
FEC ERROR 43200000
...
What does this mean.
Best regards



     

^ permalink raw reply

* Re: [PATCH] PPC32 CPM_UART: update to utilize the new TTY flip API
From: Paul Mackerras @ 2006-01-20  5:05 UTC (permalink / raw)
  To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060115154409.1627.95041.stgit@vitb.dev.rtsoft.ru>

Vitaly Bordug writes:

> This replaces old direct usage of tty->flip stuff with relative flip API
> calls.

Could I have a Signed-off-by line from you for it please?

Paul.

^ permalink raw reply

* serial driver for MPC860T  in linux 2.6.13
From: bharathi kandimalla @ 2006-01-20  6:30 UTC (permalink / raw)
  To: Linuxppc-embedded; +Cc: jagadish

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

  Hi
   We are able to port the linux 2.6 in our target board.As the 
MPC860T has 4 SCC  ports and two SMC ports.I want to up all the SMC and SCC
 ports.When I am selecting all the options in the kernel configuration
 It is getting hanged.
 I did n't see any mknod in the code
  how can I know  ttyCPM2 is for SMC2.At the time of ramdisk building I have created the the softlink to ttyCPM2 ->console
   ttyCPM1 is for SMC1  like that
   and they mentioned only major number is 204 minor number is 46
    As we  want to use 6 ports.We want 6 minor numbers
   
   when I am selectind SMC  and all  SCC' s  the o.s is up in the target board( as the program did not have any portpin configuartions for the SCC's)
   when I am selecting SMC1 and SMC2 it is getting hanged
  
 regards
  Bharathi



			
---------------------------------
Yahoo! Photos
 Got holiday prints? See all the ways to get quality prints in your hands ASAP.

[-- Attachment #2: Type: text/html, Size: 1368 bytes --]

^ permalink raw reply

* u-boot debugging
From: Mustafa Çayır @ 2006-01-20  6:51 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

Hi,

Which tool must i use to debuggin u-boot codes. BDI2000 or windriver visionclick, which one do you prefer? is step by step code tracing possible?

thanks

[-- Attachment #2: Type: text/html, Size: 659 bytes --]

^ permalink raw reply

* MPC5200, PCI, udelay(10)
From: Roman Kuzmenko @ 2006-01-20  8:31 UTC (permalink / raw)
  To: Linuxppc-embedded

Hello.

Please, help me to investigate why the delays present in the
"mpc5xxx_read_config_dword" and "mpc5xxx_write_config_dword" functions
in the "arch/ppc/kernel/mpc52xx_pci.c" file.

I.e.
==========================
  *(volatile u32 *)MPC5xxx_PCI_CAR = 0;
> udelay(10);
  return 0;
==========================

I was neither able to find any reference at the MPC5200 documentation
supplied by FreeScale nor reproduce any error with these lines got
removed.

Thank you.

-- 
Roman Kuzmenko <roman.kuzmenko@auriga.ru>
Auriga, Inc.

^ permalink raw reply

* serial drivers for MPC860Tin linux 2.6.13
From: bharathi kandimalla @ 2006-01-20  8:54 UTC (permalink / raw)
  To: linuxppc-embedded@ozlabs.org; +Cc: ram krishna, jagadish

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

> Hi
>   We are able to port the linux 2.6 in our target board.As the 
MPC860T
> has 4 SCC  ports and two SMC ports.I want to up all the SMC and SCC
> ports.When I am selecting all the options in the kernel configuration
> It is getting hanged.
>  did n't see any mknod in the code
> w how can I know  ttyCPM2 is for SMC2
> ttyCPM1 is for SMC1  like thatI 
>    and they mentioned only major number is 204
> mainor number is 46
>  As we  want to use 6 ports.We want 6 minor numbers
> regards
bharthi

			
---------------------------------
Yahoo! Photos
 Got holiday prints? See all the ways to get quality prints in your hands ASAP.

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

^ permalink raw reply

* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: Mikael Pettersson @ 2006-01-20  9:28 UTC (permalink / raw)
  To: David S. Miller; +Cc: laforge, linuxppc-dev, netfilter-devel, linux-kernel
In-Reply-To: <20060119.165635.104653932.davem@davemloft.net>

David S. Miller writes:
 > From: Harald Welte <laforge@netfilter.org>
 > Date: Fri, 20 Jan 2006 01:45:12 +0100
 > 
 > > [NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
 > > 
 > > To keep backwards compatibility with old iptables userspace programs,
 > > the new XT_ALIGN macro always has to return the same value as IPT_ALIGN,
 > > IP6T_ALIGN or ARPT_ALIGN in previous kernels.
 > > 
 > > However, in those kernels the macro was defined in dependency to the
 > > respective layer3 specifi data structures, which we can no longer do with
 > > x_tables.
 > > 
 > > The fix is an ugly kludge, but it has been tested to solve the problem. Yet
 > > another reason to move away from the current {ip,ip6,arp,eb}tables like
 > > data structures.
 > > 
 > > Signed-off-by: Harald Welte <laforge@netfilter.org>
 > 
 > Harald, I'm going to modify this to just use u_int64_t as that
 > should be totally sufficient.

ACK. Both Harald's patch and DaveM's simplification of it
(simply s/void */u_int64_t/g in XT_ALIGN()) fix the iptables
problems on my ppc32 box.

/Mikael

^ permalink raw reply

* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: David S. Miller @ 2006-01-20  9:43 UTC (permalink / raw)
  To: mikpe; +Cc: laforge, linuxppc-dev, netfilter-devel, linux-kernel
In-Reply-To: <17360.44337.425946.347577@alkaid.it.uu.se>

From: Mikael Pettersson <mikpe@csd.uu.se>
Date: Fri, 20 Jan 2006 10:28:17 +0100

> ACK. Both Harald's patch and DaveM's simplification of it
> (simply s/void */u_int64_t/g in XT_ALIGN()) fix the iptables
> problems on my ppc32 box.

Thanks for testing.

^ permalink raw reply

* [PATCH] sound/ppc/pmac.c typo.
From: Stelian Pop @ 2006-01-20 10:35 UTC (permalink / raw)
  To: linuxppc-dev

In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
which prevents my Powerbook G4 sound from working:

	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
	snd: can't request rsrc  0 (Sound Control: 0x80000000:80004fff)
	ALSA device list:
	   No soundcards found.

The patch below fixes it. Of course, the patch fixing the i2c issues 
('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
the sound to completly work.
 
Signed-off-by: Stelian Pop <stelian@popies.net>

diff -r ad1abd4058ea sound/ppc/pmac.c
--- a/sound/ppc/pmac.c	Fri Jan 20 11:02:26 2006 +0100
+++ b/sound/ppc/pmac.c	Fri Jan 20 11:13:55 2006 +0100
@@ -1217,7 +1217,7 @@
 			goto __error;
 		}
 		for (i = 0; i < 3; i ++) {
-			if (of_address_to_resource(np->parent, i,
+			if (of_address_to_resource(np, i,
 						   &chip->rsrc[i])) {
 				printk(KERN_ERR "snd: can't translate rsrc "
 				       " %d (%s)\n", i, rnames[i]);


-- 
Stelian Pop <stelian@popies.net>

^ permalink raw reply

* Re: AGPGART driver for ArticiaS - ioremap() problem
From: Gerhard Pircher @ 2006-01-20 11:16 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1137708554.12998.31.camel@localhost.localdomain>

> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: AGPGART driver for ArticiaS - ioremap() problem
> Datum: Fri, 20 Jan 2006 09:09:13 +1100
> 
> > > Makes sense, since this value is right in the middle of your RAM :)
> > > What does the firmware sets the base register too ?
> > I did a readout of all AGP related registers and the base register was
> > set to 0x0, so the firmware doesn't set it up at all.
> > 
> > > Can't you try to allocate some resource in the PCI area that isn't
> > > already occupied instead ?
> > I though the GART base address should be in memory space!?
> 
> Euh... I was talking about the aperture base, not the GART base... (One
> is the address one the bus where the AGP area will be visible, the other
> is where the GART will be in memory, that is the table that contains the
> mapping between AGP pages and memory pages).
Doh! :) Actually I meant the aperture base. That was a communication error
between brain and hands. :) 

> > Sorry for this dumb question: how can I allocate a resource in the PCI
> > area? I'm not yet familiar with the whole Linux PCI/MM API. :) With
> > something like pci_alloc_consistent()?
> 
> Nope... look at drivers/pci/setup-res.c how it does for allocating new
> resources for PCI devices.
I guess you mean something like this code snipped from the efficeon-agp.c
source code (with pci_assign_resource()):

---

/*
 * The following fixes the case where the BIOS has "forgotten" to
 * provide an address range for the GART.
 * 20030610 - hamish@zot.org
 */
r = &pdev->resource[0];
if (!r->start && r->end) {
   if(pci_assign_resource(pdev, 0)) {
      printk(KERN_ERR PFX "could not assign resource 0\n");
      return -ENODEV;
   }
}

/*
 * If the device has not been properly setup, the following will catch
 * the problem and should stop the system from crashing.
 * 20030610 - hamish@zot.org
 */
if (pci_enable_device(pdev)) {
   printk(KERN_ERR PFX "Unable to Enable PCI device\n");
   return -ENODEV;
}

/* Fill in the mode register */
if (cap_ptr) {
   pci_read_config_dword(pdev,
   bridge->capndx+PCI_AGP_STATUS, &bridge->mode);
}

pci_set_drvdata(pdev, bridge);

----

BTW: I took a look at the PCI resources list of the AmigaOne and found out
that the resources of the AGP graphic card are allocated to bus 0 (PCI
only). IMHO their allocation should be assigned to bus 1 (AGP) (at least
this is the case on x86!?), so I think this should be fixed. Is my
assumption correct?

Thanks!

Gerhard

-- 
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

^ permalink raw reply

* Re: [PATCH] powerpc: remove useless spinlock from mpc83xx watchdog
From: Wim Van Sebroeck @ 2006-01-20 11:55 UTC (permalink / raw)
  To: Alan Cox; +Cc: Andrew Morton, Kumar Gala, linux-kernel, linuxppc-embedded
In-Reply-To: <1137708739.8471.69.camel@localhost.localdomain>

All,

> On Iau, 2006-01-19 at 14:48 -0200, Marcelo Tosatti wrote:
> > On Thu, Jan 19, 2006 at 09:49:16AM +0000, Alan Cox wrote:
> > > 
> > > 	f = open("/dev/watchdog", O_RDWR);
> > > 	fork();
> > > 	while(1) {
> > > 		write(f, "Boing", 5);
> > > 	}
> > 
> > Oops.
> > 
> > At least 50% of the watchdog drivers rely solely on the "wdt_is_open"
> > atomic variable and are broken with respect to synchronization.
> 
> What an excellent janitors project

I'll have a look at it from a global point of view.

Greetings,
Wim.

^ permalink raw reply

* Re: FEC ERROR
From: Wolfgang Denk @ 2006-01-20 13:37 UTC (permalink / raw)
  To: feng; +Cc: Linuxppc-embedded
In-Reply-To: <43D06E4F.15E79E.30255>

In message <43D06E4F.15E79E.30255> you wrote:
> 
> sometimes,  My PowerPC(852T) get the following message:

And your kernel version is ... ???

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Lots of folks confuse bad management with destiny.   -- Frank Hubbard

^ permalink raw reply

* Re: u-boot debugging
From: Wolfgang Denk @ 2006-01-20 13:40 UTC (permalink / raw)
  To: Mustafa Çayır; +Cc: linuxppc-embedded
In-Reply-To: <008501c61d8d$e35ff9f0$9e01120a@bilisim.local>

In message <008501c61d8d$e35ff9f0$9e01120a@bilisim.local> you wrote:
> 
> Which tool must i use to debuggin u-boot codes. BDI2000 or windriver
> visionclick, which one do you prefer? is step by step code tracing
> possible?

I know that the  BDI2000  works  fine,  and  some  people  have  been
successfully   using   the  vision*  tools,  too  (often  after  some
struggeling).

My personal tool of choice is the BDi2000.

Use the tool you know best...

And yes, single stepping is possible if your tool allows it.


Note that this question is off topic on this list;  you  should  post
such questions on the U-Boot mailing list. But please ntoe that...

> Content-Type: text/html;
> 	charsetÿso-8859-9"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

...HTML code is strictly forbidden there!

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

^ permalink raw reply

* I'm in troube to port linux on 405ep
From: Jongmin Yoon @ 2006-01-20 13:52 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 3540 bytes --]

Hello, there,

 

Now, I’m in trouble with porting Linux to AMCC PPC405EP.

I think u-boot was ported successfully, So, I compile linux kernel 2.6.14 with crosstool-0.38

 

Here is a capture of my terminial

 

=> tftp 200000 uImage

ENET Speed is 10 Mbps - HALF duplex connection

TFTP from server 192.168.10.100; our IP address is 192.168.10.99

Filename 'uImage'.

Load address: 0x200000

Loading: T invalid RARP header

#################################################################

         #################################################################

         #################################################################

         ################

done

Bytes transferred = 1075636 (1069b4 hex)

=> bootm 200000

## Booting image at 00200000 ...

   Image Name:   Linux-2.6.14-kodicom

   Created:      2006-01-20  13:37:31 UTC

   Image Type:   PowerPC Linux Kernel Image (gzip compressed)

   Data Size:    1075572 Bytes =  1 MB

   Load Address: 00000000

   Entry Point:  00000000

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

## Transferring control to Linux (at address 00000000) ...

Starting kernel...

id mach(): done

MMU:enter

MMU:hw init

MMU:mapin

MMUetio

MMU:exit

setup_arch: enter

setup_arch: bootmem

ocp: exit

arch: exit

@

@

@

@

@

@

@

|^_���^_^_��~L~L~@p^_p^_�^_~L|�~L�^\|^_�|�^_^\p�^_?�^_~@~@|~L^_~L||

^_8~�^_|^_|^_^_^G|^_|^_8|^\~@|^_~L~L��c|~C^_�|�^_�~L�^\|^_�|�|

^_^\?�^_8�^_~@����|~Lp^\~L~@|c�~Lp^_c~@~L|p~@p|~C|�~C|^C�^_^\p��~@|

p~L|����|~C|^_�~@~L|pp��|p^C~L|^_������~L~L~Cp|�^_^\p|cp�~C|^_

|�^C�|^_^G|��~Lp^_|^_|~@|^C~L|~C|||�|^C�^\|^_?~^_8|^Cp|c~@^_^\?pp

^\�^_~@^_^\?�|||~L|^\|�c|~@~L|^_?�^_|��|�|~L|^_�p^C~L|^_���^_^_

��~L~L�p|�^C���p^C~L|^_|p������~L~L�|c��~@|p�p|^_|~L��^_p^_|

|�||^\~L|^_������~L~L�~C~L�^\||~L����|~L|^_|^_�|~@�p~@|�|~L�^\\

�|�|�^_�|^_|^_^_~L~@~@|~C|^_�~@�~L|p��p||^_|~@|�^_8~~L�|p|^C

~L|^_^\?��~@�~C|||^_|^_~L||~C|p|c|���|~C|p~L�~@||��|�p|��p�|�p�||

�^\�������|����^_~@�|��^_�������^_~@�|�^_~@�^_~@��~~

L|~L|�p~L|~L|^_^G~L|~L|^_�^C~L|^_|p������~L~L~L~C~@~@|p|^_|||^_^\~@||

^Cp��^_^_~L��^_8p|~C|^_^_||^\��p~@|�|^_^G|�~L�^\p��~@��||�~@|�

p�~C|�~L�^_cp^C~L|^_|p��^_^_��~L~L�||�^_�|~@|^_^_p�|�|^_||^_~Lp||

p~@�~L|�~L|^_�p~@�c�|~C||�c|p�|^\?~c^_p^C~L|^_���^_^_��~L~L~@~@|c|||

~@|^\|p|��^_|^_^_�^_|||~@|^Cp��~L�p~L�|^_8p|~C|~L�^_|^\�|��|

��^_|p|�|cp|^\�~L|~@^_^\?~@���|p�p�|�~L�^_|~Cp^C~L|^_���^_^_��

~L~L~C|||^_8~^_^_~L^_~@�^_|^_^_�^_|||^_^\~@|^Cp��~L�p~L��^_8p|~C|^_^_|

|^\��||�~@|^_|^_^G~@�cp|^\�~@|~@�|~L|~L||�|��~C~@|c|^_cp^C~L|^_||

p������~L~L~Lp^_^_~L|^_|p|~Cp���|�|�|�p��~C|^_|�^\~@|^_^_^_^^

G��~@||�p|�cp||^_^_~@|^_^\|�|~@�c|�~L||p��~@����^_^\�||�p

��^_p^_~@|��|����|~L|^_^_~L|^_p~Cp^C~L

 

 

I don’t know what’s wrong… 

Is there anybody to give me some advises?

 

 

Regards,

I


[-- Attachment #2: Type: text/html, Size: 70698 bytes --]

^ permalink raw reply

* Re: [PATCH] sound/ppc/pmac.c typo.
From: Takashi Iwai @ 2006-01-20 14:51 UTC (permalink / raw)
  To: Stelian Pop; +Cc: linuxppc-dev
In-Reply-To: <1137753338.5050.8.camel@localhost.localdomain>

At Fri, 20 Jan 2006 11:35:38 +0100,
Stelian Pop wrote:
> 
> In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
> which prevents my Powerbook G4 sound from working:
> 
> 	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
> 	snd: can't request rsrc  0 (Sound Control: 0x80000000:80004fff)
> 	ALSA device list:
> 	   No soundcards found.
> 
> The patch below fixes it. Of course, the patch fixing the i2c issues 
> ('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
> the sound to completly work.
>  
> Signed-off-by: Stelian Pop <stelian@popies.net>

Thanks, I applied it to ALSA tree now.


Takashi

^ permalink raw reply

* Re: I'm in troube to port linux on 405ep
From: Mark Chambers @ 2006-01-20 15:52 UTC (permalink / raw)
  To: Jongmin Yoon, linuxppc-embedded
In-Reply-To: <002d01c61dc8$c90572c0$efb079d2@Thinkpad>


Now, I’m in trouble with porting Linux to AMCC PPC405EP.
I think u-boot was ported successfully, So, I compile linux kernel 2.6.14
with crosstool-0.38
Here is a capture of my terminial

<snip>

setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
@
@
@
@
@
@
@
|^_���^_^_��~L~L~@p^_p^_�^_~L|�~L�^\|^_�|�^_^\p�^_?�^_~@~@|~L^_~L||
^_8~�^_|^_|^_^_^G|^_|^_8|^\~@|^_~L~L��c|~C^_�|�^_�~L�^\|^_�|�|
^_^\?�^_8�^_~@����|~Lp^\~L~@|c�~Lp^_c~@~L|p~@p|~C|�~C|^C�^_^\p��~@|
p~L|����|~C|^_�~@~L|pp��|p^C~L|^_������~L~L~Cp|�^_^\p|cp�~C|^_
|�^C�|^_^G|��~Lp^_|^_|~@|^C~L|~C|||�|^C�^\|^_?~^_8|^Cp|c~@^_^\?pp
^\�^_~@^_^\?�|||~L|^\|�c|~@~L|^_?�^_|��|�|~L|^_�p^C~L|^_���^_^_
��~L~L�p|�^C���p^C~L|^_|p������~L~L�|c��~@|p�p|^_|~L��^_p^_|
|�||^\~L|^_������~L~L�~C~L�^\||~L����|~L|^_|^_�|~@�p~@|�|~L�^\\
�|�|�^_�|^_|^_^_~L~@~@|~C|^_�~@�~L|p��p||^_|~@|�^_8~~L�|p|^C
~L|^_^\?��~@�~C|||^_|^_~L||~C|p|c|���|~C|p~L�~@||��|�p|��p�|�p�||
�^\�������|����^_~@�|��^_�������^_~@�|�^_~@�^_~@��~~

Probably when the kernel (re)configures the terminal it sets it to a
different baud rate

You should send your email in plain text mode, no HTML

Mark Chambers

^ permalink raw reply

* Re: [PATCH] sound/ppc/pmac.c typo.
From: Stelian Pop @ 2006-01-20 15:54 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: linuxppc-dev
In-Reply-To: <s5hpsmn7y0l.wl%tiwai@suse.de>

Le vendredi 20 janvier 2006 à 15:51 +0100, Takashi Iwai a écrit :
> At Fri, 20 Jan 2006 11:35:38 +0100,
> Stelian Pop wrote:
> > 
> > In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
> > which prevents my Powerbook G4 sound from working:
> > 
> > 	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
> > 	snd: can't request rsrc  0 (Sound Control: 0x80000000:80004fff)
> > 	ALSA device list:
> > 	   No soundcards found.
> > 
> > The patch below fixes it. Of course, the patch fixing the i2c issues 
> > ('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
> > the sound to completly work.
> >  
> > Signed-off-by: Stelian Pop <stelian@popies.net>
> 
> Thanks, I applied it to ALSA tree now.

Thanks.

BTW, is it a hardware or a configuration issue the fact that I'm unable
to mix several alsa streams ?

For example, if I issue two instances of 'aplay foo.wav', the first one
plays the sound while the second one remains stuck in:
	stat64("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=7467, ...}) = 0
	open("/dev/snd/controlC0", O_RDONLY)    = 3
	close(3)                                = 0
	open("/dev/snd/controlC0", O_RDWR)      = 3
	ioctl(3, USBDEVFS_CONTROL, 0x7fee2bf8)  = 0
	ioctl(3, UI_DEV_CREATE, 0x7fee2ca0)     = 0
	close(3)                                = 0
	open("/dev/snd/controlC0", O_RDONLY)    = 3
	close(3)                                = 0
	open("/dev/snd/controlC0", O_RDWR)      = 3
	ioctl(3, USBDEVFS_CONTROL, 0x7fee2fa8)  = 0
	ioctl(3, 0x80045532, 0x7fee2fd8)        = 0
	open("/dev/snd/pcmC0D0p", O_RDWR
until the first one ends playing. Only then the second one continues the
execution.

Just in case this is useful:
	# cat /proc/asound/version
	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
	# cat /proc/asound/cards
	 0 [Snapper        ]: PMac Snapper - PowerMac Snapper
	                      PowerMac Snapper (Dev 0) Sub-frame 0
	# cat /proc/asound/devices
	  0: [ 0]   : control
	  1:        : sequencer
	 16: [ 0- 0]: digital audio playback
	 24: [ 0- 0]: digital audio capture
	 33:        : timer
	# cat /proc/asound/pcm
	00-00: PMac Snapper : PowerMac Snapper : playback 1 : capture 1

Stelian.
-- 
Stelian Pop <stelian@popies.net>

^ permalink raw reply

* Re: [PATCH] sound/ppc/pmac.c typo.
From: Takashi Iwai @ 2006-01-20 16:06 UTC (permalink / raw)
  To: Stelian Pop; +Cc: linuxppc-dev
In-Reply-To: <1137772472.14920.9.camel@localhost.localdomain>

At Fri, 20 Jan 2006 16:54:31 +0100,
Stelian Pop wrote:
> 
> Le vendredi 20 janvier 2006 à 15:51 +0100, Takashi Iwai a écrit :
> > At Fri, 20 Jan 2006 11:35:38 +0100,
> > Stelian Pop wrote:
> > > 
> > > In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
> > > which prevents my Powerbook G4 sound from working:
> > > 
> > > 	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
> > > 	snd: can't request rsrc  0 (Sound Control: 0x80000000:80004fff)
> > > 	ALSA device list:
> > > 	   No soundcards found.
> > > 
> > > The patch below fixes it. Of course, the patch fixing the i2c issues 
> > > ('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
> > > the sound to completly work.
> > >  
> > > Signed-off-by: Stelian Pop <stelian@popies.net>
> > 
> > Thanks, I applied it to ALSA tree now.
> 
> Thanks.
> 
> BTW, is it a hardware or a configuration issue the fact that I'm unable
> to mix several alsa streams ?

Did you install alsa-lib 1.0.11rc2, too?  It should work with dmix as
default.


Takashi

^ permalink raw reply

* Re: [PATCH] sound/ppc/pmac.c typo.
From: Stelian Pop @ 2006-01-20 16:09 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: linuxppc-dev
In-Reply-To: <s5hek3251ez.wl%tiwai@suse.de>

Le vendredi 20 janvier 2006 à 17:06 +0100, Takashi Iwai a écrit :
> At Fri, 20 Jan 2006 16:54:31 +0100,
> Stelian Pop wrote:
> > 
> > Le vendredi 20 janvier 2006 à 15:51 +0100, Takashi Iwai a écrit :
> > > At Fri, 20 Jan 2006 11:35:38 +0100,
> > > Stelian Pop wrote:
> > > > 
> > > > In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
> > > > which prevents my Powerbook G4 sound from working:
> > > > 
> > > > 	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
> > > > 	snd: can't request rsrc  0 (Sound Control: 0x80000000:80004fff)
> > > > 	ALSA device list:
> > > > 	   No soundcards found.
> > > > 
> > > > The patch below fixes it. Of course, the patch fixing the i2c issues 
> > > > ('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
> > > > the sound to completly work.
> > > >  
> > > > Signed-off-by: Stelian Pop <stelian@popies.net>
> > > 
> > > Thanks, I applied it to ALSA tree now.
> > 
> > Thanks.
> > 
> > BTW, is it a hardware or a configuration issue the fact that I'm unable
> > to mix several alsa streams ?
> 
> Did you install alsa-lib 1.0.11rc2, too?  It should work with dmix as
> default.

This is an ubuntu breezy ppc distribution, and it seems that the package
is called libasound2, and it is based on alsa-lib 1.0.9-2.

Stracing the aplay process shows that dmix.conf is being read:

	defiant:~ 20 > strace -eopen aplay wav/slow_20spindle_20motor.wav
	open("/etc/ld.so.cache", O_RDONLY)      = 3
	open("/usr/lib/libasound.so.2", O_RDONLY) = 3
	open("/lib/libm.so.6", O_RDONLY)        = 3
	open("/lib/libdl.so.2", O_RDONLY)       = 3
	open("/lib/libpthread.so.0", O_RDONLY)  = 3
	open("/lib/libc.so.6", O_RDONLY)        = 3
	open("/usr/share/alsa/alsa.conf", O_RDONLY) = 3
	open("/usr/share/alsa/cards/aliases.conf", O_RDONLY) = 3
	open("/usr/share/alsa/pcm/default.conf", O_RDONLY) = 4
	open("/usr/share/alsa/pcm/dmix.conf", O_RDONLY) = 4
	open("/usr/share/alsa/pcm/dsnoop.conf", O_RDONLY) = 4
	open("/dev/snd/controlC0", O_RDONLY)    = 3
	open("/dev/snd/controlC0", O_RDONLY)    = 3
	open("/dev/snd/controlC0", O_RDWR)      = 3
	open("/dev/snd/controlC1", O_RDONLY)    = -1 ENOENT (No such file or directory)
	open("/dev/aloadC1", O_RDONLY)          = -1 ENOENT (No such file or directory)
	[...]

I suppose I could test with 1.0.11rc2 if it does make sense to.

Stelian.
-- 
Stelian Pop <stelian@popies.net>

^ permalink raw reply

* Re: [PATCH] sound/ppc/pmac.c typo.
From: Takashi Iwai @ 2006-01-20 16:25 UTC (permalink / raw)
  To: Stelian Pop; +Cc: linuxppc-dev
In-Reply-To: <1137773366.14920.16.camel@localhost.localdomain>

At Fri, 20 Jan 2006 17:09:26 +0100,
Stelian Pop wrote:
> 
> Le vendredi 20 janvier 2006 à 17:06 +0100, Takashi Iwai a écrit :
> > At Fri, 20 Jan 2006 16:54:31 +0100,
> > Stelian Pop wrote:
> > > 
> > > Le vendredi 20 janvier 2006 à 15:51 +0100, Takashi Iwai a écrit :
> > > > At Fri, 20 Jan 2006 11:35:38 +0100,
> > > > Stelian Pop wrote:
> > > > > 
> > > > > In 2.6.16-rc1 there is a small typo introduced by the 'Remove device_node addrs/n_addr' changes
> > > > > which prevents my Powerbook G4 sound from working:
> > > > > 
> > > > > 	Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20 2006 UTC).
> > > > > 	snd: can't request rsrc  0 (Sound Control: 0x80000000:80004fff)
> > > > > 	ALSA device list:
> > > > > 	   No soundcards found.
> > > > > 
> > > > > The patch below fixes it. Of course, the patch fixing the i2c issues 
> > > > > ('i2c_smbus_write_i2c_block_data' patch) needs to be applied to in order for
> > > > > the sound to completly work.
> > > > >  
> > > > > Signed-off-by: Stelian Pop <stelian@popies.net>
> > > > 
> > > > Thanks, I applied it to ALSA tree now.
> > > 
> > > Thanks.
> > > 
> > > BTW, is it a hardware or a configuration issue the fact that I'm unable
> > > to mix several alsa streams ?
> > 
> > Did you install alsa-lib 1.0.11rc2, too?  It should work with dmix as
> > default.
> 
> This is an ubuntu breezy ppc distribution, and it seems that the package
> is called libasound2, and it is based on alsa-lib 1.0.9-2.

1.0.9 doesn't use dmix as default.


Takashi

^ permalink raw reply

* Re: [PATCH] sound/ppc/pmac.c typo.
From: Stelian Pop @ 2006-01-20 16:37 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: linuxppc-dev
In-Reply-To: <s5h3bjisw6x.wl%tiwai@suse.de>

Le vendredi 20 janvier 2006 à 17:25 +0100, Takashi Iwai a écrit :

> > > > BTW, is it a hardware or a configuration issue the fact that I'm unable
> > > > to mix several alsa streams ?
> > > 
> > > Did you install alsa-lib 1.0.11rc2, too?  It should work with dmix as
> > > default.
> > 
> > This is an ubuntu breezy ppc distribution, and it seems that the package
> > is called libasound2, and it is based on alsa-lib 1.0.9-2.
> 
> 1.0.9 doesn't use dmix as default.

Ok, using 1.0.11rc2 works with dmix indeed.

Aplay works correctly. So does xine.

However mplayer seems to have problems with this version of the library:

[...]
Building audio filter chain for 22050Hz/1ch/u8 -> 0Hz/0ch/s8...
alsa-init: 1 soundcard found, using: default
alsa: 22050 Hz/1 channels/1 bpf/8192 bytes buffer/Unsigned 8 bit
AO: [alsa] 22050Hz 1ch u8 (1 bps)
Building audio filter chain for 22050Hz/1ch/u8 -> 22050Hz/1ch/u8...
Video: no video
Starting playback...
alsa-space: xrun of at least 0.006 msecs. resetting stream
alsa-space: xrun of at least 0.006 msecs. resetting stream
alsa-space: xrun of at least 0.006 msecs. resetting stream
alsa-space: xrun of at least 0.005 msecs. resetting stream
alsa-space: xrun of at least 0.009 msecs. resetting stream
alsa-space: xrun of at least 0.006 msecs. resetting stream
alsa-space: xrun of at least 0.004 msecs. resetting stream
alsa-space: xrun of at least 0.005 msecs. resetting stream
alsa-space: xrun of at least 0.005 msecs. resetting stream

But it could be mplayer's fault at this point.

Stelian.
-- 
Stelian Pop <stelian@popies.net>

^ permalink raw reply

* Re: MPC5200, PCI, udelay(10)
From: Andrey Volkov @ 2006-01-20 17:24 UTC (permalink / raw)
  To: roman.kuzmenko; +Cc: Linuxppc-embedded
In-Reply-To: <1137745904.4631.17.camel@trust.auriga.ru>

Roman Kuzmenko wrote:
> Hello.
> 
> Please, help me to investigate why the delays present in the
> "mpc5xxx_read_config_dword" and "mpc5xxx_write_config_dword" functions
> in the "arch/ppc/kernel/mpc52xx_pci.c" file.
> 
> I.e.
> ==========================
>   *(volatile u32 *)MPC5xxx_PCI_CAR = 0;
>> udelay(10);
>   return 0;
> ==========================
> 
> I was neither able to find any reference at the MPC5200 documentation
> supplied by FreeScale nor reproduce any error with these lines got
> removed.
> 
> Thank you.
> 
kernel version?

--
Regards
Andrey Volkov

^ permalink raw reply

* Re: [PATCH] x_tables: fix alignment on [at least] ppc32
From: Harald Welte @ 2006-01-20 17:28 UTC (permalink / raw)
  To: David S. Miller
  Cc: linuxppc-dev, netfilter-devel, Jiri Slaby, linux-kernel, mikpe
In-Reply-To: <20060119.165635.104653932.davem@davemloft.net>

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

On Thu, Jan 19, 2006 at 04:56:35PM -0800, David S. Miller wrote:
> > [NETFILTER] x_tables: Fix XT_ALIGN() macro on [at least] ppc32
> > [...]
> > The fix is an ugly kludge, but it has been tested to solve the problem. Yet
> > another reason to move away from the current {ip,ip6,arp,eb}tables like
> > data structures.
> > 
> > Signed-off-by: Harald Welte <laforge@netfilter.org>
> 
> Harald, I'm going to modify this to just use u_int64_t as that
> should be totally sufficient.
>
> It is the largest type, and will produce the desired results without
> the silly structure.

Sorry dave, as I just learned, it isn't.   As reported by Jiri Slaby
<xslaby@fi.muni.cz>, Linus' tree now breaks on i386 :(

Interestingly, on i386:

__alignof__(struct _xt_align)	4
__alignof__(u_int64_t)		8
__alignof__(void *)		4

whereas on ppc:

__alignof__(struct _xt_align)	8
__alignof__(u_int64_t)		8
__alignof__(void *)		4

So your assumption that __alignof__(u_int64_t) == __alignof__(struct xt_align)
doesn't hold true for all archs.

I would therefore recommend applying my unmodified patch, and hope that
it then works on all archs simultaneously.

> Some malloc() implementations use "long double" to figure out the
> largest type size and alignment requirements any C type might have
> on the machine.  But there is no reason to use that here.

Our main problem is that we have to stay compatible with old userspace
programs that had a different definition for what has now become
XT_ALIGN().  So independent what might be the best solution from an
alignment point of view, we must match what old userspace thinks.

Yes, this all sucks.  And yes, we will see a new interface this year.
Promised.

Cheers,
	Harald.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox