Re: kernel newby help.... What's causing my Oops
On Fri, 27 Oct 2000, David Won wrote: > Oct 22 22:37:20 phlegmish kernel: Process esd (pid: 2356, stackpage=c1715000) [snip] > Oct 22 22:37:20 phlegmish kernel: Call Trace: > [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-220073/96] > [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-237584/96] > [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-245443/96] > [__fput+35/144] [_fput+17/64] [fput+18/24] [filp_close+82/92] It certainly has smbfs printed all over it. But I don't know how to decode the call trace ... "sm+-220073" ? Could you describe what it is you are doing when this happens? Are you perhaps playing sound from a mounted smbfs? (esd) Could you test if this is or isn't related to smbfs? (ie don't mount any smbfs stuff and do the same things you normally do) For reproducing oopses it is nice to use a separate system, either a second installation on the same machine (with none of the normal partitions mounted) or a second machine. You could also try 2.4.0-test10-pre6 which is the latest (but if it is smbfs related it should not make any difference). The second oops I don't know anything about except that it may have been triggered by the first oops. /Urban - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test10-pre6
Thanks to everybody who has been testing. pre6 has tons of small fixes, the most noticeable of which are (a) the new compiler requirements (sorry, but it turned out that 2.7.2.3 really is too subtly broken with named structure initializers that are very heavily used these days inside the kernel) Suggested stable compiler: gcc-2.91.66, aka egcs-1.1.2, which is the one most vendors have been shipping for a long time, and while sure to be buggy too has not been found to be seriously so at least yet. Other modern gcc versions may well work too. (b) various PCI fixes that used to make 2.4.0 completely unboot/usable on certain machines (ALI chipsets with certain PIRQ routing tables and laptops with some docking bridges. Oh, and PIIX4 chipsets with USB enabled and certain other magic things going on). Let's hope that there aren't too many more of these. The ALI one in particular was "interesting" to chase down. More interesting than I personally need in my old age. The rest of the changes should be mostly unnoticeable. Still known: the same old "page->mapping = NULL" thing that has not seen an acceptable fix yet. If it wasn't for that, I'd have called this test10 already and be done with it. Super-Al to the rescue (and no, that was not a reference to the current sad state of US politics). Linus - - pre6: - Jeremy Fitzhardinge: autofs4 expiry fix - David Miller: sparc driver updates, networking updates - Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write - Ingo Molnar: wakeup race fix (admittedly the window was basically non-existent, but still..) - Rasmus Andersen: notice that "this_slice" is no longer used for scheduling - delete the code that calculates it. - ALI pirq routing update. It's even uglier than we initially thought.. - Dimitrios Michailidis: fix ipip locking bugs - Various: face it - gcc-2.7.2.3 miscompiles structure initializers. - Paul Cassella: locking comments on dev_base - Trond Myklebust: NFS locking atomicity. refresh inode properly. - Andre Hedrick: Serverworks Chipset driver, IDE-tape fix - Paul Gortmaker: kill unused code from 8390 support. - Andrea Arcangeli: fix nfsv3d wrong truncates over 4G - Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3. - me: if we cannot figure out the PCI bridge windows, just "inherit" the window from the parent. Better than not booting. - Ching-Ling Lee: ALI 5451 Audio core support update - pre5: - Mikael Pettersson: more Pentium IV cleanup. - David Miller: non-x86 platforms missed "pte_same()". - Russell King: NFS invalidate_inode_pages() can do bad things! - Randy Dunlap: usb-core.c is gone - module fix - Ben LaHaise: swapcache fixups for the new atomic pte update code - Oleg Drokin: fix nm256_audio memory region confusion - Randy Dunlap: USB printer fixes - David Miller: sparc updates - David Miller: off-by-one error in /proc socket dumper - David Miller: restore non-local bind() behaviour. - David Miller: wakeups on socket shutdown() - Jeff Garzik: DEPCA net drvr fixes and CodingStyle - Jeff Garzik: netsemi net drvr fix - Jeff Garzik & Andrea Arkangeli: keyboard cleanup - Jeff Garzik: VIA audio update - Andrea Arkangeli: mxcsr initialization cleanup and fix - Gabriel Paubert: better twd_i387_to_fxsr() emulation - Andries Brouwer: proper error return in ext2 mkdir() - pre4: - disable writing to /proc/xxx/mem. Sure, it works now, but it's still a security risk. - IDE driver update (Victroy66 SouthBridge support) - i810 rng driver cleanup - fix sbus Makefile - named initializers in module.. - ppoe: remove explicit initializer - it's done with initcalls. - x86 WP bit detection: do it cleanly with exception handling - Arnaldo Carvalho de Melo: memory leaks in drivers/media/video - Bartlomiej Zolnierkiewicz: video init functions get __init - David Miller: get rid of net/protocols.c - they get to initialize themselves - David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway. - Geert Uytterhoeven: Zorro (Amiga) bus support update - David Miller: work around gcc-2.7.2 bug - Geert Uytterhoeven: mark struct consw's "const". - Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix - Tigran Aivazian: clean up __alloc_pages(), kill_super() and notify_change() - Tigran Aivazian: move stuff from .data to .bss - Jeff Garzik: divert.h typename cleanups - James Simmons: mdacon using spinlocks - Tigran Aivazian: fix BFS free block calculation - David Miller: sparc32 works again - Bernd Schmidt: fix undefined C code (set/use without a sequence point) - Mikael Pettersson: nicer Pentium IV setup handling. - Georg Acher: usb-uhci cpia oops fix - Kanoj Sarcar: m
NWFS Imaging/Migration tools for Linux Posted
I have posted a very complete set of server migration/consolidation tools for Linux at vger.timpanogas.org. These tools include Installshield versions for W2K, Linux, and DOS and provide a complete set of tools that can be used to perform large-scale organization-wide migrations of NetWare servers to Linux. These tools allow IT personnel to boot NetWare servers on DOS, W2K, or Linux, and compress and archive entire volume sets of a NetWare server's data into offline archives for migrating and consolidating NetWare servers and moving large amounts of user data over to Linux systems. NDS (NetWare Directory Services) database files are preserved and stored as well in these archives and these tools preserve all of a customer's NDS data for review and import into Linux in native eDirectory formats. We are releasing these tools to aid Novell's Oracle customers who have been advised by Oracle to immediately migrate to Linux from NetWare. TRG will be posting Ute-NWFS Oct 30, 2000 (Linux on Native NWFS) along with the NWFS patches for 2.2.17 on Monday. The full source code for the Imaging tools will also be posted at the time at vger.timpanogas.org. The inode mapping problems for NWFS are completed and ready to roll out. All Imaging/Migration tools and related source code for W2K, Linux, and DOS versions are released under the GPL, and are freely redistributable. Jeff Merkey CEO, TRG P.S. This want sent to TRG by NetWare customers using Oracle who wanted an easy path to get from NetWare to Linux. Oracle cuts NetWare support Oracle is to drop its support for Novell's NetWare in a move which analysts say will kill off the operating system as a database platform. The company unexpectedly announced last week that it would withdraw all support for NetWare from 31 December 2001, giving users just one year to migrate to other platforms. Robin Bloor, chief executive at Bloor Research, said it would be difficult for Novell to maintain Netware's role as a database platform without the support of Oracle. "I believe that NT is a better database server than NetWare, and the market agrees. But for those who have NetWare, it is important to have support," he said. "We'll see if they will now move over to Linux or NT." Oracle will continue to offer limited 'extended assistance support' for its products on NetWare for another three years, but this was described as "worthless" because it does not cover bug fixes, certification or response time support. "Without error correction support, the extended assistance support is meaningless," said one user. Oracle has recommended that "customers upgrade to other platforms as soon as possible", and is touting its own Oracle 8i appliance as well as Linux, Sun Solaris and HP-Unix. A Novell spokeswoman said that the discontinuation of support was Oracle's decision but that Novell was helping to find migration arrangements for its users. "Our customers are unhappy and say that Oracle is wrong," she said. The announcement comes as a blow for Novell so soon after announcing the release of its internet-based open platform, NetWare 6. Gartner's Mike Silver predicted last week that investments in Novell's products and services would only be viable up until 2004. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel newby help.... What's causing my Oops
I need some help. My system keeps locking up on me or suddenly rebooting. Sometimes I'm able to telnet in and shutdown but usually I have to hit the power button and pray that the disk isn't thrashed. I'm running RedHat 7 and it happens with the supplied kernel or with a new kernel. I'm currently running linux-2.4.0-test8 right now and it is compiled using kgcc. (Found that tip in a message here) I searched through my logs for help and find lots of these Oops messages. I then did some searching on what Oops is. I was told to run ksymoops to get more info but this extra info is way over my head. I'm posting this here in the hopes that somebody can help me pin down what module or kernel setting is causing all my problems. Thanks for any help. Oct 22 22:37:20 phlegmish kernel: Unable to handle kernel paging request at virtual address 00018486 Oct 22 22:37:20 phlegmish kernel: c880eae3 Oct 22 22:37:20 phlegmish kernel: *pde = Oct 22 22:37:20 phlegmish kernel: Oops: Oct 22 22:37:20 phlegmish kernel: CPU:0 Oct 22 22:37:20 phlegmish kernel: EIP: 0010:[smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-234781/96] Oct 22 22:37:20 phlegmish kernel: EFLAGS: 00010046 Oct 22 22:37:20 phlegmish kernel: eax: 0012 ebx: ecx: edx: 00014402 Oct 22 22:37:20 phlegmish kernel: esi: c1715ef8 edi: 00014402 ebp: c697e4e0 esp: c1715ec4 Oct 22 22:37:20 phlegmish kernel: ds: 0018 es: 0018 ss: 0018 Oct 22 22:37:20 phlegmish kernel: Process esd (pid: 2356, stackpage=c1715000) Oct 22 22:37:20 phlegmish kernel: Stack: c49e5204 00014402 c697e4e0 c671c000 0012 00200203 c71d3008 Oct 22 22:37:20 phlegmish kernel:0086 c8812457 00014402 0012 0003 Oct 22 22:37:20 phlegmish kernel:1011 0002 c49e5200 Oct 22 22:37:20 phlegmish kernel: Call Trace: [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-220073/96] [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-237584/96] [smbfs:__insmod_smbfs_O/lib/modules/2.4.0-test8/kernel/fs/smbfs/sm+-245443/96] [__fput+35/144] [_fput+17/64] [fput+18/24] [filp_close+82/92] Oct 22 22:37:20 phlegmish kernel: Code: 0f b7 aa 84 40 00 00 89 ef 83 c7 04 89 4c 24 1c 83 c6 04 8b Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f b7 aa 84 40 00 00 movzwl 0x4084(%edx),%ebp Code; 0007 Before first symbol 7: 89 ef mov%ebp,%edi Code; 0009 Before first symbol 9: 83 c7 04 add$0x4,%edi Code; 000c Before first symbol c: 89 4c 24 1c mov%ecx,0x1c(%esp,1) Code; 0010 Before first symbol 10: 83 c6 04 add$0x4,%esi Code; 0013 Before first symbol 13: 8b 00 mov(%eax),%eax Oct 22 23:00:02 phlegmish kernel: Unable to handle kernel NULL pointer dereference at virtual address 0018 Oct 22 23:00:02 phlegmish kernel: c015984b Oct 22 23:00:02 phlegmish kernel: *pde = Oct 22 23:00:02 phlegmish kernel: Oops: Oct 22 23:00:02 phlegmish kernel: CPU:0 Oct 22 23:00:02 phlegmish kernel: EIP:0010:[shm_swap_core+55/168] Oct 22 23:00:02 phlegmish kernel: EFLAGS: 00013286 Oct 22 23:00:02 phlegmish kernel: eax: 0a0d0a0d ebx: c1283400 ecx: 0031 edx: Oct 22 23:00:02 phlegmish kernel: esi: edi: c31d0540 ebp: 0001 esp: c1217f58 Oct 22 23:00:02 phlegmish kernel: ds: 0018 es: 0018 ss: 0018 Oct 22 23:00:02 phlegmish kernel: Process kswapd (pid: 2, stackpage=c1217000) Oct 22 23:00:02 phlegmish kernel: Stack: c31d0540 c024b111 0003 c01599f7 c31d0540 0001 001fa100 Oct 22 23:00:02 phlegmish kernel:c1217f88 c1217f8c c024b10c c024b114 0007 c01272bf 001fa100 c012735d Oct 22 23:00:02 phlegmish kernel: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NCPFS flags all files executable on NetWare Volumes with NFS Namespace
Petr/Linux, I noticed NCPFS is flagging all the files on a native NetWare volume as executable and chmod -x does not work, even if the NetWare server has the NFS namespace loaded. I looked at you code in more detail, and I did not see support their for the NFS/Unix namespace. Is this in a newer version, or has it not been implemented yet? I was testing with MARS and Native NetWare this evening and saw this. If the NFS namespace is loaded, you should be able to get to it and access and set all these bits in the file system namespace directory records. Do you need any info from me to get this working, or is there another version where I can get this for Ute-Linux? Thanks, :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
On Thu, 26 Oct 2000, octave klaba wrote: > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > let me guess: intel eepro100 or similar?? > yeap er, "me too": Bus 0, device 2, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xb5fff000 [0xb5fff000]. I/O at 0x2400 [0x2401]. Non-prefetchable 32 bit memory at 0xb5e0 [0xb5e0]. On Debian's 2.2.17-compact on a Compaq DL380 - with 60 days uptime I have 6 "eth0: card reports no resources." messages reported in dmesg. [...] > > Well known problem with that one. dont know if its fully fixed ... With > > 2.4.0-test9-pre3 it doesnt happen on my machine ... > we have 1-2 servers running 2.4.0-test9 and we got this error ... > > is there any patch to 2.2.18pre ? since the server has to run on sunday > we can still make the crazy tests 3 days. it would be cool to fix it to > 2.2.X if the bug is known ;) Unless this is "mostly harmless" a backport of any fix to 2.2.xx would be received most gratefully. Thanks, Neale. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: missing mxcsr initialization
On Fri, 27 Oct 2000, Alan Cox wrote:
> > bitmap is all about, and should be forced to go back to the bad old times
> > when you had to check the stepping levels etc to figure out what the CPU's
> > could do.
>
> You still do. In fact your example SEP specifically requires this due to
> Intel specification changes in the undocumented=->documented versions
NO.
Go back. Read ym email. Realize that you do this ONCE. At setup time.
You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
bit. You should not have to test stepping levels in normal use: that
invariably causes problems when there are more than one CPU that has some
feature.
It is insidious. It starts out as something simple like
if (stepping < 5) {
...
}
and everybody thinks it is cool. Until somebody notices that it should be
if (vendor == intel && stepping < 5) {
...
}
and it appears to work again, until it turns out that Cyrix has the same
issue, and then it ends up being the test from hell, where different
vendor tests all clash, and it gets increasingly difficult to add a new
thing later on sanely.
In contrast, having the test be
if (feature & SEPNEW) {
...
}
your test is simplified, easier to read and understand, AND it is much
easier to account for different vendors who have different stepping levels
etc. Especially as some vendors need setup code for the thing to work at
all, so it's not even stepping levels, it's stepping levels PLUS some
certain magic sequence that must have been done to initialize the thing.
No thank you. We'll just require fixed feature flags. Which can be turned
on as the features are enabled.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
NFS, Can't get request slot
Hi, We have /usr mounted over NFS on our workstations RH6.2 Server RH 6.2 nfs-utils-0.1.9.1-1 Kernel 2.2.16 These workstations happily use samba and other services without any delays but with NFS they hang in X for up to 15 minutes before NFS come back. We can ssh into the workstations and use any utility underneath X without any problems whilst it is hung in X. We have changed the Server eepro100 for a 3com 3c95x with no difference according to what has been alluded to in other kernel posts. By the evidence that we have gathered it seems that the Server is not taxed too much as samba users are getting files OK etc. The can't get request slot is plaguing many others in different ways. It looks like an NFS issue. How can this be proven? Then we can work on the problem. Thanks -- Grahame Jordan Network Manager Interim Technology Training Institute Mobile: +61 3 0408 058 209 Phone: +61 3 9243 2220 Fax: +61 3 9820 2010 e-mail: [EMAIL PROTECTED] Transforming the way people work with technology with INTEGRITY LEARNING INNOVATION TEAMWORK PERFORMANCE
Re: 2.4.0-test9 + LFS
On Thu, 26 Oct 2000, Wakko Warner wrote: > I attempted to create a 4gb sparce file with dd. It failed. > I created one that was 2.1gb in size which worked. Then I appeneded more > junk to the end of the file making it over 2.2gb. > > doing an ls -l shows: > ls: x: Value too large for defined data type > > NOTE: this worked in 2.4.0-test6 and I believe it stopped working around > test8, but I'm not sure. May have been around test7. Previous kernels allowed up to 4gb to be returned by the old stat. Upgrade your glibc and fileutils -- most recent distributions (Red Hat, SuSE, ...) are LFS ready, and the only reports I've seen about this concerned Slackware. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: scheduler
Anonymous wrote: > > In redhat where is the process scheduler located? Does this scheduler > implement round robin? It doesn't matter whether it's RedHat, or any other distribution. They're all the same kernel. Look at schedule() in kernel/sched.c to see the heart of the scheduler. My understanding is that it's a weighted round robiner, considering such things as the nice value and how often a process gets caught "holding the ball" by the clock interrupt. Hope this helps. -Brian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test[9-10] USB depmod unresolved symbols
Okay, updates: Compiled modutils 2.3.19 and the problem persists. Arch is i386, AMD K-6. Result for modprobe -ae (test10-pre5): depmod: *** Unresolved symbols in /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/dc2xx.o depmod: usb_bulk_msg depmod: usb_deregister depmod: usb_free_dev depmod: usb_inc_dev_use depmod: usb_register depmod: *** Unresolved symbols in /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/ov511.o depmod: usb_deregister depmod: usb_free_urb depmod: usb_alloc_urb depmod: usb_register depmod: usb_submit_urb depmod: usb_driver_release_interface depmod: usb_control_msg depmod: usb_set_interface depmod: usb_unlink_urb depmod: *** Unresolved symbols in /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/printer.o depmod: usb_deregister depmod: usb_register depmod: usb_submit_urb depmod: usb_set_interface depmod: usb_unlink_urb depmod: *** Unresolved symbols in /lib/modules/2.4.0-test10-pre5/kernel/drivers/usb/scanner.o depmod: usb_bulk_msg depmod: usb_deregister depmod: usb_register depmod: usb_submit_urb depmod: usb_driver_release_interface depmod: usb_unlink_urb Let me know if you need more info. __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test10-pre5: netfilter compile error
i get the following when trying to compile netfilter: ld -m elf_i386 -r -o fs.o filesystems.o open.o read_write.o devices.o file_table.o buffer.o super.o block_dev.o stat.o exec.o pipe.o namei.o fcntl.o ioctl.o readdir.o select.o fifo.o locks.o dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o dquot.o binfmt_script.o binfmt_elf.o proc/proc.o partitions/partitions.o ext2/ext2.o devfs/devfs.o nls/nls.o devpts/devpts.o make[2]: Leaving directory `/misc/src/linux/fs' make[1]: Leaving directory `/misc/src/linux/fs' make CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strict-aliasing " -C net make[1]: Entering directory `/misc/src/linux/net' /usr/src/linux/Rules.make:145: target `_subdir_sched' given more than once in the same rule. make -C core make[2]: Entering directory `/misc/src/linux/net/core' make all_targets make[3]: Entering directory `/misc/src/linux/net/core' kgcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe-fno-strict-aliasing -DEXPORT_SYMTAB -c netfilter.c netfilter.c:43: `NF_MAX_HOOKS' undeclared here (not in a function) netfilter.c:52: parse error before `nf_queue_outfn_t' netfilter.c:52: warning: no semicolon at end of struct or union netfilter.c:54: parse error before `}' netfilter.c:54: warning: type defaults to `int' in declaration of `queue_handler' netfilter.c:54: warning: data definition has no type or storage class netfilter.c:56: warning: `struct nf_hook_ops' declared inside parameter list netfilter.c:56: warning: its scope is only this definition or declaration, netfilter.c:56: warning: which is probably not what you want. netfilter.c: In function `nf_register_hook': netfilter.c:61: dereferencing pointer to incomplete type netfilter.c:61: dereferencing pointer to incomplete type netfilter.c:62: dereferencing pointer to incomplete type netfilter.c:62: dereferencing pointer to incomplete type netfilter.c:64: dereferencing pointer to incomplete type netfilter.c:64: dereferencing pointer to incomplete type netfilter.c:67: dereferencing pointer to incomplete type netfilter.c:58: warning: `i' might be used uninitialized in this function netfilter.c: At top level: netfilter.c:72: warning: `struct nf_hook_ops' declared inside parameter list netfilter.c: In function `nf_unregister_hook': netfilter.c:75: dereferencing pointer to incomplete type netfilter.c: At top level: netfilter.c:87: warning: `struct nf_sockopt_ops' declared inside parameter list netfilter.c: In function `nf_register_sockopt': netfilter.c:97: dereferencing pointer to incomplete type netfilter.c:97: dereferencing pointer to incomplete type netfilter.c:98: dereferencing pointer to incomplete type netfilter.c:98: dereferencing pointer to incomplete type netfilter.c:99: dereferencing pointer to incomplete type netfilter.c:99: dereferencing pointer to incomplete type netfilter.c:100: dereferencing pointer to incomplete type netfilter.c:100: dereferencing pointer to incomplete type netfilter.c:101: dereferencing pointer to incomplete type netfilter.c:101: dereferencing pointer to incomplete type netfilter.c:112: dereferencing pointer to incomplete type netfilter.c: At top level: netfilter.c:118: warning: `struct nf_sockopt_ops' declared inside parameter listnetfilter.c: In function `nf_unregister_sockopt': netfilter.c:123: dereferencing pointer to incomplete type netfilter.c:125: dereferencing pointer to incomplete type netfilter.c:131: dereferencing pointer to incomplete type netfilter.c: In function `nf_sockopt': netfilter.c:292: dereferencing pointer to incomplete type netfilter.c:294: dereferencing pointer to incomplete type netfilter.c:295: dereferencing pointer to incomplete type netfilter.c:296: dereferencing pointer to incomplete type netfilter.c:298: dereferencing pointer to incomplete type netfilter.c:302: dereferencing pointer to incomplete type netfilter.c:303: dereferencing pointer to incomplete type netfilter.c:304: dereferencing pointer to incomplete type netfilter.c:306: dereferencing pointer to incomplete type netfilter.c:317: dereferencing pointer to incomplete type netfilter.c:318: dereferencing pointer to incomplete type netfilter.c:319: dereferencing pointer to incomplete type netfilter.c:285: warning: `ret' might be used uninitialized in this function netfilter.c: In function `nf_iterate': netfilter.c:345: dereferencing pointer to incomplete type netfilter.c:347: warning: unreachable code at beginning of switch statement netfilter.c: At top level: netfilter.c:372: parse error before `nf_queue_outfn_t' netfilter.c:373: warning: function declaration isn't a prototype netfilter.c: In function `nf_register_queue_handler': netfilter.c:377: `pf' undeclared (first use in this function) netfilter.c:377: (Each undeclared identifier is reported only once netfilter.c:377: for each function it appears in.) netfilter.c:380: `outfn' undeclared (first use in this function) netfilter.c: In function `n
Re: kqueue microbenchmark results
* Alan Cox <[EMAIL PROTECTED]> [001026 18:33] wrote: > > the application of a close event. What can I say, "the fd formerly known > > as X" is now gone? It would be incorrect to say that "fd X was closed", > > since X no longer refers to anything, and the application may have reused > > that fd for another file. > > Which is precisely why you need to know where in the chain of events this > happened. Otherwise if I see > > 'read on fd 5' > 'read on fd 5' > > How do I know which read is for which fd in the multithreaded case No you don't, you don't see anything with the current code unless fd 5 is still around, what you're presenting to Jonathan is a application threading problem, not something that need to be resolved by the OS. > > As for the multi-thread case, this would be a bug; if one thread closes > > the descriptor, the other thread is going to get an EBADF when it goes > > to perform the read. > > Another thread may already have reused the fd This is another example of an application threading problem. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9 + LFS
I attempted to create a 4gb sparce file with dd. It failed. I created one that was 2.1gb in size which worked. Then I appeneded more junk to the end of the file making it over 2.2gb. doing an ls -l shows: ls: x: Value too large for defined data type NOTE: this worked in 2.4.0-test6 and I believe it stopped working around test8, but I'm not sure. May have been around test7. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux's implementation of poll() not scalable?
In article [EMAIL PROTECTED]> you write: >Linus Torvalds wrote: >> I'd much rather have an event interface that is documented to be edge- >> triggered and is really _lightweight_, than have another interface that >> starts out with some piggy features. > >Agreed (except for that 'edge-triggered' part), but I don't think >'level-triggered' implies piggy. I haven't benchmarked whether >kqueue() slows down the networking layer of FreeBSD yet; do you >suspect maintaining the level-triggered structures actually is >a bottleneck for them? I really don't think it's a bottleneck. At the moment, all events are maintained on a linked list. To dequeue an event, we simply: 1. take the event on the front of the list. 2. validate event. (call filter function) 3. copy event into return array. 4. put event back on end of list. If the `EV_ONESHOT' flag is set, we skip steps 2 & 4, and destroy the event after it is returned to the user. (we want to wait only once for this particular event) If the `EV_CLEAR' flag is set, we skip step 4. (pure edge-triggered delivery) Step 4 is pretty simple, just re-insertion back onto the queue. If you eliminate Step 2, then you have a `correctness' issue; where the application must deal with stale events. The validation function is equally lightweight and doesn't (IMO) cause a performance problem. >> ... the "re-bind()" approach works very simply, and means that the >> overhead of testing whether the event is still active is not a generic >> thing that _always_ has to be done, but something where the application >> can basically give the kernel the information that "this time we're >> leaving the event possibly half-done, please re-test now". > >Hmm. I don't like the extra system call, though. Any chance you'd be >willing to make get_events() take a vector of bind requests, so we can >avoid the system call overhead of re-binding? (Or is that too close >to kqueue for you?) IMO, I'd think that the calls should be orthogonal. If the "get_events()" call returns an array, why shouldn't the "bind_request()" call as well? Otherwise you're only amortizing the system calls in one direction. >And are you sure apps will always know whether they need to rebind? >Sometimes you're faced with a protocol stack which may or may not >read the requests fully, and which you aren't allowed to change. >It'd be nice to still have a high-performance interface that can deal with >that situation. Agreed. -- Jonathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
> the application of a close event. What can I say, "the fd formerly known > as X" is now gone? It would be incorrect to say that "fd X was closed", > since X no longer refers to anything, and the application may have reused > that fd for another file. Which is precisely why you need to know where in the chain of events this happened. Otherwise if I see 'read on fd 5' 'read on fd 5' How do I know which read is for which fd in the multithreaded case > As for the multi-thread case, this would be a bug; if one thread closes > the descriptor, the other thread is going to get an EBADF when it goes > to perform the read. Another thread may already have reused the fd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] Re: LVM snapshotting broken?
On Fri, Oct 27, 2000 at 01:53:08AM +0200, Christoph Hellwig wrote: > Look like a structure mis-match to me, although lv_v2_t is the same for > all tools. Sorry I was wrong. The __unused field is missing. Yet another reason for an official 0.8 maintaince release ;) Christoph -- Always remember that you are unique. Just like everyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] address-space identification for /proc
On Thu, Oct 26, 2000 at 07:01:26PM -0400, Johannes Erdfelt wrote: > and even more obvious: > > + buffer += sprintf(buffer, "ASID:\t%p\n", mm); > > Actually putting it into the buffer would be useful as well :) That serves me right for hand-editing patches. J -- Repeat to self: I am not Linus PGP signature
Re: missing mxcsr initialization
> > corrected for include the facts that the XMM feature bit is an Intel specific > > bit that other vendors may use for other things, so you need to test vendor == >^^^ > Note that they shouldn't do that! I would consider a very bad thing if they > goes out of sync on those bits. CPUID is vendor specific. Every bit in those fields is vendor specific. Every piece of documentation tells you to check the CPU vendor. Every time we didnt bother we got burned. I keep hearing people saying things like 'bad thing' 'assume standards'. Well all I can say is cite a vendor issued document which says 'dont bother checking the vendor'. And when you can't find that document, put the checks in so we dont crash on an Athlon or when using MTRR on a Cyrix III etc Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
On Fri, Oct 27, 2000 at 01:50:40AM +0100, Alan Cox wrote: > > kqueue currently does this; a close() on an fd will remove any pending > > events from the queues that they are on which correspond to that fd. > > This seems an odd thing to do. Surely what you need to do is to post a > 'close completed' event to the queue. This also makes more sense when you > have a threaded app and another thread may well currently be in say a read > at the time it is closed Actually, it makes sense when you think about it. The `fd' is actually a capability that the application uses to refer to the open file in the kernel. If the app does a close() on the fd, it destroys this naming. The application then has no capability left which refers to the formerly open socket, and conversly, the kernel has no capability (name) to notify the application of a close event. What can I say, "the fd formerly known as X" is now gone? It would be incorrect to say that "fd X was closed", since X no longer refers to anything, and the application may have reused that fd for another file. As for the multi-thread case, this would be a bug; if one thread closes the descriptor, the other thread is going to get an EBADF when it goes to perform the read. -- Jonathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
* Alan Cox <[EMAIL PROTECTED]> [001026 17:50] wrote: > > kqueue currently does this; a close() on an fd will remove any pending > > events from the queues that they are on which correspond to that fd. > > This seems an odd thing to do. Surely what you need to do is to post a > 'close completed' event to the queue. This also makes more sense when you > have a threaded app and another thread may well currently be in say a read > at the time it is closed Kqueue's flexibility could allow this to be implemented, all you would need to do is make a new filter trigger. You might need a _bit_ of hackery to make sure those aren't removed, or one could just add the event after clearing all pending events. Adding a filter to be informed when a specific fd is closed is certainly an option, it doesn't make very much sense because that fd could then be reused quickly by something else... but anyhow: The point of this interface is to ask kqueue to report only on the things you are interested in, not to generate superfluous that you wouldn't care about. You could make such a flag if Linux adopted this interface and I'm sure we'd be forced to adopt it, but if you make kqueue generate info an application won't care about I don't think that would be taken back. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
Rik writes: > it looks like the LVM snapshotting in 2.4 doesn't allow you > to create snapshots from anything else than the _first_ LV > in the VG... > > It looks like somewhere in either the utilities or the > kernel, the argument of which LV to snapshot gets mangled... > Oh, I'm using version 0.8final of the LVM utities. One thing to notice is that the 0.8final tools have several bugs in them. Most of these bugs are fixed in my user tools SRPM at: ftp://ftp.stelias.com/pub/adilger/ If you are compiling on a 2.4 system, you need to patch the lvm.h file with the following patch, so that you can use the same header in kernel and user space. One of the problems with snapshots is that there is a char __unused field added in the 2.4 kernel sources that is not in the header for the user tools, and this is only affecting snapshots, so it is best to use the same header for both. This patch should probably be added to the stock 2.4 kernel... Give my user tools a try (if you aren't doing so already), to ensure you aren't hitting a known bug, and the lvm.h patch so you aren't having trouble with struct parsing between kernel and user space. Cheers, Andreas patch to make 2.4 lvm.h usable from LVM user tools - --- linux-2.4.0-test10-pre5/include/linux/lvm.h Thu Oct 26 18:43:42 2000 +++ linux/include/linux/lvm.h Thu Oct 26 18:39:13 2000 @@ -49,6 +50,8 @@ *08/12/1999 - changed LVM_LV_SIZE_MAX macro to reflect current 1TB limit *01/01/2000 - extended lv_v2 core structure by wait_queue member *12/02/2000 - integrated Andrea Arcagnelli's snapshot work + *18/02/2000 - seperated user and kernel space parts by + * #ifdef them with __KERNEL__ * */ @@ -56,7 +59,9 @@ #ifndef _LVM_H_INCLUDE #define _LVM_H_INCLUDE -#define_LVM_H_VERSION "LVM 0.8final (15/2/2000)" +#define_LVM_H_VERSION "LVM 0.8final (22/02/2000)" + +#include /* * preprocessor definitions @@ -64,8 +69,9 @@ /* if you like emergency reset code in the driver */ #defineLVM_TOTAL_RESET +#ifdef __KERNEL__ #define LVM_GET_INODE -#undef LVM_HD_NAME +#defineLVM_HD_NAME /* lots of debugging output (see driver source) #define DEBUG_LVM_GET_INFO @@ -80,20 +86,19 @@ #define DEBUG_KFREE */ -#include - -#ifndef __KERNEL__ -#define NOT_KERNEL +#include +#include +#else #define __KERNEL__ -#endif #include -#ifdef NOT_KERNEL -#undef NOT_KERNEL +#include #undef __KERNEL__ -#endif +#endif /* #ifndef __KERNEL__ */ +#include #include +#ifdef __KERNEL__ #if LINUX_VERSION_CODE >= KERNEL_VERSION ( 2, 3 ,0) #include #else @@ -101,6 +106,8 @@ #endif #include +#endif /* #ifdef __KERNEL__ */ + #include #if !defined ( LVM_BLK_MAJOR) || !defined ( LVM_CHAR_MAJOR) @@ -125,7 +132,7 @@ #define pv_disk_t pv_disk_v1_t #define lv_disk_t lv_disk_v1_t #define vg_disk_t vg_disk_v1_t -#define lv_exception_t lv_v2_exception_t +#define lv_block_exception_t lv_block_exception_v1_t #endif @@ -220,7 +227,7 @@ LVM_TIMESTAMP_DISK_SIZE) /* now for the dynamically calculated parts of the VGDA */ -#defineLVM_LV_DISK_OFFSET(a, b) ( (a)->lv_on_disk.base + sizeof ( lv_t) * b) +#defineLVM_LV_DISK_OFFSET(a, b) ( (a)->lv_on_disk.base + sizeof ( lv_disk_t) +* b) #defineLVM_DISK_SIZE(pv)( (pv)->pe_on_disk.base + \ (pv)->pe_on_disk.size) #defineLVM_PE_DISK_OFFSET(pe, pv) ( pe * pv->pe_size + \ @@ -386,8 +392,7 @@ kdev_t rdev_org; ulong rsector_new; kdev_t rdev_new; -} lv_block_exception_t; - +} lv_block_exception_v1_t; /* disk stored pe information */ typedef struct @@ -597,10 +558,14 @@ __u32 lv_remap_end; __u32 lv_chunk_size; __u32 lv_snapshot_minor; +#ifdef __KERNEL__ struct kiobuf * lv_iobuf; struct semaphore lv_snapshot_sem; struct list_head * lv_snapshot_hash_table; -unsigned long lv_snapshot_hash_mask; +ulong lv_snapshot_hash_mask; +#else +char dummy[200]; +#endif } lv_v2_t; /* disk */ -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
> certainly accept it), then why not just do the equivalent of a reset in > the high-level IDE driver on coming back from sleep? Possibly together > with forcing any other setup state we know about. Because windows seems to drop the controller back to PIO mode 0 and the BIOS knows about it. At least in the palmax case, although since 2.4test doesnt boot on it as of pre9 I've not tried the 2.4 patches yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: killing read_ahead[]
"Jeff V. Merkey" wrote: > > Martin, > > A lot of changes. Have you tested this adequately? Changes of this > magnitude this late in the 2.4 cycle could break a lot of stuff. I'll > apply your patch, and let you know. > > :-) > > Jeff Martin, 1. Adaptec SCSI driver on a 4 x P6 POCA blows up with timeout errors then hard hangs machine. 2. DVD-RAM drive gets scsi timeout errors on AMD K6 System. 3. Cannot see the MASHITA RW-CDROM with ide-scsi loaded with patch. 4. 2.4.0 hard locks on dual processor PIII 400Mhz during kernel boot. :-) Well, I tried the patch. Looks like some SMP issues of some kind. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
> kqueue currently does this; a close() on an fd will remove any pending > events from the queues that they are on which correspond to that fd. This seems an odd thing to do. Surely what you need to do is to post a 'close completed' event to the queue. This also makes more sense when you have a threaded app and another thread may well currently be in say a read at the time it is closed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Topic for discussion: OS Design
Richard B. Johnson writes: > On Thu, 26 Oct 2000, Albert D. Cahalan wrote: >> Richard B. Johnson writes: >>> o Once installed, a kernel module is every bit as "efficient" >>> as some driver linked into the kernel at build-time. Of course >> >> I doubt this is true on most modern processors. On the Pentium >> and above, large pages are used for the kernel. The PowerPC port > ^^^ > > The page-size is determined by the architecture. The page sizes are determined by the architecture. For common Intel chips: 4 kB, 2 MB, 4 MB. (some restrictions may apply -- Ingo Molnar would know) For ia64, you get about a dozen different sizes ranging from the old 4 kB pages up to something like 256 MB. For the PowerPC you have BAT registers that override page tables. You get 4 for code and 4 for data, so you can map all physical memory for the kernel w/o using page table entries or TLB slots. The SPARC code, if I recall correctly, does not maintain page tables for normal kernel code. If the virtual address is within the direct mapped region, a software TLB loader just adds an offset to get the physical address. So your modules suffer by being unable to take advantage of more efficent virtual-to-physical mapping mechanisms. >> uses BAT registers. Other ports have other hacks to reduce TLB >> misses and/or wasted memory. Also, you waste half a page or more >> for the average module. > > Since kernel memory is allocated in pages, you use whatever you > need. If a module is 4097 bytes in length, you could, in principle, > 'waste' 4095 bytes. So what? it's never paged or otherwise producing > any overhead whatsoever. What, wasted memory is not overhead? Also, consider the cache effects. To keep things simple, assume you have a highly modular kernel and that modules are 2 kB. Also, you have separate 4-way 16 kB L1 caches for code and data. Well, you now have an 8 kB cache for code, along with 8 kB of useless transistors. Of course this is bad, even if you don't have modules that are exactly 2 kB. > These are modules I have written for a project. Since these are object > files, they contain not only code, but also a relocation table. So they > don't require as much memory as the file size shows. However, since > these are all modules, the relocation table is similar in size and > can be considered a constant. > > 6204 Oct 24 10:48 firewire.o8192 - 6204 = 1988 > 11120 Oct 24 10:48 gpib_drvr.o 12288 - 11120 = 1168 > 6692 Oct 24 10:48 ramdisk.o 8192 - 6692 = 1500 > 3886 Oct 24 10:48 rtc_drvr.o4096 - 3886 = 210 > 6776 Oct 25 12:38 vxibus.o 8192 - 6776 = 1416 > Totals >346786282 > > This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 > pages. Since there are 5 modules, we waste about 1/3 page per module. > > So I don't, as you say; "... waste 1/2 page or more per module". Somebody else posted their numbers: you waste about 15% of memory. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux's implementation of poll() not scalable?
Linus Torvalds wrote: > However, we also need to remember what got us to this discussion in the > first place. One of the reasons why poll() is such a piggy interface is > exactly because it tries to be "nice" to the programmer. poll() is a piggy interface because it is O(n) in polled file descriptors, not because of its level-triggered nature. > I'd much rather have an event interface that is documented to be edge- > triggered and is really _lightweight_, than have another interface that > starts out with some piggy features. Agreed (except for that 'edge-triggered' part), but I don't think 'level-triggered' implies piggy. I haven't benchmarked whether kqueue() slows down the networking layer of FreeBSD yet; do you suspect maintaining the level-triggered structures actually is a bottleneck for them? > I do understand that level to some degree is "nicer", but everybody pretty > much agrees that apart from requireing more care, edge-triggered certainly > does everything the level-triggered interfaces do. Agreed. > For example, if you want to only partially handle an event (one of the > more valid arguments I've seen, although I do not agree with it actually > being all that common or important thing to do), the edge-triggered > interface _does_ allow for that. It's fairly easy, in fact: you just > re-bind the thing. > > (My suggested "bind()" interface would be to just always add a newly bound > fd to the event queue, but I would not object to a "one-time test for > active" kind of "bind()" interface either - which would basically allow > for a poll() interface - and the existing Linux internal "poll()" > implementation actually already allows for exactly this so it wouldn't > even add any complexity). > ... the "re-bind()" approach works very simply, and means that the > overhead of testing whether the event is still active is not a generic > thing that _always_ has to be done, but something where the application > can basically give the kernel the information that "this time we're > leaving the event possibly half-done, please re-test now". Hmm. I don't like the extra system call, though. Any chance you'd be willing to make get_events() take a vector of bind requests, so we can avoid the system call overhead of re-binding? (Or is that too close to kqueue for you?) And are you sure apps will always know whether they need to rebind? Sometimes you're faced with a protocol stack which may or may not read the requests fully, and which you aren't allowed to change. It'd be nice to still have a high-performance interface that can deal with that situation. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: missing mxcsr initialization
> Let's face it. People who don't follow the intel ordering of bits are > _buggy_. And yes, there are tons of buggy chips out there (mainly from Its tricky to do so, some of them were not even documented. And one of them (SEP) changed in the undocumented phase from one version of SYSCALL to another (now documented one) > bitmap is all about, and should be forced to go back to the bad old times > when you had to check the stepping levels etc to figure out what the CPU's > could do. You still do. In fact your example SEP specifically requires this due to Intel specification changes in the undocumented=->documented versions Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel build and symbol version problem with RedHat Linux 7
On Wed, 25 Oct 2000 16:48:05 -0600, [EMAIL PROTECTED] wrote: >scsi_register--> scsi_register_R__ver_scsi_register You have been bitten by the broken Makefiles, time to do a complete cleanup and start again. mv .config .. make mrproper (clean is not enough) mv ../.config .. make oldconfig dep clean vmlinux modules Install. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Thu, Oct 26, 2000 at 09:10:06PM -0200, Marcelo Tosatti wrote: > With LVM from 2.2.18aa kernels (I dont exactly remember which one) Ok, nothing relevant is recently changed there so it should be an userspace issue. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] Re: LVM snapshotting broken?
On Thu, Oct 26, 2000 at 11:37:07PM +, Heinz J. Mauelshagen wrote: > > Hi Rik, > > I can't reproduce it on my box. > > Could you provide a "lvcreate -d" output of what you did to help > me to dig into that one. > > Did somebody else out there face the same 0.8final snapshot weirdness? Yes. I have the same problem Rik has. A debug printf just before the ioctl in lv_create_remove gives the right ->lv_snapshot_minor. A debug printk in lvm_do_lv_create just at the beginning has ->lv_snapshot_minor _always_ = 0. This happens with the 0.8final utils, both with and without additional patches. Andrea's lvm-tools-aa-2119 are ok. Look like a structure mis-match to me, although lv_v2_t is the same for all tools. Christoph -- Always remember that you are unique. Just like everyone else. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: killing read_ahead[]
Martin,
A lot of changes. Have you tested this adequately? Changes of this
magnitude this late in the 2.4 cycle could break a lot of stuff. I'll
apply your patch, and let you know.
:-)
Jeff
Martin Dalecki wrote:
>
> Hello!
>
> Please have a look at the following patch and feel free to be scared
> by the fact how UTTERLY BROKEN and ARBITRARY the current usage of the
> read_ahead[] array and during the whole past decade was!
> If you really care about clean internal interfaces this should be
> one of those prio number ONE targets to shoot at...
>
> The most amanzing thing is that the whole test10-pre5 kernel with this
> patch applied doesn't show any performance penalties for me at all!
> And of corse it's about 10k smaller...
>
> --mdcki
>
>
> diff -ur linux-test10-pre5/arch/sparc64/kernel/ioctl32.c
>linux/arch/sparc64/kernel/ioctl32.c
> --- linux-test10-pre5/arch/sparc64/kernel/ioctl32.c Tue Oct 24 13:52:02 2000
> +++ linux/arch/sparc64/kernel/ioctl32.c Tue Oct 24 15:37:56 2000
> @@ -2136,7 +2136,7 @@
> uint32_t lv_badblock;
> uint32_t lv_allocation;
> uint32_t lv_io_timeout;
> - uint32_t lv_read_ahead;
> + uint32_t lv_NOT_USED;
> /* delta to version 1 starts here */
> u32 lv_snapshot_org;
> u32 lv_snapshot_prev;
> @@ -3100,7 +3100,6 @@
> COMPATIBLE_IOCTL(BLKROGET)
> COMPATIBLE_IOCTL(BLKRRPART)
> COMPATIBLE_IOCTL(BLKFLSBUF)
> -COMPATIBLE_IOCTL(BLKRASET)
> COMPATIBLE_IOCTL(BLKFRASET)
> COMPATIBLE_IOCTL(BLKSECTSET)
> COMPATIBLE_IOCTL(BLKSSZGET)
> @@ -3621,7 +3620,6 @@
> HANDLE_IOCTL(SIOCRTMSG, ret_einval)
> HANDLE_IOCTL(SIOCGSTAMP, do_siocgstamp)
> HANDLE_IOCTL(HDIO_GETGEO, hdio_getgeo)
> -HANDLE_IOCTL(BLKRAGET, w_long)
> HANDLE_IOCTL(BLKGETSIZE, w_long)
> HANDLE_IOCTL(0x1260, broken_blkgetsize)
> HANDLE_IOCTL(BLKFRAGET, w_long)
> diff -ur linux-test10-pre5/drivers/acorn/block/mfmhd.c
>linux/drivers/acorn/block/mfmhd.c
> --- linux-test10-pre5/drivers/acorn/block/mfmhd.c Wed Oct 4 01:39:44 2000
> +++ linux/drivers/acorn/block/mfmhd.c Tue Oct 24 15:35:40 2000
> @@ -1231,8 +1231,6 @@
> case BLKFLSBUF:
> case BLKROSET:
> case BLKROGET:
> - case BLKRASET:
> - case BLKRAGET:
> case BLKPG:
> return blk_ioctl(dev, cmd, arg);
>
> @@ -1448,7 +1446,6 @@
> hdc63463_irqpollmask= irqmask;
>
> blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
> - read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB?) read ahread */
>
> #ifndef MODULE
> mfm_gendisk.next = gendisk_head;
> diff -ur linux-test10-pre5/drivers/block/DAC960.c linux/drivers/block/DAC960.c
> --- linux-test10-pre5/drivers/block/DAC960.cTue Oct 24 13:52:03 2000
> +++ linux/drivers/block/DAC960.cTue Oct 24 15:24:51 2000
> @@ -1931,10 +1931,7 @@
>Controller->GenericDiskInfo.sizes = Controller->PartitionSizes;
>blksize_size[MajorNumber] = Controller->BlockSizes;
>max_sectors[MajorNumber] = Controller->MaxSectorsPerRequest;
> - /*
> -Initialize Read Ahead to 128 sectors.
> - */
> - read_ahead[MajorNumber] = 128;
> +
>/*
> Complete initialization of the Generic Disk Information structure.
>*/
> @@ -4964,16 +4961,6 @@
>return put_user(Controller->GenericDiskInfo.part[MINOR(Inode->i_rdev)]
> .nr_sects,
> (long *) Argument);
> -case BLKRAGET:
> - /* Get Read-Ahead. */
> - if ((long *) Argument == NULL) return -EINVAL;
> - return put_user(read_ahead[MAJOR(Inode->i_rdev)], (long *) Argument);
> -case BLKRASET:
> - /* Set Read-Ahead. */
> - if (!capable(CAP_SYS_ADMIN)) return -EACCES;
> - if (Argument > 256) return -EINVAL;
> - read_ahead[MAJOR(Inode->i_rdev)] = Argument;
> - return 0;
> case BLKFLSBUF:
>/* Flush Buffers. */
>if (!capable(CAP_SYS_ADMIN)) return -EACCES;
> diff -ur linux-test10-pre5/drivers/block/acsi.c linux/drivers/block/acsi.c
> --- linux-test10-pre5/drivers/block/acsi.c Thu Feb 17 00:42:05 2000
> +++ linux/drivers/block/acsi.c Tue Oct 24 15:24:13 2000
> @@ -1792,9 +1792,8 @@
> }
> phys_acsi_buffer = virt_to_phys( acsi_buffer );
> STramMask = ATARIHW_PRESENT(EXTD_DMA) ? 0x : 0xff00;
> -
> +
> blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
> - read_ahead[MAJOR_NR] = 8; /* 8 sector (4kB) read-ahead */
> acsi_gendisk.next = gendisk_head;
> gendisk_head = &acsi_gendisk;
>
> diff -ur linux-test10-pre5/drivers/block/ataflop.c linux/drivers/block/ataflop.c
> --- linux-test10-pre5/drivers/block/ataflop.c Wed Jul 5 20:24:40 2000
> +++ linux/drivers/block/ataflop.c Tue Oct 24 15:33:40 2000
> @@ -1571,8 +1571,6 @@
> switch (cmd) {
> case BLKROSET:
> case BLK
[launch] Beanie Award Fund
Hi,
This is a notice that was sent to the
linux-usb-devel mailing list last month.
~Randy
___
|Randy Dunlap |
|randy.dunlap_at_intel.com503-677-5408|
---
-Original Message-
From: Dunlap, Randy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 20, 2000 5:00 PM
To: 'l-u-d'
Subject: [linux-usb-devel] [launch] Beanie Award Fund
Hi,
At this time I'm announcing that the remainder of
the Slashdot Beanie award is available for expenses
for hardware or software that is used to further the
development of open source projects, preferably
Linux-USB-related or Linux-hotplug-related projects.
About the Linux-USB Purchase Request Fund
The Linux-USB Purchase Request fund (PRQ) is a limited-duration cash
distribution fund established with part of the Award made at the "2000
Slashdot Beanies", where the Linux USB community won US$10,000 for the
Most Improved Kernel Module - see
http://slashdot.org/articles/00/02/06/1950248.shtml.
The aim of the Linux-USB PRQ is to support the Open Source development
of Linux-USB. A secondary goal is to support related projects;
especially those that are likely to assist Linux-USB, such as other
hotplug support (devices or infrastructure).
The fund was started with US$6,300 in Sept. 2000. No additional
funds are being sought, and the PRQ will be wound up when all funds
are distributed.
Linux-USB Purchase Request Process
~~
1. Requests
A person or group makes a request of the Purchase Request
("PRQ") fund and the committee decides whether to grant or
deny the request.
Requests should be submitted to the PRQ team via a web-based
form (URL: http://www.linux-usb.org/beanieForm.html).
The PRQ team coordinator receives these requests and does
an initial review of them for missing information or invalid
requests. If the request is not invalid, the PRQ coordinator
logs and acknowledges it. The clock starts for the accepted
requests.
2. Qualifying Requests
Requests may be made for any hardware or software that enables
someone to contribute or continue to contribute to the
development of Linux, Linux-USB, or other open-source
Linux software projects, whether software development,
testing, or documentation.
Requests that appear most likely to advance USB support
on Linux are the primary focus, with a secondary focus
of Linux support for other PnP/hotplug buses on Linux.
Award decisions are based on many things, including
your proposal, qualifications, and track record.
No previous experience is required to get a first funding;
future funding may be based on results (positive or negative).
3. Monetary Range
The normal range of awards is expected to be US$60 to US$600, to
keep workload manageable while still assisting a reasonable number of
people. Awards outside this will only be made under exceptional
circumstances.
4. Permanence of Award
The award or grant from the purchase request fund is
"permanent." Whoever receives the award owns the hardware
or software that they purchase with it. (Of course, they
could also share it with others who could use it.)
There is no need or desire to provide receipts for the
purchase.
The recipient of an award can return the full amount of the
award within three (3) months of its receipt without
affecting future PRQ requests.
5. Consideration of Proposals
Every proposal is considered in isolation from the others,
on its own merits, and applications are accepted at any time
until the money pool is spent.
We have a goal of making a Yes/No decision within one week,
with a maximum of 2 weeks.
6. Tracking of Awards
Successful proposals are tracked on a web page while in progress
and after completion. Unsuccessful proposals are not reported to
anyone outside of the PRQ team and the requester(s).
To ensure that the purchase fund is actually helping people to
contribute to open source software, each recipient is asked to
post a message within three (3) months saying how this award
actually contributed to what they proposed. These reports will
be linked to the cumulative approved list so that it is evident
which recipients have not reported back.
7. Voting
The entire PRQ team (currently 7 members) votes or abstains
on each request.
The actual Purchase Request team members who decide on any
one funding request are not identified to the Linux-USB community.
All PRQ members are asked to vote on every PRQ proposal (or to
Abstain). Members of the PRQ team should abstain from voting
due to conflicts of interest and may abstain due to business or
personal time constraints or they feel unqualified to vote on
a particular proposal.
Valid votes are:
YES (for Approval)
NO (Comments optional but preferred)
ABSTAIN
Each proposal is sent to the PRQ coordinator who checks only for
completeness. If a subm
Re: [PATCH] address-space identification for /proc
On Thu, Oct 26, 2000, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 26, 2000 at 03:45:27PM -0700, I wrote:
> > + buffer += sprintf("ASID: %p\n", mm);
>
> Obviously, this should be:
>
> + buffer += sprintf("ASID:\t%p\n", mm);
and even more obvious:
+ buffer += sprintf(buffer, "ASID:\t%p\n", mm);
Actually putting it into the buffer would be useful as well :)
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Fri, 27 Oct 2000, Andrea Arcangeli wrote: > On Thu, Oct 26, 2000 at 06:34:48PM -0200, Rik van Riel wrote: > > On Thu, 26 Oct 2000, Rik van Riel wrote: > > > > > it looks like the LVM snapshotting in 2.4 doesn't allow you > > > to create snapshots from anything else than the _first_ LV > > > in the VG... > > > > OK, I reproduced it in 2.2 as well ... ;( > > Which 2.2.x? LVM isn't supported in 2.2.18pre17 or any other previous version. > > For some irrelevant reason I always test snapshotting on a LV with minor > number > 1 and the kernel side definitely works with 2.2.18pre17aa1: > > laser:/home/andrea # ls -l /dev/vg1/lv* > brw-r- 1 root root 58, 0 Oct 27 2000 /dev/vg1/lv0 > brw-r- 1 root root 58, 1 Oct 27 2000 /dev/vg1/lv1 > laser:/home/andrea # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M > lvcreate -- INFO: using default snapshot chunk size of 64 KB > lvcreate -- doing automatic backup of "vg1" > lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created > > laser:/home/andrea # lvremove -f /dev/vg1/lv1-snap > lvremove -- doing automatic backup of volume group "vg1" > lvremove -- logical volume "/dev/vg1/lv1-snap" successfully removed > > laser:/home/andrea # With LVM from 2.2.18aa kernels (I dont exactly remember which one) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.18pre17 + VM-global -7 = `Negative d_count' oops
On Thu, Oct 26, 2000 at 06:37:37PM +0100, Ian Jackson wrote: > Negative d_count (-805538369) for [binary garbage]/ > > followed by an oops. Kernel logfile extract below, uuencoded. Thanks for the feedback. The oops is forced by the kernel after it sees then wrong negative d_count. I'd say it's memory corruption, but it doesn't look like a memory bitflip. I'm almost certain that it's not caused by the VM-global patch. Which device driver and compiler are you using? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: QLOGIC Fibre Channel init
On Thu, 26 Oct 2000, Klaus Naumann wrote: > Byeong-ryeol Kim wrote: > > > > On Thu, 26 Oct 2000, Klaus Naumann wrote: > > > > > I was having some little trouble with the QLOGIC Fibre Channel SCSI > > > cards. > > > The issue is, that I have a box with an internal SCSI controller/disk > > > and a QLOGIC card which is connected to an external RAID. The probelm > > > is, that the internal disk is my root disk but is the second in the > > > chain (sdb) after bootup. This gives a lot of problems, because it's > > > impossible to get the system to boot (LILO isn't working). > > > Since I've modified the hosts.c it's working perfectly (at least the > > > order is better now). Patch is attached. > > > Can anyone give a comment on that please ? > > > > > > Hello, > > Your patch would be good, but there is another simple method. > > Did you happen to make the BIOS of Qlogic FC adapter enable to > > boot the machine? > > If so, while POST, timely hit 'Ctrl + Q', and disable boot > > ability in BIOS setting of it. > > No, I have the bios of the controller disabled. > The problem with that is that on boot up (for lilo) the internal disk > is disk number one. But when I'm in the system and want to install lilo > it's disk number two - that's what lilo is complaining about on boot up. > (By spewing out an L and a 01 01 01 01 and so on). > Activating the bios of the QLOGIC (to make the internal disk appear > to be the 2nd one on bootup) didn't solve the problem too - I simply > got a message saying I should insert a system disk ;) Aha, I forgot to describe about making qlogic drivers as a module. While I had been setting and testing SAN switch(Brocade, Gadzoox), RAID with Qlogic 2100(or 2200A), I had the same experience that you described in the previous mail, and solved the problem by patching drivers/scsi/hosts.c as you did. It was a good solution. But, I became aware of the convenience and flexibility of modular drivers(or initrd) in this case. Because, I thought, whenever I do the same test or benchmarking, rebooting the system each is terrible. In that method, I experienced no problem such that you described in the previous E-mail. -- "Where there is a will, there is a way." [EMAIL PROTECTED] For the future of you and me!hitel: jinbo21 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Quota mods needed for journaled quota
hi Stephen, On Oct 26, 11:00am, Stephen C. Tweedie wrote: > Subject: Re: Quota mods needed for journaled quota > ... > > This would allow ext3 to do that which it needs to do differently > > at Q_QUOTAON and would also allow Jan's changes to work in such > > a way that both the current form of dquot structure and his new > > version of dquots could be used together > > Adding the init_quota hook would do that, as the filesystem will be > able to install its own dq_ops methods during the init so we get the > flexibility you are asking for anyway. > Hmmm ... I'm not so sure. In order to have the flexibility of filesystem-specific dquot formats, the struct dquot would need to become more like struct inode/super_block, i.e. not hardcoding the ondisk structure into the incore structure (using a union and a generic pointer, as inode/super_block do). The DQUOT_SYNC mechanism would need to be able to be overridden per-filesystem also. It isn't really as cut-and-dried as "per- filesystem" either, because an ext2/3 filesystem might make use of either the original dquot format or Jan's newer format, either at mount time or even after doing a quota_off & quota_on with a new quota file format (that would be quite clean). But I've sidetracked completely from what you were originally talking about now, which had nothing to do with a different ondisk format at all. cheers. -- Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre5 won't boot on my Athlon machine (Irongate and Viper chip sets)
Miles Lane wrote:
> Perhaps this is related to the PCI issues that are being debated on the list now.
> Would someone look at my bus configuration and let me know what to test or what
>patch to apply to get my kernel booting?
My Athlon box has a MSI A6195KMS bios. The motherboard has the IronGate and the Viper
chipsets, and test10-pre5 works great on it.
One possible caveats :
- USB doesn't work too well, because of a bug in the Viper USB controller. You may
want to try to disable "PnP aware OS" in the bios. You may also try to download the
latest rev of the A6195KMS bios
available here :
http://www.amdzone.com/files/bios/msi/a6195kms173.zip
- Even when USB finally works, the ohci USB driver sends this kind of message all the
time :
usb-ohci.c: bogus NDP=64 for OHCI usb-00:07.4
usb-ohci.c: rereads as NDP=4
but it shouldn't kill your machine. In any doubt, just disable USB.
Otherwise, let me know if you want me to send you my .config and my BIOS settings, it
you think they can help you.
Take care !
--
__
_ / / | / ___/ _ /
/ /| / / / /
___ / / // __// /
__ / / // / / /
_ _/ _/ _/ _/ _/ /
\
(@ @)
oOOo-(_)-oOOo-
Pierre-Philippe Coupard
Software Engineer, Lineo, Inc.
Email : [EMAIL PROTECTED]
Phone : (801) 426-5001 x 208
--
A door is what a dog is perpetually on the wrong side of.
-- Ogden Nash
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with msgsnd
On Thu, 26 Oct 2000 17:15:30 Marc Schneider wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Marc Schneider wrote:
> > >
> > > msgsnd seems to be corrupting memory around the msgbuf pointer.
> > >
> > > for example I have the following code:
> > >
> > > pMsgBuf = malloc(iPacketLen + 4 + 8);
> > > bzero(pMsgBuf, iPacketLen + 4 + 8);
> > > pMsgBuf += 4; /* Build a guard band */
> > >
> > > printf("PMQ:pMsgBuf: %p\n",pMsgBuf);
> > > printf("PMQ:-4: %p\n", *(pMsgBuf-4));
> > >
Silly question: why do you :
printf("PMQ:-4: %p\n", *(pMsgBuf-4));
instead of:
!!!
printf("PMQ:-4: %d\n", *(pMsgBuf-4));, or whatever applies...(typeof pMsgBuf?)
If you use %p, printf expects a pointer in stack, and depending on type of
pMsgBuf (is a char * ?), *pMsgBuf can be passed as a char (I don't think so,
C passes chars as ints, and I dont remenber any kind of option to modify this)
or a short or an int...
So, perhaps you dont put enough data on stack for a pointer and printf gets
incorrect data (the zero in pMsgBuf plus the return value that stored in rc...).
--
Juan Antonio Magallon Lacarta mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
On Thu, Oct 26, 2000 at 06:21:41PM -0400, Alan Cox wrote: > > Well, this is usually handled by a third module that takes care of > > registering/unregistering the existence of the two modules that need to > > be possible to load/unload separately. > > But that module then depends on both of the others unless you keep recompiling > it Not really, see for example ns558.c and adi.c plus their third module gameport.c, all in drivers/char/joystick. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
Andre Hedrick writes: > APM signals ATA/IDE to goto sleep. > IDE then records and buffers the setup of the host and device. > IDE forces device and host to PIO 0 (imortant step, explain later) > IDE issues spindown and sleep task-command. > IDE returns to APM with success/failure. Insert here... BIOS tries to hibernate to disk and finds the disk already asleep. > success, sets request_queue blocker flag (very critical) _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] address-space identification for /proc
On Thu, Oct 26, 2000 at 03:45:27PM -0700, I wrote:
> + buffer += sprintf("ASID: %p\n", mm);
Obviously, this should be:
+ buffer += sprintf("ASID:\t%p\n", mm);
for consistency.
J
PGP signature
[PATCH] address-space identification for /proc
Hi,
/proc has no way to indicate whether tasks share an address space.
This one-liner patch adds a new ASID: field to /proc//status so
there's some way to see address-space sharing between tasks.
While this is hardly a bug-fix, it is a pretty useful thing to know
which is otherwise completely absent.
J
--- ../2.3/fs/proc/array.c Mon Oct 9 17:03:53 2000
+++ linux/fs/proc/array.c Thu Oct 26 15:20:52 2000
@@ -294,6 +294,7 @@
for(line=0;(len=sprintf_regs(line,buffer,task,NULL,NULL))!=0;line++)
buffer+=len;
#endif
+ buffer += sprintf("ASID: %p\n", mm);
return buffer - orig;
}
PGP signature
Re: LVM snapshotting broken?
On Thu, Oct 26, 2000 at 06:34:48PM -0200, Rik van Riel wrote: > On Thu, 26 Oct 2000, Rik van Riel wrote: > > > it looks like the LVM snapshotting in 2.4 doesn't allow you > > to create snapshots from anything else than the _first_ LV > > in the VG... > > OK, I reproduced it in 2.2 as well ... ;( Which 2.2.x? LVM isn't supported in 2.2.18pre17 or any other previous version. For some irrelevant reason I always test snapshotting on a LV with minor number > 1 and the kernel side definitely works with 2.2.18pre17aa1: laser:/home/andrea # ls -l /dev/vg1/lv* brw-r- 1 root root 58, 0 Oct 27 2000 /dev/vg1/lv0 brw-r- 1 root root 58, 1 Oct 27 2000 /dev/vg1/lv1 laser:/home/andrea # lvcreate -s -n lv1-snap /dev/vg1/lv1 -L 400M lvcreate -- INFO: using default snapshot chunk size of 64 KB lvcreate -- doing automatic backup of "vg1" lvcreate -- logical volume "/dev/vg1/lv1-snap" successfully created laser:/home/andrea # lvremove -f /dev/vg1/lv1-snap lvremove -- doing automatic backup of volume group "vg1" lvremove -- logical volume "/dev/vg1/lv1-snap" successfully removed laser:/home/andrea # Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test10-pre5 won't boot on my Athlon machine (Irongate and Viper chip sets)
Perhaps this is related to the PCI issues that are being debated on the list now. Would someone look at my bus configuration and let me know what to test or what patch to apply to get my kernel booting? lspci -vv reports: 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] System Controller (rev 25) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] AGP Bridge (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-756 [Viper] ISA (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make agpsupport work with modversions
> Well, this is usually handled by a third module that takes care of > registering/unregistering the existence of the two modules that need to > be possible to load/unload separately. But that module then depends on both of the others unless you keep recompiling it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel.org back up (film at 11)
Good job -- A++. I hardly even noticed it was down. :-) Jeff "H. Peter Anvin" wrote: > > kernel.org is back up. > > -hpa > > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Fixes for the input (joystick, USB) drivers
Hi!
The attached patch fixes many different little bugs in the USB input,
joystick input and core input drivers maintained by me.
drivers/char/joystick/adi.c:
Fix gamepad handling for Logitech ThunderPad Digital and WingMan Gamepad
drivers/char/joystick/gamecon.c
Fix PSX gamepad support - patch by Nathan Hand
drivers/char/joystick/iforce.c
Fix breakage caused by recent usb_submit_urb() changes
drivers/char/joystick/ns558.c
Fix the already fixed 'oops on rmmod' problem in a slightly different way
Fix another two possible causes for 'oops on rmmod'
drivers/char/joystick/sidewinder.c
Fix a missing button for Microsoft ForceFeedback Wheel
drivers/char/joystick/tmdc.c
Fix the ThrustMaster FragMaster by adding specific support,
generic support isn't good enough
drivers/input/evdev.c
Fix two possible overflow cases.
Add event write() support, needed badly
drivers/input/joydev.c
Fix two possible overflow cases.
drivers/input/mousedev.c
Fix two possible overflow cases.
Change 5-button support from GenPS/2 to ImExPS/2, making it
finally useful with XFree (which only supports ImExPS/2 5-button mice)
Add xmax and ymax module parameters, needed for binary distribution
drivers/usb/usbkbd.c
Fix breakage caused by recent usb_submit_urb() changes
drivers/usb/usbmouse.c
Unify the usb_submit_urb() fix to match usbkbd, wacom and others
drivers/usb/wacom.c
Fix the Intuos 4DMouse and Intuos Lens tool behavior (James E. Blair)
The patch is against 2.4.0-test10-pre5.
TIA.
--
Vojtech Pavlik
SuSE Labs
diff -urN linux-test10-pre5-old/drivers/char/joystick/adi.c
linux/drivers/char/joystick/adi.c
--- linux-test10-pre5-old/drivers/char/joystick/adi.c Thu Jun 22 15:59:58 2000
+++ linux/drivers/char/joystick/adi.c Thu Oct 26 23:02:11 2000
@@ -1,5 +1,5 @@
/*
- * $Id: adi.c,v 1.12 2000/06/03 20:18:52 vojtech Exp $
+ * $Id: adi.c,v 1.14 2000/10/23 07:28:57 vojtech Exp $
*
* Copyright (c) 1998-2000 Vojtech Pavlik
*
@@ -418,7 +418,7 @@
adi->dev.private = port;
adi->dev.evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
- for (i = 0; i < adi->axes10 + adi->axes8 + adi->hats * 2; i++)
+ for (i = 0; i < adi->axes10 + adi->axes8 + (adi->hats + (adi->pad > 0)) * 2;
+i++)
set_bit(adi->abs[i], &adi->dev.absbit);
for (i = 0; i < adi->buttons; i++)
@@ -431,7 +431,7 @@
if (!adi->length) return;
- for (i = 0; i < adi->axes10 + adi->axes8 + adi->hats * 2; i++) {
+ for (i = 0; i < adi->axes10 + adi->axes8 + (adi->hats + (adi->pad > 0)) * 2;
+i++) {
t = adi->abs[i];
x = adi->dev.abs[t];
diff -urN linux-test10-pre5-old/drivers/char/joystick/gamecon.c
linux/drivers/char/joystick/gamecon.c
--- linux-test10-pre5-old/drivers/char/joystick/gamecon.c Mon Aug 14 22:55:01
2000
+++ linux/drivers/char/joystick/gamecon.c Thu Oct 26 23:02:11 2000
@@ -1,11 +1,11 @@
/*
- * $Id: gamecon.c,v 1.5 2000/06/25 09:56:58 vojtech Exp $
+ * $Id: gamecon.c,v 1.10 2000/08/19 19:51:02 vojtech Exp $
*
* Copyright (c) 1999-2000 Vojtech Pavlik
*
* Based on the work of:
* Andree Borrmann John Dahlstrom
- * David Kuder
+ * David Kuder Nathan Hand
*
* Sponsored by SuSE
*/
@@ -75,8 +75,7 @@
static int gc_status_bit[] = { 0x40, 0x80, 0x20, 0x10, 0x08 };
static char *gc_names[] = { NULL, "SNES pad", "NES pad", "NES FourPort", "Multisystem
joystick",
- "Multisystem 2-button joystick", "N64 controller",
"PSX pad",
- "PSX NegCon", "PSX Analog contoller" };
+ "Multisystem 2-button joystick", "N64 controller",
+"PSX controller" };
/*
* N64 support.
*/
@@ -205,22 +204,30 @@
/*
* PSX support
- */
-
-#define GC_PSX_DELAY 10
-#define GC_PSX_LENGTH 8 /* talk to the controller in bytes */
+ *
+ * See documentation at:
+ * http://www.dim.com/~mackys/psxmemcard/ps-eng2.txt
+ * http://www.gamesx.com/controldata/psxcont/psxcont.htm
+ * ftp://milano.usal.es/pablo/
+ *
+ */
+
+#define GC_PSX_DELAY 60 /* 60 usec */
+#define GC_PSX_LENGTH 8 /* talk to the controller in bytes */
+
+#define GC_PSX_MOUSE 1 /* Mouse */
+#define GC_PSX_NEGCON 2 /* NegCon */
+#define GC_PSX_NORMAL 4 /* Digital / Analog or Rumble in Digital mode
+*/
+#define GC_PSX_ANALOG 5 /* Analog in Analog mode / Rumble in Green
+mode */
+#define GC_PSX_RUMBLE 7 /* Rumble in Red mode */
+
+#define GC_PSX_CLOCK 0x04/* Pin 4 */
+#define GC_PSX_COMMAND 0x01/* Pin 1 */
+#define GC_PSX_POWER 0xf8/* Pins 5-9 */
+#define GC_PSX_SELECT 0x02/* Pin 3 */
-#define GC_PSX_MOUSE 0x12/* PSX Mouse */
-#define GC_PSX_NE
Re: Linux's implementation of poll() not scalable?
Jim Gettys wrote: > So I want an interface in which I can get as many events as possible > at once, and one in which the events themselves can have appropriate > aggregation behavior. It isn't quite clear to me if the proposed interface > would have this property. I believe get_event, /dev/poll, and kqueue all share this property. e.g. none of them will present multiple POLLIN events per fd per call. Is that what you meant? - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
Hi Rik, I can't reproduce it on my box. Could you provide a "lvcreate -d" output of what you did to help me to dig into that one. Did somebody else out there face the same 0.8final snapshot weirdness? On Thu, Oct 26, 2000 at 04:36:37PM -0200, Rik van Riel wrote: > Hi Heinz, > > it looks like the LVM snapshotting in 2.4 doesn't allow you > to create snapshots from anything else than the _first_ LV > in the VG... > > I have run both the following command lines (after lvremoving > snap1, of course) and both of them give as a result that the > LV /dev/test_vg/swap ends up being the snapshotted filesystem ;( > > # lvcreate -s -L100 -nsnap1 /dev/test_vg/test > # lvcreate -s -L100 -nsnap1 /dev/test_vg/swap > > # cat /proc/lvm > LVM driver version 0.8final (15/02/2000) > > > > LVs: [AWDL ] swap122880 /30 1x open > [AWDL ] test204800 /50 1x open > [ARDL ] snap1 122880 /30 close > > It looks like somewhere in either the utilities or the > kernel, the argument of which LV to snapshot gets mangled... > Oh, I'm using version 0.8final of the LVM utities. > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ -- Regards, Heinz -- The LVM guy -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Bartningstr. 12 64289 Darmstadt Germany [EMAIL PROTECTED] +49 6151 7103 86 FAX 7103 96 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 11:24:38PM +0200, Yoann Vandoorselaere wrote: > Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > > On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote: > > > > > yop, I 've done : > > > > > > make -j10 World > > > in the xfree tree and simulateously : > > > > > > while true; do make dep && make clean && make bzImage; done > > > in the kernel tree > > > > Now it'd be nice to verify that the problem also happens when the system > > is not running out of memory (which -j10 quite causes I think) ... > > Nope, my system was loaded, but was usable > (at least until the problem occured)... Good to know. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote: > > > yop, I 've done : > > > > make -j10 World > > in the xfree tree and simulateously : > > > > while true; do make dep && make clean && make bzImage; done > > in the kernel tree > > Now it'd be nice to verify that the problem also happens when the system > is not running out of memory (which -j10 quite causes I think) ... Nope, my system was loaded, but was usable (at least until the problem occured)... Athlon 750 with 128mb of ram and 103mb of swap. -- -- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : "Actually, we do write our drivers without documentation." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 11:05:04PM +0200, Yoann Vandoorselaere wrote: > yop, I 've done : > > make -j10 World > in the xfree tree and simulateously : > > while true; do make dep && make clean && make bzImage; done > in the kernel tree Now it'd be nice to verify that the problem also happens when the system is not running out of memory (which -j10 quite causes I think) ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote: > > > > > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > > > > > to the timer. It writes 0 to the control-word for timer 0. This > > > > > > does the following: > > > > [Snipped...] > > > > > > > > > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > > > > > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > > > > > include/linux/ide.h. > > > > > > > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > > > they're not probably the cause of the problem we see here. > > > > > > > > Okay, good. > > > > > > Ok, here is a list of places within the kernel that access the PIT > > > timer, plus the method of locking (i386 arch only): > > > > [...] > > > > Ok, I just tested if the problem was always present without > > the IDE subsystem... > > > > The answer is it is not... so it isn't an IDE problem. > > Uh, guess too many negations. You wanted to say that the problem was > present even when you disabled the IDE subsystem, right? yop > > So now it seems that possibly enough PCI traffic / busmastering traffic > can cause the problem ... yop, I 've done : make -j10 World in the xfree tree and simulateously : while true; do make dep && make clean && make bzImage; done in the kernel tree -- -- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : "Actually, we do write our drivers without documentation." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel.org back up (film at 11)
kernel.org is back up. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: AMD CPU misdetection?
> cpu family : 5 > model : 8 > model name : AMD-K6(tm) 3D processor > ^^ > > Shouldn't it be K6-2? We report what AMD report - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Quota mods needed for journaled quota
Hi, On Thu, Oct 26, 2000 at 12:53:00PM -0400, Nathan Scott wrote: > > The addition of an "init_quota" method to the super_operations struct, > > with quota_on calling this and defaulting to installing the default > > quota_ops if the method is NULL, ought to be sufficient to let ext3 > > get quotas right in all cases as far as I can see. > > It might also/alternatively be generally useful to allow a > filesystem-specific implementation of quotactl itself - through > an additional member in the dquot_operations set of functions? I'm not sure how useful that addition would be --- for quota_on and quota_off, at least, the setting up of the dquot structures around the superblock or their destruction after quota_off can probably stay as common code, with calls into the filesystem for init_quota (and perhaps destroy_quota?) at the appropriate places. > This would allow ext3 to do that which it needs to do differently > at Q_QUOTAON and would also allow Jan's changes to work in such > a way that both the current form of dquot structure and his new > version of dquots could be used together Adding the init_quota hook would do that, as the filesystem will be able to install its own dq_ops methods during the init so we get the flexibility you are asking for anyway. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: killing read_ahead[]
On Wed, 25 Oct 2000, Alexander Viro wrote:
>
> Linus, what do you think about that? I can do the remaining filesystems
> and give it initial testing today.
Ok, looks reasonable, if not really pretty. I'd probably prefer
last_page = size >> PAGE_CACHE_SIZE;
last_page_size = size & (PAGE_CACHE_SIZE-1);
and then the three cases would be
if (index < last_page) {
full page case - ok.
}
if (index > last_page || !last_page_size) {
bad case, past the end
}
partial_page.
I see why you did it the way you did, but while it makes it really cheap
to test for "index past the end", it makes for less obvious calculations
in other places, I feel.
The alternative is to have an entirely different approach, where the page
cache itself only knows about the maximum page (in which case your current
"last_page" calculation is right on), and then anybody who needs to know
about partial pages needs to get THAT information from the inode.
I'd almost prefer the alternative approach. Especially as right now the
only real problem we're fighting is to make sure we never return an
invalid page - the sub-page offset really doesn't matter for those things,
and everybody who cares about the sub-page-information already obviously
has it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: LVM snapshotting broken?
On Thu, 26 Oct 2000, Rik van Riel wrote: > it looks like the LVM snapshotting in 2.4 doesn't allow you > to create snapshots from anything else than the _first_ LV > in the VG... OK, I reproduced it in 2.2 as well ... ;( > I have run both the following command lines (after lvremoving > snap1, of course) and both of them give as a result that the > LV /dev/test_vg/swap ends up being the snapshotted filesystem ;( > > # lvcreate -s -L100 -nsnap1 /dev/test_vg/test > # lvcreate -s -L100 -nsnap1 /dev/test_vg/swap > > # cat /proc/lvm > LVM driver version 0.8final (15/02/2000) > > > > LVs: [AWDL ] swap122880 /30 1x open > [AWDL ] test204800 /50 1x open > [ARDL ] snap1 122880 /30 close > > It looks like somewhere in either the utilities or the > kernel, the argument of which LV to snapshot gets mangled... > Oh, I'm using version 0.8final of the LVM utities. > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 10:11:54PM +0200, Yoann Vandoorselaere wrote: > > > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > > > > to the timer. It writes 0 to the control-word for timer 0. This > > > > > does the following: > > > [Snipped...] > > > > > > > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > > > > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > > > > include/linux/ide.h. > > > > > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > > they're not probably the cause of the problem we see here. > > > > > > Okay, good. > > > > Ok, here is a list of places within the kernel that access the PIT > > timer, plus the method of locking (i386 arch only): > > [...] > > Ok, I just tested if the problem was always present without > the IDE subsystem... > > The answer is it is not... so it isn't an IDE problem. Uh, guess too many negations. You wanted to say that the problem was present even when you disabled the IDE subsystem, right? So now it seems that possibly enough PCI traffic / busmastering traffic can cause the problem ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote: > > > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > > > to the timer. It writes 0 to the control-word for timer 0. This > > > > does the following: > > [Snipped...] > > > > > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > > > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > > > include/linux/ide.h. > > > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > > they're not probably the cause of the problem we see here. > > > > Okay, good. > > Ok, here is a list of places within the kernel that access the PIT > timer, plus the method of locking (i386 arch only): [...] Ok, I just tested if the problem was always present without the IDE subsystem... The answer is it is not... so it isn't an IDE problem. -- -- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : "Actually, we do write our drivers without documentation." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux's implementation of poll() not scalable?
Note that there is another aspect to the efficiency / performance of the select/poll style of interfaces not immediately obvious, but which occurs as a result of how some (streaming/batching) protocols work. An X server does not call select all that often (probably one of the two items most frequently used that care; though I believe getting the Apache case right is more important). X is such a streaming protocol: it is a feature that I don't have to do extra reads or system calls to deal with more data arriving from a client. An X server doesn't want one event generated for each incoming TCP segment: it merely needs to know there is data available on a file descriptor as a binary condition. I really don't want to have to do one operation per segment; this is less efficient than the current situation. Similarly, it is a feature that with one call I can find out that there is work to do on multiple file descriptors. In short, the X server does a select, and then loops across all the file descriptors with work to do before doing another select: the system call overhead gets amortized across multiple clients and buffers received from the client. As the server gets busier, it is more and more likely that there is more than one client with work to do, and/or multiple TCP segments have arrived to process (in the common single client is busy case). So we make the system call less and less often as a fraction of work done. This has the happy consequence that the select caused overhead DROPS as a fraction of total work as the X server gets busier, and X is most efficient at the point in time you care the most: when you have the most work to do. The system call is returning more information each time it is called, and some of that information is aggregated as well (additional data arriving). It doesn't practically matter how efficient the X server is when you aren't busy, after all. This aggregation property is therefore important, and there needs to be some way to achieve this, IMHO. Web servers often have similar behavior, though since most current HTTP clients don't implement streaming behavior, the benefit is currently much lower (would that HTTP clients start driving HTTP servers the way the HTTP/1.1 protocol allows... Sigh...). Right now, scaling to large numbers of descriptors is most urgent for big web servers. So I want an interface in which I can get as many events as possible at once, and one in which the events themselves can have appropriate aggregation behavior. It isn't quite clear to me if the proposed interface would have this property. As I said in early talks about X: "X is an exercise in avoiding system calls" - Jim Gettys -- Jim Gettys Technology and Corporate Development Compaq Computer Corporation [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
On Thu, Oct 26, 2000 at 06:21:29PM +0200, octave klaba wrote: > > > > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > let me guess: intel eepro100 or similar?? > yeap > > 00:02.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) > Subsystem: Asustek Computer, Inc.: Unknown device 1043 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- >Stepping- SERR- FastB2B- > Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 8 min, 56 max, 64 set, cache line size 08 > Interrupt: pin A routed to IRQ 20 > Region 0: Memory at fd00 (32-bit, non-prefetchable) > Region 1: I/O ports at d800 > Region 2: Memory at fc80 (32-bit, non-prefetchable) > Capabilities: > > > Well known problem with that one. dont know if its fully fixed ... With > > 2.4.0-test9-pre3 it doesnt happen on my machine ... > we have 1-2 servers running 2.4.0-test9 and we got this error ... I get similar eth0 hangs using a 3c59x. Though outside of rebooting I have no clue how to get networking going again. --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball <[EMAIL PROTECTED]> Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.2.x Fixes for stackable filesystems
Linus, Alan,
I am proposing this patch for inclusion in the 2.2.x tree. (Whether it goes
into 2.2.18 or 2.2.19 is your call.) We have run this successfully with
2.2.14 through 2.2.17.
Our kernel patches help stacking file systems work properly in two
areas:
* dentry reference count fixes when files are opened by init_private_file()
* file reference count fixes for stacking filesystems mmap().
1. In some cases, stacking file systems which do no data translation may
want to substitute another dentry/inode at the time of a file open. If
they do that, the dentry reference counts will get mishandled by some
callers of init_private_file(). Our changes make init_private_file()
take a dentry reference itself, and free it only if an error occurs on
the file open. This leaves the file open routine free to swap the
dentry with another one. All callers of the file system open routine
must dget() the dentry before putting it into the file structure prior
to calling the open routine. Callers of init_private_file() must dput()
the file's dentry when they are done with the file.
2. In the mmap case, stacking file systems which do no data translation
probably want to substitute the underlying file system's file pointer,
so that paging operations are handled directly by the underlying file
system. The call into the file system's mmap() must be allowed to set
the VM area's file pointer, so that it can effect this swap. Our change
to the VM system is to set the VMA's file pointer only if the specific
mmap() routine did not set it.
Thanks,
Will Taber
+-+
| Will Taber |
| Software Engineer, CMBU E-mail [EMAIL PROTECTED] |
| Rational Software Corporation Phone: 781-676-2436|
| 20 Maguire Road, Lexington, Mass. 02421 |
+-+
diff -Naur linux.clean.2.2.14/fs/exec.c linux/fs/exec.c
--- linux.clean.2.2.14/fs/exec.cTue Oct 26 20:53:42 1999
+++ linux/fs/exec.c Wed Sep 13 09:51:09 2000
@@ -136,7 +136,7 @@
goto out_fd;
f->f_flags = mode;
f->f_mode = (mode+1) & O_ACCMODE;
- f->f_dentry = dentry;
+ f->f_dentry = dget(dentry);
f->f_pos = 0;
f->f_reada = 0;
f->f_op = inode->i_op->default_file_ops;
@@ -146,11 +146,11 @@
goto out_filp;
}
fd_install(fd, f);
- dget(dentry);
}
return fd;
out_filp:
+dput(dentry);
if (error > 0)
error = -EIO;
put_filp(f);
@@ -371,6 +371,7 @@
close_readexec:
if (file.f_op->release)
file.f_op->release(inode,&file);
+dput(file.f_dentry);
end_readexec:
return result;
}
diff -Naur linux.clean.2.2.14/fs/file_table.c linux/fs/file_table.c
--- linux.clean.2.2.14/fs/file_table.c Tue Jan 4 13:12:23 2000
+++ linux/fs/file_table.c Wed Sep 13 09:51:09 2000
@@ -117,16 +117,20 @@
*/
int init_private_file(struct file *filp, struct dentry *dentry, int mode)
{
+ int err;
memset(filp, 0, sizeof(*filp));
filp->f_mode = mode;
filp->f_count = 1;
- filp->f_dentry = dentry;
+ filp->f_dentry = dget(dentry);
filp->f_uid= current->fsuid;
filp->f_gid= current->fsgid;
filp->f_op = dentry->d_inode->i_op->default_file_ops;
- if (filp->f_op->open)
- return filp->f_op->open(dentry->d_inode, filp);
- else
+ if (filp->f_op->open) {
+ err = filp->f_op->open(dentry->d_inode, filp);
+if (err)
+dput(dentry);
+ return err;
+} else
return 0;
}
diff -Naur linux.clean.2.2.14/fs/nfsd/nfsfh.c linux/fs/nfsd/nfsfh.c
--- linux.clean.2.2.14/fs/nfsd/nfsfh.c Tue Sep 12 17:08:27 2000
+++ linux/fs/nfsd/nfsfh.c Wed Sep 13 09:51:09 2000
@@ -396,6 +396,7 @@
out_close:
if (file.f_op->release)
file.f_op->release(dir, &file);
+dput(file.f_dentry);
out:
return error;
}
diff -Naur linux.clean.2.2.14/mm/mmap.c linux/mm/mmap.c
--- linux.clean.2.2.14/mm/mmap.cTue Jan 4 13:12:26 2000
+++ linux/mm/mmap.c Wed Sep 13 09:51:09 2000
@@ -321,8 +321,14 @@
file->f_dentry->d_inode->i_writecount++;
if (error)
goto unmap_and_free_vma;
- vma->vm_file = file;
- file->f_count++;
+if (vma->vm_file == NULL) {
+/*
+ * underlying FS may have attached it differently--only
+ * attach it if they didn't.
+ */
+vma->vm_file = file;
+
Re: Oops while running test10-pre5
[EMAIL PROTECTED] wrote: > > On Thu, 26 Oct 2000, Robert Lynch wrote: > > > Oct 19 13:00:23 ives kernel: EIP:0010:[try_to_swap_out+252/796] > > Those Oopsen look like they're from test10-pre4 (fixed in pre5). Also, > please include the lines beginning with "kernel BUG at...". > > -ben OOPS! That's entirely correct, I previously reported this older oops also. When reporting the newer one, I inadvertantly copied the wrong oops file. BOTH of the oops I mentioned are reported below my .sig. Sorry, Bob L. -- Robert Lynch-Berkeley CA [EMAIL PROTECTED] -- test10-pre4 oops (OLD; for the record, sent as requested) --- Oct 19 13:00:23 ives kernel: kernel BUG at vmscan.c:102! Oct 19 13:00:23 ives kernel: invalid operand: Oct 19 13:00:23 ives kernel: CPU:0 Oct 19 13:00:23 ives kernel: EIP: 0010:[try_to_swap_out+252/796] Oct 19 13:00:23 ives kernel: EFLAGS: 00010286 Oct 19 13:00:23 ives kernel: eax: 001c ebx: 0200 ecx: edx: Oct 19 13:00:23 ives kernel: esi: c11c8590 edi: 0001 ebp: 06b60045 esp: c1273ebc Oct 19 13:00:23 ives kernel: ds: 0018 es: 0018 ss: 0018 Oct 19 13:00:23 ives kernel: Process kswapd (pid: 3, stackpage=c1273000) Oct 19 13:00:23 ives kernel: Stack: c01d07ea c01d09a9 0066 40279000 c7e3dda0 4027a000 40278000 c01836e7 Oct 19 13:00:23 ives kernel:c012968e c7e3dda0 c6b9bd60 40278000 c6cad9e0 0004 40278000 c6b9bd60 Oct 19 13:00:23 ives kernel:c7e3dda0 0004 c6cad9e0 40678000 c6ca3400 4027a000 4027a000 c6ca3400 Oct 19 13:00:23 ives kernel: Call Trace: [tvecs+6622/60500] [tvecs+7069/60500] [ide_end_request+111/120] [swap_out_vma+322/440] [swap_out_mm+56/100] [swap_out+283/368] [refill_inactive+213/376] Oct 19 13:00:23 ives kernel:[do_try_to_free_pages+98/128] [tvecs+7429/60500] [kswapd+139/348] [empty_bad_page+0/4096] [kernel_thread+35/48] Oct 19 13:00:23 ives kernel: Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 a9 09 1d c0 Oct 19 13:00:35 ives kernel: kernel BUG at vmscan.c:102! Oct 19 13:00:35 ives kernel: invalid operand: Oct 19 13:00:35 ives kernel: CPU:0 Oct 19 13:00:35 ives kernel: EIP: 0010:[try_to_swap_out+252/796] Oct 19 13:00:35 ives kernel: EFLAGS: 00013282 Oct 19 13:00:35 ives kernel: eax: 001c ebx: 0500 ecx: c6c813c0 edx: 0001 Oct 19 13:00:35 ives kernel: esi: c118bc90 edi: 0001 ebp: 05d20045 esp: c6afbc20 Oct 19 13:00:35 ives kernel: ds: 0018 es: 0018 ss: 0018 Oct 19 13:00:35 ives kernel: Process squid (pid: 829, stackpage=c6afb000) Oct 19 13:00:35 ives kernel: Stack: c01d07ea c01d09a9 0066 40199000 c6c81be0 4019d000 40197000 Oct 19 13:00:35 ives kernel:c012968e c6c81be0 c521cb60 40198000 c4a13660 0003 40197000 c521cb60 Oct 19 13:00:35 ives kernel:c6c81be0 0003 c4a13660 40597000 c4977400 4019d000 4019d000 c4977400 Oct 19 13:00:35 ives kernel: Call Trace: [tvecs+6622/60500] [tvecs+7069/60500] [swap_out_vma+322/440] [swap_out_mm+56/100] [swap_out+283/368] [refill_inactive+213/376] [do_try_to_free_pages+98/128] Oct 19 13:00:35 ives kernel:[try_to_free_pages+34/44] [__alloc_pages+566/712] [grow_buffers+59/284] [refill_freelist+10/44] [getblk+274/292] [ext2_getblk+92/192] [__wait_on_buffer+178/192] [ext2_find_entry+176/960] Oct 19 13:00:35 ives kernel:[iget4+198/212] [ext2_lookup+48/136] [real_lookup+79/192] [path_walk+1459/2060] [open_namei+147/1484] [filp_open+59/92] [sys_open+56/180] [system_call+51/56] Oct 19 13:00:35 ives kernel:[stext+43/314] Oct 19 13:00:35 ives kernel: Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 a9 09 1d c0 -- ksymoops 2.3.4 on i686 2.4.0-test10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test10/ (specified) -m /usr/src/linux/System.map (default) Error (regular_file): read_system_map stat /usr/src/linux/System.map failed Oct 19 13:00:23 ives kernel: invalid operand: Oct 19 13:00:23 ives kernel: CPU:0 Oct 19 13:00:23 ives kernel: EIP: 0010:[try_to_swap_out+252/796] Oct 19 13:00:23 ives kernel: EFLAGS: 00010286 Oct 19 13:00:23 ives kernel: eax: 001c ebx: 0200 ecx: edx: Oct 19 13:00:23 ives kernel: esi: c11c8590 edi: 0001 ebp: 06b60045 esp: c1273ebc Oct 19 13:00:23 ives kernel: ds: 0018 es: 0018 ss: 0018 Oct 19 13:00:23 ives kernel: Process kswapd (pid: 3, stackpage=c1273000) Oct 19 13:00:23 ives kernel: Stack: c01d07ea c01d09a9 0066 40279000 c7e3dda0 4027a000 40278000 c01836e7 Oct 19 13:00:23 ives kernel:c012968e c7e3dda0 c6b9bd60 40278000 c6cad9e0 0004 40278000 c6b9bd60 Oct 19 13:00:23 ives kernel:c7e3dda0 0004 c6cad9e0 40678000 c6ca3400 4027a000 4027a000 c6ca3400 Oct 19 13:00:23 ives kernel: Call Trace: [tvecs+6622/60500] [tvecs+7069/60500] [ide_end_request+111/120] [swap_out_vma+322/440] [swap_out_mm+56/100] [swap_out+283/368] [refill_inactive+2
LVM snapshotting broken?
Hi Heinz, it looks like the LVM snapshotting in 2.4 doesn't allow you to create snapshots from anything else than the _first_ LV in the VG... I have run both the following command lines (after lvremoving snap1, of course) and both of them give as a result that the LV /dev/test_vg/swap ends up being the snapshotted filesystem ;( # lvcreate -s -L100 -nsnap1 /dev/test_vg/test # lvcreate -s -L100 -nsnap1 /dev/test_vg/swap # cat /proc/lvm LVM driver version 0.8final (15/02/2000) LVs: [AWDL ] swap122880 /30 1x open [AWDL ] test204800 /50 1x open [ARDL ] snap1 122880 /30 close It looks like somewhere in either the utilities or the kernel, the argument of which LV to snapshot gets mangled... Oh, I'm using version 0.8final of the LVM utities. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Topic for discussion: OS Design
Andi Kleen <[EMAIL PROTECTED]>: > On Thu, Oct 26, 2000 at 11:00:03AM -0500, Jesse Pollard wrote: > > Keith Owens <[EMAIL PROTECTED]>: > > > > > > On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), > > > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: > > [snip] > > > >This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 > > > >pages. Since there are 5 modules, we waste about 1/3 page per module. > > > > > > > >So I don't, as you say; "... waste 1/2 page or more per module". > > > > > > Statistics say that the average loss will be 1/2 page per module. Some > > > will waste more, some will waste less, average is 1/2 the unit. > > > > Only if the size of a random module can be between 0 and a full page > > > > Module sizes are skewed data... there is a minimum size for a module > > (somewhere around 1k, I believe - didn't measure it), and if the module > > is going to DO anything then it will be between 1-2K. This skews the data > > sample such that you are only loosing 1/2 of (1 page - minimum) or 1/2 of > > 3K = 1.5K. Hence the 1/3 measured loss will be closer to the correct > > theoretical loss than 1/2. > > You're forgetting that longer modules wrap at the end to a full page, which > makes all values possible again. You appear to be right I thought of them as anomalies, but there are more of them than I believed. I was also thinking of the total number of pages for the modules rather than the total number of modules. The following is from my server (SCSI based, but does have IDE disks too): module size pages loss - -- vfat9116 0 (unused) 2.22559 0.774414 smbfs 26232 0 (unused) 6.4043 0.595703 msdos 5180 0 (unused) 1.26465 0.735352 isofs 17432 0 (unused) 4.25586 0.744141 fat30240 0 [vfat msdos] 7.38281 0.617188 3c509 6004 1 1.46582 0.53418 ide-probe 6244 0 1.52441 0.475586 ide-disk5800 0 1.41602 0.583984 ide-cd 23028 0 5.62207 0.37793 ide-mod44536 0 [ide-probe ide-disk ide-cd] 10.873 0.126953 sb 33876 0 8.27051 0.729492 uart401 5968 0 [sb] 1.45703 0.542969 sound 57336 0 [sb uart401]13.9980.00195312 soundlow 224 0 [sound] 0.05468750.945312 soundcore 2308 5 [sb sound] 0.563477 0.436523 serial 19284 0 (unused) 4.70801 0.291992 lp 5180 0 1.26465 0.735352 parport_pc 5652 1 1.37988 0.620117 parport 7208 1 [lp parport_pc] 1.75977 0.240234 averages: 3.99423 0.532072 So the average size of a module is 3.9 pages and the average size of lost space in a page IS close to .5 (actually a little greater). If the two anomilies (ide-mod and sound) are dropped then the average size of lost space is 0.525288, even close to .5. The only remaining anomily is the soundlow module (size 224). If this one is dropped too then the average size of lost page space is 0.475535. Looking at this, the overall wasted space is a whopping 10.1 pages or 40K. Not bad at all. BTW, all values taken from a Linux 2.2.13.SMP system. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
This is a long posting, with a humble beginning, but it has a point. I'm being complete so that no one is left in the dark, or in any doubt as to what that point is. That means rehashing some history. This posting is not really about select or Linux: it's about interfaces. Like cached state, interfaces can often be harmful. NB: I really should redirect this to FreeBSD, as well, since there are people in that camp who haven't learned the lesson, either, but I'll leave it in -chat, for now. --- [ ... kqueue discussion ... ] > Linux also thought it was OK to modify the contents of the > timeval structure before returning it. It's been pointed out that I should provide more context for this statement, before people look at me strangely and make circling motions with their index fingers around their ears (or whatever the international sign for "crazy" is these days). So I'll start with a brief history. The context is this: the select API was designed with the idea that one might wish to do non-I/O related background processing. Toward this end, one could have several ways of using the API: 1) The (struct timeval *) could be NULL. This means "block until a signal or until a condition on which you are selecting is true"; select is a BSD interface, and, until BSD 4.x and POSIX signals, the signal would actually call the handler and restart the select call, so in effect, this really meant "block until you longjmp out of a signal handler or until a condition on which you are selecting is true". 2) The (struct timeval *) could point to the address of a real timeval structure (i.e. not be NULL); in that case, the result depended on the contents: a) If the timeval struct was zero valued, it meant that the select should poll for one of the conditions being selected for in the descriptor set, and return a 0 if no conditions were true. The contents of the bitmaps and timeval struct were left alone. b) If the timeval struct was not zero valued, it meant that the select should wait until the time specified had expired since the system call was first started, or one of the conditions being selected for was true. If the timeout expired, then a 0 would be returned, but if one or more of the conditions were true, the number of descriptors on which true conditions existed would be returned. Wedging so much into a single interface was fraught with peril: it was undefined as to what would happen if the timeval specified an interval of 5 seconds, yet there was a persistently rescheduled alarm every 2 seconds, resulting in a signal handler call that did _not_ longjmp... would the timer expire after 5 seconds, or would the timer be considered to have been restarted along with the call? Implementations that went both ways existed. Mostly, programmers used longjmp in signal handlers, and it wasn't a portability issue. More perilous, the question of what to do with a partially satisfied request that was interrupted with a timer or signal handler and longjump (later, siginterrupt(2), and later POSIX non-restart default behaviour). This meant that the bitmap of select events might have been modified already, after the wakeup, but before the process was rescheduled to run. Finally, the select manual page specifically reserved the right to modify the contents of the timeval struct; this was presumably so that you could either do accurate timekeeping by maintaining a running tally using the timeval deficit (a lot of math, that), or, more likely, to deal with the system call restart, and ensure that signals would not prevent the select from ever exiting in the case of system call restart. So this was the select API definition. --- Being pragmatists, programmers programmed to the behaviour of the API in actual implementations, rather than to the strict "letter of the law" laid down by the man page. This meant that select was called in loop control constructs, and that the bitmaps were reinitialized each time through the loop. It also meant that the timeval struct was not reinitialized, since that was more work, and no known implementations would modify it. Pre-POSIX signals, signal handlers were handled on a signal stack, as a result of a kernel trampoline outcall, and that meant that a restarting system call would not impact the countdown. --- Linux came along, and implemented the letter of the law; the machines were no sufficiently fast, and the math sufficiently cheap, that it was now possible to usefully accurate timekeeping using the inverted math required of keeping a running tally using the timeval deficit. So they implemented it: it was more useful than the historical b
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 01:42:29PM -0400, Richard B. Johnson wrote: > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > > to the timer. It writes 0 to the control-word for timer 0. This > > > does the following: > [Snipped...] > > > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > > include/linux/ide.h. > > > > So this is not our problem here. Anyway I guess it's time to hunt for > > i8259 accesses in the kernel that lack the necessary spinlock, even when > > they're not probably the cause of the problem we see here. > > Okay, good. Ok, here is a list of places within the kernel that access the PIT timer, plus the method of locking (i386 arch only): Usage: Lock method: arch/i386/kernel/time.c:170:spin_lock() arch/i386/kernel/time.c:491:spin_lock() arch/i386/kernel/time.c:575:none (init) arch/i386/kernel/i8259.c:491: none (init) arch/i386/kernel/apm.c:871: cli() arch/i386/kernel/apic.c:398:spin_lock_irqsave() drivers/char/vt.c:121: cli() drivers/char/ftape/lowlevel/ftape-calibr.c:80: cli() drivers/char/ftape/lowlevel/ftape-calibr.c:99: cli() drivers/char/joystick/analog.c:142: cli() __cli() drivers/char/joystick/gameport.c:66:cli() drivers/ide/hd.c:137: cli() drivers/ide/ide.c:206: __cli() I guess we'll need to fix this. While races here are not likely (the most likely is a beep by vt.c at a wrong moment), they're possible. However, these don't seem to be the cause of the problem we see here anyway. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Oops while running test10-pre5
On Thu, 26 Oct 2000, Robert Lynch wrote: > Oct 19 13:00:23 ives kernel: EIP:0010:[try_to_swap_out+252/796] Those Oopsen look like they're from test10-pre4 (fixed in pre5). Also, please include the lines beginning with "kernel BUG at...". -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, 26 Oct 2000, Vojtech Pavlik wrote: > On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote: > > > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > > to the timer. It writes 0 to the control-word for timer 0. This > > does the following: [Snipped...] > > Well, at least on 2.4.0-test9, the above timing code is #ifed to > DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in > include/linux/ide.h. > > So this is not our problem here. Anyway I guess it's time to hunt for > i8259 accesses in the kernel that lack the necessary spinlock, even when > they're not probably the cause of the problem we see here. Okay, good. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
linux 2.2.18pre17 + VM-global -7 = `Negative d_count' oops
Andrea Arcangeli writes ("Re: linux 2.2.18-pre17: "Kernel panic: LRU list corrupted""):
> I also included the fix in a new VM-global patch against vanilla 2.2.18pre17
> (the VM-global patch is available as a single patch inside 2.2.18pre17aa1/
> directory too but I have to maintain a separate version of it against clean
> 2.2.18pre17 due silly rejects that I can't avoid)
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre17/VM-global-2.2.18pre17-7.bz2
I've been having apparently VM-related `pauses' with 2.2.17 [1], so I
thought I'd try 2.2.18pre17 with that patch. The results weren't
good: I get many instances of
Negative d_count (-805538369) for [binary garbage]/
followed by an oops. Kernel logfile extract below, uuencoded.
I'm sure I'd be able to reproduce this, but I'd rather not because
this is a production system. ver_linux reports:
chiark:linux-2.2.17-chiark> sh scripts/ver_linux
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux chiark 2.2.17 #2 Thu Oct 26 10:57:45 BST 2000 i586 unknown
Kernel modules 2.3.11
Gnu C 2.95.2
Binutils 2.9.5.0.37
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount 2.10f
Net-tools 2.05
Kbd0.99
Sh-utils 2.0
cat: /proc/modules: No such file or directory
Modules Loaded
chiark:linux-2.2.17-chiark>
I don't know why it says `Kernel modules 2.3.11', since I have
disabled kernel modules completely. My CPU is:
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 0
cpu MHz : 350.808
cache size : 64 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mmx 3dnow
bogomips: 699.60
REPORTING-BUGS wanted me to include /proc/scsi/scsi, so here it is:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DCAS-34330 Rev: S65A
Type: Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: IBM Model: DCAS-34330 Rev: S65A
Type: Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: HP Model: T20 Rev: 3.01
Type: Sequential-AccessANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DNES-318350W Rev: SA30
Type: Direct-AccessANSI SCSI revision: 03
It might be relevant that a large part of the system's job is to be a
shell account server, and users log in with a variety of mechanisms,
most often OpenSSH (Debian 1.2.3-9). I've not had any reports from
users about sessions randomly dropping, which I might have expected;
however, I did have a number of background cron jobs die in very
strange ways suggesting killing of processes at random.
The system as a whole is largely Debian 2.2, and has 256Mb of RAM and
about 400Mb of swap. It usually runs with about 50-100Mb of swap used
and at a load of somewhere around 1ish during busy periods.
[1] VM lockup problem:
I believe that this is a known problem with the 2.2.x VM ? The
symptoms I have are that under reasonably high but not excessive VM
and/or disk load, the system will freeze for around 10-15 minutes.
Most often this seems to have beeen provoked by a moderately large
(20Mb or so) Emacs doing an auto-save during an otherwise-busy time.
During the lockup network packets are processed - pings receive
replies, and TCP connection attempts succeed, but there is no evidence
of any user-mode executing. After the lockup the system apparently
just resumes where it left off. Sometimes afterwards there is a
message like `VM: do_try_to_free_pages failed for emacs...' but more
often there isn't.
Thanks for your attention,
Ian.
begin 664 chiark-oops
M3V-T(#(U(#$U.C`U.C`U(&-H:6%R:R!K97)N96PZ($%D9&EN9R!3=V%P.B`T
M,#DU.3)K('-W87`M5#E$)%Y0=5Y#,<##N./#7#(Q,?9<
M,C$S1"1>1%PR,#/`7E0Y1"1>4'5>1[C[PUPR,C"XX\-<,C$Q]KA=
M7D$O/$Y53$P^"D]C="`R-2`Q-SHS-CHS,R!C:&EA#H@,#`P,#`P-C0@("!E8G@Z(&-F9F,W,#(P("`@
M96-X.B!C86-C8S`P,"`@(&5D>#H@,#`P,#`P,68*3V-T(#(U(#$W.C,V.C,S
M(&-H:6%R:R!K97)N96PZ(&5S:3H@8V9F8S'!R("AP:60Z(#$X-S`V+"!P5]R96%D*S`O
M,C1=(%M?7V9P=70K-C(O-S)=(%MF<'5T*S(S+S5]H86YD;&5R
M*S5#E$)%Y0=5Y#,<##N./#7#(Q,?9<,C$S1"1>
M1%PR,#/`7E0Y1"1>4'5>1[C[PUPR,C"XX\-<,C$Q]KA=7D$O/$Y5
M3$P^"D]C="`R-2`Q.#HP-SHP-R!C:&EA#H@,#`P,#`P-C0@("!E8G@Z(&-F9F,W,#(P("`@96-X.B!C
M-61E93`P,"`@(&5D>#H@,#`P,#`P,38*3V-T(#(U(#$X.C`W.C`W(&-H:6%R
M:R!K97)N96PZ(&5S:3H@8V9F8S'!R("AP
M:60Z(#(S,C8P+"!P5]R96%D*S`O,C1=(%M?
M7V9P=70K-C(O-S)=(%MF<'5T*S(S
Re: 3-order allocation failed
On Thu, 26 Oct 2000, Rik van Riel wrote: > On Thu, 26 Oct 2000, Forever shall I be. wrote: > > On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi Kärkkäinen wrote: > > > > __alloc_pages: 2-order allocation failed. > > > __alloc_pages: 2-order allocation failed. > > > __alloc_pages: 5-order allocation failed. > > > __alloc_pages: 4-order allocation failed. > > > __alloc_pages: 3-order allocation failed. > > > __alloc_pages: 2-order allocation failed. > > > __alloc_pages: 5-order allocation failed. > > > > > > Any ideas? > > > > I'm getting __alloc_pages: 7-order allocation failed. > > all the time in 2.4.0-test9 on my "pIII (Katmai)".. kernel's > > compiled with 2.95.2 + bounds, without -fbounds-checking > > It means something in the system is trying to allocate a > large continuous area of memory that isn't available... > > The printk is basically a debug output indicating that we > don't have the large physically contiguous area available > that's being requested. > > Basically everything bigger than order-1 (2 contiguous > pages) is unreliable at runtime. Orders 2 and 3 should > usually be available (if you only allocate very few of > them) and higher orders should not be relied upon. > > If somebody is seeing a lot of these messages, it means > that some driver in the system is asking unreasonable > things from the VM subsystem ;) > > (and buffer allocations are failing) > I got those order-x messages when I was running a script, that looked something like this: streamer -s 320x240 -o webcam.jpg sleep 5 It worked fine for about 20 minutes, and after I started to get those messages and the camera didn't work anymore. Solution: I'm now using a program, that is "using the camera all the time" and it just saves the frames with 5 seconds delay. The script I was running previously used streamer, that initializes and opens the v4l-device everytime I run it. Is this bug in the usb-driver (usb-uhci), in the camera's driver (cpia_usb) or in the v4l? - Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3-order allocation failed
On Thu, 26 Oct 2000, Forever shall I be. wrote: > On Thu, Oct 26, 2000 at 02:57:30PM +0300, Pasi Kärkkäinen wrote: > > __alloc_pages: 2-order allocation failed. > > __alloc_pages: 2-order allocation failed. > > __alloc_pages: 5-order allocation failed. > > __alloc_pages: 4-order allocation failed. > > __alloc_pages: 3-order allocation failed. > > __alloc_pages: 2-order allocation failed. > > __alloc_pages: 5-order allocation failed. > > > > Any ideas? > > I'm getting __alloc_pages: 7-order allocation failed. > all the time in 2.4.0-test9 on my "pIII (Katmai)".. kernel's > compiled with 2.95.2 + bounds, without -fbounds-checking It means something in the system is trying to allocate a large continuous area of memory that isn't available... The printk is basically a debug output indicating that we don't have the large physically contiguous area available that's being requested. Basically everything bigger than order-1 (2 contiguous pages) is unreliable at runtime. Orders 2 and 3 should usually be available (if you only allocate very few of them) and higher orders should not be relied upon. If somebody is seeing a lot of these messages, it means that some driver in the system is asking unreasonable things from the VM subsystem ;) (and buffer allocations are failing) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOPS on boot
Mircea Damian wrote: > > On Thu, Oct 26, 2000 at 10:20:45AM -0400, Brian Gerst wrote: > > Mircea Damian wrote: > > > > > > Hello, > > > > > > I'm unable to boot kernel 2.4.0-test10-pre5 on a: > > > > Upgrade GCC to 2.91.66 (aka egcs-1.1.2) > > Ok. I can do that, but there is nowhere written that I should do > that. If I remember right gcc-2.7.2.3 was the preferred compiler for all > kernels. The change that broke compiling with 2.7.2.3 was in test10-pre4. There is a patch that should be going in to test10-pre6 that documents this and checks the version. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
LT, I can do it from user-space completely, but not today. The tools are missing. Also I have/will get my traces on my code in a day or so. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 12:04:21PM -0400, Richard B. Johnson wrote: > ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things > to the timer. It writes 0 to the control-word for timer 0. This > does the following: > > o Selects timer 0. > o Latches the timer. > o Selects mode 0. > o Programs it to a 16 bit counter. > > The result is a latched (stopped) counter. Bits 5 and 4 should have been > selected. Then you read bits 0-7 from 0x40, followed by bits 8-15 from > the same port. > > Also, there is no spin-lock protecting access to these ports. If anybody > else is mucking with the timer, all bets are off. Well, at least on 2.4.0-test9, the above timing code is #ifed to DISK_RECOVERY_TIME > 0, which in turn is #defined to 0 in include/linux/ide.h. So this is not our problem here. Anyway I guess it's time to hunt for i8259 accesses in the kernel that lack the necessary spinlock, even when they're not probably the cause of the problem we see here. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kqueue microbenchmark results
On Thu, Oct 26, 2000 at 02:16:28AM -0700, Gideon Glass wrote: > Jonathan Lemon wrote: > > > > Also, consider the following scenario for the proposed get_event(): > > > >1. packet arrives, queues an event. > >2. user retrieves event. > >3. second packet arrives, queues event again. > >4. user reads() all data. > > > > Now, next time around the loop, we get a notification for an event > > when there is no data to read. The application now must be prepared > > to handle this case (meaning no blocking read() calls can be used). > > > > Also, what happens if the user closes the socket after step 4 above? > > Depends on the implementation. If the item in the queue is the > struct file (or whatever an fd indexes to), then the implementation > can only queue the fd once. This also avoids the problem with > closing sockets - close() would naturally do a list_del() or whatever > on the struct file. > > At least I think it could be implemented this way... kqueue currently does this; a close() on an fd will remove any pending events from the queues that they are on which correspond to that fd. I was trying to point out that it isn't as simple as it would seem at first glance, as you have to consider an issues like this. Also, if the implementation allows multiple event types per fd, (leading to multiple queued events per fd) there no longer is a 1:1 mapping to something like 'struct file', and performing a list walk doesn't scale very well. -- Jonathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux's implementation of poll() not scalable?
On Thu, 26 Oct 2000, Dan Kegel wrote: > > With level-triggered interfaces like poll(), your chances > of writing a correctly functioning program are higher because you > can throw events away (on purpose or accidentally) with no consequences; > the next time around the loop, poll() will happily tell you the current > state of all the fd's. Agreed. However, we also need to remember what got us to this discussion in the first place. One of the reasons why poll() is such a piggy interface is exactly because it tries to be "nice" to the programmer. I'd much rather have an event interface that is documented to be edge- triggered and is really _lightweight_, than have another interface that starts out with some piggy features. I do understand that level to some degree is "nicer", but everybody pretty much agrees that apart from requireing more care, edge-triggered certainly does everything the level-triggered interfaces do. For example, if you want to only partially handle an event (one of the more valid arguments I've seen, although I do not agree with it actually being all that common or important thing to do), the edge-triggered interface _does_ allow for that. It's fairly easy, in fact: you just re-bind the thing. (My suggested "bind()" interface would be to just always add a newly bound fd to the event queue, but I would not object to a "one-time test for active" kind of "bind()" interface either - which would basically allow for a poll() interface - and the existing Linux internal "poll()" implementation actually already allows for exactly this so it wouldn't even add any complexity). > With edge-triggered interfaces, the programmer must be much more careful > to avoid ever dropping a single event; if he does, he's screwed. > This gives rise to complicated code in apps to remember the current > state of fd's in those cases where the programmer has to drop events. No, the "re-bind()" approach works very simply, and means that the overhead of testing whether the event is still active is not a generic thing that _always_ has to be done, but something where the application can basically give the kernel the information that "this time we're leaving the event possibly half-done, please re-test now". Advantage: performance again. The common case doesn't take the performance hit. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
eepro100: card reports no resources [was VM-global...]
Markus Pfeiffer <[EMAIL PROTECTED]> wrote: > > > Oct 26 11:24:13 ns29 kernel: eth0: card reports no resources. > > Oct 26 11:24:15 ns29 kernel: eth0: card reports no resources. > > Oct 26 12:22:21 ns29 kernel: eth0: card reports no resources. > > Oct 26 16:16:59 ns29 kernel: eth0: card reports no resources. > > Oct 26 16:28:37 ns29 kernel: eth0: card reports no resources. > > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > > > let me guess: intel eepro100 or similar?? > Well known problem with that one. dont know if its fully fixed ... With Happens here too, with 2xPPro200, 2.2.18pre17, Eepro100 and light load. The network stalls for several minutes when it happens. > 2.4.0-test9-pre3 it doesnt happen on my machine ... What about a fix for a 2.2.x...? -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test10-5: af_irda.o compile error
Hello, I didn't see this posted yet, so I have attached it below. If it has, sorry in advance. I have gcc 2.8.1 , and the kernel version is : test10-5 Regards, Frank During make modules ... af_irda.o : In function 'cleanup_module' : af_irda.o(.text+0x3e90): multiple definition of 'cleanup_module' irmod.o(.text+0x514): first defined here make[2]: *** [irda.o] Error 1 make[2]: Leaving directory '/usr/src/linux/net/irda' ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
> > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > let me guess: intel eepro100 or similar?? yeap 00:02.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) Subsystem: Asustek Computer, Inc.: Unknown device 1043 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- > Well known problem with that one. dont know if its fully fixed ... With > 2.4.0-test9-pre3 it doesnt happen on my machine ... we have 1-2 servers running 2.4.0-test9 and we got this error ... is there any patch to 2.2.18pre ? since the server has to run on sunday we can still make the crazy tests 3 days. it would be cool to fix it to 2.2.X if the bug is known ;) octave -- Amicalement, oCtAvE "Peu importe ce qu'il y a de l'autre côté. Tout ce qu'on laisse ici n'est qu'une histoire dont on se souviendra ou pas." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM-global-2.2.18pre17-7
octave klaba wrote: > > > >ftp://ftp.kernel.org/pub/people/andrea/patches/v2.2/2.2.18pre17/VM-global-2.2.18pre17-7.bz2 > > > eth0: card reports no resources > > > VFS: file-max limit 4096 reached > > > Kernel panic: VFS: LRU block list corrupted. > > > Kernel panic: VFS: LRU block list corrupted. > > > Kernel panic: VFS: LRU block list corrupted. > > > Kernel panic: VFS: LRU block list corrupted. > > after 6h of test 23-24mbs it seems to work. > we still have some errors with eth0. I think it is because the > server is changed and there is no more CPU ? > > thanks for help > octave > > 890-900 process > 5:12pm up 6:05, 3 users, load average: 710.14, 713.70, 713.84 > > Oct 26 11:24:13 ns29 kernel: eth0: card reports no resources. > Oct 26 11:24:15 ns29 kernel: eth0: card reports no resources. > Oct 26 12:22:21 ns29 kernel: eth0: card reports no resources. > Oct 26 16:16:59 ns29 kernel: eth0: card reports no resources. > Oct 26 16:28:37 ns29 kernel: eth0: card reports no resources. > Oct 26 16:38:01 ns29 kernel: eth0: card reports no resources. > let me guess: intel eepro100 or similar?? Well known problem with that one. dont know if its fully fixed ... With 2.4.0-test9-pre3 it doesnt happen on my machine ... Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel OOPS on boot
On Thu, Oct 26, 2000 at 10:20:45AM -0400, Brian Gerst wrote: > Mircea Damian wrote: > > > > Hello, > > > > I'm unable to boot kernel 2.4.0-test10-pre5 on a: > > Upgrade GCC to 2.91.66 (aka egcs-1.1.2) Ok. I can do that, but there is nowhere written that I should do that. If I remember right gcc-2.7.2.3 was the preferred compiler for all kernels. Am I wrong? -- Mircea Damian E-mails: [EMAIL PROTECTED], [EMAIL PROTECTED] WebPage: http://taz.mania.k.ro/~dmircea/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux's implementation of poll() not scalable?
"Eric W. Biederman" wrote: > > Dan Kegel <[EMAIL PROTECTED]> writes: > > It's harder to write correct programs that use edge-triggered events. > > Huh? The race between when an event is reported, and when you take action > on it effectively means all events are edge triggered. Nope. With any of these interfaces, whether level or edge, the app must treat all the events as hints, and be prepared for them to be wrong. That's why code that uses poll() tends to use nonblocking sockets. No matter what you do, you can't get away from that. Consider accepting a connection. Poll or whatever tells you a listening socket is ready for you to call accept(). Before you do, the other end sends an RST. Consequence: app must be prepared for a readiness event to be wrong. cf. http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0616.html This is orthogonal to the question of whether edge or level triggering is easier to write code for, I think. > So making the interface clearly edge triggered seems to be a win for > correctness. With level-triggered interfaces like poll(), your chances of writing a correctly functioning program are higher because you can throw events away (on purpose or accidentally) with no consequences; the next time around the loop, poll() will happily tell you the current state of all the fd's. With edge-triggered interfaces, the programmer must be much more careful to avoid ever dropping a single event; if he does, he's screwed. This gives rise to complicated code in apps to remember the current state of fd's in those cases where the programmer has to drop events. And there are many cases like that; see http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0529.html and http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0592.html for examples. Better to let apps ask the kernel for the current state of each socket if they want, is what I say. This reduces the amount of code and effort needed to write many apps, *and makes migrating legacy apps to high-performance interfaces easier*. For new apps that are willing to maintain the state themselves, by all means, provide an edge-oriented interface, too. It's probably better if your code is manly enough to handle it. - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RAID superblock
> > Hi, > > After I create a RAID setup on the drives,The > > superblock will be generated at the end of the drives. > > If I move these drives to other linux system, will > > this > > system recognise the RAID setup without reconfiguring > > the Linux ? > > If the CHS / LBA settings are the same, and the kernel is the same : Yes. While this subject is fresh, what would be wrong with using the entire drive as opposed to creating a partition and adding the partition to the raid? -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at slab.c:804!
> "christian" == Christian Reiser <[EMAIL PROTECTED]> writes: christian> Hi, christian> i hope i am right here, and this problem wasn't mailed a thousand times christian> before - but it is not older than 3 days (2.4.0-test10-pre5 is'nt christian> older...) christian> I am playing around with usb and usb-storage, and then i wanted to reload christian> the usb-ohci-module, during the insmod i got this error: christian> Oct 26 15:11:00 christian kernel: usb.c: kusbd: /sbin/hotplug remove 2 christian> Oct 26 15:11:00 christian kernel: usb.c: USB bus 2 deregistered christian> kmem_cache_destroy: Can't free all objects c116a890 christian> : usb-ohci.h: td_cache remained christian> kernel BUG at slab.c:804! christian> invalid operand: christian> CPU:0 christian> EIP:0010:[] christian> EFLAGS: 00010282 christian> eax: 001a ebx: c116a8ec ecx: c19e2000 edx: c23b9780 christian> esi: c116a8e0 edi: c48ef78b ebp: c116a8f4 esp: c19e3ef8 christian> ds: 0018 es: 0018 ss: 0018 christian> Process insmod (pid: 1026, stackpage=c19e3000) christian> Stack: c02197e7 c0219867 0324 2000 0001 c48ec051 c48ec048 christian> c116a908 christian>c116a950 c02b14a8 c19e3f28 0020 c48ec069 c48ef783 christian> 0020 christian>0020 00022000 c48ec000 c48ef606 c48ec000 christian> c01177db christian> Call Trace: [] [] [] [] christian> [] [] [] christian>[] [] [] [] [] christian> [] christian> Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 8b 1b 81 fb bc 23 26 c0 christian> ... hope it could help ... Hi could you pass the output through ksymoops to know the backtrace, see the linux/Reporting_bugs file. Without that info it is very difficult to know what is happening. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On 26 Oct 2000, Yoann Vandoorselaere wrote: > Vojtech Pavlik <[EMAIL PROTECTED]> writes: [Snipped...] ../drivers/block/ide.c, line 162, on version 2.2.17 does bad things to the timer. It writes 0 to the control-word for timer 0. This does the following: o Selects timer 0. o Latches the timer. o Selects mode 0. o Programs it to a 16 bit counter. The result is a latched (stopped) counter. Bits 5 and 4 should have been selected. Then you read bits 0-7 from 0x40, followed by bits 8-15 from the same port. Also, there is no spin-lock protecting access to these ports. If anybody else is mucking with the timer, all bets are off. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Topic for discussion: OS Design
Keith Owens <[EMAIL PROTECTED]>: > > On Thu, 26 Oct 2000 09:17:49 -0400 (EDT), > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote: [snip] > >This shows that out of 34,678 bytes we needed, we wasted 6282, ~1.5 > >pages. Since there are 5 modules, we waste about 1/3 page per module. > > > >So I don't, as you say; "... waste 1/2 page or more per module". > > Statistics say that the average loss will be 1/2 page per module. Some > will waste more, some will waste less, average is 1/2 the unit. Only if the size of a random module can be between 0 and a full page Module sizes are skewed data... there is a minimum size for a module (somewhere around 1k, I believe - didn't measure it), and if the module is going to DO anything then it will be between 1-2K. This skews the data sample such that you are only loosing 1/2 of (1 page - minimum) or 1/2 of 3K = 1.5K. Hence the 1/3 measured loss will be closer to the correct theoretical loss than 1/2. - Jesse I Pollard, II Email: [EMAIL PROTECTED] Any opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
On Thu, 26 Oct 2000, Igmar Palsenberg wrote: >> Per chance are you running the name service caching daemon (nscd)? I'd >> also guess you aren't disabling fsync() for your sysylog files (it's part >> of the syslog.conf format) -- this is a conciderable drain on syslogd. > >Agree. It is there for a reason : I case the system hangs, you at least >get the last messages. But it is indeed a major drain. I've send Patrick a >small path that makes reverse lookups a config option. Sadly, you WILL still lose entries if the system crashes before fs metadata has been flushed to disk. Unless the inode has the correct size stored, the crap fsync()ed to disk doesn't make much difference. (This is amplified by dcache.) --Ricky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: missing mxcsr initialization
On Thu, 26 Oct 2000, Andrea Arcangeli wrote: > On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote: > > I've made a few correctness changes to this code. Items that needed to be > > corrected for include the facts that the XMM feature bit is an Intel specific > > bit that other vendors may use for other things, so you need to test vendor == >^^^ > Note that they shouldn't do that! I would consider a very bad thing if they > goes out of sync on those bits. Indeed. Let's face it. People who don't follow the intel ordering of bits are _buggy_. And yes, there are tons of buggy chips out there (mainly from AMD, but I'll refrain from throwing _too_ many stones in case somebody else ends up with similar bugs in the future ;). And yes, some of those bugs are even explainable (ie AMD wanted to do their own features, and at the time Intel didn't reserve those bits). But whatever the excuses are, it is NOT VALID to not honour the feature bits. You should NOT have to do something stupid like if (vendor == intel) if feature in intel_feature_flags else if (vendor == ..) ... just to test a simple feature. You should do something like if (X86_FEATURE_SEP & feature) it claims fast system calls.. and then the _setup_ code is supposed to find bugs, and fix them up. And the "standard" features are the ones Intel exports. End of story. Everybody else gets to be re-ordered until they look like intel. Now, things like 3dnow etc extensions that Intel isn't likely to ever support can be handled quite well with this approach, thank you very much. The cpuid "feature" field on x86 is 32-bit. We'll make the kernel feature fields be 64 bits or more. End of story. And then we move the 3dnow feature bit up beyond the 32nd bit (or up beyond the 64th bit or wahtever, in case we start using extended intel bit numbers etc). The whole _point_ of the feature bitmap is that you don't care about the vendor, the CPU level, or the phase of the moon. Anybody arguing that you should check vendor information does not understand what the feature bitmap is all about, and should be forced to go back to the bad old times when you had to check the stepping levels etc to figure out what the CPU's could do. Note how this also goes for intel and clone 386 and 486 CPU's from before cpuid: we can fix up the feature bitmap even if they don't even _have_ cpuid, at setup time. So that we forever after can just test the feature bitmap and be done with it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug
Hi, I have the same problem. On Thu, 26 Oct 2000, Vojtech Pavlik wrote: [...snip...] > Could you send me your 'lspci -vvxxx' to confirm it's the very same > chip? 00:07.0 ISA bridge: VIA Technologies, Inc.: Unknown device 0686 (rev 21) Subsystem: Unknown device 1106: Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote: > > > > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote: > > > > > > > ... > > > > > > > > Have you any idea what is the relation between time and this chip ? > > > > > > > > Also, I'm experiencing the problem for several month on my > > > > workstation and I never could find where it was comming from... > > > > how did you do ? > > > > > > Well, it integrates both the i8253 PIT and the vt82c586 IDE controller. > > > > > > I first located the wrong time was coming from gettimeofday() and not > > > from the other sources of time the kernel provides. And then I was > > > tracking the problem (which actually is an underflow - the chip bug > > > causes some time offset variables go negative - 0x microseconds > > > is about 1:20 hours). And this way I got to the spot where the patch > > > cures the problem. > > > > Ok, here is what I experienced : > > > > First what is strange is that : > > - I'm using SCSI > > - I just have an IDE disk for mp3. > > The IDE subsystem is never used heavilly... > > > > I've experienced the problem after some time of > > heavy scsi IO, my screen under X was going black (like with dpms) > > When I was moving the mouse, the image was coming back > > for < 1 seconds, then black screen... > > > > The only fix was to kill X then to reboot. > > > > Anyway, thanks for your explaination... > > I'll do a feedback for this patch ASAP. > > Interesting. If it's caused by SCSI as well (might be), then it's not > caused by heavy IDE activity but rather than that it could be heavy > BusMastering activity instead (The IDE chip does BM as well). > > I'm still wondering if it could be a Linux kernel bug (bad/concurrent > accesses to the i8253 registers), this has to be checked. An easy way to verify the problem is to start 'dbench 128', I'm gonna do that with and without IDE subsystem to see what happen. -- -- Yoann http://www.mandrakesoft.com/~yoann/ I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' -- Mike Godwin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug (private question)
On Thu, Oct 26, 2000 at 04:42:31PM +0200, Yoann Vandoorselaere wrote: > > On Thu, Oct 26, 2000 at 04:20:43PM +0200, Yoann Vandoorselaere wrote: > > > > > ... > > > > > > Have you any idea what is the relation between time and this chip ? > > > > > > Also, I'm experiencing the problem for several month on my > > > workstation and I never could find where it was comming from... > > > how did you do ? > > > > Well, it integrates both the i8253 PIT and the vt82c586 IDE controller. > > > > I first located the wrong time was coming from gettimeofday() and not > > from the other sources of time the kernel provides. And then I was > > tracking the problem (which actually is an underflow - the chip bug > > causes some time offset variables go negative - 0x microseconds > > is about 1:20 hours). And this way I got to the spot where the patch > > cures the problem. > > Ok, here is what I experienced : > > First what is strange is that : > - I'm using SCSI > - I just have an IDE disk for mp3. > The IDE subsystem is never used heavilly... > > I've experienced the problem after some time of > heavy scsi IO, my screen under X was going black (like with dpms) > When I was moving the mouse, the image was coming back > for < 1 seconds, then black screen... > > The only fix was to kill X then to reboot. > > Anyway, thanks for your explaination... > I'll do a feedback for this patch ASAP. Interesting. If it's caused by SCSI as well (might be), then it's not caused by heavy IDE activity but rather than that it could be heavy BusMastering activity instead (The IDE chip does BM as well). I'm still wondering if it could be a Linux kernel bug (bad/concurrent accesses to the i8253 registers), this has to be checked. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Possible critical VIA vt82c686a chip bug
On Thu, Oct 26, 2000 at 04:04:16PM +0100, Mark Cooke wrote: > On 26 Oct 2000, Yoann Vandoorselaere wrote: > > > This is an athlon 750 machine, with scsi and ide a disk... > > I've tryed to see where the problem was comming from for age > > ( the problem is what you describe and it happen after some time > > (1 to 24 hour, it depend) and often while or after heavy I/O... > >the only fix is to reboot the machine. ) > > xset s off will fix it (least it does for me), without needing a > reboot. At least until the 'next time'. It fixes the blanking, but squid, wmclock (and other apps using gettimeofday()) will still cause trouble. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make my life easier ...
On Thu, 26 Oct 2000, Stephen Rothwell wrote: > > OK, I include below a more or less translation for 2.4. I have not even > compiled this, and have not got the hardware to test it anyway. I disagree violently with doing this in the low-level drivers. If it cannot be done in user space (which is dubious in itself, but I'll certainly accept it), then why not just do the equivalent of a reset in the high-level IDE driver on coming back from sleep? Possibly together with forcing any other setup state we know about. That, together with using the pci_register_driver() thing, would be my preferred approach by far. This kind of low-level twiddling and special casing _will_ come back to haunt us later. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops while running test10-pre5
ksymoops 2.3.4 on i686 2.4.0-test10. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test10/ (specified) -m /usr/src/linux/System.map (default) Error (regular_file): read_system_map stat /usr/src/linux/System.map failed Oct 19 13:00:23 ives kernel: invalid operand: Oct 19 13:00:23 ives kernel: CPU:0 Oct 19 13:00:23 ives kernel: EIP:0010:[try_to_swap_out+252/796] Oct 19 13:00:23 ives kernel: EFLAGS: 00010286 Oct 19 13:00:23 ives kernel: eax: 001c ebx: 0200 ecx: edx: Oct 19 13:00:23 ives kernel: esi: c11c8590 edi: 0001 ebp: 06b60045 esp: c1273ebc Oct 19 13:00:23 ives kernel: ds: 0018 es: 0018 ss: 0018 Oct 19 13:00:23 ives kernel: Process kswapd (pid: 3, stackpage=c1273000) Oct 19 13:00:23 ives kernel: Stack: c01d07ea c01d09a9 0066 40279000 c7e3dda0 4027a000 40278000 c01836e7 Oct 19 13:00:23 ives kernel:c012968e c7e3dda0 c6b9bd60 40278000 c6cad9e0 0004 40278000 c6b9bd60 Oct 19 13:00:23 ives kernel:c7e3dda0 0004 c6cad9e0 40678000 c6ca3400 4027a000 4027a000 c6ca3400 Oct 19 13:00:23 ives kernel: Call Trace: [tvecs+6622/60500] [tvecs+7069/60500] [ide_end_request+111/120] [swap_out_vma+322/440] [swap_out_mm+56/100] [swap_out+283/368] [refill_inactive+213/376] Oct 19 13:00:23 ives kernel: Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 a9 09 1d c0 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: f7 c5 02 00 00 00 test $0x2,%ebp Code; 000b Before first symbol b: 74 17 je 24 <_EIP+0x24> 0024 Before first symbol Code; 000d Before first symbol d: 6a 68 push $0x68 Code; 000f Before first symbol f: 68 a9 09 1d c0push $0xc01d09a9 Oct 19 13:00:35 ives kernel: invalid operand: Oct 19 13:00:35 ives kernel: CPU:0 Oct 19 13:00:35 ives kernel: EIP:0010:[try_to_swap_out+252/796] Oct 19 13:00:35 ives kernel: EFLAGS: 00013282 Oct 19 13:00:35 ives kernel: eax: 001c ebx: 0500 ecx: c6c813c0 edx: 0001 Oct 19 13:00:35 ives kernel: esi: c118bc90 edi: 0001 ebp: 05d20045 esp: c6afbc20 Oct 19 13:00:35 ives kernel: ds: 0018 es: 0018 ss: 0018 Oct 19 13:00:35 ives kernel: Process squid (pid: 829, stackpage=c6afb000) Oct 19 13:00:35 ives kernel: Stack: c01d07ea c01d09a9 0066 40199000 c6c81be0 4019d000 40197000 Oct 19 13:00:35 ives kernel:c012968e c6c81be0 c521cb60 40198000 c4a13660 0003 40197000 c521cb60 Oct 19 13:00:35 ives kernel:c6c81be0 0003 c4a13660 40597000 c4977400 4019d000 4019d000 c4977400 Oct 19 13:00:35 ives kernel: Call Trace: [tvecs+6622/60500] [tvecs+7069/60500] [swap_out_vma+322/440] [swap_out_mm+56/100] [swap_out+283/368] [refill_inactive+213/376] [do_try_to_free_pages+98/128] Oct 19 13:00:35 ives kernel: Code: 0f 0b 83 c4 0c f7 c5 02 00 00 00 74 17 6a 68 68 a9 09 1d c0 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: f7 c5 02 00 00 00 test $0x2,%ebp Code; 000b Before first symbol b: 74 17 je 24 <_EIP+0x24> 0024 Before first symbol Code; 000d Before first symbol d: 6a 68 push $0x68 Code; 000f Before first symbol f: 68 a9 09 1d c0push $0xc01d09a9 1 error issued. Results may not be reliable. -- END - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre4: deadlock in VM?
On Thu, 26 Oct 2000, Rik van Riel wrote: > On Wed, 25 Oct 2000, Roger Larsson wrote: > > > I noted that even try_to_free_buffers locks lru_list_lock. > > lru_list_lock != pagemap_lru_lock > btw, while we are at it, I am not able to reproduce this with test10-pre5 but am still running tests with higher and higher load... I will let you know if something of interest happens. regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: syslog() blocks on glibc 2.1.3 with kernel 2.2.x
Igmar Palsenberg <[EMAIL PROTECTED]> writes: > On 23 Oct 2000, Patrick J. LoPresti wrote: > > > Not true. The named on our loghost is authoritative for the reverse > > mappings for all of the machines which can log there. > > Put the names of your machines in /etc/hosts on your logmachine. This is not an option for us, unfortunately. Many of our IP addresses are dynamically assigned, with the DNS tables dynamically updated. Thank you for the patch to syslogd, though! Can you try to get your "-x" option into the standard distributions of syslogd, or should I work up a bug report / feature request for Red Hat myself? - Pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
