* [parisc-linux] 2.5 fix for user level page fault problems
From: James Bottomley @ 2002-12-18 16:20 UTC (permalink / raw)
To: parisc-linux; +Cc: James.Bottomley
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
It seems that going from 2.4 to 2.5 there was an over zealous removal of the
check signals return path. The problem is that if a user application takes a
page fault, that can result in a signal being posted (specifically SEGV for
illegal memory access). If we never check the signals, the instruction is
retried and re-faults ad infinitum (well actually, it seems to terminate with
an unaligned instruction trap in this case after a few hundred faults).
The attached path makes signal posting on page fault work again
James
[-- Attachment #2: tmp.diff --]
[-- Type: text/plain , Size: 422 bytes --]
===== entry.S 1.8 vs edited =====
--- 1.8/arch/parisc/kernel/entry.S Sun Nov 24 17:36:53 2002
+++ edited/entry.S Mon Dec 16 22:09:59 2002
@@ -944,11 +944,11 @@
ldo -16(%r30),%r29 /* Reference param save area */
#endif
- ldil L%intr_restore, %r2
+ ldil L%intr_check_sig, %r2
copy %r25, %r16 /* save pt_regs */
b handle_interruption
- ldo R%intr_restore(%r2), %r2
+ ldo R%intr_check_sig(%r2), %r2
/*
^ permalink raw reply
* Re: [drm:drm_init] *ERROR* Cannot initialize the agpgart module.
From: Dave Jones @ 2002-12-18 16:29 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <200212180757.53583.tomlins@cam.org>
On Wed, Dec 18, 2002 at 07:57:53AM -0500, Ed Tomlinson wrote:
> > > > Ed, does it work if you take all the __init out of the agp code?
> > > My moneys on it working. The oops looked like it was jumping to oblivion
> > > when it called agp_backend_initialize.
> Dave when you have this in a bk tree let me know and I will pull and
> verify it working here.
bk://linux-dj.bkbits.net/agpgart
I've given it a compile testing, but not booted it yet.
Scream if necessary.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [Fwd: [Bug 136] New: FSID returned from statvfs always 0]
From: Bryan Henderson @ 2002-12-18 16:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Andries Brouwer, H. Peter Anvin, linux-fsdevel
In-Reply-To: <3E000454.F791294@digeo.com>
>If this feature is to have any value, should not the fsid remain stable
>as the disk gets moved around the machine?
To have _any_ value would be an overstatement. Today's FSID (always zero)
has no value. An FSID that works only in machines where the disks never
move would have more value than that.
But as long as we're talking about designs that solve the entire problem,
don't forget this aspect too: A perfect FSID must be stable as the
filesystem is moved from one disk to another while the disks stay put.
And, more importantly, must change when you replace the contents of a disk
with a new or different filesystem.
^ permalink raw reply
* RE: ifconfig: SCC1 enet0 not showing up
From: James Don @ 2002-12-18 16:25 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
My goodness ... thanks for all the email ...
The problem was indeed not having CONFIG_IP_PNP ...
Regards and thanks,
Jim
-----Original Message-----
From: James Don [mailto:JDon@spacebridge.com]
Sent: Wednesday, December 18, 2002 9:57 AM
To: 'linuxppc-embedded@lists.linuxppc.org'
Subject: ifconfig: SCC1 enet0 not showing up
Hi,
I have a MPC860 FADS based board running kernel 2.4.
My Ethernet is not showing up ... I have compiled in enet support ... fixed
my port pins ... but when I do ifconfig I see only:
# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
At start my enet scc is configured properly ... I am pretty sure because I
see:
## Transferring control to Linux (at address 00000000) ...
Linux version 2.4.20-pre8 ...
Kernel command line: root=/dev/ram rw
ip=192.168.104.101:192.168.103.151:192.168.104.1:255.255.255.0:BigMoney::off
...
eth0: CPM ENET Version 0.2 on SCC1, 00:22:2e:ff:67:de
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1425k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 44k init
....
Am I missing some kernel config (see below)?
Jim
#
# Automatically generated by make menuconfig: don't edit
#
# CONFIG_UID16 is not set
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# Platform support
#
CONFIG_PPC=y
CONFIG_PPC32=y
# CONFIG_6xx is not set
# CONFIG_4xx is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
CONFIG_8xx=y
# CONFIG_PPC_STD_MMU is not set
CONFIG_SERIAL_CONSOLE=y
# CONFIG_RPXLITE is not set
# CONFIG_RPXCLASSIC is not set
# CONFIG_BSEIP is not set
CONFIG_FADS=y
# CONFIG_TQM823L is not set
# CONFIG_TQM850L is not set
# CONFIG_TQM855L is not set
# CONFIG_TQM860L is not set
# CONFIG_FPS850L is not set
# CONFIG_TQM860 is not set
# CONFIG_SPD823TS is not set
# CONFIG_IVMS8 is not set
# CONFIG_IVML24 is not set
# CONFIG_SM850 is not set
# CONFIG_MBX is not set
# CONFIG_WINCEPT is not set
# CONFIG_ALL_PPC is not set
# CONFIG_SMP is not set
CONFIG_MATH_EMULATION=y
CONFIG_EMBEDDEDBOOT=y
#
# General setup
#
# CONFIG_HIGHMEM is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
# CONFIG_PCI_QSPAN is not set
# CONFIG_PCI is not set
CONFIG_NET=y
# CONFIG_SYSCTL is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
# CONFIG_PPC_RTC is not set
# CONFIG_CMDLINE_BOOL is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_BLK_STATS=y
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_GMAC is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
# CONFIG_STRIP is not set
# CONFIG_WAVELAN is not set
# CONFIG_ARLAN is not set
# CONFIG_AIRONET4500 is not set
# CONFIG_AIRONET4500_NONCS is not set
# CONFIG_AIRONET4500_PROC is not set
CONFIG_HERMES=y
# CONFIG_NET_WIRELESS is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Console drivers
#
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
#
# Macintosh device drivers
#
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGO8XX is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_PROC=y
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_TMPFS is not set
CONFIG_RAMFS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set
#
# Sound
#
# CONFIG_SOUND is not set
#
# MPC8xx CPM Options
#
CONFIG_SCC_ENET=y
CONFIG_SCC1_ENET=y
# CONFIG_SCC2_ENET is not set
# CONFIG_SCC3_ENET is not set
# CONFIG_FEC_ENET is not set
# CONFIG_ENET_BIG_BUFFERS is not set
# CONFIG_SMC2_UART is not set
# CONFIG_USE_SCC_IO is not set
# CONFIG_8xx_COPYBACK is not set
# CONFIG_8xx_CPU6 is not set
# CONFIG_UCODE_PATCH is not set
#
# USB support
#
# CONFIG_USB is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Library routines
#
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.5.52-mm1
From: Andrew Morton @ 2002-12-18 16:37 UTC (permalink / raw)
To: tomlins; +Cc: linux-kernel
In-Reply-To: <20021218122602.288D52230@oscar.casa.dyndns.org>
Ed Tomlinson wrote:
>
> Hi
>
> Got this oops this morning reading news:
>
> Dec 18 07:15:29 oscar kernel: printing eip:
> Dec 18 07:15:29 oscar kernel: c0140317
> Dec 18 07:15:29 oscar kernel: Oops: 0002
> Dec 18 07:15:29 oscar kernel: CPU: 0
> Dec 18 07:15:29 oscar kernel: EIP: 0060:[remove_inode_buffers+67/116] Not tainted
> Dec 18 07:15:29 oscar kernel: EFLAGS: 00010246
> Dec 18 07:15:29 oscar kernel: EIP is at remove_inode_buffers+0x43/0x74
> Dec 18 07:15:29 oscar kernel: eax: 0dc4c344 ebx: c3440dc4 ecx: c3440dc6 edx: 0000c344
> Dec 18 07:15:29 oscar kernel: esi: c3440cd4 edi: 00000001 ebp: dfdb9ebc esp: dfdb9e8c
> Dec 18 07:15:29 oscar kernel: ds: 0068 es: 0068 ss: 0068
> Dec 18 07:15:29 oscar kernel: Process kswapd0 (pid: 7, threadinfo=dfdb8000 task=dfdcb860)
> Dec 18 07:15:29 oscar kernel: Stack: c3440cd4 c3440cdc dfdb8000 c0152ff7 c3440cd4 00000080 00000923 d
> Dec 18 07:15:29 oscar kernel: 00000036 00000036 c3440b5c d76876dc 00000000 c01530db 00000080 c
> Dec 18 07:15:29 oscar kernel: 00000080 000001d0 00000221 c02a5374 fffffe27 0000000c 0d024a92 0
Wow, what a mess. Something has written this "c3440cd4" value
into the stack and most of the registers. Presumably it was
some interrupt. Don't know, sorry.
^ permalink raw reply
* Re: [PATCH]: config1 is only used by MIPS32 and MIPS64
From: Maciej W. Rozycki @ 2002-12-18 16:29 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2n0n4qezp.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> subject told everything
The code is broken anyway -- it shouldn't use #ifdef in the first place
-- that's what PRId is there for.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: [parisc-linux] 2.5 fix for user level page fault problems
From: Randolph Chung @ 2002-12-18 16:34 UTC (permalink / raw)
To: James Bottomley; +Cc: parisc-linux
In-Reply-To: <200212181620.gBIGKOJ02593@localhost.localdomain>
In reference to a message from James Bottomley, dated Dec 18:
> It seems that going from 2.4 to 2.5 there was an over zealous removal of the
> check signals return path. The problem is that if a user application takes a
> page fault, that can result in a signal being posted (specifically SEGV for
> illegal memory access). If we never check the signals, the instruction is
> retried and re-faults ad infinitum (well actually, it seems to terminate with
> an unaligned instruction trap in this case after a few hundred faults).
thanks James. I've commited this to our 2.5 tree. We had fixed this in
2.4 a couple of weeks ago but I forgot to commit this to 2.5 too.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* 2.5.52 take 1
From: Margit Schubert-While @ 2002-12-18 16:42 UTC (permalink / raw)
To: linux-kernel
Hurrah - Got a 2.5 kernel to boot.
No DEVFS, everything compiled in.
Compiling in USB oopses on boot. No serial terminal so will
copy by hand later.
Snips from boot and log below.
Comments on the "<---***" lines and log ?
(config attached at end)
-- snip --
<5>Intel(R) PRO/100 Network Driver - version 2.1.24-k2
<5>Copyright (c) 2002 Intel Corporation
<5>
<7>e100: selftest OK.
<3>Freeing alive device dfc24800, eth%%d <------
********
<5>e100: eth0: Intel(R) PRO/100 VE Network Connection
<5> Mem:0xff9fb000 IRQ:14 Speed:0 Mbps Dx:N/A
<5> Hardware receive checksums enabled
<5>
<4>scsi HBA driver <NULL> didn't set max_sectors, please fix the
template <------ *******
<6>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<4> <Adaptec 3960D Ultra160 SCSI adapter>
<4> aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
<4>
<4>(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
<5> Vendor: FUJITSU Model: MAN3184MP Rev: 0108
<5> Type: Direct-Access ANSI SCSI revision: 03
<4>(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
<5> Vendor: FUJITSU Model: MAN3184MP Rev: 0108
<5> Type: Direct-Access ANSI SCSI revision: 03
-- end snip --
-- snip --
Dec 18 16:58:11 margit kernel: Saw underflow (752 of 768 bytes). Treated as
error
Dec 18 16:58:11 margit last message repeated 9 times
Dec 18 16:58:11 margit kernel: Saw underflow (748 of 768 bytes). Treated as
error
Dec 18 16:58:11 margit last message repeated 9 times
-- end snip --
-- config stripped --
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_SWAP=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_NET=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_MPENTIUM4=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_PREEMPT=y
CONFIG_X86_MCE=y
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PM=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_PCI=y
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
CONFIG_PARPORT_1284=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_BLK_DEV_INITRD=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=16
CONFIG_AIC7XXX_RESET_DELAY_MS=2000
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IPV6_SCTP__=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_E100=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=y
CONFIG_INTEL_RNG=y
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_RAW_DRIVER=y
CONFIG_AUTOFS4_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y
CONFIG_UDF_FS=y
CONFIG_UFS_FS=y
CONFIG_SMB_FS=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_DUMMY=y
CONFIG_SND_VIRMIDI=y
CONFIG_SND_MTPAV=y
CONFIG_SND_SERIAL_U16550=y
CONFIG_SND_MPU401=y
CONFIG_SND_INTEL8X0=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SLAB=y
CONFIG_KALLSYMS=y
CONFIG_X86_BIOS_REBOOT=y
-- end config --
Margit
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Dave Jones @ 2002-12-18 16:41 UTC (permalink / raw)
To: Horst von Brand; +Cc: Linus Torvalds, linux-kernel
In-Reply-To: <200212181340.gBIDeOmK018730@pincoya.inf.utfsm.cl>
On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> [Extremely interesting new syscall mechanism tread elided]
>
> What happened to "feature freeze"?
*bites lip* it's fairly low impact *duck*.
Given the wins seem to be fairly impressive across the board, spending
a few days on getting this right isn't going to push 2.6 back any
noticable amount of time.
This stuff is mostly of the case "it either works, or it doesn't".
And right now, corner cases like apm aside, it seems to be holding up
so far. This isn't as far reaching as it sounds. There are still
drivers being turned upside down which are changing things in a
lot bigger ways than this[1]
Dave
[1] Myself being one of the guilty parties there, wrt agp.
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH]: make highmem only things enclosed in the right #ifdef
From: Maciej W. Rozycki @ 2002-12-18 16:35 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2k7i8qezg.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> +#ifdef CONFIG_HIGHMEM
> unsigned long vaddr;
> - pgd_t *pgd, *pgd_base;
> pmd_t *pmd;
> pte_t *pte;
> -
> + pgd_t *pgd, pgd_base;
> +#endif
> /* Initialize the entire pgd. */
> pgd_init((unsigned long)swapper_pg_dir);
Please don't change the spacing this way -- it worsens readability.
Check other pathes for cases like this, too.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* [parisc-linux] 2.5 randomly kills applications with page faults
From: James Bottomley @ 2002-12-18 16:37 UTC (permalink / raw)
To: parisc-linux; +Cc: James.Bottomley
I find when booting 2.5.51 up on a C380 that applications seem to take random
page faults and die. It seems that the more heavily an application does file
accesses, the more likely it is to suffer from this.
In debugging the problems, so far it has always been stack manipulation
instructions in the user level code causing this. Further, on adding a
register dump to the page fault debugging code, the reason is that the stack
pointer is way out of where it should be for a user process (around 0x4f000),
so I surmise it got clobbered on a rare return path from kernel to user.
Does anyone have any additional information and pointers? I'm trying to audit
entry.S to see if there is a little used path that can clobber the stack, but
my parisc assembly isn't the best...
James
^ permalink raw reply
* Re: [PATCH]: make prototype of printk available
From: Maciej W. Rozycki @ 2002-12-18 16:37 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m23cowqeyn.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> Once there, put a tag to the printk.
Why is the default log level incorrect here?
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Linus Torvalds @ 2002-12-18 16:49 UTC (permalink / raw)
To: Dave Jones; +Cc: Horst von Brand, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <20021218164119.GC27695@suse.de>
On Wed, 18 Dec 2002, Dave Jones wrote:
> On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> > [Extremely interesting new syscall mechanism tread elided]
> >
> > What happened to "feature freeze"?
>
> *bites lip* it's fairly low impact *duck*.
However, it's a fair question.
I've been wondering how to formalize patch acceptance at code freeze, but
it might be a good idea to start talking about some way to maybe put
brakes on patches earlier, ie some kind of "required approval process".
I think the system call thing is very localized and thus not a big issue,
but in general we do need to have something in place.
I just don't know what that "something" should be. Any ideas? I thought
about the code freeze require buy-in from three of four people (me, Alan,
Dave and Andrew come to mind) for a patch to go in, but that's probably
too draconian for now. Or is it (maybe start with "needs approval by two"
and switch it to three when going into code freeze)?
Linus
^ permalink raw reply
* Re: ifconfig: SCC1 enet0 not showing up
From: Wolfgang Denk @ 2002-12-18 16:43 UTC (permalink / raw)
To: James Don; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <DB0585C9F6F9D411BE8F00D0B7896A4CC05F4E@SNCMAIL>
In message <DB0585C9F6F9D411BE8F00D0B7896A4CC05F4E@SNCMAIL> you wrote:
>
> My Ethernet is not showing up ... I have compiled in enet support ... fixed
> my port pins ... but when I do ifconfig I see only:
Probably you did not configure the network interface at all?
> At start my enet scc is configured properly ... I am pretty sure because I
> see:
> ## Transferring control to Linux (at address 00000000) ...
> Linux version 2.4.20-pre8 ...
> Kernel command line: root=/dev/ram rw
> ip=192.168.104.101:192.168.103.151:192.168.104.1:255.255.255.0:BigMoney::off
>From this command line I suspect that you intend to use IP
autoconfiguration, but then...
...
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> # CONFIG_IP_ADVANCED_ROUTER is not set
> # CONFIG_IP_PNP is not set
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...then you don't enable IP autoconfiguration in the kernel, so you
will have to manually configure the interface.
I guess you want to define CONFIG_IP_PNP ...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Why is an average signature file longer than an average Perl script??
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH]: fix compiler warnings in the math-emulator
From: Maciej W. Rozycki @ 2002-12-18 16:43 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux mips mailing list, Ralf Baechle
In-Reply-To: <m2znr4p0e2.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> this patch does:
>
> * redefine SETCX to only set cx
> * define a new macre SETANDTESTCX for the few cases when we also want to
> test the value set.
Is it needed? The part that returns .mx should be optimized away by the
compiler automagically if unused.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Larry McVoy @ 2002-12-18 16:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Jones, Horst von Brand, linux-kernel, Alan Cox,
Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212180844550.29852-100000@home.transmeta.com>
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
We went through this here for the bk-3.0 release. We're a much smaller
team so this may not work at all for you, but it was very successful
for us, so much so that we are looking at formalizing it in BK. But
you can apply the same process outside of BK just fine.
We created a well known spot for pending patches; all reviewers need access
to that spot. Here's the README from that directory:
There should be the following subdirectories here
ready/ -> waiting on review
done/ -> in the tree
rejected/ -> no good
In the ready/ subdirectory, for each repository which has changes that
want to be in bk-3.0 but are not, I want:
ready/atrev -> /home/bk/wscott/bk-3.0-atrev
ready/atrev.RTI
ready/atrev.REVIEWED
The first is a symlink to the location of the repository.
The second is an RTI request which describes what is in the repo and why
it should go in.
The third contains the review comments in the form
lm (approved|not approved)
review comments
wscott (approved|not approved)
review comments
etc.
Once the REVIEWED file contains enough approvals, in the judgement
of the gatekeeper, then he pulls the repo into the bk-3.0 tree and moves
the 3 files from ready/* to done/*
The things which worked very well were:
a) extremely simple. As we added developers they understood right away
what the process was.
b) centralized location. Anyone could be bored and go do a review.
c) tight control on the tree.
We're thinking about formalizing this in the context of BK as follows:
NAME
bk queue - manage the queue of pending changes
DESCRIPTION
bk queue is used to manage a queue of changes to a repository.
It is typically used on integration repositories where tighter
controls on change are desirable.
In all commands, if no URL is specified, the implied URL is the
parent of the current repository, if any. The URL "." means this
repository.
XXX - need a large paragraph on the importance of not circulating
changesets which are in review state. They'll come back.
bk queue [-n<name>] [-R<rti>] [<URL>]
This is like a bk push but wants a "request to integrate"
(RTI) which is sent with the changes. It also wants a name
for the set of changes. All pending changesets are pushed.
If no name is given, the user is prompted for one. If no
RTI is given, the user is prompted for one.
bk queue -l [-n<name>] [<URL>]
Lists the set of pending changes in the queue like so:
<name> <date> <user> <state>
Values for the <state> field:
unreviewed - nobody has looked at it yet
reviewed by <reviewer> on <date> - obvious
accepted - it is in accepted state but not integrated
rejected - reviewed and rejected
Note that if there are multiple reviewers of a change, there
will be multiple lines in the listing for that change.
If the <name> arg is present then restrict the listing to
that name. If the <name> arg is present more than once,
restrict the listing to the set of named changes.
Could also have a -s<state> option which restricts the listing
to those changes in <state> state.
bk queue -pR [-o<file>] <name> [<URL>]
Retrieves and displays the RTI for change <name>.
If <file> is specified, put the form there.
bk queue -pr [-o<file>] [-u<user>] <name> [<URL>]
Retrieves and displays the review form[s] for change <name>.
If a user is specified, retrieve that users' review only.
If <file> is specified, put the form there.
bk queue -uR [<rti>] [<URL>]
Replaces any existing RTI with the specified RTI. If no RTI
is specified, it prompts you for one like bk setup does.
bk queue -ur [<review>] [<URL>]
Adds or replaces any existing review form with the specified
review. If no review is specified, it prompts you for one
like bk setup does. You may only replace your own reviews.
bk queue -O[<owner>] [<URL>]
Sets the owner of the repository to <owner>. Only the owner
may update the repository. Only the current owner can change
the ownership. If no owner is specified and there is an owner
and the caller is the owner, then delete the owner.
(This is nothing more than a pre-{incoming,commit}-owner trigger)
bk queue -d<name> [-f] [<URL>]
Delete the named change from the queue. This deletes EVERYTHING,
the patch, rti, reviews, everything. Only the submitter of the
change may delete the change unless the -f option is supplied.
bk queue -U<name> [-R<rti>] [<URL>]
Replace the changes in the queue <name> with the set of
changesets in the current repository. If the <rti> is
present, replace the current RTI form with the specified form.
All reviews, if any, are updated with a note that indicates
the existing review was against changes which have been replaced.
GUI
This is a command line tool; Bryan gets to do bk queuetool
using these interfaces.
TODO
- how do we merge?
- define a format for the RTI
- define a format for reviews
- should the RTI & review files be KV files?
- should the {name/RTI/REVIEWS} live as part of the repo and be
propogated? I think yes for upstream propogation, no for
downstream. Hard to say.
- need a way to add a queue item with no changes, i.e., an RFE which
needs to be in the tree but there are no changes yet.
FILES
BitKeeper/queue/<name>/CSETS - changeset keys for change <name>
BitKeeper/queue/<name>/RTI - RTI for change <name>
BitKeeper/queue/<name>/PATCH - BK patch for change <name>
BitKeeper/queue/<name>/RESYNC - exploded patch for change <name>
BitKeeper/queue/<name>/review.user - review by user for change <name>
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Dave Jones @ 2002-12-18 16:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Horst von Brand, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212180844550.29852-100000@home.transmeta.com>
On Wed, Dec 18, 2002 at 08:49:37AM -0800, Linus Torvalds wrote:
> > > What happened to "feature freeze"?
> > *bites lip* it's fairly low impact *duck*.
> However, it's a fair question.
Indeed. Were you merging something like preempt at this stage, I'd be wondering
if you'd broken out the eggnog a little too soon.
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?
You'd likely need an odd number of folks in this cabal^Winner circle
though, or would you just do it and be damned if you got an equal
number of 'aye's and 'nay's ? 8-)
Other than that, it reminds me of the way the gcc folks work, with a
number of people reviewing patches before acceptance [not that this
doesn't happen on l-k already], and at least 1 approval from someone
prepared to approve submissions.
The approval process does seem to be quite a lot of work though.
I think it was rth last year at OLS who told me that at that time
he'd been doing more approving of other peoples stuff than coding himself.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: Grant Grundler @ 2002-12-18 16:58 UTC (permalink / raw)
To: jsoe0708; +Cc: Ed Schaller, parisc-linux
In-Reply-To: <3DED9BBD0000213A@ocpmta7.freegates.net>
On Tue, Dec 17, 2002 at 08:12:03AM +0100, jsoe0708@tiscali.be wrote:
> Just to avoid you loose time here is a diff:
...
> - if (ee_data[27] == 0) { /* No valid media table. */
> + if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) { /* No valid media
> table. */
Like I suspected, backing out this change made add-on boards work again.
I've reverted that change in 2.4.20-pa15 along with a traps.c change.
Please apply by hand and try the 4-port again.
thanks,
grant
^ permalink raw reply
* Re: [PATCH] sys_poll SuS compliance fix
From: Jeff Garzik @ 2002-12-18 17:06 UTC (permalink / raw)
To: Linux Kernel Mailing List, manfred
In-Reply-To: <200212181631.gBIGVLJ11794@hera.kernel.org>
Linux Kernel Mailing List wrote:
> ChangeSet 1.942, 2002/12/18 10:33:48-02:00, manfred@colorfullife.com
>
> [PATCH] sys_poll SuS compliance fix
> diff -Nru a/fs/select.c b/fs/select.c
> --- a/fs/select.c Wed Dec 18 08:31:22 2002
> +++ b/fs/select.c Wed Dec 18 08:31:22 2002
> @@ -417,7 +417,7 @@
> int nchunks, nleft;
>
> /* Do a sanity check on nfds ... */
> - if (nfds > NR_OPEN)
> + if (nfds > current->files->max_fdset && nfds > OPEN_MAX)
> return -EINVAL;
The changeset description is awful, can you give us more details
Manfred? [also in the future can you please give Linus more description
with your patches?]
In particular, I wonder if "||" is more appropriate than "&&"?
Jeff
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Eli Carter @ 2002-12-18 17:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Jones, Horst von Brand, linux-kernel, Alan Cox,
Andrew Morton
In-Reply-To: <Pine.LNX.4.44.0212180844550.29852-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> On Wed, 18 Dec 2002, Dave Jones wrote:
>
>>On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
>> > [Extremely interesting new syscall mechanism tread elided]
>> >
>> > What happened to "feature freeze"?
>>
>>*bites lip* it's fairly low impact *duck*.
>
>
> However, it's a fair question.
>
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
>
> I think the system call thing is very localized and thus not a big issue,
> but in general we do need to have something in place.
>
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?
Well, Linus, you're not the most conservative when it comes to freezes.
(Hey! Watch it with those thunderbolts!) Alan, on the other hand, I
would trust to be pretty conservative.
I'm afraid I haven't followed Dave & Andrew well enough in that light.
But my question is... if 2 are required, and say, Dave is as slushy on
freezes as you are, then have we gained much?
Perhaps 2 of 4 approve with no dissenting votes?
If Dave and Andrew are relatively conservative on freezes, then this
concern is sufficiently addressed already.
Food for thought from a relative nobody. ;)
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: [parisc-linux] 2.5 randomly kills applications with page faults
From: Randolph Chung @ 2002-12-18 17:02 UTC (permalink / raw)
To: James Bottomley; +Cc: parisc-linux
In-Reply-To: <200212181637.gBIGb5r02708@localhost.localdomain>
> In debugging the problems, so far it has always been stack manipulation
> instructions in the user level code causing this. Further, on adding a
ditto.... there's a note about this in the todo....
> register dump to the page fault debugging code, the reason is that the stack
> pointer is way out of where it should be for a user process (around 0x4f000),
> so I surmise it got clobbered on a rare return path from kernel to user.
> Does anyone have any additional information and pointers? I'm trying to audit
> entry.S to see if there is a little used path that can clobber the stack, but
> my parisc assembly isn't the best...
>
that's what i thought too, so i went through entry.S as well to see what
i can find. haven't found anything yet :(
i was able to get the kernel to die simply by having a program do
gettimeofday() in a loop with 2.5... i would guess it's a case where we
have to do some work on the syscall return path (resched, softirq, etc)
that's clobbering things, but i don't know what it is.
randolph
--
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
^ permalink raw reply
* Re: [PATCH]: remove warnings on promlib
From: Maciej W. Rozycki @ 2002-12-18 17:00 UTC (permalink / raw)
To: Juan Quintela; +Cc: linux-mips, Ralf Baechle
In-Reply-To: <m2u1hcp0ds.fsf@demo.mitica>
On 18 Dec 2002, Juan Quintela wrote:
> Index: arch/mips/lib/promlib.c
> ===================================================================
> RCS file: /home/cvs/linux/arch/mips/lib/promlib.c,v
> retrieving revision 1.1.2.1
> diff -u -r1.1.2.1 promlib.c
> --- arch/mips/lib/promlib.c 28 Sep 2002 22:28:38 -0000 1.1.2.1
> +++ arch/mips/lib/promlib.c 18 Dec 2002 00:49:18 -0000
> @@ -1,3 +1,7 @@
> +
> +#include <asm/sgialib.h>
> +#include <linux/kernel.h>
> +
> #include <stdarg.h>
>
> void prom_printf(char *fmt, ...)
A few comments:
1. <linux> includes first, <asm> ones following (hmm, shouldn't that be
obvious...).
2. <linux/kernel.h> is obviously OK for vsprintf().
3. I would hesitate using <asm/sgialib.h> here being too much platform
specific. Either a separate generic <asm/prom.h> should be created for
primitives like prom_putchar(), prom_getchar(), etc. or a private
conservative declaration should be used here. The reason is the functions
are much platform-specific, e.g. they may be pointers or even macros --
see <asm/dec/prom.h> for a not-so-trivial example (luckily, DECstations
support prom_printf() directly, so they don't have to use promlib.c).
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* RE: [ANNOUNCE] Intel PRO/100 software developer manual released
From: Feldman, Scott @ 2002-12-18 17:07 UTC (permalink / raw)
To: 'linux-kernel@vger.kernel.org',
'netdev@oss.sgi.com'
Cc: LOSTeam
> I would also like to thank the Intel editors and reviewers:
> Carolyn Abrigana, Larry Bates, Julie Donnelly, John Ronciak,
> Wen-Hwa Tao, Eli Kupermann, David Valdez, Colleen Culbertson,
> and especially Glenn Begis for not giving up.
Credit is important, and I unintentionally omitted Shaun Sloan. Thanks
Shaun for your help.
-scott
^ permalink raw reply
* Re: Freezing.. (was Re: Intel P6 vs P7 system call performance)
From: Andrew Morton @ 2002-12-18 17:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Horst von Brand, linux-kernel, Alan Cox
In-Reply-To: <Pine.LNX.4.44.0212180844550.29852-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> On Wed, 18 Dec 2002, Dave Jones wrote:
> > On Wed, Dec 18, 2002 at 10:40:24AM -0300, Horst von Brand wrote:
> > > [Extremely interesting new syscall mechanism tread elided]
> > >
> > > What happened to "feature freeze"?
> >
> > *bites lip* it's fairly low impact *duck*.
>
> However, it's a fair question.
>
> I've been wondering how to formalize patch acceptance at code freeze, but
> it might be a good idea to start talking about some way to maybe put
> brakes on patches earlier, ie some kind of "required approval process".
>
> I think the system call thing is very localized and thus not a big issue,
> but in general we do need to have something in place.
>
> I just don't know what that "something" should be. Any ideas? I thought
> about the code freeze require buy-in from three of four people (me, Alan,
> Dave and Andrew come to mind) for a patch to go in, but that's probably
> too draconian for now. Or is it (maybe start with "needs approval by two"
> and switch it to three when going into code freeze)?
>
It does sound a little bureacratic for this point in development.
The first thing we need is a set of widely-understood guidelines.
Such as:
Only
- bugfixes
- speedups
- previously-agreed-to or in-progress features
- totally new things (new drivers, new filesystems)
Once everyone understands this framework then it becomes easy to
decide what to drop, what not.
So right now, sysenter is "in". Later, even "speedups" falls off
the list and sysenter would at that stage be "out".
Can it be that simple?
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: Grant Grundler @ 2002-12-18 17:01 UTC (permalink / raw)
To: jsoe0708; +Cc: Ryan Bradetich, Ed Schaller, parisc-linux
In-Reply-To: <3DED9A6600002207@ocpmta3.freegates.net>
On Wed, Dec 18, 2002 at 07:30:40AM +0100, jsoe0708@tiscali.be wrote:
> In eeprom.c I also suspect:
> line 193: if (ee_data[27] == 0 || ee_data[ee_data[27]] == 0) {
...
> and it works. Unforunately I do not have enough doc to actulay fix the pb.
I don't either. I made that change after reviewing the code and just
botched it. My understanding is jgarzik is rewriting tulip driver anyway.
grant
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.