Hey,
while trying to define a non-unique devalias at the Sun PROM prompt
(the SPARCclassic X has wrong aliases for scsi, disk1, etc. in the
PROM, at least mine) I fell over a bug resulting in an endless loop
while booting the kernel.
The problem is the getting the properties list of the /aliases node.
As the next element in this list is identified by name and the
function which retrieves this property always returns the first
occurrence this goes forever....
I could track down the issue to the function __prom_nextprop() in
arch/sparc/prom/tree.c, but I am now looking for the definition of
prom_nodeops->no_nextprop() without success.
My naive solution would be to return not the first but the last
occurrence of a property.
Greetings,
Markus
From: Markus Dahms <[email protected]>
Date: Mon, 20 Aug 2007 09:59:49 +0200
> I could track down the issue to the function __prom_nextprop() in
> arch/sparc/prom/tree.c, but I am now looking for the definition of
> prom_nodeops->no_nextprop() without success.
When we boot the firmware provides a vector of function
pointers, and this is prom_nodeops. So prom_nodeops->no_nextprop()
is a routine inside the PROM.
Dnia 20-08-2007 o godz. 9:59 Markus Dahms napisa?(a):
> Hey,
>
> while trying to define a non-unique devalias at the Sun PROM prompt
> (the SPARCclassic X has wrong aliases for scsi, disk1, etc. in the
> PROM, at least mine) I fell over a bug resulting in an endless loop
> while booting the kernel.
>
> The problem is the getting the properties list of the /aliases
node.
> As the next element in this list is identified by name and the
> function which retrieves this property always returns the first
> occurrence this goes forever....
>
Could you give name of the function which contains this endless loop?
When I looked into the tree.c file for the first time I thought
it had a bug
in handling the prom_nextprop, but later I concluded that this is ok.
Maybe there is a bug there after all.
Regards,
Krzysztof
----------------------------------------------------
Wielka siatk?wka we wrze?niu w Starych Jab?onkach
zobacz gwiazdy siatk?wki pla?owej na ?ywo!
Mistrzostwa ?wiata w siatk?wce pla?owej 5-9.09.2007
Kliknij: http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fstarejablonki.html&sid=1262
Krzysztof Helt wrote,
> Could you give name of the function which contains this endless loop?
> When I looked into the tree.c file for the first time I thought
> it had a bug
> in handling the prom_nextprop, but later I concluded that this is ok.
> Maybe there is a bug there after all.
if I understood it correctly the following functions are called in this
order:
* prom_init() # arch/sparc/kernel/head.S
[...]
* create_node() # arch/sparc/kernel/prom.c
* build_prop_list() # arch/sparc/kernel/prom.c
* build_one_prop() # arch/sparc/kernel/prom.c
* prom_nextprop() # arch/sparc/prom/tree.c
* __prom_nextprop() # arch/sparc/prom/tree.c
* prom_nodeops->no_nextprop() # PROM
And this loops while getting the attributes/properties of the /aliases
node.
Greetings,
Markus
Hello again,
David Miller wrote:
> When we boot the firmware provides a vector of function
> pointers, and this is prom_nodeops. So prom_nodeops->no_nextprop()
> is a routine inside the PROM.
Thanks. So there is no real chance to fix it but to override this
function?
The strange thing is that the PROM prompt handles it correctly:
| ok devalias scsi /iommu/sbus/espdma/esp
| scsi isn't unique
| ok cd /aliases
| ok .attributes
| scsi /iommu/sbus/espdma/esp
| screen /iommu@0,10000000/sbus@0,10001000/cgthree@3,0
| net-g net:,SUNXT_KERNEL.SUN4M
| ttyb /obio/zs@0,100000:b
| ttya /obio/zs@0,100000:a
| keyboard! /obio/zs@0,0:forcemode
| keyboard /obio/zs@0,0
| floppy /obio/SUNW,fdtwo
| scsi /iommu/sbus/espdma@4,8400000/esp@4,8800000
| net-aui /iommu/sbus/ledma@4,8400010:aui/le@4,8c00000
| net-tpe /iommu/sbus/ledma@4,8400010:tpe/le@4,8c00000
| [...]
| name aliases
Linux PROM initialization goes this way:
| scsi
| screen
| net-g
| ttyb
| ttya
| keyboard!
| keyboard
| floppy
| scsi
| screen
| net-g
[...]
As I'm not sure anymore whether the device tree (show-devs) or the aliases
(devalias) are broken on the Classic X (I "upgraded" mine to a Classic by
changing some NVRAM bytes) this may be a non-issue. But it is still an
endless loop where it don't has to be.
Markus
Markus Dahms wrote:
>Hello again,
>
>David Miller wrote:
>
>
>>When we boot the firmware provides a vector of function
>>pointers, and this is prom_nodeops. So prom_nodeops->no_nextprop()
>>is a routine inside the PROM.
>>
>>
>
>Thanks. So there is no real chance to fix it but to override this
>function?
>The strange thing is that the PROM prompt handles it correctly:
>
>| ok devalias scsi /iommu/sbus/espdma/esp
>| scsi isn't unique
>
>
Non-unique devalias entries are NASTY. Get rid of them, for example
your second definition of scsi could be changed to scsidisk.
You should also check that any nvramrc entries do not cause conflicts,
it is common for nvramrc entries to refer to devalias entries, so you
may need to also change an nvramrc entry to match any devalias change.
You can disable the use of nvramrc from the OBP prompt with
setenv if the entry isnon-essential, they are most commonly used
where there is a mirrored root disk.
Hi,
>> | ok devalias scsi /iommu/sbus/espdma/esp
>> | scsi isn't unique
> Non-unique devalias entries are NASTY. Get rid of them, for example
> your second definition of scsi could be changed to scsidisk.
Yes, it is nasty and I don't really want to use it. But it is possible
and IMHO Linux should handle it one way or the other.
Originally I tried to workaround an Oops in esp on the Classic X which
I connected to some broken PROM entries. The PROM booted from SCSI disk
(using another device path as the scsi aliases are broken or so), but
Linux crashes on loading the SCSI driver. As already said now I use the
"recommended workaround": patching the Classic X to be a Classic.
Markus
On Mon, 20 Aug 2007 12:53:20 +0200
Markus Dahms <[email protected]> wrote:
> Hello again,
> As I'm not sure anymore whether the device tree (show-devs) or the aliases
> (devalias) are broken on the Classic X (I "upgraded" mine to a Classic by
> changing some NVRAM bytes) this may be a non-issue. But it is still an
> endless loop where it don't has to be.
>
I understand your problem now. The only rational solution is
to stop building the list in the build_one_prop() if the property
with already found name is defined.
Changing way the *_nextprop() works seems not a good
idea to me.
My two cents,
Krzysztof