headers
Nguyen Dang Phuoc Dong | 2 May 2004 13:12
Picon

pci_pool_free() bug ?!

Hi folks,

I'm testing usb camera on SH3-DSP platform (SH7727RP). Although this
platform does not have PCI, but it support some API such as pci_pool_xxx(),
pci_alloc_consistent(), pci_free_consistent(), ... My cam is OV511 with
sensor OV7620. My kernel is 2.4.18

I use vidcat to test. It crashed after captured a few images. I could see
some kernel messages:

reserved instruction: 0180

PC  : 8c00bd50 SP  : 8c13beb8 SR  : 400001f1 TEA : 295c31c0    Not tainted
R0  : 00000018 R1  : 00000000 R2  : 00000005 R3  : 000000f0
R4  : 00000018 R5  : 00000040 R6  : 00000040 R7  : 8c17c0b0
R8  : 00000018 R9  : 8df2c210 R10 : 8c1f7fe0 R11 : ade6c600
R12 : 00000000 R13 : fffffffb R14 : adff0800
MACH: 00006fb5 MACL: 00053a64 GBR : cf224caf PR  : 8c00bd3e
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

I use sh3-linux-objdump to check the kernel and I could find the bug is in
pci_pool_free() function, the bug is caused by this instruction:

8c00bd50:       2d 41           shld    r2,r1

Kernel also said "reserved instruction: 0180", I guessed that it is
generated by a trap. But i'm not sure. I show you more detail below :)

8c00bd10 <pci_pool_free>:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Fabio Giovagnini | 4 May 2004 09:02
Picon

Hi everybody, just a question about SH5

Hi folks,

could anyone tell me if I could now to design a board based on Renesas Sh5? Is 
it possible to buy in Europe such a chip? What about the evaluation board?

Thanks a lot

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
Permalink | Reply | 3 comments |
headers
Boyd Moffat | 4 May 2004 12:32

RE: Hi everybody, just a question about SH5

Fabio,

Renesas have SH-5 on their roadmap but no availability of a standard part.

SuperH have availability of evaluation boards, tools etc. depending on your
requirements.

If you can let me know what you are after I can perhaps advise better.

Regards
Boyd

> -----Original Message-----
> From: linuxsh-dev-admin <at> lists.sourceforge.net 
> [mailto:linuxsh-dev-admin <at> lists.sourceforge.net] On Behalf Of 
> Fabio Giovagnini
> Sent: Tuesday, May 04, 2004 8:02 AM
> To: linuxsh-dev <at> lists.sourceforge.net; linux-sh <at> m17n.org
> Subject: [linuxsh-dev] Hi everybody, just a question about SH5
> 
> 
> Hi folks,
> 
> could anyone tell me if I could now to design a board based 
> on Renesas Sh5? Is 
> it possible to buy in Europe such a chip? What about the 
> evaluation board?
> 
> Thanks a lot
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fabio Giovagnini | 4 May 2004 12:56
Picon

Re: Hi everybody, just a question about SH5

ok. Now I do a check list of my real need and I'll send you it so you can 
suggest me the beast way fo follow.

Thanks a lot for your quick answer.

Fabio

On Tuesday 04 May 2004 12:32, Boyd Moffat wrote:
> Fabio,
>
> Renesas have SH-5 on their roadmap but no availability of a standard part.
>
> SuperH have availability of evaluation boards, tools etc. depending on your
> requirements.
>
> If you can let me know what you are after I can perhaps advise better.
>
> Regards
> Boyd
>
> > -----Original Message-----
> > From: linuxsh-dev-admin <at> lists.sourceforge.net
> > [mailto:linuxsh-dev-admin <at> lists.sourceforge.net] On Behalf Of
> > Fabio Giovagnini
> > Sent: Tuesday, May 04, 2004 8:02 AM
> > To: linuxsh-dev <at> lists.sourceforge.net; linux-sh <at> m17n.org
> > Subject: [linuxsh-dev] Hi everybody, just a question about SH5
> >
> >
> > Hi folks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Bennee | 4 May 2004 19:08

SH SCI output weirdness...

Hi,

I'm giving the 2.6 kernel a spin on my ST40 based hardware and I'm
seeing some weird output from the serial port. The following output
comes from straight boot, however if I step though the initialisation
via gdb the output comes out ok. My initial suspicion was a buffer
overflow for the serial driver. However a 2.4 boot has a similar amount
of diags and gives no such problems. also I'm running at 57600 so its
hard to imagine the diags being overrun.

