[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rtc and chrony on Ultra 1 and Ultra 5



The "eeprom" OBP node does not include an "intr" or "interrupts" node,
so the device does not support generating interrupts (at least, as
implemented).  In this case, UIE_ON and UIE_OFF are invalid (the
drivers/char/rtc.c driver already treats them as such, returning
EINVAL).  Because some devices support this and some (apparently)
don't, and we masquerade behind a common interface, ENOTSUP might have
been a better choice.

Depending upon what Chrony expects, perhaps no-ops would make them
work, but I suspect chrony ought to get a bit smarter to support such
devices.  I haven't looked at the code, but I assume the interrupts
are disabled while warping time.

E

On 4/20/05, Frans Pop <aragorn@tiscali.nl> wrote:
> Hello David,
> 
> I've run the new patch. See below.
> 
> FYI, I had already submitted a bug against chrony, mainly because it floods
> the log files in an unacceptable way:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301592
> The last comment in that report is interesting. Does Sparc use genrtc?
> 
> Cheers,
> Frans
> 
> P.S. No harm done to my system.
> 
> On Tuesday 19 April 2005 23:49, David S. Miller wrote:
> > Or we can do something like this, provide the PC rtc ioctls
> > in the Mostek RTC driver.
> 
> Yes, that sounds like a nice approach.
> 
> > @@ -164,6 +225,7 @@
> >               printk(KERN_ERR "rtc: unable to get misc minor for Mostek\n");
> >               return error;
> >       }
> > +     printk("rtc_sun_init: Registered Mostek RTC driver.\n");
> >
> >       return 0;
> >  }
> 
> IMO this bit should go in anyway (though maybe without the closing period).
> It makes at least clear that a driver for the RTC _is_ loaded. The message
> appears a bit later in the kernel log than the "No PC RTC" message:
> 
> Apr 20 16:25:24 localhost kernel: rtc_init: no PC rtc found
> Apr 20 16:25:24 localhost kernel: su0 at 0x000001fff13062f8 (irq = 4,7ea) is a 16550A
> Apr 20 16:25:24 localhost kernel: su1 at 0x000001fff13083f8 (irq = 9,7e9) is a 16550A
> Apr 20 16:25:24 localhost kernel: ttyS0 at MMIO 0x1fff1400000 (irq = 7052256) is a SAB82532 V3.2
> Apr 20 16:25:24 localhost kernel: ttyS1 at MMIO 0x1fff1400040 (irq = 7052256) is a SAB82532 V3.2
> Apr 20 16:25:24 localhost kernel: Using anticipatory io scheduler
> Apr 20 16:25:24 localhost kernel: Floppy drive(s): fd0 is 1.44M
> Apr 20 16:25:24 localhost kernel: FDC 0 is a National Semiconductor PC87306
> Apr 20 16:25:24 localhost kernel: RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
> Apr 20 16:25:24 localhost kernel: loop: loaded (max 8 devices)
> Apr 20 16:25:24 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> Apr 20 16:25:24 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> Apr 20 16:25:24 localhost kernel: CMD646: IDE controller at PCI slot 0000:01:03.0
> Apr 20 16:25:24 localhost kernel: CMD646: chipset revision 3
> Apr 20 16:25:24 localhost kernel: CMD646: chipset revision 0x03, MultiWord DMA Force Limited
> Apr 20 16:25:24 localhost kernel: CMD646: 100%% native mode on irq 4,7e0
> Apr 20 16:25:24 localhost kernel:     ide0: BM-DMA at 0x1fe02c00020-0x1fe02c00027, BIOS settings: hda:pio, hdb:pio
> Apr 20 16:25:24 localhost kernel:     ide1: BM-DMA at 0x1fe02c00028-0x1fe02c0002f, BIOS settings: hdc:pio, hdd:pio
> Apr 20 16:25:24 localhost kernel: hda: ST34342A, ATA DISK drive
> Apr 20 16:25:24 localhost kernel: ide0 at 0x1fe02c00000-0x1fe02c00007,0x1fe02c0000a on irq 4,7e0
> Apr 20 16:25:24 localhost kernel: hdc: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive
> Apr 20 16:25:24 localhost kernel: ide1 at 0x1fe02c00010-0x1fe02c00017,0x1fe02c0001a on irq 4,7e0 (shared with ide0)
> Apr 20 16:25:24 localhost kernel: hda: max request size: 128KiB
> Apr 20 16:25:24 localhost kernel: hda: 8404830 sectors (4303 MB), CHS=8894/15/63, (U)DMA
> Apr 20 16:25:24 localhost kernel:  hda: hda1 hda2 hda3 hda4
> Apr 20 16:25:24 localhost kernel: rtc_sun_init: Registered Mostek RTC driver.
> 
> However, the patch does not yet solve the problem with chrony.
> I've taken a look at chrony's source. The relevant files seem to be
> rtc_linux.[hc] (attached).
> 
> The .c file defines the calls that are expected to be supported. Not all
> seem to be actually used. AFAICT only the following calls are used:
> RTC_UIE_ON, RTC_UIE_OFF
> RTC_RD_TIME, RTC_SET_TIME
> 
> I've also attached an strace from starting the chrony daemon and marked the
> relevant (AFAICT) lines.
> From this I conclude that the following statements from rtc_linux.c are
> causing the problems:
>     status = ioctl(fd, RTC_UIE_ON, 0);
>     status = read(fd, &data, sizeof(data));
>     status = ioctl(fd, RTC_UIE_OFF, 0);
> with fd refering to /dev/rtc.
> 
> 
> 


-- 
E



Reply to: