Debian parisc config for 2.6.26 broke the real time clock

Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
clock driver).  Starting with 2.6.26, debian is now enabling
CONFIG_RTC_CLASS (for platforms with specific RTC drivers) which
disables CONFIG_GEN_RTC and means that hwclock (and ntp tracking) are
broken on parisc with debian kernels 2.6.26 and above.

All of the arch/parisc/config files get this right, so someone at debian
must have screwed up somehow.  The config option CONFIG_RTC_CLASS must
be set to 'N' for all parisc systems.  I'd suggest checking the debian
kernel configs against the in-tree default files to see if there are any
other cockups like this.

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

On Sat, 2008-09-06 at 10:06 -0500, James Bottomley wrote:
> Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
> clock driver).  Starting with 2.6.26, debian is now enabling
> CONFIG_RTC_CLASS (for platforms with specific RTC drivers) which
> disables CONFIG_GEN_RTC and means that hwclock (and ntp tracking) are
> broken on parisc with debian kernels 2.6.26 and above.
> 
> All of the arch/parisc/config files get this right, so someone at debian
> must have screwed up somehow.  The config option CONFIG_RTC_CLASS must
> be set to 'N' for all parisc systems.  I'd suggest checking the debian
> kernel configs against the in-tree default files to see if there are any
> other cockups like this.

OK, I dug into this.  The problem with debian is that CONFIG_RTC_CLASS
is set in the generic configuration and from 2.6.26 onwards
CONFIG_GEN_RTC is overridden by this (that's the reason we don't see it
on our local configs).  I'm not entirely sure what the correct fix is.
It looks like GEN_RTC is being deprecated, so it might be to move to
RTC_CLASS.  I think the best thing is for me to try to put an arch
override for RTC_CLASS and see what the reaction is.

In the meantime, you can get a working debian kernel here:

http://parisc-linux.org/~jejb/linux-image-2.6.26-1-parisc_2.6.26-4+b1_hppa.deb

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[Bastian Blank]

On Sat, Sep 06, 2008 at 10:06:26AM -0500, James Bottomley wrote:
> Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
> clock driver).

Well.

>                 Starting with 2.6.26, debian is now enabling
> CONFIG_RTC_CLASS (for platforms with specific RTC drivers) which
> disables CONFIG_GEN_RTC and means that hwclock (and ntp tracking) are
> broken on parisc with debian kernels 2.6.26 and above.

Yes. Most arches already needs it anyway.

> All of the arch/parisc/config files get this right, so someone at debian
> must have screwed up somehow.  The config option CONFIG_RTC_CLASS must
> be set to 'N' for all parisc systems.

Apparently hppa uses its special rtc type.  I propose that you take a
look at drivers/rtc/rtc-ppc.c and write a wrapper rtc module.

>                                        I'd suggest checking the debian
> kernel configs against the in-tree default files to see if there are any
> other cockups like this.

If there are, this are bugs in the kernel themself. I'm no hppa
developer so I won't waste my time with such.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
		-- Spock, "Day of the Dove", stardate unknown

Re: Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

On Mon, 2008-09-08 at 18:37 +0200, Bastian Blank wrote:
> On Sat, Sep 06, 2008 at 10:06:26AM -0500, James Bottomley wrote:
> > Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
> > clock driver).
> 
> Well.
> 
> >                 Starting with 2.6.26, debian is now enabling
> > CONFIG_RTC_CLASS (for platforms with specific RTC drivers) which
> > disables CONFIG_GEN_RTC and means that hwclock (and ntp tracking) are
> > broken on parisc with debian kernels 2.6.26 and above.
> 
> Yes. Most arches already needs it anyway.
> 
> > All of the arch/parisc/config files get this right, so someone at debian
> > must have screwed up somehow.  The config option CONFIG_RTC_CLASS must
> > be set to 'N' for all parisc systems.
> 
> Apparently hppa uses its special rtc type.  I propose that you take a
> look at drivers/rtc/rtc-ppc.c and write a wrapper rtc module.

That may be the way forwards depending on what the RTC developers say,
but it certainly won't fix the 2.6.26 regression.

> >                                        I'd suggest checking the debian
> > kernel configs against the in-tree default files to see if there are any
> > other cockups like this.
> 
> If there are, this are bugs in the kernel themself. I'm no hppa
> developer so I won't waste my time with such.

Hardly, the bug is actually in the debian configs.  You have
CONFIG_RTC_CLASS as a generic override.  This is wrong, it needs to be
subordinate to CONIFG_GEN_RTC.  The quick fix would be to move the
CONFIG_RTC_CLASS sequence down from generic to the architectures ... if
you're incapable of doing that, I might be able to find time to look at
doing it for you.

