* Re: uboot environment variables size for Yosemite board.
From: Wolfgang Denk @ 2006-07-17 7:00 UTC (permalink / raw)
To: Leonid; +Cc: linuxppc-embedded
In-Reply-To: <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net>
In message <FAB00A8DC59FAB42B13C2B3B0F6877010D14478B@ehost011-3.exch011.intermedia.net> you wrote:
>
> I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
Note that this is off topic here. You should have posted this on the
U-Boot-Users mailing list instead.
> this uboot from DENX site. It uses EEPROM to store environment
> variables. Since EEPROM on Yosemite board is only 512 bytes, there can
> not be more environment variables which is not very convenient.
Thisi s wrong. The Yosemite configuration uses (like most (all?) AMCC
eval boards - two redundand flash sectors to store the environment.
And available environment size is 8 kB:
=> print
...
Environment size: 1355/8187 bytes
> There is theoretical possibility to save these variables on flash (64M
> from which I use only part) and yosemite.h header file even has defines,
> allowing this option. But is it going work in reality? What is simplest
> way for Yosemite board to increase environment variables storage space?
I have no idea where you got your board configuration from, but it is
definitely not current code, nor the binary image at
ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/u-boot.bin
The current code does use (redundand) flash for environment storage.
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
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
^ permalink raw reply
* Re: [PATCH] powerpc: simplify dma_ops bug conditions
From: Muli Ben-Yehuda @ 2006-07-17 6:31 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <20060717062825.GA18291@rhun.ibm.com>
On Mon, Jul 17, 2006 at 01:55:09PM +1000, Jeremy Kerr wrote:
> No, it's not really necessary, more a style thing. The BUG_ON only adds
> an extra 3 instructions (subfic, addi and tdnei), which should be tiny
> compared to the indirect branch.
When we were submitting a patch to add a
BUG_ON(!valid_dma_data_direction(dir)) to x86-64's DMA-API, Jeff
Garzik was vehemently opposed to adding a few instructions to "one of
the hottest paths in the kernel".
Cheers,
Muli
^ permalink raw reply
* Re: how to get individual patches
From: Grant Likely @ 2006-07-17 5:30 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44BB080E.6060107@dlasys.net>
On 7/16/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> The zlib library was updated within the past month.
> The new zlib code does not work in my environment.
> I have guesses as to why, but I am not a zlib expert and not looking
> to be one.
> I have solved my personal problem by reverting to the older zlib code.
> With that I have 2.6.18-rc4 or whatever is in the linux-2.6 git tree
> as of today working for me.
> I was stuck at 2.6.16.21 before.
>
> So my questions:
>
> How/where do I report a problem ? I would be perfectly happy to help
> whoever is responsible for zlib to work this out.
> But I am not up to doing it myself.
Once you've got the patch extracted (see below); post it to the lkml
with a description of your symptoms and what you are trying to do.
(or post it here, and if nobody knows; then move over to the lkml)
>
> git bisect got me down to a good/bad scenario. But I could not
> provoke git to either pull the offending patch or export the change as a
> patch so that I could back it out myself.
> Now that the final git bisect screen is gone all I have (besides a
> fixed 2.6.18-xx kernel) is I guess the sha has number for the particular
> commit.
git-format-patch <good_sha1>..<bad_sha1>
for example:
$ git-format-patch
0ce030395b92270567423d57d9d432eb77df32f2..8d92bc2270d67a43b1d7e94a8cb6f81f1435fe9a
0001-PCI-Error-handling-on-PCI-device-resume.txt
extracts a single patch file for the
PCI-Error-handling-on-PCI-device-resume.txt commit. If there are more
than one commits between <good_sha1> and <bad_sha1>, then you'll get
more than one patch file extracted.
Then, you can apply the patch reversed to backout the change.
> I suspect that would have been enough to yank just that patch but I
> googled every permutation of git backout or similar things I could think
> of and browsed the git tutorials etc.
> and could not seem to decipher how to do anything usefull with the
> sha id of a single patch.
"git-log <sha1>" will give you the history starting at a particular
commit, which is useful for finding the next commit after it for doing
the git-format-patch command.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* uboot environment variables size for Yosemite board.
From: Leonid @ 2006-07-17 5:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Hi:
I'm using uboot-1.1.4 for AMCC PPC440E Yosemite board. I've downloaded
this uboot from DENX site. It uses EEPROM to store environment
variables. Since EEPROM on Yosemite board is only 512 bytes, there can
not be more environment variables which is not very convenient.
There is theoretical possibility to save these variables on flash (64M
from which I use only part) and yosemite.h header file even has defines,
allowing this option. But is it going work in reality? What is simplest
way for Yosemite board to increase environment variables storage space?
Thanks,
Leonid.
[-- Attachment #2: Type: text/html, Size: 3286 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: simplify dma_ops bug conditions
From: Jeremy Kerr @ 2006-07-17 3:55 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060713063947.GD5096@rhun.ibm.com>
Muli,
> Is the BUG_ON() necessary? the next line just goes and deref's it,
> which should lead to a shiny NULL pointer deref.
No, it's not really necessary, more a style thing. The BUG_ON only adds
an extra 3 instructions (subfic, addi and tdnei), which should be tiny
compared to the indirect branch.
Also, it makes it a little easier for a user to understand: "there's a
bug in the kernel" vs. "invalid memory access".
Jeremy
^ permalink raw reply
* Re: how to get individual patches
From: David H. Lynch Jr. @ 2006-07-17 3:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0607141122t53adeb30h8c2acb4e26ba0ddf@mail.gmail.com>
Grant Likely wrote:
> On 7/14/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
> AFAIK, yes you will have to repatch every time; I typically write a
> little helper script to lessen the pain:
>
> git bisect good|bad # depends on whether it works or not
> patch < [patchfile]
> compile, test, etc
> cg restore -f # Remove the patches
> git bisect good|bad # lather, rinse, repeate
>
Alright, I have bisected my way down to the problem.
Well sort of.
I think the real problem I started looking for eventually got fixed
in the kernel tree on its own.
But I did find a real problem. I have found my own work around - but
this problem may effect others.
The zlib library was updated within the past month.
The new zlib code does not work in my environment.
I have guesses as to why, but I am not a zlib expert and not looking
to be one.
I have solved my personal problem by reverting to the older zlib code.
With that I have 2.6.18-rc4 or whatever is in the linux-2.6 git tree
as of today working for me.
I was stuck at 2.6.16.21 before.
So my questions:
How/where do I report a problem ? I would be perfectly happy to help
whoever is responsible for zlib to work this out.
But I am not up to doing it myself.
git bisect got me down to a good/bad scenario. But I could not
provoke git to either pull the offending patch or export the change as a
patch so that I could back it out myself.
Now that the final git bisect screen is gone all I have (besides a
fixed 2.6.18-xx kernel) is I guess the sha has number for the particular
commit.
I suspect that would have been enough to yank just that patch but I
googled every permutation of git backout or similar things I could think
of and browsed the git tutorials etc.
and could not seem to decipher how to do anything usefull with the
sha id of a single patch.
I am sure that is a knowledge problem.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Geoff Thorpe @ 2006-07-17 3:28 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Olof Johansson, linuxppc-dev, Stephen Rothwell, linuxppc-embedded
In-Reply-To: <20060716151246.94C9C352681@atlas.denx.de>
Wolfgang Denk wrote:
>Please don't try to reinvent Usenet netiquette, poorly.
>
Begging your pardon, sire. Thanks for the adverb too btw, quite a bonus
- amusing, albeit poorly.
And speaking of which...
>Commercial
>ads, job ofers and the like have always been banned. It's just lately
>that nobody remembers the good old days any more and everybody thinks
>he can force his ideas over everybody else.
>
>
?! Whoah, if that's the nature of the discussion, fine - count me out.
Oh, and FYI - the good old days also involved rock musicians in spandex,
and ... well ... whatever. If you were referring to me, then I retract
any such "force" without hesitation - because until you told me
otherwise, I was entirely ignorant to its existence. To be honest, I'm
still not sure *what* force you're talking about, but I'll take your
word for it.
And while I'm at it, the next time you throw a dart, I sure hope it at
least hits the dart-board - there's nothing more uncomfortable than
having to apologise to an unknown, uninterested, and uninvolved
bystander who has a dart sticking out of his forehead just for having
been in the room. But for what it's worth, "oh don't be silly, no
apology necessary". :-)
>If there is demand for job offer postings, then these should be
>handled on a separate mailing list.
>
>
If you say so, I never really liked playing darts anyway, stupid game -
too many people holding sharp instruments they have too little control over.
Cheers,
Geoff
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Luke Browning @ 2006-07-17 2:02 UTC (permalink / raw)
To: Anton Blanchard
Cc: linuxppc-dev-bounces+lukebrowning=us.ibm.com, Arnd Bergmann,
Bryan S Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh,
Paul Mackerras
In-Reply-To: <20060715153053.GK31081@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
linuxppc-dev-bounces+lukebrowning=us.ibm.com@ozlabs.org wrote on
07/15/2006 12:30:54 PM:
>
> > What happened to the question whether to use PURR values for also
measuring
> > cycles spent executing the hcall as opposed to cycles that passed
before
> > the hcall returns. Did that turn out not giving extra information
after all
> > or was there a different reason to drop that idea?
>
> You have to be careful with PURR since it may be context switched
> between partitions.
>
That shouldn't be an issue as the PURR is supposed to be virtualized by
PHYP at
the virtual processor level.
Luke
[-- Attachment #2: Type: text/html, Size: 828 bytes --]
^ permalink raw reply
* Re: Kexec initial registers
From: Michael Ellerman @ 2006-07-17 1:22 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <28C15305-BE9F-4EE7-93A2-437EAEA7B886@watson.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]
On Sat, 2006-07-15 at 22:10 -0400, Jimi Xenidis wrote:
> On Jul 14, 2006, at 5:08 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2006-07-14 at 12:02 -0400, Jimi Xenidis wrote:
> >> This is what I have so far:
> >>
> >> r3: address of device tree blob
> >> r4: address that kernel was loaded
> >> r5: not OF (=0)
> >
> > Correct and that's all that should be needed
> >
> >> r13: local_paca address (0?)
> >
> > You shouldn't have to care about r13 at all, it should be set by the
> > kernel before it's used. If not, please let us know as that means
> > there
> > is a bug :)
>
> Not! 99.99% :)
> When loading a kernel under Xen using kexec we set r1-r5 and set all
> other GPRS to all 5's (cuz we can) with CONFIG_PPC_EARLY_DEBUG=y and
> all hell breaks loose in the first printk()/DBG() from early_setup()
> for:
> kernel/printk.c:506
> 506 spin_lock_irqsave(&logbuf_lock, flags);
>
> where is access local_paca.
There should be a call to setup_paca(0) in early_setup() _before_ the
first printk/DBG. That patch is pretty new though, so you might not have
it yet.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: David H. Lynch Jr. @ 2006-07-17 1:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060716151246.94C9C352681@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]
Wolfgang Denk wrote:
> In message <44B7E508.7020700@freescale.com> you wrote:
>
>> otherwise unnoticed). Hell, if the subject header was appropriately
>> keyworded - Wolfgang could even procmail it to /dev/null ;-)
>>
>
> Please don't try to reinvent Usenet netiquette, poorly. Commercial
> ads, job ofers and the like have always been banned. It's just lately
> that nobody remembers the good old days any more and everybody thinks
> he can force his ideas over everybody else.
>
Atleast where I am reading it this is a mailing list not Usenet.
Each group/list has always had its own acceptable use policies.
I can trivially think of several with vastly different ones than
linuxppc-embedded.
And there are still flamewars over minor issues of netiquette.
There are many many things wrong with the internet today - but as
with everything else - the good old days often look better after the fact.
I do not know how long linuxppc-embedded has been arround, but I am
certain if you go back far enough there were not enough people with
internet access and the appropriate skills to form many of the focused
lists we have today.
5 years ago, I got much less spam than today. But 5 years ago, I
could not throw away all my reference books and just use google and
other search engines to look up virtually anything.
Today, the problem is not so much getting an answer to a question,
but finding the answer in the noise.
I do not want to dwell on this - I am prone to pine for the good old
days myself. I can rant about plenty of modern evils in the internet and
elsewhere. But I do nto trully want to go back. I want what I have now
AND some of what I had then.
One of the things I want out of the internet NOW, is tools to help
me persue my dreams and my lifestyle.
Wolfgang, seems to have gotten there before me, built the skills,
contacts, and reputation and I hope he is doing well. I had been doing
other things with my life and they did nto work out.
Now I am trying to parlay my skills into consulting work that lets
me do the work I want and keep the lifestyle I want.
Only I do not have the 25 years of industry contacts I would have
had I taken a different route, and I want to use the internet as a means
to mitigate that.
I have no problems banning job posting from this list.
But I do beleive there needs to be some place for them.
Personally I would like to see separate lists for traditional "jobs"
and consulting - with recruiters and contract employment postings banned
from the latter.
But I will live with whatever comes about.
> If there is demand for job offer postings, then these should be
> handled on a separate mailing list.
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 4427 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Olof Johansson @ 2006-07-16 23:09 UTC (permalink / raw)
To: Luke Browning
Cc: Arnd Bergmann, Bryan S Rosenburg, linuxppc-dev, Paul Mackerras,
Christopher Yeoh, Nathan Lynch
In-Reply-To: <OFFBAD5953.E17A24C8-ON832571AD.007DA01D-832571AD.007DBBB5@us.ibm.com>
On Sun, Jul 16, 2006 at 08:53:21PM -0200, Luke Browning wrote:
> > Just so people don't forget: this can't be done on all processors. For
> > example, PPC970 and POWER4 don't implement the PURR SPR. And it doesn't
> > make sense to use H_PURR to get the software emulated ones there. Not
> > really an issue on POWER4 since they don't do shared processor LPAR, but
> > on JS21 I think they might do?
> >
> Isn't there someway to do a platform specific processor overlay, where you
> get PURR if it exists and TB otherwise.
Sure, it's what we have cpu feature bits for. It's not a difficult
problem to solve, I was just reminding of the lack of SPRN_PURR on some
processors that can run hypervisors.
-Olof
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Luke Browning @ 2006-07-16 23:02 UTC (permalink / raw)
To: Anton Blanchard
Cc: linuxppc-dev-bounces+lukebrowning=us.ibm.com, Arnd Bergmann,
Bryan S Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh,
Paul Mackerras
In-Reply-To: <20060715220757.GA31511@krispykreme>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
linuxppc-dev-bounces+lukebrowning=us.ibm.com@ozlabs.org wrote on
07/15/2006 07:07:58 PM:
>
> > Not sure I follow you. I would expect the PURR value to be restored
after
> > a context switch, even if we continue on a different physical CPU.
> >
> > The idea behind monitoring both PURR and timebase is that the
difference
> > between the two tells you how long the partition was suspended during
> > the hcall.
>
> Sounds good, last time I looked at the patch I thought it was gathering
> the PURR only. That on its own would make for some confusing results.
>
It would be more efficient to have a separate trace log for PHYP
dispatches as
there are many more hypervisor calls than PHYP dispatches. I believe PHYP
provides
a trace records for dispatches, which could be seperately written. Perf
tools can
assemble the information from multiple records. It would be nice to have
processor
specific time function that reads either PURR or TB based on the platform.
Luke
[-- Attachment #2: Type: text/html, Size: 1376 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Luke Browning @ 2006-07-16 22:53 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev-bounces+lukebrowning=us.ibm.com, Arnd Bergmann,
Bryan S Rosenburg, linuxppc-dev, Nathan Lynch, Christopher Yeoh,
Paul Mackerras
In-Reply-To: <20060716035353.GA5266@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
linuxppc-dev-bounces+lukebrowning=us.ibm.com@ozlabs.org wrote on
07/16/2006 12:53:54 AM:
> On Sat, Jul 15, 2006 at 02:00:02AM +0200, Arnd Bergmann wrote:
>
> > What happened to the question whether to use PURR values for also
measuring
> > cycles spent executing the hcall as opposed to cycles that passed
before
> > the hcall returns. Did that turn out not giving extra information
after all
> > or was there a different reason to drop that idea?
>
> Just so people don't forget: this can't be done on all processors. For
> example, PPC970 and POWER4 don't implement the PURR SPR. And it doesn't
> make sense to use H_PURR to get the software emulated ones there. Not
> really an issue on POWER4 since they don't do shared processor LPAR, but
> on JS21 I think they might do?
>
Isn't there someway to do a platform specific processor overlay, where you
get PURR if it exists and TB otherwise.
Luke
[-- Attachment #2: Type: text/html, Size: 1129 bytes --]
^ permalink raw reply
* [PATCH] aoa: fix feature-call GPIO layer
From: Johannes Berg @ 2006-07-16 20:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Per Christian Henden, paulus, linuxppc-dev
In-Reply-To: <1153065707.5905.8.camel@localhost.localdomain>
I hope this isn't too badly mangled... I'm without a proper mail client
right now because my ~ is corrupted enough to be put offline once I access
it a lot :/ I intend to repair this tomorrow, so if it is mangled I can
resend Tuesday.
---
This fixes the feature-call GPIO layer in snd-aoa which is used on
machines without platform functions so that it doesn't try to look up an
interrupt property for detect device nodes that don't exist.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Index: linux-2.6-fetch/sound/aoa/core/snd-aoa-gpio-feature.c
===================================================================
--- linux-2.6-fetch.orig/sound/aoa/core/snd-aoa-gpio-feature.c 2006-07-16
22:10:02.467630929 +0200
+++ linux-2.6-fetch/sound/aoa/core/snd-aoa-gpio-feature.c 2006-07-16
22:13:41.891630929 +0200
@@ -112,7 +112,10 @@ static struct device_node *get_gpio(char
static void get_irq(struct device_node * np, int *irqptr)
{
- *irqptr = irq_of_parse_and_map(np, 0);
+ if (np)
+ *irqptr = irq_of_parse_and_map(np, 0);
+ else
+ *irqptr = NO_IRQ;
}
/* 0x4 is outenable, 0x1 is out, thus 4 or 5 */
@@ -322,7 +325,7 @@ static int ftr_set_notify(struct gpio_ru
return -EINVAL;
}
- if (irq == -1)
+ if (irq == NO_IRQ)
return -ENODEV;
mutex_lock(¬if->mutex);
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Olaf Hering @ 2006-07-16 19:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1153079015.5905.39.camel@localhost.localdomain>
On Sun, Jul 16, Benjamin Herrenschmidt wrote:
> > It crashes later for different reasons. The whole init process works by
> > luck it seems.
>
> I've been having weird things happening with latest linus trees and
> really no time to debug ... do you have a backtrace for the "other"
> crash ?
It was in aty128_bl_set_power(), cant remember the trace.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Benjamin Herrenschmidt @ 2006-07-16 19:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060716192727.GA17387@suse.de>
On Sun, 2006-07-16 at 21:27 +0200, Olaf Hering wrote:
> On Sun, Jul 16, Benjamin Herrenschmidt wrote:
>
> >
> > > Yeah, that looks like some serious bogosity in that code. Care to send a
> > > patch ?
> >
> > (I'm in a hotel room in Ottawa with no r128 at hand to test so I'm not
> > doing it myself just now :)
>
> It crashes later for different reasons. The whole init process works by
> luck it seems.
I've been having weird things happening with latest linus trees and
really no time to debug ... do you have a backtrace for the "other"
crash ?
Ben.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Olaf Hering @ 2006-07-16 19:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1153077953.5905.37.camel@localhost.localdomain>
On Sun, Jul 16, Benjamin Herrenschmidt wrote:
>
> > Yeah, that looks like some serious bogosity in that code. Care to send a
> > patch ?
>
> (I'm in a hotel room in Ottawa with no r128 at hand to test so I'm not
> doing it myself just now :)
It crashes later for different reasons. The whole init process works by
luck it seems.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Benjamin Herrenschmidt @ 2006-07-16 19:25 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1153077550.5905.33.camel@localhost.localdomain>
> Yeah, that looks like some serious bogosity in that code. Care to send a
> patch ?
(I'm in a hotel room in Ottawa with no r128 at hand to test so I'm not
doing it myself just now :)
Ben.
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Benjamin Herrenschmidt @ 2006-07-16 19:19 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060716165004.GA16369@suse.de>
On Sun, 2006-07-16 at 18:50 +0200, Olaf Hering wrote:
> On Sun, Jul 16, Olaf Hering wrote:
>
> >
> > Current Linus tree crashes in aty128_set_lcd_enable() because par->pdev
> > is NULL. This happens since at least a week. Call trace is:
> >
> > aty128_set_lcd_enable
> > aty128fb_set_par
> > fbcon_init
> > visual_init
> > take_over_console
> > fbcon_takeover
> > notifier_call_chain
> > blocking_notifier_call_chain
> > register_framebuffer
> > aty128fb_probe
>
> aty128_init calls register_framebuffer() before it assigns pdev.
Yeah, that looks like some serious bogosity in that code. Care to send a
patch ?
> 2028 if (register_framebuffer(info) < 0)
> 2029 return 0;
> 2030
> 2031 par->pm_reg = pci_find_capability(pdev, PCI_CAP_ID_PM);
> 2032 par->pdev = pdev;
> 2033 par->asleep = 0;
> 2034 par->lock_blank = 0;
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: crash in aty128_set_lcd_enable on PowerBook
From: Olaf Hering @ 2006-07-16 16:50 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
In-Reply-To: <20060716163728.GA16228@suse.de>
On Sun, Jul 16, Olaf Hering wrote:
>
> Current Linus tree crashes in aty128_set_lcd_enable() because par->pdev
> is NULL. This happens since at least a week. Call trace is:
>
> aty128_set_lcd_enable
> aty128fb_set_par
> fbcon_init
> visual_init
> take_over_console
> fbcon_takeover
> notifier_call_chain
> blocking_notifier_call_chain
> register_framebuffer
> aty128fb_probe
aty128_init calls register_framebuffer() before it assigns pdev.
2028 if (register_framebuffer(info) < 0)
2029 return 0;
2030
2031 par->pm_reg = pci_find_capability(pdev, PCI_CAP_ID_PM);
2032 par->pdev = pdev;
2033 par->asleep = 0;
2034 par->lock_blank = 0;
^ permalink raw reply
* crash in aty128_set_lcd_enable on PowerBook
From: Olaf Hering @ 2006-07-16 16:37 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Current Linus tree crashes in aty128_set_lcd_enable() because par->pdev
is NULL. This happens since at least a week. Call trace is:
aty128_set_lcd_enable
aty128fb_set_par
fbcon_init
visual_init
take_over_console
fbcon_takeover
notifier_call_chain
blocking_notifier_call_chain
register_framebuffer
aty128fb_probe
pci_device_probe
bus_for_each_dev
driver_attach
bus_add_driver
driver_register
__pci_register_driver
aty128fb_init
init
kernel_thread
This happens on a PowerBook pismo.
^ permalink raw reply
* Re: Kexec initial registers
From: Benjamin Herrenschmidt @ 2006-07-16 16:18 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <1153065556.5905.4.camel@localhost.localdomain>
> > I think everyone else (ot just the sane ones) just sets all GPRS to 0
>
> Then we have a bug and we need to initialize local_paca before we call
> early_setup...
Ah ok, I see that things have changed a bit there ... well, we do have a
setup_paca(0) after the first DBG() so that should work.
Really, it's the kernel job to setup r13 before it has any use for it.
The kexec interface only specifies what is in r3..r5, everything else
can be 0xDEADBEEF as far as I'm concerned
Ben.
^ permalink raw reply
* Re: Kexec initial registers
From: Benjamin Herrenschmidt @ 2006-07-16 15:59 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <28C15305-BE9F-4EE7-93A2-437EAEA7B886@watson.ibm.com>
On Sat, 2006-07-15 at 22:10 -0400, Jimi Xenidis wrote:
> On Jul 14, 2006, at 5:08 PM, Benjamin Herrenschmidt wrote:
>
> > On Fri, 2006-07-14 at 12:02 -0400, Jimi Xenidis wrote:
> >> This is what I have so far:
> >>
> >> r3: address of device tree blob
> >> r4: address that kernel was loaded
> >> r5: not OF (=0)
> >
> > Correct and that's all that should be needed
> >
> >> r13: local_paca address (0?)
> >
> > You shouldn't have to care about r13 at all, it should be set by the
> > kernel before it's used. If not, please let us know as that means
> > there
> > is a bug :)
>
> Not! 99.99% :)
> When loading a kernel under Xen using kexec we set r1-r5 and set all
> other GPRS to all 5's (cuz we can) with CONFIG_PPC_EARLY_DEBUG=y and
> all hell breaks loose in the first printk()/DBG() from early_setup()
> for:
> kernel/printk.c:506
> 506 spin_lock_irqsave(&logbuf_lock, flags);
>
> where is access local_paca.
>
> I think everyone else (ot just the sane ones) just sets all GPRS to 0
Then we have a bug and we need to initialize local_paca before we call
early_setup...
Ben.
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Wolfgang Denk @ 2006-07-16 15:12 UTC (permalink / raw)
To: Geoff Thorpe
Cc: Olof Johansson, linuxppc-dev, Stephen Rothwell, linuxppc-embedded
In-Reply-To: <44B7E508.7020700@freescale.com>
In message <44B7E508.7020700@freescale.com> you wrote:
>
> otherwise unnoticed). Hell, if the subject header was appropriately
> keyworded - Wolfgang could even procmail it to /dev/null ;-)
Please don't try to reinvent Usenet netiquette, poorly. Commercial
ads, job ofers and the like have always been banned. It's just lately
that nobody remembers the good old days any more and everybody thinks
he can force his ideas over everybody else.
If there is demand for job offer postings, then these should be
handled on a separate mailing list.
Best regards,
Wolfgang Denk
--
You young'uns. That was *long* before AltaVista, DejaNews, or even
(gasp) the *Web*! In fact, we typed that thread on steam-powered card
punchers, and shipped it around via Pony Express.
-- Randal Schwartz in <8cwww1cd0d.fsf@gadget.cscaper.com>
^ permalink raw reply
* Re: some problems on the SystemACE driver.
From: Ming Liu @ 2006-07-16 13:17 UTC (permalink / raw)
To: ammubhai; +Cc: linuxppc-embedded
In-Reply-To: <44BA09A1.50908@gmail.com>
Dear Ameet,
Good news! This time, it works well and no error during the compilation
process. Finally we solved this sucking problem! Congratulations to us!
I have tried the kernel. It works well for the SystemACE driver, although I
have not successfully made Temac work well. It shows that the network is
disconnected and there is no device symbol in /dev directory. I think I
should make this device in /dev manually and make it recognizable for
Linux, right? If any guidance, please feel free to tell me. Thanks in
advance.
> I know this might be very tedious for you. But its the same for me
>especially when there is no need for me to do it.
I will not feel it tedious because 1. in this process I can learn a lot; 2.
it's really useful for me. :-) So I would like to consume time on that.
Also, you are really helpful for my project. So if possible, I would like
to cooperate with you and do something meanningful together.
Thanks again for all your help and hard work recently.
Regards
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ 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