Re: [patch][rfc][rft] vm throughput 2.4.2-ac4
On Tue, 6 Mar 2001, Marcelo Tosatti wrote: > On Fri, 2 Mar 2001, Mike Galbraith wrote: > > > On Thu, 1 Mar 2001, Rik van Riel wrote: > > > > > > > The merging at the elevator level only works if the requests sent to > > > > > it are right next to each other on disk. This means that randomly > > > > > sending stuff to disk really DOES DESTROY PERFORMANCE and there's > > > > > nothing the elevator could ever hope to do about that. > > > > > > > > True to some (very real) extent because of the limited buffering > > > > of requests. However, I can not find any useful information > > > > that the vm is using to guarantee the IT does not destroy > > > > performance by your own definition. > > > > > > Indeed. IMHO we should fix this by putting explicit IO > > > clustering in the ->writepage() functions. > > > > I notice there's a patch sitting in my mailbox.. think I'll go read > > it and think (grunt grunt;) about this issue some more. > > Mike, > > One important information which is not being considered by > page_launder() now the dirty buffers watermark. > > In general, it should not try to avoid writing dirty pages if we're above > the dirty buffers watermark. Agreed in theory.. I'll go try to measure. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-ac13 make modules_install error
Hi. I've had the same problem, it also happens in 2.4.2ac12 Cheers, Matt Johnston On Wed, 7 Mar 2001 13:04, Frank Davis wrote: > Hello, >While 'make modules_install' on 2.4.2-ac13, I receive the following > error: > > make -C kernel modules_install > make[1]: Entering directory '/usr/src/linux/kernel' > make[1]: Nothing to be done for 'modules_install'. > .. > make -C drivers modules_install > make[1]: Entering directory ;/usr/src/linux/drivers' > make -C arm modules_install > make[2]: Entering directory '/usr/src/linux/drivers/atm' > mkdir -p /lib/modules/2.4.2-ac13/kernel/$(shell ($CONFIG_SHELL) > $(TOPDIR)/scripts/pathdown.sh) /bin/sh: CONFIG_SHELL: command not found > /bin/sh: TOPDIR: command not found > > > All previous steps appeared to work without any problems, and I performed a > 'make mrproper'. The build worked in 2.4.2-ac11 . Any suggestions? > > Regards, > Frank > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RAID, 2.4.2 and Buslogic
Leonard, My story is somewhat similar to what Dick Johnson has encountered except this is with 2.4.2 running on a pentium 200. I encountered an oops last night while untarring a file. Upon reboot, it appears that the partition labels disappeared along with the superblock. Unfortunately, I was not able to recover and had to redo the setup from scratch. Here is the lspci output deepthought%jauderho% lspci 00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 01) 00:09.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 02) 00:0b.0 VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX] (rev 01) 00:0d.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) 00:0f.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10] (rev 08) Unfortunately, the System.map was deleted during a compile but attached is the dmesg output. EXT2-fs error (device md(9,0)): ext2_add_entry: bad entry in directory #343396: inode out of bounds - offset=0, inode=343396, rec_len=12, name_len=1 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 12 EXT2-fs error (device md(9,0)): free_inode: reserved inode or nonexistent inode kernel BUG at inode.c:885! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010292 eax: 001b ebx: c2af8ba0 ecx: c373c000 edx: 0001 esi: c023b9e0 edi: c38bd017 ebp: c3c285e0 esp: c1877f24 ds: 0018 es: 0018 ss: 0018 Process tar (pid: 5383, stackpage=c1877000) Stack: c01fd7e5 c01fd865 0375 c2af8ba0 c13b8f40 c014fa07 c2af8ba0 01fd c3c285e0 c3c28650 c13b8f40 0007 c3932560 c0138ef7 fffe c013a773 c3c285e0 c13b8ee0 01fd c13b8ee0 c1877fa4 c13b8ee0 c1e5c000 Call Trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c eb 6f 39 1b 74 3b f6 83 ec 00 00 00 07 75 26 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 474218 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 474219 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 474216 ... EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 1062908 EXT2-fs error (device md(9,0)): ext2_readdir: bad entry in directory #310689: in ode out of bounds - offset=0, inode=310689, rec_len=12, name_len=1 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 228935 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212584 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212583 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212586 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212588 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212589 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212587 EXT2-fs error (device md(9,0)): ext2_write_inode: bad inode number: 212585 EXT2-fs error (device md(9,0)): ext2_find_entry: bad entry in directory #883010: inode out of bounds - offset=60, inode=245344, rec_len=4036, name_len=16 --Jauder PS. Is there a minimum processor speed requirement to do RAID? I know the pentium 200 is pretty wimpy but if this is the failure mode it was certainly unexpected. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
On Wed, 7 Mar 2001, Alexander Viro wrote:
>
>
> You are reinventing the wheel.
> man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
With ptrace data will be copied twice. As far as I understood, Jeremy
wants to avoid that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 and new aic7xxx
> I suspect it's easier to just make the PCI layer call the probe function > in that order, instead of working around it in your driver. Jeff? Would 'pci=reverse' do the trick already? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
On Wed, 7 Mar 2001, Jonathan Morton wrote: > Still doesn't make a difference - there is one revolution between writes, > no matter where on disk it is. Oh it does, because you are hitting the same sector with the same data. Rotate your buffer and then you will see the difference. > >Because of WinBench! > >All the prefetch/caching are modeled to be optimized to that bench-mark. > > Lies, damn lies, statistics, benchmarks, delivery dates. Especially a > consumer-oriented benchmark like WinBench. It's perfectly natural to > optimise for particular access patterns, but IMHO that doesn't excuse > breaking the drive just to get a better benchmark score. Obviously you have never been in the bowls of drive industry hell. Why do you think there was a change the ATA-6 to require the Write-Verify-Read to always return stuff from the platter? Because the SOB's in storage LIE! A real wake-up call for you is that everything about the world of storage is a big-fat-whopper of a LIE. Storage devices are BLACK-BOXES with the standards/rules to communicate being dictated by the device not the host. Storage devices are no beter then a Coke(tm) vending machine. You push "Coke" it gives you "Coke". You have not a clue to how it arrives or where it came from. Same thing about reading from a drive. > That isn't the point! I'm not talking about the physical mechanism, which > indeed is often the same between one generation of SCSI and the next > generation of IDE devices. I'm talking about the IDE controller which is > slapped on the bottom of said mechanism. The mech can be of world-class > quality, but if the controller is shot it doesn't cut the grain. So there is a $5 differnce in the cell-gates and the line drivers are more powerful, 80GB ATA + $5 != 80GB SCSI. > >Since all OSes that enable WC at init will flush > >it at shutdown and do a periodic purge with in-activity. > > But Linux doesn't, as has been pointed out earlier. We need to fix Linux. Friend I have fixed this some time ago but it is bundled with TASKFILE that is not going to arrive until 2.5. Because I need a way to execute this and hold the driver until it is complete, regardless of the shutdown method. > >Err, last time I check all good devices flush their write caching on their > >own to take advantage of having a maximum cache for prefetching. > > Which doesn't work if the buffer is filled up by the OS 0.5 seconds before > the power goes. Maybe that is why there is a vender disk-cache dump zone on the edge of the platters...just maybe you need to buy your drives from somebody that does this and has a predictive sector stretcher as the energy from the inertia by the DC three-phase motor executes the dump. Ever wondered why modern drives have open collectors on the databuss? Maybe to disconnect the power draw so that the motor now generator provides the needed power to complete the data dump... > I'm sorry if this looks like another troll, but I really do like to clear > up confusion. I do accept that IDE now has good enough real performance > for many purposes, but in terms of enforced quality it clearly lags behind > the entire SCSI field. I have no desire to debate the merits, but when your onboard host for ATA starts shipping with GigaBit-Copper speeds then we can have a pissing contest. Cheers, Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
David Brownell wrote: > > There are two problems I see. > > (1) CONFIG_SLAB_DEBUG breaks the documented > requirement that the slab cache return adequately aligned > data ... adequately aligned for the _cpu_, not for some controllers. It's neither documented that HW_CACHEALIGN aligns to 16 byte boundaries nor that kmalloc uses HW_CACHEALIGN. > which the appended patch should probably handle > nicely (something like it sure did :-) and with less danger > than the large patch you posted. > > (2) The USB host controller drivers all need something > like a pci_consistent slab cache, which doesn't currently > exist. I have something like that in the works, and David > Miller noted one driver that I may steal from. > > - Dave > > --- slab.c-orig Tue Mar 6 15:01:26 2001 > +++ slab.c Tue Mar 6 15:05:58 2001 > @@ -676,12 +676,10 @@ > } > > #if DEBUG > + /* redzoning would break cache alignment requirements */ > + if (flags & SLAB_HWCACHE_ALIGN) > + flags &= ~SLAB_RED_ZONE; The problem is that you've just disabled red zoning for kmalloc. And kmalloc is the only case where redzoning is important: If a caller uses kmem_cache_alloc() for a structure then he won't write beyond the end of the structure. I think everyone agrees that (2) correct fix. I see 2 temporary workarounds: either your patch or + #ifdef CONFIG_SLAB_DEBUG + #error + #endif in uhci.c. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
> So, if I configure the interface as suggested ("/sbin/ip addr add
> 10.0.0.0/24 dev eth0") can I really bind to any IP in 10.0.0.0/24 and
> conduct TCP sessions (as a client or server) using that IP--assuming all
> the ARP, etc, issues are worked out?
hostA: ip a a 10.0.0.0/24 brd + dev lo
hostB: ip r a 10.0.0.0/24 dev eth0
hostB: telnet 10.0.0.27
hostB: ssh 10.0.0.91
'tis a little magic I like. nothing special needed anywhere. does that
help?
-d
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-ac13 make modules_install error
On Wed, 7 Mar 2001 00:04:08 -0500 (EST), Frank Davis <[EMAIL PROTECTED]> wrote: >make[2]: Entering directory '/usr/src/linux/drivers/atm' >mkdir -p /lib/modules/2.4.2-ac13/kernel/$(shell ($CONFIG_SHELL) >$(TOPDIR)/scripts/pathdown.sh) >/bin/sh: CONFIG_SHELL: command not found >/bin/sh: TOPDIR: command not found Against 2.4.2-ac13. You need the same patch on 2.4.3-pre2. Index: 2.26/Rules.make --- 2.26/Rules.make Tue, 06 Mar 2001 13:01:59 +1100 kaos (linux-2.4/T/c/47_Rules.make 1.1.1.2 644) +++ 2.26(w)/Rules.make Wed, 07 Mar 2001 17:25:40 +1100 kaos +(linux-2.4/T/c/47_Rules.make 1.1.1.2 644) @@ -150,7 +150,7 @@ endif # ALL_MOBJS = $(filter-out $(obj-y), $(obj-m)) ifneq "$(strip $(ALL_MOBJS))" "" -MOD_DESTDIR ?= $(shell $(CONFIG_SHELL) $(TOPDIR)/scripts/pathdown.sh) +MOD_DESTDIR := $(shell $(CONFIG_SHELL) $(TOPDIR)/scripts/pathdown.sh) endif unexport MOD_DIRS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
> > At the time, I didn't feel like creating a custom sub-allocator just > > for USB, ... > > > > I'd be good to get it done "properly" at some point though. > > Something like > > struct pci_pool *pci_alloc_consistent_pool(int objectsize, int align) struct pci_pool * pci_create_consistent_pool (struct pci_dev *dev, int size, int align) and similar for freeing the pool ... pci_alloc_consistent() needs the device, presumably since some devices may need to dma into specific memory. I'd probably want at least "flags" from kmem_cache_create(). > pci_alloc_pool_consistent(pool,.. > pci_free_pool_consistent(pool,.. These should have signatures just like pci_alloc_consistent() and pci_free_consistent() except they take the pci_pool, not a pci_dev. Oh, and likely GFP_ flags to control blocking. > Where the pool allocator does page grabbing and chaining Given an agreement on API, I suspect Johannes' patch could get quickly generalized. Then debugging support (like in slab.c) could be added later. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 and new aic7xxx
In article <[EMAIL PROTECTED]>, Justin T. Gibbs <[EMAIL PROTECTED]> wrote: >>I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890 >>Ultra II scsi controller. I'm attaching the console grab when booting >>2.4.3-pre2. The controller BIOS is configured to boot off the disk with >>scsi id 0 on channel B. > >It looks like Doug was right to think that the functions can be >presented to the device driver in reverse order. I should have >a patch for you early tomorrow. It should be easy enough to make the PCI layer sort the devices, and you might not be the only driver that wants to see subfunction 0 before subfunction 1. I suspect it's easier to just make the PCI layer call the probe function in that order, instead of working around it in your driver. Jeff? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:IMS Twin Turbo 128 framebuffer
>Is there any particular reason why imsttfb isn't available in the >i386 arch? > >It doesn't work in X either in spite of being "supported", but >that's not for this list. I had this card while working at suse and I did try to get it to work on ix86. The problem is the card is initialzed by its firmware which is forth since this is a Apple card. As for getting the detail specs to get it to work on ix86 (making it firmware independent) good luck. You will have to suck the info from the deeps pits of apple. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi vs ide performance on fsync's
>I am not going to bite on your flame bate, and are free to waste you money. I don't flamebait. I was trying to clear up some confusion... >No, SCSI does with queuing. >I am saying that the ata/ide driver rips the heart out of the >io_request_lock what to darn long. This means that upon execution a >request virtually all interrupts are wacked and the drivers in dominating >the system. Given that IO's are limited to 128 sectors or one DMA PRD, >this is vastly smaller than the SCSI trasfer limit. Ah, so the ATA driver hogs interrupts. Nice. Kinda explains why I can't use the mouse on some systems when I use cdparanoia. >Okay real shortlimit to two zones that are equal in size. >The inner and outer, and the latter will cover more physical media than >the former. Simple Two zone model. Still doesn't make a difference - there is one revolution between writes, no matter where on disk it is. >> Under those circumstances, >> I would expect my 7200rpm Seagate to perform slower than my 1rpm IBM >> *regardless* of seeking performance. Seeking doesn't come into it! > >It does, because more RPM means more air-flow and more work to keep the >position stable. That's the engineers' problem, not ours. In fact, it's not really a problem because my IBM drive gave almost exactly the correct performance result, even at 1rpm, therefore it's managing to keep the position stable regardless of airflow. >> Why does this sound familiar? > >Because of WinBench! >All the prefetch/caching are modeled to be optimized to that bench-mark. Lies, damn lies, statistics, benchmarks, delivery dates. Especially a consumer-oriented benchmark like WinBench. It's perfectly natural to optimise for particular access patterns, but IMHO that doesn't excuse breaking the drive just to get a better benchmark score. >> Personally, I feel the bottom line is rapidly turning into "if you have >> critical data, don't put it on an IDE disk". There are too many corners >> cut when compared to ostensibly similar SCSI devices. Call me a SCSI bigot >> if you like - I realise SCSI is more expensive, but you get what you pay >> for. > >Let me slap you in the face with a salomi stick! >ATA 7200 RPM Drives are using SCSI 7200 RPM Drive HDA's >So you say ATA is Lame? Then so was your SCSI 7200's. That isn't the point! I'm not talking about the physical mechanism, which indeed is often the same between one generation of SCSI and the next generation of IDE devices. I'm talking about the IDE controller which is slapped on the bottom of said mechanism. The mech can be of world-class quality, but if the controller is shot it doesn't cut the grain. >Since all OSes that enable WC at init will flush >it at shutdown and do a periodic purge with in-activity. But Linux doesn't, as has been pointed out earlier. We need to fix Linux. Also, as I and someone else have also pointed out, there are drives in circulation which refuse to turn off write caching, including one sitting in my main workstation - the one which is rebooted the most often, simply because I need to use Windoze 95 for a few onerous tasks. I haven't suffered disk corruption yet, because Linux unmounts the filesystems and flushes it's own buffers several seconds before powering down, and uses a non-pathological access pattern, but I sure don't want to see the first time this doesn't work properly. >Err, last time I check all good devices flush their write caching on their >own to take advantage of having a maximum cache for prefetching. Which doesn't work if the buffer is filled up by the OS 0.5 seconds before the power goes. I'm sorry if this looks like another troll, but I really do like to clear up confusion. I do accept that IDE now has good enough real performance for many purposes, but in terms of enforced quality it clearly lags behind the entire SCSI field. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Mapping a piece of one process' addrspace to another?
You are reinventing the wheel.
man ptrace (see PTRACE_{PEEK,POKE}{TEXT,DATA} and PTRACE_{ATTACH,CONT,DETACH})
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 and new aic7xxx
>I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890 >Ultra II scsi controller. I'm attaching the console grab when booting >2.4.3-pre2. The controller BIOS is configured to boot off the disk with >scsi id 0 on channel B. It looks like Doug was right to think that the functions can be presented to the device driver in reverse order. I should have a patch for you early tomorrow. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.3 and new aic7xxx
"Justin T. Gibbs" wrote: > Can you provide me with a dmesg from a boot with aic7xxx=verbose? > I just tested this on a 3940AUW and the behavior was as expected. > Perhaps you have a motherboard based controller that has no seeprom? > I don't know how to detect flipped channels in that configuration > but I'll see what I can find out. I've a Super P6SBS motherboard with a builtin dual channel Adaptec 7890 Ultra II scsi controller. I'm attaching the console grab when booting 2.4.3-pre2. The controller BIOS is configured to boot off the disk with scsi id 0 on channel B. -- Rafael Linux version 2.4.3-pre2 (raffo@inca) (gcc version 2.95.2 19991024 (release)) #1 Mon Mar 5 12:54:06 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 0ff0 @ 0010 (usable) BIOS-e820: 0004 @ fffc (reserved) On node 0 totalpages: 65536 zone(0): 4096 pages. zone(1): 61440 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux_243 ro root=803 BOOT_FILE=/boot/vmlinuz_243 1 aic7xxx=verbose console=t8 Initializing CPU#0 Detected 701.600 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1399.19 BogoMIPS Memory: 255488k/262144k available (1064k kernel code, 6268k reserved, 416k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU: Intel Pentium III (Coppermine) stepping 03 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfdb81, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Limiting direct PCI/PCI transfers. isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 169725kB/56575kB, 512 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: WDC AC310100B, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-M1212, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 19807200 sectors (10141 MB) w/512KiB Cache, CHS=1232/255/63, UDMA(33) Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 > p3 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10d SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted ahc_pci:0:14:1: Reading SEEPROM...done. ahc_pci:0:14:1: Low byte termination Enabled ahc_pci:0:14:1: High byte termination Enabled ahc_pci:0:14:1: Downloading Sequencer Program... 404 instructions downloaded ahc_pci:0:14:0: Reading SEEPROM...done. ahc_pci:0:14:0: Low byte termination Enabled ahc_pci:0:14:0: High byte termination Enabled ahc_pci:0:14:0: Downloading Sequencer Program... 404 instructions downloaded scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5 aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5 aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs Vendor: SEAGATE Model: ST15150N Rev: 4611 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0,
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
From: "Jens Axboe" <[EMAIL PROTECTED]>
To: "Andre Hedrick" <[EMAIL PROTECTED]>
Cc: "Alan Cox" <[EMAIL PROTECTED]>; "Linus Torvalds"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > This is a LIE, it does not destroy the drive, only the partition table.
> > Please recally the limited effects of "DiskDestroyer" and "SCSIkiller"
> >
> > This is why we had the flaming discussion about command filters.
>
> But I might want to do this (write sector 0), why would we want
Jens, and others, I have noted a very simple data killer technique that
at LEAST works on Quantum SCSI drives as of a couple years ago and some
other earlier drives I felt could be sacrificed to the test. You can write
as many blocks at once as SCSI supports to the drive as long as you do
*NOT* start at block zero. If you write more than 1 block to block zero
the drive becomes unformatted. The only recovery is to reformat the
drive. The data on the drive is lost for good. I found no recovery for
this. I have, to my great chagrin, discovered this twice, the hard way.
Once on a large Micropolis harddisk I was working with in the block zero
area for partitioning purposes. And the other time when I was attempting
to make a complete duplicate of a 2G Quantum SCSI disk to another identical
2G SCSI disk. I ended up writing a script for the process that wrote one
block to block zero and then proceeded to use large blocks for the rest
of the disk, using dd under 2.0.36 at the time.
If this problem still exists the lowest level drivers in the OS should
offer protection for this problem so people working at any higher level
do not see it and fall victim to it.
{^_^}Joanne Dow, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re:Escape sequences & console
I would say the escape sequence are for /dev/ttyX since only Vt emulate Dec VT 100s. The web site to look for this info is http://www.vt100.net MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [[EMAIL PROTECTED]] /| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.netU http://linuxconsole.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Mapping a piece of one process' addrspace to another?
Greetings, Is there some way to map a piece of process X's address space into process Y, without X's knowledge or cooperation? (The non-cooperating nature of process X is why I can't use plain old shared memory.) Put another way, I need to grant Process Y permission to write into a private buffer owned by process X. X doesn't know this is happening, and I don't know where X's buffer even lives (X's stack, heap, etc.). X just passes a pointer to the kernel via a system call (e.g., like sys_read). In the system I currently have implemented, Y writes a buffer to the kernel, and the kernel relays it to X on behalf of Y. But, for performance reasons, I want to try to get Y to write its data directly to X instead. X might be any process calling read() (e.g., "cat"), but Y is in collusion with the kernel. If this is possible at all, is it also possible on a granularity down to one byte (as opposed to an entire page)? Sorry if this seems like a strange thing to do - but, I hope to document and release my code soon, in which case its purpose should be clearer :-). Regards, Jeremy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Incoming TCP TOS: A simple question, I would have thought...
> getsockopt(fd, SOL_IP, IP_TOS, .. Doesn't work. Returns the TOS of outgoing packets, which defaults to 0 even if there is a TOS set on incoming traffic... that was what I tried in my first test program. David. > cheers, > > lincoln. > > At 03:00 PM 7/03/2001 +1100, David Luyer wrote: > > >I've scrolled through various code in net/ipv4, and I can't see how to query > >the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which > >initiated the connection). > > > >Someone has sent in a feature request for squid which would require this, > >presumably so they can set the TOS in their routers and have the squid caches > >honour the TOS to select performance (via delay pools, multiple parents, > >different outgoing IP or similar). However I can't see how to get the TOS for > >a TCP socket out of the kernel short of having an open raw socket watching for > >SYNs and looking at the TOS on them. > > > >Any pointers? > > > >David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2-ac13 make modules_install error
Hello, While 'make modules_install' on 2.4.2-ac13, I receive the following error: make -C kernel modules_install make[1]: Entering directory '/usr/src/linux/kernel' make[1]: Nothing to be done for 'modules_install'. .. make -C drivers modules_install make[1]: Entering directory ;/usr/src/linux/drivers' make -C arm modules_install make[2]: Entering directory '/usr/src/linux/drivers/atm' mkdir -p /lib/modules/2.4.2-ac13/kernel/$(shell ($CONFIG_SHELL) $(TOPDIR)/scripts/pathdown.sh) /bin/sh: CONFIG_SHELL: command not found /bin/sh: TOPDIR: command not found All previous steps appeared to work without any problems, and I performed a 'make mrproper'. The build worked in 2.4.2-ac11 . Any suggestions? Regards, Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Drive corruption with VIA VT82C686A (ABIT KT7-RAID) - Still -
>VP_IDE: IDE controller on PCI bus 00 dev 39 >VP_IDE: chipset revision 16 >VP_IDE: not 100% native mode: will probe irqs later >ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx >VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 >ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio >ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio >hda: WDC WD205BA, ATA DISK drive >hdc: TOSHIBA DVD-ROM SD-M1202, ATAPI CD/DVD-ROM drive >ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 >ide1 at 0x170-0x177,0x376 on irq 15 >hda: 40088160 sectors (20525 MB) w/2048KiB Cache, CHS=2495/255/63, UDMA(33) >hdc: ATAPI 32X DVD-ROM drive, 256kB Cache, DMA ... >PCI: Found IRQ 10 for device 00:08.0 >PCI: The same IRQ used for device 00:07.2 >PCI: The same IRQ used for device 00:07.3 >3c59x.c:LK1.1.12 06 Jan 2000 Donald Becker and others. >http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ >See Documentation/networking/vortex.txt >eth0: 3Com PCI 3c905C Tornado at 0xdc00, 00:01:03:30:0f:3a, IRQ 10 > product code 'HN' rev 00.3 date 11-03-00 > 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. > MII transceiver found at address 24, status 782d. > Enabling bus-master transmits and whole-frame receives. ... >PCI: Found IRQ 10 for device 00:07.2 >PCI: The same IRQ used for device 00:07.3 >PCI: The same IRQ used for device 00:08.0 >uhci.c: USB UHCI at I/O 0xd400, IRQ 10 >uhci.c: detected 2 ports >usb.c: new USB bus registered, assigned bus number 1 >hub.c: USB hub found >hub.c: 2 ports detected >PCI: Found IRQ 10 for device 00:07.3 >PCI: The same IRQ used for device 00:07.2 >PCI: The same IRQ used for device 00:08.0 >uhci.c: USB UHCI at I/O 0xd800, IRQ 10 >uhci.c: detected 2 ports >usb.c: new USB bus registered, assigned bus number 2 >hub.c: USB hub found >hub.c: 2 ports detected ... >eth0: using NWAY autonegotiation >eth0: command 0x2800 took 33590 usecs! Please tell [EMAIL PROTECTED] >hda: DMA disabled >VFS: Disk change detected on device ide1(22,0) >hdc: DMA disabled I suggest moving your network card to a different PCI slot, which should partially resolve those IRQ conflicts and may improve reliability. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
[EMAIL PROTECTED] said:
> Here it is:
> http://oss.sgi.com/projects/postwait/
> Check out the download section for a 2.4.0 patch.
After having thought about this a bit more, I don't see why pw_post and
pw_wait can't be implemented in userspace as:
int pw_post(uid_t uid)
{
return(kill(uid, SIGHUP)) /* Or signal of the waiter's choice */
}
int pw_wait(struct timespec *t)
{
return(nanosleep(t, t));
}
In the case of UML, there would be a uid field in its lock structure and the
spin code would look like:
lock->uid = getpid();
pw_wait(NULL);
and the lock release code would be:
pw_post(lock->uid);
Obviously, sending signals to processes from the outside could massively
confuse matters, but I don't see that being a big problem, since I think you
can do that now, and no one is complaining about it.
Is there anything that I'm missing?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Incoming TCP TOS: A simple question, I would have thought...
getsockopt(fd, SOL_IP, IP_TOS, .. cheers, lincoln. At 03:00 PM 7/03/2001 +1100, David Luyer wrote: >I've scrolled through various code in net/ipv4, and I can't see how to query >the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which >initiated the connection). > >Someone has sent in a feature request for squid which would require this, >presumably so they can set the TOS in their routers and have the squid caches >honour the TOS to select performance (via delay pools, multiple parents, >different outgoing IP or similar). However I can't see how to get the TOS for >a TCP socket out of the kernel short of having an open raw socket watching for >SYNs and looking at the TOS on them. > >Any pointers? > >David. >-- >David LuyerPhone: +61 3 9674 7525 >Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 >Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 >http://www.pacific.net.au/ NASDAQ: PCNTF > > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Incoming TCP TOS: A simple question, I would have thought...
I've scrolled through various code in net/ipv4, and I can't see how to query the TOS of an incoming TCP stream (or at the least, the TOS of the SYN which initiated the connection). Someone has sent in a feature request for squid which would require this, presumably so they can set the TOS in their routers and have the squid caches honour the TOS to select performance (via delay pools, multiple parents, different outgoing IP or similar). However I can't see how to get the TOS for a TCP socket out of the kernel short of having an open raw socket watching for SYNs and looking at the TOS on them. Any pointers? David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
Jeremy Jackson wrote: > What the hell kind of monster are you making? There's got to be another way. heh. As I mentioned in my other response, we're doing TCP/IP load balance testing--so we need one linux system to act as many hosts. The only solution, short of using bind/connect/accept/etc with non-local IPs, is to use raw sockets (libpcap+libnet) and handle all of the TCP protocol layer in userland. For speed reasons, that's clearly not desireable, so I am seeking a kernel solution for acting as many hosts (10,000+) without having to bring up network interfaces for each one Kind of sick, isn't it? :) In any case we will definitely be pushing the 2.4 network code to the extreme. Regards, Bryan -- Bryan Rittmeyer mailto:[EMAIL PROTECTED] Ixia Communications 26601 W. Agoura Rd. Calabasas, CA 91302 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
In article <[EMAIL PROTECTED]>, Jamie Lokier <[EMAIL PROTECTED]> wrote: >Pavel Machek wrote: >> > the space allowed for arguments is not a userland issue, it is a kernel >> > limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one >> > wanted to without breaking any userland. >> >> Which is exactly what I done on my system. 2MB for command line is >> very nice. > >Mine too (until recently). A proper patch to remove the limit, and copy >the args into swappable memory as they go (to avoid DoS) would be nicer, >but a quick change to MAX_ARG_PAGES seemed so much easier :-) You can't just change MAX_ARG_PAGES. The space for the array is allocated on the stack, and you'll just overflow the stack if you start upping it a lot. The long-term solution for this is to create the new VM space for the new process early, and add it to the list of mm_struct's that the swapper knows about, and then just get rid of the pages[MAX_ARG_PAGES] array completely and instead just populate the new VM directly. That way the destination is swappable etc, and you can also remove the "put_dirty_page()" loop later on, as the pages will already be in their right places. It's definitely not a one-liner, but if somebody really feels strongly about this, then I can tell already that the above is the only way to do it sanely. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Error compiling aic7xxx driver on 2.4.2-ac13
I actually had the problem with lack-of-lex also, but worked through that... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alan Cox Sent: Tuesday, March 06, 2001 4:51 PM To: J . A . Magallon Cc: Phil Oester; [EMAIL PROTECTED] Subject: Re: Error compiling aic7xxx driver on 2.4.2-ac13 > Which distro is yours ? In my Mandrake 8.0beta there is no /usr/include/db. > Mdk offers the 3 db libs (db1, db2, db3), so I had to create a symlink > /usr/include/db3 -> /usr/include/db. > > Which is the standard path ? At least, Mdk and RH (Alan...) differ. Im not too worried about this right now since as Al Viro pointed out the libdb use is unneeded. The irony of all this was that the real concern Justin had and discussed with people was about lex/bison/yacc being available, and the problem has been db - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
Gregory Maxwell wrote:
> I didn't pick-up on the fact that you planned on have other computers
> listening with those addresses.
We won't--without getting into the specifics (NDA) we are developing a
TCP/IP load balance tester that needs to act--similtaneously--as many
machines. It is certainly not designed to run on your average LAN, but
rather on a carefully prepared test network using data assigned by a
user who (presumably) has ensured the IPs we are using are not already
assigned to other machines.
> This won't work without support from your routing device if you actually
> have hosts on the addresses, just because of ARP.
We have hacks in place for promiscous ARPing on any of the IPs we may
want to use :)
So, if I configure the interface as suggested ("/sbin/ip addr add
10.0.0.0/24 dev eth0") can I really bind to any IP in 10.0.0.0/24 and
conduct TCP sessions (as a client or server) using that IP--assuming all
the ARP, etc, issues are worked out?
Regards,
Bryan
--
Bryan Rittmeyer
mailto:[EMAIL PROTECTED]
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: eject weirdness on NEC disc changer, kernel 2.4.2
From: Walter Hofmann ([EMAIL PROTECTED]) Date: Mon Mar 05 2001 - 15:19:10 EST >> cancelling a burn session with cdrecord I am unable to eject the disc. >> However that was on kernel 2.2.x and using "real" scsi (not ide-scsi). >This was a bug in cdrecord which used generic scsi access to lock the >drive. The kernel cannot notice this. AFAIK this bug is fixed in >cdrecord. K, thanks. I will have to upgrade once I figure out why my burner box just beeps at me when I try to turn it on. ;-\ So, anybody know what is up with the kernel? :) Again the issue I originally posted about is a problem with standard ATAPI stuff (not ide-scsi). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 ext2 filesystem corruption ? (was 2.4.2: What happened ? (No
Alan Cox wrote: > > > running a bad hdparm command while running a full GNOME desktop: > > (This was not a good idea...and I know, and knew that...but) > > > > hdparm -X34 -d1 -u1 /dev/hda > > (As found here: http://www.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html?page=2 > > > > Sorry for the lame bug report, but I'm scared to try it again, and > > I didn't realize the complexity of the problem when I simply powered > > down my machine with the HD light on solid... > > Its not a bug. As the system administrator you reconfigured a hard disk on > the fly and shit happened. The hdparm man page warnings do exist for a reason. I'm not arguing it was a smart thing to do, but I would think that the fs/kernel/driver writers could keep really nasty and un-expected things from happenning. For instance, the driver could dis-allow any new (non-hdparm) writes while hdparm is doing it's test. Or maybe the driver could realize it was being told to do something that would break and just not do it? Considering this disk is my root disk, is there *any* safe way to test out hdparm on this disk? Enjoy, Ben > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com Author of ScryMUD: scry.wanfear.com (Released under GPL) http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac12
On Tue, 6 Mar 2001, Alan Cox wrote: > > I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE > > stage it just reboots. > > Does ac11 also reboot like that. -ac is currently testing versions of the new > VIA IDE driver so knowing if the latest update did that would be very > useful > Stock 2.4.2 kernel. It (so far), hasn't happened again .. the drive led is still screwed though. It's weird, the other drives seem to seek at odd times too (like when they aren't even mounted). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 - do_try_to_free_pages failed
In mailing-lists.linux-kernel, you wrote: > I know that 2.2.19 is still in the -pre state. [ . . . ] Have > significant VM problems been fixed? Yes, 2.2.19-pre incorporates what was known as Andrea's VM-global patch, and it is widely reported to fix the exact problem you mentioned. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 - do_try_to_free_pages failed
> I know that 2.2.19 is still in the -pre state. Is it that much > better? Have significant VM problems been fixed? Yes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
Jeff Dike wrote:
[ ... ]
>
> > Another synchronization method popular with database peeps is "post/
> > wait" for which SGI have a patch available for Linux. I understand
> > that this is relatively "light weight" and might be a better choice
> > for PG.
>
> URL?
>
> Jeff
Here it is:
http://oss.sgi.com/projects/postwait/
Check out the download section for a 2.4.0 patch.
cheers,
ananth.
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
On Tue, 6 Mar 2001, Andrew Morton wrote: > With respect, Rik. You haven't finished the 2.4 VM yet. > > It needs better design description. > Could you please take the time to raise a commentary patch > which describes the underlying design intent? OK, I'll go work on this... You are right, this is an extremely important thing. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 - do_try_to_free_pages failed
Thiago, I know that 2.2.19 is still in the -pre state. Is it that much better? Have significant VM problems been fixed? Thanks. David At 08:48 PM 3/6/01, Thiago Rondon wrote: > > Mar 6 16:35:32 osage kernel: VM: do_try_to_free_pages failed for kswapd... > >Update your kernel to 2.2.19 and try again. > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
Mike Fedyk wrote: > > [snip] > > > > /sbin/ip addr add 10.2.0.0/24 dev eth0 > > > > Tada > How would you deal with the other computer responding to the host "port not > reachable"? What the hell kind of monster are you making? There's got to be another way. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
At 5:01 PM -0600 3/6/2001, Oliver Xymoron wrote:
>On Fri, 2 Mar 2001, David S. Miller wrote:
>
>> > On PPC, we don't have an "IO" space neither, all we have is a range of
>> > memory addresses that will cause IO cycles to happen on the PCI bus.
>>
>> This is precisely what the "next MMAP is XXX space" ioctl I've
>> suggested is for. I think I've addressed this concern in my
>> proposal already. Look:
>>
>> fd = open("/proc/bus/pci/${BUS}/${DEV}", ...);
>> if (fd < 0)
>> return -errno;
>> err = ioctl(fd, PCI_MMAP_IO, 0);
>
>I know I'm coming in on this late, but wouldn't it be cleaner to have
>separate files for memory and io cycles, eg ${BUS}/${DEV}.(io|mem)?
>They're logically different so they might as well be embodied separately.
If I were designing this (and I'm not), I would do it as thus:
/proc/bus/pci/${BUS}/${DEV} is same as it always is
/proc/bus/pci/${BUS}/${DEV}.d/io.n for IO resources, where n is the number
of the IO resource
/proc/bus/pci/${BUS}/${DEV}.d/mem.n for Mem resouces, where n is...
/proc/bus/pci/${BUS}/${DEV}.d/ints for interrupts, which would block on
read when there are no interrupts pending, and after an interrupt is
triggered the data read would be some sort of information about the
interrupt.
And that should (in theory) be all you need for writing a basic userspace
PCI device driver. (You wouldn't really be able to set up DMA or such, but
at that point I think "put the damn driver in the kernel" would be an
appropriate utterance)
This is just off the top of my head, so no warranties expressed or implied
about the sanity of this kind of system.
Come to think of it, is /proc really the best place to put all this stuff?
It would be a pain to put it in /dev and mess with assigning majors and
minors and making sure all the special devices get created and stuff...
Makes me wish Linux had an /hw fs like on IRIX. (I suppose devfs is close,
but I don't personally like the idea of completely replacing /dev with an
automatic filesystem)
Anyways...
Cheers - Tony 'Nicoya' Mantler :)
--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - [EMAIL PROTECTED]
Winnipeg, Manitoba, Canada -- http://nicoya.feline.pp.se/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
On Tue, Mar 06, 2001 at 05:46:39PM -0800, Mike Fedyk wrote: > Gregory Maxwell wrote: > > > > On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: > > > Hello linux-kernel, > > > > > > Is there any way to conduct TCP sessions (IE have a userland process > > > connect out, or accept connections) using non-local IPs? By "non-local" > > > I just mean IPs that aren't assigned to an interface, but do fall into > > > the network range of a running interface (so netmask, gateway, etc are > > > "known"). > > > > > > For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 > > > and assign it IP 10.0.0.1 Then, I want a process to accept TCP > > [snip] > > > > /sbin/ip addr add 10.2.0.0/24 dev eth0 > > > > Tada > How would you deal with the other computer responding to the host "port not > reachable"? I didn't pick-up on the fact that you planned on have other computers listening with those addresses. This won't work without support from your routing device if you actually have hosts on the addresses, just because of ARP. You can make this work, if, you can control and configure the router 1. You can configure your router to direct the needed ports to your Linux box and not the real hosts. (Linux can do this) If you can firewall on the victim boxes, you could block their 'not reachable' reply, but that doesn't solve ARP. You could probably make a trivial change to Linux and run it in promiscuous mode to achieve this. It's more likely the first will be a better option for you. What are you doing anyways? :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
[EMAIL PROTECTED] said: > If you're a UP system, it never makes sense to spin in userland, since > you'll just burn up a timeslice and prevent the lock holder from > running. I haven't looked, but assume that their code only uses > spinlocks on SMP. If you're an SMP system, then you shouldn't be using > a spinlock unless the critical section is "short", in which case the > waiters should simply spin in userland rather than making system calls > which is simply overhead. This is a problem that UML is going to have when I turn SMP back on. Emulating a multiprocessor box on a UP host with the existing locking primitives is going to result in exactly this problem. > Actually, what's really needed here is an efficient form of > dynamically marking a process as non-preemptible so that when > acquiring a spinlock the process can ensure that it exits the critical > section as fast as possible, when it would relinquish its > non-preemptible privilege. That sounds like a pretty fundamental (and abusable) mechanism. I had a suggestion from an IBM guy at ALS last year to make UML "spin"-locks actually sleep in the host (this doesn't make them sleep locks in userspace because they don't call schedule), which sounds reasonable. This gives the lock-holder an opportunity to run immediately. It's unclear to me what the wake-up mechanism would be, though. Another thought I had was to raise the priority of a thread holding a spinlock. This would reduce the chance that it would be preempted by a thread that will waste a timeslice spinning on that lock. I don't know whether this is a good idea either. > Another synchronization method popular with database peeps is "post/ > wait" for which SGI have a patch available for Linux. I understand > that this is relatively "light weight" and might be a better choice > for PG. URL? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Forcible removal of modules
On Tue, 6 Mar 2001 14:17:28 -0800 (PST), Thomas Hood <[EMAIL PROTECTED]> wrote: >My question is: Is there some better way of blocking >all open() calls to a particular device driver while >processes using it are being killed off? Not yet. There have been some off list discussions about redoing the module load/unload process to avoid races, as part of that we will get forced module unregister followed by unload when the use count goes to zero. Probably 2.5 changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IP autoconfig via DHCP?
Quick question... Back in 2.2, we could use DHCP to auto-config the IP setup. In fact, the choice was DHCP, BOOTP or RARP. Now there is only BOOTP or RARP. What happened to DHCP support? Later, Kenn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux installation problem (Microchannel)
> >Standard Red Hat has no MCA support (sorry much as I love my PS/2 its >rather >hard to make an honest business case for the huge amount of extra work to >build MCA boot disks/CD images). Debian I believe should install >straight >out >of the box on most MCA bus PC systems > >Alan > Hard if you want to pretend you're Microsoft. MCA may still be interesting for a bottom-feeder strategy. There are apparently still millions of them in storage. It seems the powers that be have made it harder for accountable organizations to discard computers, due to the lead content and so on. I have come off them myself, but the MAD types (Microchannel Affection Disorder) on Usenet still do strange things like upgrade thier CPUs and so on. My Microchannel stuff is in ftp://ftp.gwdg.de/pub/linux/install/clienux/MCA/ including what I believe was the first 2.88meg rawwrite. cLIeNUX was up until recently built on a 9595. The worst afflicted MAD individual is probably Charles Lasitter (one s) [EMAIL PROTECTED] . His MCA cLIeNUX spin-off should still cater to MCA quite nicely. Regular cLIeNUX should still install on MCA, I think, and is one dir up from the above URL. The newsgroup is comp.sys.ibm.ps2.hardware. Rick Hohensee www.clienux.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
Gregory Maxwell wrote: > > On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: > > Hello linux-kernel, > > > > Is there any way to conduct TCP sessions (IE have a userland process > > connect out, or accept connections) using non-local IPs? By "non-local" > > I just mean IPs that aren't assigned to an interface, but do fall into > > the network range of a running interface (so netmask, gateway, etc are > > "known"). > > > > For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 > > and assign it IP 10.0.0.1 Then, I want a process to accept TCP > [snip] > > /sbin/ip addr add 10.2.0.0/24 dev eth0 > > Tada How would you deal with the other computer responding to the host "port not reachable"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 - do_try_to_free_pages failed
> Mar 6 16:35:32 osage kernel: VM: do_try_to_free_pages failed for kswapd... Update your kernel to 2.2.19 and try again. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Drive corruption with VIA VT82C686A (ABIT KT7-RAID) - Still -
tried both 2.4.3-pre2 and 2.4.2-ac12. Same results with each. Let me know which reports are most important so I don't post more than necassary. I was able to get lspci -vvxxx, dmesg, hdparm -i, cat/proc/ide/via. I did notice it is detecting a 40w cable even though I am using a 80w. Could that possibly be the problem? Although I have tried switching cables and had the same problem. As soon as the drive has to do any work (hdparm -tT /dev/hda, cp'ing, mv'ing) the system will lock. I can get the drive working after a few fsck's in 2.2.16 but if I were to try booting into 2.4.x and running fsck I will soon get lost inodes and the system will fail to operate. Please CC me with responses. I am not subscribed to the list. Thanks Jeff Garzik wrote: > If you haven't already, would it be possible for you to try two patches > for 2.4.2 (separately)? > > Linus' latest testing patch, 2.4.3-pre2, is available from > ftp://ftp..kernel.org/pub/linux/kernel/testing/ > > Alan Cox's latest patchkit, 2.4.2-ac12, is available from > ftp://ftp..kernel.org/pub/linux/kernel/people/alan/2.4/ > > Both of these, actually, have the potential for solving your problem. > It would greatly help, IMHO, if you could try 2.4.3-pre2 and 2.4.2-ac12 > and compare the results you see with 2.4.2 kernel. > > Best regards, > > Jeff > > > Linux version 2.4.3-pre2 (root@hades) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Tue Mar 6 09:32:38 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 00e0 @ 0010 (usable) BIOS-e820: 0010 @ 00f0 (reserved) BIOS-e820: 06ff @ 0100 (usable) BIOS-e820: d000 @ 07ff3000 (ACPI data) BIOS-e820: 3000 @ 07ff (ACPI NVS) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. mapped APIC to e000 (01223000) Kernel command line: BOOT_IMAGE=Linux-2.4 ro root=305 mem=128M Initializing CPU#0 Detected 800.060 MHz processor. Console: colour VGA+ 80x34 Calibrating delay loop... 1595.80 BogoMIPS Memory: 126040k/131072k available (1389k kernel code, 4644k reserved, 542k data, 220k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Duron(tm) Processor stepping 00 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Bus master read caching disabled PCI: Using IRQ router VIA [1106/0686] at 00:07.0 isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 83701kB/27900kB, 256 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio hda: WDC WD205BA, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-M1202, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 40088160 sectors (20525 MB) w/2048KiB Cache, CHS=2495/255/63, UDMA(33) hdc: ATAPI 32X DVD-ROM drive, 256kB Cache, DMA Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) Serial driver version 5.02 (2000-08-09) with
Re: Interesting fs corruption story
On 06 Mar 2001 17:01:02 -0800, Tim Wright wrote: > Hi Ettore, > I have no idea if this is related to your problem since you didn't mention > that key part, but with the same drive, I managed to trash my root partition > incredibly badly by trying to use DMA and then do APM suspend or hibernate. > On wakeup, I'd get an 'hda: lost interrupt' but then things would appear to > carry on. > > The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS > was enabled. So, do you ever use power management and is this similar, or do > you have a completely different problem ? Wow, this sounds like this might be the problem. I just checked my `.config' and indeed `CONFIG_APM_ALLOW_INTS' is not enabled. And indeed I have been suspending/resuming the machine a few times before the partition got corrupted. So, does DMA work correctly on your system after setting this option? I have now disabled it completely as a safety measure (and as suggested by somebody else on this list), and indeed I have not had any more troubles for now. (I have been forcing a fsck every day before turning the machine off.) Thanks a lot for the hint! I will now rebuild my kernel with that option turned on. -- Ettore - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi
Chip,
I thought O grabbed that from you...
On Tue, 6 Mar 2001, Chip Salzenberg wrote:
> With Andre's IDE subsystem, I found the below patch necessary to use
> my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long
> since I created this patch that I can't remember the detailed reasons
> for the changes. But I knew them once. :-) And it works for me.
>
> Reminder, this is against Andre Hedrick's 2.2 IDE subsystem.
>
> Index: drivers/block/ide-tape.c
> --- drivers/block/ide-tape.c.prev
> +++ drivers/block/ide-tape.c Tue Dec 5 01:17:32 2000
> @@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr
> static int idetape_flush_tape_buffers (ide_drive_t *drive)
> {
> + idetape_tape_t *tape = drive->driver_data;
> idetape_pc_t pc;
> int rc;
>
> + if (tape->chrdev_direction != idetape_direction_write)
> + return 0;
> idetape_create_write_filemark_cmd(drive, , 0);
> if ((rc = idetape_queue_pc_tail (drive,)))
> @@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i
> if (tape->chrdev_direction == idetape_direction_none) {
> MOD_INC_USE_COUNT;
> + if (tape->onstream) {
> #if ONSTREAM_DEBUG
> - if (tape->debug_level >= 6)
> - printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in
>idetape_chrdev_open-2\n");
> + if (tape->debug_level >= 6)
> + printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT"
> +" in idetape_chrdev_open-2\n");
> #endif
> - idetape_create_prevent_cmd(drive, , 1);
> - if (!idetape_queue_pc_tail (drive,)) {
> - if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
> - tape->door_locked = DOOR_LOCKED;
> + idetape_create_prevent_cmd(drive, , 1);
> + if (!idetape_queue_pc_tail (drive,)) {
> + if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
> + tape->door_locked = DOOR_LOCKED;
> + }
> }
> idetape_analyze_headers(drive);
> @@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc
> (void) idetape_rewind_tape (drive);
> if (tape->chrdev_direction == idetape_direction_none) {
> - if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
> - idetape_create_prevent_cmd(drive, , 0);
> - if (!idetape_queue_pc_tail (drive,))
> - tape->door_locked = DOOR_UNLOCKED;
> - }
> - MOD_DEC_USE_COUNT;
> + if (tape->onstream) {
> + if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
> + idetape_create_prevent_cmd(drive, , 0);
> + if (!idetape_queue_pc_tail (drive,))
> + tape->door_locked = DOOR_UNLOCKED;
> + }
> #if ONSTREAM_DEBUG
> - if (tape->debug_level >= 6)
> - printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in
>idetape_chrdev_release\n");
> + if (tape->debug_level >= 6)
> + printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT"
> +" in idetape_chrdev_release\n");
> #endif
> + }
> + MOD_DEC_USE_COUNT;
> }
> clear_bit (IDETAPE_BUSY, >flags);
>
> --
> Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Interesting fs corruption story
Hi Ettore, I have no idea if this is related to your problem since you didn't mention that key part, but with the same drive, I managed to trash my root partition incredibly badly by trying to use DMA and then do APM suspend or hibernate. On wakeup, I'd get an 'hda: lost interrupt' but then things would appear to carry on. The fix for me was to rebuild the kernel and make sure CONFIG_APM_ALLOW_INTS was enabled. So, do you ever use power management and is this similar, or do you have a completely different problem ? Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Error compiling aic7xxx driver on 2.4.2-ac13
> Which distro is yours ? In my Mandrake 8.0beta there is no /usr/include/db. > Mdk offers the 3 db libs (db1, db2, db3), so I had to create a symlink > /usr/include/db3 -> /usr/include/db. > > Which is the standard path ? At least, Mdk and RH (Alan...) differ. Im not too worried about this right now since as Al Viro pointed out the libdb use is unneeded. The irony of all this was that the real concern Justin had and discussed with people was about lex/bison/yacc being available, and the problem has been db - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
Ying- I'm a little confused here. It's very hard to compare a UP application vs. the same app. converted to use threads. Unless the app. is structured such that multiple threads can run at the same time then no, you won't see any improvement by going to SMP, in fact a true single threaded app. will frequently slow down when run on an SMP kernel. Have you watched a CPU meter while your benchmark runs? Even something basic like `top' should give you a feel for whether or not your using all of the CPU's. On Tue, Mar 06, 2001 at 03:55:55PM -0800, Ying Chen wrote: > Hi, > > I have two questions on Linux pthread related issues. Would anyone be able > to help? > > ... > > 2. We ran multi-threaded application using Linux pthread library on 2-way > SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see > significant increase in context switching when moving from UP to SMP, and > high CPU usage with no performance gain in turns of actual work being done > when moving to SMP, despite the fact the benchmark we are running is > CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks > went to scheduling and signaling overheads. Has anyone seen something like > this before with pthread applications running on SMP platforms? Any > suggestions or pointers on this subject? > > Thanks a lot! > > Ying > > > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Error compiling aic7xxx driver on 2.4.2-ac13
> make[5]: Entering directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' > lex -t aicasm_scan.l > aicasm_scan.c > gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm_symbol.c:39: db/db_185.h: No such file or directory You need db3/db3-devel installed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
Pavel Machek wrote: > > the space allowed for arguments is not a userland issue, it is a kernel > > limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one > > wanted to without breaking any userland. > > Which is exactly what I done on my system. 2MB for command line is > very nice. Mine too (until recently). A proper patch to remove the limit, and copy the args into swappable memory as they go (to avoid DoS) would be nicer, but a quick change to MAX_ARG_PAGES seemed so much easier :-) In my case, it was a Makefile generating the huge command lines. There were about 2 source files and 8 target files, and the occasional long line "update the archive with these changed files: ..." ;-) Splitting the file name list seemed so much more difficult. You can't even do "echo $(FILES) | xargs", as the "echo" command line is too long! -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18 IDE tape problem, with ide-scsi
With Andre's IDE subsystem, I found the below patch necessary to use
my IDE tape drive (Exabyte Eagle TR-4). Frankly, it's been so long
since I created this patch that I can't remember the detailed reasons
for the changes. But I knew them once. :-) And it works for me.
Reminder, this is against Andre Hedrick's 2.2 IDE subsystem.
Index: drivers/block/ide-tape.c
--- drivers/block/ide-tape.c.prev
+++ drivers/block/ide-tape.cTue Dec 5 01:17:32 2000
@@ -3096,7 +3096,10 @@ static int idetape_queue_pc_tail (ide_dr
static int idetape_flush_tape_buffers (ide_drive_t *drive)
{
+ idetape_tape_t *tape = drive->driver_data;
idetape_pc_t pc;
int rc;
+ if (tape->chrdev_direction != idetape_direction_write)
+ return 0;
idetape_create_write_filemark_cmd(drive, , 0);
if ((rc = idetape_queue_pc_tail (drive,)))
@@ -5199,12 +5202,15 @@ static int idetape_chrdev_open (struct i
if (tape->chrdev_direction == idetape_direction_none) {
MOD_INC_USE_COUNT;
+ if (tape->onstream) {
#if ONSTREAM_DEBUG
- if (tape->debug_level >= 6)
- printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT in
idetape_chrdev_open-2\n");
+ if (tape->debug_level >= 6)
+ printk(KERN_INFO "ide-tape: MOD_INC_USE_COUNT"
+ " in idetape_chrdev_open-2\n");
#endif
- idetape_create_prevent_cmd(drive, , 1);
- if (!idetape_queue_pc_tail (drive,)) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
- tape->door_locked = DOOR_LOCKED;
+ idetape_create_prevent_cmd(drive, , 1);
+ if (!idetape_queue_pc_tail (drive,)) {
+ if (tape->door_locked != DOOR_EXPLICITLY_LOCKED)
+ tape->door_locked = DOOR_LOCKED;
+ }
}
idetape_analyze_headers(drive);
@@ -5258,14 +5264,17 @@ static int idetape_chrdev_release (struc
(void) idetape_rewind_tape (drive);
if (tape->chrdev_direction == idetape_direction_none) {
- if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
- idetape_create_prevent_cmd(drive, , 0);
- if (!idetape_queue_pc_tail (drive,))
- tape->door_locked = DOOR_UNLOCKED;
- }
- MOD_DEC_USE_COUNT;
+ if (tape->onstream) {
+ if (tape->door_locked != DOOR_EXPLICITLY_LOCKED) {
+ idetape_create_prevent_cmd(drive, , 0);
+ if (!idetape_queue_pc_tail (drive,))
+ tape->door_locked = DOOR_UNLOCKED;
+ }
#if ONSTREAM_DEBUG
- if (tape->debug_level >= 6)
- printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT in
idetape_chrdev_release\n");
+ if (tape->debug_level >= 6)
+ printk(KERN_INFO "ide-tape: MOD_DEC_USE_COUNT"
+ " in idetape_chrdev_release\n");
#endif
+ }
+ MOD_DEC_USE_COUNT;
}
clear_bit (IDETAPE_BUSY, >flags);
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
On Tue, Mar 06, 2001 at 11:39:17PM +, Matthew Kirkwood wrote:
> On Tue, 6 Mar 2001, Jonathan Lahr wrote:
>
> [ sorry to reply over another reply, but I don't have
> the original of this ]
>
> > > Tridge and I tried out the postgresql benchmark you used here and this
> > > contention is due to a bug in postgres. From a quick strace, we found
> > > the threads do a load of select(0, NULL, NULL, NULL, {0,0}).
>
> I can shed some light on this (though I'm far from a PG hacker).
>
> Postgres can use either of two locking methods -- SysV semaphores
> (which it tries to avoid, asusming that they'll be too heavy) or
> userspace spinlocks (via inline assembler on platforms which support
> it).
>
> In the slow path of a spinlock_acquire they busy wait for a few
> cycles, and then call schedule with a zero timeout assuming that
> it'll basically do the same as a sched_yield() but more portably.
>
Ugh !
I had a nasty feeling that might be what they were up to. The reason for
the "ugh" is as follows. If you're a UP system, it never makes sense to
spin in userland, since you'll just burn up a timeslice and prevent the
lock holder from running. I haven't looked, but assume that their code only
uses spinlocks on SMP. If you're an SMP system, then you shouldn't be
using a spinlock unless the critical section is "short", in which case the
waiters should simply spin in userland rather than making system calls which
is simply overhead. If the argument is that the "spinners" take too much
useful time away from other processes, then it sounds like the contention is
too high, or that the critical section is sufficiently long that semaphores
would be a better choice.
Actually, what's really needed here is an efficient form of dynamically
marking a process as non-preemptible so that when acquiring a spinlock the
process can ensure that it exits the critical section as fast as possible,
when it would relinquish its non-preemptible privilege.
Another synchronization method popular with database peeps is "post/wait"
for which SGI have a patch available for Linux. I understand that this is
relatively "light weight" and might be a better choice for PG.
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Error compiling aic7xxx driver on 2.4.2-ac13
Phil Oester wrote: > > one more try... > > anyone else get the following: > > make[5]: Entering directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' > lex -t aicasm_scan.l > aicasm_scan.c > gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm_symbol.c:39: db/db_185.h: No such file or directory > make[5]: *** [aicasm] Error 1 > make[5]: Leaving directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' The location of db_185.h is somewhat vendor dependent. In my case (Mandrake cooker), the location is in /usr/include/db3 rather than /usr/include/db. You have a couple of choices for now... symlink db3 to db if that is your situation or back out that portion of the patch to use the original db1 library. I personally chose the symlink, but it does highlight the problem of having userspace dependencies in the tree... John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: threads
On 03.07 Ying Chen wrote: > 2. We ran multi-threaded application using Linux pthread library on 2-way > SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see > significant increase in context switching when moving from UP to SMP, and > high CPU usage with no performance gain in turns of actual work being done > when moving to SMP, despite the fact the benchmark we are running is > CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks > went to scheduling and signaling overheads. Has anyone seen something like > this before with pthread applications running on SMP platforms? Any > suggestions or pointers on this subject? > Too much contention ? How frequently do you create and destroy threads ? How much frequently do they access shared-writable-data ? How do you protect them ? It seems like your system spents more time creating and killing threads that doing real work. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac13 #3 SMP Wed Mar 7 00:09:17 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch][rfc][rft] vm throughput 2.4.2-ac4
On Fri, 2 Mar 2001, Mike Galbraith wrote: > On Thu, 1 Mar 2001, Rik van Riel wrote: > > > > > The merging at the elevator level only works if the requests sent to > > > > it are right next to each other on disk. This means that randomly > > > > sending stuff to disk really DOES DESTROY PERFORMANCE and there's > > > > nothing the elevator could ever hope to do about that. > > > > > > True to some (very real) extent because of the limited buffering > > > of requests. However, I can not find any useful information > > > that the vm is using to guarantee the IT does not destroy > > > performance by your own definition. > > > > Indeed. IMHO we should fix this by putting explicit IO > > clustering in the ->writepage() functions. > > I notice there's a patch sitting in my mailbox.. think I'll go read > it and think (grunt grunt;) about this issue some more. Mike, One important information which is not being considered by page_launder() now the dirty buffers watermark. In general, it should not try to avoid writing dirty pages if we're above the dirty buffers watermark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Error compiling aic7xxx driver on 2.4.2-ac13
>make[5]: Entering directory >`/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' >lex -t aicasm_scan.l > aicasm_scan.c >gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c >aicasm_symbol.c -o aicasm >aicasm_symbol.c:39: db/db_185.h: No such file or directory >make[5]: *** [aicasm] Error 1 >make[5]: Leaving directory >`/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' Is it prudent to build the assembler from within the kernel build? I'd personally love to ditch the aic7xxx_seq.h and aic7xxx_reg.h files from the kernel distribution and I even have the makefiles for version 6.1.6 of the driver. The only question is, with so many distributions out there can we rely on lex, yacc, and berkeley DB existing on the host system? As to your *real* problem. My guess is that the dependency to regenerate the files is getting hit. This often happens during a patch upgrade where only one of the two generated files is updated. If you touch aic7xxx_reg.h and aic7xxx_seq.h the build will work fine. Alternatively, you can figure out how to get Berekeley DB installed on your system. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.2.18 - do_try_to_free_pages failed
This is my first report of a kernel crash, so if there is more information wanted, please let me know and I'll do my best to supply it. I'm running Mandrake 7.2 with a 2.2.18 kernel and GNOME, PIII 500 mhz, 256MB ram, AIC789x SCSI on mobo, Fujitsu 18GB scsi HD, ATI video card. This evening, xscreensaver crashed with a message saying (roughly): "xscreensaver hypercube had(?) a SIGSEGV" I had to power down the machine and restart it. From /var/log/messages the last message before the reboot and the first message after the reboot are: Mar 6 16:35:32 osage kernel: VM: do_try_to_free_pages failed for kswapd... Mar 6 17:13:04 osage syslogd 1.4-0: restart. 2.2.18 has run for as long as 71 days on this machine (at which point I restarted it to include the Sangoma WANROUTER driver, which was NOT running at the time of the crash). I'll be glad to supply any additional info/files. Just let me know what's wanted. David David Relson Osage Software Systems, Inc. [EMAIL PROTECTED] Ann Arbor, MI 48103 www.osagesoftware.com tel: 734.821.8800 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Error compiling aic7xxx driver on 2.4.2-ac13
On 03.07 Phil Oester wrote: > one more try... > > anyone else get the following: > > make[5]: Entering directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' > lex -t aicasm_scan.l > aicasm_scan.c > gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c > aicasm_symbol.c -o aicasm > aicasm_symbol.c:39: db/db_185.h: No such file or directory > make[5]: *** [aicasm] Error 1 > make[5]: Leaving directory > `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' > Which distro is yours ? In my Mandrake 8.0beta there is no /usr/include/db. Mdk offers the 3 db libs (db1, db2, db3), so I had to create a symlink /usr/include/db3 -> /usr/include/db. Which is the standard path ? At least, Mdk and RH (Alan...) differ. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac13 #3 SMP Wed Mar 7 00:09:17 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
Hi, I have two questions on Linux pthread related issues. Would anyone be able to help? 1. Does any one have some suggestions (pointers) on good kernel Linux thread libraries? 2. We ran multi-threaded application using Linux pthread library on 2-way SMP and UP intel platforms (with both 2.2 and 2.4 kernels). We see significant increase in context switching when moving from UP to SMP, and high CPU usage with no performance gain in turns of actual work being done when moving to SMP, despite the fact the benchmark we are running is CPU-bound. The kernel profiler indicates that the a lot of kernel CPU ticks went to scheduling and signaling overheads. Has anyone seen something like this before with pthread applications running on SMP platforms? Any suggestions or pointers on this subject? Thanks a lot! Ying _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v2.4.1-v2.4.3pre2 doesnt power off by halt or shutdown -h
Hello i have such problem, with 2.2.17 halt or shutdown -h - are ok. but with 2.4.1, 2.4.2, 2.4.3-pre2 aren`t. maybe i make wrong .config? # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set CONFIG_M686=y # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set 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_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_X86_PAE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_PM=y # CONFIG_ACPI is not set CONFIG_APM=y CONFIG_APM_IGNORE_USER_SUSPEND=y CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_DISPLAY_BLANK=y CONFIG_APM_RTC_IS_GMT=y CONFIG_APM_ALLOW_INTS=y CONFIG_APM_REAL_MODE_POWER_OFF=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_ROUTE_LARGE_TABLES=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y # CONFIG_IP_PIMSM_V1 is not set # CONFIG_IP_PIMSM_V2 is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set # CONFIG_IP_NF_IPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NET_SCH_CBQ=y # CONFIG_NET_SCH_CSZ is not set CONFIG_NET_SCH_PRIO=y # CONFIG_NET_SCH_RED is not set CONFIG_NET_SCH_SFQ=y # CONFIG_NET_SCH_TEQL is not set CONFIG_NET_SCH_TBF=y # CONFIG_NET_SCH_GRED is not set CONFIG_NET_SCH_DSMARK=y CONFIG_NET_SCH_INGRESS=y CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=y CONFIG_NET_CLS_ROUTE4=y CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_U32=y CONFIG_NET_CLS_RSVP=y CONFIG_NET_CLS_RSVP6=y CONFIG_NET_CLS_POLICE=y # # Telephony Support # # CONFIG_PHONE is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set #
Re: spinlock help
On Tue, 6 Mar 2001, Manoj Sontakke wrote: > 1. when spin_lock_irqsave() function is called the subsequent code is > executed untill spin_unloc_irqrestore()is called. is this right? Yes. The protected code will not be interrupted, or simultaneously executed by another CPU. > 2. is this sequence valid? > spin_lock_irqsave(a,b); > spin_lock_irqsave(c,d); Yes, as long as it is followed by: spin_unlock_irqrestore(c, d); spin_unlock_irqrestore(a, b); Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
Rik van Riel wrote: > > On Tue, 6 Mar 2001, Alan Cox wrote: > > > I'm getting a notable increase in people sending me patches that > > do major things and should be 2.5 stuff. Please if you want to > > rewrite the VM completely, redesign the scsi layer and the like > > wait until 2.5. > > VM folks can post their patches to [EMAIL PROTECTED], where > we can play with things until 2.5 is forked. > With respect, Rik. You haven't finished the 2.4 VM yet. It needs better design description. I've been reading through it lately, and in some parts it is very, very hard to go backwards from the implementation to the designer's intent. Let's take just one line: count = inactive_shortage() + free_shortage(); That expands to, approximately, sometimes: inactive_shortage(): freepages.high + inactive_target - nr_free_pages() - nr_inactive_clean_pages() - nr_inactive_dirty_pages; plus free_shortage(): (freepages.high + inactive_target / 3) - (nr_free_pages() + nr_inactive_clean_pages()) IOW: 2 * freepages.high + 1.33*(min((memory_pressure >> INACTIVE_SHIFT), (num_physpages / 4))) - 2 * nr_free_pages() - 2 * nr_inactive_clean_pages() - nr_inactive_dirty_pages That's not a thing which just leaps out at me and shouts "ah-ha!" :) Across the lifetime of 2.4, other people are going to need to understand this stuff. To be able to analyse and even predict how the VM dynamics will change with varying tuning, varying workload and varying platform characteristics. There *is* a fair quantity of good design description in there, but there are gaps. Could you please take the time to raise a commentary patch which describes the underlying design intent? I'd strongly recommend *against* some offstream document (it doesn't get updated) or API documentation (usually lame and useless). Inline description is much more useful and better maintained. Thanks - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Error compiling aic7xxx driver on 2.4.2-ac13
one more try... anyone else get the following: make[5]: Entering directory `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' lex -t aicasm_scan.l > aicasm_scan.c gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db/db_185.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac13/drivers/scsi/aic7xxx/aicasm' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
On Tue, 6 Mar 2001, Jonathan Lahr wrote:
[ sorry to reply over another reply, but I don't have
the original of this ]
> > Tridge and I tried out the postgresql benchmark you used here and this
> > contention is due to a bug in postgres. From a quick strace, we found
> > the threads do a load of select(0, NULL, NULL, NULL, {0,0}).
I can shed some light on this (though I'm far from a PG hacker).
Postgres can use either of two locking methods -- SysV semaphores
(which it tries to avoid, asusming that they'll be too heavy) or
userspace spinlocks (via inline assembler on platforms which support
it).
In the slow path of a spinlock_acquire they busy wait for a few
cycles, and then call schedule with a zero timeout assuming that
it'll basically do the same as a sched_yield() but more portably.
Matthew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Error compiling aic7xxx driver on 2.4.2-ac13
anyone else get the following: make[5]: Entering directory ` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac12
On Tue, 6 Mar 2001, Scott M. Hoffman wrote: > On Tue, 6 Mar 2001, God wrote: > > > # iostat > > Linux 2.4.2 (scotch)03/06/2001 > > I have not had problems with 2.4.2, just tried 2.4.2-ac12. About the IDE > stage it just reboots. Same chipset/mb? > As for your iostat output, which version do you have? The stock one with > RH7 needs to be upgraded to work with 2.4 kernels. I'm using 3.3.5 now, > which seems to work. Version of? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] smbfs: d_add + re-open fixes
Hello
Enough details in the ChangeLog I hope.
Patch vs 2.4.2-ac12 but appears to be clean vs 2.4.3-pre2 and the recently
released -ac13. Please apply.
/Urban
diff -urN -X exclude linux-2.4.2-ac12-orig/fs/smbfs/ChangeLog
linux-2.4.2-ac12-smbfs/fs/smbfs/ChangeLog
--- linux-2.4.2-ac12-orig/fs/smbfs/ChangeLogThu Feb 22 20:52:03 2001
+++ linux-2.4.2-ac12-smbfs/fs/smbfs/ChangeLog Tue Mar 6 23:50:06 2001
@@ -1,9 +1,22 @@
ChangeLog for smbfs.
+2001-03-06 Urban Widmark <[EMAIL PROTECTED]>
+
+ * cache.c: d_add on hashed dentries corrupts d_hash list and
+ causes loops in d_lookup. Inherited bug. :)
+ * inode.c: tail -f fix for non-readonly opened files
+ (related to the smb_proc_open change).
+ * inode.c: tail -f fix for fast size changes with the same mtime.
+
+2001-03-02 Michael Kockelkorn <[EMAIL PROTECTED]>
+
+ * proc.c: fix smb_proc_open to allow open being called more than once
+ with different modes (O_RDONLY -> O_WRONLY) without closing.
+
2001-02-10 Urban Widmark <[EMAIL PROTECTED]>
- * dir.c: replace non-bigmem safe cache with cache code from ncpfs
- and fix some other bigmem bugs in smbfs.
+ * dir.c, cache.c: replace non-bigmem safe cache with cache code
+ from ncpfs and fix some other bigmem bugs in smbfs.
* inode.c: root dentry not properly initialized
* proc.c, sock.c: adjust max parameters & max data to follow max_xmit
lots of servers were having find_next trouble with this.
diff -urN -X exclude linux-2.4.2-ac12-orig/fs/smbfs/cache.c
linux-2.4.2-ac12-smbfs/fs/smbfs/cache.c
--- linux-2.4.2-ac12-orig/fs/smbfs/cache.c Thu Feb 22 20:52:03 2001
+++ linux-2.4.2-ac12-smbfs/fs/smbfs/cache.c Tue Mar 6 23:01:17 2001
@@ -167,6 +167,7 @@
struct inode *newino, *inode = dentry->d_inode;
struct smb_cache_control ctl = *ctrl;
int valid = 0;
+ int hashed = 0;
ino_t ino = 0;
qname->hash = full_name_hash(qname->name, qname->len);
@@ -181,9 +182,11 @@
newdent = d_alloc(dentry, qname);
if (!newdent)
goto end_advance;
- } else
+ } else {
+ hashed = 1;
memcpy((char *) newdent->d_name.name, qname->name,
newdent->d_name.len);
+ }
if (!newdent->d_inode) {
smb_renew_times(newdent);
@@ -191,7 +194,9 @@
newino = smb_iget(inode->i_sb, entry);
if (newino) {
smb_new_dentry(newdent);
- d_add(newdent, newino);
+ d_instantiate(newdent, newino);
+ if (!hashed)
+ d_rehash(newdent);
}
} else
smb_set_inode_attr(newdent->d_inode, entry);
diff -urN -X exclude linux-2.4.2-ac12-orig/fs/smbfs/inode.c
linux-2.4.2-ac12-smbfs/fs/smbfs/inode.c
--- linux-2.4.2-ac12-orig/fs/smbfs/inode.c Tue Mar 6 21:14:31 2001
+++ linux-2.4.2-ac12-smbfs/fs/smbfs/inode.c Tue Mar 6 23:05:50 2001
@@ -161,17 +161,15 @@
struct smb_fattr fattr;
error = smb_proc_getattr(dentry, );
- if (!error)
- {
+ if (!error) {
smb_renew_times(dentry);
/*
* Check whether the type part of the mode changed,
* and don't update the attributes if it did.
*/
- if ((inode->i_mode & S_IFMT) == (fattr.f_mode & S_IFMT))
+ if ((inode->i_mode & S_IFMT) == (fattr.f_mode & S_IFMT)) {
smb_set_inode_attr(inode, );
- else
- {
+ } else {
/*
* Big trouble! The inode has become a new object,
* so any operations attempted on it are invalid.
@@ -212,18 +210,11 @@
struct smb_sb_info *s = server_from_dentry(dentry);
struct inode *inode = dentry->d_inode;
time_t last_time;
+ loff_t last_sz;
int error = 0;
DEBUG1("smb_revalidate_inode\n");
- /*
-* If this is a file opened with write permissions,
-* the inode will be up-to-date.
-*/
lock_kernel();
- if (S_ISREG(inode->i_mode) && smb_is_open(inode)) {
- if (inode->u.smbfs_i.access != SMB_O_RDONLY)
- goto out;
- }
/*
* Check whether we've recently refreshed the inode.
@@ -236,11 +227,13 @@
/*
* Save the last modified time, then refresh the inode.
-* (Note: a size change should have a different mtime.)
+* (Note: a size change should have a different mtime,
+* or same mtime but different size.)
*/
last_time = inode->i_mtime;
+ last_sz = inode->i_size;
error = smb_refresh_inode(dentry);
- if (error || inode->i_mtime !=
Drive corruption with VIA VT82C686A (ABIT KT7-RAID) - Still -
Still having drive corruption issues with 2.4+ when DMA mode is enabled. Drive corruption is almost instant. attached are output files for the system with kernel 2.4.2 without DMA mode and with DMA. Immediatley after running those commands I attempted to do a copy with DMA on and the system locked. If I reboot with 2.4.2 FSCK will fail and after a few reboots the drive will be unusable. Linux version 2.4.2 (root@hades) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Mar 6 07:03:02 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 00e0 @ 0010 (usable) BIOS-e820: 0010 @ 00f0 (reserved) BIOS-e820: 06ff @ 0100 (usable) BIOS-e820: d000 @ 07ff3000 (ACPI data) BIOS-e820: 3000 @ 07ff (ACPI NVS) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009fc00 for 4096 bytes. On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. mapped APIC to e000 (01223000) Kernel command line: BOOT_IMAGE=Linux-2.4 ro root=305 mem=128M Initializing CPU#0 Detected 800.064 MHz processor. Console: colour VGA+ 80x34 Calibrating delay loop... 1595.80 BogoMIPS Memory: 126020k/131072k available (1403k kernel code, 4664k reserved, 542k data, 224k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Duron(tm) Processor stepping 00 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Bus master read caching disabled PCI: Using IRQ router VIA [1106/0686] at 00:07.0 isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 83688kB/27896kB, 256 slots per queue loop: enabling 8 loop devices Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio hda: WDC WD205BA, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-M1202, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 40088160 sectors (20525 MB) w/2048KiB Cache, CHS=2495/255/63, UDMA(33) hdc: ATAPI 32X DVD-ROM drive, 256kB Cache, DMA Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A PCI: Found IRQ 10 for device 00:08.0 PCI: The same IRQ used for device 00:07.2 PCI: The same IRQ used for device 00:07.3 3c59x.c:LK1.1.12 06 Jan 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905C Tornado at 0xdc00, 00:01:03:30:0f:3a, IRQ 10 product code 'HN' rev 00.3 date 11-03-00 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 96M agpgart: Detected Via Apollo Pro KT133 chipset agpgart: AGP aperture is 64M @ 0xd000 [drm] AGP 0.99 on VIA Apollo KT133 @ 0xd000 64MB [drm] Initialized r128 2.1.2 20001215 on minor 63 SCSI
Re: scsi vs ide performance on fsync's
> itself is a bad thing, particularly given the amount of CPU overhead that > IDE drives demand while attached to the controller (orders of magnitude > higher than a good SCSI controller) - the more overhead we can hand off to I know this is just a troll by a scsi-believer, but I'm biting anyway. on current machines and disks, ide costs a few % CPU, depending on which CPU, disk, kernel, the sustained bandwidth, etc. I've measured this using the now-trendy method of noticing how much the IO costs a separate, CPU-bound benchmark: load = 1 - (unloadedPerf / loadedPerf). my cheesy duron/600 desktop typically shows ~2% actual cost when running bonnie's block IO tests. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
> Anyways, is this the end of the discussion regarding my patch?
I think one of the maintainers for usb-uhci (Georg) said he'd
want the general fix ...
> Manfred said plainly "usb-uhci is broken", Alan kinda
> manuevered around my small problem, Dave Brownell looks
> unconvinced. So?
There are two problems I see.
(1) CONFIG_SLAB_DEBUG breaks the documented
requirement that the slab cache return adequately aligned
data ... which the appended patch should probably handle
nicely (something like it sure did :-) and with less danger
than the large patch you posted.
(2) The USB host controller drivers all need something
like a pci_consistent slab cache, which doesn't currently
exist. I have something like that in the works, and David
Miller noted one driver that I may steal from.
- Dave
--- slab.c-orig Tue Mar 6 15:01:26 2001
+++ slab.c Tue Mar 6 15:05:58 2001
@@ -676,12 +676,10 @@
}
#if DEBUG
+ /* redzoning would break cache alignment requirements */
+ if (flags & SLAB_HWCACHE_ALIGN)
+ flags &= ~SLAB_RED_ZONE;
if (flags & SLAB_RED_ZONE) {
- /*
- * There is no point trying to honour cache alignment
- * when redzoning.
- */
- flags &= ~SLAB_HWCACHE_ALIGN;
size += 2*BYTES_PER_WORD; /* words for redzone */
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ES1371 problem (2.4.2)
Approx. 90% of the time my es1371 sound card refuses to work. dmesg reveals: es1371: version v0.27 time 16:38:48 Mar 3 2001 es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08 PCI: Found IRQ 10 for device 00:0b.0 es1371: found es1371 rev 8 at io 0xa400 irq 10 es1371: features: joystick 0x0 ac97_codec: AC97 codec, id: 0x:0x (Unknown) When it works (I'm not sure, but a clean boot helps) the id fields are non-zero. My setup: Athlon/KX133 (VIA chipset)/Creative SB64 PCI kernel 2.4.2/gcc 2.96 (latest) I am using devfs also. Please CC any replies to this address. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac13
"Alan Cox wrote:" > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ > The .gz patch file still seems to have zero size. Same mirrored :( Andrzej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
On Fri, 2 Mar 2001, David S. Miller wrote:
> > On PPC, we don't have an "IO" space neither, all we have is a range of
> > memory addresses that will cause IO cycles to happen on the PCI bus.
>
> This is precisely what the "next MMAP is XXX space" ioctl I've
> suggested is for. I think I've addressed this concern in my
> proposal already. Look:
>
> fd = open("/proc/bus/pci/${BUS}/${DEV}", ...);
> if (fd < 0)
> return -errno;
> err = ioctl(fd, PCI_MMAP_IO, 0);
I know I'm coming in on this late, but wouldn't it be cleaner to have
separate files for memory and io cycles, eg ${BUS}/${DEV}.(io|mem)?
They're logically different so they might as well be embodied separately.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2ac13
Against vanilla 2.4.2: === Cut === Patch #0 (patch-2.4.2-ac13.bz2): + /usr/bin/bzip2 -d + patch -p1 -s The next patch would create the file drivers/video/sis/Makefile, which already exists! Assume -R? [n] Apply anyway? [n] 1 out of 1 hunk ignored -- saving rejects to file drivers/video/sis/Makefile.rej === Cut === --- Sergey Kubushin Sr. Unix Administrator CyberBills, Inc.Phone: 702-567-8857 874 American Pacific Dr,Fax:702-567-8808 Henderson, NV, 89014 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel lock contention and scalability
> Tridge and I tried out the postgresql benchmark you used here and this
> contention is due to a bug in postgres. From a quick strace, we found
> the threads do a load of select(0, NULL, NULL, NULL, {0,0}). Basically all
> threads are pounding on schedule().
...
> Our guess is that the app has some form of userspace synchronisation
> (semaphores/spinlocks). I'd argue that the app needs to be fixed not the
> kernel, or a more valid test case is put forwards. :)
...
> PS: I just looked at the postgresql source and the spinlocks (s_lock() etc)
> are in a tight loop doing select(0, NULL, NULL, NULL, {0,0}).
Anton,
Thanks for looking into postgresql/pgbench related locking. Yes,
apparently postgresql uses a synchronization scheme that uses select()
to effect delays for backing off while attempting to acquire a lock.
However, it seems to me that runqueue lock contention was not entirely due
to postgresql code, since it was largely alleviated by the multiqueue
scheduler patch.
In using postgresql/pgbench to measure lock contention, I was attempting
to apply a typical server workload to measure scalability using only open
software. My goal is to load and measure the kernel for server performance,
so I need to ensure that the software I use represents likely real world
server configurations. I did not use mysql, because it cannot perform
transactions which I considered important. Any pointers to other open
database software or benchmarks that might be suitable for this effort
would be appreciated.
Jonathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac12
On Tue, 6 Mar 2001, Alan Cox wrote: > > Just trying 2.4.3-pre2 now. It appears to be working fine. I used the > > same config from my ac11-12 attempts. My systems problem with ac11-12 must > > not be something common between them. Hope this helps. > > It helps a lot. I now know not to submit the VIA ide driver to Linus until > further investigation is completed. Now you know why I pawned it off the VIA-core to Vojtech ;-) It is a mess! Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.2ac13
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac13 o Clean up mad16 detection stuff (Pavel Rabel) o Fix epca unload (Andrey Panin) o Change null apic handling (Maciej Rozycki) o aicasm now uses db3 (Sergey Kubushin) o Fix aic7xxx cross compile (Cort Dougan) o Merge small net driver fixups/config fixes (Jeff Garzik) o Update symbios drivers (Gérard Roudier) o Rusty has moved (Rusty Russell) o 3c509/3c515 compile fixes (Jeff Garzik) o Console locking updates - should fix vesafb (Andrew Morton) clock problems o Merge the serial.c 5.0.5 update (Jeff Garzik, Ted Ts'o) o Merge SiS framebuffer updates (Can-Ru Yeou) o Update ctrlfb (Takashi Oe, Michel Lanners) o Add epson 640U scanner to the usb scanner list (Patrick Dreker) 2.4.2-ac12 o Move the pci_enable_device for cardbus (David Hinds) o Add Sony MSC-U01N to the unusual devices(Marcel Holtmann) o Final smc-mca fixups - should now work (James Bottomley) o Document kernel string/mem* functions (Matthew Wilcox) | and I added a memcpy warning o Update VIA IDE driver to 3.21 (Vojtech Pavlik) |No UDMA66 on 82c686, fix /proc and udma on |686b, fix dma disables o Allow sleeping in ctrl-alt-del callbacks(Andrew Morton) |Fix i2o, dac960, watchdog, gdth hangs on exit o Fix binfmt_misc (and make the proc handling (Al Viro) |a filesystem - |mount -t binfmt_misc none /proc/sys/fs/binfmt_misc o Update the ACI support for sound/radio stuff(Robert Siemer) o Add RDS support to miroRadio(Robert Siemer) o Remove serverworks handling. The BIOS is our(me) best (and right now only) hope for that chip o Tune the vm behavioru a bit more(Mike Galbraith) o Update PAS16 documentation (Thomas Molina) o Reiserfs tools recommended are now 0d not 0b(Steven Cole) o Wan driver small fixes (Jeff Garzik) o Net driver fixes for 3c503, 3c509, 3c515, (Jeff Garzik) 8139too, de4x5, defxx, dgrs, dmfe, eth16i, ewrk3, natsemi, ni5010, pci-skeleton, rcpci45, sis900, sk_g16, smc-ultra, sundance, tlan, via-rhine, winbond-840, yellowfin, wavelan_cs tms380tr o Trim 3K off the aha1542 driver size (Andrzej Krzysztofowicz) o Trim 1K off qlogicfas (Andrzej Krzysztofowicz) o Fix openfirmware/mm boot on ppc (Cort Dougan) o Fix topdir handling in Makefile (Keith Owens) o Minor fusion driver updates (Steve Ralston) o Merge Etrax cris updates(Bjorn Wesen) o Clgen fb copyright update (Jeff Garzik) o AGP linkage fix (Jeff Garzik) o Update visor driver to work with minijam(Arnim Laeuger) o Fix a usb devio return code (Dan Streetman) o Resync a few other net device changes with the submits Jeff sent to Linus (Jeff Garzik) o Add missing md export symbol(Mohammad Haque) 2.4.2-ac11 o Fix NLS Config.in (David Weinehall) o Sort out one escaped revert from the megaraid (me) update o Resync with Linux 2.4.3pre1 | Except tulip the network driver changes have | been used to replace the existing ones o Fix parport case where a reader could get stuck (Tim Waugh) o Add ALi15x3 to the list of isa dma hangs(Angelo Di Filippo) o Fix nasty bug in IPX routing of netbios frames (Arnaldo Carvalho de Melo) o Misc code cleanups (Keith Owens) o Updated 3c527 driver(Richard Proctor) o Further tulip updates (Jeff Garzik) o i810_rng fixes (FIPS test, regions) (Jeff Garzik) o Further cs89x0 cleanups (Andrew Morton) o Further USB hub updates (Dave Brownell) o Mall USB resource cleanup (Jeff Garzik) o Resync hp100 changes from Jeff Garzik (Jeff Garzik) o PCI documentation update(Tim Waugh) o Fix
Re: Linux 2.4.2-ac12
> Just trying 2.4.3-pre2 now. It appears to be working fine. I used the > same config from my ac11-12 attempts. My systems problem with ac11-12 must > not be something common between them. Hope this helps. It helps a lot. I now know not to submit the VIA ide driver to Linus until further investigation is completed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Forcible removal of modules
Hi. Here's my question, with a little introduction. Sometimes modules need to be reloaded in order to cause some sort of reinitialization (of the driver or of the hardware) to occur. Sometimes this has to be done every time a machine is suspended. E.g., some sound driver modules need to be reloaded after an APM suspend because the sound chip forgets its configuration during the suspend. Obviously, one would like to be able to automate the process of unloading and reloading the modules by putting some commands in the apmd_proxy script. Sometimes, though, "rmmod themodulename" fails because some process is holding open a device handled by the device driver module in question. The solution to this is to do a "fuser" on the device nodes associated with the device driver and kill all the processes reported to be using those nodes. However, this is easier said than done because of one problem: while you are killing a batch of processes that are using the device node, other processes may be opening that device node! What is needed is a way of preventing processes from opening a given device node. Now, one way of doing this is to change the device permissions on the node to 000. Unfortunately this does not work well with devfs under the circumstances we have in mind here: because once the permissions are changed the device driver is removed; then devfs stores "000" as the permissions that are to be used for that device node when it is created again. My question is: Is there some better way of blocking all open() calls to a particular device driver while processes using it are being killed off? Thomas Hood ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: setleds source and ppp
> after each byte, downloaded from the internet, the CAPS LOCK led blinks.
[poor you - you must have a slow connection]
Two possibilities: (i) blink from user space,
(ii) blink from kernel space.
There is a program setleds in the kbd distribution that sets the leds.
Source fragment:
int setleds(char leds) {
if (ioctl(0, KDSETLED, leds)) {
perror("KDSETLED");
return -1;
}
return 0;
}
There is also a kernel routine that accepts kernel calls:
See keyboard.c, routines register_leds(), setledstate().
In ancient times people used this for "blinkenlights".
Have not checked recently whether this still works.
Andries
cc'd to l-k -- no doubt there are people that'll want to play
with the lights again
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: conducting TCP sessions with non-local IPs
On Tue, Mar 06, 2001 at 12:30:58PM -0800, Bryan Rittmeyer wrote: > Hello linux-kernel, > > Is there any way to conduct TCP sessions (IE have a userland process > connect out, or accept connections) using non-local IPs? By "non-local" > I just mean IPs that aren't assigned to an interface, but do fall into > the network range of a running interface (so netmask, gateway, etc are > "known"). > > For example, I want to bring up an interface for 10.0.0.0/255.255.255.0 > and assign it IP 10.0.0.1 Then, I want a process to accept TCP [snip] /sbin/ip addr add 10.2.0.0/24 dev eth0 Tada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB-keyboard not recognize after connection
Otto Wyss wrote: > 3. How can I get more information what's happening? Is there any > USB-log/-trace accessable after the restart of linux? And whom/where do > I have to send it? > If you compiled your kernel with "USB verbose debug messages" (CONFIG_USB_DEBUG) enabled, USB subsystem should log a message every time a device is connected and disconnected. These messages will be there in /var/log/messages if this file survives hard reset. These messages can show you if USB detected a reconnect from your keyboard and mouse the last time you switched from mac to PC. Khalid Aziz Linux Development Laboratory (970)898-9214Hewlett-Packard [EMAIL PROTECTED]Fort Collins, CO - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.2-ac12
On Mon, 5 Mar 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Scott M. Hoffman <[EMAIL PROTECTED]> wrote: > > > > It may not be related, but out of five boot attempts, only one got past > >the IDE driver stage(ie, below from 2.4.2 : > > VP_IDE: IDE controller on PCI bus 00 dev 39 > > VP_IDE: chipset revision 16 > > VP_IDE: not 100% native mode: will probe irqs later > > ide: Assuming 33MHz system bus speed for PIO modes; override with > > idebus=xx > > VP_IDE: VIA vt82c596b (rev 23) IDE UDMA66 controller on pci00:07.1 > > ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA > > ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA) > > > > I've had 2.4.2 running great for the past 10 days. Need any more info? > > I'd love to hear anything you can come up with. What's the next step in > your boot process, ie what's the part that normally shows up but doesn't > with 2.4.2-ac12? Is this using IDE-SCSI, for example? > > One thing that both 2.4.3-pre3 and -ac12 do is to not have allocate a > result buffer for TEST_UNIT_READY. I don't see why that should matter, > but can you try un-doing the patch to "scsi_error.c" and see if that > makes a difference. I'm worried about this report, and the buslogic > corruption thing.. > > Justin: there's another "2.4.3-pre2 corrupts all disks on a buslogic > controller" report. The interesting part is that 2.4.3-pre2 doesn't > actually contain any buslogic changes. The only generic-scsi changes > were yours. Ideas? > > Linus > Just trying 2.4.3-pre2 now. It appears to be working fine. I used the same config from my ac11-12 attempts. My systems problem with ac11-12 must not be something common between them. Hope this helps. Scott - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Info on adding system calls
[T.L.Madhu] > I want to add a function defined in my loadeble kernel module as > system call. You can't. At least not without hackery -- anything is possible with a bit of hackery. And there are at least two good reasons for this. First: adding syscalls at runtime is a recipe for chaos in terms of applications knowing what the ABI should be. What if two modules wanted the same unallocated syscall? Should the second one fail, or should it just get a free syscall, and somehow publish its syscall to userspace so apps can use it? The second is philosophical. At the top of the COPYING file in the kernel source, you see that Linus has made an exception to the GPL, to allow anyone to write and distribute non-GPL modules, as long as they do not compile directly into the kernel. However, he doesn't want people to use this as a general GPL circumvention device, so he will not make it convenient to extend the system call interface this way. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
> So EOD from me. ditto... Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, Mar 06 2001, Andre Hedrick wrote: > > But I might want to do this (write sector 0), why would we want > > to filter that? If someone a) uses an email client that will execute > > java script code (or whatever) and b) runs that as root (which > > he would have to do, surely no ordinary user has privileges to send > > arbitrary commands) then he gets what he deserves. > > Jens we are not going therethe filter is the only way known to jam > unknown commands, and you missed the point of the issue then and I think > you still miss it. "arbitrary commands" + wrong hander is lock-up. I'm perfectly aware of the handler issue. So make it part of the user space taskfile interface in a nice way, done and done. And I knew I shouldn't have replied to this, the last thing I want to do is start another flamewar :-) So EOD from me. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch submissions
Rik van Riel wrote: > On Tue, 6 Mar 2001, Kurt Garloff wrote: > > On Tue, Mar 06, 2001 at 02:22:58PM -0300, Rik van Riel wrote: > > > probably even out of linux-kernel ... > > > > No. I want to see experimental stuff on l-k. That's what it's meant for. > > Putting the experimental stuff which isn't on l-k at the > moment would probably triple the volume of this list, if > not more ... > > I'm pretty sure most people already find l-k traffic too > heavy to keep up. If you want to read all the experimental > stuff of all the subsystems, why not subscribe to the > mailing lists of those subsystems ? Every patch doesn't need to go to lkml, but keeping linux-kernel folks updated on experimental issues is always IMHO a good idea. Otherwise, interested folks who don't have time to find out about and subscribe to 1000 other lists are kept informed. Jeff -- Jeff Garzik | "You see, in this world there's two kinds of Building 1024 | people, my friend: Those with loaded guns MandrakeSoft | and those who dig. You dig." --Blondie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP vegas implementation
On Tue, 6 Mar 2001, Mordechai Ovits wrote: > On Tue, Mar 06, 2001 at 12:03:02PM -0500, Hao Sun wrote: > > > From Neal Cardwell ([EMAIL PROTECTED]) > > > Tue, 20 Jul 1999 03:08:21 -0700 (PDT) > > > A new TCP Vegas patch for 2.2.10/2.3.10 is available at: > > > http://www.cs.washington.edu/homes/cardwell/linux-vegas/ > > Does anyone know where to get the above TCP vegas implementation code > > or a more recent one? The link above is broken and Neal Cardwell is > > not there. I had big performance problems with tcp-vegas on highly assymetric WAN connections (eg 8m/640k adsl). Normal tcp worked fine. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, James A. Sutherland wrote: > > Jens we are not going therethe filter is the only way known to jam > > unknown commands, > > Erm... the hoax "virus" was about writing to the first sector of the disk, > overriding the partition table. If "write data" is an "unknown command", > HTF am I supposed to store data on my HDD? :P One-liner: It is stupid to issue a data-command using a non-data-handler. Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Andre Hedrick wrote: > On Tue, 6 Mar 2001, Jens Axboe wrote: > > > But I might want to do this (write sector 0), why would we want > > to filter that? If someone a) uses an email client that will execute > > java script code (or whatever) and b) runs that as root (which > > he would have to do, surely no ordinary user has privileges to send > > arbitrary commands) then he gets what he deserves. > > Jens we are not going therethe filter is the only way known to jam > unknown commands, Erm... the hoax "virus" was about writing to the first sector of the disk, overriding the partition table. If "write data" is an "unknown command", HTF am I supposed to store data on my HDD? :P > and you missed the point of the issue then and I think you still miss > it. "arbitrary commands" + wrong hander is lock-up. Everyone can do > this, and that is fine. I will not stop the drive-command ioctl from > issuing a drive-data command, you win! Hrm. I like the idea of being able to filter out dodgy commands from hitting the drive: there's a difference between the Unix philosophy of "enough rope" and the NT approach of everything having a landmine on top with a big red button marked "press this and see!" :) James. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP vegas implementation
linux-vegas: http://pictures.care2.com/view/2/459681070 Really. Mordy On Tue, Mar 06, 2001 at 12:03:02PM -0500, Hao Sun wrote: > > > From Neal Cardwell ([EMAIL PROTECTED]) > > Tue, 20 Jul 1999 03:08:21 -0700 (PDT) > > > > Hi all, > > > > A new TCP Vegas patch for 2.2.10/2.3.10 is available at: > > http://www.cs.washington.edu/homes/cardwell/linux-vegas/ > > Does anyone know where to get the above TCP vegas implementation code > or a more recent one? The link above is broken and Neal Cardwell is > not there. > > TIA. Please CC to me. > > -- Hao > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VFS: Cannot open root device
Peter Samuelson wrote: > [Jeremy Jackson] > > try command 'man mkinitrd' under redhat for hints about initial > > ramdisk. > > I have been puzzled about this for quite some time. Why exactly does > everyone always recommend using 'mkinitrd' on Red Hat systems? It > seems to me that if you are compiling a kernel for a specific server > anyway, it is a much more reliable proposition to just compile in > whatever drivers you need to boot. > > initrd's are inherently clumsy and fragile, to my way of thinking. > I've always thought they should only be used to support diverse or > unknown hardware, or odd cases like crypto loopback root. Are there > other advantages to 'mkinitrd' in the case of a custom kernel for a > single machine? > no the reason redhat uses it is to allow a generic kernel for everyone. having *ALL* drivers in kernel would make it huge, and some drivers conflict with each other (not many) so they couldn't all be in there. If you have made a custom kernel (that is configured properly) you don't need to bother. The question is if you configured it properly :) I would suggest taking a config from redhat (it puts them in /usr/src/linux/configs) and just tweaking that. (sorry if i already said that once) other pitfalls include not having the right root= entry (or missing one) in lilo.conf. > > Peter > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- Original Message - From: "David Weinehall" <[EMAIL PROTECTED]> To: "Sean Hunter" <[EMAIL PROTECTED]>; "Laramie Leavitt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, 6. March 2001 15:37 Subject: Re: binfmt_script and ^M > On Tue, Mar 06, 2001 at 03:12:42PM +, Sean Hunter wrote: > > > > I propose > > >/proc/sys/kernel/im_too_lame_to_learn_how_to_use_the_most_basic_of_unix_tools_so_i_want_the_kernel_to_be_filled_with_crap_to_disguise_my_ineptitude > > > > Any support? > > > Hey, let's go even further! Let's add support in all programs for \r\n. That is no sarcasm, it is ridiculous. CRLF line endings are ISO-IR-6 and US-ASCII standard, and even UN*X systems used them when they had printers (typewriters?) as output device, and no screens. With the Virtual Terminal, Virtual Console stuff times may have changed but we have so many old stuff in it... I won't remove them or didn't think of, but I remember you of: - lost+found - using ESC (or Alt???) as META for _shell commands_ which easily could be Ctrl-Left, Ctrl-Right, Ctrl-Del etc. - EMACS:-(( - ED/EX/VI :-( The following does _not_ have to do with any US-ASCII or ISO_646.irv:1991 standards which IIRC are inherited by POSIX. > And why not make all program use filenames that have an 8+3 char garbled > equivalent where the last 3 are the indicators of the filetype. Oh, and > let's do everything to make sure the user doesn't leave Gnome/KDE. > And of course, let's add new features to all existing protocols and > other standards to make them "superior" to other implementations. > Oh, and of course, we must require an extra 64 MB of memory and > 500 MB of diskspace for each release, and a 200MHz faster processor. > And let us do all system settings through a registry. > > OH! Let's change the name of the operating-system to something more > catchy. Hmmm. Let's see. Windows maybe... > > > > /David I _do_ _not_ like Windoze either, but we live in a world where we have to cope with it. I am even to code windoze apps in order to support linux (no comment on this)... -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
On Tue, 6 Mar 2001, Peter Samuelson wrote: > [Dr. Kelsey Hudson] > > umm, last i checked a carriage return wasn't whitespace... space, > > horizontal tab, vertical tab, form feed constitute whitespace IIRC... > > Where and when did you check? Several sources disagree with you. a long while ago... i should have checked before i opened my mouth :p Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: binfmt_script and ^M
- Original Message - From: "Jesse Pollard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Richard B. Johnson" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, 5. March 2001 19:14 Subject: Re: binfmt_script and ^M > John Kodis <[EMAIL PROTECTED]>: > > On Mon, Mar 05, 2001 at 08:40:22AM -0500, Richard B. Johnson wrote: > > > > > Somebody must have missed the boat entirely. Unix does not, never > > > has, and never will end a text line with '\r'. > > > > Unix does not, never has, and never will end a text line with ' ' (a > > space character) or with \t (a tab character). Yet if I begin a shell > > script with '#!/bin/sh ' or '#!/bin/sh\t', the training white space is > > striped and /bin/sh gets exec'd. Since \r has no special significance > > to Unix, I'd expect it to be treated the same as any other whitespace > > character -- it should be striped, and /bin/sh should get exec'd. > > Actually it does have some significance - it causes a return, then the > following text overwrites the current text. Granted, this is only used > occasionally for generating bold/underline/... > > This is used in some formatters (troff) occasionally, though it tends to > use backspace now. Less supports it, but ^H is quite more oftenly used. ISO_646.irv:1991 aka ISO-IR-6 aka US-ASCII-7 _also_ defines it, and we're going to be not ASCII-compatible any longer if we aren't going to support CRLF line endings. I also oftenly have the other problem round: LF endings in files which are to be viewed under DOS. I use a 15-year-old text editor from Digital Research (yes, DOS 3.41) which still is fine under W** and DOSEMU, it looks like jstar only that I miss find and replace. IMHO those problems could be solved with programmes/kernels/libs accepting LF as line ending and CRLF (and possibly CRCRLF ...) as a synonyme for LF, but treat CR non-LF differently. I have seen this behaviour quite often in the past and am using it for myself, too (except for native assembly progs). > \r is not considered whitespace, though it should be possible to define > it that way. A line terminator is always \n. ACK > Another point, is that the "#!/bin/sh" can have options added: it can be > "#!/bin/sh -vx" and the option -vx is passed to the shell. The space is > not just "stripped". It is used as a parameter separator. As such, the > "stripping" is only because the first parameter is separated from the > command by whitespace. That's why I suggest treating CRLF (and only CR only-LF) as LF. -mirabilos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft ZERO Sector Virus, Result of Taskfile WAR
On Tue, 6 Mar 2001, Jens Axboe wrote: > But I might want to do this (write sector 0), why would we want > to filter that? If someone a) uses an email client that will execute > java script code (or whatever) and b) runs that as root (which > he would have to do, surely no ordinary user has privileges to send > arbitrary commands) then he gets what he deserves. Jens we are not going therethe filter is the only way known to jam unknown commands, and you missed the point of the issue then and I think you still miss it. "arbitrary commands" + wrong hander is lock-up. Everyone can do this, and that is fine. I will not stop the drive-command ioctl from issuing a drive-data command, you win! Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