The real bug looks to be the debian config system which relies on
concatenation ... what's really needed is a way of turning
CONFIG_RTC_CLASS off on parisc while keeping RTC_CLASS generic for those
architectures that need it.

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[dann frazier]

On Mon, Sep 08, 2008 at 11:58:22AM -0500, James Bottomley wrote:
> On Mon, 2008-09-08 at 18:37 +0200, Bastian Blank wrote:
> > On Sat, Sep 06, 2008 at 10:06:26AM -0500, James Bottomley wrote:
> > > Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
> > > clock driver).
> > 
> > Well.
> > 
> > >                 Starting with 2.6.26, debian is now enabling
> > > CONFIG_RTC_CLASS (for platforms with specific RTC drivers) which
> > > disables CONFIG_GEN_RTC and means that hwclock (and ntp tracking) are
> > > broken on parisc with debian kernels 2.6.26 and above.
> > 
> > Yes. Most arches already needs it anyway.
> > 
> > > All of the arch/parisc/config files get this right, so someone at debian
> > > must have screwed up somehow.  The config option CONFIG_RTC_CLASS must
> > > be set to 'N' for all parisc systems.
> > 
> > Apparently hppa uses its special rtc type.  I propose that you take a
> > look at drivers/rtc/rtc-ppc.c and write a wrapper rtc module.
> 
> That may be the way forwards depending on what the RTC developers say,
> but it certainly won't fix the 2.6.26 regression.
> 
> > >                                        I'd suggest checking the debian
> > > kernel configs against the in-tree default files to see if there are any
> > > other cockups like this.
> > 
> > If there are, this are bugs in the kernel themself. I'm no hppa
> > developer so I won't waste my time with such.
> 
> Hardly, the bug is actually in the debian configs.  You have
> CONFIG_RTC_CLASS as a generic override.  This is wrong, it needs to be
> subordinate to CONIFG_GEN_RTC.  The quick fix would be to move the
> CONFIG_RTC_CLASS sequence down from generic to the architectures ... if
> you're incapable of doing that, I might be able to find time to look at
> doing it for you.
> 
> The real bug looks to be the debian config system which relies on
> concatenation ... what's really needed is a way of turning
> CONFIG_RTC_CLASS off on parisc while keeping RTC_CLASS generic for those
> architectures that need it.

fyi, I've got an hppa build in progress - disabling RTC_CLASS causes
the symbols below to be removed (essentially, ^rtc_*)

I'm not sure what's behind the hppa/ABI removal commits - I didn't see
this discussed on the list - but I think it should be safe to remove
these symbols from the ABI files if we can demonstrate that none of
the conglomerate packages use them.

rtc_class_close
rtc_class_open
rtc_device_register
rtc_device_unregister
rtc_irq_register
rtc_irq_set_freq
rtc_irq_set_state
rtc_irq_unregister
rtc_month_days
rtc_read_alarm
rtc_read_time
rtc_set_alarm
rtc_set_mmss
rtc_set_time
rtc_time_to_tm
rtc_tm_to_time
rtc_update_irq
rtc_valid_tm
rtc_year_days

-- 
dann frazier

Re: Debian parisc config for 2.6.26 broke the real time clock

[Bastian Blank]

On Tue, Sep 09, 2008 at 10:58:35AM -0600, dann frazier wrote:
> fyi, I've got an hppa build in progress - disabling RTC_CLASS causes
> the symbols below to be removed (essentially, ^rtc_*)

The whole new-style rtc support.

> I'm not sure what's behind the hppa/ABI removal commits - I didn't see
> this discussed on the list - but I think it should be safe to remove
> these symbols from the ABI files if we can demonstrate that none of
> the conglomerate packages use them.

Why does noone write this 30 lines module and fix it for all?

Bastian

-- 
Behind every great man, there is a woman -- urging him on.
		-- Harry Mudd, "I, Mudd", stardate 4513.3

Re: Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

On Tue, 2008-09-09 at 10:58 -0600, dann frazier wrote:
> On Mon, Sep 08, 2008 at 11:58:22AM -0500, James Bottomley wrote:
> > On Mon, 2008-09-08 at 18:37 +0200, Bastian Blank wrote:
> > > On Sat, Sep 06, 2008 at 10:06:26AM -0500, James Bottomley wrote:
> > > > Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time
> > > > clock driver).
> > > 
> > > Well.
> > > 
> > > >                 Starting with 2.6.26, debian is now enabling
> > > > CONFIG_RTC_CLASS (for platforms with specific RTC drivers) which
> > > > disables CONFIG_GEN_RTC and means that hwclock (and ntp tracking) are
> > > > broken on parisc with debian kernels 2.6.26 and above.
> > > 
> > > Yes. Most arches already needs it anyway.
> > > 
> > > > All of the arch/parisc/config files get this right, so someone at debian
> > > > must have screwed up somehow.  The config option CONFIG_RTC_CLASS must
> > > > be set to 'N' for all parisc systems.
> > > 
> > > Apparently hppa uses its special rtc type.  I propose that you take a
> > > look at drivers/rtc/rtc-ppc.c and write a wrapper rtc module.
> > 
> > That may be the way forwards depending on what the RTC developers say,
> > but it certainly won't fix the 2.6.26 regression.
> > 
> > > >                                        I'd suggest checking the debian
> > > > kernel configs against the in-tree default files to see if there are any
> > > > other cockups like this.
> > > 
> > > If there are, this are bugs in the kernel themself. I'm no hppa
> > > developer so I won't waste my time with such.
> > 
> > Hardly, the bug is actually in the debian configs.  You have
> > CONFIG_RTC_CLASS as a generic override.  This is wrong, it needs to be
> > subordinate to CONIFG_GEN_RTC.  The quick fix would be to move the
> > CONFIG_RTC_CLASS sequence down from generic to the architectures ... if
> > you're incapable of doing that, I might be able to find time to look at
> > doing it for you.
> > 
> > The real bug looks to be the debian config system which relies on
> > concatenation ... what's really needed is a way of turning
> > CONFIG_RTC_CLASS off on parisc while keeping RTC_CLASS generic for those
> > architectures that need it.
> 
> fyi, I've got an hppa build in progress - disabling RTC_CLASS causes
> the symbols below to be removed (essentially, ^rtc_*)

Thanks Dann ... are you the person in charge of the builds then?

> I'm not sure what's behind the hppa/ABI removal commits - I didn't see
> this discussed on the list - but I think it should be safe to remove
> these symbols from the ABI files if we can demonstrate that none of
> the conglomerate packages use them.
> 
> rtc_class_close
> rtc_class_open
> rtc_device_register
> rtc_device_unregister
> rtc_irq_register
> rtc_irq_set_freq
> rtc_irq_set_state
> rtc_irq_unregister
> rtc_month_days
> rtc_read_alarm
> rtc_read_time
> rtc_set_alarm
> rtc_set_mmss
> rtc_set_time
> rtc_time_to_tm
> rtc_tm_to_time
> rtc_update_irq
> rtc_valid_tm
> rtc_year_days

They certainly have to be inessential to the parisc ABI ... they don't
work if anything's actually trying to use them.

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

On Tue, 2008-09-09 at 19:38 +0200, Bastian Blank wrote:
> On Tue, Sep 09, 2008 at 10:58:35AM -0600, dann frazier wrote:
> > fyi, I've got an hppa build in progress - disabling RTC_CLASS causes
> > the symbols below to be removed (essentially, ^rtc_*)
> 
> The whole new-style rtc support.

But it doesn't work, that's rather the point of all of this.  If it
doesn't work, it can hardly be a committed ABI.

> > I'm not sure what's behind the hppa/ABI removal commits - I didn't see
> > this discussed on the list - but I think it should be safe to remove
> > these symbols from the ABI files if we can demonstrate that none of
> > the conglomerate packages use them.
> 
> Why does noone write this 30 lines module and fix it for all?

Because only an idiot would fix a bug in a released product by
introducing a new feature: that's QA and release process 101.  New
features belong in the next merge window, which will be for 2.6.28 by
which time it should have been reasonably QA'd by the parisc developers.

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[Bastian Blank]

On Tue, Sep 09, 2008 at 12:48:35PM -0500, James Bottomley wrote:
> They certainly have to be inessential to the parisc ABI ... they don't
> work if anything's actually trying to use them.

Really? Which sort of "don't work" is this? Why should a I2C rtc device
(some dallas chip) not work?

Bastian

-- 
No problem is insoluble.
		-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

Re: Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

On Tue, 2008-09-09 at 20:01 +0200, Bastian Blank wrote:
> On Tue, Sep 09, 2008 at 12:48:35PM -0500, James Bottomley wrote:
> > They certainly have to be inessential to the parisc ABI ... they don't
> > work if anything's actually trying to use them.
> 
> Really? Which sort of "don't work" is this? Why should a I2C rtc device
> (some dallas chip) not work?

Um, because the architecture doesn't have an i2c bus.

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[Bastian Blank]

On Tue, Sep 09, 2008 at 01:12:01PM -0500, James Bottomley wrote:
> On Tue, 2008-09-09 at 20:01 +0200, Bastian Blank wrote:
> > On Tue, Sep 09, 2008 at 12:48:35PM -0500, James Bottomley wrote:
> > > They certainly have to be inessential to the parisc ABI ... they don't
> > > work if anything's actually trying to use them.
> > Really? Which sort of "don't work" is this? Why should a I2C rtc device
> > (some dallas chip) not work?
> Um, because the architecture doesn't have an i2c bus.

Well, it have USB, so can also power usb-to-i2c adapters. And there is
even the rtc test module.

Which "don't work" do you refer to?
- Does not work because there is no binding to the hardware.
- Does not work because a fundamental problem in the whole subsystem.
(- Does not work because ...)

Bastian

-- 
You're dead, Jim.
		-- McCoy, "The Tholian Web", stardate unknown

Re: Debian parisc config for 2.6.26 broke the real time clock

[John David Anglin]

> Um, because the architecture doesn't have an i2c bus.

Don't know about rtc but some PA-RISC models definitely have an i2c bus.
I see this message on a A500-75 model:

     The support bus which connects the system processors, the Guardian Service
     Processor (GSP) and the Power Monitor or Platform Monitor may have become
     hung.  (The support bus can be tested by issuing the GSP command "XD", and
     selecting the I2C access test).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Debian parisc config for 2.6.26 broke the real time clock

[Matthew Wilcox]

On Tue, Sep 09, 2008 at 02:42:03PM -0400, John David Anglin wrote:
> > Um, because the architecture doesn't have an i2c bus.
> 
> Don't know about rtc but some PA-RISC models definitely have an i2c bus.
> I see this message on a A500-75 model:
> 
>      The support bus which connects the system processors, the Guardian Service
>      Processor (GSP) and the Power Monitor or Platform Monitor may have become
>      hung.  (The support bus can be tested by issuing the GSP command "XD", and
>      selecting the I2C access test).

This I2C bus is not acessible by the operating system (as far as I know).

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Debian parisc config for 2.6.26 broke the real time clock

[James Bottomley]

On Tue, 2008-09-09 at 20:29 +0200, Bastian Blank wrote:
> On Tue, Sep 09, 2008 at 01:12:01PM -0500, James Bottomley wrote:
> > On Tue, 2008-09-09 at 20:01 +0200, Bastian Blank wrote:
> > > On Tue, Sep 09, 2008 at 12:48:35PM -0500, James Bottomley wrote:
> > > > They certainly have to be inessential to the parisc ABI ... they don't
> > > > work if anything's actually trying to use them.
> > > Really? Which sort of "don't work" is this? Why should a I2C rtc device
> > > (some dallas chip) not work?
> > Um, because the architecture doesn't have an i2c bus.
> 
> Well, it have USB, so can also power usb-to-i2c adapters. And there is
> even the rtc test module.

Um you mean i2c_tiny_usb?  It doesn't drive any supported hardware ...
you have to build the connection yourself.  Plus only the latest revs of
PA actually supported USB ...

> Which "don't work" do you refer to?
> - Does not work because there is no binding to the hardware.
> - Does not work because a fundamental problem in the whole subsystem.
> (- Does not work because ...)

Well, like most real world systems, you can artificially construct
pathological failure cases.  If I were you I'd stop looking for the
heath robinson ones.  No-one in their right mind is going to construct a
USB to I2C interface for the purpose of running and I2C RTC; the set of
users is clearly empty.

The way you would get an external RTC is via a more credible interface
like PCI (or EISA/ISA) is from a watchdog card ... however, no-one's
apparently written a RTC interface for any of those yet.

James

Re: Debian parisc config for 2.6.26 broke the real time clock

[John David Anglin]

> This I2C bus is not acessible by the operating system (as far as I know).

HP-UX seems to be able to access fan and power status somehow.  It
sends me an email when it thinks the i2c is hung, and once a day,
it sends a message that a fan which the chassis doesn't have (as far
as I can tell) has failed.  Of course, the A500-75 model doesn't
actually exist...  The model that actually shipped was a A500-7X.
As a result, I've never been able to update the firmware.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Debian parisc config for 2.6.26 broke the real time clock

[Thibaut VARENE]

On Tue, Sep 9, 2008 at 9:20 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> This I2C bus is not acessible by the operating system (as far as I know).
>
> HP-UX seems to be able to access fan and power status somehow.  It

Fan and power status are accessed through PDC. That's what I do with
the pdc_chassis driver, and what's exposed in /proc/chassis on !PAT
boxes (I don't have the PAT specs to implement the proper calls,
unfortunately). AFAIK, there's no need to use i2c to retrieve that
info, it's all PDC glue.

HTH

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/