Has anyone else seen any output like this? I'm hoping so otherwise its
likely some sort of weird memory corruption..... 

Boot log:

....
SuperH SCI(F) driver initialized
ttySC0 at MMIO 0xffe00000 (irq = 26) is a scif
ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
Linux Tulip driver version 1.1.13 (May 11, 2002)
eth0: ADMtek Comet rev 161 at 0xa0000100, 00:12:45:34:12:AA, IRQ 3.
NET: Registered protocol f`xfIP: routing cache hash table of 512
buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
NET: Registered protocol fam`fxfeth0: tulip_up(), affxIP-Config:
Complete:
      device=eth0, addr=192.168.0.230, mask=255.255.255.0,
gw=192.168.0.250,
     host=192.168.0.230, domain=, nis-domain=(none),
     bootserver=192.168.0.251, rootserver=192.168.0.251, rootpath=
(Continue reading)

Permalink | Reply | 17 comments |
headers
Stuart MENEFY | 4 May 2004 22:48

Re: [linux-sh:03224] SH SCI output weirdness...

On Tue, 04 May 2004 18:08:46 +0100 Alex Bennee <kernel-hacker <at> bennee.com> wrote:

> Hi,
> 
> I'm giving the 2.6 kernel a spin on my ST40 based hardware and I'm
> seeing some weird output from the serial port. The following output
> comes from straight boot, however if I step though the initialisation
> via gdb the output comes out ok. My initial suspicion was a buffer
> overflow for the serial driver. However a 2.4 boot has a similar amount
> of diags and gives no such problems. also I'm running at 57600 so its
> hard to imagine the diags being overrun.
> 
> Has anyone else seen any output like this? I'm hoping so otherwise its
> likely some sort of weird memory corruption..... 

Yes, I've seen it, and much head scratching it caused.

The problem is the idle loop has been modified to call cpu_relax(), and
cpu_relax() now includes a "sleep" instruction. The hlt_counter, although
still present, is ignored.

On the ST40, with the default power management configuration, this appears
to try and power down or reduce the clock speed of the serial port. So any
data still in the FIFO gets corrupted.

Personally I think doing a "sleep" in the middle of cpu_relax() is wrong,
as it is typically used in busy loops like spinlocks where there is no
guarantee that there will be something to wake you back up. It also has an
overhead which you may not want. Using it in the idle loop is more
appropriate, as typically worth while going to sleep there, and you can
(Continue reading)

Permalink | Reply | 15 comments |
headers
Paul Mundt | 5 May 2004 00:25
Gravatar

Re: [linux-sh:03225] Re: SH SCI output weirdness...

On Tue, May 04, 2004 at 09:48:55PM +0100, Stuart MENEFY wrote:
> The problem is the idle loop has been modified to call cpu_relax(), and
> cpu_relax() now includes a "sleep" instruction. The hlt_counter, although
> still present, is ignored.
> 
That's an oversight, the hlt_counter should be added back in to cpu_idle().
Additionally, it's probably worth having cpu_relax() check hlt_counter
prior to emitting the sleep instruction.

Putting this into cpu_relax() was ultimately a power saving hack (in the same
capacity as x86 hlt). But this does depend on the power-down mode config.
I agree that cpu_relax() is a bit of a problematic case, but in the case
where a module is well aware of when it can sleep, it certainly helps in
the power consumption case. As such, the power-down mode configuration needs
to be quite precise.

In the event that sleep is possible, it's certainly nicer to have in a busy
loop than a do { } while (0), particularly if you're going to be there for
awhile.

Perhaps if DPM is ever merged we can setup some more intelligent policies for
things like this.

> On the ST40, with the default power management configuration, this appears
> to try and power down or reduce the clock speed of the serial port. So any
> data still in the FIFO gets corrupted.
> 
In that case, ST40 needs to setup the power management configuration in a way
that won't power down serial, or hlt_counter needs to be wrapped in and then
disabled for ST40.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Alex Bennee | 5 May 2004 12:07

Re: Re: [linux-sh:03224] SH SCI output weirdness...

On Tue, 2004-05-04 at 21:48, Stuart MENEFY wrote:
> However, for the moment I've simply got back to the 2.4 version of the code.
> 
Ahh. Does that mean you have a 2.6 kernel tree somewhere? I've been
looking through the CVS code trying to get it up and running on my board
and one thing I've noticed is the ST40 stuff seems a little out of date
(pre the merges I did on 2.4) .

My current plan is to forward port the merges I did into 2.4 into 2.6
(time.c and pci-st40.c to start with). However if you have a more
current tree I can certainly go through that re-sync stuff into the
LinuxSH CVS like I did for 2.4

Paul also has a bunch of stuff waiting to be merged from his bk tree
into 2.4 (and I assume 2.6) which I said I'd look at. It breaks down to:

* Board specific stuff (which I could merge but have no way of testing)
* ST40 PCI fix (asbytes stuff which make no difference on my h/w)
* ST40 Clock and PIO additions (which I'm unfamiliar with)

--

-- 
Alex, homepage: http://www.bennee.com/~alex/
That does not compute.

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart MENEFY | 5 May 2004 16:05

Re: [linux-sh:03225] Re: SH SCI output weirdness...

On Tue, 4 May 2004 18:25:21 -0400 Paul Mundt <lethal <at> linux-sh.org> wrote:

> On Tue, May 04, 2004 at 09:48:55PM +0100, Stuart MENEFY wrote:
> > The problem is the idle loop has been modified to call cpu_relax(), and
> > cpu_relax() now includes a "sleep" instruction. The hlt_counter, although
> > still present, is ignored.
> > 
> That's an oversight, the hlt_counter should be added back in to cpu_idle().
> Additionally, it's probably worth having cpu_relax() check hlt_counter
> prior to emitting the sleep instruction.
> 
> Putting this into cpu_relax() was ultimately a power saving hack (in the same
> capacity as x86 hlt). But this does depend on the power-down mode config.

Note that x86 does not use "hlt" in cpu_relax(), it only uses it in the
idle loop. On x86 cpu_relax() uses the bizarre "rep;nop" sequence which as
I understand it is much lighter weight, effectively causes the CPU to wait
until the pipeline empties and then restarts. Its also effectively a yield
on hyperthreaded systems. So people calling cpu_relax() are not going to
expect a fairly major power down.

> I agree that cpu_relax() is a bit of a problematic case, but in the case
> where a module is well aware of when it can sleep, it certainly helps in
> the power consumption case. As such, the power-down mode configuration needs
> to be quite precise.
> 
> In the event that sleep is possible, it's certainly nicer to have in a busy
> loop than a do { } while (0), particularly if you're going to be there for
> awhile.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Paul Mundt | 5 May 2004 16:18
Gravatar

Re: [linux-sh:03225] Re: SH SCI output weirdness...

On Wed, May 05, 2004 at 03:05:36PM +0100, Stuart MENEFY wrote:
> Note that x86 does not use "hlt" in cpu_relax(), it only uses it in the
> idle loop. On x86 cpu_relax() uses the bizarre "rep;nop" sequence which as
> I understand it is much lighter weight, effectively causes the CPU to wait
> until the pipeline empties and then restarts. Its also effectively a yield
> on hyperthreaded systems. So people calling cpu_relax() are not going to
> expect a fairly major power down.
> 
That's interesting, I could've sworn the last time I looked it wrapped into
hlt as well.

> While I agree it would be nice to have a way of doing this, "sleep" is not
> it. The only way to get out of a "sleep" is an interrupt or reset. A busy
> loop is explicitly polling for something to happen, not waiting for an
> interrupt. So putting a "sleep" in a busy loop is going to play havoc
> with latency.
> 
That's a good point. In that case, I'll back it out for cpu_relax() and add
the hlt_counter back in for the idle loop. This should fix serial on ST40.

> To do this properly we need a way of saying "the CPU isn't doing much, so
> maybe reduce its clock frequency, reduce its bus priority, but keep it
> going". I don't see any light weight way of doing this on an SH.
> 
Something like this is possible with DPM policies, but as it hasn't been
integrated into mainline, it's not anything we'll be worrying about at this
point.

> Agreed. I've never tried running without the sleep being disabled since it was
> known to be broken on early HCMOS7 parts. Given correct configuration, I think
(Continue reading)

Permalink | Reply | 7 comments |

Gmane