Skip to contentSkip to conversation

module mess in -CURRENT

DISCUSSION Andi Kleen 7 participants 10 messages Nov 14, 2002 – Nov 15, 2002 2 messages not in the archive

lore
Share & tools
lore

Andi Kleen

author
#2 lore raw
In reply to a message not in the archive
Quoted 4 lines · Linus Torvalds

(There are some other patches I'm still thinking about, notably kprobes and posix timers, but other than that my plate is fairly empty froma feature standpoint. And the kexec stuff I want others to test, at least now it's palatable to me).

How about the nanosecond stat stuff? It is needed for reliable make.

If I sent you a patch would you still consider it? It is not that intrusive, but needs straightforward editing in all file systems.

-Andi

#3 lore raw
Quoted 7 lines · Andi Kleen
Quoted 4 lines · Linus Torvalds

(There are some other patches I'm still thinking about, notably kprobes and posix timers, but other than that my plate is fairly empty froma feature standpoint. And the kexec stuff I want others to test, at least now it's palatable to me).

Quoted 5 lines

How about the nanosecond stat stuff? It is needed for reliable make.

If I sent you a patch would you still consider it? It is not that intrusive, but needs straightforward editing in all file systems.

Owens' kbuild-2.5 handled it a different way and didn't need exact timings. That is especially important since nanosecond time accuracy is impossible if you are handling a collection of machines doing the work. NTP is accurate, but not that accurate.

john

author
#4 lore raw
Quoted 2 lines

Owens' kbuild-2.5 handled it a different way and didn't need exact timings. That is especially important since nanosecond time accuracy is

You may not believe it, but there are projects other than the kernel that do use make too.

Quoted 2 lines

impossible if you are handling a collection of machines doing the work. NTP is accurate, but not that accurate.

The patch does not actually implement nanosecond resolution, but jiffies resolution (1ms on 2.5), which is easily reachable with NTP.

-Andi

#5 lore raw
Quoted 11 lines · Andi Kleen
Quoted 2 lines

Owens' kbuild-2.5 handled it a different way and didn't need exact timings. That is especially important since nanosecond time accuracy is

You may not believe it, but there are projects other than the kernel that do use make too.

Quoted 2 lines

impossible if you are handling a collection of machines doing the work. NTP is accurate, but not that accurate.

The patch does not actually implement nanosecond resolution, but jiffies resolution (1ms on 2.5), which is easily reachable with NTP.

1msec still leave a reasonable window open IMHO. this problem would need sequence numbers updated atomically to be solved correctly without regard to the timing that may vary depending on the hardware IMHO (so that it could still work on a 1Thz cpu even if it's not a pratical matter for at least this decade).

Andrea

author
#6 lore raw
Quoted 10 lines · Andrea Arcangeli
Quoted 9 lines · Andi Kleen
Quoted 2 lines

Owens' kbuild-2.5 handled it a different way and didn't need exact timings. That is especially important since nanosecond time accuracy is

You may not believe it, but there are projects other than the kernel that do use make too.

Quoted 2 lines

impossible if you are handling a collection of machines doing the work. NTP is accurate, but not that accurate.

Quoted 9 lines
Quoted 2 lines

The patch does not actually implement nanosecond resolution, but jiffies resolution (1ms on 2.5), which is easily reachable with NTP.

1msec still leave a reasonable window open IMHO. this problem would need sequence numbers updated atomically to be solved correctly without regard to the timing that may vary depending on the hardware IMHO (so that it could still work on a 1Thz cpu even if it's not a pratical matter for at least this decade).

The API is ready for nanoseconds so when you feel the need you can convert it to using do_gettimeofday()

-Andi

#7 lore raw
In reply to Andrea Arcangeli
Quoted 3 lines · Andrea Arcangeli

1msec still leave a reasonable window open IMHO. this problem would need sequence numbers updated atomically to be solved correctly without regard to the timing

I agree 100% - it would be nice to be correct instead of "usually works".

Once you're talking about nanoseconds, you can have both: each time you store an mtime, make sure the value is at least 1 nanosecond greater than the previously stored mtime for any file in the serialisation domain. If it is not, simply _wait_ for up to a nanosecond until the value has advanced enough.

-- Jamie

#8 lore raw
Quoted 6 lines · Jamie Lokier

Once you're talking about nanoseconds, you can have both: each time you store an mtime, make sure the value is at least 1 nanosecond greater than the previously stored mtime for any file in the serialisation domain. If it is not, simply _wait_ for up to a nanosecond until the value has advanced enough.

Note that the fields already _are_ nanoseconds, it's just not updated at a nanosecond rate. We're updating xtime only at a rate of HZ, where the 1 ms comes from in 2.5.x.

And doing a full "gettimeofday()" sounds just a bit too expensive for the stuff that needs to just update an inode time field.

But the thing is, we don't actually care about the exact time, we only care about it being monotonically increasing, so I suspect we could just have something like

	static unsigned long xtime_count;

	static struct timespec current_time(void)
	{
		struct timespec val;
		unsigned long extra;

		read_lock_irq(&xtime_lock);
		val = xtime;
		extra = xtime_count;
		xtime_count = extra+1;
		read_unlock_irq(&xtime_lock);

		val.nsec += count;
		if (val.tv_nsec > 1000000000) {
			val.tv_nsec -= 1000000000;
			val.tv_sec ++;
		}
		return val;
	}

and then have the timer clear "xtime_count" every time it updates it.

This obviously doesn't give us nanosecond resolution, but it _does_ give us "unique" timestamps (assuming a system call takes longer than a nanosecond, which is likely true for the next decade or so - after that we can start worrying about whether the users might be outrunning the clock).

Linus

author
#9 lore raw
Quoted 1 line

and then have the timer clear "xtime_count" every time it updates it.

Problem is that you cannot easily synchronize such a monotonously increasing timer in a network. But make needs synchronized times.

-Andi

#11 lore raw

Linux 2.5.47 -- Trouble booting Xwindows

In reply to Linus Torvalds

I am trying to set up 2.5.47. This is my first time building a kernel from scratch, and I've managed to boot as far as runlevel 3. However, when I attempt to boot at runlevel 5, the screen goes black and I have to cycle power. I'm guessing I have something set wrong for my video card. I have included output from dmesg, lspci, and my config. I would appreciate any help.

Thank you.
Mark

Linux version 2.4.18-3 ([email protected]) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110)) #1 Thu Apr 18 07:37:53 EDT 2002 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line: ro root=/dev/hde2
Initializing CPU#0
Detected 996.578 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1985.74 BogoMIPS
Memory: 255440k/262080k available (1119k kernel code, 6252k reserved, 775k data, 280k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.

CPU:     After generic, caps: 0383fbff 00000000 00000000 00000000
CPU:             Common caps: 0383fbff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 0a

Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfdb01, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16)
Starting kswapd
VFS: Diskquotas version dquot_6.5.0 initialized
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10e
block: 496 slots per queue, batch=124
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1

    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio

PDC20265: IDE controller on PCI bus 00 dev 80
PCI: Found IRQ 11 for device 00:10.0
PDC20265: chipset revision 2
ide: Found promise 20265 in RAID mode.
PDC20265: not 100% native mode: will probe irqs later
PDC20265: ROM enabled at 0xdffc0000
PDC20265: (U)DMA Burst Bit ENABLED Primary MASTER Mode Secondary MASTER Mode.

    ide2: BM-DMA at 0xcc00-0xcc07, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdg:DMA, hdh:pio

hdc: SR243T, ATAPI CD/DVD-ROM drive
hde: WDC WD400BB-32BSA0, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xdc00-0xdc07,0xd802 on irq 11
blk: queue c035ed6c, I/O limit 4095Mb (mask 0xffffffff)
hde: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63, UDMA(100) ide-floppy driver 0.99.newide
Partition check:
hde: hde1 hde2 hde3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ide-floppy driver 0.99.newide
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 122k freed
VFS: Mounted root (ext2 filesystem).
Journalled Block Device driver loaded
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 280k freed
Adding Swap: 524152k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 07:43:07 Apr 18 2002
usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 5 for device 00:07.3
PCI: Sharing IRQ 5 with 00:07.2
PCI: Sharing IRQ 5 with 00:0f.0
usb-uhci.c: USB UHCI at I/O 0xc000, IRQ 5
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 5 for device 00:07.2
PCI: Sharing IRQ 5 with 00:07.3
PCI: Sharing IRQ 5 with 00:0f.0
usb-uhci.c: USB UHCI at I/O 0xbc00, IRQ 5
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide2(33,2), internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide2(33,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ide-floppy driver 0.99.newide
hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdc: DMA disabled
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport_pc: Via 686A parallel port: io=0x378
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
PCI: Found IRQ 5 for device 00:0f.0
PCI: Sharing IRQ 5 with 00:07.3
PCI: Sharing IRQ 5 with 00:07.2
eth0: OEM i82557/i82558 10/100 Ethernet, 00:20:ED:06:9B:B7, IRQ 5.
Board assembly 727095-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
PCI: Found IRQ 3 for device 00:0e.0
eth1: OEM i82557/i82558 10/100 Ethernet, 00:20:ED:06:9B:B6, IRQ 3.
Board assembly 727095-004, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).

00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. USB (rev 10)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:0e.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:0f.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:10.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage XL AGP 2X (rev 27)

#10 lore raw
In reply to Andi Kleen

[email protected] (Andi Kleen) wrote on 15.11.02 in <[email protected]>:

Quoted 4 lines
Quoted 1 line

and then have the timer clear "xtime_count" every time it updates it.

Problem is that you cannot easily synchronize such a monotonously increasing timer in a network. But make needs synchronized times.

That's really a make problem. It gets much worse when you count in times going backwards because you restore a file from backup, or whatever.

What I'd really like make to do - but it can't with the current design - is to note the exact time stamp of each dependency when creating a target, and when reconsidering that target, finding out if any of those time stamps have changed in any way (and, while we're at it, probably check the size as well). *Changed since last time*, not younger than the target.

But of course to do that, you need a persistent repository for those time stamps - which, I think, kbuild-Owen does.

If you think about the more tricky things to do with make, this is almost always what you would need to make a solution much easier.

Take network time shift, for example. Once you no longer need a younger- older relation, that time shift is actually completely irrelevant!

One of these days, when I have lots of time (as if!) ...

MfG Kai