Re: rtc and chrony on Ultra 1 and Ultra 5
On Thursday 21 April 2005 08:56, [EMAIL PROTECTED] wrote: > Shouldn't the SPARC V9 tag be on for an Ultra(SPARC) 10? Yes, and I've already confirmed in a later test that it is. It was just that I do not have an isa bus so the scan loop was not entered at a lower level. Cheers, FJP pgpC51dVFom0a.pgp Description: PGP signature
Re: rtc and chrony on Ultra 1 and Ultra 5
--- Frans Pop <[EMAIL PROTECTED]> wrote:
> On Tuesday 19 April 2005 13:24, Frans Pop wrote:
> > ./drivers/char/rtc.c has this code:
> >
> > #ifdef __sparc__
> > for_each_ebus(ebus) {
> > for_each_ebusdev(edev, ebus) {
> printk(KERN_INFO "rtc_init: ebus %s\n",
> edev->prom_name);
> > if(strcmp(edev->prom_name, "rtc") == 0) {
> > rtc_port = edev->resource[0].start;
> > rtc_irq = edev->irqs[0];
> > goto found;
> > }
> > }
> > }
> >
>
> I've added a debug statement in this code, which gives the following
> output:
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus auxio
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus power
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,pll
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus se
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus su
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus su
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus ecpp
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus fdthree
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus eeprom
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus flashprom
> Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,CS4231
> Apr 19 20:39:22 localhost kernel: rtc_init: no PC rtc found
>
> So, apparently __sparc__ is defined for my U10. I also added a
> similar
> statement in the isa bus scan, so __sparc_v9__ is not set.
Shouldn't the SPARC V9 tag be on for an Ultra(SPARC) 10?
> Any ideas where the RTC could be hiding?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Wed, 20 Apr 2005 10:18:50 -0700 Eric Brower <[EMAIL PROTECTED]> wrote: > 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. The switch_interrupts() function in chrony basically tries RTC_UIE_ON and RTC_UIE_OFF and barfs a log message regardless of the error return. Any error makes it output a log message. And as Eric stated, these chips lack any interrupt facilities at all, so we the generic RTC driver would do the same thing. In any event, I'll change my Mostek RTC driver changes such that it returns the same error codes driver/char/rtc.c does for these cases. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On 20 Apr 2005 18:36:15 +0200 Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > Well, I will try somewtimes (as soon as I have faster internet > access). Did you submit this patch to be included in the "official" > kernel? Not yet, need to get chrony actually working first. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
"David S. Miller" <[EMAIL PROTECTED]> writes: > On 19 Apr 2005 23:57:51 +0200 > Sebastian Niehaus <[EMAIL PROTECTED]> wrote: [...] > The patch I just posted most recently for 2.6.x should allow > chrony to work even in this case by providing support for the > normal PC rtc driver's ioctls. You guys rule the world ;-) Well, I will try somewtimes (as soon as I have faster internet access). Did you submit this patch to be included in the "official" kernel? Thanks a lot, Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 0x01fff13062f8 (irq = 4,7ea) is
> a 16550A
> Apr 20 16:25:24 localhost kernel: su1 at 0x01fff13083f8 (irq = 9,7e9) is
> a 16550A
> Apr 20 16:25:24 localhost kernel: ttyS0 at MMIO 0x1fff140 (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
> :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
> 0x1fe02c0-0x1fe02c7,0x1fe02ca 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
Re: rtc and chrony on Ultra 1 and Ultra 5
On 19 Apr 2005 23:57:51 +0200 Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > Okay, Sun Ultra 5 with 2.4.27: Yes, same situation as Frans's machine. This chip is programmed by the drivers/sbus/char/rtc.c driver which only provides some Sparc specfici ioctls() to get/set RTC settings. The patch I just posted most recently for 2.6.x should allow chrony to work even in this case by providing support for the normal PC rtc driver's ioctls. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
"David S. Miller" <[EMAIL PROTECTED]> writes: > On 19 Apr 2005 23:16:28 +0200 > Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > > > Sorry for behaving like a complete moron :-( Yes, I got the wron spelling :-( > bash$ dpkg -S /usr/sbin/prtconf > sparc-utils: /usr/sbin/prtconf > bash$ > > So you need to: > > bash# apt-get install sparc-utils > > I'm surprised that package isn't in base at this point. It was. I tried the wrong command :-( Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 14:32:44 -0700
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> chrony needs to be hacked to try and use RTC_GET/RTC_SET on sparc.
Or we can do something like this, provide the PC rtc ioctls
in the Mostek RTC driver.
Frans, perhaps you can give this a spin instead?
drivers/sbus/char/rtc.c: 136d088ef324eb5843dfe9fdf9351b89fc3aae73
--- drivers/sbus/char/rtc.c
+++ drivers/sbus/char/rtc.c 2005-04-19 14:46:18.0 -0700
@@ -28,6 +28,24 @@
static int rtc_busy = 0;
+/* This is the structure layout used by drivers/char/rtc.c, we
+ * support that drivers ioctls so that things are less in
+ * userspace.
+ */
+struct rtc_time_generic {
+ int tm_sec;
+ int tm_min;
+ int tm_hour;
+ int tm_mday;
+ int tm_mon;
+ int tm_year;
+ int tm_wday;
+ int tm_yday;
+ int tm_isdst;
+};
+#define RTC_RD_TIME_IOR('p', 0x09, struct rtc_time_generic) /* Read RTC
time */
+#define RTC_SET_TIME _IOW('p', 0x0a, struct rtc_time_generic) /* Set RTC
time*/
+
/* Retrieve the current date and time from the real time clock. */
static void get_rtc_time(struct rtc_time *t)
{
@@ -82,29 +100,72 @@
spin_unlock_irq(&mostek_lock);
}
+static int put_rtc_time_generic(void __user *argp, struct rtc_time *tm)
+{
+ struct rtc_time_generic __user *utm = argp;
+
+ if (__put_user(tm->sec, &utm->tm_sec) ||
+ __put_user(tm->min, &utm->tm_min) ||
+ __put_user(tm->hour, &utm->tm_hour) ||
+ __put_user(tm->dom, &utm->tm_mday) ||
+ __put_user(tm->month, &utm->tm_mon) ||
+ __put_user(tm->year, &utm->tm_year) ||
+ __put_user(tm->dow, &utm->tm_wday) ||
+ __put_user(0, &utm->tm_yday) ||
+ __put_user(0, &utm->tm_isdst))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int get_rtc_time_generic(struct rtc_time *tm, void __user *argp)
+{
+ struct rtc_time_generic __user *utm = argp;
+
+ if (__get_user(tm->sec, &utm->tm_sec) ||
+ __get_user(tm->min, &utm->tm_min) ||
+ __get_user(tm->hour, &utm->tm_hour) ||
+ __get_user(tm->dom, &utm->tm_mday) ||
+ __get_user(tm->month, &utm->tm_mon) ||
+ __get_user(tm->year, &utm->tm_year) ||
+ __get_user(tm->dow, &utm->tm_wday))
+ return -EFAULT;
+
+ return 0;
+}
+
static int rtc_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
unsigned long arg)
{
struct rtc_time rtc_tm;
void __user *argp = (void __user *)arg;
- switch (cmd)
- {
+ switch (cmd) {
case RTCGET:
+ case RTC_RD_TIME:
memset(&rtc_tm, 0, sizeof(struct rtc_time));
get_rtc_time(&rtc_tm);
- if (copy_to_user(argp, &rtc_tm, sizeof(struct rtc_time)))
+ if (cmd == RTCGET) {
+ if (copy_to_user(argp, &rtc_tm,
+sizeof(struct rtc_time)))
+ return -EFAULT;
+ } else if (put_rtc_time_generic(argp, &rtc_tm))
return -EFAULT;
return 0;
case RTCSET:
+ case RTC_SET_TIME:
if (!capable(CAP_SYS_TIME))
return -EPERM;
- if (copy_from_user(&rtc_tm, argp, sizeof(struct rtc_time)))
+ if (cmd == RTCSET) {
+ if (copy_from_user(&rtc_tm, argp,
+ sizeof(struct rtc_time)))
+ return -EFAULT;
+ } else if (get_rtc_time_generic(&rtc_tm, argp))
return -EFAULT;
set_rtc_time(&rtc_tm);
@@ -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;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
"David S. Miller" <[EMAIL PROTECTED]> writes: [...] > On the Ultra1, the drivers/sbus/char/rtc.c driver is used. > > It is very strange to see the "rtc_init: no PC rtc found" message > on an Ultra5 or Ultra10, as drivers/char/rtc.c is the driver that > should be used on that platform. > > Can someone provide "/usr/sbin/prtconv -pv" *Waahh* I just tried this one without spell checking. Sorry for unneccesary noise. > on either the Ultra5 or > Ultra10 system which fails like this? It may provide the clue. > > Also, is this with a 2.4.x or 2.6.x kernel? Okay, Sun Ultra 5 with 2.4.27: , | System Configuration: Sun Microsystems sun4u | Memory size: 64 Megabytes | System Peripherals (PROM Nodes): | | Node 0xf00297e4 | reset-reason: 'POR' | idprom: 01800800.20a22ad3..a22ad3a9...40aa.aa00 | interrupt-map: 003c...f005f7c0.8033 | interrupt-map-mask: 003e.. | #interrupt-cells: 0001 | #address-cells: 0002 | breakpoint-trap: 007f | #size-cells: 0002 | energystar-v2: | model: 'SUNW,375-0066' | name: 'SUNW,Ultra-5_10' | clock-frequency: 055d4a80 | banner-name: 'Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz)' | device_type: 'upa' | | Node 0xf002ca28 | name: 'packages' | | Node 0xf0033adc | iso6429-1983-colors: | name: 'terminal-emulator' | | Node 0xf0036810 | disk-write-fix: | name: 'deblocker' | | Node 0xf0036ed4 | name: 'obp-tftp' | | Node 0xf0040b38 | name: 'disk-label' | | Node 0xf005b464 | name: 'SUNW,builtin-drivers' | | Node 0xf0069180 | name: 'sun-keyboard' | | Node 0xf002ca98 | stdout: fff9bd40 | stdin: fff93a68 | mmu: fffe8438 | memory: fffe8638 | bootargs: 00 | bootpath: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a' | gateway-ip: | server-ip: | client-ip: | stdout-#lines: | name: 'chosen' | | Node 0xf002cb04 | version: 'OBP 3.15.2 1998/11/10 10:35' | model: 'SUNW,3.15' | decode-complete: | aligned-allocator: | relative-addressing: | name: 'openprom' | | Node 0xf002cb94 | name: 'client-services' | | Node 0xf002cc3c | tpe-link-test?: 'true' | scsi-initiator-id: '7' | keyboard-click?: 'false' | keymap: | ttyb-rts-dtr-off: 'false' | ttyb-ignore-cd: 'true' | ttya-rts-dtr-off: 'false' | ttya-ignore-cd: 'true' | ttyb-mode: '9600,8,n,1,-' | ttya-mode: '9600,8,n,1,-' | pcia-probe-list: '1,2,3,4' | pcib-probe-list: '1,2,3' | mfg-mode: 'off' | diag-level: 'max' | #power-cycles: '461' | system-board-serial#: | system-board-date: | fcode-debug?: 'false' | output-device: 'screen:r640x480x60' | input-device: 'keyboard' | load-base: '16384' | boot-command: 'boot' | auto-boot?: 'true' | watchdog-reboot?: 'false' | diag-file: '-r' | diag-device: 'net' | boot-file: | boot-device: 'disk net' | local-mac-address?: 'false' | ansi-terminal?: 'true' | screen-#columns: '80' | screen-#rows: '34' | silent-mode?: 'false' | use-nvramrc?: 'false' | nvramrc: 'devalias pgx24 /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/SUNW,m64B' | security-mode: 'none' | security-password: | security-#badlogins: '0' | oem-logo: | oem-logo?: 'false' | oem-banner: | oem-banner?: 'false' | hardware-revision: | last-hardware-update: | diag-switch?: 'false' | name: 'options' | | Node 0xf002ccac | screen: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/SUNW,[EMAIL PROTECTED]' | net: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED],1' | cdrom: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:f' | disk: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' | disk3: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' | disk2: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' | disk1: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' | disk0: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' | ide: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]' | floppy: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTEC
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tuesday 19 April 2005 23:48, Sebastian Niehaus wrote: > | radioactive:/home/niehaus# /usr/sbin/prtconv -pb > | bash: /usr/sbin/prtconv: No such file or directory > Hmm, strange. > > I can't get it. David made a typo in his first request. Try /usr/sbin/prtconf :-) ^^^ :-D pgpeHnLEZvS5a.pgp Description: PGP signature
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 23:34:06 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > Thanks a lot David. The RTC error was something that had been nagging me > for some time. Please see my other email, my patch is incredibly wrong. chrony needs to be hacked to try and use RTC_GET/RTC_SET on sparc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 22:57:43 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > Apr 19 22:32:32 localhost kernel: Real Time Clock Driver v1.12 > > Apr 19 22:32:32 localhost kernel: rtc: unable to get misc minor for Mostek > > So, the patch looks to work. Nice one! > Is this last line a problem? Actually, I take all of what I just said back. Things should have been fine before, if drivers/char/rtc.c doesn't see the device, drivers/sbus/char/rtc.c will register itself so you will have a fully functioning /dev/rtc device. That "cannot find PC rtc device" message can be safely ignored. You should not use the patch I posted, because drivers/char/rtc.c does not program Mostek chips correctly, it may even scramble your eeprom. chrony probably only knows about the drivers/char/rtc.c ioctl calls, not the ones provided by Sparc's drivers/sbus/char/rtc.c driver (RTC_SET and RTC_GET). You can look in the util-linux sources to see how these two sets of ioctls() are probed for, /sbin/hwclock knows how to do it for example. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
Mike Edwards <[EMAIL PROTECTED]> writes: > On Tue, Apr 19, 2005 at 11:16:28PM +0200, Sebastian Niehaus said: > > , > > | radioactive:/home/niehaus# /usr/sbin/prtconv -pv > > | bash: /usr/sbin/prtconv: No such file or directory > > | radioactive:/home/niehaus# apt-cache search prtconv > > | radioactive:/home/niehaus# > > ` > > apt-get install sparc-utils , | radioactive:/home/niehaus# /usr/sbin/prtconv -pv | bash: /usr/sbin/prtconv: No such file or directory | radioactive:/home/niehaus# apt-cache policy sparc-utils | sparc-utils: | Installed: 1.9-2.3 | | [...] | | radioactive:/home/niehaus# cat /etc/debian_version | 3.1 | | | radioactive:/home/niehaus# /usr/sbin/prtconv -pb | bash: /usr/sbin/prtconv: No such file or directory ` Hmm, strange. I can't get it. Thanks, Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: inode issue with openpromfs [was Re: rtc and chrony on Ultra 1 and Ultra 5]
On Tue, 19 Apr 2005 17:02:29 -0400 Mike Edwards <[EMAIL PROTECTED]> wrote: > That reminds me... Yes, I've seen this before too. Openpromfs is due for a cleanup anyways, I'll try to get to fixing this at some point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On 19 Apr 2005 23:16:28 +0200 Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > Sorry for behaving like a complete moron :-( bash$ dpkg -S /usr/sbin/prtconf sparc-utils: /usr/sbin/prtconf bash$ So you need to: bash# apt-get install sparc-utils I'm surprised that package isn't in base at this point. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 22:57:43 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > Apr 19 22:32:32 localhost kernel: Real Time Clock Driver v1.12 > > Apr 19 22:32:32 localhost kernel: rtc: unable to get misc minor for Mostek > > So, the patch looks to work. Nice one! > Is this last line a problem? Not functionally, your machine should work fine. But it is a bug that wants fixing. drivers/sbus/char/rtc.c, function rtc_sun_init() should find a better test of whether drivers/char/rtc.c has probed a PCI rtc chip or not. I'll try to come up with something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tuesday 19 April 2005 21:15, David S. Miller wrote: > __sparc_v9__ should be set when compiling 64-bit code... > Can you add a "#error OK it is set" or something right under > the "#ifdef __sparc_v9__" to make sure? You are right, it is set. (Had to move the printk up a bit though because the original line I put it is skipped now that the RTC is recognized :-) Thanks a lot David. The RTC error was something that had been nagging me for some time. Cheers, Frans pgp5MVKD1T8Nr.pgp Description: PGP signature
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, Apr 19, 2005 at 11:16:28PM +0200, Sebastian Niehaus said: > , > | radioactive:/home/niehaus# /usr/sbin/prtconv -pv > | bash: /usr/sbin/prtconv: No such file or directory > | radioactive:/home/niehaus# apt-cache search prtconv > | radioactive:/home/niehaus# > ` apt-get install sparc-utils -- Mike Edwards <[EMAIL PROTECTED]> System Administrator Psychology Department, Rutgers University, Newark campus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
"David S. Miller" <[EMAIL PROTECTED]> writes: [...] > Anyways, "/usr/sbin/prtconf -pv" output would shed more light > on this problem. , | radioactive:/home/niehaus# /usr/sbin/prtconv -pv | bash: /usr/sbin/prtconv: No such file or directory | radioactive:/home/niehaus# apt-cache search prtconv | radioactive:/home/niehaus# ` Sorry for behaving like a complete moron :-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
inode issue with openpromfs [was Re: rtc and chrony on Ultra 1 and Ultra 5]
That reminds me... prtconf: Node 0xf0085810 manufacturer#: 0017 implementation#: 0011 mask#: 0020 sparc-version: 0009 ecache-associativity: 0001 ecache-line-size: 0040 ecache-size: 0020 #dtlb-entries: 0040 dcache-associativity: 0001 dcache-line-size: 0020 dcache-size: 4000 #itlb-entries: 0040 icache-associativity: 0002 icache-line-size: 0020 icache-size: 4000 upa-portid: clock-frequency: 11a49a00 reg: 01c0...0008 device_type: 'cpu' name: 'SUNW,UltraSPARC-II' Node 0xf0085b7c manufacturer#: 0017 implementation#: 0011 mask#: 0020 sparc-version: 0009 ecache-associativity: 0001 ecache-line-size: 0040 ecache-size: 0020 #dtlb-entries: 0040 dcache-associativity: 0001 dcache-line-size: 0020 dcache-size: 4000 #itlb-entries: 0040 icache-associativity: 0002 icache-line-size: 0020 icache-size: 4000 upa-portid: 0001 clock-frequency: 11a49a00 reg: 01c2...0008 device_type: 'cpu' name: 'SUNW,UltraSPARC-II' Note how certain pieces of information (upa-portid and reg, as well as the node #) differ, for obvious reasons (two cpus). openpromfs: $ ls -alid /proc/openprom/SUNW,UltraSPARC-II* 79 dr-xr-xr-x2 root root0 Apr 19 14:39 /proc/openprom/SUNW,[EMAIL PROTECTED],0 79 dr-xr-xr-x2 root root0 Apr 19 14:39 /proc/openprom/SUNW,[EMAIL PROTECTED],0 Same inode number. Of course, with the node name and inode number being the same, not all information available from openprom will be available via openpromfs... $ cat /proc/openprom/SUNW\,[EMAIL PROTECTED],0/upa-portid Wh? On Tue, Apr 19, 2005 at 12:30:53PM -0700, David S. Miller said: > Why did the rename the device node to "eeprom"? :-/ > > Node 0xf0066414 > address: fffba000 > reg: 0014..2000 > model: 'mk48t59' > name: 'eeprom' -- Mike Edwards <[EMAIL PROTECTED]> System Administrator Psychology Department, Rutgers University, Newark campus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tuesday 19 April 2005 21:30, David S. Miller wrote: > Give this patch a try (should apply cleanly to just about any 2.6.x) Except with my debug statements added... ;-) I've applied the patch and this is the result: Apr 19 22:32:32 localhost kernel: rtc_init: __sparc__ is set Apr 19 22:32:32 localhost kernel: rtc_init: ebus auxio Apr 19 22:32:32 localhost kernel: rtc_init: ebus power Apr 19 22:32:32 localhost kernel: rtc_init: ebus SUNW,pll Apr 19 22:32:32 localhost kernel: rtc_init: ebus se Apr 19 22:32:32 localhost kernel: rtc_init: ebus su Apr 19 22:32:32 localhost kernel: rtc_init: ebus su Apr 19 22:32:32 localhost kernel: rtc_init: ebus ecpp Apr 19 22:32:32 localhost kernel: rtc_init: ebus fdthree Apr 19 22:32:32 localhost kernel: rtc_init: ebus eeprom Apr 19 22:32:32 localhost kernel: Real Time Clock Driver v1.12 Apr 19 22:32:32 localhost kernel: rtc: unable to get misc minor for Mostek So, the patch looks to work. Nice one! Is this last line a problem? Cheers, Frans pgpgoxyjIeEyp.pgp Description: PGP signature
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 21:28:21 +0200
Frans Pop <[EMAIL PROTECTED]> wrote:
> On Tuesday 19 April 2005 20:47, David S. Miller wrote:
> > Can someone provide "/usr/sbin/prtconv -pv" on either the Ultra5 or
> > Ultra10 system which fails like this? It may provide the clue.
> Attached.
Why did the rename the device node to "eeprom"? :-/
Node 0xf0066414
address: fffba000
reg: 0014..2000
model: 'mk48t59'
name: 'eeprom'
That's your clock chip.
Give this patch a try (should apply cleanly to just about any 2.6.x)
drivers/char/rtc.c: 0af5fb0c19e378bc3c660c70873cdf22d806f9b8
--- drivers/char/rtc.c
+++ drivers/char/rtc.c 2005-04-19 12:29:00.0 -0700
@@ -889,6 +889,28 @@
static irqreturn_t (*rtc_int_handler_ptr)(int irq, void *dev_id, struct
pt_regs *regs);
#endif
+#ifdef __sparc__
+static int is_rtc_device(char *name, int prom_node)
+{
+ unsigned char model[32];
+
+ if (!strcmp(name, "rtc"))
+ return 1;
+
+ prom_getstring(prom_node, "model", model, sizeof(model));
+ if (!strcmp(model, "mk48t02") ||
+ !strcmp(model, "mk48t08") ||
+ !strcmp(model, "mk48t59") ||
+ !strcmp(model, "m5819") ||
+ !strcmp(model, "m5819p") ||
+ !strcmp(model, "m5823") ||
+ !strcmp(model, "ds1287"))
+ return 1;
+
+ return 0;
+}
+#endif
+
static int __init rtc_init(void)
{
struct proc_dir_entry *ent;
@@ -909,7 +931,8 @@
#ifdef __sparc__
for_each_ebus(ebus) {
for_each_ebusdev(edev, ebus) {
- if(strcmp(edev->prom_name, "rtc") == 0) {
+ if (is_rtc_device(edev->prom_name,
+ edev->prom_node)) {
rtc_port = edev->resource[0].start;
rtc_irq = edev->irqs[0];
goto found;
@@ -919,7 +942,8 @@
#ifdef __sparc_v9__
for_each_isa(isa_br) {
for_each_isadev(isa_dev, isa_br) {
- if (strcmp(isa_dev->prom_name, "rtc") == 0) {
+ if (is_rtc_device(isa_dev->prom_name,
+ isa_dev->prom_node)) {
rtc_port = isa_dev->resource.start;
rtc_irq = isa_dev->irq;
goto found;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tue, 19 Apr 2005 21:07:34 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > I've added a debug statement in this code, which gives the following output: > Apr 19 20:39:22 localhost kernel: rtc_init: ebus auxio > Apr 19 20:39:22 localhost kernel: rtc_init: ebus power > Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,pll > Apr 19 20:39:22 localhost kernel: rtc_init: ebus se > Apr 19 20:39:22 localhost kernel: rtc_init: ebus su > Apr 19 20:39:22 localhost kernel: rtc_init: ebus su > Apr 19 20:39:22 localhost kernel: rtc_init: ebus ecpp > Apr 19 20:39:22 localhost kernel: rtc_init: ebus fdthree > Apr 19 20:39:22 localhost kernel: rtc_init: ebus eeprom > Apr 19 20:39:22 localhost kernel: rtc_init: ebus flashprom > Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,CS4231 > Apr 19 20:39:22 localhost kernel: rtc_init: no PC rtc found > > So, apparently __sparc__ is defined for my U10. I also added a similar > statement in the isa bus scan, so __sparc_v9__ is not set. > > Any ideas where the RTC could be hiding? __sparc_v9__ should be set when compiling 64-bit code... Can you add a "#error OK it is set" or something right under the "#ifdef __sparc_v9__" to make sure? If you added debugging to the ISA loop and it didn't print out, this just means that your box lacks that bus type. Anyways, "/usr/sbin/prtconf -pv" output would shed more light on this problem. Thanks for your debugging so far. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tuesday 19 April 2005 20:47, David S. Miller wrote: > Can someone provide "/usr/sbin/prtconv -pv" on either the Ultra5 or > Ultra10 system which fails like this? It may provide the clue. Attached. > Also, is this with a 2.4.x or 2.6.x kernel? I'm currently using the Debian 2.6.8 kernel, but IIRC the problem is the same for both kernels (I checked that a while back). Cheers, Frans Pop System Configuration: Sun Microsystems sun4u Memory size: 1024 Megabytes System Peripherals (PROM Nodes): Node 0xf00297e4 power-cycle-limit: '3000' reset-reason: 'S-POR' idprom: 01800800.209c14f5..9c14f5a9.... interrupt-map: 003c...f005f31c.8033 interrupt-map-mask: 003e.. #interrupt-cells: 0001 #address-cells: 0002 breakpoint-trap: 007f #size-cells: 0002 energystar-v2: model: 'SUNW,375-0009' name: 'SUNW,Ultra-5_10' clock-frequency: 05f4bc7f banner-name: 'Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 300MHz)' device_type: 'upa' Node 0xf002ca28 name: 'packages' Node 0xf0033adc iso6429-1983-colors: name: 'terminal-emulator' Node 0xf0036810 disk-write-fix: name: 'deblocker' Node 0xf0036ed4 name: 'obp-tftp' Node 0xf0040b34 name: 'disk-label' Node 0xf005afc0 name: 'SUNW,builtin-drivers' Node 0xf0068c94 name: 'sun-keyboard' Node 0xf002ca98 stdout: fff9b5e8 stdin: fff9b860 mmu: fffe8438 memory: fffe8638 bootargs: 00 bootpath: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:a' gateway-ip: server-ip: client-ip: stdout-#lines: 0022 name: 'chosen' Node 0xf002cb04 version: 'OBP 3.11.9 1998/03/06 10:31' model: 'SUNW,3.11' decode-complete: aligned-allocator: relative-addressing: name: 'openprom' Node 0xf002cb94 name: 'client-services' Node 0xf002cc3c tpe-link-test?: 'true' scsi-initiator-id: '7' keyboard-click?: 'false' keymap: ttyb-rts-dtr-off: 'false' ttyb-ignore-cd: 'true' ttya-rts-dtr-off: 'false' ttya-ignore-cd: 'true' ttyb-mode: '9600,8,n,1,-' ttya-mode: '9600,8,n,1,-' pcia-probe-list: '1,2,3,4' pcib-probe-list: '1,2,3' mfg-mode: 'off' diag-level: 'max' #power-cycles: '399' system-board-serial#: system-board-date: fcode-debug?: 'false' output-device: 'screen' input-device: 'keyboard' load-base: '16384' boot-command: 'boot' auto-boot?: 'false' watchdog-reboot?: 'false' diag-file: diag-device: 'net' boot-file: boot-device: 'disk' local-mac-address?: 'false' ansi-terminal?: 'true' screen-#columns: '80' screen-#rows: '34' silent-mode?: 'false' use-nvramrc?: 'false' nvramrc: security-mode: 'none' security-password: security-#badlogins: '0' oem-logo: oem-logo?: 'false' oem-banner: oem-banner?: 'false' hardware-revision: last-hardware-update: diag-switch?: 'false' name: 'options' Node 0xf002ccac screen: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/SUNW,[EMAIL PROTECTED]' net: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED],1' cdrom: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0:f' disk: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' disk3: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' disk2: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' disk1: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' disk0: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],0' ide: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]' floppy: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/fdthree' ttyb: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/se:b' ttya: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/se:a' keyboard!: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],3083f8:forcemode' keyboard: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],3083f8' mouse: '/[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL PROTECTED],3062f8' name: 'alias
Re: rtc and chrony on Ultra 1 and Ultra 5
On 19 Apr 2005 14:32:39 +0200 Sebastian Niehaus <[EMAIL PROTECTED]> wrote: > Frans Pop <[EMAIL PROTECTED]> writes: > > > On Tuesday 19 April 2005 12:33, Sebastian Niehaus wrote: > > > | radioactive:/home/niehaus# dmesg | grep -i rtc > > > | rtc_init: no PC rtc found > > > > I have the same problem on my Ultra 10. > > I don't really get it as there is an RTC present in the system > > There must be one since the date is set up quite correctly even > without network. On the Ultra1, the drivers/sbus/char/rtc.c driver is used. It is very strange to see the "rtc_init: no PC rtc found" message on an Ultra5 or Ultra10, as drivers/char/rtc.c is the driver that should be used on that platform. Can someone provide "/usr/sbin/prtconv -pv" on either the Ultra5 or Ultra10 system which fails like this? It may provide the clue. Also, is this with a 2.4.x or 2.6.x kernel? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tuesday 19 April 2005 13:24, Frans Pop wrote:
> ./drivers/char/rtc.c has this code:
>
> #ifdef __sparc__
> for_each_ebus(ebus) {
> for_each_ebusdev(edev, ebus) {
printk(KERN_INFO "rtc_init: ebus %s\n",
edev->prom_name);
> if(strcmp(edev->prom_name, "rtc") == 0) {
> rtc_port = edev->resource[0].start;
> rtc_irq = edev->irqs[0];
> goto found;
> }
> }
> }
>
I've added a debug statement in this code, which gives the following output:
Apr 19 20:39:22 localhost kernel: rtc_init: ebus auxio
Apr 19 20:39:22 localhost kernel: rtc_init: ebus power
Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,pll
Apr 19 20:39:22 localhost kernel: rtc_init: ebus se
Apr 19 20:39:22 localhost kernel: rtc_init: ebus su
Apr 19 20:39:22 localhost kernel: rtc_init: ebus su
Apr 19 20:39:22 localhost kernel: rtc_init: ebus ecpp
Apr 19 20:39:22 localhost kernel: rtc_init: ebus fdthree
Apr 19 20:39:22 localhost kernel: rtc_init: ebus eeprom
Apr 19 20:39:22 localhost kernel: rtc_init: ebus flashprom
Apr 19 20:39:22 localhost kernel: rtc_init: ebus SUNW,CS4231
Apr 19 20:39:22 localhost kernel: rtc_init: no PC rtc found
So, apparently __sparc__ is defined for my U10. I also added a similar
statement in the isa bus scan, so __sparc_v9__ is not set.
Any ideas where the RTC could be hiding?
pgpB56GPaYMeu.pgp
Description: PGP signature
Re: rtc and chrony on Ultra 1 and Ultra 5
Frans Pop <[EMAIL PROTECTED]> writes: > On Tuesday 19 April 2005 12:33, Sebastian Niehaus wrote: > > | radioactive:/home/niehaus# dmesg | grep -i rtc > > | rtc_init: no PC rtc found > > I have the same problem on my Ultra 10. > I don't really get it as there is an RTC present in the system There must be one since the date is set up quite correctly even without network. [...] > In the kernel config (Debian's 2.6.8), I have CONFIG_SUN_MOSTEK_RTC > enabled. , | radioactive:/home/niehaus# grep -i rtc /boot/config-2.4.27-1-sparc64 | CONFIG_RTC=y | CONFIG_SUN_MOSTEK_RTC=y | radioactive:/home/niehaus# ` >The Mostek RTC chip is used on all known Sun computers except >some JavaStations. For a JavaStation you need to say Y both here >and to "Enhanced Real Time Clock Support". That's what I read as well Thanks, Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rtc and chrony on Ultra 1 and Ultra 5
On Tuesday 19 April 2005 12:33, Sebastian Niehaus wrote:
> | radioactive:/home/niehaus# dmesg | grep -i rtc
> | rtc_init: no PC rtc found
I have the same problem on my Ultra 10.
I don't really get it as there is an RTC present in the system (OpenBoot's
watch-clock works) and as it seems the kernel should have support for it.
./drivers/char/rtc.c has this code:
#ifdef __sparc__
for_each_ebus(ebus) {
for_each_ebusdev(edev, ebus) {
if(strcmp(edev->prom_name, "rtc") == 0) {
rtc_port = edev->resource[0].start;
rtc_irq = edev->irqs[0];
goto found;
}
}
}
#ifdef __sparc_v9__
for_each_isa(isa_br) {
for_each_isadev(isa_dev, isa_br) {
if (strcmp(isa_dev->prom_name, "rtc") == 0) {
rtc_port = isa_dev->resource.start;
rtc_irq = isa_dev->irq;
goto found;
}
}
}
#endif
printk(KERN_ERR "rtc_init: no PC rtc found\n");
return -EIO;
It looks like this is failing somehow or missing something...
In the kernel config (Debian's 2.6.8), I have CONFIG_SUN_MOSTEK_RTC
enabled. From the kernel config help:
The Mostek RTC chip is used on all known Sun computers except
some JavaStations. For a JavaStation you need to say Y both here
and to "Enhanced Real Time Clock Support".
Is that correct?
"Enhanced Real Time Clock Support" (CONFIG_RTC) is enabled by default and
AFAICT can not be configured.
Cheers,
Frans Pop
pgpMfODM2Ng7z.pgp
Description: PGP signature
rtc and chrony on Ultra 1 and Ultra 5
Hi,
I am kernel running 2.4.27 on my Ultra 1 and Ultra 5.
If I comment in ("remove the hash in front of")
| rtcfile /var/lib/chrony/chrony.rtc
in /etc/chrony/chrony.conf chrony trashes syslog on start:
,
| Apr 19 11:57:05 radioactive chronyd[767]: chronyd version V1_20 starting
| Apr 19 11:57:05 radioactive chronyd[767]: Initial txc.tick=10001
txc.freq=-147469 (-2.25019836) txc.offset=0 => hz=100 shift_hz=7
| Apr 19 11:57:05 radioactive chronyd[767]: set_config_hz=0 hz=100 shift_hz=7
basic_freq_scale=1.2800 nominal_tick=1 slew_delta_tick=833
max_tick_bias=1000
| Apr 19 11:57:05 radioactive chronyd[767]: Linux kernel major=2 minor=4
patch=27
| Apr 19 11:57:05 radioactive chronyd[767]: calculated_freq_scale=0.99902439
freq_scale=0.99902439
| Apr 19 11:57:05 radioactive chronyd[767]: Could not start measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not stop measurement :
Invalid argument
| Apr 19 11:57:05 radioactive chronyd[767]: Could not read flags /dev/rtc :
Invalid argument
|
| [...]
|
`
The lines right above that entry in the chrony configuration file say:
,
| # Specify the file where real-time clock data is stored. To use this you
| # must have enhanced real-time clock support compiled into your kernel.
| # Comment out the next line if you do not. Note: I have seen problems with
| # the rtc on some motherboards. Please file a bug if this bites you.
|
| # rtcfile /var/lib/chrony/chrony.rtc
`
I am not sure If I have to file a bug report for chrony or ...
,
| radioactive:/home/niehaus# dmesg | grep -i rtc
| rtc_init: no PC rtc found
`
.. if there is a (sun specific?) configuration problem. Any hints out
there?
Thanks for reading and thinking about this!
Sebastian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
