Debian parisc config for 2.6.26 broke the real time clock

DISCUSSION James Bottomley 6 participants 16 messages Sep 6, 2008 – Sep 9, 2008

Share & tools

James Bottomley

author

2008-09-06 15:06 UTC #0 lore raw

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

James Bottomley

author

2008-09-08 15:43 UTC #1 lore raw

Quoted 11 lines · 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.

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

Bastian Blank

2008-09-08 16:37 UTC #2 lore raw

In reply to James Bottomley

Quoted 2 lines · James Bottomley

Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time clock driver).

Well.

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

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

Signature · 2 lines

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

James Bottomley

author

2008-09-08 16:58 UTC #3 lore raw

Quoted 11 lines · Bastian Blank

Quoted 2 lines · James Bottomley
Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time clock driver).
Well.
Quoted 4 lines
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.

Quoted 8 lines

Yes. Most arches already needs it anyway.
Quoted 3 lines
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.

Quoted 6 lines

Quoted 3 lines
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

dann frazier

2008-09-09 16:58 UTC #4 lore raw

Quoted 38 lines · James Bottomley

Quoted 11 lines · Bastian Blank
Quoted 2 lines · James Bottomley
Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time clock driver).
Well.
Quoted 4 lines
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.
Quoted 8 lines
Yes. Most arches already needs it anyway.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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.

Quoted 4 lines

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

Signature · 1 line

dann frazier

Bastian Blank

2008-09-09 17:38 UTC #5 lore raw

Quoted 2 lines · dann frazier

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.

Quoted 4 lines

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

Signature · 2 lines

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

James Bottomley

author

2008-09-09 17:53 UTC #6 lore raw

Quoted 5 lines · Bastian Blank

Quoted 2 lines · dann frazier
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.

Quoted 6 lines

Quoted 4 lines
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

James Bottomley

author

2008-09-09 17:48 UTC #7 lore raw

In reply to dann frazier

Quoted 39 lines · dann frazier

Quoted 38 lines · James Bottomley
Quoted 11 lines · Bastian Blank
Quoted 2 lines · James Bottomley
Parisc is a CONFIG_GEN_RTC architecture (we use the generic real time clock driver).
Well.
Quoted 4 lines
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.
Quoted 8 lines
Yes. Most arches already needs it anyway.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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.

Quoted 7 lines

Quoted 4 lines
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?

Quoted 16 lines

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

Quoted 8 lines

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

Bastian Blank

2008-09-09 18:01 UTC #8 lore raw

Quoted 2 lines · James Bottomley

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

Signature · 2 lines

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

James Bottomley

author

2008-09-09 18:12 UTC #9 lore raw

Quoted 6 lines · Bastian Blank

Quoted 2 lines · James Bottomley
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

Bastian Blank

2008-09-09 18:29 UTC #10 lore raw

Quoted 7 lines · James Bottomley

Quoted 5 lines · Bastian Blank
Quoted 2 lines · James Bottomley
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

Signature · 2 lines

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

James Bottomley

author

2008-09-09 18:58 UTC #11 lore raw

Quoted 11 lines · Bastian Blank

Quoted 7 lines · James Bottomley
Quoted 5 lines · Bastian Blank
Quoted 2 lines · James Bottomley
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 ...

Quoted 4 lines

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

John David Anglin

2008-09-09 18:42 UTC #12 lore raw

In reply to James Bottomley

Quoted 1 line

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

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Matthew Wilcox

2008-09-09 18:46 UTC #13 lore raw

Quoted 9 lines · John David Anglin

Quoted 1 line
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).

Signature · 4 lines

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."

John David Anglin

2008-09-09 19:20 UTC #14 lore raw

Quoted 1 line

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

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Thibaut VARENE

2008-09-09 19:35 UTC #15 lore raw

Quoted 3 lines · John David Anglin

Quoted 1 line
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

Signature · 2 lines

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