lkml.org 
[lkml]   [1998]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
SubjectRe:linux-kernel-digest V1 #2942
I am on leave from 7/12/98 till 9/12/98.  For urgent matters you may resend the mail to :

Soo Heng (AUDTQSH) on Network Security related matters
Jenny (AUDTJCG) on PC and LAN matters.

Thank you.

>>> "linux-kernel@vger.rutgers.edu" 12/05/98 09:54 >>>


linux-kernel-digest Friday, 4 December 1998 Volume 01 : Number 2942

In this issue:

Re: idle_task priority and scheduling 2.1.131
[2.1.13x] 2.1.13x + Gated OSPF = trubble.
TCP bad checksum
Re: Linux timekeeping plans
2.1.131 Kernel panic while booting
Re: IDE disk geometry + patch
MegaRAID patch with SMP
Re: NFS in 2.1.130??
Modular IPC, slightly revised
Re: Internationalizing Linux
Re: [PATCH] swapin readahead and fixes
RE: Y2k compliance
Re: Problem with 1G RAM
Re: [PATCH] swapin readahead and fixes
FW: NTFS partitions show up as OS/2 partitions.
Re: Dead Machine & 2.1.131
Re: NO ROM BASIC
Re: Problem with 1G RAM
Re: Internationalizing Linux
Sound Problem
Re: SWAP: Linux far behind Solaris or I missed something (fwd)
Re: NO ROM BASIC
Re: disks stats through /proc
"TCPv4 bad checksum" errors: a little more debugging
Re: st_blocks - was: Re: crazy swapping
Re: /dev/temperature
Re: Linux-2.1.131.. (VM Tuning)
SAR (was Re: disks stats through /proc)
Re: Y2k compliance

See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.

----------------------------------------------------------------------

From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 10:56:17 +0100 (CET)
Subject: Re: idle_task priority and scheduling 2.1.131

On Fri, 4 Dec 1998, Andrea Arcangeli wrote:
> On Thu, 3 Dec 1998, Rik van Riel wrote:
>
> >Move the != SCHED_OTHER test before the goodness test,
> >it will avoid clobbering p->policy, fouling up the
> >actual reschedule.

> - if (p->policy != SCHED_OTHER || p->counter > current->counter + 3)
> - current->need_resched = 1;
> + if (p->policy != SCHED_OTHER ||

Please change this to:
if (p->policy != SCHED_OTHER || current->policy != SCHED_OTHER ||

> + p->counter + p->priority > this->counter + this->priority + 3)
> + current->need_resched = 1;
> }

We really want to catch the case where current has set
SCHED_YIELD or has done something strange (idle process).

We can safely use this test because the number of tasks
where policy != SCHED_OTHER should be relatively small
so only testing this should be cheaper than an expensive
test followed by a (very rare) wasted schedule().

regards,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+


Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Alexandr D. Kanevskiy" <kad@dgtu.donetsk.ua>
Date: Fri, 4 Dec 1998 15:28:37 +0200 (EET)
Subject: [2.1.13x] 2.1.13x + Gated OSPF = trubble.

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

- --750966455-1467126216-912778117=:844
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all !


I don't know why, but gated with recent kernels does't work.
2.1.129 with some config = ok. 2.1.130 - not ok.

RH5.1,(glibc from RH5.2) gated from RH5.2 3.5.10(I also tryed 3.5.9)

With best regards,
Alexandr.
---------------------------------------------------------
InterNIC: AK2644 Email: kad@alchevsk.lugansk.ua
Groups: // MFUA // UCL // kad@dgtu.donetsk.ua
---------------------------------------------------------

- --750966455-1467126216-912778117=:844
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config"
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.3.96.981204152837.844B@r4.dgtu.donetsk.ua>
Content-Description:

#
# Automatically generated by make menuconfig: don't edit
#

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M686 is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OPTIMIZE=y
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_BINFMT_JAVA=m
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_OTHER=y
# CONFIG_APM is not set

#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_PARPORT=m

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_VIA82C586=y
# CONFIG_BLK_DEV_CMD646 is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_RAM=m
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE_PARPORT=m
# CONFIG_PARIDE is not set
# CONFIG_BLK_DEV_HD is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FIREWALL=y
CONFIG_NET_ALIAS=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
CONFIG_IP_ROUTE_NAT=y
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_NETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_IP_ALWAYS_DEFRAG=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_MASQUERADE_ICMP=y
CONFIG_IP_MASQUERADE_MOD=y
CONFIG_IP_MASQUERADE_IPAUTOFW=m
CONFIG_IP_MASQUERADE_IPPORTFW=m
CONFIG_IP_ROUTER=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
# CONFIG_NET_IPGRE_BROADCAST is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
CONFIG_IP_ALIAS=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_RARP=m
CONFIG_IP_NOSR=y
# CONFIG_SKB_LARGE is not set
CONFIG_IPV6=m
CONFIG_IPV6_EUI64=y
CONFIG_IPV6_NO_PB=y
CONFIG_IPX=m
CONFIG_IPX_INTERN=y
CONFIG_SPX=m
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_BRIDGE=y
# CONFIG_LLC 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
# CONFIG_CPU_IS_SLOW is not set
CONFIG_NET_SCHED=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
CONFIG_SCSI_PPA=m
# CONFIG_SCSI_PPA_HAVE_PEDANTIC is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_DEBUG is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
CONFIG_ETHERTAP=m
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
CONFIG_EL16=m
CONFIG_EL3=m
# CONFIG_3C515 is not set
# CONFIG_VORTEX is not set
CONFIG_LANCE=y
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
CONFIG_RTL8139=m
# CONFIG_YELLOWFIN is not set
# CONFIG_ACENIC is not set
CONFIG_NET_ISA=y
# CONFIG_AT1700 is not set
# CONFIG_E2100 is not set
# CONFIG_DEPCA is not set
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
# CONFIG_FMV18X is not set
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_HP100=m
# CONFIG_ETH16I is not set
CONFIG_NE2000=m
# CONFIG_SEEQ8005 is not set
# CONFIG_SK_G16 is not set
CONFIG_NET_EISA=y
CONFIG_PCNET32=m
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
CONFIG_DE4X5=m
CONFIG_DEC_ELCP=m
# CONFIG_DGRS is not set
CONFIG_EEXPRESS_PRO100=m
# CONFIG_LNE390 is not set
# CONFIG_NE3210 is not set
CONFIG_NE2K_PCI=m
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_ES3210 is not set
CONFIG_EPIC100=m
# CONFIG_ZNET is not set
# CONFIG_NET_POCKET is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_DLCI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_NET_RADIO is not set
# CONFIG_TR is not set
CONFIG_SHAPER=m
# CONFIG_HOSTESS_SV11 is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# CD-ROM drivers (not for SCSI or IDE/ATAPI drives)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_EXTENDED=y
CONFIG_SERIAL_MANY_PORTS=y
CONFIG_SERIAL_SHARE_IRQ=y
CONFIG_SERIAL_DETECT_IRQ=y
# CONFIG_SERIAL_MULTIPORT is not set
# CONFIG_HUB6 is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
CONFIG_PRINTER_READBACK=y
CONFIG_MOUSE=y
# CONFIG_ATIXL_BUSMOUSE is not set
# CONFIG_BUSMOUSE is not set
# CONFIG_MS_BUSMOUSE is not set
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_WATCHDOG is not set
CONFIG_RTC=y
CONFIG_VIDEO_DEV=m
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
CONFIG_RADIO_AZTECH=m
# CONFIG_RADIO_MIROPCM20 is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_ZOLTRIX is not set
# CONFIG_NVRAM is not set
# CONFIG_JOYSTICK is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set

#
# Filesystems
#
CONFIG_QUOTA=y
CONFIG_MINIX_FS=m
CONFIG_EXT2_FS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_PROC_FS=y
CONFIG_NFS_FS=m
CONFIG_NFSD=m
# CONFIG_NFSD_SUN is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
# CONFIG_CODA_FS is not set
CONFIG_SMB_FS=m
CONFIG_SMB_WIN95=y
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_MOUNT_SUBDIR=y
CONFIG_HPFS_FS=m
CONFIG_NTFS_FS=m
CONFIG_NTFS_RW=y
CONFIG_SYSV_FS=m
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_AUTOFS_FS=m
CONFIG_UFS_FS=m
CONFIG_BSD_DISKLABEL=y
CONFIG_SMD_DISKLABEL=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_DEVPTS_FS=y
# CONFIG_ADFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_NLS=y

