Messages in this thread Patches in this message | | | Date | Sat, 05 Dec 1998 19:00:19 +0800 | From | Foong Wai Ho <> | Subject | Re: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/
| |