Linux 2.4.4-ac10

Linux 2.4.4-ac10

[Alan Cox]

 	     ftp://ftp.linux.org.uk/pub/linux/alan/2.4-ac/

		 Intermediate diffs are available from
			http://www.bzimage.org

Ok we are back on kernel.org

2.4.4-ac10
o	Move cs46xx docs into the right spot		(Arjan van de Ven)
o	Merge Linus 2.4.5pre3
	- switch to Linus page fault race fixes
	- switch to Linus arch/ppc
	- merged serial driver cli fixes but also
	  added an extra missing moxa check
	- used -ac better version of comx fix
	- used -ac better version of scsi fix
	- now 2.4.5pre vm seems sane dump other vmscan
	  experiments
	[not merged; rage-xl code]

2.4.4-ac9
o	Clean up x86isms from the UML code		(Chris Emerson)
o	Remove un-needed UML flag,fix hang under load	(Jeff Dike)
o	Fix attach race	in UML				(Jeff Dike)
o	Fix warnings, clean up cpp abuses in UML	(Roman Zippel)
o	Remove -D__KERNEL__ from user space of UML	(Roman Zippel)
o	Add NCR53c700 and 53c700/66 driver		(James Bottomley)
	|For NCR Dual 700 microchannel card
o	Alpha semaphore updates				(Ivan Kokshaysky)
p	Fix ibmtr build a bit			(Andrzej Krzysztofowicz)
o	Tidy sysrq-t output				(Russell King)
o	Fix miata halt to SRM				(Tom Vier)
o	Fix aging on buffer cache pages			(Marcelo Tosatti)
o	Fix looping behaviour on failing memory 	(Marcelo Tosatti)
	allocations
o	Handle the PIIX4 on the new intel 82801BAM	(Tim Raymond)
o	Fix user visible -ENOIOCTLCMD returns		(Shane Wegner)
o	Fix startech uart detection problem		(Val Henson)
o	Further tulip updates				(Jeff Garzik)
o	Revert hpt366 patch

2.4.4-ac8
o	Prefetch constant copy_to_user data		(Arjan van de Ven)
o	Update cpqarray driver - use pci dma api	(Charles White)
o	Update cciss driver - use pci dma api		(Charles White)
o	Enable compiled in synclink driver		(Paul Fulghum)
o	Fix plip section conflict			(Keith Owens)
o	Tulip driver updates				(Jeff Garzik)
o	Frame buffer logo updates			(Geert Uytterhoeven)
o	Update __initdata documentation			(Ingo Oeser)
o	Linearize sunrpc buffers using GFP_KERNEL	(Trond Myklebust)
o	C Scott Ananian has moved			(C Scott Ananian)
o	Update get_unaligned docs			(John Levon)
o	Fix pci pool handling on boxes that have non	(Pete Zaitcev)
	irq safe map create/destroy
o	Update m68k semaphores				(Geert Uytterhoeven)
o	Update NLS Configure.help			(Nerijus Baliunas)
o	Clean up cyclom driver			(Arnaldo Carvalho de Melo)
o	Further serial driver update			(Jeff Garzik)
o	Fix typo in sched.c				(Jim Freeman)
o	Do prefetches on wake_up_common walk		(Arjan van de Ven)
o	Fix bootmem init problems			(Andrea Arcangeli)
o	Fix pops on cs46xx power management		(Thomas Woller)
o	Fix reference of freed memory in cs46xx		(Christopher Kanaan)
o	Hopefully fix i2o scsi reset crash		(me)

2.4.4-ac7
o	Fix dasd off by one found by Al Viro		(me)
o	Fix copy under cli in
	moxa,mxser,pcxx,riscom8
o	Cleaned up serial167 formatting (no code	(me)
	changes this patch set)
o	Fix missing length check in AGPgart		(me)
	| Found by Al Viro
o	Fix wrong kmalloc sizes in ixj/emu10k1		(David Chan)
o	Fix make distclean on ramfs/tmpfs		(Ingo Oeser)
o	Update checkconfig, Changes			(Niels Jensen)
o	NFS mmap consistency on close fix		(Andrea Arcangeli)
o	Fix 10 bit decode causing APM hang on a laptop	(Pete Zaitcev)
	when using ymfpci
o	Reserve failure on vesa video ram is not fatal	(Jordan Crouse)
o	Update athlon mmx copier to not prefetch off	(Arjan van de Ven)
	the end
o	Fix scsi.c procfs zero termination checks	(Al Viro)
o	And fix -EFAULT returns from it			(me)
o	Update ibm token ring driver			(Mike Phillips)
o	Fix sockfilter maths overflow			(Al Viro)
o	Make dev name lookup robust to nonterminated	(Al Viro)
	buffers
o	Update config.h use				(Niels Jensen)
o	Fix xircom cardbus ethernet/modem support	(Bill Nottingham)
o	Fix off by one buffer checks in atm_poa and	(Al Viro)
	dasd
o	Clean up printks in zr36067.c			(me)

2.4.4-ac6
o	Revert dead swap patch pending fixes		(Dave Miller)
o	Allow arch specific writeproc/DMA for IDE	(Bjorn Wesen)
o	Move to aic7xxx 6.1.13				(Justin Gibbs)
o	Use pci_set_master on eni.c			(Jeff Garzik)
o	Update wireless drivers, add airport		(Jean Tourrihles,
							Benjamin Herrenschmidt)
o	Add new pci ids, clean up dup defines in eicon	(Jeff Garzik)
o	Add module loader to kernel docs		(Erik Mouw)
o	Fix wanrouter makefile bug		(Arnaldo Carvalho de Melo)
o	Add another pair of idents to the yenta driver  (Alexandr Kanevskiy)
o	Parport fixes for 1284 mode			(Fred Barnes)
o	Update 8139too driver to handle wakeup bug	(Jeff Garzik)
o	Add koi8-ru locale              		(Andrzej Krzysztofowicz)
o       Add ICH3 to the i810 audio driver		(Tom Woller)
o	Improve (hopefully) the confusing I82365 help   (me)
o	Fix a bug in koi8-u tables			(Andrzej Krzysztofowicz)
o	Fix a bug in UTF8->CP1255			(Andrzej Krzysztofowicz)
o	Fix a bug in iso8859-13 tables			(Andrzej Krzysztofowicz)
o	Update gdth driver to current vendor release    (Achim Leubner)
o	Kill cpia_write_proc (its insecure)		(Al Viro, me)
o	Fix unterminated array strtoul() in comx	(Al Viro)
o	Fix TCP send path leak				(Dave Miller)
o	Restore older skb_cow() headroom behaviour	(Dave Miller)
o	Fix ipv6 oops					(Dave Miller)
o	Small ipx tidy up			(Arnaldo Carvalho de Melo)
o	Fix unprotected userspace reference in trident  (Al Viro)
	audio
o	Fix expand stack locking			(Manfred Spraul)
o	Fix offslab_limit calculation			(Manfred Spraul)
o	EATA and U14F updates				(Dario Ballabio)
o	Update scsi generic to 3.1.18			(Doug Gilbert)
o	Clean up abs() 					(Kai Germaschewski)
	| This needs further checking
o	ymfpci update					(Pete Zaitcev)
o	Quota code updates				(Jan Kara)
o	Clean up eicon include abuse			(me)

2.4.4-ac5
o	Fix DMA setup on hpt366/370			(Tim Hockin)
o	DRM memory alloc failure checks			(Akash Jain)
o	Remove bogus fs/buffer.c diff			(Ben LaHaise)
o	cs46xx update - adds Hercules Game Theatre XP	(Thomas Woller)
o	Fix menuconfig breakage with ()		(Andrzej Krzysztofowicz)
o	Updated multithreaded core dump support		(Don Dugger)
o	Remove dead ibmtr.h include			(Mike Phillips)
o	Fix misplaced letters in koi8-u			(Andriy Rysin)
o	Further alpha module locking fix		(Andrea Arcangeli)
o	Keyspan bitwidth fixes				(Hugh Blemings)
o	usb-uhci oops fix				(Pete Zaitcev)
o	Add ability to specify preferred minor on 	(Gerd Knorr)
	video/radio4linux devices
o	Further IPX updates			(Arnaldo Carvalho de Melo)
o	Further IRDA updates				(Dag Brattli)
o	Make x86 ptrace framesize a define (code clean)	(Pavel Machek)
o	Moxa serial tidy				(Tim Hockin)
o	Fix tiny select race				(Rusty Russell)
o	Update aic7xxx to 6.1.12			(Justin Gibbs)
o	Alpha was missing rwlock_init			(Reto Baettig)
o	Alpha SCHED_YIELD was broken on UP		(Andrea Arcangeli)
o	Allow IRQ sharingon more PCI ide		(Pete Zaitcev)
o	Fix capable checks found by Stanford analyser	(me)
	for cciss/cpqarray
o	List more devices in sysrq table	(Andrzej Krzysztofowicz)
o	Run uml exit callbacks reverse to init		(Andrew Morton)
o	Fix SMP resched_idle pre-emption bug		(Nigel Gamble)
o	Work around config problem with menuconfig
	and USB					(Andrzej Krzysztofowicz)
o	Fix nasty bug in Alpha PCI mapping		(Hyung Min SEO)
	| Nautilus specific stuff not applied yet
o	SBLive endianness fixes	(output only so far)	(Ira Weiny)
o	Move sblive pci_enable earlier			(Marcus Meissner)
o	Merge IBM ServeRAID 4.72 driver			(Keith Mitchell)
o	Fix affs races					(Roman Zippel)
o	Fix cdrom unload crash			(Andrzej Krzysztofowicz)

2.4.4-ac4
o	Fix future domain scsi				(Carlo Prelz)
o	Merge Linux 2.4.5pre1
o	Fix ipx without sysctl compile			(Pavel Roskin)
o	Revert fork changes to match Linus 2.4.5pre1
o	Drop the threaded core dump code
	| It can go back in when it works
o	Drop pa-risc work - it'll be easier to resync
	just once as pa has moved on a lot
o	Add spin_lock_prefetch to get_empty_inode	(me)
	| Experimenting
o	Kbuild has moved				(Keith Owens)
o	Update kernel docs on memory barriers		(Rusty Russell)
o	Move es1370 pci_enable and do some cleanup	(Marcus Meissner)
o	Fix netfilter overuse of __exit			(Rusty Russell)
o	Fix alpha build bug				(Michal Jaegermann)
o	Fix tigon1 build				(Olivier Galibert)
o	Fix tmpfs deadlocks writing into a file from	(Christoph Rohland)
	an mmap of itself
o	Fix missing (but harmless) return in vmtruncate	(Al Viro)

2.4.4-ac3
o	Fix hang on boot with SMP			(Andrea Arcangeli)
	| and fixes a few more uglies too
o	freevxfs module name was wrong (should be	(me)
	freevxfs.o)