#
# Native Language Support
#
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
CONFIG_NLS_CODEPAGE_866=m
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_ISO8859_9 is not set
CONFIG_NLS_KOI8_R=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_ATY is not set
CONFIG_FB_VIRTUAL=m
CONFIG_FBCON_ADVANCED=y
CONFIG_FBCON_MFB=m
CONFIG_FBCON_CFB2=m
CONFIG_FBCON_CFB4=m
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=m
CONFIG_FBCON_CFB32=m
# CONFIG_FBCON_AFB is not set
# CONFIG_FBCON_ILBM is not set
# CONFIG_FBCON_IPLAN2P2 is not set
# CONFIG_FBCON_IPLAN2P4 is not set
# CONFIG_FBCON_IPLAN2P8 is not set
CONFIG_FBCON_MAC=m
CONFIG_FBCON_VGA=m
# CONFIG_FBCON_FONTWIDTH8_ONLY is not set
# CONFIG_FBCON_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Sound
#
CONFIG_SOUND=m
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
CONFIG_SOUND_OSS=m
# CONFIG_SOUND_PAS is not set
CONFIG_SOUND_SB=m
CONFIG_SOUND_ADLIB=m
# CONFIG_SOUND_GUS is not set
CONFIG_SOUND_MPU401=m
# CONFIG_SOUND_PSS is not set
CONFIG_SOUND_MSS=m
CONFIG_SOUND_SSCAPE=m
# CONFIG_SOUND_TRIX is not set
CONFIG_SOUND_MAD16=m
CONFIG_MAD16_OLDCARD=y
# CONFIG_SOUND_WAVEFRONT is not set
CONFIG_SOUND_CS4232=m
# CONFIG_SOUND_OPL3SA2 is not set
# CONFIG_SOUND_MAUI is not set
# CONFIG_SOUND_SGALAXY is not set
CONFIG_SOUND_OPL3SA1=m
CONFIG_SOUND_SOFTOSS=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_VMIDI=m
CONFIG_SOUND_UART6850=m

#
# Additional low level sound drivers
#
CONFIG_LOWLEVEL_SOUND=y
# CONFIG_ACI_MIXER is not set
CONFIG_AWE32_SYNTH=m
# CONFIG_AEDSP16 is not set

#
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=y

- --750966455-1467126216-912778117=:844--

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Lenart Gabor <lgb@hal2000.hal.vein.hu>
Date: Fri, 4 Dec 1998 14:39:54 +0100
Subject: TCP bad checksum

Dec 3 19:11:35 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:04d3, len=20/20/40
Dec 3 19:12:03 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:04fc, len=20/20/40
Dec 3 19:12:26 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:050d, len=20/20/40
Dec 3 19:13:13 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:050e, len=20/20/40
Dec 3 19:14:03 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:04fc, len=20/20/40
Dec 3 19:14:26 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:050d, len=20/20/40
Dec 3 19:15:13 oxygene kernel: TCPv4 bad checksum from 192.225.44.214:0050 to 193.6.41.138:050e, len=20/20/40
Dec 4 14:19:27 oxygene kernel: Socket destroy delayed (r=0 w=128)

What do hex numbers after target IP address mean ? And what do these messages
mean exactly ? (So what did 192.225.44.214 with my machine, or is it somewhat
kernelbug ?)
(2.1.131UP)

thx

