Re: Dell Precision 330 (Pentium 4, i850 chipset, 3c905c)
What is the output of 'lspci -v'? If it says that the chip revision is '78' then this is one of the new 3C905CX (note the CX) NIC's or ASIC on the motherboard. I've seen a problem with the 3c59x.c driver and this chip, it can send packets but not receive any. The 3Com 3c90x-1.0.0i.tgz driver at http://support.3com.com/infodeli/tools/nic/linux.htm should work with this chip. There has been some discussion of this NIC on the vortex mailing list at http://www.scyld.com/network/vortex.html , with a patched driver to make for this chip available for testing at Andrew's web site http://www.uow.edu.au/~andrewm/linux/#3c59x-bc (see the '2.2.19pre2 driver for testing'). Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0 tulip bug (was: And oh, btw..)
On Thu, 4 Jan 2001, Linus Torvalds wrote: >Changes since the prerelease: >... >Matti Aarnio: > - teach tulip driver about media types 5 and 6 This part of the patch introduces a bug in 2.4.0, as noticed by gcc: media.c: In function `tulip_select_media': media.c:268: warning: unused variable `csr15val' media.c:268: warning: unused variable `csr15dir' media.c:268: warning: unused variable `csr14val' media.c:268: warning: unused variable `csr13val' media.c:151: warning: `new_csr6' might be used uninitialized in this function The last warning indicates a real problem. The patch adds a new control flow path in which new_csr6 is _not_ assigned a value, which causes the procedure's second last statement tp->csr6 = new_csr6 | (tp->csr6 & 0xfdff) | (tp->full_duplex ? 0x0200 : 0); to 'or' random bits into tp->csr6. The patch also adds four unused variables, which looks rather fishy. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> I need to look at fdisk, because it is doing things wrong. I don't think so, unless you have a really old version. > Linux sees the correct size, but fdisk still sees 32 GB. > Probably a recompile / upgrade. Yes, upgrade in case your version is older than 2.10i. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 todo list update
> * VFS?VM - mmap/write deadlock (demo code seems to show lock > is there) Linus fixed that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Error building 2.4.0-prerelease
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/acpi/acpi.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux net/network.o: In function `ftp_nat_expected': net/network.o(.text+0x2ef31): undefined reference to `ip_nat_setup_info' net/network.o: In function `delete_sack': net/network.o(.text+0x2f340): undefined reference to `ip_nat_cheat_check' net/network.o: In function `help': net/network.o(.text+0x2f740): undefined reference to `ip_nat_cheat_check' net/network.o(.text+0x2f750): undefined reference to `ip_nat_cheat_check' net/network.o: In function `init': net/network.o(.text.init+0x116f): undefined reference to `ip_nat_expect_register' net/network.o(.text.init+0x1182): undefined reference to `ip_nat_helper_register' net/network.o(.text.init+0x1195): undefined reference to `ip_nat_expect_unregister' make: *** [vmlinux] Error 1 [summer@possum linux]$ [summer@possum linux]$ gcc -v Reading specs from /usr/lib/gcc-lib/i686-redhat-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) [summer@possum linux]$ Here's the configuration: CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_M686=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_MSR=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_HOTPLUG=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_ACPI=y CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_1284=y CONFIG_PNP=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=m CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_NET_DIVERT=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y CONFIG_IDEDMA_AUTO=y CONFIG_IDEDMA_IVB=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_TCQ_ON_BY_DEFAULT=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_PROC_STATS=y CONFIG_AIC7XXX_RESET_DELAY=5 CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_TUN=m CONFIG_ETHERTAP=m CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_EPIC100=y CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_ASYNC=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_SLIP=m CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_EVDEV=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_AGP=m CONFIG_AGP_INTEL=y CONFIG_DRM=y CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_JFFS_FS_VERBOSE=0 CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFSD=y CONFIG_NFSD_V3=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y
Re: Dell Precision 330 (Pentium 4, i850 chipset, 3c905c)
Sorry to follow up, but I forgot to note that it is trying to share IRQ 11 for aic7xx and eth0. However, even if I move the Adaptec card to another slot, where it gets IRQ 10, still no joy for eth0 on IRQ 11. --Lee Hetherington - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Dell Precision 330 (Pentium 4, i850 chipset, 3c905c)
Andrew Morton wrote: > Please do. The boot-time messages which come out of the driver > would be interesting. It would help if you add `debug=7' to > the 3c59x modprobe command line also. OK. I've included dmesg output due to modprobe with debug=7 followed by ifup (using pump -- problems persist with static IP as well), cat /proc/interrupts showing no eth0, and ifconfig eth0. Please let me know what else I can provide to help out. --Lee Hetherington 3c59x.c 15Sep00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905C Tornado at 0xe880, 00:b0:d0:14:d2:b4, IRQ 11 Internal config register is 180, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 1, status 24. MII transceiver found at address 2, status 24. Enabling bus-master transmits and whole-frame receives. eth0: Initial media type Autonegotiate. eth0: MII #1 status 0024, link partner capability 41e1, setting full-duplex. eth0: vortex_open() InternalConfig 0180. eth0: vortex_open() irq 11 media status 8080. eth0: Filling in the Rx ring. eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: Trying to send a boomerang packet, Tx index 0. eth0: interrupt, status f201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status f201. eth0: exiting interrupt, status f000. eth0: Media selection timer tick happened, Autonegotiate. eth0: MII transceiver has status 0020. eth0: Media selection timer finished, Autonegotiate. eth0: Trying to send a boomerang packet, Tx index 1. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: Trying to send a boomerang packet, Tx index 2. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 3. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 4. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 5. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 6. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 7. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 8. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 9. eth0: interrupt, status e201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: Trying to send a boomerang packet, Tx index 10. eth0: interrupt, status e201, latency 2, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status e201. eth0: exiting interrupt, status e000. eth0: vortex_close() status e000, Tx status 00. eth0: vortex close stats: rx_nocopy 0 rx_copy 0 tx_queued 11 Rx pre-checksummed 0. eth0: Initial media type Autonegotiate. eth0: MII #1 status 0020, link partner capability 41e1, setting full-duplex. eth0: vortex_open() InternalConfig 0180. eth0: vortex_open() irq 11 media status 8080. eth0: Filling in the Rx ring. eth0: no boomerang interrupt pending eth0: no boomerang interrupt pending eth0: Trying to send a boomerang packet, Tx index 0. eth0: interrupt, status f201, latency 3, cur_rx 0, dirty_rx 0 eth0: In interrupt loop, status f201. eth0: exiting interrupt, status f000. eth0: Media selection timer tick happened, Autonegotiate. eth0: MII transceiver has status 0020. eth0: Media selection
2.4 todo list update
Hi Ted,
in the last few weeks quite a few of the bugs listed on your
(excellent) http://linux24.sourceforge.net/ have been fixed.
Here is a list of the VM bugs that are on your list and can
be moved to the "fixed" category:
* truncate->invalidate_inode_pages removes mapping information from
mapped pages which may be dirty; sync_pte -> crash. (CRITICAL)
fixed by Linus and Al
* VM: raw I/O data loss (raw IO may arrive in a page which afer it
is unammped from a process) (CRITICAL)
fixed by Linus, now page_launder() does the IO
and try_to_swap_out() only unmaps the pte
* VM: Fix the highmem deadlock, where the swapper cannot create low
memory bounce buffers OR swap out low memory because it has
consumed all resources {CRITICAL}
this was never an issue, the pagecache has been
highmem safe for a long time and the whole bounce
buffer creation has been removed
* VM: page->mapping->flush() callback in page_lauder() for easier
integration with journaling filesystem and maybe the network
filesystems
page->mapping->writepage(), used from page_launder()
... now ext3, reiserfs, xfs and others need to make
their own ->writepage() function
... some semantics are still being discussed, but it's
mostly ready
* VM: maybe rebalance the swapper a bit... we do page aging now so
maybe refill_inactive_scan() / shm_swap() and swap_out() need to
be rebalanced a bit
moving shm into the page cache permanently and doing
the page down aging from refill_inactive_scan() seems
to have fixed most of this
... low priority, but may still have some room for
improvement (consider it fixed)
The following bugs _could_ be fixed ... I'm not 100% certain
but they're probably gone (could somebody confirm/deny?):
* mm->rss is modified in some places without holding the
page_table_lock
* VFS?VM - mmap/write deadlock (demo code seems to show lock
is there)
The "probably post 2.4" category VM issues remain ... maybe
we want to add the following 2 items though:
* VM: experiment with different forms of page aging ... maybe
different aging rates for pages of different ages
* VM: RSS ulimit enforcement (trivial)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to loose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: More better in mount(2)
Nathan Scott wrote: > On Jan 5, 3:26am, Daniel Phillips wrote: > > ... > > This filesystem mount option parsing code is completely ad hoc, and uses > > strtok which is horribly horribly broken. (Do man strtok and read the > > 'Bugs' section.) > > > > It would be worth thinking about how to do this better. > > hmm ... can't claim I wrote this code, just looked at it. > are you saying the kernel strtok is horribly broken or just > the way its being used here? (and why?) >From the man page: BUGSNever use this function. If you do, note that: This function modifies its first argument. The identity of the delimiting character is lost. This functions cannot be used on constant strings. The strtok () function uses a static buffer while parsing, so it's not thread safe. Use strtok_r () if this matters to you. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reset_xmit_timer errors with 2.4.0
Hello! I've installed 2.4.0 on a system that has been tracking 2.3.xx/2.4test for quite a while. With 2.4.0 installed, I've started to see the following errors: reset_xmit_timer sk=cfd889a0 1 when=0x3b4a, caller=c01e0748 reset_xmit_timer sk=cfd889a0 1 when=0x3a80, caller=c01e0748 reset_xmit_timer sk=cfd889a0 1 when=0x398a, caller=c01e0748 reset_xmit_timer sk=cfd889a0 1 when=0x389e, caller=c01e0748 reset_xmit_timer sk=cfd889a0 1 when=0x37b6, caller=c01e0748 It's a UP system with no kernel patches, running an eepro100 card. I did not get these errors under any of the 2.4test kernels. Should I be worried? Best, -- Patrick Michael Kane <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18: do_try_to_free_pages
On Fri, 5 Jan 2001, Rik van Riel wrote: > [If you don't mind, please help test 2.4.0 a bit more. I'm > pretty confident it's better than 2.2.18 when under load, > but maybe the device drivers you use still need some tweaking] I'll be trying to move to 2.4.0 again soon. First 2.4.0-test* I tried was one that ate filesystems (reinstall, not pretty). Second 2.4.0-test* I tried, I tried to get UDMA working (ALi 1533) ate my filesystems again. Third 2.4.0-test*, I finally decided to give up on UDMA on my hardware when I trashed my filesystems once again. Tried changing the 80-conductor cable a couple times, and tried different hdparm options, but no luck. Sucks having two 7200RPM/2MB buffer/UDMA33 drives and only getting 7.7Mbyte/sec off of them. At least my system at work (Athlon/Irongate) gets 24MB/sec without tweaking on one of those Maxtor 60MB/5400RPM drives. Oh well, I'm just rambling now...I'll probably fire up 2.4.0 this weekend on my main machine, so unless this error is capable of corruption, I'll likely wait until then and just skip the 2.2.19 series. Thanks, - Brad Hartin - [EMAIL PROTECTED] Communications Administrator Straus-Frank Enterprises Limited Carquest retail/wholesale distributor for areas in TX, OK, LA, AR, NM, and KS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anyone else interested in a high-precision monotonic counter?
Manfred Bartz wrote: > Why a new system call? Well, you'd be accessing a different kernel variable--"ytime" instead of "xtime". This new variable wouldn't be adjusted when the system time/date was, it would start at zero and always increase. > regarding a: it could have microsecond resolution but not > microseconds accuracy. On PPC and x86 systems, gettimeofday() is both accurate and precise to microseconds, since it is based off of jiffies and then offset to get microseconds. > regarding b: have you looked at the return-value of times(2) > Or roll your own using setitimer(2) Both of these are precise only to jiffies, which defaults at 10 milliseconds on x86 and PPC. If you want microsecond timing, the only current standard way to do it is to use gettimeofday(), which is sensitive to changes in system date and time. -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18: do_try_to_free_pages
On Fri, 5 Jan 2001, Brad Hartin wrote: > Jan 4 00:06:05 osprey kernel: VM: do_try_to_free_pages failed for X... > Jan 4 00:06:06 osprey last message repeated 6 times This bug is fixed in 2.2.19-pre2 and later. Oh, and 2.4.0 of course doesn't have it either ;) [If you don't mind, please help test 2.4.0 a bit more. I'm pretty confident it's better than 2.2.18 when under load, but maybe the device drivers you use still need some tweaking] regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel halts rock solid on assigning ip (ne2k-pci)
Hi, I have a problem with a network-driver. The ne2k-pci modules loads fine, no problem at all. Everything works like a sunshine. But as soon as I try to assign an IP-adress the whole system halts rock-solid, the magic sysrq combinations don't even work anymore. I am not sure if this is due to an IRQ-conflict. But I do know it all happens to work perfectly fine with 2.4.0-test10. This happens on both 2.4.0-prerelease and the 2.4.0-kernel. I attached some info about my configuration. I hope you/somebody can help me solve this, I am eager to start using 2.4.0. So far I have been very happy using 2.4.0-test10. Thanks for any comments, Aschwin -- "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. # cat /proc/version Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #14 Fri Jan 5 13:36:52 EET 2001 # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 41) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) 00:07.3 Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) 00:08.0 Ethernet controller: Winbond Electronics Corp W89C940 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G100 [Productiva] AGP (rev 02) # lspci -vv -s 00:08.0 00:08.0 Ethernet controller: Winbond Electronics Corp W89C940 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://www.scyld.com/network/ne2k-pci.html Jan 5 15:29:15 lorien kernel: PCI: Found IRQ 11 for device 00:08.0 Jan 5 15:29:15 lorien kernel: eth0: Winbond 89C940 found at 0xe800, IRQ 11, 48:54:E8:2B:CB:F7. # modprobe -V modprobe: Nothing to load ??? Specify at least a module or a wildcard like \* modprobe version 2.4.0 # cat /proc/interrupts CPU0 0: 144539 XT-PIC timer 1: 3891 XT-PIC keyboard 2: 0 XT-PIC cascade 4:986 XT-PIC serial 5: 1 XT-PIC soundblaster 14: 123626 XT-PIC ide0 15: 6 XT-PIC ide1 NMI: 0 ERR: 0 # cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0213-0213 : isapnp read 0220-022f : soundblaster 02f8-02ff : serial(auto) 0376-0376 : ide1 03c0-03df : vga+ 03c0-03df : matrox 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0a79-0a79 : isapnp write 0cf8-0cff : PCI conf1 5000-50ff : VIA Technologies, Inc. VT82C586B ACPI d000-dfff : PCI Bus #01 e000-e00f : VIA Technologies, Inc. Bus Master IDE e000-e007 : ide0 e008-e00f : ide1 e800-e81f : Winbond Electronics Corp W89C940 e800-e81f : ne2k-pci # cat /proc/iomem -0009fbff : System RAM 0009fc00-0009 : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-05ff : System RAM 0010-0022b05d : Kernel code 0022b05e-0029f963 : Kernel data e000-e3ff : PCI Bus #01 e000-e0003fff : Matrox Graphics, Inc. MGA G100 [Productiva] AGP e000-e0003fff : matroxfb MMIO e100-e17f : Matrox Graphics, Inc. MGA G100 [Productiva] AGP e400-e4ff : PCI Bus #01 e400-e4ff : Matrox Graphics, Inc. MGA G100 [Productiva] AGP e400-e47f : matroxfb FB e600-e63f : VIA Technologies, Inc. VT82C597 [Apollo VP3] - : reserved # cat /proc/isapnp Card 1 'CMI0001:CMI8330/C3D Audio Adapter' PnP version 1.0 Logical device 0 '@@@0001:Unknown' Device is active Active port 0x530,0x388 Active DMA ,0 Resources 0 Priority preferred Port 0x530-0x530, align 0x0, size 0x8, 16-bit address decoding Port 0x388-0x388, align 0x0, size 0x8, 16-bit address decoding IRQ 11 High-Edge DMA 0 8-bit byte-count compatible Alternate resources 0:1 Priority acceptable Port 0x530-0x530, align 0x0, size 0x8, 16-bit address decoding Port 0x388-0x388, align 0x0, size 0x8, 16-bit address decoding IRQ 5,7,2/9,10,11,12 High-Edge DMA 0,1,3 8-bit byte-count compatible Alternate resources 0:2 Priority acceptable Port 0x530-0xfe0, align 0xf, size 0x8, 16-bit address decoding Port 0x388-0x3f8, align 0xf, size 0x8, 16-bit address decoding IRQ 5,7,2/9,10,11,12 High-Edge DMA 0,1,3 8-bit byte-count compatible Logical device 1 '@H@0001:Unknown' Device is not active Active port 0x330 Active IRQ 9 [0x2] Active DMA 0,0 Resources 0
Re: reiserfs patch for 2.4.0-final
On Friday, January 05, 2001 02:04:08 PM +0100 Claas Langbehn <[EMAIL PROTECTED]> wrote: > On Thu, Jan 04, 2001 at 04:52:49PM -0500, Chris Mason wrote: >> This patch is meant to be applied on top of the reiserfs >> 3.6.23 patch to get everything working in the new prerelease >> kernels. The order is: >> >> untar linux-2.4.0-prerelease.tar.bz2 >> apply linux-2.4.0-test12-reiserfs-3.6.23.gz >> apply this patch >> apply the fs/super.c patch to make sure fsync_dev is called >> when unmounting /. This was already sent to l-k, I'll send >> to the reiserfs list as well. > > Is this still correct for the final 2.4.0-kernel ? > Yes > Could someone create one single patch for the 2.4.0 ? > I put all the code into CVS, and Yura is making the official patch now. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18: do_try_to_free_pages
I recieved the following messages from the kernel yesterda morning. It doesn't appear that any running programs actually died, or ran out of memory (128M physical/ 256M swap, only about 150M total or so in use when I got back on the machine. As a side note, during times of what I consider only moderate system activity (burning a CD while xmms playing and doing stuff in netscape, for example) I've had some system freezes. While under X, everything freezes solid, mouse pointer and all. System is completely inaccessable. After about 2 minutes or so, everything begins responding again. These problems began only when I moved to kernel 2.2.18. I also have Reiserfs 3.5.29 patched in, and in use. System is a K6-2/450, 128MB ram, Matsonic 6120S motherboard, ALi chipset. Just email me for any more details that are needed. dmesg: Jan 4 00:06:05 osprey kernel: VM: do_try_to_free_pages failed for X... Jan 4 00:06:06 osprey last message repeated 6 times Jan 4 00:06:06 osprey kernel: VM: do_try_to_free_pages failed for klogd... Jan 4 00:06:07 osprey last message repeated 15 times Jan 4 00:06:07 osprey kernel: VM: do_try_to_free_pages failed for kfm... Jan 4 00:06:07 osprey last message repeated 14 times Jan 4 00:06:07 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:07 osprey last message repeated 4 times Jan 4 00:06:07 osprey kernel: VM: do_try_to_free_pages failed for xmms... Jan 4 00:06:08 osprey last message repeated 10 times Jan 4 00:06:08 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:08 osprey kernel: VM: do_try_to_free_pages failed for klogd... Jan 4 00:06:09 osprey last message repeated 14 times Jan 4 00:06:09 osprey kernel: VM: do_try_to_free_pages failed for identd... Jan 4 00:06:09 osprey last message repeated 4 times Jan 4 00:06:09 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:09 osprey last message repeated 10 times Jan 4 00:06:09 osprey kernel: VM: do_try_M: do_try_to_free_pages failed for syslogd... Jan 4 00:06:09 osprey kernel: VM: do_try_to_free_pages failed for init... Jan 4 00:06:10 osprey last message repeated 14 times Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for identd... Jan 4 00:06:10 osprey last message repeated 14 times Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for fetchmail... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for xmms... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for X... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for X... Jan 4 00:06:11 osprey last message repeated 14 times Jan 4 00:06:11 osprey kernel: VM: do_try_to_free_pages failed for xmms... Jan 4 00:06:11 osprey last message repeated 14 times Jan 4 00:06:11 osprey kernel: VM: do_try_to_free_pages failed for wpexc... Jan 4 00:06:12 osprey last message repeated 14 times Jan 4 00:06:12 osprey kernel: VM: do_try_to_free_pages failed for fetchmail... ... Messages continue for all programs running at the time, and end with: ... Jan 4 00:06:16 osprey kernel: VM: do_try_to_free_pages failed for gpm... Jan 4 00:06:17 osprey last message repeated 13 times Jan 4 00:06:17 osprey kernel: VM: do_try_to_free_pages failed for crond... Jan 4 00:06:17 osprey last message repeated 14 times - Brad Hartin - [EMAIL PROTECTED] Communications Administrator Straus-Frank Enterprises Limited Carquest retail/wholesale distributor for areas in TX, OK, LA, AR, NM, and KS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Network oddity....
On Fri, 5 Jan 2001, Rogier Wolff wrote:
>Date: Fri, 5 Jan 2001 01:08:49 +0100 (MET)
>From: Rogier Wolff <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=US-ASCII
>Subject: Network oddity
>
>
>Hi all,
>
>I have a server, and it reports ("netstat -a")
>
>tcp0 0 server:sshclient:1022 SYN_RECV
>
>This sounds normal right?
>
>However there are 79 of these lines in the netstat output. Not normal!
>
>A TCP connection is identified by the 12 bytes source IP, dest IP,
>source port, dest port. Right? Then as far as I can see, these should
>all refer to the SAME socket. (yes, they all refer to server:ssh, and
>client: 1022!)
>
>Oh, this situation seems to continue: it sends a syn-ack and then the
>client replies with a reset. This goes on and on. I'm going to make
>the client disappear, and hope that this makes the number of these
>connections go away.
>
>Kernel is 2.2.13. That was "fresh" when the system was booted. Yes,
>that's over 14 months ago.
Someone synflooding you perhaps?
--
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
--
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?
-- Tom Cargill, C++ Journal, Fall 1990.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Fw: Change of policy for future 2.2 driver submissions
> since Mark posted his views to the list, I figured I could safely post the > conversation I've been having with him in email which is universally considered rude, if not illegal. in any case, please don't respond to this thread, which is quite off-topic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Hi, On Fri, Jan 05, 2001 at 12:46:19PM +, Alan Cox wrote: > > recovery. Because the ext3 journal is just a series of data blocks to > > be copied into the filesystem (rather than "actions" to be done), it > > doesn't matter how many times it is done. The recovery flags are not > > reset until after the journal replay is completed. > > Which means an ext3 volume cannot be recovered on a hard disk error. Depends on the error. If the disk has gone hard-readonly, then we need to recover in core, and that's something which is not yet implemented but is a known todo item. Otherwise, it's not worse than an error on ext2: you don't have a guaranteed safe state to return to so you fall back to recovering what you can from the journal and then running an e2fsck pass. e2fsck groks the journal already. And yes, a badly faulty drive can mess this up, but it can mess it for ext2 just as badly. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] up to 50% faster sys_poll()
sys_poll spends around 1/2 of the execution time allocating / freeing a
few bytes temporary memory.
The attached patch tries to avoid these allocation by using the stack -
usually only a few bytes are needed, kmalloc is used for the rest.
The result: one poll of stdin is down from 1736 cpu ticks to 865 cpu
ticks (Pentium II/350 SMP, SMP kernel)
select() should also be faster, but I haven't written a micro-benchmark
for select.
Please test it,
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 0
// EXTRAVERSION =
--- 2.4/fs/select.c Thu Nov 16 21:54:18 2000
+++ build-2.4/fs/select.c Fri Jan 5 13:46:30 2001
@@ -24,12 +24,6 @@
#define ROUND_UP(x,y) (((x)+(y)-1)/(y))
#define DEFAULT_POLLMASK (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM)
-struct poll_table_entry {
- struct file * filp;
- wait_queue_t wait;
- wait_queue_head_t * wait_address;
-};
-
struct poll_table_page {
struct poll_table_page * next;
struct poll_table_entry * entry;
@@ -52,11 +46,36 @@
* poll table.
*/
+/*
+ * Memory free and alloc took a significant part of the total
+ * sys_poll()/sys_select() execution time, thus I moved several
+ * structures on the stack:
+ * - sys_select has a 192 byte (enough for 256 fds) buffer on the stack.
+ * Please avoid selecting more than 5000 descriptors
+ * (kmalloc > 4096 bytes), and you can't select
+ * more than 170.000 fds (kmalloc > 128 kB)
+ * - sys_poll stores the first 24 file descriptors on the
+ * stack. If more than 24 descriptors are polled, then
+ * additional memory is allocated, but the first 24 descriptors
+ * always lie on the stack.
+ * - the poll table contains 8 wait queue entries. This means that no dynamic
+ * memory allocation is necessary for the wait queues if one of the first
+ * 8 file descriptors has new data.
+ * <[EMAIL PROTECTED]>
+ */
+
void poll_freewait(poll_table* pt)
{
struct poll_table_page * p = pt->table;
+ struct poll_table_entry * entry;
+ entry = pt->internal + pt->nr;
+ while(pt->nr > 0) {
+ pt->nr--;
+ entry--;
+ remove_wait_queue(entry->wait_address,>wait);
+ fput(entry->filp);
+ }
while (p) {
- struct poll_table_entry * entry;
struct poll_table_page *old;
entry = p->entry;
@@ -73,33 +92,36 @@
void __pollwait(struct file * filp, wait_queue_head_t * wait_address, poll_table *p)
{
- struct poll_table_page *table = p->table;
-
- if (!table || POLL_TABLE_FULL(table)) {
- struct poll_table_page *new_table;
+ struct poll_table_entry * entry;
- new_table = (struct poll_table_page *) __get_free_page(GFP_KERNEL);
- if (!new_table) {
- p->error = -ENOMEM;
- __set_current_state(TASK_RUNNING);
- return;
+ if(p->nr < POLL_TABLE_INTERNAL) {
+ entry = p->internal+p->nr++;
+ } else {
+ struct poll_table_page *table = p->table;
+
+ if (!table || POLL_TABLE_FULL(table)) {
+ struct poll_table_page *new_table;
+
+ new_table = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!new_table) {
+ p->error = -ENOMEM;
+ __set_current_state(TASK_RUNNING);
+ return;
+ }
+ new_table->entry = new_table->entries;
+ new_table->next = table;
+ p->table = new_table;
+ table = new_table;
}
- new_table->entry = new_table->entries;
- new_table->next = table;
- p->table = new_table;
- table = new_table;
- }
-
- /* Add a new entry */
- {
- struct poll_table_entry * entry = table->entry;
+ entry = table->entry;
table->entry = entry+1;
- get_file(filp);
- entry->filp = filp;
- entry->wait_address = wait_address;
- init_waitqueue_entry(>wait, current);
- add_wait_queue(wait_address,>wait);
}
+ /* Add a new entry */
+ get_file(filp);
+ entry->filp = filp;
+ entry->wait_address = wait_address;
+ init_waitqueue_entry(>wait, current);
+ add_wait_queue(wait_address,>wait);
}
#define __IN(fds, n) (fds->in + n)
@@ -233,14 +255,18 @@
return retval;
}
-static void *select_bits_alloc(int size)
+#define SELECT_INLINE_BYTES32
+static inline void *select_bits_alloc(int size, void* internal)
{
+ if(size <= SELECT_INLINE_BYTES)
+ return internal;
return kmalloc(6 * size, GFP_KERNEL);
}
-static void select_bits_free(void
reiserfs patch for 2.4.0-final
On Thu, Jan 04, 2001 at 04:52:49PM -0500, Chris Mason wrote: > This patch is meant to be applied on top of the reiserfs > 3.6.23 patch to get everything working in the new prerelease > kernels. The order is: > > untar linux-2.4.0-prerelease.tar.bz2 > apply linux-2.4.0-test12-reiserfs-3.6.23.gz > apply this patch > apply the fs/super.c patch to make sure fsync_dev is called > when unmounting /. This was already sent to l-k, I'll send > to the reiserfs list as well. Is this still correct for the final 2.4.0-kernel ? Could someone create one single patch for the 2.4.0 ? Bye, Claas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
Mark Hahn wrote: > > I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to > ... > > afraid that this may partialy criple 2.2 driver development. > > egads! how can there be "development" on a *stable* kernel line? > > maybe this is the time to reconsider terminology/policy: > does "stable" mean "bugfixes only"? > or does it mean "development kernel for conservatives"? It means development kernel for those who don't have enough time to debug the main kernel as well as their own project. The stable branch tends to be *far* better documented than the bleeding edge branch. Try to find documentation on the all-important page cache, for example. It makes a whole lot of sense to develop in the stable branch, especially for new kernel developers, providing, of course, that the stable branch has the basic capabilities you need for your project. Alan isn't telling anybody which branch to develop in - he's telling people what they have to do if they want their code in his tree. This means that when you develop in the stable branch you've got an extra step to do at the end of your project: port to the unstable branch. This only has to be done once and your code *will* get cleaned up a lot in the process. (It's amazing how the prospect of merging 500 lines of rejected patch tends to concentrate the mind.) I'd even suggest another step after that: port your unstable version back to the stable branch, and both versions will be cleaned up. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Update of quota patches
> and added a few comments. I also fixed compilation problems > (when quota was disabled) - Alan, were there any problems > I didn't fix (I've seen you and someone else were fixing some AFAIK the only reported problem was the compile with no quotas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: agpgart problem on 2.4.0-ac1
> wanted to try the latest stuff, but X fails to start now. Yep > dmesg part: > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 93M > agpgart: agpgart: Detected an Intel i815 Chipset. > Unable to handle kernel NULL pointer dereference at virtual address > I broke agpgart. It will be cured (I hope) in -ac2 coming soon. That bug is also one in -ac1 so its not in the Linus tree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
> Unless Stephen says otherwise, my understanding is that a crash during > journal recovery will just mean the journal is replayed again at the next > recovery. Because the ext3 journal is just a series of data blocks to > be copied into the filesystem (rather than "actions" to be done), it > doesn't matter how many times it is done. The recovery flags are not > reset until after the journal replay is completed. Which means an ext3 volume cannot be recovered on a hard disk error. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
> No. 2.2.* handles large drives since 2.2.14. > This looks more like you used the jumper to clip the drive to 32GB. > Don't use it and get full capacity. > If your BIOS hangs when it sees such a large drive so that you > cannot avoid using the jumper, use setmax in your boot scripts, > or use a kernel patch that does the same at kernel boot time. > > >> Looks like some short int (2 bytes) overflowing. I'll try the ide patches. > > The overflow is in certain BIOSes, not in Linux. > (You see in the above: 65531 is not an overflow value.) The number after clipping was actual - 2^16. Was the reason I was thinking the kernel was playing games. After applying IDE patches the idesetmax message showed up :) > > I had to recompile fdisk as my old suse 6.4 version got the same > > 2byte-wraparound problem. > > In the good old days the HDIO_GETGEOM ioctl would give you the disk > geometry. It has a short for cylinders and hence overflows when C > gets above 65535. Since geometry is on its way out - indeed, there has > not been any such thing for many, many years - it would have been > nonsense to introduce new ioctls that report meaningless 32-bit numbers > instead of the present meaningless 16-bit number. > So, instead, the "cylinder" field in the output of this ioctl has been > declared obsolete, and is not used anymore. Programs that want to print > some value, just because they always did and users expect something, > now use BLKGETSIZE to get total size and divide by heads*sectors > to get a cylinder value. > (But again: this cylinder value is not used anywhere, the computed value > is just for the user's eyes.) all is block adressed indeed.. I need to look at fdisk, because it is doing things wrong. The other machine's BIOS can handle 64 GB wihout problems, so I can run without clipping in that machine. Linux sees the correct size, but fdisk still sees 32 GB. Probably a recompile / upgrade. > Andries Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Update of quota patches
Hello. So I've updated my quota patches for 2.4.0-prerelease. I also fixed one locking bug in implementation of new quotafile format and added a few comments. I also fixed compilation problems (when quota was disabled) - Alan, were there any problems I didn't fix (I've seen you and someone else were fixing some compilation problems with my patches in -ac but I've seen no mail about it (maybe I just missed it))? The patches can be downloaded from: ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ as quota-fix-2.4.0-pre-1.diff and quota-patch-2.4.0-pre-1.diff. Contents of patches: quota-fix: This patch mainly fixes bugs in current quota code: * races between preallocation and chgrp/chown fixed * cleaned up locking * quotas are dynamically allocated (so there are no more 'No free dquots' messages) quota-patch: This patch implements new quotafile format. It allows: * accounting of quota in bytes * 32-bit UIDs/GIDs * root is no longer special user Note that you will need new quota utilities for new quotafile format (you can download them at ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/quota-3.00-4.tar.gz). Also note that quota-patch requires quota-fix to be already applied. Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.0 drivers/atm/Makefile...
...is still broken. It does not build Fore 200e driver. Jan --- linux/drivers/atm/Makefile.orig Tue Jan 2 10:18:25 2001 +++ linux/drivers/atm/Makefile Tue Jan 2 12:00:05 2001 @@ -46,7 +46,7 @@ endif endif -obj-$(CONFIG_ATM_FORE200E) += fore200e.o $(FORE200E_FW_OBJS) +obj-$(CONFIG_ATM_FORE200E) += fore_200e.o include $(TOPDIR)/Rules.make -- Jan Rkorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dcache 2nd chance replacement
On Thu, 4 Jan 2001, Alan Cox wrote: > > On Thu, Jan 04, 2001 at 02:59:49PM -0200, Rik van Riel wrote: > > > Unfortunately you seem to ignore my arguments, so lets > > I've not ignored them, as said they were either obviously wrong of offtopic. > > Would the two of you ajourn this debate to alt.flame Better still stop _theorizing_ and start _measuring_ Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Hi, On Fri, Jan 05, 2001 at 02:01:37AM +0100, Stefan Traby wrote: > > Please tell me how to specify "noreplay" for the initial "/" mount > :) You don't have to: the filesystem knows when a root mount is happening, and can do the extra work then to make sure that the mount isn't failed on a readonly media. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
[EMAIL PROTECTED] said: > Powering down a VCR whilst recording can damage the tape or even > worse have the tap get jammed in the video. I have also had a TV die > because it was unpowered from the mains without being switched off > first. > Sure, these things don't always happen -- but they sometimes do. I > would argue things like VCRs and TVs are just more tolerant than more > complex systems -- not immune. The reasoning here seems to be that because many other systems break under these circumstances, we shouldn't bother to make Linux reliable. I don't quite understand that way of thinking. I will continue to test the boards I work on with random power cycles and to consider the filesystem broken if it doesn't like that treatment. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
[EMAIL PROTECTED] said: > In what way? A root fs readonly mount is usually designed to prevent ^^^ > the filesystem from being stomped on during the initial boot so that > fsck can run without the filesystem being volatile. That's the only > reason for the readonly mount: to allow recovery before we enable > writes. With ext3, that recovery is done in the kernel, so doing that > recovery during mount makes perfect sense even if the user is mounting > root readonly. Alternative reasons for readonly mount include "my hard drive is dying and I don't want _anything_ to write to it because it'll explode". You mount it read-only, recover as much as possible from it, and bin it. You _don't_ want the fs code to ignore your explicit instructions not to write to the medium, and to destroy whatever data were left. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
On Thu, 4 Jan 2001, Nicholas Knight wrote: > While I understand the reasoning behind this, and might do the > same thing if I was in your position, I feel it may be a > mistake. I personaly do not trust the 2.4.x kernel entirely yet, > and would prefer to wait for 2.4.1 or 2.4.2 before upgrading > from 2.2.18 to ensure last-minute wrinkles have been completely > ironed out, This is *exactly* why Alan's policy change makes sense. If somebody submits a driver bugfix or update for 2.2, but not for 2.4, it'll take FOREVER for 2.4 to become as "trustable" as 2.2... This change, however, will make sure that 2.4 will be as reliable as 2.2 much faster. Unlike 2.2, the core kernel of 2.4 is reliable ... only the peripheral stuff like drivers may be out of date or missing. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How can I create root disk in Redhat 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike wrote: > Hi !! > > When i boot linux from rescue disk, i get following message: > > VFS: Insert root floppy disk to be loaded in RAM disk and press ENTER > > Now how can i create a root disk... I am trying to boot Redhat 6.0 > > > Regards, > Mike > man mkbootdisk Basically you do mkbootdisk version-number-of-your-kernel Sometimes with the addition of --device /dev/fd0 as this: mkbootdisk --device /dev/fd0 version-number-of-your-kernel The kernel version you are running can be seen by doing: uname -a /Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6VbI8USLExYo23RsRAiW4AKCo7Bg+TpLth1a2OOWFV0VvWyClHwCfUp3f HEnQVOnAJYu1N0D2ZWJBLsg= =nYhZ -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Can I submit a bug report on this mailing list?
On Thu, 4 Jan 2001, Evan Thompson wrote: > I hear about the 2.4.0 release. I have, in my mailbox, many > messages titled "Re: And oh, btw...", BUT NO ORIGINAL MESSAGE! > What happened? Is my stupid mailserver selective or something? > > Anyways. My bug report is: "[EMAIL PROTECTED] does > not send me important mails that are important and that should > be sent due to their high importancy." Says the guy who reads his linux-kernel email on bigfoot.com ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How can I create root disk in Redhat 6.0
Mike, there are docs named HOWTO-. There is also one about boot/root disks. I recommend you to boot from redhat instalation CD and after launch pres Alt-F2 (or F3,4... a can't remember) to get into free console with bash prompt. Then mount your hacked(TM) disk and try to repair. devik > When i boot linux from rescue disk, i get following message: > VFS: Insert root floppy disk to be loaded in RAM disk and press ENTER > Now how can i create a root disk... I am trying to boot Redhat 6.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
Hi, On Fri, Jan 05, 2001 at 12:06:47AM -0700, Andreas Dilger wrote: > Stephen, you write: > > On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote: > > > BTW, what inumber do you want for whiteouts? IIRC, we decided to use > > > the same entry type as UFS does (14), but I don't remember what was > > > the decision on inumber. UFS uses 1 for them, is it OK with you? > > > > 0 is used for padding, so 1 makes sense, yes. > > Sorry, but what are whiteouts? Inode 1 in ext2 is the bad blocks inode, > so it will never be used for a valid directory entry, but depending on > what it is we may want to make sure e2fsck is OK with it as well. Whiteouts are used for union filesystems, where you layer one filesystem over another so that all modifications are made in the "upper" layer, but unmodified files stay in the "lower" layer. That way, you can layer an empty filesystem on top of some other directory and get what is essentially a free snapshot of that directory. In such a scheme, whiteouts are used if you unlink a file from the union mount. The lower-layered filesystem is effectively readonly as far as the union is concerned, so we record the unlink by adding a whiteout entry in the upper filesystem. A lookup for that name in the union filesystem will find the whiteout and will return ENOENT immediately without looking to see if the entry exists in the lower filesystem. We still need to return the whiteouts to user space for getdents(), though: union filesystems normally deal with readdir() by reading the whole set of dentries into user space and sorting them there, so the whiteout is semantically significant to getdents(). Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: agpgart problem on 2.4.0-ac1
> EIP: 0010:[<>] > Call Trace: [] [] [] [] > [] [] [] > [] [] [] > > Code: Bad EIP value. Could you parse your oops through ksymoops? Probably someone called an uninitialized function pointer, or there was a stack overrun. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IEEE1394 2.4.0 (final) compile problems
In article <[EMAIL PROTECTED]> you wrote:
> video1394.o(.data+0x0): multiple definition of `ohci_csr_rom'
> ohci1394.o(.data+0x0): first defined here
Known bug, fix attached below.
Greetings,
Arjan van de Ven
diff -urN /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.c
linux/drivers/ieee1394/ohci1394.c
--- /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.cThu Jan 4
10:10:00 2001
+++ linux/drivers/ieee1394/ohci1394.c Thu Jan 4 17:32:30 2001
@@ -112,6 +112,80 @@
#define DBGMSG(card, fmt, args...)
#endif
+/* This structure is not properly initialized ... it is taken from
+ the lynx_csr_rom written by Andreas ... Some fields in the root
+ directory and the module dependent info needs to be modified
+ I do not have the proper doc */
+quadlet_t ohci_csr_rom[] = {
+/* bus info block */
+0x0404, /* info/CRC length, CRC */
+0x31333934, /* 1394 magic number */
+0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
+0x, /* vendor ID, chip ID high (written from card info) */
+0x, /* chip ID low (written from card info) */
+/* root directory - FIXME */
+0x0009, /* CRC length, CRC */
+0x03080028, /* vendor ID (Texas Instr.) */
+0x8109, /* offset to textual ID */
+0x0c000200, /* node capabilities */
+0x8d0e, /* offset to unique ID */
+0xc710, /* offset to module independent info */
+0x0400, /* module hardware version */
+0x8126, /* offset to textual ID */
+0x0900, /* node hardware version */
+0x8126, /* offset to textual ID */
+/* module vendor ID textual */
+0x0008, /* CRC length, CRC */
+0x,
+0x,
+0x54455841, /* "Texas Instruments" */
+0x5320494e,
+0x53545255,
+0x4d454e54,
+0x5300,
+/* node unique ID leaf */
+0x0002, /* CRC length, CRC */
+0x08002856, /* vendor ID, chip ID high */
+0x083E, /* chip ID low */
+/* module dependent info - FIXME */
+0x0006, /* CRC length, CRC */
+0xb806, /* ??? offset to module textual ID */
+0x8104, /* ??? textual descriptor */
+0x, /* SRAM size */
+0x, /* AUXRAM size */
+0x, /* AUX device */
+/* module textual ID */
+0x0005, /* CRC length, CRC */
+0x,
+0x,
+0x54534231, /* "TSB12LV22" */
+0x324c5632,
+0x3200,
+/* part number */
+0x0006, /* CRC length, CRC */
+0x,
+0x,
+0x39383036, /* "9806000-0001" */
+0x3030342d,
+0x30303431,
+0x2001,
+/* module hardware version textual */
+0x0005, /* CRC length, CRC */
+0x,
+0x,
+0x5453424b, /* "TSBKOHCI403" */
+0x4f484349,
+0x34303300,
+/* node hardware version textual */
+0x0005, /* CRC length, CRC */
+0x,
+0x,
+0x54534234, /* "TSB41LV03" */
+0x314c5630,
+0x3300
+};
+
+
/* print general (card independent) information */
#define PRINT_G(level, fmt, args...) \
printk(level "ohci1394: " fmt "\n" , ## args)
diff -urN /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.h
linux/drivers/ieee1394/ohci1394.h
--- /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.hThu Jan 4
10:10:00 2001
+++ linux/drivers/ieee1394/ohci1394.h Thu Jan 4 17:32:15 2001
@@ -280,74 +280,7 @@
the lynx_csr_rom written by Andreas ... Some fields in the root
directory and the module dependent info needs to be modified
I do not have the proper doc */
-quadlet_t ohci_csr_rom[] = {
-/* bus info block */
-0x0404, /* info/CRC length, CRC */
-0x31333934, /* 1394 magic number */
-0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
-0x, /* vendor ID, chip ID high (written from card info) */
-0x, /* chip ID low (written from card info) */
-/* root directory - FIXME */
-0x0009, /* CRC length, CRC */
-0x03080028, /* vendor ID (Texas Instr.) */
-0x8109, /* offset to textual ID */
-0x0c000200, /* node capabilities */
-0x8d0e, /* offset to unique ID */
-0xc710, /* offset to module independent info */
-0x0400, /* module hardware version */
-0x8126, /* offset to textual ID */
-0x0900, /* node hardware version */
-0x8126, /* offset to textual ID */
-/* module vendor ID textual */
-0x0008, /* CRC length, CRC */
-0x,
-0x,
-0x54455841, /* "Texas Instruments" */
-0x5320494e,
-0x53545255,
-0x4d454e54,
-
Re: Network oddity....
Interesting, yesterday I have TCP problems with my three independent systems. They all acts as simple firewalls with MASQ. Yesterday they all suddenly stopped responding to ssh TCP connections to IP on eth1 (internal net) but they continued to work on IP attached to eth0 and lo. The problem survived reboot. Then it suddenly ceased and I can't trigger it again. Kernels was 2.2.13, 2.2.16 and 2.2.17 and the systems was completely unrelated. Kind of woodoo or what ... devik > Oh, this situation seems to continue: it sends a syn-ack and then the > client replies with a reset. This goes on and on. I'm going to make > the client disappear, and hope that this makes the number of these > connections go away. > > Kernel is 2.2.13. That was "fresh" when the system was booted. Yes, > that's over 14 months ago. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
subscrive
> Cícero Clarindo Campelo Neto > Analista de Suporte, MCSE > Departamento de Suporte > Lanlink Informática Ltda > * (0xx85) 466-8004 > [EMAIL PROTECTED] > http://www.lanlink.com.br > > Serviço de Atendimento ao Cliente: > * (85) 0800-85-0800 > [EMAIL PROTECTED] > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lvm: hw error or misconfig?
Dear developers! (sorry for the long mail) We have a compaq proliant server with NO raid and 5 scsi discs: Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: COMPAQ Model: BD00911934 Rev: 3B02 Type: Direct-AccessANSI SCSI revision: 02 bounded together to a volume group vg00. This morning we received this strange message, and a file is not readable anymore. It is i/o error-ed. unfort. this caused loosing important data. Jan 5 11:30:21 matrix kernel: attempt to access beyond end of device Jan 5 11:30:21 matrix kernel: 08:31: rw=0, want=8883914, limit=8883913 Jan 5 11:30:21 matrix kernel: dev 3a:00 blksize=1024 blocknr=8551735 sector=17767820 size=4096 count=1 Does it mean that some of the disks are hw errored or is it a misconfiguration, error in lvm or kernel code? How could I check the disks while they are in live work? It would be a big pain to stop the system and reformat the drives, so on. any idea? kernel 2.2.17, lvm 0.8i a la debian woody. thanks for your help, and hoping for fast answer Narancs v1 - cat /proc/scsi/sym53c8xx/0 General information: Chip sym53c876, device id 0xf, revision id 0x14 IO port address 0x2000, IRQ number 23 Using memory mapped IO at virtual address 0xe0800f00 Synchronous period factor 12, max commands per lun 32 vgdisplay -v --- Volume group --- VG Name vg00 VG Access read/write VG Status available/resizable VG # 0 MAX LV256 Cur LV1 Open LV 1 MAX LV Size 255.99 GB Max PV256 Cur PV5 Act PV5 VG Size 41.1 GB PE Size 4 MB Total PE 10521 Alloc PE / Size 10521 / 41.1 GB Free PE / Size 0 / 0 --- Logical volume --- LV Name /dev/vg00/oracle VG Name vg00 LV Write Access read/write LV Status available LV # 1 # open1 LV Size 41.1 GB Current LE10521 Allocated LE 10521 Allocationnext free Read ahead sectors120 Block device 58:0 --- Physical volumes --- PV Name (#) /dev/sda3 (1) PV Status available / allocatable Total PE / Free PE2061 / 0 PV Name (#) /dev/sdb2 (2) PV Status available / allocatable Total PE / Free PE2061 / 0 PV Name (#) /dev/sdc2 (3) PV Status available / allocatable Total PE / Free PE2061 / 0 PV Name (#) /dev/sdd1 (4) PV Status available / allocatable Total PE / Free PE2169 / 0 PV Name (#) /dev/sde1 (5) PV Status available / allocatable Total PE / Free PE2169 / 0 cat /etc/fstab # /etc/fstab: static file system information. # # /dev/sda2 / ext2defaults,errors=remount-ro 01 /dev/sda1 noneswapsw 0 0 /dev/sdb1 noneswapsw 0 0 /dev/sdc1 noneswapsw 0 0 proc/proc procdefaults00 /dev/fd0/floppy autodefaults,user,noauto00 /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 00 /dev/vg00/oracle /u01 ext2defaults0 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: INIT: No inittab file found
I tried linux single but it says " no such image" Actually someone hacked my linux box and now i can't boot it. Can somone help me. "J . A . Magallon" wrote: > On 2001.01.04 Mike wrote: > > Hi, > > > > I am unable to boot my linux. I got the following message during boot. > > > > > > INIT: No inittab file found > > INIT: Can't open(/etc/ioctl.save, O_WRONLY): No such file or directory > > > > Enter Runlevel: > > = > > > > Try answering 'single'. That boots into 'single user mode': no > daemons, no try to load inittab. Just a shell to let you check if > there exists an /etc/inittab file. > > -- > J.A. Magallon $> cd pub > mailto:[EMAIL PROTECTED] $> more beer > > Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
How can I create root disk in Redhat 6.0
Hi !! When i boot linux from rescue disk, i get following message: VFS: Insert root floppy disk to be loaded in RAM disk and press ENTER Now how can i create a root disk... I am trying to boot Redhat 6.0 Regards, Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where to get quota.
Hello. > Perhaps the help text for disk quotas needs to be updated, or at least the > howto for quotas. > > The help text for disk quotas says to see the Quota mini-HOWTO. The howto > says to get the quota source from: > > ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/subsystems/quota/all.tar.gz > > That doesn't exist anymore. You can get newest quota utilities (I'm expecting you want utils for old quotafile format) at 'ftp://ftp.cistron.nl/pub/people/mvw/quota/quota-2.00-pre11.tar.gz' > I'm just looking for a quick pointer to the quota source, but also > suggesting that maybe the help text should be updated. Or if someone > points me in the right direction, I'll write to the author of the howto. Sorry... I don't know who's the author. Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: So, what about kwhich on RH6.2?
On Thu, 4 Jan 2001, Albert D. Cahalan wrote: can't we just hardwire `kgcc' into the build system and be done with all this kwhich stuff? It's just a symlink >>> >>> And break compilation on all non RedHat 7, non connectiva systems ? >>> Would you volunteer to handle the support load on l-k that would cause? >> >> Hardcoding kgcc is definitely not an option. > >Creating symlinks during the build would solve the problem. > >/usr/src/linux/kern-cc -> /usr/bin/kgcc >/usr/src/linux/user-cc -> /usr/bin/gcc But who builds kernels in /usr/src anymore, or as root for that matter... ;o) -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- If at first you don't succeed, call it version 1.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
compile error on 2.4.0
Hi, gcc -D__KERNEL__ -I/usr/src/linux-2.4.0/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i586 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.0/include/linux/modversions.h -c -o r128_cce.o r128_cce.c r128_cce.c: In function `r128_cce_init_ring_buffer': r128_cce.c:339: structure has no member named `agp' r128_cce.c:333: warning: `ring_start' might be used uninitialized in this function r128_cce.c: In function `r128_cce_packet': r128_cce.c:1023: warning: unused variable `size' r128_cce.c:1021: warning: unused variable `buffer' r128_cce.c:1019: warning: unused variable `dev_priv' make[3]: *** [r128_cce.o] Error 1 .config file on request... regards, chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: modutils 2.4.0 is available
On Fri, Jan 05, 2001 at 12:48:04PM +0600, Anuradha Ratnaweera wrote: > Why not DEB? Because Keith doesn't have a Debian system? He just provides the rpms as a service, he doesn't have to do that. Install the "alien" package on your machine and you will be able to convert between rpm and deb. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Hi, On Fri, Jan 05, 2001 at 01:31:12AM +0100, Daniel Phillips wrote: > "Stephen C. Tweedie" wrote: > > > Yes, and so long as your journal is not on another partition/disk things > will eventually be set right. The combination of a partially updated > filesystem and its journal is in some sense a complete, consistent > filesystem. Right. > I'm curious - how does ext3 handle the possibility of a crash during > journal recovery? Recovery comes in two parts: replay of the log, and deletion of orphaned inodes. The log replay is fully idempotent: it just consists of writing the appropriate log blocks to their home locations on disk. It doesn't matter if you do those writes once, twice or a hundred times, you still get the same result, so crashing mid-recovery and starting again from scratch is perfectly safe. Once that recovery is done, the filesystem is marked, atomically, to be clean. Secondly, we do the deletion of orphaned inodes. By this time, the journal itself has been recovered so we are journaling our operations, so each orphaned inode delete is being logged. A crash will recover to a consistent state via the normal journaling transaction methods, and will restart orphan recovery from where it left off. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
agpgart problem on 2.4.0-ac1
Dear all!
wanted to try the latest stuff, but X fails to start now.
dmesg part:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 93M
agpgart: agpgart: Detected an Intel i815 Chipset.
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
*pde =
Oops:
CPU:0
EIP:0010:[<>]
EFLAGS: 00010246
eax: ebx: c8827000 ecx: c020da88 edx: 0001
esi: edi: ebp: esp: c78a1f04
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 61, stackpage=c78a1000)
Stack: c8829bb0 c8827000 c8827068 3fd0 c8829d50
c882aa00
0063 c8827000 c01156cd c78a bfffc3a4 bfffc3a4
bfffc364
3b67 c779a000 0060 c779b000 ffea 0007 c1253460
0060
Call Trace: [] [] [] []
[] [] []
[] [] []
Code: Bad EIP value.
lsmod
Module Size Used by
nls_cp850 3584 2 (autoclean)
nls_iso8859-2 3360 2 (autoclean)
smbfs 31056 2 (autoclean)
floppy 45296 0 (autoclean)
serial 43312 1 (autoclean)
isa-pnp27600 0 (autoclean) [serial]
ide-cd 26288 0
cdrom 26720 0 [ide-cd]
softdog 1472 0 (unused)
agpgart16336 1 (initializing)
8139too14784 1
rtc 5248 0
ipchains 30848 0 (unused)
I hope you'll fix it soon.
Köszönettel
Narancs v1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
why getch() cann't work in rpm package's %post section?
a program using getch() function (included in curses.h) runs OK when it executes in system prompt. when I put it in rpm package's %post section, it can start running until getch() statement. press any key to test getch(), getch() has no response! Can anybody tell me how to resolve this problem? thanks very much. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How to Power off with ACPI/APM?
On 2001.01.05 Dominik Kubla wrote: > On Fri, Jan 05, 2001 at 10:18:46AM +0100, J . A . Magallon wrote: > > > > Silly question, but have you realized that you don't have to enable > > SMP in kernel to do multithreading ? > > > > That depends on your definition: If you really want to run multiple > threads simultaneously (as opposed to concurrent i guess) i imagine > you will either need more than one CPU or one of those new beasties > which support multiple threads in parallel on their various execution > units... > Nope. You can run multiple threads "simultaneously" on an uniprocessor, so simultaneous as the rest of the processes the cpu is running. Of course the efficiency of multi-threading drops on an uni-processor if your threads only do hard math work and no IO, but a thread can be crunchin numbers at the same time one other is waiting for IO even on a one cpu box. Think on an app that does read-process-write in loop. Two parallel threads on an uniprocessor can overlap IO and process and be more efficient than a non-threaded version. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How to Power off with ACPI/APM?
On 2001.01.05 Michael D. Crawford wrote: > > In my own work I mostly do multithreaded software development and I just sort > of > felt like it would be good karma to enable it even if my machine didn't > support > it. Go figure. So this was mostly a user error, although I guess I've been > helpful in discovering the current interaction of ACPI and APM. > Silly question, but have you realized that you don't have to enable SMP in kernel to do multithreading ? -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
IEEE1394 2.4.0 (final) compile problems
# IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c ieee1394_syms.c ld -m elf_i386 -r -o ieee1394.o ieee1394_core.o ieee1394_transactions.o hosts.o highlevel.o csr.o guid.o ieee1394_syms.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-c -o ohci1394.o ohci1394.c ohci1394.c:152: warning: `ohci1394_pci_tbl' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o video1394.o video1394.c video1394.c:1229: warning: `video1394_fops' defined but not used video1394.c:1239: warning: `video1394_init' defined but not used video1394.c:1277: warning: `remove_card' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o raw1394.o raw1394.c rm -f ieee1394drv.o ld -m elf_i386 -r -o ieee1394drv.o ieee1394.o ohci1394.o video1394.o raw1394.o video1394.o(.data+0x0): multiple definition of `ohci_csr_rom' ohci1394.o(.data+0x0): first defined here make[3]: *** [ieee1394drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 [root@thud linux]# - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Adding devices to dc2xx.c
Hello, and thank you to those who responded to my query about adding my
Agfa ePhoto to the USB mass storage device database. I had no success
with this (the machine locked hard on connecting the device), so I have
decided to try it with the dc2xx driver.
I have added it to /usr/src/linux/drivers/usb/dc2xx.c as follows:
..
{ idVendor: 0x040a, idProduct: 0x0112 },// Kodak DC-290
{ idVendor: 0xf003, idProduct: 0x6002 },// HP PhotoSmart C500
{ idVendor: 0x06bd, idProduct: 0x0403 },// Agfa ePhoto CL18
..
However, after I recompile and reboot with the new boot image, I receive
the following:
..
Jan 5 19:37:33 localhost kernel: usb.c: registered new driver dc2xx
..
Jan 5 19:37:33 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 2
Jan 5 19:37:33 localhost kernel: usb.c: USB device 2 (vend/prod
0x6bd/0x403) is not claimed by any active driver.
..
Why is dc2xx not being associated with the camera? I note that the vendor
and product names of the camera omit the leading '0', but I have tried
adding
them to the driver file as both '0x06bd' and '0x6bd' and neither works. I'm
using 2.4.0-prerelease, in case that helps.
So, does this sound like a bug with the above driver, or is there something
that I've missed?
--
Alastair Foster
Note new email address => [EMAIL PROTECTED]
http://users.netaccess.co.nz/ala/
021 250 6482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
System Crash Kernel 2.4.0-test12 and 2.4.0-pre with XFree 4.0.2
Hi,
[1.] One line summary of the problem:
my System hangs up if I have a high load and if I use XFree.
[2.] Full description of the problem/report:
I'm using XFree 4.0.2 on a Vodoo3 2000 Graphics Board.
If I'm booting 2.4.0-test10 it works fine.
If I'm booting 2.4.0-test12 or pre my System Crashes if
I use multimedia applications like gkrellm, mtv, xmms
and do some downloads.
[3.] Keywords (i.e., modules, networking, kernel):
2.4.0 test12 pre crash XFree Vodoo
[4.] Kernel version (from /proc/version):
Linux version 2.4.0-prerelease (root@BOFH) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #4 Thu Jan 4 20:41:18 /etc/localtime 2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
[6.] A small shell script or example program which triggers the
problem (if possible)
wget -c -r ftp.kernel.org &
wget -c -r blafasel.lan &
mtv test.mpg &
gkrellm
( just wait and work :-) )
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 350.803
cache size : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips: 699.59
[7.3.] Module information (from /proc/modules):
cs4232 3024 1
ad1848 17216 0 [cs4232]
uart401 6448 0 [cs4232]
sound 57616 1 [cs4232 ad1848 uart401]
soundcore 3952 4 [sound]
bttv 56848 0 (unused)
msp340013328 0 (unused)
tuner 3280 1
i2c-algo-bit7232 1 [bttv]
i2c-dev 3904 0 (unused)
i2c-core 12656 0 [bttv msp3400 tuner i2c-algo-bit i2c-dev]
videodev4576 2 [bttv]
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
/proc/ioports:
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
02f8-02ff : serial(auto)
0340-035f : eth1
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0530-0533 : Crystal audio controller
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
5000-50ff : VIA Technologies, Inc. VT82C586B ACPI
d000-dfff : PCI Bus #01
d000-d0ff : 3Dfx Interactive, Inc. Voodoo 3
e000-e00f : VIA Technologies, Inc. Bus Master IDE
e000-e007 : ide0
e008-e00f : ide1
e800-e8ff : Macronix, Inc. [MXIC] MX987x5
e800-e8ff : eth0
/proc/iomem:
-0009fbff : System RAM
0009fc00-0009 : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07fe : System RAM
0010-002fe60f : Kernel code
002fe610-0031c983 : Kernel data
07ff-07ff2fff : ACPI Non-volatile Storage
07ff3000-07ff : ACPI Tables
e000-e3ff : PCI Bus #01
e000-e1ff : 3Dfx Interactive, Inc. Voodoo 3
e400-e5ff : PCI Bus #01
e400-e5ff : 3Dfx Interactive, Inc. Voodoo 3
e600-e6ff : VIA Technologies, Inc. VT82C597 [Apollo VP3]
e800-e8ff : Macronix, Inc. [MXIC] MX987x5
e800-e8ff : eth0
e8001000-e8001fff : Brooktree Corporation Bt848 TV with DMA push
e8001000-e8001fff : bttv
- : reserved
[7.5.] PCI information ('lspci -vvv' as root)
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IDE-CD Model: R/RW 4x4x32 Rev: 1.10
Type: CD-ROM ANSI SCSI revision: 02
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
dmesg:
Linux version 2.4.0-prerelease (root@BOFH) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #4 Thu Jan 4 20:41:18 /etc/localtim
e 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (usable)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 0001 @ (reserved)
BIOS-e820: 07ef @ 0010 (usable)
BIOS-e820: d000 @ 07ff3000 (ACPI data)
BIOS-e820: 3000 @ 07ff (ACPI NVS)
Scan SMP from c000 for 1024 bytes.
Scan SMP from
Memory Corruption
This message has a couple of questions to it, so maybe a few people might want to contribute to answering them all. My apologies in advance for the long length of this post. The Problem: I have an Alpha PC164 with 512 Meg of memory. As a friend and I were setting it up, we tried to compile mozilla. At some point during the install, a repeating error would scroll by the screen so fast that we could not read it. From what we could pick out, we determined that the error was memory related. We deduced that since compiling mozilla would fill the entire bank of memory, once gcc (or whatever directly writes to memory) tried to address the bad area of memory, gcc would produce the error. Also, after trying to recompile mozilla a number of times, the error would be at a random point, usually after about 15 or 20 minutes of compiling. From this information, we hazard to guess that one of the eight 64 Meg SIMMS was bad, or contained a bad area. Therefore, we removed the last 4 of the 8 modules, and the error never occurred. The suggested solution: We plan to swap out the 4 of the 4 remaining modules with the 4 that we removed earlier, one at a time, and try to compile mozilla, since it will fill all of the memory. Then, hopefully, we can rotate the modules to find the one that contains the bad area. We are not quite sure what to do from there. Here are our ideas: 1. One suggestion I made was to create a ram drive over the last 64 Meg of addressable memory, the simply not read or write to the drive. Is that even possible? Can I tell the kernel to create a ram drive over a certain area of memory? 2. Another idea I had was to tell the kernel to only use a certain size of memory, with a modification to lilo.conf: append="mem=448m" since 512(the total memory) - 64(the size of the module) = 448Meg. Will this work? Any ideas? Another question: We are not sure if the memory is ECC or not, but we think that there is a good chance of it. Are there any kernel optimizations that can be made so that the kernel can map out the bad memory and mark it so that it cant be used? The machine is booted from an SRM prompt, if that helps. Please let me know if anyone had any ideas on these problems. Thanks in advance to all those out there who took the time to read this. --Ryan Sizemore - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
Michael D. Crawford wrote: > You might think this is great because of all the extra testing the new users > will do but I assert that it isn't. The environment for Linux is quite > different these days than when 2.2 or 2.0 were released. > > A lot of the people who will be using it are not technically savvy people, and > many of those who do know technology depend on its reliability for the > profitability of large businesses but may not read Linus' message that indicates > this is really just for testing. Alan's comments were addressed to driver developers, not users. It's driver developers who need to work with Alan to make sure he doesn't have to now do twice as much work as he used to (BTW: I think this is a mental and physical impossibility). The distros will ship 2.4.0 kernels whenever they want to, which will probably be when they think there are no major gotchas in it. If I remember correctly, when 2.2.0 was released, a similar process took place. Alan helped get patches into the 2.0 kernel tree for a while. When the 2.3.0 tree was opened up, Linus' attention shifted completely to that new development tree. That left Alan to take up the slack by becoming the maintainer of the 2.2 tree. Very shortly after Alan moved onto the 2.2 tree, he announced that the vast amount of his work would be focussed there and not on the 2.0 tree. As far as I know, 2.0 to 2.2 transition went really quite smoothly, so this process must be working. I would suggest that if you are writing drivers for the 2.2 tree, that you just work with Alan and make sure your code is also in the 2.4 tree. Alan's doing you a favor by clearly spelling out what he can reasonably be expected to accomplish. If he over- estimated his ability to process code changes, we'd all be in a world of hurt and disappointment. As for users, their fate is in the hands of the distribution developers. It's the distribution developers' responsibility to ship good, solid code. If you are scared that they won't do a good job of that, I guess you'll want to wait for one of their later releases. Best wishes, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: modutils 2.4.0 is available
On Thu, Jan 04, 2001 at 11:30:57PM -0800, Greg KH wrote: > > Greg KH wrote: > > > > > > > I agree. I can set up a "linux-hotplug" group using SourceForge if ... > I'm only proposing SourceForge as I can set up a list easily there > easily, and I don't know the right people to ask to get it done on > vger.kernel.org :) The right one to ask is <[EMAIL PROTECTED]>, and somebody has already made that question there. Powers that be (DaveM) need to decide on it. I am also one of those postmaster persons, but DaveM decides things at the Majordomo subsystem. (And thus lists.) > Unless anyone objects in the next 10 hours, I'll try to create it, and > let everyone know about it. As you wish, I don't have ambitions either way. One thing though, NEVER configure list to modify through going message subjects any way what so ever. Doing that is just a sign of giving up on people who don't know how else they can recognize traffic thru given lists. (I leave it as an excercise to the reader to review full headers of this message in their mailbox, and see which RFC 822 defined headers they could use to recognize which list this message has gone thru. Some of you will receive this in several copies via different paths!) Such subject modifications lead to abominations like: [linux-usb-devel] Re: [linux-usb-devel] Re: [linux-usb-devel] ... People don't clean their outgoing Subject: headers anyway. > thanks, > greg k-h > -- > greg@(kroah|wirex).com /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: You've Been Slashdotted
I gather from the combination of what I read on Slashdot and what folks replied here that the mirrors are actually lightly loaded, but Slashdot readers don't know about them because they couldn't read the home page at http://www.kernel.org that directed them to the mirror list. So I posted the algorithm for calculating the URL to your nearest mirror on Slashdot. Maybe that'll help some Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.0-prerelease: preemptive kernel.
ludovic fernandez wrote:
>
> george anzinger wrote:
>
> > Roger Larsson wrote:
> > >
> >
> > > This part can probably be put in a proper non inline function.
> > > Cache issues...
> > > +/*
> > > +* At that point a scheduling is healthy iff:
> > > +* - a scheduling request is pending.
> > > +* - the task is in running state.
> > > +* - this is not an interrupt context.
> > > +* - local interrupts are enabled.
> > > +*/
> > > +if (current->need_resched == 1 &&
> > > + current->state == TASK_RUNNING &&
> > > + !in_interrupt()&&
> > > + local_irq_are_enabled())
> > > +{
> > > +schedule();
> > > +}
> > >
> > Actually the MontaVista Patch cleverly removes the tests for
> > in_interrupt() and local_irq_are_enabled() AND the state ==
> > TASK_RUNNING. In actual fact these states can be considered way points
> > on the system status vector. For example the interrupts off state
> > implies all the rest, the in_interrupt() implies not preemptable and
> > finally, not preemptable is one station away from fully preemptable.
> >
> > TASK_RUNNING is easily solved by makeing schedule() aware that it is
> > being called for preemption. See the MontaVista patch for details.
> >
>
> Humm, I'm just curious,
> Regarding in_interrupt(). How do you deal with soft interrupts?
> Guys calling cpu_bh_disable() or even incrementing the count on
> their own.
#define cpu_bh_disable(cpu) do { ctx_sw_off(); local_bh_count(cpu)++;
barrier(); } while (0)
#define cpu_bh_enable(cpu) do { barrier();
local_bh_count(cpu)--;ctx_sw_on(); } while (0)
I don't know if this acceptable but definitely can be done,
> I prefer to rely on fact than on API.
Yes, of course anything CAN be done, but then they would be SOL with the
movement of the flag location (as was done on the way from 2.3 to
2.4.0). If we encounter such problems, we just fix them.
> Regarding local_irq_enabled(). How do you handle the code that
> call local_irq_disable(), then spin_lock(), spin_unlock() and only
> re-enable the interruptions ?
Good question, as this is exactly what spin_lock_irq()/spin_unlock_irq()
do. In this case it is not a problem as the intent was the same anyway,
but we can fix the code to handle this. If you read the patch, you will
find that we call preempt_schedule() which calls schedule(). We could
easily put a test of the interrupt off state here and reject the
preemption. The real issue here is how to catch the preemption when
local_irq_enable() is called. If the system has an interrupt dedicated
to scheduling we could use this, however, while this is available in SMP
systems it is usually not available in UP systems.
On the other hand I have not seen any code do this. I have, however,
seen code that:
spin_lock_irq()
:
local_irq_enable()
:
spin_unlock()
We would rather not mess with the preemption count while irq is disabled
but this sort of code messes up the pairing we need to make this work.
> In this case, you preempt code that
> is supposed to run interruptions disabled.
> Finally, regarding the test on the task state, there may be a cache issue
> but calling schedule() has also some overhead.
>
I am not sure what you are getting at here. The task state will be
looked at by schedule() in short order in any case so a cache miss is
not the issue. We don't look at the state but on the way to schedule()
(in preempt_schedule()) we add a flag to the state to indicate that it
is a preemption call. schedule() is then changed to treat this task as
running, regardless of the state.
George
> Ludo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: You've Been Slashdotted
I gather from the combination of what I read on Slashdot and what folks replied here that the mirrors are actually lightly loaded, but Slashdot readers don't know about them because they couldn't read the home page at http://www.kernel.org that directed them to the mirror list. So I posted the algorithm for calculating the URL to your nearest mirror on Slashdot. Maybe that'll help some Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Memory Corruption
This message has a couple of questions to it, so maybe a few people might want to contribute to answering them all. My apologies in advance for the long length of this post. The Problem: I have an Alpha PC164 with 512 Meg of memory. As a friend and I were setting it up, we tried to compile mozilla. At some point during the install, a repeating error would scroll by the screen so fast that we could not read it. From what we could pick out, we determined that the error was memory related. We deduced that since compiling mozilla would fill the entire bank of memory, once gcc (or whatever directly writes to memory) tried to address the bad area of memory, gcc would produce the error. Also, after trying to recompile mozilla a number of times, the error would be at a random point, usually after about 15 or 20 minutes of compiling. From this information, we hazard to guess that one of the eight 64 Meg SIMMS was bad, or contained a bad area. Therefore, we removed the last 4 of the 8 modules, and the error never occurred. The suggested solution: We plan to swap out the 4 of the 4 remaining modules with the 4 that we removed earlier, one at a time, and try to compile mozilla, since it will fill all of the memory. Then, hopefully, we can rotate the modules to find the one that contains the bad area. We are not quite sure what to do from there. Here are our ideas: 1. One suggestion I made was to create a ram drive over the last 64 Meg of addressable memory, the simply not read or write to the drive. Is that even possible? Can I tell the kernel to create a ram drive over a certain area of memory? 2. Another idea I had was to tell the kernel to only use a certain size of memory, with a modification to lilo.conf: append="mem=448m" since 512(the total memory) - 64(the size of the module) = 448Meg. Will this work? Any ideas? Another question: We are not sure if the memory is ECC or not, but we think that there is a good chance of it. Are there any kernel optimizations that can be made so that the kernel can map out the bad memory and mark it so that it cant be used? The machine is booted from an SRM prompt, if that helps. Please let me know if anyone had any ideas on these problems. Thanks in advance to all those out there who took the time to read this. --Ryan Sizemore - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
System Crash Kernel 2.4.0-test12 and 2.4.0-pre with XFree 4.0.2
Hi,
[1.] One line summary of the problem:
my System hangs up if I have a high load and if I use XFree.
[2.] Full description of the problem/report:
I'm using XFree 4.0.2 on a Vodoo3 2000 Graphics Board.
If I'm booting 2.4.0-test10 it works fine.
If I'm booting 2.4.0-test12 or pre my System Crashes if
I use multimedia applications like gkrellm, mtv, xmms
and do some downloads.
[3.] Keywords (i.e., modules, networking, kernel):
2.4.0 test12 pre crash XFree Vodoo
[4.] Kernel version (from /proc/version):
Linux version 2.4.0-prerelease (root@BOFH) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #4 Thu Jan 4 20:41:18 /etc/localtime 2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
[6.] A small shell script or example program which triggers the
problem (if possible)
wget -c -r ftp.kernel.org
wget -c -r blafasel.lan
mtv test.mpg
gkrellm
( just wait and work :-) )
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 350.803
cache size : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips: 699.59
[7.3.] Module information (from /proc/modules):
cs4232 3024 1
ad1848 17216 0 [cs4232]
uart401 6448 0 [cs4232]
sound 57616 1 [cs4232 ad1848 uart401]
soundcore 3952 4 [sound]
bttv 56848 0 (unused)
msp340013328 0 (unused)
tuner 3280 1
i2c-algo-bit7232 1 [bttv]
i2c-dev 3904 0 (unused)
i2c-core 12656 0 [bttv msp3400 tuner i2c-algo-bit i2c-dev]
videodev4576 2 [bttv]
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
/proc/ioports:
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
02f8-02ff : serial(auto)
0340-035f : eth1
0376-0376 : ide1
0378-037a : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0530-0533 : Crystal audio controller
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
5000-50ff : VIA Technologies, Inc. VT82C586B ACPI
d000-dfff : PCI Bus #01
d000-d0ff : 3Dfx Interactive, Inc. Voodoo 3
e000-e00f : VIA Technologies, Inc. Bus Master IDE
e000-e007 : ide0
e008-e00f : ide1
e800-e8ff : Macronix, Inc. [MXIC] MX987x5
e800-e8ff : eth0
/proc/iomem:
-0009fbff : System RAM
0009fc00-0009 : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07fe : System RAM
0010-002fe60f : Kernel code
002fe610-0031c983 : Kernel data
07ff-07ff2fff : ACPI Non-volatile Storage
07ff3000-07ff : ACPI Tables
e000-e3ff : PCI Bus #01
e000-e1ff : 3Dfx Interactive, Inc. Voodoo 3
e400-e5ff : PCI Bus #01
e400-e5ff : 3Dfx Interactive, Inc. Voodoo 3
e600-e6ff : VIA Technologies, Inc. VT82C597 [Apollo VP3]
e800-e8ff : Macronix, Inc. [MXIC] MX987x5
e800-e8ff : eth0
e8001000-e8001fff : Brooktree Corporation Bt848 TV with DMA push
e8001000-e8001fff : bttv
- : reserved
[7.5.] PCI information ('lspci -vvv' as root)
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IDE-CD Model: R/RW 4x4x32 Rev: 1.10
Type: CD-ROM ANSI SCSI revision: 02
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
dmesg:
Linux version 2.4.0-prerelease (root@BOFH) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #4 Thu Jan 4 20:41:18 /etc/localtim
e 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (usable)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 0001 @ (reserved)
BIOS-e820: 07ef @ 0010 (usable)
BIOS-e820: d000 @ 07ff3000 (ACPI data)
BIOS-e820: 3000 @ 07ff (ACPI NVS)
Scan SMP from c000 for 1024 bytes.
Scan SMP from
Adding devices to dc2xx.c
Hello, and thank you to those who responded to my query about adding my
Agfa ePhoto to the USB mass storage device database. I had no success
with this (the machine locked hard on connecting the device), so I have
decided to try it with the dc2xx driver.
I have added it to /usr/src/linux/drivers/usb/dc2xx.c as follows:
..
{ idVendor: 0x040a, idProduct: 0x0112 },// Kodak DC-290
{ idVendor: 0xf003, idProduct: 0x6002 },// HP PhotoSmart C500
{ idVendor: 0x06bd, idProduct: 0x0403 },// Agfa ePhoto CL18
..
However, after I recompile and reboot with the new boot image, I receive
the following:
..
Jan 5 19:37:33 localhost kernel: usb.c: registered new driver dc2xx
..
Jan 5 19:37:33 localhost kernel: hub.c: USB new device connect on bus1/2,
assigned device number 2
Jan 5 19:37:33 localhost kernel: usb.c: USB device 2 (vend/prod
0x6bd/0x403) is not claimed by any active driver.
..
Why is dc2xx not being associated with the camera? I note that the vendor
and product names of the camera omit the leading '0', but I have tried
adding
them to the driver file as both '0x06bd' and '0x6bd' and neither works. I'm
using 2.4.0-prerelease, in case that helps.
So, does this sound like a bug with the above driver, or is there something
that I've missed?
--
Alastair Foster
Note new email address = [EMAIL PROTECTED]
http://users.netaccess.co.nz/ala/
021 250 6482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
IEEE1394 2.4.0 (final) compile problems
# IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y CONFIG_IEEE1394_VIDEO1394=y CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-DEXPORT_SYMTAB -c ieee1394_syms.c ld -m elf_i386 -r -o ieee1394.o ieee1394_core.o ieee1394_transactions.o hosts.o highlevel.o csr.o guid.o ieee1394_syms.o gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686-c -o ohci1394.o ohci1394.c ohci1394.c:152: warning: `ohci1394_pci_tbl' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o video1394.o video1394.c video1394.c:1229: warning: `video1394_fops' defined but not used video1394.c:1239: warning: `video1394_init' defined but not used video1394.c:1277: warning: `remove_card' defined but not used gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-f rame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -c -o raw1394.o raw1394.c rm -f ieee1394drv.o ld -m elf_i386 -r -o ieee1394drv.o ieee1394.o ohci1394.o video1394.o raw1394.o video1394.o(.data+0x0): multiple definition of `ohci_csr_rom' ohci1394.o(.data+0x0): first defined here make[3]: *** [ieee1394drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/ieee1394' make[1]: *** [_subdir_ieee1394] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 [root@thud linux]# - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How to Power off with ACPI/APM?
On 2001.01.05 Michael D. Crawford wrote: In my own work I mostly do multithreaded software development and I just sort of felt like it would be good karma to enable it even if my machine didn't support it. Go figure. So this was mostly a user error, although I guess I've been helpful in discovering the current interaction of ACPI and APM. Silly question, but have you realized that you don't have to enable SMP in kernel to do multithreading ? -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How to Power off with ACPI/APM?
On 2001.01.05 Dominik Kubla wrote: On Fri, Jan 05, 2001 at 10:18:46AM +0100, J . A . Magallon wrote: Silly question, but have you realized that you don't have to enable SMP in kernel to do multithreading ? That depends on your definition: If you really want to run multiple threads simultaneously (as opposed to concurrent i guess) i imagine you will either need more than one CPU or one of those new beasties which support multiple threads in parallel on their various execution units... Nope. You can run multiple threads "simultaneously" on an uniprocessor, so simultaneous as the rest of the processes the cpu is running. Of course the efficiency of multi-threading drops on an uni-processor if your threads only do hard math work and no IO, but a thread can be crunchin numbers at the same time one other is waiting for IO even on a one cpu box. Think on an app that does read-process-write in loop. Two parallel threads on an uniprocessor can overlap IO and process and be more efficient than a non-threaded version. -- J.A. Magallon $ cd pub mailto:[EMAIL PROTECTED] $ more beer Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
agpgart problem on 2.4.0-ac1
Dear all!
wanted to try the latest stuff, but X fails to start now.
dmesg part:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 93M
agpgart: agpgart: Detected an Intel i815 Chipset.
Unable to handle kernel NULL pointer dereference at virtual address
printing eip:
*pde =
Oops:
CPU:0
EIP:0010:[]
EFLAGS: 00010246
eax: ebx: c8827000 ecx: c020da88 edx: 0001
esi: edi: ebp: esp: c78a1f04
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 61, stackpage=c78a1000)
Stack: c8829bb0 c8827000 c8827068 3fd0 c8829d50
c882aa00
0063 c8827000 c01156cd c78a bfffc3a4 bfffc3a4
bfffc364
3b67 c779a000 0060 c779b000 ffea 0007 c1253460
0060
Call Trace: [c8829bb0] [c8827000] [c8827068] [c8829d50]
[c882aa00] [c8827000] [c01156cd]
[c882] [c8827060] [c0108d5f]
Code: Bad EIP value.
lsmod
Module Size Used by
nls_cp850 3584 2 (autoclean)
nls_iso8859-2 3360 2 (autoclean)
smbfs 31056 2 (autoclean)
floppy 45296 0 (autoclean)
serial 43312 1 (autoclean)
isa-pnp27600 0 (autoclean) [serial]
ide-cd 26288 0
cdrom 26720 0 [ide-cd]
softdog 1472 0 (unused)
agpgart16336 1 (initializing)
8139too14784 1
rtc 5248 0
ipchains 30848 0 (unused)
I hope you'll fix it soon.
Ksznettel
Narancs v1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: modutils 2.4.0 is available
On Fri, Jan 05, 2001 at 12:48:04PM +0600, Anuradha Ratnaweera wrote: Why not DEB? Because Keith doesn't have a Debian system? He just provides the rpms as a service, he doesn't have to do that. Install the "alien" package on your machine and you will be able to convert between rpm and deb. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Hi, On Fri, Jan 05, 2001 at 01:31:12AM +0100, Daniel Phillips wrote: "Stephen C. Tweedie" wrote: Yes, and so long as your journal is not on another partition/disk things will eventually be set right. The combination of a partially updated filesystem and its journal is in some sense a complete, consistent filesystem. Right. I'm curious - how does ext3 handle the possibility of a crash during journal recovery? Recovery comes in two parts: replay of the log, and deletion of orphaned inodes. The log replay is fully idempotent: it just consists of writing the appropriate log blocks to their home locations on disk. It doesn't matter if you do those writes once, twice or a hundred times, you still get the same result, so crashing mid-recovery and starting again from scratch is perfectly safe. Once that recovery is done, the filesystem is marked, atomically, to be clean. Secondly, we do the deletion of orphaned inodes. By this time, the journal itself has been recovered so we are journaling our operations, so each orphaned inode delete is being logged. A crash will recover to a consistent state via the normal journaling transaction methods, and will restart orphan recovery from where it left off. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
compile error on 2.4.0
Hi, gcc -D__KERNEL__ -I/usr/src/linux-2.4.0/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i586 -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4.0/include/linux/modversions.h -c -o r128_cce.o r128_cce.c r128_cce.c: In function `r128_cce_init_ring_buffer': r128_cce.c:339: structure has no member named `agp' r128_cce.c:333: warning: `ring_start' might be used uninitialized in this function r128_cce.c: In function `r128_cce_packet': r128_cce.c:1023: warning: unused variable `size' r128_cce.c:1021: warning: unused variable `buffer' r128_cce.c:1019: warning: unused variable `dev_priv' make[3]: *** [r128_cce.o] Error 1 .config file on request... regards, chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: So, what about kwhich on RH6.2?
On Thu, 4 Jan 2001, Albert D. Cahalan wrote: can't we just hardwire `kgcc' into the build system and be done with all this kwhich stuff? It's just a symlink And break compilation on all non RedHat 7, non connectiva systems ? Would you volunteer to handle the support load on l-k that would cause? Hardcoding kgcc is definitely not an option. Creating symlinks during the build would solve the problem. /usr/src/linux/kern-cc - /usr/bin/kgcc /usr/src/linux/user-cc - /usr/bin/gcc But who builds kernels in /usr/src anymore, or as root for that matter... ;o) -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- If at first you don't succeed, call it version 1.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Where to get quota.
Hello. Perhaps the help text for disk quotas needs to be updated, or at least the howto for quotas. The help text for disk quotas says to see the Quota mini-HOWTO. The howto says to get the quota source from: ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/subsystems/quota/all.tar.gz That doesn't exist anymore. You can get newest quota utilities (I'm expecting you want utils for old quotafile format) at 'ftp://ftp.cistron.nl/pub/people/mvw/quota/quota-2.00-pre11.tar.gz' I'm just looking for a quick pointer to the quota source, but also suggesting that maybe the help text should be updated. Or if someone points me in the right direction, I'll write to the author of the howto. Sorry... I don't know who's the author. Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lvm: hw error or misconfig?
Dear developers! (sorry for the long mail) We have a compaq proliant server with NO raid and 5 scsi discs: Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: COMPAQ Model: BD00911934 Rev: 3B02 Type: Direct-AccessANSI SCSI revision: 02 bounded together to a volume group vg00. This morning we received this strange message, and a file is not readable anymore. It is i/o error-ed. unfort. this caused loosing important data. Jan 5 11:30:21 matrix kernel: attempt to access beyond end of device Jan 5 11:30:21 matrix kernel: 08:31: rw=0, want=8883914, limit=8883913 Jan 5 11:30:21 matrix kernel: dev 3a:00 blksize=1024 blocknr=8551735 sector=17767820 size=4096 count=1 Does it mean that some of the disks are hw errored or is it a misconfiguration, error in lvm or kernel code? How could I check the disks while they are in live work? It would be a big pain to stop the system and reformat the drives, so on. any idea? kernel 2.2.17, lvm 0.8i a la debian woody. thanks for your help, and hoping for fast answer Narancs v1 - cat /proc/scsi/sym53c8xx/0 General information: Chip sym53c876, device id 0xf, revision id 0x14 IO port address 0x2000, IRQ number 23 Using memory mapped IO at virtual address 0xe0800f00 Synchronous period factor 12, max commands per lun 32 vgdisplay -v --- Volume group --- VG Name vg00 VG Access read/write VG Status available/resizable VG # 0 MAX LV256 Cur LV1 Open LV 1 MAX LV Size 255.99 GB Max PV256 Cur PV5 Act PV5 VG Size 41.1 GB PE Size 4 MB Total PE 10521 Alloc PE / Size 10521 / 41.1 GB Free PE / Size 0 / 0 --- Logical volume --- LV Name /dev/vg00/oracle VG Name vg00 LV Write Access read/write LV Status available LV # 1 # open1 LV Size 41.1 GB Current LE10521 Allocated LE 10521 Allocationnext free Read ahead sectors120 Block device 58:0 --- Physical volumes --- PV Name (#) /dev/sda3 (1) PV Status available / allocatable Total PE / Free PE2061 / 0 PV Name (#) /dev/sdb2 (2) PV Status available / allocatable Total PE / Free PE2061 / 0 PV Name (#) /dev/sdc2 (3) PV Status available / allocatable Total PE / Free PE2061 / 0 PV Name (#) /dev/sdd1 (4) PV Status available / allocatable Total PE / Free PE2169 / 0 PV Name (#) /dev/sde1 (5) PV Status available / allocatable Total PE / Free PE2169 / 0 cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dumppass /dev/sda2 / ext2defaults,errors=remount-ro 01 /dev/sda1 noneswapsw 0 0 /dev/sdb1 noneswapsw 0 0 /dev/sdc1 noneswapsw 0 0 proc/proc procdefaults00 /dev/fd0/floppy autodefaults,user,noauto00 /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 00 /dev/vg00/oracle /u01 ext2defaults0 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
subscrive
Cícero Clarindo Campelo Neto Analista de Suporte, MCSE Departamento de Suporte Lanlink Informática Ltda * (0xx85) 466-8004 [EMAIL PROTECTED] http://www.lanlink.com.br Serviço de Atendimento ao Cliente: * (85) 0800-85-0800 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Network oddity....
Interesting, yesterday I have TCP problems with my three independent systems. They all acts as simple firewalls with MASQ. Yesterday they all suddenly stopped responding to ssh TCP connections to IP on eth1 (internal net) but they continued to work on IP attached to eth0 and lo. The problem survived reboot. Then it suddenly ceased and I can't trigger it again. Kernels was 2.2.13, 2.2.16 and 2.2.17 and the systems was completely unrelated. Kind of woodoo or what ... devik Oh, this situation seems to continue: it sends a syn-ack and then the client replies with a reset. This goes on and on. I'm going to make the client disappear, and hope that this makes the number of these connections go away. Kernel is 2.2.13. That was "fresh" when the system was booted. Yes, that's over 14 months ago. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: IEEE1394 2.4.0 (final) compile problems
In article [EMAIL PROTECTED] you wrote:
video1394.o(.data+0x0): multiple definition of `ohci_csr_rom'
ohci1394.o(.data+0x0): first defined here
Known bug, fix attached below.
Greetings,
Arjan van de Ven
diff -urN /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.c
linux/drivers/ieee1394/ohci1394.c
--- /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.cThu Jan 4
10:10:00 2001
+++ linux/drivers/ieee1394/ohci1394.c Thu Jan 4 17:32:30 2001
@@ -112,6 +112,80 @@
#define DBGMSG(card, fmt, args...)
#endif
+/* This structure is not properly initialized ... it is taken from
+ the lynx_csr_rom written by Andreas ... Some fields in the root
+ directory and the module dependent info needs to be modified
+ I do not have the proper doc */
+quadlet_t ohci_csr_rom[] = {
+/* bus info block */
+0x0404, /* info/CRC length, CRC */
+0x31333934, /* 1394 magic number */
+0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
+0x, /* vendor ID, chip ID high (written from card info) */
+0x, /* chip ID low (written from card info) */
+/* root directory - FIXME */
+0x0009, /* CRC length, CRC */
+0x03080028, /* vendor ID (Texas Instr.) */
+0x8109, /* offset to textual ID */
+0x0c000200, /* node capabilities */
+0x8d0e, /* offset to unique ID */
+0xc710, /* offset to module independent info */
+0x0400, /* module hardware version */
+0x8126, /* offset to textual ID */
+0x0900, /* node hardware version */
+0x8126, /* offset to textual ID */
+/* module vendor ID textual */
+0x0008, /* CRC length, CRC */
+0x,
+0x,
+0x54455841, /* "Texas Instruments" */
+0x5320494e,
+0x53545255,
+0x4d454e54,
+0x5300,
+/* node unique ID leaf */
+0x0002, /* CRC length, CRC */
+0x08002856, /* vendor ID, chip ID high */
+0x083E, /* chip ID low */
+/* module dependent info - FIXME */
+0x0006, /* CRC length, CRC */
+0xb806, /* ??? offset to module textual ID */
+0x8104, /* ??? textual descriptor */
+0x, /* SRAM size */
+0x, /* AUXRAM size */
+0x, /* AUX device */
+/* module textual ID */
+0x0005, /* CRC length, CRC */
+0x,
+0x,
+0x54534231, /* "TSB12LV22" */
+0x324c5632,
+0x3200,
+/* part number */
+0x0006, /* CRC length, CRC */
+0x,
+0x,
+0x39383036, /* "9806000-0001" */
+0x3030342d,
+0x30303431,
+0x2001,
+/* module hardware version textual */
+0x0005, /* CRC length, CRC */
+0x,
+0x,
+0x5453424b, /* "TSBKOHCI403" */
+0x4f484349,
+0x34303300,
+/* node hardware version textual */
+0x0005, /* CRC length, CRC */
+0x,
+0x,
+0x54534234, /* "TSB41LV03" */
+0x314c5630,
+0x3300
+};
+
+
/* print general (card independent) information */
#define PRINT_G(level, fmt, args...) \
printk(level "ohci1394: " fmt "\n" , ## args)
diff -urN /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.h
linux/drivers/ieee1394/ohci1394.h
--- /mnt/kernel/clean/linuxprereleaseac5/drivers/ieee1394/ohci1394.hThu Jan 4
10:10:00 2001
+++ linux/drivers/ieee1394/ohci1394.h Thu Jan 4 17:32:15 2001
@@ -280,74 +280,7 @@
the lynx_csr_rom written by Andreas ... Some fields in the root
directory and the module dependent info needs to be modified
I do not have the proper doc */
-quadlet_t ohci_csr_rom[] = {
-/* bus info block */
-0x0404, /* info/CRC length, CRC */
-0x31333934, /* 1394 magic number */
-0xf07da002, /* cyc_clk_acc = 125us, max_rec = 1024 */
-0x, /* vendor ID, chip ID high (written from card info) */
-0x, /* chip ID low (written from card info) */
-/* root directory - FIXME */
-0x0009, /* CRC length, CRC */
-0x03080028, /* vendor ID (Texas Instr.) */
-0x8109, /* offset to textual ID */
-0x0c000200, /* node capabilities */
-0x8d0e, /* offset to unique ID */
-0xc710, /* offset to module independent info */
-0x0400, /* module hardware version */
-0x8126, /* offset to textual ID */
-0x0900, /* node hardware version */
-0x8126, /* offset to textual ID */
-/* module vendor ID textual */
-0x0008, /* CRC length, CRC */
-0x,
-0x,
-0x54455841, /* "Texas Instruments" */
-0x5320494e,
-0x53545255,
-0x4d454e54,
-
Re: agpgart problem on 2.4.0-ac1
EIP: 0010:[] Call Trace: [c8829bb0] [c8827000] [c8827068] [c8829d50] [c882aa00] [c8827000] [c01156cd] [c882] [c8827060] [c0108d5f] Code: Bad EIP value. Could you parse your oops through ksymoops? Probably someone called an uninitialized function pointer, or there was a stack overrun. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
Hi, On Fri, Jan 05, 2001 at 12:06:47AM -0700, Andreas Dilger wrote: Stephen, you write: On Thu, Jan 04, 2001 at 05:31:12PM -0500, Alexander Viro wrote: BTW, what inumber do you want for whiteouts? IIRC, we decided to use the same entry type as UFS does (14), but I don't remember what was the decision on inumber. UFS uses 1 for them, is it OK with you? 0 is used for padding, so 1 makes sense, yes. Sorry, but what are whiteouts? Inode 1 in ext2 is the bad blocks inode, so it will never be used for a valid directory entry, but depending on what it is we may want to make sure e2fsck is OK with it as well. Whiteouts are used for union filesystems, where you layer one filesystem over another so that all modifications are made in the "upper" layer, but unmodified files stay in the "lower" layer. That way, you can layer an empty filesystem on top of some other directory and get what is essentially a free snapshot of that directory. In such a scheme, whiteouts are used if you unlink a file from the union mount. The lower-layered filesystem is effectively readonly as far as the union is concerned, so we record the unlink by adding a whiteout entry in the upper filesystem. A lookup for that name in the union filesystem will find the whiteout and will return ENOENT immediately without looking to see if the entry exists in the lower filesystem. We still need to return the whiteouts to user space for getdents(), though: union filesystems normally deal with readdir() by reading the whole set of dentries into user space and sorting them there, so the whiteout is semantically significant to getdents(). Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How can I create root disk in Redhat 6.0
Mike, there are docs named HOWTO-. There is also one about boot/root disks. I recommend you to boot from redhat instalation CD and after launch pres Alt-F2 (or F3,4... a can't remember) to get into free console with bash prompt. Then mount your hacked(TM) disk and try to repair. devik When i boot linux from rescue disk, i get following message: VFS: Insert root floppy disk to be loaded in RAM disk and press ENTER Now how can i create a root disk... I am trying to boot Redhat 6.0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: How can I create root disk in Redhat 6.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike wrote: Hi !! When i boot linux from rescue disk, i get following message: VFS: Insert root floppy disk to be loaded in RAM disk and press ENTER Now how can i create a root disk... I am trying to boot Redhat 6.0 Regards, Mike man mkbootdisk Basically you do mkbootdisk version-number-of-your-kernel Sometimes with the addition of --device /dev/fd0 as this: mkbootdisk --device /dev/fd0 version-number-of-your-kernel The kernel version you are running can be seen by doing: uname -a /Richard -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6VbI8USLExYo23RsRAiW4AKCo7Bg+TpLth1a2OOWFV0VvWyClHwCfUp3f HEnQVOnAJYu1N0D2ZWJBLsg= =nYhZ -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Can I submit a bug report on this mailing list?
On Thu, 4 Jan 2001, Evan Thompson wrote: I hear about the 2.4.0 release. I have, in my mailbox, many messages titled "Re: And oh, btw...", BUT NO ORIGINAL MESSAGE! What happened? Is my stupid mailserver selective or something? Anyways. My bug report is: "[EMAIL PROTECTED] does not send me important mails that are important and that should be sent due to their high importancy." Says the guy who reads his linux-kernel email on bigfoot.com ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Change of policy for future 2.2 driver submissions
On Thu, 4 Jan 2001, Nicholas Knight wrote: While I understand the reasoning behind this, and might do the same thing if I was in your position, I feel it may be a mistake. I personaly do not trust the 2.4.x kernel entirely yet, and would prefer to wait for 2.4.1 or 2.4.2 before upgrading from 2.2.18 to ensure last-minute wrinkles have been completely ironed out, This is *exactly* why Alan's policy change makes sense. If somebody submits a driver bugfix or update for 2.2, but not for 2.4, it'll take FOREVER for 2.4 to become as "trustable" as 2.2... This change, however, will make sure that 2.4 will be as reliable as 2.2 much faster. Unlike 2.2, the core kernel of 2.4 is reliable ... only the peripheral stuff like drivers may be out of date or missing. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to loose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
[EMAIL PROTECTED] said: In what way? A root fs readonly mount is usually designed to prevent ^^^ the filesystem from being stomped on during the initial boot so that fsck can run without the filesystem being volatile. That's the only reason for the readonly mount: to allow recovery before we enable writes. With ext3, that recovery is done in the kernel, so doing that recovery during mount makes perfect sense even if the user is mounting root readonly. Alternative reasons for readonly mount include "my hard drive is dying and I don't want _anything_ to write to it because it'll explode". You mount it read-only, recover as much as possible from it, and bin it. You _don't_ want the fs code to ignore your explicit instructions not to write to the medium, and to destroy whatever data were left. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
[EMAIL PROTECTED] said: Powering down a VCR whilst recording can damage the tape or even worse have the tap get jammed in the video. I have also had a TV die because it was unpowered from the mains without being switched off first. Sure, these things don't always happen -- but they sometimes do. I would argue things like VCRs and TVs are just more tolerant than more complex systems -- not immune. The reasoning here seems to be that because many other systems break under these circumstances, we shouldn't bother to make Linux reliable. I don't quite understand that way of thinking. I will continue to test the boards I work on with random power cycles and to consider the filesystem broken if it doesn't like that treatment. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Hi, On Fri, Jan 05, 2001 at 02:01:37AM +0100, Stefan Traby wrote: Please tell me how to specify "noreplay" for the initial "/" mount :) You don't have to: the filesystem knows when a root mount is happening, and can do the extra work then to make sure that the mount isn't failed on a readonly media. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dcache 2nd chance replacement
On Thu, 4 Jan 2001, Alan Cox wrote: On Thu, Jan 04, 2001 at 02:59:49PM -0200, Rik van Riel wrote: Unfortunately you seem to ignore my arguments, so lets I've not ignored them, as said they were either obviously wrong of offtopic. Would the two of you ajourn this debate to alt.flame Better still stop _theorizing_ and start _measuring_ Cheers Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.0 drivers/atm/Makefile...
...is still broken. It does not build Fore 200e driver. Jan --- linux/drivers/atm/Makefile.orig Tue Jan 2 10:18:25 2001 +++ linux/drivers/atm/Makefile Tue Jan 2 12:00:05 2001 @@ -46,7 +46,7 @@ endif endif -obj-$(CONFIG_ATM_FORE200E) += fore200e.o $(FORE200E_FW_OBJS) +obj-$(CONFIG_ATM_FORE200E) += fore_200e.o include $(TOPDIR)/Rules.make -- Jan Rkorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Update of quota patches
Hello. So I've updated my quota patches for 2.4.0-prerelease. I also fixed one locking bug in implementation of new quotafile format and added a few comments. I also fixed compilation problems (when quota was disabled) - Alan, were there any problems I didn't fix (I've seen you and someone else were fixing some compilation problems with my patches in -ac but I've seen no mail about it (maybe I just missed it))? The patches can be downloaded from: ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ as quota-fix-2.4.0-pre-1.diff and quota-patch-2.4.0-pre-1.diff. Contents of patches: quota-fix: This patch mainly fixes bugs in current quota code: * races between preallocation and chgrp/chown fixed * cleaned up locking * quotas are dynamically allocated (so there are no more 'No free dquots' messages) quota-patch: This patch implements new quotafile format. It allows: * accounting of quota in bytes * 32-bit UIDs/GIDs * root is no longer special user Note that you will need new quota utilities for new quotafile format (you can download them at ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/quota-3.00-4.tar.gz). Also note that quota-patch requires quota-fix to be already applied. Honza - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 and Maxtor 96147H6 (61 GB)
No. 2.2.* handles large drives since 2.2.14. This looks more like you used the jumper to clip the drive to 32GB. Don't use it and get full capacity. If your BIOS hangs when it sees such a large drive so that you cannot avoid using the jumper, use setmax in your boot scripts, or use a kernel patch that does the same at kernel boot time. Looks like some short int (2 bytes) overflowing. I'll try the ide patches. The overflow is in certain BIOSes, not in Linux. (You see in the above: 65531 is not an overflow value.) The number after clipping was actual - 2^16. Was the reason I was thinking the kernel was playing games. After applying IDE patches the idesetmax message showed up :) I had to recompile fdisk as my old suse 6.4 version got the same 2byte-wraparound problem. In the good old days the HDIO_GETGEOM ioctl would give you the disk geometry. It has a short for cylinders and hence overflows when C gets above 65535. Since geometry is on its way out - indeed, there has not been any such thing for many, many years - it would have been nonsense to introduce new ioctls that report meaningless 32-bit numbers instead of the present meaningless 16-bit number. So, instead, the "cylinder" field in the output of this ioctl has been declared obsolete, and is not used anymore. Programs that want to print some value, just because they always did and users expect something, now use BLKGETSIZE to get total size and divide by heads*sectors to get a cylinder value. (But again: this cylinder value is not used anywhere, the computed value is just for the user's eyes.) all is block adressed indeed.. I need to look at fdisk, because it is doing things wrong. The other machine's BIOS can handle 64 GB wihout problems, so I can run without clipping in that machine. Linux sees the correct size, but fdisk still sees 32 GB. Probably a recompile / upgrade. Andries Regards, Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Unless Stephen says otherwise, my understanding is that a crash during journal recovery will just mean the journal is replayed again at the next recovery. Because the ext3 journal is just a series of data blocks to be copied into the filesystem (rather than "actions" to be done), it doesn't matter how many times it is done. The recovery flags are not reset until after the journal replay is completed. Which means an ext3 volume cannot be recovered on a hard disk error. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: agpgart problem on 2.4.0-ac1
wanted to try the latest stuff, but X fails to start now. Yep dmesg part: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 93M agpgart: agpgart: Detected an Intel i815 Chipset. Unable to handle kernel NULL pointer dereference at virtual address I broke agpgart. It will be cured (I hope) in -ac2 coming soon. That bug is also one in -ac1 so its not in the Linus tree - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reiserfs patch for 2.4.0-final
On Thu, Jan 04, 2001 at 04:52:49PM -0500, Chris Mason wrote: This patch is meant to be applied on top of the reiserfs 3.6.23 patch to get everything working in the new prerelease kernels. The order is: untar linux-2.4.0-prerelease.tar.bz2 apply linux-2.4.0-test12-reiserfs-3.6.23.gz apply this patch apply the fs/super.c patch to make sure fsync_dev is called when unmounting /. This was already sent to l-k, I'll send to the reiserfs list as well. Is this still correct for the final 2.4.0-kernel ? Could someone create one single patch for the 2.4.0 ? Bye, Claas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Hi, On Fri, Jan 05, 2001 at 12:46:19PM +, Alan Cox wrote: recovery. Because the ext3 journal is just a series of data blocks to be copied into the filesystem (rather than "actions" to be done), it doesn't matter how many times it is done. The recovery flags are not reset until after the journal replay is completed. Which means an ext3 volume cannot be recovered on a hard disk error. Depends on the error. If the disk has gone hard-readonly, then we need to recover in core, and that's something which is not yet implemented but is a known todo item. Otherwise, it's not worse than an error on ext2: you don't have a guaranteed safe state to return to so you fall back to recovering what you can from the journal and then running an e2fsck pass. e2fsck groks the journal already. And yes, a badly faulty drive can mess this up, but it can mess it for ext2 just as badly. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] up to 50% faster sys_poll()
sys_poll spends around 1/2 of the execution time allocating / freeing a
few bytes temporary memory.
The attached patch tries to avoid these allocation by using the stack -
usually only a few bytes are needed, kmalloc is used for the rest.
The result: one poll of stdin is down from 1736 cpu ticks to 865 cpu
ticks (Pentium II/350 SMP, SMP kernel)
select() should also be faster, but I haven't written a micro-benchmark
for select.
Please test it,
--
Manfred
// $Header$
// Kernel Version:
// VERSION = 2
// PATCHLEVEL = 4
// SUBLEVEL = 0
// EXTRAVERSION =
--- 2.4/fs/select.c Thu Nov 16 21:54:18 2000
+++ build-2.4/fs/select.c Fri Jan 5 13:46:30 2001
@@ -24,12 +24,6 @@
#define ROUND_UP(x,y) (((x)+(y)-1)/(y))
#define DEFAULT_POLLMASK (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM)
-struct poll_table_entry {
- struct file * filp;
- wait_queue_t wait;
- wait_queue_head_t * wait_address;
-};
-
struct poll_table_page {
struct poll_table_page * next;
struct poll_table_entry * entry;
@@ -52,11 +46,36 @@
* poll table.
*/
+/*
+ * Memory free and alloc took a significant part of the total
+ * sys_poll()/sys_select() execution time, thus I moved several
+ * structures on the stack:
+ * - sys_select has a 192 byte (enough for 256 fds) buffer on the stack.
+ * Please avoid selecting more than 5000 descriptors
+ * (kmalloc 4096 bytes), and you can't select
+ * more than 170.000 fds (kmalloc 128 kB)
+ * - sys_poll stores the first 24 file descriptors on the
+ * stack. If more than 24 descriptors are polled, then
+ * additional memory is allocated, but the first 24 descriptors
+ * always lie on the stack.
+ * - the poll table contains 8 wait queue entries. This means that no dynamic
+ * memory allocation is necessary for the wait queues if one of the first
+ * 8 file descriptors has new data.
+ * [EMAIL PROTECTED]
+ */
+
void poll_freewait(poll_table* pt)
{
struct poll_table_page * p = pt-table;
+ struct poll_table_entry * entry;
+ entry = pt-internal + pt-nr;
+ while(pt-nr 0) {
+ pt-nr--;
+ entry--;
+ remove_wait_queue(entry-wait_address,entry-wait);
+ fput(entry-filp);
+ }
while (p) {
- struct poll_table_entry * entry;
struct poll_table_page *old;
entry = p-entry;
@@ -73,33 +92,36 @@
void __pollwait(struct file * filp, wait_queue_head_t * wait_address, poll_table *p)
{
- struct poll_table_page *table = p-table;
-
- if (!table || POLL_TABLE_FULL(table)) {
- struct poll_table_page *new_table;
+ struct poll_table_entry * entry;
- new_table = (struct poll_table_page *) __get_free_page(GFP_KERNEL);
- if (!new_table) {
- p-error = -ENOMEM;
- __set_current_state(TASK_RUNNING);
- return;
+ if(p-nr POLL_TABLE_INTERNAL) {
+ entry = p-internal+p-nr++;
+ } else {
+ struct poll_table_page *table = p-table;
+
+ if (!table || POLL_TABLE_FULL(table)) {
+ struct poll_table_page *new_table;
+
+ new_table = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!new_table) {
+ p-error = -ENOMEM;
+ __set_current_state(TASK_RUNNING);
+ return;
+ }
+ new_table-entry = new_table-entries;
+ new_table-next = table;
+ p-table = new_table;
+ table = new_table;
}
- new_table-entry = new_table-entries;
- new_table-next = table;
- p-table = new_table;
- table = new_table;
- }
-
- /* Add a new entry */
- {
- struct poll_table_entry * entry = table-entry;
+ entry = table-entry;
table-entry = entry+1;
- get_file(filp);
- entry-filp = filp;
- entry-wait_address = wait_address;
- init_waitqueue_entry(entry-wait, current);
- add_wait_queue(wait_address,entry-wait);
}
+ /* Add a new entry */
+ get_file(filp);
+ entry-filp = filp;
+ entry-wait_address = wait_address;
+ init_waitqueue_entry(entry-wait, current);
+ add_wait_queue(wait_address,entry-wait);
}
#define __IN(fds, n) (fds-in + n)
@@ -233,14 +255,18 @@
return retval;
}
-static void *select_bits_alloc(int size)
+#define SELECT_INLINE_BYTES32
+static inline void *select_bits_alloc(int size, void* internal)
{
+ if(size = SELECT_INLINE_BYTES)
+ return internal;
return kmalloc(6 * size, GFP_KERNEL);
}
-static void select_bits_free(void *bits, int
Re: Fw: Change of policy for future 2.2 driver submissions
since Mark posted his views to the list, I figured I could safely post the conversation I've been having with him in email which is universally considered rude, if not illegal. in any case, please don't respond to this thread, which is quite off-topic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Network oddity....
On Fri, 5 Jan 2001, Rogier Wolff wrote:
Date: Fri, 5 Jan 2001 01:08:49 +0100 (MET)
From: Rogier Wolff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=US-ASCII
Subject: Network oddity
Hi all,
I have a server, and it reports ("netstat -a")
tcp0 0 server:sshclient:1022 SYN_RECV
This sounds normal right?
However there are 79 of these lines in the netstat output. Not normal!
A TCP connection is identified by the 12 bytes source IP, dest IP,
source port, dest port. Right? Then as far as I can see, these should
all refer to the SAME socket. (yes, they all refer to server:ssh, and
client: 1022!)
Oh, this situation seems to continue: it sends a syn-ack and then the
client replies with a reset. This goes on and on. I'm going to make
the client disappear, and hope that this makes the number of these
connections go away.
Kernel is 2.2.13. That was "fresh" when the system was booted. Yes,
that's over 14 months ago.
Someone synflooding you perhaps?
--
Mike A. Harris - Linux advocate - Free Software advocate
This message is copyright 2001, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
--
If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when
was the last time you needed one?
-- Tom Cargill, C++ Journal, Fall 1990.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18: do_try_to_free_pages
I recieved the following messages from the kernel yesterda morning. It doesn't appear that any running programs actually died, or ran out of memory (128M physical/ 256M swap, only about 150M total or so in use when I got back on the machine. As a side note, during times of what I consider only moderate system activity (burning a CD while xmms playing and doing stuff in netscape, for example) I've had some system freezes. While under X, everything freezes solid, mouse pointer and all. System is completely inaccessable. After about 2 minutes or so, everything begins responding again. These problems began only when I moved to kernel 2.2.18. I also have Reiserfs 3.5.29 patched in, and in use. System is a K6-2/450, 128MB ram, Matsonic 6120S motherboard, ALi chipset. Just email me for any more details that are needed. dmesg: Jan 4 00:06:05 osprey kernel: VM: do_try_to_free_pages failed for X... Jan 4 00:06:06 osprey last message repeated 6 times Jan 4 00:06:06 osprey kernel: VM: do_try_to_free_pages failed for klogd... Jan 4 00:06:07 osprey last message repeated 15 times Jan 4 00:06:07 osprey kernel: VM: do_try_to_free_pages failed for kfm... Jan 4 00:06:07 osprey last message repeated 14 times Jan 4 00:06:07 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:07 osprey last message repeated 4 times Jan 4 00:06:07 osprey kernel: VM: do_try_to_free_pages failed for xmms... Jan 4 00:06:08 osprey last message repeated 10 times Jan 4 00:06:08 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:08 osprey kernel: VM: do_try_to_free_pages failed for klogd... Jan 4 00:06:09 osprey last message repeated 14 times Jan 4 00:06:09 osprey kernel: VM: do_try_to_free_pages failed for identd... Jan 4 00:06:09 osprey last message repeated 4 times Jan 4 00:06:09 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:09 osprey last message repeated 10 times Jan 4 00:06:09 osprey kernel: VM: do_try_M: do_try_to_free_pages failed for syslogd... Jan 4 00:06:09 osprey kernel: VM: do_try_to_free_pages failed for init... Jan 4 00:06:10 osprey last message repeated 14 times Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for identd... Jan 4 00:06:10 osprey last message repeated 14 times Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for fetchmail... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for xmms... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for X... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for maudio... Jan 4 00:06:10 osprey kernel: VM: do_try_to_free_pages failed for X... Jan 4 00:06:11 osprey last message repeated 14 times Jan 4 00:06:11 osprey kernel: VM: do_try_to_free_pages failed for xmms... Jan 4 00:06:11 osprey last message repeated 14 times Jan 4 00:06:11 osprey kernel: VM: do_try_to_free_pages failed for wpexc... Jan 4 00:06:12 osprey last message repeated 14 times Jan 4 00:06:12 osprey kernel: VM: do_try_to_free_pages failed for fetchmail... ... Messages continue for all programs running at the time, and end with: ... Jan 4 00:06:16 osprey kernel: VM: do_try_to_free_pages failed for gpm... Jan 4 00:06:17 osprey last message repeated 13 times Jan 4 00:06:17 osprey kernel: VM: do_try_to_free_pages failed for crond... Jan 4 00:06:17 osprey last message repeated 14 times - Brad Hartin - [EMAIL PROTECTED] Communications Administrator Straus-Frank Enterprises Limited Carquest retail/wholesale distributor for areas in TX, OK, LA, AR, NM, and KS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs patch for 2.4.0-final
On Friday, January 05, 2001 02:04:08 PM +0100 Claas Langbehn [EMAIL PROTECTED] wrote: On Thu, Jan 04, 2001 at 04:52:49PM -0500, Chris Mason wrote: This patch is meant to be applied on top of the reiserfs 3.6.23 patch to get everything working in the new prerelease kernels. The order is: untar linux-2.4.0-prerelease.tar.bz2 apply linux-2.4.0-test12-reiserfs-3.6.23.gz apply this patch apply the fs/super.c patch to make sure fsync_dev is called when unmounting /. This was already sent to l-k, I'll send to the reiserfs list as well. Is this still correct for the final 2.4.0-kernel ? Yes Could someone create one single patch for the 2.4.0 ? I put all the code into CVS, and Yura is making the official patch now. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