o	Update alloc_etherdev docs			(Erik Mouw)
o	Remove dead funcs, put back ip_set_manually	(David Miller,
	in the ipconfig code			(Arnaldo Carvalho de Melo)
o	Fix SA_ONSTACK standards violation (for x86)	(Christian Ehrhardt)
	| Other arch maintainers should check..
o	Add another species of SB AWE 32		(Bill Nottingham)
o	SE401 USB camera driver				(Jeroen Vreeken)
o	Correct MAX_HD and make stuff static in ps2esdi	(Hal Duston)
o	Fix inode-nr corruption				(Al Viro)
o	Fix pgd_alloc for user mode linux		(Jeff Dike)
o	Fix UML hostfs for get_hardsect_size		(Jeff Dike)
o	Tidy up APM options setting, add module opts	(Stephen Rothwell)
o	Fix acm open race				(Oliver Neukum)
o	Further bounce buffer fixes			(Arjan van de Ven)
o	ACPI updates					(Andrew Grover)
o	Move pci_enable_device earlier on via audio	(Arjan van de Ven)

2.4.4-ac2
o	Remove some spurious whitespace differences 	(me)
	between trees
o	Make the VIA timer reload check test avoid 	(me)
	tripping on a timer as it rolls back to zero
o	Drop dasdfmt man page changes (dos ^M noise)	(me)
o	Drop experimental iee1284 pnp module loading	(me)
o	Revert pcnet32 chance causing compile errors	(me)
o	Remove wrong __init in sunhme			(Dave Miller)
o	Fix overlarge udely in aironet4500		(Arjan van de Ven)
o	Remove non existant parameter from aironet4500	(Keith Owens)
o	Kill duplicate aic7xxx include		(Andrzej Krzysztofowicz)
o	Fix pci2220i scsi compile bug			(Matt Domsch)
o	Fix module exception race on Alpha		(Andrea Arcangeli)
o	Disable broken large vmalloc support on Alpha	(Andrea Arcangeli)
o	Remove dead ia64 config entries			(Steven Cole)
o	Add kbuild list info to MAINTAINERS		(Steven Cole)
o	linux appletalk list has moved		(Arnaldo Carvalho de Melo)
o	Revert wrong mount changes in 2.4.4		(Andries Brouwer)
o	Revert drivers/scsi/scsi.c change in 2.4.4	(me)
	that subtly broke about 15 drivers
o	Fix typo in slab.h				(Pavel Machek)
o	More correct child favouring fork behaviour	(Peter Österlund)
o	Only apply pci fixups if there is a VIA 686B	(Charl Botha)
o	Fix GDT padding error introduced by PnPBIOS	(Brian Gerst)
	support
o	Fix UML build without CONFIG_PT_PROXY		(Jeff Dike)
o	dmfe wasnt calling dev_alloc_skb		(Tobias Ringstrom)
o	Further Configure.help fixups			(Steven Cole)
o	Move pci_enable_device earlier in trident	(Marcus Meissner)

2.4.4-ac1
o	Merge with Linus 2.4.4
	| This wasnt entirely trivial so this is the only
	| stuff in this patch
	| The following stuff has been switched to the Linus branch
	| in the merge: uhci, dcache atomicity, raw I/O

2.4.3-ac14
o	Merge read-only vxfs reading support		(Christoph Hellwig)
o	Fix missing return in broken_apm_power		(Alex Riesen)
o	Remove bogus rwsem hacks from usbdevice_fs.h	(Alex Riesen)
o	Fix umount/sync_inodes race			(Al Viro)
o	Make new xircom driver report when promisc used	(Arjan van de Ven)
o	Fix acenic PCI flag set up			(Phil Copeland)
o	Make nfs smart about passing max file sizes	(Trond Myklebust)
o	Add initrd support to User Mode Linux		(Jeff Dike)
o	Fix timer irq race in User Mode Linux		(Jeff Dike)
o	Fix UML for semaphore changes			(Jeff Dike)
o	Update thw W9966 parallel port camera driver	(Jakob Kemi)
o	Further dmfe SMP fixups				(Tobias Ringstrom)
o	Kernel manual pages in man9			(Tim Waugh)
o	Work around BIOSes that implement E801 sizing
	but don't implement the CX/DX values part	(Michael Miller)
o	Fix atp driver build				(Arjan van de Ven)
o	Fix irda poll handling				(Dag Brattli)
o	Remove unused buggy pdc202xx code		(Arjan van de Ven)
o	Clean up iphase ATM				(Arnaldo Carvalho
								de Melo)
o	Setup slave PDC20265 controller on fasttrak	(Arjan van de Ven)
	as normal IDE
o	Add __init/__initdata to most net driver   (Andrzej Krzysztofowicz)
	version info
o	SDDR09 config entry was missing			(Phil Stracchino)
o	Configure.help NFS updates		   (Andrzej Krzysztofowicz)
o	Netfilter updates				(Rusty Russell and co)
o	Update 2.4 ipconfig to support dhcp		(Eric Biederman)
o	es1371 setup updates/error check/pci bits	(Marcus Meissner)
o	Fix buzzing ymfpci				(Nick Brown)
o	Update nm256 audio driver			(Marcus Meissner)
o	Blacklist updates				(Arjan van de Ven)

2.4.3-ac13
o	Switch to NOVERS symbols for rwsem		(me)
	| Called from asm blocks so they can't be versioned
o	Fix gcc 2.95 building on rwsem			(Niels Jensen)
o	Fix cmsfs build				    (Andrzej Krzysztofowicz)
o	Fix rio build/HZ setup			    (Andrzej Krzysztofowicz)
o	Fix PPP filtering dependancy in config      (Andrzej Krzysztofowicz)

2.4.3-ac12
o	Rewrite the i2o post handling code to fix 	(me)
	DMA memory scribbles
o	Handle IOP constipation in the i2o_block layer	(me)
o	Fix bugs in the i2o table query causing reboots	(me)
	in i2o_proc on the DPT card
o	Add quirks for i2o cards that handle large I/O	(me)
	queues badly [Promise supertrak100]
o	Add cache heuristics to the I2O block driver	(me)
	| We don't cache large writes (assume seq)
	| We writeback small writes (random, metadata)
o	Disable use of writeback caching if there is	(me)
	no battery backup
o	Merge Linus 2.4.4pre6
o	Further semaphore fixes				(David Howells)
o	Correct 'void main' to 'int main' in rtc doc	(Jesper Juhl)
o	Hopefully fix bugtraq reported netfilter ftp
	flaw
o	Fix unistd.h for ARM				(Russell King)
o	Fix pre-emption of rt tasks			(Nigel Gamble)
o	Fix revalidation bugs in cciss/cpqarray		(Charles White)
	when rereading partitions
o	Acenic updates					(Jes Sorensen)
o	Fix MAINTAINERS sort order			(David Woodhouse)
o	Restore DVDRAM fix with cdrom init fix too	(Jens Axboe)
o	Fix irda disconnect timeout bug			(Dag Brattli)
o	Experimentally reap dead swap harder		(Dave Miller)
o	Remove dead low mtu checks from drivers		(Arnaldo Carvalho de
							 Melo)
o	Add missing sk_chk_filter export		(Byeong-ryeol Kim)
o	Quieten pci printks, send them to log		(Arjan van de Ven)
o	Hopefully fix fastrak oops			(me)

2.4.3-ac11
o	Merge Linus 2.4.4pre5
o	Back out problem dvdram changes
o	Make reiserfs use daemonize			(Chris Mason)
o	Fix lvm map buglet				(Jens Axboe)
o	tms380 driver fixes				(Adam Fritzler)
o	Fix up duplicate configs and other glitches	(Steven Cole)
o	Fix pcnet32 printk format bug			(me)
o	ISDN driver further small update/fixes		(me)
o	Fix bounce buffer deadlock on bh allocs		(Arjan van de Ven)
o	Fix fbmem merge glitch				(Geert Uytterhoeven)
o	Version string cleanups on net devices		(Jeff Garzik)
o	Update ext2 documentation			(Andreas Dilger)
o	Add MCE support for AMD Athlon/Duron		(Dave Jones)
o	Further SDLA tidying				(me)
o	Update Configure.help maintainers		(Steven Cole, Eric
							 Raymond)
o	Tulip update					(Jeff Garzik)
o	Fix sound config to use right symnames		(Eric Raymond)
o	Further dmfe fixes				(Tobias Ringstrom,
							 Frank Davis
							 Jeff Garzik)
o	Parport probe cleanups				(Tim Waugh)
o	Fix a few configure items			(Eric Raymond)
o	Fix cmsfs nonbuild				(me)


2.4.3-ac10
o	Merge Linus 2.4.4pre4
o	Apply the i960 quirk to the DPT I2O controllers	(me)
o	Etrax100 updates				(Bjorn Wesen)
o	Fix skge memory leak				(Jes Sorensen)
o	Handle reiserfs log overflow error		(Chris Mason)
o	Merge JFFS2 (compressing log flash file system)	(David Woodhouse)
o	Merge contributed help texts for options	(Eric Raymond,
							 Steven Cole)
o	Further screen blanking fixes			(Mikael Pettersson)
o	Further binfmt elf DLINFO fixes/alignment      (Benjamin Herrenschmidt)
o	Fix reboot notifier unregister in aic7xxx	(Arjan van de Ven)
o	Fix orinoco_cs build on powerpc			(David Gibson)
o	Neomagic audio didn't call pci_enable_device	(Marcus Meissner)
o	Remove superblock file size setting for 2Gb	(Al Viro)
	default size file systems
o	Merge UML gprof support				(Jeff Dike)
o	Clean up UML slip code				(Jeff Dike)
o	Allow UML attach to already running debuggers	(Jeff Dike)
o	Reorder frame buffer probes			(Geert Uytterhoeven)
o	Add __init calls to bluesmoke.c			(Dave Jones)
o	Add missing pci_enable_device to toshoboe	(Marcus Meissner)
o	Updated AFFS file system			(Roman Zippel)
o	DVD-RAM fixes					(Jens Axboe)
o	Further sundance driver fixes			(Jeff Garzik)
o	Fix qlogicfc warning				(Dave Miller)
o	Fix sign handling error in scsi_ioctl		(me)
	| Found by the Stanford validator
o	Fix sign handling error in af_decnet		(me)
	| Found by the Stanford validator
o	Fixed I2O posts to be uninterruptible		(me)
o	Stop IDE layer eating Supertrak slave PDC20265	(me)
o	Work around the DPT I2O controller exploding 
	when asked to quiesce.				(me)


2.4.3-ac9
o	Fix ac8 pnpbios build bug			(me)
o	Fix ac8 sysrq build bug				(me)
o	Fix uml for new semaphores			(Jeff Dike)
o	Attempt to flush low memory buffers when short
	of bounce space on highmem machines		(Marcelo Tosatti)
o	Kill old filesystem_setup function		(Al Viro)
o	Small pnp bios tidy up				(me)

2.4.3-ac8
o	Restore wan router features backed out by the	(me)
	sangoma stuff Linus merged
o	Clean up #ifdefs in Sangoma code a bit		(me)
o	Fix missing kmalloc return checks in Sangoma 	(me)
o	Fix d_flags bit setting in knfsd		(Mikael Pettersson)
o	Turn on winchip MCE				(Dave Jones)
o	IRDA USB driver fixups				(Dag Brattli, 
					Philipp Rumpf, Jean Tourrilhes)
o	Tidy up cpu capability mask reporting		(Rogier Wolff)
o	Refix icmp gcc warnings			(Andrzej M. Krzysztofowicz)
o	Remove 2.0 ioremap hacks from ISDN layer	(Kai Germaschewski)
o	Fix request_region ranges on hisax/bkm_a8	(Roland Klabunde)
o	Add rx fifo overlfow handling to pci hisax	(Werner Cornelius)
o	Hysdn driver updates				(Ulrich Albrecht)
o	Rewrite cisco hdlc keepalive code		(Bjoern Zeeb,
							 Kai Germaschewski)
o	Document CONFIG_TMSISA				(Jochen Friedrich)
o	Fix emu10k memory leak				(Hugh Dickins)
o	Fix i810 audio SMP lockups			(Doug Ledford)
o	Merge binfmt_elf changes for PPC	(Benjamin Herrenschmidt)
o	Make sysrq keybindings a clean API		(Crutcher Dunvant)
	| I think I caught all the sysrq updates from after
	| the patch was written and got them right - please check
o	Merge PnP bios enumeration and PnP BIOS		(Christian Schmidt,
	parport support			(Tom Lees, David Hinds, Gunther Mayer)
o	Bit more experimental work on fixing bounce	(Marcelo Tosatti, me)
	buffers

2.4.3-ac7
o	Updated VIA quirk handling for the chipset	(Andre Hedrick,
	flaws						 George Breese)
	| Experimental version removed
	| VIA users should check this kernel -carefully-!!!!
o	Remove KT7 dma kill				(me)
	| See above note
o	Merge Linus 2.4.4pre3
o	Fix winchip1 oops in mtrr from previous change	(me)
o	Add winchip3 support to mtrr/oostore		(me)
o	Fix the Zoran driver build			(me)
	| This is still not up to date with the master copy
	| that is intentional - first things first.
o	Fix CONFIG_WINCHIP kernel crash on cpu with	(me)
	fxsave
o	Fix UML options help bug			(Jeff Dike)
o	Fix pte corruption in user mode linux		(Jeff Dike)
o	Fix gdb and terminal initialisation in UML	(Jeff Dike)
o	UML code cleanup				(Jeff Dike)
o	Fix saved register corruption in UML		(Jeff Dike)
o	Add pci_disable_device				(Jeff Garzik)
o	Fix a slight bug in the parport help		(Tim Waugh)
o	Hopefully fix the sb1000 driver irq support	(James Anderson)
o	Fix missing signal lock in keventd		(Manfred Spraul)
o	Fix module build with io debugging on		(Markus Kossmann)
o	Fix dcache flag atomicty			(Al Viro)
o	Make cs4281 use pci_set_dma_mask, clean up 	(Jeff Garzik)
	wrappers
o	Use pci_set_dma_mask on maestro3		(Jeff Garzik)
o	Fix 3270 driver build bug 			(Dick Hitt)
o	Fix accidental sb driver bug revert		(Jeff Garzik)
o	Clean up PCI dependancies in sound drivers	(Jeff Garzik)
o	Update synclink driver				(Paul Fulghum)
o	rtl8139 driver update				(Jeff Garzik)
o	Update ps/2 esdi fixes to correct DMA access	(Hal Duston)
o	More aha1542 code marked __init			(Matthias Hanisch)
o	More random.c code marked __init		(Matthias Hanisch)

2.4.3-ac6
o	Remove tables.h include from fatfs_syms		(OGAWA Hirofumi)
o	Update UML					(Jeff Dike)
o	Protect more __KERNEL__ only stuff from 	(Phil Copeland)
	asm-alpha/io.h
o	Fix sound/Config.in bug with ARM		(Russell King)
o	Update network drivers for ARM bits		(Russell King)
	| 8390, pcnet_cs, tulip
o	Fix umount cleanups				(Al Viro)
o	Merge aic7xxx driver 6.11			(Justin Gibbs)
o	Added support for the pentium machine check	(me)
	| Also including thermal check
o	Add support for the winchip machine check	(me)
o	Fix mtrr support of the WinChip2		(me)
	| Existing code set uncachable not write gathering on winchip2
o	Support weak ordering mode on winchip cpus	(me)

2.4.3-ac5
o	Merge Linus 2.4.4pre1
o	New rwsem implementation			(David Howells)
o	Fix rwsem compile problem			(me)
o	Fix bust_spinlocks build fail if !CONFIG_VT	(me)
o	Merge Linus 2.4.4pre2 except for ipv6
o	Fix the corner case non zeroing bug in 		(me)
	copy_from_user for x86

2.4.3-ac4
o	Fix corruption case in ext2 inode handling	(Ingo Molnar, Al Viro)
o	Merge user mode linux port			(Jeff Dike)
o	Remove some surplus ifdefs from init/main.c	(me)
o	Update nwfpe					(Russell King)
o	Fix ps2esdi driver				(Hal Duston)
o	Update ARM documentation			(Russell King)
o	Update Symbios 53c8xx driver			(Gérard Roudier)
o	ARM frame buffer update				(Russell King)
o	Update ARM bootstrap code			(Russell King)
o	Eicon driver fix				(Armin Schindler)
o	Update S/390 Documentation			(Utz Bacher, Carsten
o	Update S/390 math emulation			 Otte, Holger Smolinski
o	S/390 tape driver				 Martin Schwidefsky
o	PAGEX support for Linux/390 under VM		 and probably others)
o	General S/390 fixes
o	Update S/390 tty drivers
o	Update S/390 irq handling
o	Update S/390 channel driver
o	Update S/390 include files
o	Update S/390 networking drivers
o	Update S/390 DASD drivers
o	Update S/390 mm to match generic mm changes
o	Update S/390 makefiles
o	Catch another subspecies of misidentifying CD	(Bob Mende Pie)
o	Fix bluesmoke formatting			(Solar Designer)
o	Fix rx error handling in rtl8139		(Jeff Garzik)
o	Update paths to e2fsprogs			(Steven Cole)
o	Fix proc alloc map locking			(Tom Leete)
o	Console blanking fix (continued..)		(Mikael Pettersson)
o	ARM tools update				(Russell King)
o	Update ARM includes				(Russell King)
o	Update ARM sound drivers			(Russell King)
o	Update the shark ARM support			(Alexander Schulz)
o	Update SA1100 support				(Russell King,
							 Nicolas Pitre)
o	Update ARM make and config files		(Russell King)
o	Update ARM mm/fault handling			(Russell King)
o	Update ARM network driver config		(Russell King)
o	Misc ARM updates				(Russell King)
o	Update ARM footbridge code			(Russell King)
o	EBSA ISA bus fixups				(Russell King)
o	Fix agp copy_from_user bug			(Dawson Engler)
o	Correct devfs docs on /dev/sg			(Herbert Xu)
o	/dev/sg doc update 				(Douglas Gilbert)

2.4.3-ac3
o	Fix console unblank from suspend bug		(Mikael Pettersson)
o	Fix unmap_buffer() race				(Al Viro)
o	Add a proper dmi blacklist			(me)
o	Fix alpha build for new mm changes		(Ivan Kokshaysky)
o	Resync setup-bus.c to pick up Alpha Noritake	(Ivan Kokshaysky)
	fixes
o	Fix swap accounting for major faults		(Marcelo Tosatti)
o	Add some bigendian support and voodoo5 support	(Ani Joshi)
	to tdfxfb
o	Fix failing build with CONFIG_VT=n		(Jason McMullan)
o	Fix some corner cases in iso9660 support	(Andreas Eckleder)
	for symlinks and XA attriubtes
o	Fix NTFS and quota sparc build problems on -ac	(Steve Ralston)
o	Resync to the Linus serial.c + B9600 fix	(me)
o	Avoid nasties with OHCI controller gets no IRQ	(Arjan van de Ven)
	assigned
o	Pull problem lance change			(Jeff Garzik)
o	Fix SMP lockup in usbdevfs			(Tony Hoyle)
o	Firestream atm update			(Patrick van de Lageweg)

2.4.3-ac2
o	Add the VIA C3 to the mtrr/setup code		(Dave Jones)
o	Report PAE mode oopses better			(Ingo Molnar)
o	Fix zap_low_mappings on PAE			(Hugh Dickins)
o	Tidy up parport resource handling, fix bug	(Tim Waugh)
o	Add series 6 backpack driver support		(Tim Waugh)
o	Make lockd use daemonize()			(Paul Mundt)
o	Fix aicasm to specify -I flags needed on some	(Mads Jørgensen)
	distributions
o	Add docbook manual on bus independant I/O	(Matthew Wilcox)
	| + a few additional notes I added
o	Make the VIA superIO driver honour the		(Tim Waugh)
	irq/dma settings passed
o	Update mpt fusion drivers			(Steve Ralston)
o	Add reiserfs maintainer entries			(Steven Cole)
o	Experimental driver for communcation class USB	(Brad Hards)
	| eg Broadcom and Ericsson USB cable modems
o	I2O updates, report SMART errors on i2o_block	(Boji Kannanthanam)
o	Fix shm locking, races on swapping, accounting	(Stephen Tweedie)
	and swapout of already mapped pages
o	Clean up REPORTING-BUGS				(Steven Cole)
o	Fix ACM handling of CLOCAL			(Vojtech Pavlik)
o	Fix sparc64 module_map/vfree bug		(Hugh Dickins)
o	Fix scsi race on requeued requests		(Mark Hemment)
o	Tulip driver update				(Jeff Garzik)
o	Update bmac and gmac driver			(Cort Dougan)
o	Winbond w9966cf webcam parport driver		(Jakob Kemi)

2.4.3-ac1
o	Merge Linus 2.4.3 final, diff versus 2.4.3	(me)

---
Alan Cox <alan@lxorguk.ukuu.org.uk>
Red Hat Kernel Hacker
& Linux 2.2 Maintainer                        Brainbench MVP for TCP/IP
http://www.linux.org.uk/diary                 http://www.brainbench.com

Re: Linux 2.4.4-ac10

[Christoph Hellwig]

Hi Alan,

In article <E150QuA-0005ah-00@the-village.bc.nu> you wrote:
>
>  	     ftp://ftp.linux.org.uk/pub/linux/alan/2.4-ac/
>

Can't find it there (neither -ac9), but on the other hand it
is on kernel.org...

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: Linux 2.4.4-ac10

[Chris Evans]

On Thu, 17 May 2001, Alan Cox wrote:

> 2.4.4-ac10
[...]
> 	- now 2.4.5pre vm seems sane dump other vmscan
> 	  experiments

Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?

Cheers
Chris

Re: Linux 2.4.4-ac10

[Geert Uytterhoeven]

On Thu, 17 May 2001, Alan Cox wrote:
> 2.4.4-ac10
> 	[not merged; rage-xl code]

I'll take care of that...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Linux 2.4.4-ac10

[Alan Cox]

> >  	     ftp://ftp.linux.org.uk/pub/linux/alan/2.4-ac/
> >
> Can't find it there (neither -ac9), but on the other hand it
> is on kernel.org...

Guess who forgot to fix the URL;)

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Thu, 17 May 2001, Chris Evans wrote:
> On Thu, 17 May 2001, Alan Cox wrote:
> 
> > 2.4.4-ac10
> [...]
> > 	- now 2.4.5pre vm seems sane dump other vmscan
> > 	  experiments
> 
> Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?

Marcelo saw a 30% speed increase from 2.4.4 to 2.4.5pre3
on several tests.

At the moment the main issues left seem to be:
- balancing the inode + dentry caches versus the rest of
  the memory users  (I'm working on it now)
- simplifying __alloc_pages() a bit  (I've got some things
  ready but I'm waiting for some other people who say they
  also have some stuff to add)
- making sure we get rid of all the highmem flushing
  deadlocks ... there may still be a few around (ben, marcelo?)


regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Thu, 17 May 2001, Chris Evans wrote:

> On Thu, 17 May 2001, Alan Cox wrote:
>
> > 2.4.4-ac10
> [...]
> > 	- now 2.4.5pre vm seems sane dump other vmscan
> > 	  experiments
>
> Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?

Only doing parallel kernel builds.  Heavy load throughput is up,
but it swaps too heavily.  It's a little too conservative about
releasing cache now imho. (keeping about double what it should be
with this load.. easily [thump] tweaked;)

	-Mike

Re: Linux 2.4.4-ac10

[Udo A. Steinberg]

Hi,

Alan Cox wrote:
> 
> 2.4.4-ac10

With 2.4.4-ac10 and binutils 2.11 I get the following warnings:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4     -c -o pci-pc.o pci-pc.c
pci-pc.c:964: warning: `pci_fixup_via691' defined but not used
pci-pc.c:977: warning: `pci_fixup_via691_2' defined but not used
{standard input}: Assembler messages:
{standard input}:747: Warning: indirect lcall without `*'
{standard input}:832: Warning: indirect lcall without `*'
{standard input}:919: Warning: indirect lcall without `*'
{standard input}:958: Warning: indirect lcall without `*'
{standard input}:990: Warning: indirect lcall without `*'
{standard input}:1022: Warning: indirect lcall without `*'
{standard input}:1053: Warning: indirect lcall without `*'
{standard input}:1082: Warning: indirect lcall without `*'
{standard input}:1111: Warning: indirect lcall without `*'
{standard input}:1392: Warning: indirect lcall without `*'
{standard input}:1497: Warning: indirect lcall without `*'

gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4     -c -o apm.o apm.c
{standard input}: Assembler messages:
{standard input}:180: Warning: indirect lcall without `*'
{standard input}:274: Warning: indirect lcall without `*'


Does anyone know what's up with that? Kernel problem or binutils issue?

Regards,
Udo.

Re: Linux 2.4.4-ac10

[Matti Aarnio]

On Thu, May 17, 2001 at 08:33:36PM +0200, Udo A. Steinberg wrote:
> With 2.4.4-ac10 and binutils 2.11 I get the following warnings:

  It is a warning about kernel code using assembler statements
  which are not valid with some older assemblers.

> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4     -c -o pci-pc.o pci-pc.c
> pci-pc.c:964: warning: `pci_fixup_via691' defined but not used
> pci-pc.c:977: warning: `pci_fixup_via691_2' defined but not used
> {standard input}: Assembler messages:
> {standard input}:747: Warning: indirect lcall without `*'
> {standard input}:832: Warning: indirect lcall without `*'
> {standard input}:919: Warning: indirect lcall without `*'
> {standard input}:958: Warning: indirect lcall without `*'
> {standard input}:990: Warning: indirect lcall without `*'
> {standard input}:1022: Warning: indirect lcall without `*'
> {standard input}:1053: Warning: indirect lcall without `*'
> {standard input}:1082: Warning: indirect lcall without `*'
> {standard input}:1111: Warning: indirect lcall without `*'
> {standard input}:1392: Warning: indirect lcall without `*'
> {standard input}:1497: Warning: indirect lcall without `*'
> 
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4     -c -o apm.o apm.c
> {standard input}: Assembler messages:
> {standard input}:180: Warning: indirect lcall without `*'
> {standard input}:274: Warning: indirect lcall without `*'
> 
> 
> Does anyone know what's up with that? Kernel problem or binutils issue?
> 
> Regards,
> Udo.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.4.4-ac10

[Ingo Oeser]

On Thu, May 17, 2001 at 05:45:38PM +0100, Alan Cox wrote:
> 2.4.4-ac10

I think someone forgot this little return. It removes the
following warning:

serial.c:4208: warning: control reaches end of non-void function


--- linux-2.4.4-ac10/drivers/char/serial.c	Thu May 17 20:41:05 2001
+++ linux-2.4.4-ac10-ioe/drivers/char/serial.c	Thu May 17 20:35:53 2001
@@ -4205,6 +4205,7 @@
 {
 	__set_current_state(TASK_UNINTERRUPTIBLE);
 	schedule_timeout(HZ/10);
+   return 0;
 }
 
 /*

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: Linux 2.4.4-ac10

[Matti Aarnio]

On Thu, May 17, 2001 at 09:40:39PM +0300, Matti Aarnio wrote:
> On Thu, May 17, 2001 at 08:33:36PM +0200, Udo A. Steinberg wrote:
> > With 2.4.4-ac10 and binutils 2.11 I get the following warnings:
> 
>   It is a warning about kernel code using assembler statements
>   which are not valid with some older assemblers.

  Naeh, I am confusing (you, and myself).  Fixing those (adding the '*')
  would not work with some older assemblers.

  Claiming minimum level of 2.10/2.11 for assembler/binutils would
  certainly allow fixing things by adding the missing '*'.

> > gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4     -c -o pci-pc.o pci-pc.c
> > pci-pc.c:964: warning: `pci_fixup_via691' defined but not used
> > pci-pc.c:977: warning: `pci_fixup_via691_2' defined but not used
> > {standard input}: Assembler messages:
> > {standard input}:747: Warning: indirect lcall without `*'
> > {standard input}:832: Warning: indirect lcall without `*'
> > {standard input}:919: Warning: indirect lcall without `*'
> > {standard input}:958: Warning: indirect lcall without `*'
...

Re: Linux 2.4.4-ac10

[J . A . Magallon]

On 05.17 Ingo Oeser wrote:
> On Thu, May 17, 2001 at 05:45:38PM +0100, Alan Cox wrote:
> > 2.4.4-ac10
> 
> I think someone forgot this little return. It removes the
> following warning:
> 
> serial.c:4208: warning: control reaches end of non-void function
> 
> 
> --- linux-2.4.4-ac10/drivers/char/serial.c	Thu May 17 20:41:05 2001
> +++ linux-2.4.4-ac10-ioe/drivers/char/serial.c	Thu May 17 20:35:53 2001
> @@ -4205,6 +4205,7 @@
>  {
>  	__set_current_state(TASK_UNINTERRUPTIBLE);
>  	schedule_timeout(HZ/10);
> +   return 0;
>  }
>  

And a pair more:

--- linux-2.4.4-ac10/include/linux/raid/md_k.h.orig	Thu May 17 19:35:41
2001
+++ linux-2.4.4-ac10/include/linux/raid/md_k.h	Thu May 17 19:36:15 2001
@@ -38,6 +38,8 @@
 		case RAID5:		return 5;
 	}
 	panic("pers_to_level()");
+
+	return 0;
 }
 
 extern inline int level_to_pers (int level)
--- linux-2.4.3-ac12/drivers/scsi/aic7xxx/aic7xxx_osm.h.orig	Sun Apr 22
10:21:55 2001
+++ linux-2.4.3-ac12/drivers/scsi/aic7xxx/aic7xxx_osm.h	Mon Apr 23
10:55:58 2001
@@ -843,10 +843,10 @@
 		pci_read_config_dword(pci, reg, &retval);
 		return (retval);
 	}
-	default:
-		panic("ahc_pci_read_config: Read size too big");
-		/* NOTREACHED */
 	}
+	panic("ahc_pci_read_config: Read size too big");
+	/* NOTREACHED */
+   return 0;
 }
 
 static __inline void ahc_pci_write_config(ahc_dev_softc_t pci,

-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:jamagallon@able.es
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.4-ac9 #4 SMP Mon May 14 11:22:40 CEST 2001 i686

Re: Linux 2.4.4-ac10

[Jeff Garzik]

"J . A . Magallon" wrote:
> --- linux-2.4.4-ac10/include/linux/raid/md_k.h.orig     Thu May 17 19:35:41
> 2001
> +++ linux-2.4.4-ac10/include/linux/raid/md_k.h  Thu May 17 19:36:15 2001
> @@ -38,6 +38,8 @@
>                 case RAID5:             return 5;
>         }
>         panic("pers_to_level()");
> +
> +       return 0;
>  }