- ---[ LGB/DC ]------------------[ root@hal2000 ]-----------------[ LINUX ]---
"The truth is out there" "We're living together" "The future is dark."
- ---[ 88/422022-4602 ]--[ http://www.hal.vein.hu/~lgb ]------[ 87/477074 ]---

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Richard B. Johnson" <root@chaos.analogic.com>
Date: Fri, 4 Dec 1998 08:41:31 -0500 (EST)
Subject: Re: Linux timekeeping plans

On Thu, 3 Dec 1998, Brandon S. Allbery KF8NH wrote:
>
> PC RTCs are horrible. For all that it lost up to 15 seconds a day, my
> 486DX2/66 kept better time in Linux (or OS/2, etc.) than its RTC did. My
> P200 dosesn't appear to be much better.
>

Here is a log of my Linux file-server's time referenced to NIST at
one-hour intervals.

Script started on Thu Dec 3 11:30:48 1998
# while gettime time-a.timefreq.bldrdoc.gov ; do sleep 3600 ; done

Reference time = Thu Dec 3 11:31:37 1998
My time = Thu Dec 3 11:31:37 1998
Difference = 0
Reference time = Thu Dec 3 12:31:38 1998
My time = Thu Dec 3 12:31:38 1998
Difference = 0
Reference time = Thu Dec 3 13:31:38 1998
My time = Thu Dec 3 13:31:38 1998
Difference = 0
Reference time = Thu Dec 3 14:31:38 1998
My time = Thu Dec 3 14:31:38 1998
Difference = 0
Reference time = Thu Dec 3 15:31:38 1998
My time = Thu Dec 3 15:31:38 1998
Difference = 0
Reference time = Thu Dec 3 16:31:37 1998
My time = Thu Dec 3 16:31:37 1998
Difference = 0
Reference time = Thu Dec 3 17:31:37 1998
My time = Thu Dec 3 17:31:37 1998
Difference = 0
Reference time = Thu Dec 3 18:31:37 1998
My time = Thu Dec 3 18:31:37 1998
Difference = 0
Reference time = Thu Dec 3 19:31:37 1998
My time = Thu Dec 3 19:31:37 1998
Difference = 0
Reference time = Thu Dec 3 20:31:36 1998
My time = Thu Dec 3 20:31:33 1998
Difference = -3 seconds
Reference time = Thu Dec 3 21:31:36 1998
My time = Thu Dec 3 21:31:33 1998
Difference = -3 seconds
Reference time = Thu Dec 3 22:31:35 1998
My time = Thu Dec 3 22:31:34 1998
Difference = -1 seconds
gettime connect(): Connection timed out
# exit
exit

Script done on Fri Dec 4 08:24:22 1998

You can see that the time was quite stable until 20:31:36 where it
took a jump of a few seconds, then by 22:31:35 it had gotten close
to the original.

I find that most all PCs are quite stable, but do suffer a long-term
drift, mostly because of the unidirectional jog shown above. If the
time would slowly vary about a mean value, the adjtime mechanism would
on, the average, keep the time quite close to NIST.

Instead, I fix by resetting the time to NIST once each morning using
a crond script.

Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.128 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Radim Literak <literakr@alpha.inf.upol.cz>
Date: Fri, 4 Dec 1998 14:42:44 +0100 (MET)
Subject: 2.1.131 Kernel panic while booting

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

- ---1029770296-1850802630-912777522=:179
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.OSF.4.05.9812041417582.1143@alpha.inf.upol.cz>

Hello,

I still have the same problem with experimental kernels. When I
booting, folowing errors occures:


Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdb: hdb1 hdb2 < hdb5 hdb6 >
EXT2-fs error (device 03:01): ext2_check_descriptors: Block bitmap for
group 27 not in group (block 0)!
EXT2-fs: group descriptors corrupted!
Kernel panic: VFS: Unable to mount root fs on 03:01


Another interesting thing is that sometimes partition check froze and
computer doesn't work (only HDD LED on my case is lighting). And when is
not frozen, then there is error described upper, but every time is here
different number in this error, like

group 27
group 19
group 23
group 40
group 17

etc. But 2.0.36 is going correctly.

Maybe is important physical description of partitions on my HDD,
because partitions are not normaly sorted:

hda3 hda1 hda4 <hda5 hda6> hda2


hda3.............FAT16 (first on hda)
hda1.............EXT2 (after hda3)
hda4.............DOS EXTENDED (after hda1)
hda5...........NTFS (first on hda4)
hda6...........NTFS (second on hda4)
hda2.............LINUX SWAP (after hda4)


I attach my configuration file, too.

Thank you for help me.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Radim Literak, Olomouc, Czech Republic
Student of Palacky University at Computer Science Department

http://www.inf.upol.cz/~literakr

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- ---1029770296-1850802630-912777522=:179
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=".config"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.OSF.4.05.9812041442440.1143@alpha.inf.upol.cz>
Content-Description: Configuration file
Content-Disposition: attachment; filename=".config"

Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m
aWc6IGRvbid0IGVkaXQNCiMNCg0KIw0KIyBDb2RlIG1hdHVyaXR5IGxldmVs
IG9wdGlvbnMNCiMNCiMgQ09ORklHX0VYUEVSSU1FTlRBTCBpcyBub3Qgc2V0
DQoNCiMNCiMgUHJvY2Vzc29yIHR5cGUgYW5kIGZlYXR1cmVzDQojDQojIENP
TkZJR19NMzg2IGlzIG5vdCBzZXQNCiMgQ09ORklHX000ODYgaXMgbm90IHNl
dA0KQ09ORklHX001ODY9eQ0KIyBDT05GSUdfTTY4NiBpcyBub3Qgc2V0DQoj
IENPTkZJR19NQVRIX0VNVUxBVElPTiBpcyBub3Qgc2V0DQoNCiMNCiMgTG9h
ZGFibGUgbW9kdWxlIHN1cHBvcnQNCiMNCkNPTkZJR19NT0RVTEVTPXkNCkNP
TkZJR19NT0RWRVJTSU9OUz15DQpDT05GSUdfS01PRD15DQoNCiMNCiMgR2Vu
ZXJhbCBzZXR1cA0KIw0KQ09ORklHX05FVD15DQpDT05GSUdfUENJPXkNCiMg
Q09ORklHX1BDSV9CSU9TIGlzIG5vdCBzZXQNCkNPTkZJR19QQ0lfRElSRUNU
PXkNCiMgQ09ORklHX1BDSV9RVUlSS1MgaXMgbm90IHNldA0KQ09ORklHX1BD
SV9PTERfUFJPQz15DQojIENPTkZJR19NQ0EgaXMgbm90IHNldA0KQ09ORklH
X1NZU1ZJUEM9eQ0KIyBDT05GSUdfQlNEX1BST0NFU1NfQUNDVCBpcyBub3Qg
c2V0DQpDT05GSUdfU1lTQ1RMPXkNCkNPTkZJR19CSU5GTVRfQU9VVD1tDQpD
T05GSUdfQklORk1UX0VMRj15DQpDT05GSUdfQklORk1UX01JU0M9eQ0KIyBD
T05GSUdfUEFSUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19BUE0gaXMgbm90
IHNldA0KDQojDQojIFBsdWcgYW5kIFBsYXkgc3VwcG9ydA0KIw0KIyBDT05G
SUdfUE5QIGlzIG5vdCBzZXQNCg0KIw0KIyBCbG9jayBkZXZpY2VzDQojDQpD
T05GSUdfQkxLX0RFVl9GRD1tDQpDT05GSUdfQkxLX0RFVl9JREU9eQ0KIyBD
T05GSUdfQkxLX0RFVl9IRF9JREUgaXMgbm90IHNldA0KQ09ORklHX0JMS19E
RVZfSURFRElTSz15DQpDT05GSUdfQkxLX0RFVl9JREVDRD1tDQojIENPTkZJ
R19CTEtfREVWX0lERVRBUEUgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RF
Vl9JREVGTE9QUFkgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVT
Q1NJIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ01ENjQwIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUloxMDAwIGlzIG5vdCBzZXQNCkNP
TkZJR19CTEtfREVWX0lERVBDST15DQpDT05GSUdfQkxLX0RFVl9JREVETUE9
eQ0KIyBDT05GSUdfQkxLX0RFVl9PRkZCT0FSRCBpcyBub3Qgc2V0DQpDT05G
SUdfSURFRE1BX0FVVE89eQ0KIyBDT05GSUdfSURFX0NISVBTRVRTIGlzIG5v
dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfTE9PUCBpcyBub3Qgc2V0DQojIENP
TkZJR19CTEtfREVWX05CRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW
X01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfUkFNIGlzIG5vdCBz
ZXQNCiMgQ09ORklHX0JMS19ERVZfWEQgaXMgbm90IHNldA0KQ09ORklHX1BB
UklERV9QQVJQT1JUPXkNCiMgQ09ORklHX1BBUklERSBpcyBub3Qgc2V0DQoj
IENPTkZJR19CTEtfREVWX0hEIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3b3Jr
aW5nIG9wdGlvbnMNCiMNCkNPTkZJR19QQUNLRVQ9bQ0KIyBDT05GSUdfTkVU
TElOSyBpcyBub3Qgc2V0DQojIENPTkZJR19GSVJFV0FMTCBpcyBub3Qgc2V0
DQojIENPTkZJR19ORVRfQUxJQVMgaXMgbm90IHNldA0KIyBDT05GSUdfRklM
VEVSIGlzIG5vdCBzZXQNCkNPTkZJR19VTklYPW0NCkNPTkZJR19JTkVUPXkN
CiMgQ09ORklHX0lQX01VTFRJQ0FTVCBpcyBub3Qgc2V0DQojIENPTkZJR19J
UF9BRFZBTkNFRF9ST1VURVIgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfUE5Q
IGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQX1JPVVRFUiBpcyBub3Qgc2V0DQoj
IENPTkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfSVBH
UkUgaXMgbm90IHNldA0KIyBDT05GSUdfSVBfQUxJQVMgaXMgbm90IHNldA0K
IyBDT05GSUdfU1lOX0NPT0tJRVMgaXMgbm90IHNldA0KIyBDT05GSUdfSU5F
VF9SQVJQIGlzIG5vdCBzZXQNCkNPTkZJR19JUF9OT1NSPXkNCkNPTkZJR19T
S0JfTEFSR0U9eQ0KQ09ORklHX0lQWD1tDQpDT05GSUdfSVBYX0lOVEVSTj15
DQojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0DQoNCiMNCiMgU0NTSSBzdXBw
b3J0DQojDQojIENPTkZJR19TQ1NJIGlzIG5vdCBzZXQNCg0KIw0KIyBOZXR3
b3JrIGRldmljZSBzdXBwb3J0DQojDQpDT05GSUdfTkVUREVWSUNFUz15DQoj
IENPTkZJR19BUkNORVQgaXMgbm90IHNldA0KQ09ORklHX0RVTU1ZPW0NCiMg
Q09ORklHX0VRVUFMSVpFUiBpcyBub3Qgc2V0DQpDT05GSUdfTkVUX0VUSEVS
TkVUPXkNCiMgQ09ORklHX05FVF9WRU5ET1JfM0NPTSBpcyBub3Qgc2V0DQoj
IENPTkZJR19MQU5DRSBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9S
X1NNQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfVkVORE9SX1JBQ0FMIGlz
IG5vdCBzZXQNCiMgQ09ORklHX05FVF9JU0EgaXMgbm90IHNldA0KQ09ORklH
X05FVF9FSVNBPXkNCiMgQ09ORklHX1BDTkVUMzIgaXMgbm90IHNldA0KIyBD
T05GSUdfQVBSSUNPVCBpcyBub3Qgc2V0DQojIENPTkZJR19DUzg5eDAgaXMg
bm90IHNldA0KIyBDT05GSUdfREU0WDUgaXMgbm90IHNldA0KIyBDT05GSUdf
REVDX0VMQ1AgaXMgbm90IHNldA0KIyBDT05GSUdfREdSUyBpcyBub3Qgc2V0
DQojIENPTkZJR19FRVhQUkVTU19QUk8xMDAgaXMgbm90IHNldA0KQ09ORklH
X05FMktfUENJPW0NCiMgQ09ORklHX1RMQU4gaXMgbm90IHNldA0KIyBDT05G
SUdfVklBX1JISU5FIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9QT0NLRVQg
aXMgbm90IHNldA0KIyBDT05GSUdfRkRESSBpcyBub3Qgc2V0DQojIENPTkZJ
R19ETENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0DQoj
IENPTkZJR19TTElQIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9SQURJTyBp
cyBub3Qgc2V0DQojIENPTkZJR19UUiBpcyBub3Qgc2V0DQojIENPTkZJR19I
T1NURVNTX1NWMTEgaXMgbm90IHNldA0KIyBDT05GSUdfV0FOX0RSSVZFUlMg
aXMgbm90IHNldA0KIyBDT05GSUdfTEFQQkVUSEVSIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1gyNV9BU1kgaXMgbm90IHNldA0KDQojDQojIEFtYXRldXIgUmFk
aW8gc3VwcG9ydA0KIw0KIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNldA0K
DQojDQojIElTRE4gc3Vic3lzdGVtDQojDQojIENPTkZJR19JU0ROIGlzIG5v
dCBzZXQNCg0KIw0KIyBDRC1ST00gZHJpdmVycyAobm90IGZvciBTQ1NJIG9y
IElERS9BVEFQSSBkcml2ZXMpDQojDQojIENPTkZJR19DRF9OT19JREVTQ1NJ
IGlzIG5vdCBzZXQNCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09O
RklHX1ZUPXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19TRVJJQUw9
eQ0KIyBDT05GSUdfU0VSSUFMX0NPTlNPTEUgaXMgbm90IHNldA0KIyBDT05G
SUdfU0VSSUFMX0VYVEVOREVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklB
TF9OT05TVEFOREFSRCBpcyBub3Qgc2V0DQojIENPTkZJR19VTklYOThfUFRZ
UyBpcyBub3Qgc2V0DQojIENPTkZJR19NT1VTRSBpcyBub3Qgc2V0DQojIENP
TkZJR19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1dBVENIRE9H
IGlzIG5vdCBzZXQNCiMgQ09ORklHX1JUQyBpcyBub3Qgc2V0DQojIENPTkZJ
R19WSURFT19ERVYgaXMgbm90IHNldA0KIyBDT05GSUdfTlZSQU0gaXMgbm90
IHNldA0KIyBDT05GSUdfSk9ZU1RJQ0sgaXMgbm90IHNldA0KDQojDQojIEZ0
YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRyaXZlcg0KIw0KIyBDT05G
SUdfRlRBUEUgaXMgbm90IHNldA0KDQojDQojIEZpbGVzeXN0ZW1zDQojDQpD
T05GSUdfUVVPVEE9eQ0KIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNldA0K
Q09ORklHX0VYVDJfRlM9eQ0KQ09ORklHX0lTTzk2NjBfRlM9bQ0KQ09ORklH
X0pPTElFVD15DQpDT05GSUdfRkFUX0ZTPW0NCkNPTkZJR19NU0RPU19GUz1t
DQpDT05GSUdfVU1TRE9TX0ZTPW0NCkNPTkZJR19WRkFUX0ZTPW0NCkNPTkZJ
R19QUk9DX0ZTPXkNCkNPTkZJR19ORlNfRlM9bQ0KQ09ORklHX05GU0Q9bQ0K
IyBDT05GSUdfTkZTRF9TVU4gaXMgbm90IHNldA0KQ09ORklHX1NVTlJQQz1t
DQpDT05GSUdfTE9DS0Q9bQ0KIyBDT05GSUdfQ09EQV9GUyBpcyBub3Qgc2V0
DQpDT05GSUdfU01CX0ZTPW0NCkNPTkZJR19TTUJfV0lOOTU9eQ0KQ09ORklH
X05DUF9GUz1tDQpDT05GSUdfTkNQRlNfUEFDS0VUX1NJR05JTkc9eQ0KQ09O
RklHX05DUEZTX0lPQ1RMX0xPQ0tJTkc9eQ0KQ09ORklHX05DUEZTX1NUUk9O
Rz15DQpDT05GSUdfTkNQRlNfTkZTX05TPXkNCkNPTkZJR19OQ1BGU19PUzJf
TlM9eQ0KQ09ORklHX05DUEZTX01PVU5UX1NVQkRJUj15DQpDT05GSUdfSFBG
U19GUz1tDQpDT05GSUdfTlRGU19GUz1tDQojIENPTkZJR19TWVNWX0ZTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldA0KIyBDT05G
SUdfSEZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JPTUZTX0ZTIGlzIG5v
dCBzZXQNCkNPTkZJR19BVVRPRlNfRlM9eQ0KIyBDT05GSUdfVUZTX0ZTIGlz
IG5vdCBzZXQNCiMgQ09ORklHX0JTRF9ESVNLTEFCRUwgaXMgbm90IHNldA0K
IyBDT05GSUdfU01EX0RJU0tMQUJFTCBpcyBub3Qgc2V0DQojIENPTkZJR19T
T0xBUklTX1g4Nl9QQVJUSVRJT04gaXMgbm90IHNldA0KIyBDT05GSUdfTUFD
X1BBUlRJVElPTiBpcyBub3Qgc2V0DQpDT05GSUdfTkxTPXkNCg0KIw0KIyBO
YXRpdmUgTGFuZ3VhZ2UgU3VwcG9ydA0KIw0KQ09ORklHX05MU19DT0RFUEFH
RV80Mzc9bQ0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBub3Qgc2V0
DQojIENPTkZJR19OTFNfQ09ERVBBR0VfNzc1IGlzIG5vdCBzZXQNCiMgQ09O
RklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldA0KQ09ORklHX05MU19D
T0RFUEFHRV84NTI9bQ0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NSBpcyBu
b3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU3IGlzIG5vdCBzZXQN
CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNldA0KIyBDT05G
SUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNf
Q09ERVBBR0VfODYyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFH
RV84NjMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NCBp
cyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY1IGlzIG5vdCBz
ZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90IHNldA0KIyBD
T05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0DQojIENPTkZJR19O
TFNfQ09ERVBBR0VfODc0IGlzIG5vdCBzZXQNCkNPTkZJR19OTFNfSVNPODg1
OV8xPW0NCkNPTkZJR19OTFNfSVNPODg1OV8yPW0NCiMgQ09ORklHX05MU19J
U084ODU5XzMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfNCBp
cyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQN
CiMgQ09ORklHX05MU19JU084ODU5XzYgaXMgbm90IHNldA0KIyBDT05GSUdf
TkxTX0lTTzg4NTlfNyBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1
OV84IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90
IHNldA0KIyBDT05GSUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0DQoNCiMNCiMg
Q29uc29sZSBkcml2ZXJzDQojDQpDT05GSUdfVkdBX0NPTlNPTEU9eQ0KQ09O
RklHX1ZJREVPX1NFTEVDVD15DQoNCiMNCiMgU291bmQNCiMNCkNPTkZJR19T
T1VORD1tDQojIENPTkZJR19TT1VORF9NU05EQ0xBUyBpcyBub3Qgc2V0DQoj
IENPTkZJR19TT1VORF9NU05EUElOIGlzIG5vdCBzZXQNCkNPTkZJR19TT1VO
RF9PU1M9bQ0KIyBDT05GSUdfU09VTkRfUEFTIGlzIG5vdCBzZXQNCkNPTkZJ
R19TT1VORF9TQj1tDQojIENPTkZJR19TT1VORF9BRExJQiBpcyBub3Qgc2V0
DQojIENPTkZJR19TT1VORF9HVVMgaXMgbm90IHNldA0KIyBDT05GSUdfU09V
TkRfTVBVNDAxIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1BTUyBpcyBu
b3Qgc2V0DQojIENPTkZJR19TT1VORF9NU1MgaXMgbm90IHNldA0KIyBDT05G
SUdfU09VTkRfU1NDQVBFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1RS
SVggaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTUFEMTYgaXMgbm90IHNl
dA0KIyBDT05GSUdfU09VTkRfV0FWRUZST05UIGlzIG5vdCBzZXQNCiMgQ09O
RklHX1NPVU5EX0NTNDIzMiBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9P
UEwzU0EyIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX01BVUkgaXMgbm90
IHNldA0KIyBDT05GSUdfU09VTkRfU0dBTEFYWSBpcyBub3Qgc2V0DQojIENP
TkZJR19TT1VORF9PUEwzU0ExIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5E
X1NPRlRPU1MgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfWU0zODEyIGlz
IG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1ZNSURJIGlzIG5vdCBzZXQNCiMg
Q09ORklHX1NPVU5EX1VBUlQ2ODUwIGlzIG5vdCBzZXQNCg0KIw0KIyBBZGRp
dGlvbmFsIGxvdyBsZXZlbCBzb3VuZCBkcml2ZXJzDQojDQojIENPTkZJR19M
T1dMRVZFTF9TT1VORCBpcyBub3Qgc2V0DQoNCiMNCiMgS2VybmVsIGhhY2tp
bmcNCiMNCiMgQ09ORklHX01BR0lDX1NZU1JRIGlzIG5vdCBzZXQNCg==
- ---1029770296-1850802630-912777522=:179--

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Peter T. Breuer" <ptb@it.uc3m.es>
Date: Fri, 4 Dec 1998 14:42:39 +0100 (MET)
Subject: Re: IDE disk geometry + patch

I saw this recently on new fujitsus. Reported 1023,255,63 after selecting LBA.
Result complete muddle until I realized that _smart IDE disk_ (or somesuch)
had been enabled in the bios. Turned it off and all OK.

But LBA has _always_ been the preferred access mode for linux. Are you saying
that it is not? Please explain!


Peter



"A month of sundays ago Andries.Brouwer@cwi.nl wrote:"
>
> People complain that the kernel reports
> hda: IB<-DTTA-351680, 16124MB w/462kB Cache, CHS=1024/255/63, UDMA
> for their large IDE disks.
> But 1024*255*63*512=8422686720, so the reported C/H/S describes
> only half of the disk.
>
> Conjectured sequence of events: the disk reports 16383,16,63;
> these numbers would have been recognized by the kernel,
> but unfortunately the user selected LBA, and the BIOS
> turned this geometry into 1024,255,63 which the kernel
> no longer recognizes. Now the fragment of ide.c:do_identify()
> in 2.0.36 or ide-disk.c:idedisk_setup() in 2.1.130
>
> /* Correct the number of cyls if the bios value is too small */
> if (drive->sect == drive->bios_sect && drive->head == drive->bios_head) {
> if (drive->cyl > drive->bios_cyl)
> drive->bios_cyl = drive->cyl;
> }
>
> does not update drive->bios_cyl since drive->head != drive->bios_head.
> So, I propose that the above fragment be changed into something like
>
> /* Set the cylinder count - the BIOS reported value may be too small */
> if (drive->bios_sect && drive->bios_head)
> drive->bios_cyl = capacity / (drive->bios_sect * drive->bios_head);
>
> where `capacity' is current_capacity(drive) in the 2.0.36 source,
> and idedisk_capacity(drive) in the 2.1.130 source.
>
> Andries
>
>
> -
>


Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Pavel.Janik@inet.cz (Pavel Janik ml.)
Date: 04 Dec 1998 15:05:41 +0100
Subject: MegaRAID patch with SMP

Hi,

we are running SMP with 4 penguins and have problems with
MegaRAID/2.1.13x (all 2.1.x exactly). MegaRAID patch comes from
ftp://ami.com/MegaRaid/Drivers/linux. Version for 2.1.131 is on
ftp://ftp.inet.cz/pub/People/Pavel.Janik/MegaRAID/

When running on 2.0.29 (latest versions are "SMP updated", so no go
for our configuration) no problems arrive (cd /usr/src/linux; make -j
5 bzImage is OK, -j 50 too ;-). 2.1.130 is bad - it stays about 30s of
compilation, then locks, no messages in log file. Some messages on the
console, but we did not write them down, but it is repoducible.

In the patch is something like:

+ * With SMP enabled under 2.1.118 with more than one processor, gets an
+ * error message "scsi_end_request: buffer-list destroyed" under heavy
+ * IO, but doesn't seem to affect operation, or data integrity. The
+ * message doesn't occur without SMP enabled, or with one proccessor with
+ * SMP enabled, or under any combination under 2.0 kernels.

It did the same for us. Any suggestion?
- --
Pavel Janik ml.
Pavel.Janik@inet.cz

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Date: Fri, 4 Dec 1998 02:34:53 +0000
Subject: Re: NFS in 2.1.130??

On Wed, Dec 02, 1998 at 09:48:12AM -0800, Joel Klecker wrote:
> That's not true, we do have a mail locking standard: dotlocking.
> (http://www.debian.org/doc/debian-policy/ch5.html#s5.5)

Even with _all_ MUAs and MTAs using dot-locking, I still expect to see
lost mail over NFS. It's a cache synchronisation problem, not a locking
problem.

Debian's policy of just dot-locking appears broken to me, whereas an
fcntl()-everywhere policy (perhaps with dot-locking as well for
compatibility with NFS servers running other OSes) would be ok. With
the recent NFS changes, that is.

Please prove me wrong.

Awaiting correction,
- -- Jamie

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Zack Weinberg <zack@rabi.columbia.edu>
Date: Fri, 04 Dec 1998 09:13:34 -0500
Subject: Modular IPC, slightly revised

I've fixed one bug in my modular IPC patch and updated it to 2.1.131-ac2.
The bug is a potential race between module deletion and the IPC syscalls.
If you don't want to grab -ac2, the fix is appended (it's very short).

The full patch may be found at
ftp://rabi.phys.columbia.edu/pub/zack/modipc-2.1.131-ac2.diff.gz.

As before, any comments, bug reports, etc. are greatly appreciated. Thank
you to all the people who sent feedback on the last version.

zw

- --- ipc/util.c Wed Dec 2 00:59:46 1998
+++ ipc/util.c.new Fri Dec 4 09:01:25 1998
@@ -79,11 +79,11 @@

void cleanup_module(void)
{
+ ipc_jumps = NULL;
+
sem_cleanup();
msg_cleanup();
shm_cleanup();
- -
- - ipc_jumps = NULL;
}
#endif

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 14:51:25 +0100 (CET)
Subject: Re: Internationalizing Linux

On Fri, 4 Dec 1998, Drago Goricanec wrote:
> On 03 Dec 1998 16:25:16 +0100, Jes Sorensen writes:
> > Oh and how to you expect kernel hackers to be able to help debug a
> > problem when someone posts dmesg output in Chinese to linux-kernel?
>
> So is that why the old IBM mainframes tagged every system message with
> a unique identifier?
>
> > We've had this discussion before, about a year ago I think, forget it
> > once and for all, please.
>
> I think having messages appear in the sysadmin's native language has
> merit. The front line for Linux support is moving away from this
> list.
>
> Once messages permeate back to this list, they can be converted back
> to English just as the original message was converted originally to
> the native language.

We could use a PERL script for that... It makes more and more
sense the more I think about it. We could all be reading and
posting error messages in our own language (as long as the
identifier is kept intact).

The only problem is with the assignment of the identifiers to
the more experimental patch series and with keeping the
translation scripts up-to-date (auto-distribute the database?).

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 15:02:56 +0100 (CET)
Subject: Re: [PATCH] swapin readahead and fixes

On Fri, 4 Dec 1998, Stephen C. Tweedie wrote:
> On Thu, 3 Dec 1998 18:56:34 +0100 (CET), Rik van Riel
> <H.H.vanRiel@phys.uu.nl> said:
>
> > The swapin enhancement consists of a simple swapin readahead.
>
> One odd thing about the readahead: you don't start the readahead until
> _after_ you have synchronously read in the first swap page of the
> cluster. Surely it is better to do the readahead first, so that you
> are submitting one IO to disk, not two?

This would severely suck when something else would be doing
a run_taskqueue(&tq_disk). It would mean that we'd read
n+1..n+15 before n itself.

OTOH, if the disk is lightly loaded it would be an advantage.
I will try it shortly (but don't know how to measure the
results :)...

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Myreen Johan <Johan.Myreen@setec.fi>
Date: Fri, 4 Dec 1998 16:13:26 +0200
Subject: RE: Y2k compliance

>So how does it cope with 2000 being a leep year?

I don't understand the fuzz about year 2000 being
a leap year. The simplistic formula for finding
out if a year is a leap year is to check if it is
divisible by four. That formula is valid from the
year 1901 until the year 2100. We're talking sbout
lazy programmers not being able to see even 5-10
years into the future. The "Year 2000 is a Leap
Year" problem is kind of the Y2K problem inversed.

Do do you really expect to find programs out there
written by programmers informed enough to take
into account that years divisible by 100 are not
leap years, but *at* *the* *same* *time* don't
know that years divisible by 400 are leap years
after all?

Has anybody ever bumped into this problem in real
life? I suspect this "problem" is just the product
of the Y2K consultants' imagination.

Johan Myréen
jem@iki.fi


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 14:11:53 +0100 (CET)
Subject: Re: Problem with 1G RAM

On Thu, 3 Dec 1998, Bob McElrath wrote:
> On Thu, 3 Dec 1998, Tigran Aivazian wrote:
>
> > It should work fine as long as you have carefully studied the kernel header
> > asm-i386/page.h and made the modifications to it and arch/i386/vmlinux.lds
> > accordingly.
> >
> > By default the kernel will not work with that much memory.
>
> Will the kernel work with that much memory on the alpha platform or sparc64?

Of course, no problem. Alpha and UltraSPARC are 64 bit platforms
so a measly 1 GB shouldn't be any problem whatsoever :)

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Stephen C. Tweedie" <sct@redhat.com>
Date: Fri, 4 Dec 1998 14:34:01 GMT
Subject: Re: [PATCH] swapin readahead and fixes

Hi,

On Fri, 4 Dec 1998 15:02:56 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

>> One odd thing about the readahead: you don't start the readahead until
>> _after_ you have synchronously read in the first swap page of the
>> cluster. Surely it is better to do the readahead first, so that you
>> are submitting one IO to disk, not two?

> This would severely suck when something else would be doing
> a run_taskqueue(&tq_disk). It would mean that we'd read
> n+1..n+15 before n itself.

No, not at all. This is already the way we do all readahead
everywhere in the kernel.

The idea is to do readahead for all the data you want, *including* the
bit you are going to need right away. Once that is done, you just
wait for the IO to complete on that first item. In this case, that
means doing a readahead on pages n to n+15 inclusive, and then after
that doing the synchronous read_swap_page on page n. The kernel will
happily find that page in the swap cache, work out that IO is already
in progress and wait for that page to become available.

Even though the buffer IO request layer issues the entire sequential
IO as one IO to the device drivers, the buffers and pages involved in
the data transfer still get unlocked one by one as the IO completes.
After submitting the initial IO you can wait for that first page to
become unlocked without having to wait for the rest of the readahead
IO to finish.

- --Stephen

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Jesper Juhl <jesper.juhl@dif.dk>
Date: Fri, 4 Dec 1998 15:33:33 +0100
Subject: FW: NTFS partitions show up as OS/2 partitions.

I assumed that most people were aware of the fact that NT and OS/2 2.x
and
later are both (somewhat loosely, in NT's case) derived from their
common
proto-OS/2-2.0 codebase after Microsoft and IBM went their separate
ways.
Each one proceeded to mutate the proto-OS/2-2.0 into their idea of what
OS/2
"should be".

- - Yes, but the fact that they share the same magic number for their
partitions was not obvious (to me at least). That's a thing that some
(I) assumed they would have changed.
It was a stupid question, and linux-kernel was not the right place to
ask it. I appologize for this "mis-use" of linux-kernel (could we end
this thread now? ;)

/Jesper Juhl

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Dec 1998 15:36:39 +0000 (GMT)
Subject: Re: Dead Machine & 2.1.131
> MOST certainly xfstt killing my machine. First it would cause random X lockups
> after usage, then it would kill my machine when xdm tried to startup my
> session. Removing the xfstt related lines from .xsession/.xinitrc solved the
> problem totally.

Thats most likely an Xserver side bug if it brought the machine down

> It was still quite nasty... I'm disappointed that a user-space program
> interacting closely with X was able to bring my machine down.

Can you try the following

start xfstt
on another machine set the remote xfstt into your font paths
start X on this machine without xfstt

See which if any dies


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Konstantyn Prokopenko <kproko@analogic.com>
Date: Fri, 4 Dec 1998 09:40:54 -0500 (EST)
Subject: Re: NO ROM BASIC

On Thu, 3 Dec 1998 doctor@fruitbat.org wrote:

> > Hi!
> >
> > I'm new in Linux and I've got a problem compiling a kernel.
> > I have dual PENTIUM II motherboard with 128 Mb memory runing Red Hat
> > Linux. I compiled the 2.1.128 Linux kernel using:
>
> Did you enable the SMP option?

No.

> > make config
> > make dep
> > make bzImage
> > make install
> >
> > Then I rebooted. When it starts, it goes to 40 column mode and
> > says "NO ROM BASIC"
>
> Pardon me, but it sounds like you just booted an Atari 400 (or maybe a
> VIC 20, or possibly a Commodore PET ;-).
>
> Seriously, this almost sounds like a virus has infected your boot block.
> Can you boot off of floppy? Are you using LILO? Do you have more than
> one OS on your system?

Yes. I can boot off of floppy and I'm using LILO. I have Linux and M$DOS
partitions on a different SCSI hard drives. Probably I've got a problem
with LILO.

> > Sincerely,
> > K.V.P
>
> --
> Peter A. Castro (doctor@fruitbat.org) or (pcastro@us.oracle.com)
>

Thanks.

Sincerely,

K.V.P


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Pavel.Janik@inet.cz (Pavel Janik ml.)
Date: 04 Dec 1998 15:45:38 +0100
Subject: Re: Problem with 1G RAM

From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Thu, 3 Dec 1998 13:19:03 +0100 (CET)

Hi,

> To do that you need to change __PAGE_OFFSET in
> include/asm-i386/page.h and arch/i386/vmlinux.lds.
>
> All you need to know to succesfully do this operation
> is in a big fat comment in page.h.
Do you really think that this pseudo-patch

- --- linux/arch/i386/vmlinux.lds
+++ linux-/arch/i386/vmlinux.lds
@@ -6,7 +6,7 @@
ENTRY(_start)
SECTIONS
{
- - . = 0xC0000000 + 0x100000;
+ . = 0xA0000000 + 0x100000;
_text = .; /* Text and read-only data */
.text : {
*(.text)
- --- linux/include/asm-i386/page.h
+++ linux-/include/asm-i386/page.h
@@ -80,7 +80,7 @@
*
* which has the same constant encoded..
*/
- -#define __PAGE_OFFSET (0xC0000000)
+#define __PAGE_OFFSET (0xA0000000)

#define PAGE_OFFSET ((unsigned long)__PAGE_OFFSET)
#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)
is enough? We need to change this too to even boot, but this was
discussed between 11th and 15th Nov here:

- --- linux/include/asm-i386/io.h
+++ linux-/include/asm-i386/io.h
@@ -101,8 +101,8 @@
#include <linux/vmalloc.h>
#include <asm/page.h>

- -#define __io_virt(x) ((void *)(PAGE_OFFSET | (unsigned long)(x)))
- -#define __io_phys(x) ((unsigned long)(x) & ~PAGE_OFFSET)
+#define __io_virt(x) ((void *)(PAGE_OFFSET + (unsigned long)(x)))
+#define __io_phys(x) ((unsigned long)(x) - PAGE_OFFSET)
/*
* Change virtual addresses to physical addresses and vv.
* These are pretty trivial
- --
Pavel Janík ml.
Pavel.Janik@inet.cz

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Dec 1998 15:45:05 +0000 (GMT)
Subject: Re: Internationalizing Linux
> So is that why the old IBM mainframes tagged every system message with
> a unique identifier?

Probably.

> I think having messages appear in the sysadmin's native language has
> merit. The front line for Linux support is moving away from this
> list.
>
> Once messages permeate back to this list, they can be converted back
> to English just as the original message was converted originally to
> the native language.

Im beginning to agree. Firstly someone says they have the tools to do
this cleanly and automatically as well as intending to do it. Secondly
providing they put numbering in you can look messages up. But they do
need to provide a nice tool for this. If for non original messages you
generate a constant numbering - and that bit is non trivial then there
needs to be a way to do

cat bugreport | toenglish | more
that wil find all the numbered errors (eg format them $ID$ - text)
and replace them with their "original" format.

To my mind the constant numbering and also correct handling of positional
data are the killer issues.


Alan


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Antonio M. Trindade" <trindade@student.dei.uc.pt>
Date: Fri, 4 Dec 1998 14:47:12 +0000 (WET)
Subject: Sound Problem
I have a problem with sound module autoloading in kernel 2.1.130.

It's very simple. The modules just doesn't get loaded properly, and I
have to load it manually. When I run any sound utility, kerneld loads all
modules except the SoundBlaster one. For example, KMix says my kernel does
not have mixer support, x11amp doesn't play, but all works well when I
load it by hand.

Um abraco,
Antonio Trindade.

/---------------------------------------------------------------------------\
|Linux RuleZ Linux RuleZ Linux R| F.C.T. da Universidade de Coimbra |
|ux RuleZ Linux RuleZ Linux Rule| Antonio Miguel Ferreira Marques Trindade |
|-------------------------------| PGP Public key available by finger |
|Jean-Michel Jarre is very cool!| Coimbra, PORTUGAL |
|---------------------------------------------------------------------------|
| E-mail address: trindade@student.dei.uc.pt |S/2 OS/2 OS/2 OS/2 OS/2 OS/2 O|
\---------------------------------------------------------------------------/


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Stephen C. Tweedie" <sct@redhat.com>
Date: Fri, 4 Dec 1998 14:49:11 GMT
Subject: Re: SWAP: Linux far behind Solaris or I missed something (fwd)

Hi,

On Fri, 4 Dec 1998 10:41:15 +0000, Neil Conway
<nconway.list@ukaea.org.uk> said:
>> (although the 2.1.130+my patch seems to work very well
>> with extremely high swap throughput)

> Since the poster didn't say otherwise, perhaps this test was performed
> with buffermem/pagecache.min_percent set to their default values, which
> IIRC add up to 13% of physical RAM (in fact that's PHYSICAL ram, not 13%
> of available RAM). So take a 1024MB machine, with (say) roughly 16MB
> used by the kernel and kernel-data. Then subtract 0.13*1024 (133MB !!)
> and you're left with a paltry 875MB or so. (This assumes that the
> poster had modified his kernel to handle the full 1024MB btw).

I know. That's why relying on fixed margins to ensure good
performance is wrong: the system really ought to be self-tuning.
We may yet get it right for 2.2: there are people working on this.

- --Stephen

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Majdi Abbas" <abbas@cdtelecom.com>
Date: Fri, 4 Dec 1998 09:53:41 -0500 (EST)
Subject: Re: NO ROM BASIC

Kenneth D'Ambrosio wrote:
| That's not a kernel issue -- that's what a non-IBM(tm) machine says when
| it can't find a boot device. In other words, your hard drive is, somehow,
| not communicating with the system. Watch your power-up stuff, and you'll
| most likely see that the hard drive isn't being mentioned. Check your
| cables, make sure the BIOS is configured properly, make sure your ID
| jumpers are correct, and, lastly, listen to see if the drive itself is
| spinning up -- it may have died. NOTE: this is a HARDWARE issue; merely
| blowing away your MBR wouldn't give you this error; then you'd get a
| "Can't find OS" or some such error.

Note that IIRC, there is an interrupt that will start ROM BASIC;
If his boot block is corrupted or being misread (bad BIOS geometry?) it's
possible to get this as well.

BTW, older NEC machines did it too :)

--msa

- --
Majdi Abbas <abbas@cdtelecom.com> Caped Crusader
CableData Telecommunications 734.995.5590 x229

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: <kfrench@unitedis.com>
Date: Fri, 4 Dec 1998 09:57:50 -0500 (EST)
Subject: Re: disks stats through /proc

I had fixed up the scsi/ide/4drive limit a while ago, but it was never
included. It was around the IO-APIC introduction time (i.e. more
important things were 'broken') and there were rumblings of a code freeze.

Grab
http://pebbles.net/~kfrench/linux/blockstatarray-2.1.86.gz
http://pebbles.net/~kfrench/linux/blockstatdirect-2.1.86.gz

Each one does the same thing, but does it differently (apply *only* one of
these, not both). 'array' hold a resizeable array for each device, and
'direct' creates a large array up-front for performance reasons. I like
'array' and Mark Lord likes 'direct'. It'll need a little fixing up to
get it going on 2.1.130, but it shouldn't be a big deal. It's also
trivial to do this on a partition level - it's just a matter of removing
the switch() statement which intentionally removes the per-partition parts
of a device #.

-kf

On Thu, 3 Dec 1998, Tigran Aivazian wrote:

> IMHO, this should be done on a fine-grained (partition level) rather than
> coarse (drive) level. There is enough information in
> ll_rw_blk.c/add_request() to do it now but, of course, kernel_stat
> structure will have to be seriously modified.
>
> There is something frustrating about the quality and speed of Linux
> development. I.e. the quality is too high and the speed is too high, in
> other words, I can implement this disk stat feature, but I bet someone else
> has already done it and is just about to release his patch to Linus soon...

heh


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Date: Fri, 4 Dec 1998 14:57:06 +0000
Subject: "TCPv4 bad checksum" errors: a little more debugging
Is it linux.kernel.org's fault? Is it Demon Internet? :-)

My ISP is Demon Internet. I have seen bursts of TCPv4 checksum errors
while transferring SMTP mail from Demon's servers, and recently from
linux.kernel.org. Probably others too.

I've looked at some recent packet traces in detail, to see what's going
on.

I wrote:
> Since 2.1.127 or thereabouts, I've noticed lots of "TCPv4 bad checksum"
> errors in my kernel logs. This is over a PPP connection.

I checked it is not VJ header compression bugs or serial overruns. Now
I've summed the contents of several bad packets (and good ones) by hand,
I can confirm that the problem is *not* kernel processing of incoming
packets: the packets really are faulty.

The interesting part is that all the errors I've looked at recently are
from the same address, linux.kernel.org. Probably this is a burst of
errors, as I've seen previous bursts from Demon's servers too, but I
haven't looked at those packets in detail. I had VJ header compression
on then too.

The other interesting thing is that the _faulty_ packets are from port
80, the HTTP port even though I did *not* send an HTTP request. They
arrive at about the same time as I have an FTP connection, which I *did*
request, which seems to be fine.

One of the packets is clearly from the middle of an HTTP stream, but has
an odd segment length (127). While not strictly a bug, this looks like
a peculiar artefact of the TCP sender. The packet header looks fine
(complete with correct length and IP checksum), but the TCP checksum is
faulty. And of course, I wasn't expecting the packet.

My first guess is that some router is rewriting the destination IP
address (but not the CRC) and sending the packet to me instead of its
real destination.

The errors usually come in bursts lasting a few minutes. I've noticed
fewer of them recently, since I switched of VJ header compression. I've
turned it back on now, we'll see what happens.

Packet log (about 16k for these errors) available on request. Much
larger log including VJ compressed packets and more errors also
available (152k).

- -- Jamie

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Dec 1998 15:58:34 +0000 (GMT)
Subject: Re: st_blocks - was: Re: crazy swapping
> Must I document the st_blocks field in a struct stat
> as returned by the stat system call on an ordinary file
> to be an approximation of the size measured in 512-byte blocks?

And how will that relate to 64bit files


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Frodo Looijaard <frodol@dds.nl>
Date: Fri, 4 Dec 1998 16:07:07 +0100 (CET)
Subject: Re: /dev/temperature


Alain Borel wrote:
> On 03-Dec-98 Roman Drahtmueller wrote:
> > My request for information about CPU-temperature measuring: Results:
> >
> > The package is called "lm78".
> >
> > http://www.netroedge.com/~lm78/
> >
>
> By the way, does anybody know a driver (or tech info) for the ACOPS98
> system in use on the Gigabyte mainboards? It is not compatible with
> the lm75/78 (as stated on http://www.giga-byte.com/RACOPS2.html)...
> Unfortunatley the word 'patented' appears on said page: this might
> mean 'NDA' in advertising language :-(

If you find the documentation, and are allowed to, please forward a copy
to me (frodol@dds.nl).

We are currently working on version two of lm_sensors (which was previously
called lm78). It uses a driver model, in which both bus drivers and chip
drivers can easily be added. It can use all existing i2c drivers, too:
in the first released version, there will be VIA chipset support, for
example. lm_sensors version 2 will be released somewhere this month.

Frodo

- --
Frodo Looijaard <frodol@dds.nl> PGP key and more: http://huizen.dds.nl/~frodol
At my homepage you will also find a guide for installing glibc under Linux.
New: Linux hardware monitoring kernel modules (LM78/79/80, Winbond etc.)


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Ben McCann <bmccann@indusriver.com>
Date: Fri, 04 Dec 1998 10:06:13 -0500
Subject: Re: Linux-2.1.131.. (VM Tuning)

Rik,

I tried you patches (included below) on a 2.1.131 kernel and there
was a noticable improvement under heavy load. I have a C++ application
that has many source and include files, and that uses templates
extensively. The virtual image of the EGCS compiler grows to 70 to
80 MB on some files and my PC only has 64MB of RAM.

I 'time'd the compilation of this application using vanilla 2.1.131:

610.510u 75.660s 24:49.75 46.0% 0+0k 0+0io 167009pf+235932w

Then I applied your patches, rebuilt, rebooted, and repeated the test:

631.650u 74.920s 24:24.99 48.2% 0+0k 0+0io 164174pf+261103w

The compile time improvement (about 1.7%) is OK _and_ there was also
a noticable improvement in the 'feel' of the system if I run X and
emacs while compiling. Without your patch, interactive response times
from emacs were often several seconds long.

FYI, I have two swap areas (64MB each) on two disks so I don't know
which of your changes the largest contributor to the performance
improvement.

Thanks!
Ben McCann


Rik van Riel wrote:
>
> On Wed, 2 Dec 1998, Linus Torvalds wrote:
>
> > 2.1.131 is out there now - and will be the last kernel release for a
> > while. I'm going to Finland for a week and a half, and will be back
> > mid December. During that time I hope people will beat on this.
>
> There are a few things in the VM balancing of 2.1.131 that
> I strongly disagree with and that will make performance
> far worse than it could have been.
>
> +++ linux/mm/swap.c Fri Nov 27 10:15:29 1998
> - 25, /* borrow percent buffer */
> + 10, /* borrow percent buffer */
> - 30, /* borrow percent page cache */
> + 15, /* borrow percent page cache */
>
> Decreasing the borrow percentages will make the system
> clear out the caches too soon. The system should basically
> be self-tuning and the borrow percentages are only there
> to make sure that the system doesn't continue swapping
> when we have obscene amounts of cache.
>
> +++ linux/mm/vmscan.c Mon Nov 30 16:05:40 1998
> @@ -431,7 +431,7 @@
> kmem_cache_reap(gfp_mask);
>
> if (buffer_over_borrow() || pgcache_over_borrow())
> - shrink_mmap(i, gfp_mask);
> + state = 0;
>
> This is a good fix as it returns behaviour back to the normal
> and desired behaviour (except for too heavy cache pruning).
> This patch would have been better however, since it does what
> we want without too heavy cache pruning or massive swapout
> frenzies.
>
> +++ ./mm/vmscan.c Tue Dec 1 07:12:28 1998
> @@ -431,6 +431,8 @@
> kmem_cache_reap(gfp_mask);
>
> if (buffer_over_borrow() || pgcache_over_borrow())
> + state = 0;
> + if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster / 2)
> shrink_mmap(i, gfp_mask);
>
> switch (state) {
>
> This patch (against 2.1.130) makes sure that kswapd will free
> memory even during heavy swapout frenzies. This makes sure
> that kswapd will finish (swapout frenzies don't free memory
> and make kswapd swap too much without doing it's job) without
> swapping too heavily.
>
> By testing for swap_cluster/2 we make sure that we don't hamper
> swapout throughput too much and don't block the I/O subsystem
> either.
>
> I have been using this patch for several days now without any
> problems whatsoever (and far better performance than ever before).
>
> And finally here is a third patchlet to fix page_io.c, it should
> be fairly obvious what this patch does. It is mainly useful when
> we have multiple swap partitions over which we stripe -- increasing
> the value of swap_cluster will give us much more throughput then.
>
> --- ./mm/page_io.c.orig Thu Nov 26 11:26:49 1998
> +++ ./mm/page_io.c Thu Nov 26 11:30:43 1998
> @@ -60,7 +60,7 @@
> }
>
> /* Don't allow too many pending pages in flight.. */
> - if (atomic_read(&nr_async_pages) > SWAP_CLUSTER_MAX)
> + if (atomic_read(&nr_async_pages) > pager_daemon.swap_cluster)
> wait = 1;
>
> p = &swap_info[type];
>
> regards,
>
> Rik -- the flu hits, the flu hits, the flu hits -- MORE
> +-------------------------------------------------------------------+
> | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
> | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
> +-------------------------------------------------------------------+
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

- --
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmccann@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Stephen C. Tweedie" <sct@redhat.com>
Date: Fri, 4 Dec 1998 15:07:07 GMT
Subject: SAR (was Re: disks stats through /proc)

Hi,

On Thu, 3 Dec 1998 13:39:42 +0000 (GMT), Tigran Aivazian
<tigran@aivazian.demon.co.uk> said:
> IMHO, this should be done on a fine-grained (partition level) rather than
> coarse (drive) level. There is enough information in
> ll_rw_blk.c/add_request() to do it now but, of course, kernel_stat
> structure will have to be seriously modified.

> There is something frustrating about the quality and speed of Linux
> development. I.e. the quality is too high and the speed is too high,
> in other words, I can implement this disk stat feature, but I bet
> someone else has already done it and is just about to release his
> patch to Linus soon...

Yep, done that. :)

I have patches for 2.0.34/35 and 2.1.125 already working, outputing
both per-partition and per-spindle access stats via /proc/partitions.
A "sard" front-end gives human-readable output. (It is modeled on the
output of the SVR4 "sar -d" output.)

Currently you get average %utilisation; average request queue length;
number of K transfered plus number of distinct IOs for reads, writes
and combined; and average request service time for each disk and each
partition.

Look for

ftp://ftp.uk.linux.org:/pub/linux/sct/fs/sard-0.2.tar.gz

for the patches and sard source code. The plan is to integrate this
into 2.3 once we have got a more sensible kdev_t in the kernel.

- --Stephen

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "S. Shore" <sshore@escape.ca>
Date: Fri, 4 Dec 1998 09:12:47 -0600 (CST)
Subject: Re: Y2k compliance

In fact, the year 2000 isn't a leap year. A little-known rule of leapyears
(iirc) is that any year divisible by 100 (i think) can't be a leapyear.

Scott.

On Fri, 4 Dec 1998 robbie@scot-mur.demon.co.uk wrote:

> Date: Fri, 4 Dec 1998 01:03:30 +0000
> From: robbie@scot-mur.demon.co.uk
> To: Linux Kernel List <linux-kernel@vger.rutgers.edu>
> Subject: Re: Y2k compliance
>
> On Thu, Dec 03, 1998 at 10:30:44AM -0500, Gregory Maxwell wrote:
> > On Thu, 3 Dec 1998, Chris Wedgwood wrote:
> >
> > > On Wed, Dec 02, 1998 at 11:53:57AM +1030, Alan Modra wrote:
> > >
> > > > Linux ignores the RTC century byte (for good reason). Before I put
> > > > this fix in, when the year wrapped to 00 Linux would read the RTC
> > > > year as 1900. So a reboot (who does that anyway?) would give a
> > > > classic Y2K time warp.
> > >
> > > So how does it know what century it is?
> >
> > If the right part of the year is less then z it's 20xx if it's greater
> > it's 19xx
> So how does it cope with 2000 being a leep year? In the small ammount of
> experimenting I have done, the year goes back to 1980, not 1900. I think
> linux needs some way of dealing with these buggy machines, probably in
> user space.
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
>
> Robbie Murray
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
End of linux-kernel-digest V1 #2942
***********************************
To subscribe to linux-kernel-digest, send the command:

subscribe linux-kernel-digest

in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":

subscribe linux-kernel-digest local-linux-kernel@your.domain.net

A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.590 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site