ping chuck ebbert

[Ronald Warsow]

hallo

according to this thread
http://www.gossamer-threads.com/lists/linux/kernel/745231
and
http://www.mail-archive.com/[e-mail]/msg06174.html

my question:
are there some more kernel parameter I can try.

currently I only can boot my F7/rawhide box (ATI SB600 controller)
with acpi=off
or
nohpet

[Christopher Brown]

On 19/09/2007, Ronald Warsow  wrote:
> hallo
>
> according to this thread
> http://www.gossamer-threads.com/lists/linux/kernel/745231
> and
> http://www.mail-archive.com/[e-mail]/msg06174.html
>
> my question:
> are there some more kernel parameter I can try.
>
> currently I only can boot my F7/rawhide box (ATI SB600 controller)
> with acpi=off
> or
> nohpet

Try noapic or nolapic. For a full list for the 2.6.22 kernel:

http://snecker.fedorapeople.org/kp.txt

Cheers
Chris

[Ronald Warsow]

Christopher Brown wrote:
> On 19/09/2007, Ronald Warsow  wrote:
> > hallo
> >
> > according to this thread
> > http://www.gossamer-threads.com/lists/linux/kernel/745231
> > and
> > http://www.mail-archive.com/[e-mail]/msg06174.html
> >
> > my question:
> > are there some more kernel parameter I can try.
> >
> > currently I only can boot my F7/rawhide box (ATI SB600 controller)
> > with acpi=off
> > or
> > nohpet
>
> Try noapic or nolapic. For a full list for the 2.6.22 kernel:

just tried without luck !
> http://snecker.fedorapeople.org/kp.txt

many thanks, but I had a look at this list already.

the difficulty for me is to decide *what* parameter in what combination 
*are best* to try.
means *minimal* bootparameter by *maximal feature*.

so, for instance, if I choose "acpi=off" I got a complete boot, but no 
cpu frequency scaling, with "nohpet" I loose tickless, - afaik-.

pci=noacpi,irqpoll as mentioned by chuck in the first above thread 
doesn't work for me.

I read some more threads about:
- 64 bit fedora should fix this
- hardware design bug,
- bios updates
- ....,

but nothing what's "handy clear".

I believe I next do a serial console trace to start investigating this 
issue in top of that.
> Cheers
> Chris

[Vaclav Misek]

Ronald Warsow wrote:
> many thanks, but I had a look at this list already.
>
> the difficulty for me is to decide *what* parameter in what 
> combination *are best* to try.
> means *minimal* bootparameter by *maximal feature*.
>
> so, for instance, if I choose "acpi=off" I got a complete boot, but no 
> cpu frequency scaling, with "nohpet" I loose tickless, - afaik-.
>
> pci=noacpi,irqpoll as mentioned by chuck in the first above thread 
> doesn't work for me.
>
> I read some more threads about:
> 64 bit fedora should fix this
> hardware design bug,
> bios updates
> ....,
>
> but nothing what's "handy clear".
>
> I believe I next do a serial console trace to start investigating this 
> issue in top of that.

Hi Ronald,
as I reported in one bugreport you should try to use pci=nomsi 
parameter. It should work without any additional impact :-).
Kind regards

sHINOBI

[Ronald Warsow]

Vaclav Misek wrote:
> Ronald Warsow wrote:

...
> Hi Ronald,
> as I reported in one bugreport you should try to use pci=nomsi 
> parameter. It should work without any additional impact :-).
> Kind regards
>                              sHINOBI

thank you, but no luck !

this are the last lines from a serial console trace:

...
pnp: 00:0c: iomem range 0xfc000-0xfffff could not be reserved
PCI: Bridge: 0000:00:01.0
Clocksource tsc unstable (delta = -298394387904 ns)
   IO window: d000-dfff
   MEM window: fdb00000-fdcfffff
   PREFETCH window: f0000000-f7ffffff
PCI: Bridge: 0000:00:07.0
   IO window: e000-efff
   MEM window: fda00000-fdafffff
   PREFETCH window: fdf00000-fdffffff
PCI: Bridge: 0000:00:14.4
   IO window: c000-cfff
   MEM window: fde00000-fdefffff
   PREFETCH window: fdd00000-fddfffff
NET: Registered protocol family 2

box hangs !!!

and this is the component where the box hangs:

00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge 
(prog-if 01 [Subtractive decode])
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop+ ParErr- 
Stepping- SERR- FastB2B-
    Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
    Latency: 64
    Bus: primary=00, secondary=03, subordinate=03, sec-latency=64
    I/O behind bridge: 0000c000-0000cfff
    Memory behind bridge: fde00000-fdefffff
    Prefetchable memory behind bridge: fdd00000-fddfffff
    Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ <SERR- <PERR+
    BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-

any idea's ???

[Ronald Warsow]

Ronald Warsow wrote:
> hallo
>
> according to this thread
> http://www.gossamer-threads.com/lists/linux/kernel/745231
> and
> http://www.mail-archive.com/[e-mail]/msg06174.html
>
> my question:
> are there some more kernel parameter I can try.
>
> currently I only can boot my F7/rawhide box (ATI SB600 controller)
> with acpi=off
> or
> nohpet

for the record:

64 bit rawhide from today doesn't have this issue (anymore)

thx. for pong

[Chuck Ebbert]

On 09/19/2007 07:04 PM, Ronald Warsow wrote:
> for the record:
>
> 64 bit rawhide from today doesn't have this issue (anymore)

There were some timekeeping changes in there, IIRC.

[David Fischer (DHL US)]

Chuck,

Would this help my Bugzilla:#298581 ??
https://bugzilla.redhat.com/show_bug.cgi?id=298581

It is really hard have this timer issue with new kernels and not the
older ones

thanks

On Wed, 2007-09-19 at 19:31 -0400, Chuck Ebbert wrote:
> On 09/19/2007 07:04 PM, Ronald Warsow wrote:
> > for the record:
> >
> > 64 bit rawhide from today doesn't have this issue (anymore)
>
> There were some timekeeping changes in there, IIRC.

[Ronald Warsow]

David Fischer (DHL US) wrote:
> Chuck,
>
> Would this help my Bugzilla:#298581 ??
> https://bugzilla.redhat.com/show_bug.cgi?id=298581
>
> It is really hard have this timer issue with new kernels and not the
> older ones
>
> thanks
>
> On Wed, 2007-09-19 at 19:31 -0400, Chuck Ebbert wrote:
> > On 09/19/2007 07:04 PM, Ronald Warsow wrote:
> > > for the record:
> > >
> > > 64 bit rawhide from today doesn't have this issue (anymore)
> >
> > There were some timekeeping changes in there, IIRC.

It isn't addressed to me, but my SB600 controller claims that it can do 
something related to address ranges that it really can't -afaik/iirc-
so I'm unable to run i386 Linux OS's without parameter and I tried 64 bit.

in your bz you mentioned a 64bit OS already.
sure you can try rawhide kernels...

[David Fischer (DHL US)]

Well I have loaded the rawhide kernel 2.6.23-0.195.rc7.git3.fc8.  All my
clock issues are gone and I no longer have any syslog messages about
kernel time error!

thanks all

On Tue, 2007-09-25 at 00:32 +0200, Ronald Warsow wrote:
> David Fischer (DHL US) wrote:
> > Chuck,
> >
> > Would this help my Bugzilla:#298581 ??
> > https://bugzilla.redhat.com/show_bug.cgi?id=298581
> >
> > It is really hard have this timer issue with new kernels and not the
> > older ones
> >
> > thanks
> >
> > On Wed, 2007-09-19 at 19:31 -0400, Chuck Ebbert wrote:
> > > On 09/19/2007 07:04 PM, Ronald Warsow wrote:
> > > > for the record:
> > > >
> > > > 64 bit rawhide from today doesn't have this issue (anymore)
> > >
> > > There were some timekeeping changes in there, IIRC.
>
> It isn't addressed to me, but my SB600 controller claims that it can do 
> something related to address ranges that it really can't -afaik/iirc-
> so I'm unable to run i386 Linux OS's without parameter and I tried 64 bit.
>
> in your bz you mentioned a 64bit OS already.
> sure you can try rawhide kernels...
>
> -- 
>       Ronald