panic should be marked attribute(noreturn), so gcc is being silly here
by warning at all.

I do this too, because IMHO its inline and won't make things bigger just
shut up the warning.  But Alan will yell at you for fixing gcc bugs in
the kernel source :)

Also, add a comment "fixes gcc warning" next to the code, so people know
why it's there.

-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: Linux 2.4.4-ac10

[Alan Cox]

> 
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4     -c -o apm.o apm.c
> {standard input}: Assembler messages:
> {standard input}:180: Warning: indirect lcall without `*'
> {standard input}:274: Warning: indirect lcall without `*'
> 
> Does anyone know what's up with that? Kernel problem or binutils issue?

binutils is issuing a correct warning but if we fix the warning old old binutils
will then refuse to assemble it right.

Re: Linux 2.4.4-ac10

[Alan Cox]

> And a pair more:

No
> --- linux-2.4.4-ac10/include/linux/raid/md_k.h.orig	Thu May 17 19:35:41
> 2001
> +++ linux-2.4.4-ac10/include/linux/raid/md_k.h	Thu May 17 19:36:15 2001
> @@ -38,6 +38,8 @@
>  		case RAID5:		return 5;
>  	}
>  	panic("pers_to_level()");
> +
> +	return 0;

panic appears properly declared as __attribute(noreturn). This looks to me like
a gcc bug

