* Re: stepping through atomic_dec_return
From: Michael Richardson @ 2005-10-07 17:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <19942.1128705328@marajade.sandelman.ottawa.on.ca>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Michael" == Michael Richardson <mcr@sandelman.ottawa.on.ca> writes:
Michael> I can see how setting through this code with the debugger
Michael> could cause a problem, since there would be debug
Michael> exceptions, and there would be other code in the debug
Michael> stubs that could set the RESERVED=0. It's hard to know,
Michael> but it seems unlikely to me.
Actually, I'm wrong.
I was trying to single step through the code, since much of the code
is inline, and doing "n" in the debugger won't set a break point after
that statement, it may well single step through.
Setting a break point after the down() worked.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQ0a0f4qHRg3pndX9AQHs7AP+NVMj0Wy3aT9j1XW6t2hZqgjzVZZpAFuV
8b6hPtMVh/SYv6KbdWD4EmxQ7WMqB1rmx6oknxo6l7zTKHFwqmeW3Nod7X/xhNjy
SW4H8U/y7RjuI68i0rf1jkpUff6+3prKRvnVQ6dml7xH6IygBqDHjVP2hZlut++3
l30N1y5x1mU=
=d/sP
-----END PGP SIGNATURE-----
^ permalink raw reply
* stepping through atomic_dec_return
From: Michael Richardson @ 2005-10-07 17:15 UTC (permalink / raw)
To: linuxppc-embedded
-----BEGIN PGP SIGNED MESSAGE-----
I have what I think is a semaphore problem.
Certainly there is an attempt to down(&sem) when sem->count ==
0. (that's my root cause, which I'm now going to examine)
However, down() in semaphore.h should just fail and call __down().
The problem seems to be that loop in atomic_dec_return(), which
uses lwarx/stwcw seems to never end:
"1: lwarx %0,0,%1 # atomic_dec_return\n\
addic %0,%0,-1\n"
PPC405_ERR77(0,%1)
" stwcx. %0,0,%1\n\
bne- 1b"
SMP_ISYNC
: "=&r" (t)
: "r" (&v->counter)
: "cc", "memory");
lwarx sets the "RESERVED" bit, and stwcx, copies that to the CR0[EQ]
bit, which bne tests.
I don't know what the "-" in the bne means. Is it significant?
I checked, and CONFIG_IBM405_ERR77 is in my .config, so that shouldn't
be the issue. (I think the work around is just a performance issue on
devices without the defect)
I can see how setting through this code with the debugger could cause a
problem, since there would be debug exceptions, and there would be other
code in the debug stubs that could set the RESERVED=0. It's hard to
know, but it seems unlikely to me.
(This is a UP system)
However, I would expect that I can set a break point after this call and
things would work fine. They do not, I get stuck in this loop.
Any comments?
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQ0atLYqHRg3pndX9AQGtNwQAsys7tNm+oVKkSptxYPbWf4KYCgibCRrt
Utb+8XR44dmIbVSeZdPZntR2Jklu00cFrNWw/2pk+Rv0tWdaiynbqRHdrkaVi9xS
9GEmf6v9FsbElIgeZP3/8FY7cuLu5PIDkuwU9can/mYJ1iZEMbLh4YcSJoNFHHws
ooLSWbz9uV8=
=hh8M
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Oops accessing BCSR on 8272ADS
From: Alex Zeffertt @ 2005-10-07 16:19 UTC (permalink / raw)
To: Vitaly Bordug, linuxppc-embedded
In-Reply-To: <43469CCD.5010404@ru.mvista.com>
> >
> It depends on which u-boot you're using and there I'm aware of
> issues when BCSR resides somewhere different... Try 0xF8000000.
> Don't you have btw
>
Thanks Vitaly. You were right. In my u-boot - version 1.1.1 - it was
0xf8000000 not 0xf4500000. I just modified BCSR_ADDR and that stopped
the oops.
Cheers,
Alex
^ permalink raw reply
* Re: Oops accessing BCSR on 8272ADS
From: Vitaly Bordug @ 2005-10-07 15:47 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded list
In-Reply-To: <20051007163735.31f48aeb.ajz@cambridgebroadband.com>
Alex Zeffertt wrote:
> Hi list,
>
> I've just downloaded linux-2.4.31 from kernel.org and compiled it for
> the mpc8272ads board.
>
> When I boot the kernel it oopses in fcc_enet.c:init_fcc_startup() at
> the point where it tries to write to the BCSR.
>
> Does anybody know why writing to the BCSR should cause a machine
> check?
>
I guess I was not ioremapped/io_block_mapped properly.
Take a look into arch/ppc/kernel/m8260_setup.c m8260_map_io() function.
Anyway BCSR is better to be ioremapped in the place it is required.
> TIA,
>
> Alex
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Oops accessing BCSR on 8272ADS
From: Alex Zeffertt @ 2005-10-07 15:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi list,
I've just downloaded linux-2.4.31 from kernel.org and compiled it for
the mpc8272ads board.
When I boot the kernel it oopses in fcc_enet.c:init_fcc_startup() at
the point where it tries to write to the BCSR.
Does anybody know why writing to the BCSR should cause a machine
check?
TIA,
Alex
^ permalink raw reply
* ALERT - GroupShield ticket number OA522_1128695305_BATISTUTA_1 w as generated
From: GroupShield for Exchange (BATISTUTA) @ 2005-10-07 14:28 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
Action Taken:
The attachment was quarantined from the message and replaced with a text
file informing the recipient of the action taken.
To:
linuxppc-embedded@ozlabs.org <linuxppc-embedded@ozlabs.org>
From:
service@ozlabs.org <service@ozlabs.org>
Sent:
-1273239936,29739840
Subject:
Your Account is Suspended For Security Reasons
Attachment Details:-
Attachment Name: important-details.zip
File: important-details.zip
Infected? Yes
Repaired? No
Blocked? No
Deleted? No
Virus Name: Generic Malware.a!zip
[-- Attachment #2: Type: application/ms-tnef, Size: 1959 bytes --]
^ permalink raw reply
* ALERT - GroupShield ticket number OA523_1128698597_BATISTUTA_1 w as generated
From: GroupShield for Exchange (BATISTUTA) @ 2005-10-07 15:23 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Action Taken:
The attachment was quarantined from the message and replaced with a text
file informing the recipient of the action taken.
To:
linuxppc-embedded@ozlabs.org <linuxppc-embedded@ozlabs.org>
From:
webmaster@ozlabs.org <webmaster@ozlabs.org>
Sent:
-1198011008,29739847
Subject:
Important Notification
Attachment Details:-
Attachment Name: email-details.zip
File: email-details.zip
Infected? Yes
Repaired? No
Blocked? No
Deleted? No
Virus Name: Generic Malware.a!zip
[-- Attachment #2: Type: application/ms-tnef, Size: 1935 bytes --]
^ permalink raw reply
* Important Notification
From: webmaster @ 2005-10-07 14:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 721 bytes --]
[-- Attachment #2: email-details.zip --]
[-- Type: application/octet-stream, Size: 53528 bytes --]
^ permalink raw reply
* Re: TQM8260 and linux-2.6.14-rc3
From: Vitaly Bordug @ 2005-10-07 15:12 UTC (permalink / raw)
To: Studencki Pawel; +Cc: linuxppc-embedded list
In-Reply-To: <253377027D27DA11B7010002A5AE5CFE0B72B6@nbgh103a.nbg6.siemens.de>
Studencki Pawel wrote:
> hello,
>
> Trying to boot linux-2.6.14-rc3 on TQM8260 I found,
> that following line is missing in file arch/ppc/syslib/m8260_setup.c:
>
> -----------------------------------------------------------------------
> --- m8260_setup.c.org 2005-10-07 16:42:41.420238000 +0200
> +++ m8260_setup.c 2005-10-07 16:41:58.811408400 +0200
> @@ -249,6 +249,8 @@
> strcpy(cmd_line, (char *)(r6+KERNELBASE));
> }
>
> + identify_ppc_sys_by_id(mfspr(SPRN_SVR));
> +
This is not quite right. For these types of boards (at least, most of),
the soc id is stored in the immr register. But yes, that's definitely a
problem, I'll take a look at this asap.
> ppc_md.setup_arch = m8260_setup_arch;
> ppc_md.show_cpuinfo = m8260_show_cpuinfo;
> ppc_md.init_IRQ = m8260_init_IRQ;
> ---------------------------------------------------------------------
>
>
> if not set, we get problem here:
>
> static int __init ppc_sys_init(void)
> {
> unsigned int i, dev_id, ret = 0;
>
> BUG_ON(cur_ppc_sys_spec == NULL); <--------------------------
>
>
> Moreover the default configuration found in
> arch/ppc/configs/TQM8260_defconfig
> doesn't work or I do something wrong.
> for example configuration of serial port:
>
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> # CONFIG_SERIAL_8250_EXTENDED is not set
>
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_UNIX98_PTY_COUNT=32
>
> inspite of this I use following(SMC1):
>
> #
> # Serial drivers
> #
> # CONFIG_SERIAL_8250 is not set
>
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_SERIAL_CPM=y
> CONFIG_SERIAL_CPM_CONSOLE=y
> # CONFIG_SERIAL_CPM_SCC1 is not set
> # CONFIG_SERIAL_CPM_SCC2 is not set
> # CONFIG_SERIAL_CPM_SCC3 is not set
> # CONFIG_SERIAL_CPM_SCC4 is not set
> CONFIG_SERIAL_CPM_SMC1=y
> # CONFIG_SERIAL_CPM_SMC2 is not set
> CONFIG_UNIX98_PTYS=y
> CONFIG_LEGACY_PTYS=y
> CONFIG_LEGACY_PTY_COUNT=256
>
>
> best regards
> Pawel
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* TQM8260 and linux-2.6.14-rc3
From: Studencki Pawel @ 2005-10-07 14:55 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
hello,
Trying to boot linux-2.6.14-rc3 on TQM8260 I found,
that following line is missing in file arch/ppc/syslib/m8260_setup.c:
-----------------------------------------------------------------------
--- m8260_setup.c.org 2005-10-07 16:42:41.420238000 +0200
+++ m8260_setup.c 2005-10-07 16:41:58.811408400 +0200
@@ -249,6 +249,8 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
+ identify_ppc_sys_by_id(mfspr(SPRN_SVR));
+
ppc_md.setup_arch = m8260_setup_arch;
ppc_md.show_cpuinfo = m8260_show_cpuinfo;
ppc_md.init_IRQ = m8260_init_IRQ;
---------------------------------------------------------------------
if not set, we get problem here:
static int __init ppc_sys_init(void)
{
unsigned int i, dev_id, ret = 0;
BUG_ON(cur_ppc_sys_spec == NULL); <--------------------------
Moreover the default configuration found in
arch/ppc/configs/TQM8260_defconfig
doesn't work or I do something wrong.
for example configuration of serial port:
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=32
inspite of this I use following(SMC1):
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_CPM=y
CONFIG_SERIAL_CPM_CONSOLE=y
# CONFIG_SERIAL_CPM_SCC1 is not set
# CONFIG_SERIAL_CPM_SCC2 is not set
# CONFIG_SERIAL_CPM_SCC3 is not set
# CONFIG_SERIAL_CPM_SCC4 is not set
CONFIG_SERIAL_CPM_SMC1=y
# CONFIG_SERIAL_CPM_SMC2 is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
best regards
Pawel
^ permalink raw reply
* Re: [PATCH] ppc32: make sure we have an L3 before touch its control register
From: Kumar Gala @ 2005-10-07 14:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1128645230.17365.5.camel@gaston>
On Oct 6, 2005, at 7:33 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:
>
>>> Dope, you're right. I notice that we apparent do this for BTIC and
>>>
>
>
>>> DPM in this function though?
>>>
>>
>> Yes, those bits are buggy. Good catch
>>
>
> And no, in fact, my brain is buggy... On ppc32 we identify first, then
> fixup, then only do the call_setup_cpu ! That's why the Idle NAP code
> actually goes test the feature bit.
>
> I think ppc64 does it the other way around. ppc64 certainly _requires_
> taht the fixup has not yet been applied while running early_setup() as
> it may change some CPU features according to firmware properties.
>
> So in the merged kernel, we need to be extra careful here. I think we
> should go the ppc64 way actually and apply the fixups later. But that
> means fixing the code in cpu_setup_6xx.S indeed.
Well, since we do this early on ppc32, my patch should be ok than.
(And is need on 7448, do to some crazyness in how L3CR works on
various versions of 7448).
I'd like to see we push this now and worry about "fixing" all of
cpu_setup_6xx.S when we move it over to arch/powerpc
- kumar
^ permalink raw reply
* Your Account is Suspended For Security Reasons
From: service @ 2005-10-07 13:12 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 625 bytes --]
[-- Attachment #2: important-details.zip --]
[-- Type: application/octet-stream, Size: 53536 bytes --]
^ permalink raw reply
* Re: Problem Regarding Ping in Linux kernel version 2.4.24
From: Aristeu Sergio Rozanski Filho @ 2005-10-07 12:31 UTC (permalink / raw)
To: apoorv sangal
Cc: apoorv sangal, vikrant_basotra, sibi_mathew, Linuxppc-embedded
In-Reply-To: <a79669360510062205v629affb9ga687078f018afae@mail.gmail.com>
Hi,
> I have ported Linux kernel version 2.4.24 on MPC8266 based customized
> Board, having LXT971 ethernet chip.
> The root file system is JFFS2 which i have made using mkfs.jffs2 utility which
> comes along with the ELDK 3.0
> In the kernel code i checked that there is support for the LXT971 chip, but
> even after enabling all the network related funcuntionalities in the linux
> kernel configuration, I am either not able to ping from the board to any
> machine on the network, nor from the any other machine to the board.
> The board is able to ping itself.
> Can some one please throw some light why the board is not able to ping any
> other machine.
try to comment this line in LXT971 section of driver:
{ mk_mii_write(MII_REG_CR, 0x1200), NULL }, /* autonegotiate */
and check if it works
--
Aristeu
^ permalink raw reply
* Re: mpc8272ads support in linux-2.4
From: Vitaly Bordug @ 2005-10-07 11:57 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20051006173628.53f25862.ajz@cambridgebroadband.com>
Alex Zeffertt wrote:
> Hi list,
>
> I have read that the MPC8272ADS board is supported in linux-2.6. Has
> anybody backported this support to linux-2.4. I am using linux-2.4.25
> from ELDK. If anyone has a patch I would be very grateful if they
> sent it to me.
>
Yes, it has been supported within 2.4 tree in bitkeeper days.
The source you can rsync from source.mvista.com (take a look at
http://penguinppc.org/kernel/.
> Regards,
>
> Alex Zeffertt
>
> PS Does anyone know where the master PPC patches are kept? I.e. the
> ones you apply to kernels from kernel.org to get all the stuff that
> hasn't yet been upstreamed.
Actually answer is nowhere AFAIK. Now with git, we are working with
maintainers, and often with Andrew Morton directly, so ppc patches
usually are pushed without inbetween place unlike they used to.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: mpc8248 and FCC ethernet
From: Fillod Stephane @ 2005-10-07 11:21 UTC (permalink / raw)
To: Wojciech Kromer, linuxppc-embedded
Wojciech Kromer wrote:
[..]
>But inside kernel all RX frames are filled with 0xff data,
>also send frames I can see on the other side, are full of 0xff.
>Clocks and other FCC aware registers seems to be correct.
>The same version on linux (2_4_devel from denx.de) works fine
>on another mpc8260 board.
Most likely, you're using a wrong DPRAM range.
This reminds me this problem "All-ones problem with FCC1 on MPC8541"
=20
http://ozlabs.org/pipermail/linuxppc-embedded/2004-November/016050.html
so double check your manual. The MPC8555E manual is still wrong in
this regard, and no errata has been issued yet.
--=20
Stephane
^ permalink raw reply
* about pci net controller without EPROM onboard
From: ÏÄÓê @ 2005-10-07 10:10 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: deboralh
Thanks for the help , i found out that the kernel was not configued well for pci net card .
Now i am boarding U-BOOT and kernel(linuxppc) to my own board (based on MPC5200,have a i82551 on board without
EPROM).After i set the eth1addr ,U-boot could tftp files through the i82551 chip :
PCI: Bus Dev VenId DevId Class Int
00 18 8086 1209 0200 00
00 1a 1057 5803 0680 00
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET, i82559#0
But after the kernel bootup ,i could not find eth1 ,message during bootup as follow :
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 00:1a.0
Intel(R) PRO/100 Network Driver - version 2.3.38-k1
Copyright (c) 2004 Intel Corporation
PCI: Enabling device 00:18.0 (0006 -> 0007)
e100: Invalid Ethernet address
e100: Failed to initialize, instance #0
How can i make the chip active ?
^ permalink raw reply
* mpc8248 and FCC ethernet
From: Wojciech Kromer @ 2005-10-07 9:14 UTC (permalink / raw)
To: linuxppc-embedded
What are differences between using FCC in u-boot and kernel?
I have fine working u-boot on my new mpc8248 board,
I can sucessfully download kernel via ethernet on FCC1.
But inside kernel all RX frames are filled with 0xff data,
also send frames I can see on the other side, are full of 0xff.
Clocks and other FCC aware registers seems to be correct.
The same version on linux (2_4_devel from denx.de) works fine
on another mpc8260 board.
Any hints? Where to find differences?
What should be important to check?
^ permalink raw reply
* Re: 8260 PQ2FADS
From: vanamali gouripeddi @ 2005-10-07 7:17 UTC (permalink / raw)
To: linuxppc-embedded
hi
after the configuration and installation of binutils-2.16.1 i hav
added headers in the same tools directory now as iam trying to
configure gcc-2.95.3 the following error is displayed after the make
command
-mppc not identified
libcc2.a as one error and
stmp-multilib-sub
as the other plz provide the solution as we running out of time
On 10/7/05, linuxppc-embedded-request@ozlabs.org
<linuxppc-embedded-request@ozlabs.org> wrote:
> Send Linuxppc-embedded mailing list submissions to
> =09linuxppc-embedded@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> =09https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> or, via email, send a message with subject or body 'help' to
> =09linuxppc-embedded-request@ozlabs.org
>
> You can reach the person managing the list at
> =09linuxppc-embedded-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-embedded digest..."
>
>
> Today's Topics:
>
> 1. mpc8272ads support in linux-2.4 (Alex Zeffertt)
> 2. TKO Notice: ***Urgent Safeharbor Department Notice***
> (aw-confirm@eBay.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 6 Oct 2005 17:36:27 +0100
> From: Alex Zeffertt <ajz@cambridgebroadband.com>
> Subject: mpc8272ads support in linux-2.4
> To: linuxppc-embedded@ozlabs.org
> Message-ID: <20051006173628.53f25862.ajz@cambridgebroadband.com>
> Content-Type: text/plain; charset=3DUS-ASCII
>
> Hi list,
>
> I have read that the MPC8272ADS board is supported in linux-2.6. Has
> anybody backported this support to linux-2.4. I am using linux-2.4.25
> from ELDK. If anyone has a patch I would be very grateful if they
> sent it to me.
>
> Regards,
>
> Alex Zeffertt
>
> PS Does anyone know where the master PPC patches are kept? I.e. the
> ones you apply to kernels from kernel.org to get all the stuff that
> hasn't yet been upstreamed.
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 6 Oct 2005 16:57:36 -0400 (EDT)
> From: aw-confirm@eBay.com <aw-confirm@eBay.com>
> Subject: TKO Notice: ***Urgent Safeharbor Department Notice***
> To: linuxppc-embedded@ozlabs.org
> Message-ID: <20051006205736.38DA586FEE6@athens.9degrees.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051006/af0ff7=
7a/attachment-0001.htm
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 14, Issue 10
> *************************************************
>
^ permalink raw reply
* Problem Regarding Ping in Linux kernel version 2.4.24
From: apoorv sangal @ 2005-10-07 5:05 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: sibi_mathew, vikrant_basotra, apoorv sangal
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Hi All,
I have ported Linux kernel version 2.4.24 on MPC8266 based customized
Board, having LXT971 ethernet chip.
The root file system is JFFS2 which i have made using mkfs.jffs2 utility
which comes along with the ELDK 3.0
In the kernel code i checked that there is support for the LXT971 chip, but
even after enabling all the network related funcuntionalities in the linux
kernel configuration, I am either not able to ping from the board to any
machine on the network, nor from the any other machine to the board.
The board is able to ping itself.
Can some one please throw some light why the board is not able to ping any
other machine.
Regards
Apoorv Sangal
[-- Attachment #2: Type: text/html, Size: 845 bytes --]
^ permalink raw reply
* Re: Two bugs in handling of highmem on PPC
From: Benjamin Herrenschmidt @ 2005-10-07 0:54 UTC (permalink / raw)
To: Paolo Galtieri; +Cc: linuxppc-dev
In-Reply-To: <1128639689.4809.19.camel@playin.mvista.com>
>
> I would very much appreciate it if those of you who are more familiar
> with this part of the kernel could review and comment on my
> interpretation of what is going on and provide feedback.
While the first bit of your patch makes some sense, the second one
doesn't at all to me, you must be missing something there...
Ben
^ permalink raw reply
* Re: [PATCH] ppc32: make sure we have an L3 before touch its control register
From: Benjamin Herrenschmidt @ 2005-10-07 0:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1128644808.17365.2.camel@gaston>
On Fri, 2005-10-07 at 10:26 +1000, Benjamin Herrenschmidt wrote:
> > Dope, you're right. I notice that we apparent do this for BTIC and
> > DPM in this function though?
>
> Yes, those bits are buggy. Good catch
And no, in fact, my brain is buggy... On ppc32 we identify first, then
fixup, then only do the call_setup_cpu ! That's why the Idle NAP code
actually goes test the feature bit.
I think ppc64 does it the other way around. ppc64 certainly _requires_
taht the fixup has not yet been applied while running early_setup() as
it may change some CPU features according to firmware properties.
So in the merged kernel, we need to be extra careful here. I think we
should go the ppc64 way actually and apply the fixups later. But that
means fixing the code in cpu_setup_6xx.S indeed.
Ben.
^ permalink raw reply
* Re: [PATCH] ppc32: make sure we have an L3 before touch its control register
From: Benjamin Herrenschmidt @ 2005-10-07 0:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AFEB186E-99B9-4BE8-9AE3-315C74277483@freescale.com>
> Dope, you're right. I notice that we apparent do this for BTIC and
> DPM in this function though?
Yes, those bits are buggy. Good catch
Ben.
^ permalink raw reply
* Two bugs in handling of highmem on PPC
From: Paolo Galtieri @ 2005-10-06 23:01 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]
Folks,
in looking at the PPC code for handling highmem and it appears to me
that there are two bugs in how the data is written out by
__dma_sync_page_highmem().
The first is how the size of the first segment is calculated, and the
second is in the calculation of the number of segments to write out.
In the case of the first bug here is the code:
size_t seg_size = min((size_t)PAGE_SIZE, size) - offset;
The intent here is to determine the number of bytes you can write in the
current page given that kmap_atomic() maps pages in one at a time. The
problem with this code is depending on the values of size and offset the
result can be negative, e.g. if size is 200 and offset is 800 then:
seg_size = min(4096, 200) - 800
seg_size = 200 - 800
seg_size = -600;
At best this will cause an OOPs, but more likely a panic, when you call
__dma_sync() because your end address will be lower than the start
address. I believe the correct calculation should be:
size_t seg_size = min((size_t)(PAGE_SIZE - offset), size);
Here (PAGE_SIZE - offset) gives you the amount of space left in the page
which is really what you want to use when determining the number of
bytes you can write.
In the case of the second bug here is the code:
int nr_segs = PAGE_ALIGN(size + (PAGE_SIZE - offset))/PAGE_SIZE;
The first thing that sticks out is why is the macro PAGE_ALIGN(), which
is supposed to take an address as a parameter, being called with a size?
The problem with this code is that it returns the wrong number of
segments. For example, if size is 200 and the offset is 4095 this will
return 1 as the number of segments. This is wrong, there are in fact 2
segments to write, 1 byte in the current page and 199 bytes in the next
page. I believe the correct calculation should be:
1 + ((size - seg_size) + PAGE_SIZE - 1)/PAGE_SIZE;
The 1 represents the first segment which will always get written, the
rest represents the number of full and partial pages that need to be
written out. For example, if we have a size of 200 and an offset of
4095 then seg_size is 1 (min(4096 - 4095, 200)) so the number of
segments comes out to:
nr_segs = 1 + (200 - 1 + 4096 - 1)/4096
nr_segs = 1 + 4294/4096
nr_segs = 1 + 1
nr_segs = 2
Which is correct.
I would very much appreciate it if those of you who are more familiar
with this part of the kernel could review and comment on my
interpretation of what is going on and provide feedback.
Thank you,
Paolo Galtieri
I have attached a patch that is made against 2.6.14-rc3-git6
[-- Attachment #2: PPC-highmempatch --]
[-- Type: text/plain, Size: 678 bytes --]
--- linux-2.6.14/arch/ppc/kernel/dma-mapping.c.orig 2005-10-06 15:50:46.000000000 -0700
+++ linux-2.6.14/arch/ppc/kernel/dma-mapping.c 2005-10-06 15:51:40.000000000 -0700
@@ -401,10 +401,10 @@
static inline void __dma_sync_page_highmem(struct page *page,
unsigned long offset, size_t size, int direction)
{
- size_t seg_size = min((size_t)PAGE_SIZE, size) - offset;
+ size_t seg_size = min((size_t)(PAGE_SIZE - offset), size);
size_t cur_size = seg_size;
unsigned long flags, start, seg_offset = offset;
- int nr_segs = PAGE_ALIGN(size + (PAGE_SIZE - offset))/PAGE_SIZE;
+ 1 + ((size - seg_size) + PAGE_SIZE - 1)/PAGE_SIZE;
int seg_nr = 0;
local_irq_save(flags);
^ permalink raw reply
* Re: Starting the arch/powerpc merge
From: Paul Mackerras @ 2005-10-06 23:24 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <XFMail.20050929092052.pochini@shiny.it>
Giuliano Pochini writes:
> Out of curiosity, is there any advantage in using a 32 bits
> kernel on ppc64 over a 64 bits kernel ? Speed ? Complexity ?
> Compatibility ? Memory ?
Not really. The main thing in the past has been that DRI with 32-bit
X server and clients would work with a 32-bit kernel but not a 64-bit
kernel, but that's fixed now. A 64-bit kernel is faster on most
lmbench tests. I guess a 32-bit kernel might end up a little smaller,
but that's the only possible advantage I can think of.
Paul.
^ permalink raw reply
* TKO Notice: ***Urgent Safeharbor Department Notice***
From: aw-confirm @ 2005-10-06 20:57 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 4482 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox