FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 09-08-2008, 04:37 PM
Bastian Blank
 
Default Debian parisc config for 2.6.26 broke the real time clock

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-08-2008, 04:58 PM
James Bottomley
 
Default Debian parisc config for 2.6.26 broke the real time clock

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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 04:58 PM
dann frazier
 
Default Debian parisc config for 2.6.26 broke the real time clock

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 05:38 PM
Bastian Blank
 
Default Debian parisc config for 2.6.26 broke the real time clock

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 05:48 PM
James Bottomley
 
Default Debian parisc config for 2.6.26 broke the real time clock

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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 05:53 PM
James Bottomley
 
Default Debian parisc config for 2.6.26 broke the real time clock

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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 06:01 PM
Bastian Blank
 
Default Debian parisc config for 2.6.26 broke the real time clock

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 06:12 PM
James Bottomley
 
Default Debian parisc config for 2.6.26 broke the real time clock

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



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 06:29 PM
Bastian Blank
 
Default Debian parisc config for 2.6.26 broke the real time clock

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


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 06:42 PM
"John David Anglin"
 
Default Debian parisc config for 2.6.26 broke the real time clock

> 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)


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:15 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org