Linux 2.4.4-ac10: Oops

[FAVRE Gregoire]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

Hello,

I have just compiled 2.4.4-ac10 and got:

...
SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 11 for device 00:0b.0
Unable to handle kernel NULL pointer dereference at virtual address 0000000
printing eip:
c01d11d0
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c01d11d0>]
EFLAGS: 00010282
eax: dfff1000 ...

Are the last ... needed, if yes I'll copy them (is there an easy way to do it)?
Just let me know about it ;-)

gcc -v gives me:
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
gcc version 2.96 20000731 (Linux-Mandrake 8.1 2.96-0.50mdk)

I have put under http:://ulima.unil.ch/greg/linux/ some files:
the config of my kernels (2.4.4-ac9 and ac10), the System.map, the
output of dmesg from 2.4.4-ac9, the output of lspci -v and finally
the list of the rpm that are installed on my system.

Thanks you very much,

	Greg
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:greg@ulima.unil.ch

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Thu, 17 May 2001, Mike Galbraith wrote:

> > Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?
> 
> Only doing parallel kernel builds.  Heavy load throughput is up,
> but it swaps too heavily.  It's a little too conservative about
> releasing cache now imho. (keeping about double what it should be
> with this load.. easily [thump] tweaked;)

"about double what it should be"

That's an interesting statement, unless you have some
arguments to define exactly how much cache the system
should keep.

Or are you just comparing with 2.2 and you'd rather
have 2.2 performance? ;)

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Linux 2.4.4-ac10: Oops

[Alan Cox]

> SCSI subsystem driver Revision: 1.00
> PCI: Found IRQ 11 for device 00:0b.0
> Unable to handle kernel NULL pointer dereference at virtual address 0000000
> printing eip:

What scsi drivers do you have and which are on IRQ 11

Re: Linux 2.4.4-ac10

[Sasi Peter]

On Thu, 17 May 2001, Rik van Riel wrote:

> Or are you just comparing with 2.2 and you'd rather
> have 2.2 performance? ;)

Actually, yes. Doing fileserving with Samba, and also using the box
interactively feels better with 2.2, and also the average TCP througput
(measured by iptraf) seems higher.

-- 
SaPE - Peter, Sasi - mailto:sape@sch.hu - http://sape.iq.rulez.org/

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Sasi Peter wrote:
> On Thu, 17 May 2001, Rik van Riel wrote:
> 
> > Or are you just comparing with 2.2 and you'd rather
> > have 2.2 performance? ;)
> 
> Actually, yes. Doing fileserving with Samba, and also using the box
> interactively feels better with 2.2, and also the average TCP througput
> (measured by iptraf) seems higher.

This part is probably mostly due to the inode and dentry
cache balancing being completely broken in current 2.4
kernels. Expect a patch soon (I'm running something really
ugly right now here at home, I'll make something cleaner).

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Thu, 17 May 2001, Rik van Riel wrote:

> On Thu, 17 May 2001, Mike Galbraith wrote:
>
> > > Has anyone benched 2.4.5pre3 vs 2.4.4 vs. ?
> >
> > Only doing parallel kernel builds.  Heavy load throughput is up,
> > but it swaps too heavily.  It's a little too conservative about
> > releasing cache now imho. (keeping about double what it should be
> > with this load.. easily [thump] tweaked;)
>
> "about double what it should be"
>
> That's an interesting statement, unless you have some
> arguments to define exactly how much cache the system
> should keep.

Do you think there's 60-80mb of good cachable data? ;-)  The "double"
is based upon many hundreds of test runs.  I "know" that performance
is best with this load when the cache stays around 25-35Mb.  I know
this because I've done enough bend adjusting to get throughput to
within one minute of single task times to have absolutely no doubt.
I can get it to 30 seconds with much obscene tweaking, and have done
it with zero additional overhead for make -j 30 ten times in a row.
(that kernel was.. plain weird. perfect synchronization.. voodoo!)

> Or are you just comparing with 2.2 and you'd rather
> have 2.2 performance? ;)

Nope.  I've bent this vm up a little and build kernels that kicked the
snot out of the previous record holder (classzone).  I know for a fact
that it can kick major butt.. why I fiddle with it when it doesn't.

	-Mike

Re: Linux 2.4.4-ac10: Oops

[FAVRE Gregoire]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Thus spake Alan Cox (alan@lxorguk.ukuu.org.uk):

> > SCSI subsystem driver Revision: 1.00
> > PCI: Found IRQ 11 for device 00:0b.0
> > Unable to handle kernel NULL pointer dereference at virtual address 0000000
> > printing eip:
> 
> What scsi drivers do you have and which are on IRQ 11

I have two:
00:0b.0 SCSI storage controller: Future Domain Corp. TMC-18C30 [36C70]
        Flags: medium devsel, IRQ 11
        I/O ports at b400 [size=16]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
        Subsystem: Adaptec 2940U2W SCSI Controller
        Flags: bus master, medium devsel, latency 32, IRQ 5
        BIST result: 00
        I/O ports at d000 [disabled] [size=256]
        Memory at df800000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: <available only to root>

Thanks,

	Greg
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:greg@ulima.unil.ch

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Mike Galbraith wrote:
> On Thu, 17 May 2001, Rik van Riel wrote:
> > On Thu, 17 May 2001, Mike Galbraith wrote:
> >
> > > Only doing parallel kernel builds.  Heavy load throughput is up,
> > > but it swaps too heavily.  It's a little too conservative about
> > > releasing cache now imho. (keeping about double what it should be
> > > with this load.. easily [thump] tweaked;)
> >
> > "about double what it should be" ?
> 
> Do you think there's 60-80mb of good cachable data? ;-)  The "double"
> is based upon many hundreds of test runs.  I "know" that performance
> is best with this load when the cache stays around 25-35Mb.  I know
> this because I've done enough bend adjusting to get throughput to
> within one minute of single task times to have absolutely no doubt.
> I can get it to 30 seconds with much obscene tweaking, and have done
> it with zero additional overhead for make -j 30 ten times in a row.
> (that kernel was.. plain weird. perfect synchronization.. voodoo!)

Ahhh, I see.  Remember that the "cached" figure you are
seeing also includes swap-cached data from the gccs, which
results from kswapd scanning the processes, clearing the
PTE and, a bit later, the process grabbing the page again.

I suspect that if the gccs _just_ fit in memory, you can
get some extra performance by mercilessly eating from the
cache and keeping the ggcs in memory. However, I also have
the sneaking suspicion that this is not the best tactic for
all workloads ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Rik van Riel wrote:

> On Fri, 18 May 2001, Mike Galbraith wrote:
> > On Thu, 17 May 2001, Rik van Riel wrote:
> > > On Thu, 17 May 2001, Mike Galbraith wrote:
> > >
> > > > Only doing parallel kernel builds.  Heavy load throughput is up,
> > > > but it swaps too heavily.  It's a little too conservative about
> > > > releasing cache now imho. (keeping about double what it should be
> > > > with this load.. easily [thump] tweaked;)
> > >
> > > "about double what it should be" ?
> >
> > Do you think there's 60-80mb of good cachable data? ;-)  The "double"
> > is based upon many hundreds of test runs.  I "know" that performance
> > is best with this load when the cache stays around 25-35Mb.  I know
> > this because I've done enough bend adjusting to get throughput to
> > within one minute of single task times to have absolutely no doubt.
> > I can get it to 30 seconds with much obscene tweaking, and have done
> > it with zero additional overhead for make -j 30 ten times in a row.
> > (that kernel was.. plain weird. perfect synchronization.. voodoo!)
>
> Ahhh, I see.  Remember that the "cached" figure you are
> seeing also includes swap-cached data from the gccs, which
> results from kswapd scanning the processes, clearing the
> PTE and, a bit later, the process grabbing the page again.

Yes.

> I suspect that if the gccs _just_ fit in memory, you can
> get some extra performance by mercilessly eating from the
> cache and keeping the ggcs in memory. However, I also have
> the sneaking suspicion that this is not the best tactic for
> all workloads ;)

Yes, ~exactly!  I chose 30 tasks because they almost do (tool/userland
dependant.. must recalibrate often) fit.  The bitch is to get the vm
to automagically detect the rss/cache munch tradeoff point without all
the manual help.

	-Mike

Re: Linux 2.4.4-ac10

[Ingo Oeser]

On Fri, May 18, 2001 at 07:45:15PM +0200, Mike Galbraith wrote:
> Yes, ~exactly!  I chose 30 tasks because they almost do (tool/userland
> dependant.. must recalibrate often) fit.  The bitch is to get the vm
> to automagically detect the rss/cache munch tradeoff point without all
> the manual help.

What about a sysctl for that? Choose decent steps and let 0
(which is an insane value) mean "let's kernel decide" and make
this default.

In the past we could do this by adjusting some watermarks in
/proc/sys/vm but now, we can't do anything but trust the genius
kernel developers.

I doubt that we can test all kinds of workload and even imagine
what pervert stuff some people do with their machines.

Tuning _is_ manual work. Always has been and always will be.

This countinously "I know it better then you" is what I hated
about Windows and now this comes more and more into Linux :-(

Rik: Would you take patches for such a tradeoff sysctl?

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Ingo Oeser wrote:

> Rik: Would you take patches for such a tradeoff sysctl?

"such a tradeoff" ?

While this sounds reasonable, I have to point out that
up to now nobody has described exactly WHAT tradeoff
they'd like to make tunable and why...

I'm not against making things tunable, but I would like
to at least see the proponents of tunable things explain
WHAT they want tunable and exactly WHY.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Linux 2.4.4-ac10

[Ingo Oeser]

On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> On Fri, 18 May 2001, Ingo Oeser wrote:
> 
> > Rik: Would you take patches for such a tradeoff sysctl?
> 
> "such a tradeoff" ?
> 
> While this sounds reasonable, I have to point out that
> up to now nobody has described exactly WHAT tradeoff
> they'd like to make tunable and why...

Amount of pages reclaimed from swapout_mm() versus amount of
pages reclaimed from caches.

A value that says: "use XX% of my main memory for RSS of
processes, even if I run heavy disk loadf now" would be nice.

For general purpose machines, where I run several services but
also play games, this would allow both to survive.

The external services would go slower. Who cares, if some CVS
updates or NFS services go slower, if I can play my favorite game
at full speed? ;-)

> I'm not against making things tunable, but I would like
> to at least see the proponents of tunable things explain
> WHAT they want tunable and exactly WHY.

Ideally: Every value that the kernel decides by heuristics,
   because heuristics can fail to get even close to an optimal
   result. 

But this is too much. Some tunables from refill_inactive would be
nice. Also the patch for honouring the soft rss limit is good (is
it in?).

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Rik van Riel wrote:

> On Fri, 18 May 2001, Ingo Oeser wrote:
>
> > Rik: Would you take patches for such a tradeoff sysctl?
>
> "such a tradeoff" ?
>
> While this sounds reasonable, I have to point out that
> up to now nobody has described exactly WHAT tradeoff
> they'd like to make tunable and why...

While I'd love to have more control, I can't say I have a clear
picture of exactly how I'd like those knobs to look.  I always
start out trying to get it to seek the right behavior.. :) and
end up fighting so many different fires I get lost in the smoke.

	-Mike

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Ingo Oeser wrote:
> On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:

> > "such a tradeoff" ?
> >
> > While this sounds reasonable, I have to point out that
> > up to now nobody has described exactly WHAT tradeoff
> > they'd like to make tunable and why...
>
> Amount of pages reclaimed from swapout_mm() versus amount of
> pages reclaimed from caches.
>
> A value that says: "use XX% of my main memory for RSS of
> processes, even if I run heavy disk loadf now" would be nice.
>
> For general purpose machines, where I run several services but
> also play games, this would allow both to survive.
>
> The external services would go slower. Who cares, if some CVS
> updates or NFS services go slower, if I can play my favorite game
> at full speed? ;-)

Remember that the executable and data of that game reside
in the filesystem cache. This "double counting" makes it
quite a bit harder to actually implement what seems like
a simple tradeoff.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Ingo Oeser wrote:

> On Fri, May 18, 2001 at 03:23:03PM -0300, Rik van Riel wrote:
> > On Fri, 18 May 2001, Ingo Oeser wrote:
> >
> > > Rik: Would you take patches for such a tradeoff sysctl?
> >
> > "such a tradeoff" ?
> >
> > While this sounds reasonable, I have to point out that
> > up to now nobody has described exactly WHAT tradeoff
> > they'd like to make tunable and why...
>
> Amount of pages reclaimed from swapout_mm() versus amount of
> pages reclaimed from caches.

I don't know if this'll make sense, but I think this has to
be a ~fuzzy suggestion to the kernel.  There are so many
variables that you can't predict what the kernel will run
into.  For example, with my favorite test, sometimes tasks
do something nasty, like all deciding to do the same things
at once and thereby jerking a _knot_ in the vm's tail.

	-Mike

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Mike Galbraith wrote:

> While I'd love to have more control, I can't say I have a clear
> picture of exactly how I'd like those knobs to look.  I always
> start out trying to get it to seek the right behavior.. :) and
> end up fighting so many different fires I get lost in the smoke.

This is the core of why we cannot (IMHO) have a discussion
of whether a patch introducing new VM tunables can go in:
there is no clear overview of exactly what would need to be
tunable and how it would help.

When you and Ingo have something more specific to talk about,
I guess we can decide on that; but deciding on something like
this isn't really possible without at least knowing what should
be tunable ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Linux 2.4.4-ac10

[Stephen C. Tweedie]

Hi,

On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:

> This is the core of why we cannot (IMHO) have a discussion
> of whether a patch introducing new VM tunables can go in:
> there is no clear overview of exactly what would need to be
> tunable and how it would help.

It's worse than that.  The workload on most typical systems is not
static.  The VM *must* be able to cope with dynamic workloads.  You
might twiddle all the knobs on your system to make your database run
faster, but end up in such a situation that the next time a mail flood
arrives for sendmail, the whole box locks up because the VM can no
longer adapt.

That's the main problem with static parameters.  The problem you are
trying to solve is fundamentally dynamic in most cases (which is also
why magic numbers tend to suck in the VM.)

Cheers, 
 Stephen

Re: Linux 2.4.4-ac10

[Rik van Riel]

On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
> 
> > This is the core of why we cannot (IMHO) have a discussion
> > of whether a patch introducing new VM tunables can go in:
> > there is no clear overview of exactly what would need to be
> > tunable and how it would help.
> 
> It's worse than that.  The workload on most typical systems is not
> static.  The VM *must* be able to cope with dynamic workloads.  You
> might twiddle all the knobs on your system to make your database run
> faster, but end up in such a situation that the next time a mail flood
> arrives for sendmail, the whole box locks up because the VM can no
> longer adapt.

That's another problem, indeed ;)

Ingo, Mike, please keep this in mind when designing
tunables or deciding which test you want to run today
in order to look how the VM is performing.


Basic rule for VM: once you start swapping, you cannot
win;  All you can do is make sure no situation loses
really badly and most situations perform reasonably.

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: Linux 2.4.4-ac10

[Mike Castle]

On Fri, May 18, 2001 at 11:12:32PM -0300, Rik van Riel wrote:
> Basic rule for VM: once you start swapping, you cannot
> win;  All you can do is make sure no situation loses
> really badly and most situations perform reasonably.

Do you mean paging in general or thrashing?

I always thought: paging good, thrashing bad.

A good effecient paging system, always moving data between memory and disk,
is great.  It's when you have the greater than physical memory working set
that things go to hell in a hand basket.

Did Linux ever do the old trick of "We've too much going on!  You!
(randomly points to a process) take a seat!  You're not running for a
while!" and the process gets totatlly swapped out for a "while," not even
scheduled?

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Stephen C. Tweedie wrote:

> Hi,
>
> On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
>
> > This is the core of why we cannot (IMHO) have a discussion
> > of whether a patch introducing new VM tunables can go in:
> > there is no clear overview of exactly what would need to be
> > tunable and how it would help.
>
> It's worse than that.  The workload on most typical systems is not
> static.  The VM *must* be able to cope with dynamic workloads.  You
> might twiddle all the knobs on your system to make your database run
> faster, but end up in such a situation that the next time a mail flood
> arrives for sendmail, the whole box locks up because the VM can no
> longer adapt.
>
> That's the main problem with static parameters.  The problem you are
> trying to solve is fundamentally dynamic in most cases (which is also
> why magic numbers tend to suck in the VM.)

Yup.  The problems are dynamic even with my static test load.

Off the top of my head, if I could make a suggestion to the vm it
would be something like "don't let dirty pages lay idle any longer
than this" and maybe "reclaim cleaned pages older than that".

	-Mike

Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Fri, 18 May 2001, Rik van Riel wrote:

> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> > On Fri, May 18, 2001 at 07:44:39PM -0300, Rik van Riel wrote:
> >
> > > This is the core of why we cannot (IMHO) have a discussion
> > > of whether a patch introducing new VM tunables can go in:
> > > there is no clear overview of exactly what would need to be
> > > tunable and how it would help.
> >
> > It's worse than that.  The workload on most typical systems is not
> > static.  The VM *must* be able to cope with dynamic workloads.  You
> > might twiddle all the knobs on your system to make your database run
> > faster, but end up in such a situation that the next time a mail flood
> > arrives for sendmail, the whole box locks up because the VM can no
> > longer adapt.
>
> That's another problem, indeed ;)
>
> Ingo, Mike, please keep this in mind when designing
> tunables or deciding which test you want to run today
> in order to look how the VM is performing.

I've bent your code up a bit.  I've not yet been tempted to replace
any of it with a knob ;-)  There is a little piece I'd like to see
thrown away though.. the loop in refill_inactive does nothing good.

The test I prefer is a good one for the area of vm performance I'm
most interested in.  It doesn't cover the full vm spectrum by any
means.  I don't have a setup (any) good for testing mondo network or
IO stuff.  I test a simple 'job one size to large' scenario.  Yes,
it's limited test coverage.. it's still legitimate.

Perhaps when you're evaluating vm performance, you should try my
simple test once in a while. :) I'll bet you a bogobeer right here
and now that when 2.4.5 hits the street you're going to be queried
by the big-busy-box folks wrt swap volume.

> Basic rule for VM: once you start swapping, you cannot
> win;  All you can do is make sure no situation loses
> really badly and most situations perform reasonably.

I disagree with that.  I've seen a heavily swapping box run like
a scaulded ass ape many times.

	Warsteiner,

	-Mike

[RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

Hi,

On Fri, 18 May 2001, Stephen C. Tweedie wrote:

> That's the main problem with static parameters.  The problem you are
> trying to solve is fundamentally dynamic in most cases (which is also
> why magic numbers tend to suck in the VM.)

Magic numbers might be sucking some performance right now ;-)

Three back to back make -j 30 runs for three different kernels.
Swap cache numbers are taken immediately after last completion.

Reference runs  (bad numbers.  cache collapse hurts.. a lot)
real    12m8.157s  11m41.192s  11m36.069s  2.4.4.virgin
user    7m57.710s   7m57.820s   7m57.150s
sys     0m37.200s   0m37.070s   0m37.020s
Swap cache: add 785029, delete 781670, find 243396/1051626

                    oddball.. infrequent, but happens
                    vvvv
real    10m30.470s  9m36.478s   9m50.512s  2.4.5-pre3.virgin
user    7m54.300s   7m53.430s   7m55.200s
sys     0m36.010s   0m36.850s   0m35.230s
Swap cache: add 1018892, delete 1007053, find 821456/1447811

real    9m9.679s    9m18.291s   8m55.981s  3.4.5-pre3.tweak
user    7m55.590s   7m57.060s   7m55.850s
sys     0m34.890s   0m34.370s   0m34.330s
Swap cache: add 656966, delete 646676, find 325186/865183

--- linux-2.4.5-pre3/mm/vmscan.c.org	Thu May 17 16:44:23 2001
+++ linux-2.4.5-pre3/mm/vmscan.c	Sat May 19 11:52:40 2001
@@ -824,39 +824,17 @@
 #define DEF_PRIORITY (6)
 static int refill_inactive(unsigned int gfp_mask, int user)
 {
-	int count, start_count, maxtry;
-
-	if (user) {
-		count = (1 << page_cluster);
-		maxtry = 6;
-	} else {
-		count = inactive_shortage();
-		maxtry = 1 << DEF_PRIORITY;
-	}
-
-	start_count = count;
-	do {
-		if (current->need_resched) {
-			__set_current_state(TASK_RUNNING);
-			schedule();
-			if (!inactive_shortage())
-				return 1;
-		}
-
-		count -= refill_inactive_scan(DEF_PRIORITY, count);
-		if (count <= 0)
-			goto done;
-
-		/* If refill_inactive_scan failed, try to page stuff out.. */
-		swap_out(DEF_PRIORITY, gfp_mask);
-
-		if (--maxtry <= 0)
-				return 0;
-
-	} while (inactive_shortage());
-
-done:
-	return (count < start_count);
+	int shortage = inactive_shortage();
+	int large = freepages.high/2;
+	int scale;
+
+	scale = shortage/large;
+	scale += free_shortage()/large;
+	if (scale > DEF_PRIORITY-1)
+		scale = DEF_PRIORITY-1;
+	if (refill_inactive_scan(DEF_PRIORITY-scale, shortage) < shortage)
+		return swap_out(DEF_PRIORITY, gfp_mask);
+	return 1;
 }

 static int do_try_to_free_pages(unsigned int gfp_mask, int user)
@@ -976,7 +954,8 @@
 		 * We go to sleep for one second, but if it's needed
 		 * we'll be woken up earlier...
 		 */
-		if (!free_shortage() || !inactive_shortage()) {
+		if (current->need_resched || !free_shortage() ||
+				!inactive_shortage()) {
 			interruptible_sleep_on_timeout(&kswapd_wait, HZ);
 		/*
 		 * If we couldn't free enough memory, we see if it was
@@ -1054,7 +1033,7 @@
 				if (!zone->size)
 					continue;

-				while (zone->free_pages < zone->pages_low) {
+				while (zone->free_pages < zone->inactive_clean_pages) {
 					struct page * page;
 					page = reclaim_page(zone);
 					if (!page)


Now, lets go back to the patch I posted which reduced context switches
under load by ~40% (of ~685000) for a moment.  Kswapd is asleep while
awaiting IO completion.  The guys who are pestering the sleeping kswapd
are going to be doing page_launder to fix the shortage they're yammering
at kswapd about.  We're nibbling away at the free shortage..  and the
inactive_dirty list.  So now, we have an inactive shortage as well as
a large free shortage when we enter refill_inactive.  (shortages became
large because kswapd is sleeping on the job)

6 * (1 << page_cluster) is larger than MAX_LAUNDER, but I don't see any
reason to sneak up on the shortage instead of correcting it all at once.
It takes too long to find out it's going to fail.  Why not just get it
over with before every scrubber in the system is sleeping on IO.. except
the ones doing swap pagebuffer allocations.  They can swapout, but they
can't help push swap, so it'll all sit there until somebody wakes up no?

If I'm interpreting the results right, taking it all on at once is saving
a lot of what looks to me to be unnecessary swap.  I can't see those
swap numbers as being anything other than unnecessary given that I see
no evidence of cache collapse as in 2.4.4 and earlier kernels, and the
job is getting done faster without them.

	-Mike

(yes, the last hunk looks out of place wrt my text.  however, it improves
throughput nicely, so I left it in.  swap reduction and time savings are
present without it.. just not quite as pretty;)

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Sat, 19 May 2001, Mike Galbraith wrote:
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> 
> > That's the main problem with static parameters.  The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the VM.)
> 
> Magic numbers might be sucking some performance right now ;-)

... so you replace them with some others ... ;)

> Three back to back make -j 30 runs for three different kernels.
> Swap cache numbers are taken immediately after last completion.

The performance increase is nice, though.  Do you see similar
changes in different kinds of workloads ?


> (yes, the last hunk looks out of place wrt my text.

It also looks kind of bogus and geared completely towards this
particular workload ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sat, 19 May 2001, Rik van Riel wrote:

> On Sat, 19 May 2001, Mike Galbraith wrote:
> > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> >
> > > That's the main problem with static parameters.  The problem you are
> > > trying to solve is fundamentally dynamic in most cases (which is also
> > > why magic numbers tend to suck in the VM.)
> >
> > Magic numbers might be sucking some performance right now ;-)
>
> ... so you replace them with some others ... ;)

I reused one of our base numbers to classify the severity of the
situation.. not the same as inventing new ones.  (well, not quite
the same anyway.. half did come from the south fourty;)

> > Three back to back make -j 30 runs for three different kernels.
> > Swap cache numbers are taken immediately after last completion.
>
> The performance increase is nice, though.  Do you see similar
> changes in different kinds of workloads ?

I don't have much to test with here, but I'll see if I can find
something. I'd rather see someone with a server load try it.

> > (yes, the last hunk looks out of place wrt my text.
>
> It also looks kind of bogus and geared completely towards this
> particular workload ;)

I'm not sure why that helps.  I didn't put it in as a trick or
anything though.  I put it in because it didn't seem like a
good idea to ever have more cleaned pages than free pages at a
time when we're yammering for help.. so I did that and it helped.

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Sun, 20 May 2001, Mike Galbraith wrote:
> On Sat, 19 May 2001, Rik van Riel wrote:
> > On Sat, 19 May 2001, Mike Galbraith wrote:
> > > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> > >
> > > > That's the main problem with static parameters.  The problem you are
> > > > trying to solve is fundamentally dynamic in most cases (which is also
> > > > why magic numbers tend to suck in the VM.)
> > >
> > > Magic numbers might be sucking some performance right now ;-)
> >
> > ... so you replace them with some others ... ;)
>
> I reused one of our base numbers to classify the severity of the
> situation.. not the same as inventing new ones.  (well, not quite
> the same anyway.. half did come from the south fourty;)

*nod* ;)

(not that I'm saying this is bad ... it's just that I'd
like to know why things work before looking at applying
them)

> > > (yes, the last hunk looks out of place wrt my text.
> >
> > It also looks kind of bogus and geared completely towards this
> > particular workload ;)
>
> I'm not sure why that helps.  I didn't put it in as a trick or
> anything though.  I put it in because it didn't seem like a
> good idea to ever have more cleaned pages than free pages at a
> time when we're yammering for help.. so I did that and it helped.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note that this is not the normal situation. Now think
about the amount of data you'd be blowing away from the
inactive_clean pages after a bit of background aging
has gone on on a lightly loaded system.  Not Good(tm)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Rik van Riel wrote:

> On Sun, 20 May 2001, Mike Galbraith wrote:
> >
> > I'm not sure why that helps.  I didn't put it in as a trick or
> > anything though.  I put it in because it didn't seem like a
> > good idea to ever have more cleaned pages than free pages at a
> > time when we're yammering for help.. so I did that and it helped.
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Note that this is not the normal situation. Now think
> about the amount of data you'd be blowing away from the
> inactive_clean pages after a bit of background aging
> has gone on on a lightly loaded system.  Not Good(tm)

You're right.  It should never dump too much data at once.  OTOH, if
those cleaned pages are really old (front of reclaim list), there's no
value in keeping them either.  Maybe there should be a slow bleed for
mostly idle or lightly loaded conditions.

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Sun, 20 May 2001, Mike Galbraith wrote:

> You're right.  It should never dump too much data at once.  OTOH, if
> those cleaned pages are really old (front of reclaim list), there's no
> value in keeping them either.  Maybe there should be a slow bleed for
> mostly idle or lightly loaded conditions.

If you don't think it's worthwhile keeping the oldest pages
in memory around, please hand me your excess DIMMS ;)

Remember that inactive_clean pages are always immediately
reclaimable by __alloc_pages(), if you measured a performance
difference by freeing pages in a different way I'm pretty sure
it's a side effect of something else.  What that something
else is I'm curious to find out, but I'm pretty convinced that
throwing away data early isn't the way to go.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Rik van Riel wrote:

> On Sun, 20 May 2001, Mike Galbraith wrote:
>
> > You're right.  It should never dump too much data at once.  OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either.  Maybe there should be a slow bleed for
> > mostly idle or lightly loaded conditions.
>
> If you don't think it's worthwhile keeping the oldest pages
> in memory around, please hand me your excess DIMMS ;)

You're welcome to the data in any of them :)  The hardware I keep.

> Remember that inactive_clean pages are always immediately
> reclaimable by __alloc_pages(), if you measured a performance
> difference by freeing pages in a different way I'm pretty sure
> it's a side effect of something else.  What that something
> else is I'm curious to find out, but I'm pretty convinced that
> throwing away data early isn't the way to go.

OK.  I'm getting a little distracted by thinking about the locking
and some latency comments I've heard various gurus make.  I should
probably stick to thinking about/measuring throughput.. much easier.

but ;-)

Looking at the locking and trying to think SMP (grunt) though, I
don't like the thought of taking two locks for each page until
kreclaimd gets a chance to run.  One of those locks is the
pagecache_lock, and that makes me think it'd be better to just
reclaim a block if I have to reclaim at all.  At that point, the
chances of needing to lock the pagecache soon again are about
100%.  The data in that block is toast anyway.  A big hairy SMP
box has to feel reclaim_page(). (they probably feel the zone lock
too.. probably would like to allocate blocks)

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Sun, 20 May 2001, Mike Galbraith wrote:

> but ;-)
> 
> Looking at the locking and trying to think SMP (grunt) though, I
> don't like the thought of taking two locks for each page until

> 100%.  The data in that block is toast anyway.  A big hairy SMP
> box has to feel reclaim_page(). (they probably feel the zone lock
> too.. probably would like to allocate blocks)

Indeed, but this is a separate problem.  Doing per-CPU private
(small, 8-32 page?) free lists is probably a good idea, but I
don't really think it's related to kreclaimd ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Zlatko Calusic]

Mike Galbraith <mikeg@wen-online.de> writes:

> Hi,
> 
> On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> 
> > That's the main problem with static parameters.  The problem you are
> > trying to solve is fundamentally dynamic in most cases (which is also
> > why magic numbers tend to suck in the VM.)
> 
> Magic numbers might be sucking some performance right now ;-)
> 
[snip]

I like your patch, it improves performance somewhat and makes things
more smooth and also code is simpler.

Anyway, 2.4.5-pre3 is quite debalanced and it has even broken some
things that were working properly before. For instance, swapoff now
deadlocks the machine (even with your patch applied).

Unfortunately, I have failed to pinpoint the exact problem, but I'm
confident that kernel goes in some kind of loop (99% system time, just
before deadlock). Anybody has some guidelines how to debug kernel if
you're running X?

Also in all recent kernels, if the machine is swapping, swap cache
grows without limits and is hard to recycle, but then again that is
a known problem.
-- 
Zlatko

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Ingo Oeser]

On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
> I'm not sure why that helps.  I didn't put it in as a trick or
> anything though.  I put it in because it didn't seem like a
> good idea to ever have more cleaned pages than free pages at a
> time when we're yammering for help.. so I did that and it helped.

The rationale for this is easy: free pages is wasted memory,
clean pages is hot, clean cache. The best state a cache can be in.

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Ingo Oeser wrote:

> On Sun, May 20, 2001 at 05:29:49AM +0200, Mike Galbraith wrote:
> > I'm not sure why that helps.  I didn't put it in as a trick or
> > anything though.  I put it in because it didn't seem like a
> > good idea to ever have more cleaned pages than free pages at a
> > time when we're yammering for help.. so I did that and it helped.
>
> The rationale for this is easy: free pages is wasted memory,
> clean pages is hot, clean cache. The best state a cache can be in.

Sure.  Under low load, cache is great.  Under stress, keeping it is
not an option though ;-)  We're at or beyond capacity and moving at
a high delda V (people yammering for help).  If you can recognize and
kill the delta rapidly by dumping that which you are going to have
to dump anyway, you save time getting back on your feet.  (my guess
as to why dumping clean pages does measurably help in this case)

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On 20 May 2001, Zlatko Calusic wrote:

> Mike Galbraith <mikeg@wen-online.de> writes:
>
> > Hi,
> >
> > On Fri, 18 May 2001, Stephen C. Tweedie wrote:
> >
> > > That's the main problem with static parameters.  The problem you are
> > > trying to solve is fundamentally dynamic in most cases (which is also
> > > why magic numbers tend to suck in the VM.)
> >
> > Magic numbers might be sucking some performance right now ;-)
> >
> [snip]
>
> I like your patch, it improves performance somewhat and makes things
> more smooth and also code is simpler.

Thanks for the feedback.  Positive is nice.. as is negative.

> Anyway, 2.4.5-pre3 is quite debalanced and it has even broken some
> things that were working properly before. For instance, swapoff now
> deadlocks the machine (even with your patch applied).

I haven't run into that.

> Unfortunately, I have failed to pinpoint the exact problem, but I'm
> confident that kernel goes in some kind of loop (99% system time, just
> before deadlock). Anybody has some guidelines how to debug kernel if
> you're running X?

Serial console and kdb or kgdb if you have two machines.. or uml?

> Also in all recent kernels, if the machine is swapping, swap cache
> grows without limits and is hard to recycle, but then again that is
> a known problem.

This one bugs me.  I do not see that and can't understand why.

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Marcelo Tosatti]

On Sun, 20 May 2001, Mike Galbraith wrote:

> > Also in all recent kernels, if the machine is swapping, swap cache
> > grows without limits and is hard to recycle, but then again that is
> > a known problem.
> 
> This one bugs me.  I do not see that and can't understand why.

To throw away dirty and dead swapcache (its done at swap writepage())
pages page_launder() has to run into its second loop (launder_loop = 1)
(meaning that a lot of clean cache has been thrown out already).

We can "short circuit" this dead swapcache pages by cleaning them in the
first page_launder() loop.

Take a look at the writepage() patch I sent to Linus a few days ago.

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Marcelo Tosatti]

On Sat, 19 May 2001, Mike Galbraith wrote:

> @@ -1054,7 +1033,7 @@
>  				if (!zone->size)
>  					continue;
> 
> -				while (zone->free_pages < zone->pages_low) {
> +				while (zone->free_pages < zone->inactive_clean_pages) {
>  					struct page * page;
>  					page = reclaim_page(zone);
>  					if (!page)


What you're trying to do with this change ? 

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Sun, 20 May 2001, Mike Galbraith wrote:
> On 20 May 2001, Zlatko Calusic wrote:

> > Also in all recent kernels, if the machine is swapping, swap cache
> > grows without limits and is hard to recycle, but then again that is
> > a known problem.
> 
> This one bugs me.  I do not see that and can't understand why.

Could it be because we never free swap space and never
delete pages from the swap cache ?

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Pavel Machek]

Hi!

> > You're right.  It should never dump too much data at once.  OTOH, if
> > those cleaned pages are really old (front of reclaim list), there's no
> > value in keeping them either.  Maybe there should be a slow bleed for
> > mostly idle or lightly loaded conditions.
> 
> If you don't think it's worthwhile keeping the oldest pages
> in memory around, please hand me your excess DIMMS ;)

Sorry, Rik, you can't have that that DIMM. You know, you are
developing memory managment, and we can't have you having too much
memory available ;-).
								  Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Rik van Riel wrote:

> On Sun, 20 May 2001, Mike Galbraith wrote:
> > On 20 May 2001, Zlatko Calusic wrote:
>
> > > Also in all recent kernels, if the machine is swapping, swap cache
> > > grows without limits and is hard to recycle, but then again that is
> > > a known problem.
> >
> > This one bugs me.  I do not see that and can't understand why.
>
> Could it be because we never free swap space and never
> delete pages from the swap cache ?

I sent a query to the list asking if a heavy load cleared it out,
but got no replies.  I figured about the only thing it could be
is that under light load, reclaim isn't needed to cure and shortage.

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Marcelo Tosatti wrote:

> On Sat, 19 May 2001, Mike Galbraith wrote:
>
> > @@ -1054,7 +1033,7 @@
> >  				if (!zone->size)
> >  					continue;
> >
> > -				while (zone->free_pages < zone->pages_low) {
> > +				while (zone->free_pages < zone->inactive_clean_pages) {
> >  					struct page * page;
> >  					page = reclaim_page(zone);
> >  					if (!page)
>
>
> What you're trying to do with this change ?

Just ensuring that I never had a large supply of cleaned pages laying
around at a time when folks are in distress.  It also ensures that you
never donate your last reclaimable pages, but that wasn't the intent.

It was a stray though that happened to produce measurable improvement.

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Stephen C. Tweedie]

Hi,

On Sun, May 20, 2001 at 07:04:31AM -0300, Rik van Riel wrote:
> On Sun, 20 May 2001, Mike Galbraith wrote:
> > 
> > Looking at the locking and trying to think SMP (grunt) though, I
> > don't like the thought of taking two locks for each page until
> 
> > 100%.  The data in that block is toast anyway.  A big hairy SMP
> > box has to feel reclaim_page(). (they probably feel the zone lock
> > too.. probably would like to allocate blocks)
> 
> Indeed, but this is a separate problem.  Doing per-CPU private
> (small, 8-32 page?) free lists is probably a good idea

Ingo already implemented that for Tux2.

Cheers,
 Stephen

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[David Weinehall]

On Sun, May 20, 2001 at 11:54:09PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > You're right.  It should never dump too much data at once.  OTOH, if
> > > those cleaned pages are really old (front of reclaim list), there's no
> > > value in keeping them either.  Maybe there should be a slow bleed for
> > > mostly idle or lightly loaded conditions.
> > 
> > If you don't think it's worthwhile keeping the oldest pages
> > in memory around, please hand me your excess DIMMS ;)
> 
> Sorry, Rik, you can't have that that DIMM. You know, you are
> developing memory managment, and we can't have you having too much
> memory available ;-).

IMVHO every developer involved in memory-management (and indeed, any
software development; the authors of ntpd comes in mind here) should
have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
still a pain to work with.


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Mon, 21 May 2001, David Weinehall wrote:

> IMVHO every developer involved in memory-management (and indeed, any
> software development; the authors of ntpd comes in mind here) should
> have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> still a pain to work with.

You're absolutely right. The smallest thing I'm testing with
on a regular basis is my dual pentium machine, booted with
mem=8m or mem=16m.

Time to hunt around for a 386 or 486 which is limited to such
a small amount of RAM ;)

cheers,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Jonathan Morton]

>Time to hunt around for a 386 or 486 which is limited to such
>a small amount of RAM ;)

I've got an old knackered 486DX/33 with 8Mb RAM (in 30-pin SIMMs, woohoo!),
a flat CMOS battery, a 2Gb Maxtor HD that needs a low-level format every
year, and no case.  It isn't running anything right now...

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Scott Anderson]

David Weinehall wrote:
> IMVHO every developer involved in memory-management (and indeed, any
> software development; the authors of ntpd comes in mind here) should
> have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> still a pain to work with.

If you really want to have fun, remove all swap...

    Scott Anderson
    scott_anderson@mvista.com   MontaVista Software Inc.
    (408)328-9214               1237 East Arques Ave.
    http://www.mvista.com       Sunnyvale, CA  94085

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Rik van Riel wrote:

> Remember that inactive_clean pages are always immediately
> reclaimable by __alloc_pages(), if you measured a performance
> difference by freeing pages in a different way I'm pretty sure
> it's a side effect of something else.  What that something
> else is I'm curious to find out, but I'm pretty convinced that
> throwing away data early isn't the way to go.

OK.. let's forget about throughput for a moment and consider
those annoying reports of 0 order allocations failing :)

What do you think of the below (ignore the refill_inactive bit)
wrt allocator reliability under heavy stress?  The thing does
kick in and pump up zones even if I set the 'blood donor' level
to pages_min.

	-Mike

--- linux-2.4.5-pre3/mm/page_alloc.c.org	Mon May 21 10:35:06 2001
+++ linux-2.4.5-pre3/mm/page_alloc.c	Thu May 24 08:18:36 2001
@@ -224,10 +224,11 @@
 			unsigned long order, int limit, int direct_reclaim)
 {
 	zone_t **zone = zonelist->zones;
+	struct page *page = NULL;

 	for (;;) {
 		zone_t *z = *(zone++);
-		unsigned long water_mark;
+		unsigned long water_mark = 1 << order;

 		if (!z)
 			break;
@@ -249,18 +250,44 @@
 			case PAGES_HIGH:
 				water_mark = z->pages_high;
 		}
+		if (z->free_pages + z->inactive_clean_pages < water_mark)
+			continue;

-		if (z->free_pages + z->inactive_clean_pages > water_mark) {
-			struct page *page = NULL;
-			/* If possible, reclaim a page directly. */
-			if (direct_reclaim && z->free_pages < z->pages_min + 8)
+		if (direct_reclaim) {
+			int count;
+
+			/* If we're in bad shape.. */
+			if (z->free_pages < z->pages_low && z->inactive_clean_pages) {
+				count = 4 * (1 << page_cluster);
+				/* reclaim a page for ourselves if we can afford to.. */
+				if (z->inactive_clean_pages > count)
+					page = reclaim_page(z);
+				if (z->inactive_clean_pages < 2 * count)
+					count = z->inactive_clean_pages / 2;
+			} else count = 0;
+
+			/*
+			 * and make a small donation to the reclaim challenged.
+			 *
+			 * We don't ever want a zone to reach the state where we
+			 * have nothing except reclaimable pages left.. not if
+			 * we can possibly do something to help prevent it.
+			 */
+			while (count--) {
+				struct page *page;
 				page = reclaim_page(z);
-			/* If that fails, fall back to rmqueue. */
-			if (!page)
-				page = rmqueue(z, order);
-			if (page)
-				return page;
+				if (!page)
+					break;
+				__free_page(page);
+			}
 		}
+		if (!page)
+			page = rmqueue(z, order);
+		if (page)
+			return page;
+		if (z->inactive_clean_pages - z->free_pages > z->pages_low
+				&& waitqueue_active(&kreclaimd_wait))
+			wake_up_interruptible(&kreclaimd_wait);
 	}

 	/* Found nothing. */
@@ -314,29 +341,6 @@
 		wakeup_bdflush(0);

 try_again:
-	/*
-	 * First, see if we have any zones with lots of free memory.
-	 *
-	 * We allocate free memory first because it doesn't contain
-	 * any data ... DUH!
-	 */
-	zone = zonelist->zones;
-	for (;;) {
-		zone_t *z = *(zone++);
-		if (!z)
-			break;
-		if (!z->size)
-			BUG();
-
-		if (z->free_pages >= z->pages_low) {
-			page = rmqueue(z, order);
-			if (page)
-				return page;
-		} else if (z->free_pages < z->pages_min &&
-					waitqueue_active(&kreclaimd_wait)) {
-				wake_up_interruptible(&kreclaimd_wait);
-		}
-	}

 	/*
 	 * Try to allocate a page from a zone with a HIGH
--- linux-2.4.5-pre3/mm/vmscan.c.org	Thu May 17 16:44:23 2001
+++ linux-2.4.5-pre3/mm/vmscan.c	Thu May 24 08:05:21 2001
@@ -824,39 +824,17 @@
 #define DEF_PRIORITY (6)
 static int refill_inactive(unsigned int gfp_mask, int user)
 {
-	int count, start_count, maxtry;
-
-	if (user) {
-		count = (1 << page_cluster);
-		maxtry = 6;
-	} else {
-		count = inactive_shortage();
-		maxtry = 1 << DEF_PRIORITY;
-	}
-
-	start_count = count;
-	do {
-		if (current->need_resched) {
-			__set_current_state(TASK_RUNNING);
-			schedule();
-			if (!inactive_shortage())
-				return 1;
-		}
-
-		count -= refill_inactive_scan(DEF_PRIORITY, count);
-		if (count <= 0)
-			goto done;
-
-		/* If refill_inactive_scan failed, try to page stuff out.. */
-		swap_out(DEF_PRIORITY, gfp_mask);
-
-		if (--maxtry <= 0)
-				return 0;
-
-	} while (inactive_shortage());
-
-done:
-	return (count < start_count);
+	int shortage = inactive_shortage();
+	int large = freepages.high/2;
+	int scale;
+
+	scale = shortage/large;
+	scale += free_shortage()/large;
+	if (scale > DEF_PRIORITY-1)
+		scale = DEF_PRIORITY-1;
+	if (refill_inactive_scan(DEF_PRIORITY-scale, shortage) < shortage)
+		return swap_out(DEF_PRIORITY, gfp_mask);
+	return 1;
 }

 static int do_try_to_free_pages(unsigned int gfp_mask, int user)
@@ -976,8 +954,9 @@
 		 * We go to sleep for one second, but if it's needed
 		 * we'll be woken up earlier...
 		 */
-		if (!free_shortage() || !inactive_shortage()) {
-			interruptible_sleep_on_timeout(&kswapd_wait, HZ);
+		if (current->need_resched || !free_shortage() ||
+				!inactive_shortage()) {
+			interruptible_sleep_on_timeout(&kswapd_wait, HZ/10);
 		/*
 		 * If we couldn't free enough memory, we see if it was
 		 * due to the system just not having enough memory.
@@ -1051,10 +1030,13 @@
 			int i;
 			for(i = 0; i < MAX_NR_ZONES; i++) {
 				zone_t *zone = pgdat->node_zones + i;
+				int count;
 				if (!zone->size)
 					continue;

-				while (zone->free_pages < zone->pages_low) {
+				count = zone->pages_low;
+				while (zone->free_pages < zone->inactive_clean_pages &&
+						count--) {
 					struct page * page;
 					page = reclaim_page(zone);
 					if (!page)
@@ -1064,6 +1046,9 @@
 			}
 			pgdat = pgdat->node_next;
 		} while (pgdat);
+#if 1
+		run_task_queue(&tq_disk);
+#endif
 	}
 }

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Thu, 24 May 2001, Mike Galbraith wrote:
> On Sun, 20 May 2001, Rik van Riel wrote:
>
> > Remember that inactive_clean pages are always immediately
> > reclaimable by __alloc_pages(), if you measured a performance
> > difference by freeing pages in a different way I'm pretty sure
> > it's a side effect of something else.  What that something
> > else is I'm curious to find out, but I'm pretty convinced that
> > throwing away data early isn't the way to go.
>
> OK.. let's forget about throughput for a moment and consider
> those annoying reports of 0 order allocations failing :)

Those are ok.  All failing 0 order allocations are either
atomic allocations or GFP_BUFFER allocations.  I guess we
should just remove the printk()  ;)

> What do you think of the below (ignore the refill_inactive bit)
> wrt allocator reliability under heavy stress?  The thing does
> kick in and pump up zones even if I set the 'blood donor' level
> to pages_min.

> -		unsigned long water_mark;
> +		unsigned long water_mark = 1 << order;

Makes no sense at all since water_mark gets assigned not 10
lines below.  ;)


> +		if (direct_reclaim) {
> +			int count;
> +
> +			/* If we're in bad shape.. */
> +			if (z->free_pages < z->pages_low && z->inactive_clean_pages) {

I'm not sure if we want to fill up the free list all the way
to z->pages_low all the time, since "free memory is wasted
memory".

The reason the current scheme only triggers when we reach
z->pages_min and then goes all the way up to z->pages_low
is memory defragmentation. Since we'll be doing direct
reclaim for just about every allocation in the system, it
only happens occasionally that we throw away all the
inactive_clean pages between z->pages_min and z->pages_low.

> +				count = 4 * (1 << page_cluster);
> +				/* reclaim a page for ourselves if we can afford to.. */
> +				if (z->inactive_clean_pages > count)
> +					page = reclaim_page(z);
> +				if (z->inactive_clean_pages < 2 * count)
> +					count = z->inactive_clean_pages / 2;
> +			} else count = 0;

What exactly is the reasoning behind this complex  "count"
stuff? Is there a good reason for not just refilling the
free list up to the target or until the inactive_clean list
is depleted ?

> +			/*
> +			 * and make a small donation to the reclaim challenged.
> +			 *
> +			 * We don't ever want a zone to reach the state where we
> +			 * have nothing except reclaimable pages left.. not if
> +			 * we can possibly do something to help prevent it.
> +			 */

This comment makes little sense

> +		if (z->inactive_clean_pages - z->free_pages > z->pages_low
> +				&& waitqueue_active(&kreclaimd_wait))
> +			wake_up_interruptible(&kreclaimd_wait);

This doesn't make any sense to me at all.  Why wake up
kreclaimd just because the difference between the number
of inactive_clean pages and free pages is large ?

Didn't we determine in our last exchange of email that
it would be a good thing under most loads to keep as much
inactive_clean memory around as possible and not waste^Wfree
memory early ?

> -	/*
> -	 * First, see if we have any zones with lots of free memory.
> -	 *
> -	 * We allocate free memory first because it doesn't contain
> -	 * any data ... DUH!
> -	 */

We want to keep this.  Suppose we have one zone which is
half filled with inactive_clean pages and one zone which
has "too many" free pages.

Allocating from the first zone means we evict some piece
of, potentially useful, data from the cache; allocating
from the second zone means we can keep the data in memory
and only fill up a currently unused page.


> @@ -824,39 +824,17 @@
>  #define DEF_PRIORITY (6)
>  static int refill_inactive(unsigned int gfp_mask, int user)
>  {

I've heard all kinds of things about this part of the patch,
except an explanation of why and how it is supposed to work ;)


> @@ -976,8 +954,9 @@
>  		 * We go to sleep for one second, but if it's needed
>  		 * we'll be woken up earlier...
>  		 */
> -		if (!free_shortage() || !inactive_shortage()) {
> -			interruptible_sleep_on_timeout(&kswapd_wait, HZ);
> +		if (current->need_resched || !free_shortage() ||
> +				!inactive_shortage()) {
> +			interruptible_sleep_on_timeout(&kswapd_wait, HZ/10);

Makes sense.  Integrated in my tree ;)


regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Thu, 24 May 2001, Rik van Riel wrote:

> On Thu, 24 May 2001, Mike Galbraith wrote:
> > On Sun, 20 May 2001, Rik van Riel wrote:
> >
> > > Remember that inactive_clean pages are always immediately
> > > reclaimable by __alloc_pages(), if you measured a performance
> > > difference by freeing pages in a different way I'm pretty sure
> > > it's a side effect of something else.  What that something
> > > else is I'm curious to find out, but I'm pretty convinced that
> > > throwing away data early isn't the way to go.
> >
> > OK.. let's forget about throughput for a moment and consider
> > those annoying reports of 0 order allocations failing :)
>
> Those are ok.  All failing 0 order allocations are either
> atomic allocations or GFP_BUFFER allocations.  I guess we
> should just remove the printk()  ;)

Hmm.  The guy who's box locks up on him after a burst of these probably
doesn't think these failures are very OK ;-)  I don't think order 0
failing is cool at all.. ever.  A (long) while back, Linus specifically
mentioned worrying about atomic allocation reliability.

> > What do you think of the below (ignore the refill_inactive bit)
> > wrt allocator reliability under heavy stress?  The thing does
> > kick in and pump up zones even if I set the 'blood donor' level
> > to pages_min.
>
> > -		unsigned long water_mark;
> > +		unsigned long water_mark = 1 << order;
>
> Makes no sense at all since water_mark gets assigned not 10
> lines below.  ;)

That assignment was supposed to turn into +=.

> > +		if (direct_reclaim) {
> > +			int count;
> > +
> > +			/* If we're in bad shape.. */
> > +			if (z->free_pages < z->pages_low && z->inactive_clean_pages) {
>
> I'm not sure if we want to fill up the free list all the way
> to z->pages_low all the time, since "free memory is wasted
> memory".

Yes.  I'm just thinking of the burst of allocations with no reclaim
possible.

> The reason the current scheme only triggers when we reach
> z->pages_min and then goes all the way up to z->pages_low
> is memory defragmentation. Since we'll be doing direct

Ah.

> reclaim for just about every allocation in the system, it
> only happens occasionally that we throw away all the
> inactive_clean pages between z->pages_min and z->pages_low.

This one has me puzzled.  We're reluctant to release cleaned pages,
but at the same time, we reclaim if possible as soon as all zones
are below pages_high.

> > +				count = 4 * (1 << page_cluster);
> > +				/* reclaim a page for ourselves if we can afford to.. */
> > +				if (z->inactive_clean_pages > count)
> > +					page = reclaim_page(z);
> > +				if (z->inactive_clean_pages < 2 * count)
> > +					count = z->inactive_clean_pages / 2;
> > +			} else count = 0;
>
> What exactly is the reasoning behind this complex  "count"
> stuff? Is there a good reason for not just refilling the
> free list up to the target or until the inactive_clean list
> is depleted ?

Well, yes.  You didn't like the 50/50 split thingy I did before, so
I connected zones to a tricklecharger instead.

> > +			/*
> > +			 * and make a small donation to the reclaim challenged.
> > +			 *
> > +			 * We don't ever want a zone to reach the state where we
> > +			 * have nothing except reclaimable pages left.. not if
> > +			 * we can possibly do something to help prevent it.
> > +			 */
>
> This comment makes little sense

If not, then none of it does.  This situation is the ONLY thing I
was worried about.  free_pages + inactive_clean_pages > pages_min
does nothing about free_pages for those who can't reclaim if most
of that is inactive_clean_pages. IFF it's possible to be critical
on free_pages and still have clean pages, it does make sense.

> > +		if (z->inactive_clean_pages - z->free_pages > z->pages_low
> > +				&& waitqueue_active(&kreclaimd_wait))
> > +			wake_up_interruptible(&kreclaimd_wait);
>
> This doesn't make any sense to me at all.  Why wake up
> kreclaimd just because the difference between the number
> of inactive_clean pages and free pages is large ?

You had to get there with direct_reclaim not set was the thought.
Nobody gave the zone a transfusion, but there is a blood supply.
If nobody gets around to refilling the zone, kreclaimd will.

> Didn't we determine in our last exchange of email that
> it would be a good thing under most loads to keep as much
> inactive_clean memory around as possible and not waste^Wfree
> memory early ?

So why do we reclaim if we're just below pages_high?  The whole
point of this patch is to reclaim _less_ in the general case, but
to do so in a timely manner if we really need it.

> > -	/*
> > -	 * First, see if we have any zones with lots of free memory.
> > -	 *
> > -	 * We allocate free memory first because it doesn't contain
> > -	 * any data ... DUH!
> > -	 */
>
> We want to keep this.  Suppose we have one zone which is
> half filled with inactive_clean pages and one zone which
> has "too many" free pages.

Oops.

> Allocating from the first zone means we evict some piece
> of, potentially useful, data from the cache; allocating
> from the second zone means we can keep the data in memory
> and only fill up a currently unused page.
>
>
> > @@ -824,39 +824,17 @@
> >  #define DEF_PRIORITY (6)
> >  static int refill_inactive(unsigned int gfp_mask, int user)
> >  {
>
> I've heard all kinds of things about this part of the patch,
> except an explanation of why and how it is supposed to work ;)

You were supposed to ignore that bit.

It's supposed to cover the situation where kswapd is sleeping,
and you have a slew of little 'helper-bees' nibbling at the
problem.  Just reach out and grab what you _are going to_ grab
anyway and get it over with.  The loop makes absolutely no sense
to me, and removing it provides a performance increase 100% of
the time.  kswapd will come back really soon if it needs to, and
user tasks have no buisness looping around when they can either
get on with their allocation or hit the scheduling point in the
allocator.  Nothing they are doing is helping them in the least..
it's helping future allocations. IMHO, one time helping is enough.
In the opinion of my performance measurements, one time helping
is enough, and more than one is too many ;-).

> > @@ -976,8 +954,9 @@
> >  		 * We go to sleep for one second, but if it's needed
> >  		 * we'll be woken up earlier...
> >  		 */
> > -		if (!free_shortage() || !inactive_shortage()) {
> > -			interruptible_sleep_on_timeout(&kswapd_wait, HZ);
> > +		if (current->need_resched || !free_shortage() ||
> > +				!inactive_shortage()) {
> > +			interruptible_sleep_on_timeout(&kswapd_wait, HZ/10);
>
> Makes sense.  Integrated in my tree ;)

I managed to write 1 line that makes sense.  I'm improving eh?  :)

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Rik van Riel]

On Thu, 24 May 2001, Mike Galbraith wrote:
> On Thu, 24 May 2001, Rik van Riel wrote:
> > On Thu, 24 May 2001, Mike Galbraith wrote:
> > > On Sun, 20 May 2001, Rik van Riel wrote:
> > >
> > > > Remember that inactive_clean pages are always immediately
> > > > reclaimable by __alloc_pages(), if you measured a performance
> > > > difference by freeing pages in a different way I'm pretty sure
> > > > it's a side effect of something else.  What that something
> > > > else is I'm curious to find out, but I'm pretty convinced that
> > > > throwing away data early isn't the way to go.
> > >
> > > OK.. let's forget about throughput for a moment and consider
> > > those annoying reports of 0 order allocations failing :)
> >
> > Those are ok.  All failing 0 order allocations are either
> > atomic allocations or GFP_BUFFER allocations.  I guess we
> > should just remove the printk()  ;)
>
> Hmm.  The guy who's box locks up on him after a burst of these
> probably doesn't think these failures are very OK ;-)  I don't
> think order 0 failing is cool at all.. ever.

You may not think it's cool, but it's needed in order to
prevent deadlocks. Just because an allocation cannot do
disk IO or sleep, that's no reason to loop around like
crazy in __alloc_pages() and hang the machine ... ;)

> A (long) while back, Linus specifically mentioned worrying
> about atomic allocation reliability.

That's a separate issue.  That was, IIRC, about the
failure of atomic allocations causing packet loss on
Linux routers and, because of that, poor performance.

This is something we still need to look into, but
basically this problem is about too high latency and
NOT about "pre-freeing" more pages (like your patch
attempts).  If this problem is still an issue, it's
quite likely that the VM is holding locks for too
long so that it cannot react fast enough to free up
some inactive_clean pages.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Thu, 24 May 2001, Rik van Riel wrote:

> > > > OK.. let's forget about throughput for a moment and consider
> > > > those annoying reports of 0 order allocations failing :)
> > >
> > > Those are ok.  All failing 0 order allocations are either
> > > atomic allocations or GFP_BUFFER allocations.  I guess we
> > > should just remove the printk()  ;)
> >
> > Hmm.  The guy who's box locks up on him after a burst of these
> > probably doesn't think these failures are very OK ;-)  I don't
> > think order 0 failing is cool at all.. ever.
>
> You may not think it's cool, but it's needed in order to
> prevent deadlocks. Just because an allocation cannot do
> disk IO or sleep, that's no reason to loop around like
> crazy in __alloc_pages() and hang the machine ... ;)

True, but if we have resources available there's no excuse for a
failure.  Well, yes there is.  If the cost of that resource is
higher than the value of letting the allocation succeed.  We have
no data on the value of success, but we do plan on consuming the
reclaimable pool and do that (must), so I still think turning
these resources loose at strategic moments is logically sound.
(doesn't mean there's not a better way.. it's just an easy way)

I'd really like someone who has this problem to try the patch to
see if it does help.  I don't have this darn problem myself, so
I'm left holding a bag of idle curiosity. ;-)

	Cheers,

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[David Weinehall]

On Wed, May 23, 2001 at 05:51:50PM +0000, Scott Anderson wrote:
> David Weinehall wrote:
> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> > still a pain to work with.
> 
> If you really want to have fun, remove all swap...

Oh, I've done some testing without swap too, mainly to test Rik's
oom-killer. Seemed to work pretty well. Can't say it was enjoyable, though.


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Pavel Machek]

Hi!

> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> > still a pain to work with.
> 
> You're absolutely right. The smallest thing I'm testing with
> on a regular basis is my dual pentium machine, booted with
> mem=8m or mem=16m.
> 
> Time to hunt around for a 386 or 486 which is limited to such
> a small amount of RAM ;)

Buy agenda handheld: 16MB flash, 8MB ram, X, size of palm. It is
definitely more sexy machine than average 486. [Or get philips velo 1,
if you want keyboard ;-)]
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Pavel Machek]

Hi!

> > IMVHO every developer involved in memory-management (and indeed, any
> > software development; the authors of ntpd comes in mind here) should
> > have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
> > luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
> > still a pain to work with.
> 
> If you really want to have fun, remove all swap...

My handheld has 12MB ram, no swap ;-), and that's pretty big machine
for handheld.
								Pavel
PS: Swapping on flash disk is bad idea, right?
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

RPM Installation - Compilation errors

[jalaja devi]

I am trying to install an RPM in Redhat 6.2. But
landed up in getting these compilation errors. Could
anyone tell me watzall this mean.


I did 
rpm --rebuild "x.rpm"

Thanks in advance,
Jalaja


+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf wnp1-2.0b1
+ /bin/mkdir -p wnp1-2.0b1
+ cd wnp1-2.0b1
+ /bin/gzip -dc
/usr/src/redhat/SOURCES/wnp1-2.0b1.tar.gz
+ tar -xvvf -
+ STATUS=0
+ [ 0 -ne 0 ]
++ /usr/bin/id -u
+ [ 0 = 0 ]
+ /bin/chown -Rhf root .
++ /usr/bin/id -u
+ [ 0 = 0 ]
+ /bin/chgrp -Rhf root .
+ /bin/chmod -Rf a+rX,g-w,o-w .
+ mkdir -p /usr/doc/wnp1-2.0b1
+ cp -f /usr/src/redhat/SOURCES/wnp1-2.0b1.tar.gz
/usr/doc/wnp1-2.0b1
+ exit 0
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd wnp1-2.0b1
+ cd ./WaveNIC1/Linux/AdapterDriver
+ cpu_count=0
+ find_num_proc
+ v1=processor
+ read proc sep count
+ [ -n processor ]
+ [ processor = processor ]
+ cpu_count=1
+ read proc sep count
+ [ -n vendor_id ]
+ [ vendor_id = processor ]
+ read proc sep count
+ [ -n cpu ]
+ [ cpu = processor ]
+ read proc sep count
+ [ -n model ]
+ [ model = processor ]
+ read proc sep count
+ [ -n model ]
+ [ model = processor ]
+ read proc sep count
+ [ -n stepping ]
+ [ stepping = processor ]
+ read proc sep count
+ [ -n cpu ]
+ [ cpu = processor ]
+ read proc sep count
+ [ -n cache ]
+ [ cache = processor ]
+ read proc sep count
+ [ -n fdiv_bug ]
+ [ fdiv_bug = processor ]
+ read proc sep count
+ [ -n hlt_bug ]
+ [ hlt_bug = processor ]
+ read proc sep count
+ [ -n sep_bug ]
+ [ sep_bug = processor ]
+ read proc sep count
+ [ -n f00f_bug ]
+ [ f00f_bug = processor ]
+ read proc sep count
+ [ -n coma_bug ]
+ [ coma_bug = processor ]
+ read proc sep count
+ [ -n fpu ]
+ [ fpu = processor ]
+ read proc sep count
+ [ -n fpu_exception ]
+ [ fpu_exception = processor ]
+ read proc sep count
+ [ -n cpuid ]
+ [ cpuid = processor ]
+ read proc sep count
+ [ -n wp ]
+ [ wp = processor ]
+ read proc sep count
+ [ -n flags ]
+ [ flags = processor ]
+ read proc sep count
+ [ -n bogomips ]
+ [ bogomips = processor ]
+ read proc sep count
+ [ -n  ]
+ read proc sep count
+ echo cpu_count  1
+ [ 1 -gt 1 ]
+ make
Makefile:137: wnicp1_d.d: No such file or directory
Makefile:137: OsSupport_d.d: No such file or directory
Makefile:137: wnic_proc_d.d: No such file or directory
Makefile:137: wnic_ioctl_d.d: No such file or
directory
Makefile:137: Device_d.d: No such file or directory
Makefile:137: Driver_d.d: No such file or directory
Makefile:137: Data_d.d: No such file or directory
Makefile:137: Enet_d.d: No such file or directory
Makefile:137: Fragment_d.d: No such file or directory
Makefile:137: MI_d.d: No such file or directory
Makefile:137: Mem_d.d: No such file or directory
Makefile:137: OC48_d.d: No such file or directory
Makefile:137: Od_d.d: No such file or directory
Makefile:137: PppSend_d.d: No such file or directory
Makefile:137: PppSupport_d.d: No such file or
directory
Makefile:137: TA1000_d.d: No such file or directory
Makefile:137: pm5357_d.d: No such file or directory
Makefile:137: if_spppsubr_d.d: No such file or
directory
Makefile:137: suni2488_api_d.d: No such file or
directory
Makefile:137: suni2488_hw_d.d: No such file or
directory
Makefile:137: suni2488_intf_d.d: No such file or
directory
Makefile:137: suni2488_isr_d.d: No such file or
directory
Makefile:137: suni2488_loh_d.d: No such file or
directory
Makefile:137: suni2488_poh_d.d: No such file or
directory
Makefile:137: suni2488_pyld_d.d: No such file or
directory
Makefile:137: suni2488_rtos_d.d: No such file or
directory
Makefile:137: suni2488_soh_d.d: No such file or
directory
Makefile:137: suni2488_util_d.d: No such file or
directory
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_util.c:39:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_util.c:39:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_soh.c:38:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_soh.c:38:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_rtos.c:36:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_rtos.c:36:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_pyld.c:38:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_pyld.c:38:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_poh.c:39:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_poh.c:39:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_loh.c:38:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_loh.c:38:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_isr.c:45:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_isr.c:45:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_intf.c:39:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_intf.c:39:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_hw.c:47:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_hw.c:47:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_api.c:46:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/suni2488_rtos.h:39,
                 from
../../SharedSource/suni2488_api.h:47,
                 from
../../SharedSource/suni2488_api.c:46:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/pm5357.c:53:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/pm5357.c:53:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/pm5357.c:56:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/pm5357.c:56:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/TA1000.c:29:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/TA1000.c:29:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/TA1000.c:30:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/TA1000.c:30:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/PppSupport.c:29:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/PppSupport.c:29:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from
../../SharedSource/PppSupport.c:30:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from
../../SharedSource/PppSupport.c:30:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/PppSend.c:25:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/PppSend.c:25:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/PppSend.c:26:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/PppSend.c:26:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from ../../SharedSource/Od.c:25:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from ../../SharedSource/Od.c:25:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/OC48.c:28:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/OC48.c:28:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/OC48.c:29:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/OC48.c:29:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Mem.c:25:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Mem.c:25:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/MI.c:22:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/MI.c:22:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/MI.c:23:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/MI.c:23:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Mem.h:27,
                 from
../../SharedSource/Fragment.c:23:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Mem.h:27,
                 from
../../SharedSource/Fragment.c:23:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Enet.c:22:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Enet.c:22:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/Enet.c:23:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from ../../SharedSource/Enet.c:23:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Data.h:38,
                 from ../../SharedSource/Data.c:25:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from ../../SharedSource/Data.h:38,
                 from ../../SharedSource/Data.c:25:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from ../include/Driver.h:32,
                 from Driver.c:24:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from ../include/Driver.h:32,
                 from Driver.c:24:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from Driver.c:24:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from Driver.c:24:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from Driver.c:35:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from Device.c:25:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from Device.c:25:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from Device.c:38:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from ../include/Driver.h:40,
                 from Device.c:38:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from Device.c:41:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from wnic_ioctl.c:27:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from wnic_ioctl.c:27:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:51,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from
/usr/src/linux/include/net/sock.h:52,
                 from wnic_ioctl.c:43:
/usr/src/linux/include/asm/hardirq.h:23: warning:
`synchronize_irq' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:78:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/interrupt.h:52,
                 from
/usr/src/linux/include/linux/netdevice.h:334,
                 from
/usr/src/linux/include/net/sock.h:52,
                 from wnic_ioctl.c:43:
/usr/src/linux/include/asm/softirq.h:72: warning:
`synchronize_bh' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:80:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from wnic_ioctl.c:47:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from wnic_proc.c:21:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from wnic_proc.c:21:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from wnic_proc.c:34:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from OsSupport.c:22:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from OsSupport.c:22:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from OsSupport.c:23:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from wnicp1.c:38:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from wnicp1.c:38:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from wnicp1.c:45:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
In file included from
/usr/src/linux/include/linux/sched.h:20,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from wnicp1.c:38:
/usr/src/linux/include/linux/smp.h:77: warning:
`smp_num_cpus' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:72:
warning: this is the location of the previous
definition
/usr/src/linux/include/linux/smp.h:83: warning:
`smp_call_function' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:98:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/linux/sched.h:74,
                 from
/usr/src/linux/include/linux/mm.h:4,
                 from
/usr/src/linux/include/linux/slab.h:14,
                 from
/usr/src/linux/include/linux/malloc.h:4,
                 from ../include/Linux.h:38,
                 from
../../include/../Linux/include/OsSupport.h:23,
                 from ../../include/OsEnv.h:179,
                 from
../../SharedSource/KernelOdWrapper.h:29,
                 from wnicp1.c:38:
/usr/src/linux/include/asm/processor.h:175: warning:
`cpu_data' redefined
/usr/src/linux/include/linux/modules-smp/i386_ksyms.ver:62:
warning: this is the location of the previous
definition
In file included from
/usr/src/linux/include/asm/pgtable.h:85,
                 from
/usr/src/linux/include/linux/vmalloc.h:7,
                 from
/usr/src/linux/include/asm/io.h:102,
                 from ../include/wnicp1.h:79,
                 from wnicp1.c:45:
/usr/src/linux/include/asm/smp.h:204: warning:
`smp_processor_id' redefined
/usr/src/linux/include/linux/smp.h:78: warning: this
is the location of the previous definition
/usr/src/linux/include/asm/smp.h:206: arguments given
to macro `hard_smp_processor_id'
make: *** [wnicp1.o] Error 1
Bad exit status from /var/tmp/rpm-tmp.86686 (%build)


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Mike Galbraith]

On Sun, 20 May 2001, Dieter Nützel wrote:

> > > Three back to back make -j 30 runs for three different kernels.
> > > Swap cache numbers are taken immediately after last completion.
> >
> > The performance increase is nice, though.  Do you see similar
> > changes in different kinds of workloads ?
>
> I you have a patch against 2.4.4-ac11 I will do some tests with some
> (interactive) 3D apps.

I don't have an ac kernel resident atm, but since Alan merged here
very recently, it will probably go in ok.  If not, just holler and
I'll download ac11 and make you a clean patch.

	-Mike

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

[Dieter Nützel]

> > Three back to back make -j 30 runs for three different kernels.
> > Swap cache numbers are taken immediately after last completion.
>
> The performance increase is nice, though.  Do you see similar
> changes in different kinds of workloads ?

I you have a patch against 2.4.4-ac11 I will do some tests with some 
(interactive) 3D apps.

-Dieter