emu10k1 broken in 2.2.18
Alan/Rui, just built 2.2.18 (on a box that's been running 2.2.14 for a very very long time, and loading an emu10k1 module from opensource.creative.com or wherever). was pleased to note that emu10k1 finally made it in. Compiled and built. Dmesg indicated that things were detecting nicely, but attempts to play sound result in 'Cannot open /dev/dsp!' (not a rights problem). I had heard a bit earlier this evening on #debian that someone was complaining of similar problems on a 2.2.17->2.2.18 upgrade, so on a hunch i pulled down a 2.2.17 kernel, and make oldconfig'd it with my 2.2.18 config. dmesg again fine, this time it works :) so there does appear to be a problem there. templestowe:~$ dmesg |less Linux version 2.2.17 (root@templestowe) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 Tue Dec 19 01:44:23 EST 2000 ... Creative EMU10K1 PCI Audio Driver, version 0.6, 01:45:48 Dec 19 2000 emu10k1: EMU10K1 rev 4 model 0x20 found, IO at 0xe400-0xe41f, IRQ 10 ... machine is running debian sid. i'll be happy to do anything else anyone suggests to play with this. I did diff out the source file by file in drivers/sound/emu10k1 (my *god* since when did this driver need to be 8k+ lines of code? i just wrote a kernel and filesystem for my CMU OS class [15-412] in that many lines :) ... and there's more than i'm prepared to deal with. is this driver working for anyone else in 2.2.18? anyone recall the reasoning behind this patch set (i may well have missed it going by on l-k)? perhaps this is just a known problem by now but i haven't seen mention on l-k so i'll risk the wrath of the appropriate gods. Cheers, Ari Heitner - 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: ServerWorks docs?
Rico & Dan, Below is the Email that Jim Forster of Serverworks sent to me: "We want to enable the Linux community as quickly as possible; we agree with you that it makes business sense to do so. Given the fact that our IP is our sole product, we cannot release our technical documents to the world at large. We have been working to create an extract of our documents to enable the Linux community. As a small company experiencing tremendous growth, our support infrastructure must focus on our existing customers. At this time, I do not have an estimated release date for the technical extract. ... We are continuing our work to enable the Linux community. Can you think of any alternative methods to enable the Linux community without exposing ourselves? I'm certainly open to new ideas..." Jim responded to my Email regarding support for lm-sensor. Granted Serverworks has not released any information to the public. But they are planing to extract certain chipset information that might be helpful for you. They are also open to idea from the Linux community. After Jim replied, Phil Edelbock from lm-sensor group came up with a good idea. They decided to ask Jim for a specific set of information pertaining to the project. So rather goes for the whole documentation, they only asked for a small subset. The idea worked because Serverworks were able to supply the information quickly. This could be a good approach in getting information from Serverwork outside of NDA. Jeff ASL Inc. - Original Message - From: "Rico Tudor" <[EMAIL PROTECTED]> To: "Jeff Nguyen" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, December 18, 2000 3:14 AM Subject: Re: ServerWorks docs? > Thanks for the offer, but the basic problem remains: no docs. > As [EMAIL PROTECTED] noted, http://www.netroedge.com/~lm78/ shows some > cause for hope, but a medium-sized LART is still called for. > > My interest in ServerWorks documentation is two-fold: first, to > expand chipset support in my ECC utility and second, to better support > ServerWorks-based machines in my workplace. > > On behalf of the Linux community, I would sign NDA if it was civilized > and if my source remained, obviously, public-domain. I could visit > ServerWorks on my next foray to the Bay Area. > > More important to me is ready access to technical documentation to support > machines at work. I come from the era when PDP-11's were shipped with > schematics, the OS, and the source to the OS. Things have been going > downhill ever since. I'm not catching the next plane to the Bay Area > for "eyes only" examination of a document every time a problem arises. > In this regard, companies like IBM Storage and Intel win my kudos, > and my dollars. ServerWorks may get some of those dollars because they > have an affordable chipset that supports 4 GB, but that advantage can > change overnight. It's not like IP has a long half-life these days, > unless you can corner the pyramid-building business. > > These companies must evaluate their proprietary stance in relation to lost > sales, the more so as free source accelerates. ATI, Matrox, Adaptec: need > we say more? But then, I'm preaching to the choir. Perhaps ServerWorks > should look into their hearts, and decide what small part of their IP > has enormous, eternal value -- the kind that will have them rolling in > dough, just like Scrooge McDuck. The rest of the specification, like > the miserable ECC circuitry that's been done a million times before, > release it already! Their adoring Linux fans are waiting. > > P.S. I wonder if Via reads this list. - 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/
Is there a devfs patch for 2.2.18?
Hi, Is there a devfs patch for 2.2.18 or how do I get devfs to work with 2.2.18? Tri [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: /dev/random: really secure?
On Sun, Dec 17, 2000 at 10:50:57PM +0100, Karel Kulhavy wrote:
> I noticed peculiarities in the behaviour of the delta-delta-3 system for
> entropy estimation in the random.c code./ When I hold right alt or control, I
> get about 8 bits of entropy per repeat fro the /dev/random which is
> overestimated. I think the real entropy is 0 bits because it is absolutely
> deterministic when the interrupt comes. Am I right or is there any hidden
not absolutely, but we should ignore repeated keys that generate more than
one scancode.
tytso, here's the patch to do it again:
--- linux/drivers/char/random.c Sun Jul 30 18:01:23 2000
+++ linux-prumpf/drivers/char/random.c Thu Sep 28 17:07:03 2000
@@ -763,10 +763,15 @@
void add_keyboard_randomness(unsigned char scancode)
{
- static unsigned char last_scancode = 0;
- /* ignore autorepeat (multiple key down w/o key up) */
- if (scancode != last_scancode) {
- last_scancode = scancode;
+ static unsigned char last_scancode[2] = { 0, 0 };
+
+ /* ignore autorepeat (multiple key down w/o key up).
+* add_keyboard_randomness is called twice for certain AT keyboard
+* keys, so we keep a longer history. */
+ if (scancode != last_scancode[0] &&
+ scancode != last_scancode[1]) {
+ last_scancode[0] = last_scancode[1];
+ last_scancode[1] = scancode;
add_timer_randomness(_timer_state, scancode);
}
}
If we want to rely solely on the add_timer_randomness checks, we should
remove the autorepeat check completely.
Philipp Rumpf
-
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: Startup IPI (was: Re: test13-pre3)
Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. -- Ferret - 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: about linux-2.4.0-test13pre3
On Sun, Dec 19, 1999 at 01:23:02PM +0800, linux-kernel wrote: > Hi, > Where can I get the linux-2.4.0-test13pre3 at ftp.xx.kernel.org /pub/linux/kernel/testing/ Where xx is your country-code of preference. /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
about linux-2.4.0-test13pre3
Hi, Where can I get the linux-2.4.0-test13pre3 -- Best regards, linux-kernel 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/
PATCH: linux-2.4.0-test13pre3/arch/i386/math-emu/fpu_system.h compilation error
In linux-2.4.0-test13pre3 (or maybe pre1 or pre2), mm_struct->segments became mm_struct->context.segmnets. This change adjusts linux-2.4.0-test13pre3/arch/i386/math-emu/fpu_system.h accordingly so that i386 math emulation will compile again. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." --- linux-2.4.0-test13-pre3/arch/i386/math-emu/fpu_system.h Mon Dec 11 13:34:33 2000 +++ linux/arch/i386/math-emu/fpu_system.h Mon Dec 18 21:10:35 2000 @@ -20,7 +20,7 @@ of the stack frame of math_emulate() */ #define SETUP_DATA_AREA(arg) FPU_info = (struct info *) -#define LDT_DESCRIPTOR(s) (((struct desc_struct *)current->mm->segments)[(s) >> 3]) +#define LDT_DESCRIPTOR(s) (((struct desc_struct +*)current->mm->context.segments)[(s) >> 3]) #define SEG_D_SIZE(x) ((x).b & (3 << 21)) #define SEG_G_BIT(x) ((x).b & (1 << 23)) #define SEG_GRANULARITY(x) (((x).b & (1 << 23)) ? 4096 : 1)
Re: Linus's include file strategy redux
[richard offer]
> Or userland libraries/applications that need to bypass libc and make
> direct kernel calls because libc hasn't yet implemented those new
> kernel calls.
Nah, it's still error-prone because it's too hard to guarantee that the
user compiling your program has up-to-date kernel headers in a location
you can find. Too many things can go wrong.
So just '#include ' -- the libc version -- then have your
own header for those few things you consider "too new to be in libc":
/* my_unistd.h */
/* [not sure if all the __{arch}__ defines are right] */
#include/* from libc, not from kernel */
#ifndef __NR_pivot_root
# ifdef __alpha__
# define __NR_pivot_root 374
# endif
# if defined(__i386__) || defined(__s390__) || defined(__superh__)
# define __NR_pivot_root 217
# endif
# ifdef __mips__
# define __NR_pivot_root (__NR_Linux + 216)
# endif
# ifdef __hppa__
# define __NR_pivot_root (__NR_Linux + 67)
# endif
# ifdef __sparc__
# define __NR_pivot_root 146
# endif
#endif
#ifndef __NR_pivot_root
# error Your architecture is not known to support pivot_root(2)
#endif
_syscall2(int,pivot_root,char *,new,char *,old)
Yes it's clumsy but it's guaranteed to be where you expect it. (And
it's not nearly as clumsy if you don't feel the need to support all
architectures.)
Peter
-
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: [RFC] Semaphores used for daemon wakeup
On Sun, Dec 17, 2000 at 01:06:10PM +0100, Daniel Phillips wrote: > This patch illustrates an alternative approach to waking and waiting on > daemons using semaphores instead of direct operations on wait queues. > The idea of using semaphores to regulate the cycling of a daemon was > suggested to me by Arjan Vos. The basic idea is simple: on each cycle > a daemon down's a semaphore, and is reactivated when some other task > up's the semaphore. [...] > > OK, there it is. Is this better, worse, or lateral? Well, I have to confess I'm rather fond of this method, but that could have something to do with it being how we did it in DYNIX/ptx (Sequent). It certainly works, and I find it very clear, but of course I'm biased :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Pourquoi pas vous ?
Title: La Toile des Communicateurs Vous recevez ce courriel pour la première et la dernière fois car un ami vous a référé à nous La Toile des Communicateurs Votre communauté professionnelle virtuelle La première communauté virtuelle des communicateurs francophones avec près de 15 000 membres à travers 38 pays vous envoie ce courriel afin de vous inviter à partager sans aucun frais les privilèges d'appartenir à un keiretsu* de communicateurs. En moins de deux ans , La Toile des Communicateurs est passée d'un simple annuaire de communicateurs à un lieu où vous retrouvez emplois, bulletins d'informations, archives publicitaires, sondages et un Index d'Influence du milieu des communicateurs. D'autres services plus spécifiques à vos besoins d'achats se grefferont à La Toile dans les prochains mois. Développez votre sentiment d'appartenance, essayez La Toile des Communicateurs. Ici, la communauté est le message ! Merci ! La Toile des Communicateurs *Keiretsu, terme japonais désignant un réseau de gens forts voulant s'entraider. Si vous ne pouvez voir ce message, cliquez ici pour l'afficher dans votre fureteur : http://www.marketingnumerique.com/diffusion/20001218.html Pour en savoir plus sur notre politique de confidentialité, cliquez ici.
Re: 2.4.0-test13-pre1 lockup: run_task_queue or tty_io are wrong
Linus Torvalds wrote: > > I wasn't clear. The sentinel is a local structure on the stack, and > > only exists while run_task_queue is executing. Another name for this is > > "deletion-safe pointer". > > Yes, except run_task_queue removes every object it finds. So two > concurrent run_task_queues would be bad. That could work, but forget it. I've just looked at Andrew's patch and it's much nicer :-) If you put a spinlock around the list operations in Andrew's version, you'd have safe tqueue deletions again (if you felt that was worth having). Some tricks and you can make it a different spinlock, but I doubt that would be a net benefit. -- Jamie - 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: old binary works not with 2.2.18
kees wrote: > Hi, > > I have an old 4GL application (from SCO3.2v4) that is a neat database > tool. Under 2.2.17 with iBCS this works well: I am just curious. Did you re-compile the iBCS2 module after upgrading to 2.2.18 to did you force the module to load up... With Slackware and kernel upgrades this is a regular procedure with me otherwise chaos ensues :-) Johnny O -- what's the difference between chattr and chmod? SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less -- Seen on #linux on irc === Never ask a geek why, just nod your head and slowly back away.=== +==++ | John O'Donnell (Sr. Systems Engineer, Net Admin, Webmaster, etc.) | | Voice FX Corporation (a subsidiary of Student Advantage) | | One Plymouth Meeting | E-Mail: [EMAIL PROTECTED] | | Suite 610| www.voicefx.com | | Plymouth Meeting, PA 19462 | www.campusdirect.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/
A way to crash an 2.4-test11 kernel
Hi, I found a way to crash an SMP 2.4-test11 kernel: 1. Create a BIG file (lets say about 300-400 MByte) 2. use losetup and the loop device to create an ext2 filesystem within the file 3. mount the file 4. copy huge amounts of data into the file. (for example copy your /usr directory into it.) -> Kernel deadlocks after some time. Could someone try to reproduce this behaviour ? so long Ingo - 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: User based routing?
On Mon, Dec 18, 2000 at 07:46:51PM +, Ian Stirling wrote: > Are there any patches floating around? > Basically to allow for example a server to dial out to ISP's on behalf > of users, and give them full control over that interface. > I know about UML, and it's not quite suited. > I've not found anything searching archives, but maybe it's out there. Sounds like you're looking for masqdialer. It doesn't give full control to users (why should it), but it allows users to select from multiple ISPs. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
> List: linux-kernel > Subject: Re: test13-pre3 woes > From: Peter Samuelson <[EMAIL PROTECTED]> > Date: 2000-12-18 9:19:13 > [Download message RAW] > > > [J Sloan] > > The module now compiles and gets installed - > > Unfortunately, attempting to load it does not go well: > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range > > kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up > > kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add > > kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user > > kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule > > kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc > > kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo > > Those symbols are rather generic and rather important. Sounds like a > generic module problem. Do other modules load? Does your kernel use > MODVERSIONS? (This module apparently doesn't.) Are you using a recent > version of modutils? > > Puzzled. Maybe Keith Owens knows something. > > Peter I got this, too. The one liner send here on lkm seems to be not enough. Even Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake this stuff. It works before these changes. So Rik any comments? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [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: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, Dec 18, 2000 at 10:57:44PM +0100, Mikulas Patocka wrote: > You have small posibility that interrupt will eat up memory - interrupt in > process that has PF_MEMALLOC. Patch: this is not the point of getblk, to fix the getblk deadlock the only way is to implement a fail path in each caller and allow getblk to return NULL (as every other memory allocation function can do). 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: SerialATA Release, sortof........
On Tue, 19 Dec 2000, David Weinehall wrote: > On Mon, Dec 18, 2000 at 01:27:07PM -0800, Andre Hedrick wrote: > > > > FYI > > > > The Serial ATA specification (500 pages) is now available to the public > > under certain "click-to-accept" conditions. Click the "specification" > > link at the bottom of the home page at http://www.serialata.org/. > > I hope the conditions are acceptable. The file is zipped MS Word. > > Well, I think that most people can be happy with the conditions. Now, > the format, that's a completely different issue. With all your > influence, I bet you could persuade them to at least run the document > through Acrobat Distiller to turn it into a .pdf?! My bad for forwarding info from internal. I knew that my copies were in PDF, but did not know if they combined all the erratas in to a newer doc or what Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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: [RFC] Semaphores used for daemon wakeup
On Sun, 17 Dec 2000, Daniel Phillips wrote: > This patch illustrates an alternative approach to waking and waiting on > daemons using semaphores instead of direct operations on wait queues. > The idea of using semaphores to regulate the cycling of a daemon was > suggested to me by Arjan Vos. The basic idea is simple: on each cycle > a daemon down's a semaphore, and is reactivated when some other task > up's the semaphore. > Is this better, worse, or lateral? This is much better, especially from a maintainability point of view. It is also the method that a lot of operating systems already use. Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SerialATA Release, sortof........
On Mon, Dec 18, 2000 at 01:27:07PM -0800, Andre Hedrick wrote: > > FYI > > The Serial ATA specification (500 pages) is now available to the public > under certain "click-to-accept" conditions. Click the "specification" > link at the bottom of the home page at http://www.serialata.org/. > I hope the conditions are acceptable. The file is zipped MS Word. Well, I think that most people can be happy with the conditions. Now, the format, that's a completely different issue. With all your influence, I bet you could persuade them to at least run the document through Acrobat Distiller to turn it into a .pdf?! /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: generic sleeping locks?
In message <[EMAIL PROTECTED]> you write: > Alan Cox wrote: > > > > > Are there blocking lock primitives already defined somewhere in the > > > kernel? > > > > down and up are normally appropriate for this > > Ungh. Forest. Trees. *sigh* Sorry for the dumb question. > Thanks for the reply Alan. :) > > Ok, second part of the question: What about blocking read/write locks > (with _interruptible variants)? Documentation/DocBook/kernel-locking* Rusty. -- Hacking time. - 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.4.0test13pre3ac2
Merge more pending stuff The patch for the adventurous is in ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/.. 2.4.0test13pre3-ac2 adds o Resync with the powerpc folks (Cort Dougan) o Fix appletalk config entry (William McGonigle) o Documentation/script fixes (Tim Waugh) o Parport experimental label fix (Tim Waugh) o Update credits to add Hans Grobler (Hans Grobler) o Make uhci return the same error code as the (David Brownell) other USB hub controllers o Merge Fusion drivers(Steve Ralston) o BPQ ethernet tidy (Hans Grobler) o Updated AX.25 tidy (Hans Grobler) o Shared memory fixes (Christoph Rohland) o Resync mac ethernet drivers (Cort Dougan) o Fix missing memory barrier in bootp/dhcp code (Cort Dougan) 2.4.0test13pre3-ac1 adds o Handle TLB flush reruns caused by APIC rexmit (me) o Fix leak in link() syscall (Christopher Yeoh) o Fix ramfs deadlock (Al Viro) o Fix udf deadlock(Al Viro) o Improve parport docs(Tim Waugh) o Document some of the macros (Tim Waugh) o Fix ppa timing issues (Tim Waugh) o Mark the parport fifo code as experimental (Tim Waugh) o Resynch ppa changelog (Tim Waugh) | Tim please double check as I got offsets o Fix Yam driver for Linux 2.4test(Hans Grobler) o Fix AF_ROSE sockets for 2.4 (Hans Grobler) o Fix AF_NETROM sockets for 2.4 (Hans Grobler) o Tidy AF_AX25 sockets for 2.4(Hans Grobler) o Teach kernel-doc about const(Jani Monoses) o Add documentation to the PCI api(Jani Monoses) o Fix inode.c documentation (Jani Monoses) o Push Davicom support into the main tulip driver (Tobias Ringstrom) o First block of mkiss driver fixes (Hans Grobler) o Fix bug in VFAT short name handling (Nicolas Goutte) o Clean up the i810 driver(Tjeerd Mulder) o RCPCI45 PCI cleanup fixes (mark 2) (Rasmus Andersen) o Improve the ALSxxx sound driver documentation (Jonathan Woithe) o Fix ext2 modular build (Jeff Raubitschek) o Fix bug in scripts/Configure.in matching(Matthew Wilcox) o Revert accidental amifb change (Geert Uytterhoeven) o Fix ext2 file size limiting for large files (Andreas Dilger) o Clean up misleading indenting in partition code (JAmes Antill) o Update SiS video drivers(Can-Ru Yeou) o Yamaha audio doc fix(Pavel Roskin) o Fix ACPI driver wakeup races(David Woodhouse) o Remove bogus asserts in 8139too driver (Jeff Garzik) o Fix timeout problms with rocktports at 249 days o Update acenic patches (Jes Sorensen) o Fix i810 tco locking(me) o Fix media makefiles (me) o Fix drm makefiles (Peter Samuelson) 2.4.0test12-ac1 adds o ARM bootup/initd fixes (Russell King) o Fix ymf_sb setup bug(Pavel Roskin) o Correctly print names of md10+ (me) [Based on code from Roberto Ragusa] o Fix sound crashes in various drivers(Tjeerd Mulder) o Update epic100 to new pci api (Francois Romieu) o Fix IOC/SIOC ioctl problems in ac97 code(Dick Streefland) To merge o Fix Ruffian Alpha boot (Ivan Kokshaysky) o Bridge handling patches needed for Alpha(Ivan Kokshaysky / Richard Henderson) o FPU emulator source set for m68k(Geert Uytterhoeven) o Fix m68k build with rmw disabled(Geert Uytterhoeven) o Cleanup ramdisk namespace (Jeff Garzik) o Link correctly with ACPI on ACPI_INTERPRETER off o Ramdisk missing blkdev_put o Acenic update o Epic100 update o Support mixed pnp and legacy sb cards o Hopefully fix the bugs in the FAT and HPFS file systems that caused fs corruption o Fix cramfs vanishing data bug o Fix NLS config.in bug for SMB o Power management locking fixes o
Re: Linus's include file strategy redux
In article <91gr99$bs81o$[EMAIL PROTECTED]> you write:
>
>[Dana Lacoste]
>> Essentially, whatever solution is implemented MUST ensure :
>>
>> 1 - glibc will work properly (the headers in /usr/include/* don't
>> change in an incompatible manner)
>>
>> 2 - programs that need to compile against the current kernel MUST
>> be able to do so in a quasi-predictable manner.
>
>(2) is bogus. NO program needs to compile against the current kernel
>headers. The only things that need to compile against the current
>kernel headers are kernel modules and perhaps libc itself.
Or userland libraries/applications that need to bypass libc and make
direct kernel calls because libc hasn't yet implemented those new
kernel calls.
>
>Peter
richard.
---
Richard Offer Widget FAQ --> http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux}
__http://reality.sgi.com/offer/
-
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: test13-pre3 woes
Olaf Titz wrote: > In article <[EMAIL PROTECTED]> you write: > > [J Sloan] > > > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range > >... > > Those symbols are rather generic and rather important. Sounds like a > > generic module problem. Do other modules load? Yes, rtl8139, emu10k are loaded and working fine. > Does your kernel use > > MODVERSIONS? Yes, I have CONFIG_MODVERSIONS=y > (This module apparently doesn't.) Are you using a recent > > version of modutils? # insmod -V insmod version 2.3.21 ... > The most important question: Did you run "make dep" after doing the patch? Yes, after the patch, it was, as always: make clean make menuconfig make dep bzlilo modules modules_install Same problem with 2.4.0-test13-pre3-ac1 on my Linux workstation at the office, where the token ring driver fails as well (olympic.o) BTW, in my experience to date with kernels from 2.3.36 up to 2.4.0-test-12 it has all worked well. jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test13-pre1 lockup: run_task_queue or tty_io are wrong
On Mon, 18 Dec 2000, Jamie Lokier wrote: > > > > Nope. > > > > There may be multiple concurrent run_task_queue's executing, so for now > > I've applied Andrew Morton's patch that most closely gets the old > > behaviour of having a private list. > > I wasn't clear. The sentinel is a local structure on the stack, and > only exists while run_task_queue is executing. Another name for this is > "deletion-safe pointer". Yes, except run_task_queue removes every object it finds. So two concurrent run_task_queues would be bad. Sure, we could just make it skip sentinels by adding a magic flag to them, but that is pretty ugly. 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: Startup IPI (was: Re: test13-pre3)
> Yeah. Just do not read video memory when another CPU starts. I'll try > disabling cache on both CPUs, maybe it will make some difference, as > secondary CPU should start with caches disabled. But maybe that it is > just broken AGP bus, and nothing else. But until I find what's really > broken on my hardware, I'd like to leave 'udelay(300)' in. In the case where it boots does it also report mismatched MTRRs ?? - 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][RFC] Converting drivers/net/rcpci45.c to new PCI API
Hi.
This is my attempt at converting the rcpci45 driver (240t13p2) to the new
PCI API interface. I fully expect to have missed something so please
comment away. BTW, I do not consider this the final version of this patch;
therefore the maintainers are not explicitly on the recipients lists.
There are some other cleanups I want to do, and I need to make my indentation
match the drivers, but that will be after the basic conversion is done.
--- linux-240-t13-pre1-clean/drivers/net/rcpci45.c Sat Nov 4 23:27:08 2000
+++ linux/drivers/net/rcpci45.c Thu Dec 14 21:41:17 2000
@@ -36,6 +36,8 @@
** Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
**
**
+** Rasmus Andersen, December 2000: Converted to new PCI API.
+**
** Pete Popov, January 11,99: Fixed a couple of 2.1.x problems
** (virt_to_bus() not called), tested it under 2.2pre5 (as a module), and
** added a #define(s) to enable the use of the same file for both, the 2.0.x
@@ -47,10 +49,6 @@
**
***/
-static char *version =
-"RedCreek Communications PCI linux driver version 2.02\n";
-
-
#include
#include
#include
@@ -75,6 +73,9 @@
#include
+static char version[] __initdata =
+"RedCreek Communications PCI linux driver version 2.03\n";
+
#define RC_LINUX_MODULE
#include "rclanmtl.h"
#include "rcif.h"
@@ -123,7 +124,6 @@
U32function;
struct timer_list timer;/* timer */
struct net_device_stats stats; /* the statistics structure */
-struct net_device *next;/* points to the next RC adapter */
unsigned long numOutRcvBuffers;/* number of outstanding receive buffers*/
unsigned char shutdown;
unsigned char reboot;
@@ -138,8 +138,6 @@
static PDPA PCIAdapters[MAX_ADAPTERS];
static int RCinit(struct net_device *dev);
-static int RCscan(void);
-static int RCfound_device(int, int, int, int, int, int);
static int RCopen(struct net_device *);
static int RC_xmit_packet(struct sk_buff *, struct net_device *);
@@ -155,71 +153,29 @@
static int RC_allocate_and_post_buffers(struct net_device *, int);
-/* A list of all installed RC devices, for removing the driver module. */
-static struct net_device *root_RCdev;
+static struct pci_device_id rcpci45_pci_table[] __devinitdata = {
+ { RC_PCI45_VENDOR_ID, RC_PCI45_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, },
+ { }
+};
+MODULE_DEVICE_TABLE(pci, rcpci_pci_table);
-static int __init rcpci_init_module (void)
+static void rcpci45_remove_one(struct pci_dev *pdev)
{
-int cards_found;
-
-cards_found = RCscan();
-if (cards_found)
-printk(version);
-return cards_found ? 0 : -ENODEV;
-}
+ struct net_device *dev = pdev->driver_data;
+ PDPA pDpa = dev->priv;
-static int RCscan(void)
-{
-int cards_found = 0;
-static int pci_index;
-
-if (!pcibios_present())
-return cards_found;
-
-for (;pci_index < 0x8; pci_index++)
-{
-unsigned char pci_bus, pci_device_fn;
-int scan_status;
-int board_index = 0;
-unsigned char pci_irq_line;
-unsigned int pci_ioaddr;
- struct pci_dev *pdev;
-
-scan_status =
-(pcibios_find_device (RC_PCI45_VENDOR_ID,
- RC_PCI45_DEVICE_ID,
- pci_index,
- _bus,
- _device_fn));
-#ifdef RCDEBUG
-printk("rc scan_status = 0x%X\n", scan_status);
-#endif
-if (scan_status != PCIBIOS_SUCCESSFUL ||
- !((pdev = pci_find_slot(pci_bus, pci_device_fn
-break;
- pci_irq_line = pdev->irq;
- pci_ioaddr = pci_resource_start (pdev, 0);
+if (!dev) {
+printk (KERN_ERR "remove non-existent device\n");
+return;
+}
-#ifdef RCDEBUG
-printk("rc: Found RedCreek PCI adapter\n");
-printk("rc: pci_bus = %d, pci_device_fn = %d\n", pci_bus, pci_device_fn);
-printk("rc: pci_irq_line = 0x%x \n", pci_irq_line);
-printk("rc: pci_ioaddr = 0x%x\n", pci_ioaddr);
-#endif
+ printk("IOP reset: 0x%x\n", RCResetIOP(pDpa->id));
- if (pci_enable_device(pdev))
- break;
- pci_set_master(pdev);
+ unregister_netdev(dev);
+ iounmap((void *)dev->base_addr);
+free_irq(dev->irq, dev);
-if (!RCfound_device(pci_ioaddr, pci_irq_line,
- pci_bus, pci_device_fn,
- board_index++, cards_found))
-cards_found++;
-}
-#ifdef RCDEBUG
-printk("rc: found %d cards \n", cards_found);
-#endif
-return cards_found;
+ kfree(dev);
}
static int RCinit(struct net_device *dev)
@@ -233,17 +189,22 @@
return 0;
}
-static int
-RCfound_device(int memaddr, int irq,
- int bus, int function, int product_index, int card_idx)
+static int
Re: APM/DPMS lockup on Dell 3800
This is a problem with the 3Com Ethernet card in your system. There are annoying problems when you try to use this card on a network with a lot of collisions. On Mon, 18 Dec 2000, David Feuer wrote: > BTW, what does it mean when this gets logged? > > Dec 17 19:01:09 localhost kernel: eth0: Resetting the Tx ring pointer. > Dec 17 19:01:09 localhost kernel: eth0: Tx Ring full, refusing to send > buffer. > > > - > 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/ > -- Andrew McNabb [EMAIL PROTECTED] http://www.mcnabbs.org/ - 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: PCMCIA modem (v.90 X2) not working with 2.4.0-test12 PCMCIA services
On Sat, Dec 16, 2000 at 05:52:30PM -0800, Miles Lane wrote: > register_serial(): autoconfig failed > serial_cs: register_serial() at 0x03e8, irq 3 failed. > > "cardctl ident" shows: > > Socket 1: > product info: "PCMCIA", "V.90 Communications Device ", "", "" > manfid: 0x018a, 0x0001 Have you tried, or could you try, using this card under a 2.2 kernel for comparison? Also, the first thing I'd try would be to exclude the irq 3, port 0x3e8-0x3ef resources in /etc/pcmcia/config.opts to verify that it is not a resource conflict of some sort. -- Dave - 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: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
> > No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
> > PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
>
> Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
> if accessing one bus or another changes the behaviour.
Uh. It took couple of hours to find it. Just place
{ int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i < 6553600;
i++) { *p; } }(**)
instead of udelay(300) and this loop does not finish. Same for
unsigned long* p. inb/outb(0x3C0) are ok. Writes are OK too. Only
simple fetches from videoram kills it.
When I replaced address with 0xC01B8000 (some cachable memory), it worked
fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
it is just set as cacheable in chipset), it works too.
Symptoms of lockup are same as hangup in printk() without udelay(300), only
problem is that 'vt_console_print' (*) does not do fetches from videoram, it
does stores only...
Placing this loop before sending startup IPI, or just below udelay(300)
is OK (modulo that this loop takes so long that secondary CPU complains
about no callin received).
I even tried to add:
mov $0xB800,%ax
mov %ax,%ds
movw %ax,0
at the beginning of trampoline.S, and then boot with 'no-scroll', but
character in upper left corner did not change, so secondary CPU probably
even did not start code fetches. That's all I can say until
I put non-AGP card into the box (but I need AGP, so it is not real option).
> > and VT82C686 (rev 22) ISA bridge. I tried to request documentation
> > of 694X from VIA, but I did not heard from them. They have probably
> > some secrets hidden in their hardware...
>
> They wan't to keep the competition from being bug-compatible, it would
> seem...
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else. But until I find what's really
broken on my hardware, I'd like to leave 'udelay(300)' in.
(*) When I was calling directly
vt_console_print(NULL, "Message1\n", 9);
vt_console_print(NULL, "Message2\n", 9);
instead of printk, I got
Message1
Messag<0x..><0x..><0x00><0x80><0x..><0x80><0x..><0x80>...
- wrong text with wrong length, so it probably started fetching garbage
instead of string as soon as second CPU started (no, it did not race due
to missing console_lock; before first printk() secondary CPU should fill
whole screen with letter '2'. It did not).
(**) When I had '*p = i; *p' in loop, from visual inspection it was
dying in range i=0x1380-0x13FF (blue background, cyan letter with diacritics).
End of guessing.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 vs Inspiron
On 17 Dec 2000 05:07:01 -0600, Peter Samuelson wrote: > > [James Simmons] > > Ah the infamous Rage Mobility chipset. Three versions of the same > > chipset but each is very different. > > I knew it was bad when ATI refuses to publish Windows drivers -- they > basically say "get drivers from your laptop vendor, there is *no* > generic driver that works for everyone". That's not entirely correct. True enough, they have a very confusing naming scheme, but that shouldn't set us back too far. Rage Mobility/M1 = Mach64 M3 = Rage128 M4 = Radeon For ATI's Mach64 based cards, they chose to let the vendor pick the DAC that best suited their needs. While this is good from an economical perspective, it caused massive support headaches. Needless to say, ATI no longer uses this model. It's not that they refused to publish drivers, they just screwed themselves out of being able to. Brad Douglas [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: APM bug with Inspiron 5000e
On 16 Dec 2000 23:05:45 -0500, wrote: > > I am seeing this bug with both test8 and test12 kernels. Help/suggestions > for debugging are appreciated. > > Computer: Inspiron 5000e. > Bug: oops when doing cat /proc/apm. > > Vladimir Dergachev What's the BIOS revision it claims to have during POST? It should be A0x (where x is a number). Thanks, Brad Douglas [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: generic sleeping locks?
Alan Cox wrote: > > > Are there blocking lock primitives already defined somewhere in the > > kernel? > > down and up are normally appropriate for this Ungh. Forest. Trees. *sigh* Sorry for the dumb question. Thanks for the reply Alan. :) Ok, second part of the question: What about blocking read/write locks (with _interruptible variants)? TIA, Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - 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.4.0test13pre3ac1
On Mon, 18 Dec 2000, Alan Cox wrote: > o Fix leak in link() syscall (Al Viro) ^^^ Originally - by Christopher Yeoh. - 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: generic sleeping locks?
> Are there blocking lock primitives already defined somewhere in the > kernel? down and up are normally appropriate for this - 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-test13-pre3 m68k Makefiles
This patch updates the Makefiles used by Linux/m68k to the new Makefile syntax. Additionally I fixed a bug in arch/ppc/amiga/Makefile (for APUS). --- linux-2.4.0-test13-pre3/MakefileMon Dec 18 12:34:22 2000 +++ linux-m68k-test13-pre3/Makefile Mon Dec 18 12:40:50 2000 @@ -159,7 +159,7 @@ DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o DRIVERS-$(CONFIG_DIO) += drivers/dio/dio.a DRIVERS-$(CONFIG_SBUS) += drivers/sbus/sbus_all.o -DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/zorro.a +DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/driver.o DRIVERS-$(CONFIG_FC4) += drivers/fc4/fc4.a DRIVERS-$(CONFIG_ALL_PPC) += drivers/macintosh/macintosh.o DRIVERS-$(CONFIG_MAC) += drivers/macintosh/macintosh.o --- linux-2.4.0-test13-pre3/arch/m68k/amiga/MakefileThu Jul 30 20:08:19 1998 +++ linux-m68k-test13-pre3/arch/m68k/amiga/Makefile Mon Dec 18 12:53:58 2000 @@ -8,11 +8,11 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := amiga.o -O_OBJS := config.o amiints.o cia.o chipram.o amisound.o -OX_OBJS := amiga_ksyms.o -ifdef CONFIG_AMIGA_PCMCIA -O_OBJS := $(O_OBJS) pcmcia.o -endif +export-objs:= amiga_ksyms.o + +obj-y := config.o amiints.o cia.o chipram.o amisound.o amiga_ksyms.o + +obj-$(CONFIG_AMIGA_PCMCIA) += pcmcia.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/apollo/Makefile Tue Feb 8 11:04:33 2000 +++ linux-m68k-test13-pre3/arch/m68k/apollo/MakefileMon Dec 18 12:57:03 2000 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := apollo.o -O_OBJS := config.o dn_ints.o dma.o \ +obj-y := config.o dn_ints.o dma.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/atari/MakefileTue Feb 8 11:04:33 2000 +++ linux-m68k-test13-pre3/arch/m68k/atari/Makefile Mon Dec 18 12:54:27 2000 @@ -8,14 +8,14 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := atari.o -O_OBJS := config.o time.o debug.o atakeyb.o ataints.o stdma.o atasound.o \ -joystick.o stram.o -OX_OBJS := atari_ksyms.o + +export-objs:= atari_ksyms.o + +obj-y := config.o time.o debug.o atakeyb.o ataints.o stdma.o \ + atasound.o joystick.o stram.o atari_ksyms.o ifdef CONFIG_PCI -ifdef CONFIG_HADES -O_OBJS += hades-pci.o -endif +obj-$(CONFIG_HADES)+= hades-pci.o endif include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/bvme6000/Makefile Sat Jun 13 22:14:31 1998 +++ linux-m68k-test13-pre3/arch/m68k/bvme6000/Makefile Mon Dec 18 12:54:32 2000 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := bvme6000.o -O_OBJS := config.o bvmeints.o rtc.o -#OX_OBJS = ksyms.o + +obj-y := config.o bvmeints.o rtc.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/hp300/MakefileWed Sep 2 18:39:18 1998 +++ linux-m68k-test13-pre3/arch/m68k/hp300/Makefile Mon Dec 18 12:54:43 2000 @@ -8,10 +8,11 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := hp300.o -O_OBJS := ksyms.o config.o ints.o time.o reboot.o -ifdef CONFIG_VT -O_OBJS += hil.o -endif +export-objs:= ksyms.o + +obj-y := ksyms.o config.o ints.o time.o reboot.o + +obj-$(CONFIG_VT) += hil.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/kernel/Makefile Thu Apr 13 21:17:11 2000 +++ linux-m68k-test13-pre3/arch/m68k/kernel/MakefileMon Dec 18 12:54:58 2000 @@ -17,13 +17,13 @@ endif O_TARGET := kernel.o -O_OBJS := entry.o process.o traps.o ints.o signal.o ptrace.o \ - sys_m68k.o time.o semaphore.o -OX_OBJS := setup.o m68k_ksyms.o -ifdef CONFIG_PCI -O_OBJS += bios32.o -endif +export-objs:= setup.o m68k_ksyms.o + +obj-y := entry.o process.o traps.o ints.o signal.o ptrace.o \ + sys_m68k.o time.o semaphore.o setup.o m68k_ksyms.o + +obj-$(CONFIG_PCI) += bios32.o head.o: head.S m68k_defs.h --- linux-2.4.0-test13-pre3/arch/m68k/lib/Makefile Thu Dec 14 12:14:15 2000 +++ linux-m68k-test13-pre3/arch/m68k/lib/Makefile Mon Dec 18 12:55:09 2000 @@ -6,6 +6,8 @@ $(CC) $(AFLAGS) -traditional -c $< -o $@ L_TARGET = lib.a -L_OBJS = ashrdi3.o lshrdi3.o checksum.o memcpy.o memcmp.o memset.o semaphore.o muldi3.o + +obj-y := ashrdi3.o lshrdi3.o checksum.o memcpy.o memcmp.o memset.o \ + semaphore.o muldi3.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/mac/Makefile Tue Feb 15 21:49:28 2000 +++ linux-m68k-test13-pre3/arch/m68k/mac/Makefile Mon Dec 18 12:55:22 2000 @@ -8,8 +8,10 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := mac.o -OX_OBJS := mac_ksyms.o -O_OBJS := config.o bootparse.o macints.o iop.o via.o oss.o psc.o \ - baboon.o macboing.o debug.o misc.o + +export-objs:= mac_ksyms.o + +obj-y :=
generic sleeping locks?
Allow me to display my ignorance a moment. Are there blocking lock primitives already defined somewhere in the kernel? It just seems that while( lockvar ) sleep_on( ); along with its various permutations would be commonly used and worthy of being made into a generic sleep lock. A few blind greps through the source didn't find anything that caught my eye. If there aren't, would a patch to add them be of interest to anyone? Input on design details welcome. TIA, Eli . "To the systems programmer, users and applications Eli Carter | serve only to provide a test load." [EMAIL PROTECTED] `-- (random fortune) - 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/
[ANNOUNCE] Powertweak v0.99.0
v0.99.0 of the system performance tuning tool "Powertweak" is released. Available from http://powertweak.sourceforge.net This release brought about a complete rewrite. Some of the major changes since the last public release are... - Should now work on all architectures. (Tested on ia32/Sparc/Alpha/PPC) - By default, Powertweak now starts as a daemon that should be run on bootup. (Old behaviour still possible with --no-daemon) The GUI now communicates with the daemon instead of doing the tweaking itself. - Backends are now completely modular plugin libraries. This allowed for easier cross-platform usage, and a cleaner API. - Profiles. Tell Powertweak "This is a webserver" and have it auto-tune. - Rewritten /proc/sys tuning backend. - PCI backend now uses XML files to describe tweaks. Several chipsets added since 0.1.17 release. - Addition of a disk elevator tuning backend. - CPU register tuning is now possible, as long as you have the cpuid/msr drivers in your kernel (2.2.18, or 2.4.0test) - Working text mode user interface. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | 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: /dev/random: really secure?
> This would allow you to say "eth0 is my internal network and I'm not > trying to hack my own system, so use IP traffic on that interface to add > entropy to the pool, but not packets that are on port 6699/21/23 or reply > packets". It would probably just be a matter of adding a new flag to a > filter rule to say "use packets that match this rule for entropy", and > then it is up to the user to determine what is safe to use. The fact > that it is user configurable makes it even harder for a cracker to know > what affects the entropy pool. This isn't from the kernel, but works great in userspace: iptables -n RANDOM iptables -A INPUT -i eth0 -j RANDOM iptables -A RANDOM -p tcp --dport 6699 -j iptables -A RANDOM -p tcp --dport 21 -j iptables -A RANDOM -p tcp --dport 32 -j iptables -A RANDOM -m state --state ! NEW -j iptables -P RANDOM -j ULOG --ulog-nlgroup 32 This sends a message down netlink in ULOG format. ULOG is a userspace logging extension written by Harald Welte, but it's extensible like you wouldn't believe, so you could easily do some whacky stuff with it. Or just hook in to a Netfilter hook and do it all from kernel land. ULOG's homepage: http://www.gnumonks.org/gnumonks/projects/project_details?p_id=1 :) d - 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: /dev/random: really secure?
Jamie Lokier <[EMAIL PROTECTED]> writes: > > A potential weakness. The entropy estimator can be manipulated by > > feeding data which looks random to the estimator, but which is in fact > > not random at all. Ted Ts'o replied: > Yes, absolutely. That's why you have to be careful before you make > changes to the kernel code to feed additional data to the estimator. > *Usually* relying on interrupt timing is safe, but not always. For > example, an adversary can observe, and in some cases control the > arrivial of network packets which control the network card's interrupt > timings. Is it enough to be able to predict with cpu-counter > resolution the inputs to the /dev/random pool? Maybe; it depends on how > paranoid you are. I think that for the case of dedicated firewall/IPSec machines, it _should_ be possible to generate some entropy from network packets, because this may be the only place where they get any activity (no keyboard/mouse/disk). Given the fact we are dealing with a router, there shouldn't be any way one person can control all of the network traffic to/through/from the router, and if they can you probably have another security problem entirely. Maybe a hook into the ipchains/netfilter code to allow selecting only traffic from certain interfaces, and discarding "repeat" source and/or destination addresses or packets arriving less than X ticks apart, just like we discard repeated keystrokes. The larger X is, the harder it is to estimate the low-order bits on the timers when a packet arrives. This would allow you to say "eth0 is my internal network and I'm not trying to hack my own system, so use IP traffic on that interface to add entropy to the pool, but not packets that are on port 6699/21/23 or reply packets". It would probably just be a matter of adding a new flag to a filter rule to say "use packets that match this rule for entropy", and then it is up to the user to determine what is safe to use. The fact that it is user configurable makes it even harder for a cracker to know what affects the entropy pool. Cheers, Andreas -- 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: ANNOUNCE: Linux Kernel ORB: kORBit
> > Imagine that kpiod is slow. try_to_swap_out returns 1 and pretends it > > freed something but it didn't. It just passed request to kpiod. There are > > no pages to be freed by shrink_mmap. do_try_to_swap_out calls swap_out > > several times, then returns. And this repeats again and again. > > kpiod ceased to exist as of 2.2.19pre2 BTW. why didn't you fix SMP race in accessing pte? It's several months old and quite subtle bug. Mikulas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
> Imagine that kpiod is slow. try_to_swap_out returns 1 and pretends it > freed something but it didn't. It just passed request to kpiod. There are > no pages to be freed by shrink_mmap. do_try_to_swap_out calls swap_out > several times, then returns. And this repeats again and again. kpiod ceased to exist as of 2.2.19pre2 - 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: usb broken in 2.4.0 test 12 versus 2.2.18
On Mon, Dec 18, 2000 at 04:33:26PM -0500, Heitzso wrote: > I have a Canon usb camera that I access via a > recent copy of the s10sh program (with -u option). > > Getting to the camera via s10sh -u worked through > large sections of 2.4.0 test X but broke recently. > I cannot say for certain which test/patch the > break occurred in. It works for me (s100), at least on my laptop. I do note that it gives timeouts if the computer is busy otherwise. gphoto2 isn't able to retrieve images using recent 2.4.0testX kernels, I haven't tried earlier kernels yet. It is able to list filenames though. Regards, bert hubert -- PowerDNS Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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: /dev/random: really secure?
> David Schwartz wrote: > > The code does its best to estimate how much actual entropy it > > is gathering. > A potential weakness. The entropy estimator can be manipulated by > feeding data which looks random to the estimator, but which is in fact > not random at all. > -- Jamie Sort of, but not really. You are correct to the extent that it's possible for someone to make the RNG think it has somewhat more actualy entropy than it actually has. However, you can't directly feed seeds into the RNG anyway without root access. The process of feeding those seeds into the RNG would inject some actual entropy at the same time. And so long as the RNG was ever properly seeded, it will always produce cryptographically secure random numbers no matter what. Even if it's not properly seeded, it doesn't take long before the machine accumulates enough entropy to be cryptographically secure. So there is only a brief window of vulnerability after the machine is started and before it has accumulated sufficient entropy. During that window, the amount of entropy present might be underestimated. The simple fix is for programs that really need good entropy to be extra conservative within a few minutes of startup. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 18 Dec 2000, Rik van Riel wrote: > On Mon, 18 Dec 2000, Andrea Arcangeli wrote: > > On Mon, Dec 18, 2000 at 06:29:24PM -0200, Rik van Riel wrote: > > > Wrong. Getblk won't deadlock, it will just sleep and another > > > > getblk will deadlock. > > OUCH. The only protection we have against this is the fact > that atomic allocations are not allowed to eat up all memory > in the system and that every thread can only have 1 getblk > operation at a time, right? You have small posibility that interrupt will eat up memory - interrupt in process that has PF_MEMALLOC. Patch: --- linux/mm/page_alloc.c_ Mon Dec 18 22:48:47 2000 +++ linux/mm/page_alloc.c Mon Dec 18 22:53:52 2000 @@ -516,7 +516,7 @@ /* XXX: is pages_min/4 a good amount to reserve for this? */ if (z->free_pages < z->pages_min / 4 && - !(current->flags & PF_MEMALLOC)) + (!(current->flags & PF_MEMALLOC) || in_interrupt())) continue; page = rmqueue(z, order); if (page) Mikulas - 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/
PROBLEM: mounting affs over loop hangs in syscall (x86 only?)
[1.] One line summary of the problem:
mounting affs over loop hangs in syscall (x86 only?)
[2.] Full description of the problem/report:
Mounting a valid Amiga Fast File System hard disk image used
to work fine even on x86 (endianity discords with m68k) back
in 2.2.x.
On 2.4.0-test11 (and possibily previous versions as well), this
command hangs forever:
mount -t affs -o loop work.img /mnt
The mount process hangs in uninterruptable syscall:
# ps ax | grep mount
3904 pts/4DL 0:00 mount -t affs -o loop work.img /mnt
Reading directly from /proc/3904/stat:
3904 (mount) D 1398 3904 1398 34820 3904 256 16 0 119 0 0 5 0 \
0 9 0 0 0 43136018 1396736 341 4294967295 134512640 134568236 \
3221223064 3221222424 1074833310 524294 2147220207 0 0 \
3222489067 0 0 17 0
After this, other program can still do open("work.img" ,"r"), but
UAE hanged like mount when accessing the file (perhaps it tried
an mmap() on it?):
# ps ax | grep uae
8048 pts/1D 0:00 ./uae
I recall trying to mount an affs image some months ago (2.3.xx) and
having the very same problem, so it's not a recently introduced bug.
[3.] Keywords (i.e., modules, networking, kernel):
kernel, filesystems, amiga, affs, loop, mount, partition
[4.] Kernel version (from /proc/version):
Linux version 2.4.0-test12 (root@beetle) (gcc version 2.96 2731 \
(Red Hat Linux 7.0)) #2 Wed Dec 13 00:24:27 CET 2000
[5.] Output of Oops.. message
No OOPSes are printed, no useful debug messages appear in
dmesg output.
[6.] A small shell script or example program which triggers the
problem (if possible)
Get an Amiga Fast File System image. If you don't have one handy,
you can create a file of a few MBs and use UAE to format it.
Amiga floppy disk images (.adf files) might trigger the problem
too (untested).
Then use this command to mount it:
mount -t affs -o loop my_amiga_hd.img /mnt
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
mount: mount-2.10r
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 2
model name : AMD Athlon(tm) Processor
stepping: 1
cpu MHz : 700.050
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36
mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1395.92
[7.3.] Module information (from /proc/modules):
affs 31472 1
loop7840 2
emu10k143456 1
soundcore 3824 4 [emu10k1]
r128 147920 1
vmnet 18240 3
vmmon 18480 0
ipt_REJECT 2080 6 (autoclean)
iptable_filter 1824 0 (autoclean) (unused)
ip_nat_ftp 3184 0 (unused)
ip_conntrack_ftp2016 0 (unused)
iptable_nat12864 1 [ip_nat_ftp]
ip_conntrack 12800 2 [ip_nat_ftp ip_conntrack_ftp iptable_nat]
ip_tables 10304 5 [ipt_REJECT iptable_filter iptable_nat]
8139too15392 1
agpgart13328 3
af_packet 11200 2 (autoclean)
ppp_async 6352 1
ppp_generic12928 3 [ppp_async]
slhc5040 0 [ppp_generic]
autofs4 9824 2
ne2k-pci4672 1 (autoclean)
83906080 0 (autoclean) [ne2k-pci]
nls_iso8859-1 2880 1 (autoclean)
nls_cp437 4384 1 (autoclean)
vfat 11408 1 (autoclean)
fat31264 0 (autoclean) [vfat]
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
not relevant
[7.5.] PCI information ('lspci -vvv' as root)
not relevant
[7.6.] SCSI information (from /proc/scsi/scsi)
not relevant
[7.7.] Other information that might be relevant to the problem
no mount points are added to /proc/mounts before the syscall
hangs.
NOTE: when replying to this message, please also Cc: to me,
as I'm not subscribed to this mailing list.
ALSO NOTE: I'm willing to cooperate with whoever wants to
fix this bug. I'll give all the assistance I can, including
running debug versions of kernel modules, providing the
FFS images that trigger the problem and giving shell access
to my system for deeper inspection.
--
// Bernardo Innocenti
\X/ http://www.codewiz.org
-
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.4.0test13pre3ac1
> On Mon, 18 Dec 2000, Alan Cox wrote: > > o Teach kernel-doc about const(Jani Monoses) > > Tim Waugh pointed out this wasn't good as 'const' is part of the function > signature and he now has a better patch. > For these I've sent Tim more cleaned up patches as I thought nobody picked > them up from the list.Looks like I was wrong ;-) Thanks for the info. I'll pick up the changes when Tim sends them on - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 18 Dec 2000, Rik van Riel wrote: > On Sat, 16 Dec 2000, Mikulas Patocka wrote: > > > > Not unless your driver is broken. > > > > ok_to_allocate: > > *** INTERRUPT > > spin_lock_irqsave(_alloc_lock, flags); > > /* if it's not a dma request, try non-dma first */ > > if (!(gfp_mask & __GFP_DMA)) > > RMQUEUE_TYPE(order, 0); > > RMQUEUE_TYPE(order, 1); > > spin_unlock_irqrestore(_alloc_lock, flags); > > > > nopage: > > return 0; > > } > > Now read the code carefully and see how allocations can > end up here ... and when they can't... GFP_ATOMIC allocations can eat all memory in 2.2. There are no free pages. Now process wants to allocate page with GFP_KERNEL or GFP_USER. It calls try_to_free_pages. try_to_free_pages succeeds and frees few pages. Interrupt is received and eats pages that were just freed. RMQUEUE fails. get_free_page returns zero. Process is shot. > > Deadlock in getblk, if memory is full of dirty file mapped pages. > > Wrong. Getblk won't deadlock, it will just sleep and another > thread will continue later on. Killing processes will (in 2.4) > only happen when you run out of swap ... 2.4 will simply have > its processes loop in alloc_pages() until memory is available. I'm talking about 2.2. getblk will sleep until some memory becomes available. And some memory can be available only if getblk succeeds. > > You actually do not need network flood to kill your box. Just imagine that > > kpiod is swapping files out too slowly, free memory is going lower and > > lower, every process screaming with "VM: do_try_to_free_pages failed" and > > the system is aproaching instant death. > > Umm? Can you explain how this could happen? Imagine that kpiod is slow. try_to_swap_out returns 1 and pretends it freed something but it didn't. It just passed request to kpiod. There are no pages to be freed by shrink_mmap. do_try_to_swap_out calls swap_out several times, then returns. And this repeats again and again. There are two possible ends: -swap_out unmaps everything and fails (all pages are pending on kpiod queue), try_to_free_pages fails, process is shot -as try_to_free_pages is pretending that it freed something, free memory is going lower and lower; finally it reaches zero - see above Mikulas - 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: usb broken in 2.4.0 test 12 versus 2.2.18
On Mon, Dec 18, 2000, Heitzso <[EMAIL PROTECTED]> wrote: > I have a Canon usb camera that I access via a > recent copy of the s10sh program (with -u option). > > Getting to the camera via s10sh -u worked through > large sections of 2.4.0 test X but broke recently. > I cannot say for certain which test/patch the > break occurred in. > > Running 2.4.0 test12 malloc errors appear. > Everything is fine with 2.2.18. I haven't tried > the test13 series of patches. > > key .config options: > CONFIG_USB on > DEVICEFS on > HOTPLUG on > UHCI on > everything else off (i.e. printers, keyboards, > mice, etc.). > > Baseline system is RH6.2 with most patches applied > (so avoiding RH7 compiler problems). Basic dev > environment is same (i.e. compiling the two kernels > on the same box). > > If someone wants to email me a debug sequence or > ask more specific questions feel free. Could you give us the exact error message you saw? 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: Disabling interrupts in 2.4.x
> I would expect this function to disable interrupts, but given the scale of > change between 2.2.x spinlock.h and 2.4.x spinlock.h I'm just not sure > anymore. spin_lock_irqsave disables interrupts but only on the CPU that the lock is taken. - 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/
usb broken in 2.4.0 test 12 versus 2.2.18
I have a Canon usb camera that I access via a recent copy of the s10sh program (with -u option). Getting to the camera via s10sh -u worked through large sections of 2.4.0 test X but broke recently. I cannot say for certain which test/patch the break occurred in. Running 2.4.0 test12 malloc errors appear. Everything is fine with 2.2.18. I haven't tried the test13 series of patches. key .config options: CONFIG_USB on DEVICEFS on HOTPLUG on UHCI on everything else off (i.e. printers, keyboards, mice, etc.). Baseline system is RH6.2 with most patches applied (so avoiding RH7 compiler problems). Basic dev environment is same (i.e. compiling the two kernels on the same box). If someone wants to email me a debug sequence or ask more specific questions feel free. [EMAIL PROTECTED] Heitzso - 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: /dev/random: really secure?
Date:Mon, 18 Dec 2000 21:38:01 +0100 From: Jamie Lokier <[EMAIL PROTECTED]> David Schwartz wrote: > The code does its best to estimate how much actual entropy it is gathering. A potential weakness. The entropy estimator can be manipulated by feeding data which looks random to the estimator, but which is in fact not random at all. Yes, absolutely. That's why you have to be careful before you make changes to the kernel code to feed additional data to the estimator. *Usually* relying on interrupt timing is safe, but not always. For example, an adversary can observe, and in some cases control the arrivial of network packets which control the network card's interrupt timings. Is it enough to be able to predict with cpu-counter resolution the inputs to the /dev/random pool? Maybe; it depends on how paranoid you are. Note that writing to /dev/random does *not* update the entropy estimate, for this very reason. The assumption is that inputs to the entropy estimator have to be trusted, and since /dev/random is typically world-writeable, it is not so trusted. - Ted - 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/
SerialATA Release, sortof........
FYI The Serial ATA specification (500 pages) is now available to the public under certain "click-to-accept" conditions. Click the "specification" link at the bottom of the home page at http://www.serialata.org/. I hope the conditions are acceptable. The file is zipped MS Word. This just for those that care...please do not ask me for my copy as I am a member of this working group and bound under the NDA. Regards, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development - 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/
QLogicFC problems with 2.4.x?
Hi, I was just lent a QLogic ISP2200 FC adapter and have been having a bear of a time trying to get it to work on my Alpha ES40 and GS80. I've tried both the qlogicfc (with standard kernel) and qla2x00 (from QLogic and Compaq) driver both built-in and as modules but neither of them are working. Has anyone had success with later (I'm using 2.4.0-test11) 2.4 kernels and the QLogic FC adapter? I'm currently plugged into a Brocade switch (Plaides I, I believe) which is also attached to two pair of HSG80 FC RAID controllers. AFAIK, the 2200 is supposed to work with an FC fabric, so this should work, right? Can anyone offer any assistance? Thanks! - Pete - 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/
phtreads program causes massive ctx switches in 2.4, not in 2.2
Problem summary: use of localtime_r glibc function causes massive
context switching on kernel 2.4, but not on 2.2, leading to ctx switch
rates of >5/sec (!) on my Athlon 700 mhz. In 2.2 ctx switch rates
are < 1000. (according to vmstat).
I don't know if this is a kernel bug, or a glibc bug, so I'm submitting
it to both places. It's a stupid program, granted, because it's
computing invalid (stupid) data. But the problem it exhibits is real
(scenario extracted from actual application). As the subject indicates,
this only occurs in 2.4 kernels.
My system:
Kernel is 2.4.0-test13-pre3 or 2.2.18. Glibc is glibc-2.1.3-15 (RedHat
RPM).
Uniprocessor Athlon 700mhz.
Also tested on:
glibc-2.1.2-11 (RedHat RPM) with kernel 2.2.15 and it doesn't have the
problem, consistent with kernel 2.4 being the culprit.
Here's the program:
-- cut --
#define _REENTRANT
#include
#include
#include
int foo = 0;
void * func(void * arg)
{
while(1) {
struct tm tm;
localtime_r((time_t*), );
foo += tm.tm_sec;
}
}
main()
{
pthread_t t;
pthread_create(, NULL, func, NULL);
func(NULL);
}
--- cut
Strace only shows a bunch of rt_sigsuspend, kill, sigreturn that I can't
really decipher (then again, I'm skeptical that strace and pthreads work
together):
<... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system
call)
sigreturn() = ? (mask now [])
kill(2030, SIGRT_0) = 0
rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
rt_sigsuspend([]
--- SIGRT_0 (Real-time signal 0) ---
Any ideas?
David Mansfield
Ultramaster Group, LLC.
[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: Linux 2.4.0test13pre3ac1
On Mon, Dec 18, 2000 at 07:40:03PM +, Alan Cox wrote:
> o Add documentation to the PCI api(Jani Monoses)
Needs this:
--- linux-2.4.0test13pre3-ac1/drivers/pci/pci.c.pcidoc Mon Dec 18 20:46:08 2000
+++ linux-2.4.0test13pre3-ac1/drivers/pci/pci.c Mon Dec 18 20:51:20 2000
@@ -73,7 +73,7 @@
* found with a matching @vendor, @device, @ss_vendor and @ss_device, a pointer to its
* device structure is returned. Otherwise, %NULL is returned.
* A new search is initiated by passing %NULL to the @from argument.
- * Otherwise if @from is not %NULL, searches continue from that point.
+ * Otherwise if @from is not %NULL, searches continue from next device on the global
+list.
*/
struct pci_dev *
pci_find_subsys(unsigned int vendor, unsigned int device,
@@ -105,7 +105,7 @@
* found with a matching @vendor and @device, a pointer to its device structure is
* returned. Otherwise, %NULL is returned.
* A new search is initiated by passing %NULL to the @from argument.
- * Otherwise if @from is not %NULL, searches continue from that point.
+ * Otherwise if @from is not %NULL, searches continue from next device on the global
+list.
*/
struct pci_dev *
pci_find_device(unsigned int vendor, unsigned int device, const struct pci_dev *from)
@@ -123,7 +123,7 @@
* found with a matching @class, a pointer to its device structure is
* returned. Otherwise, %NULL is returned.
* A new search is initiated by passing %NULL to the @from argument.
- * Otherwise if @from is not %NULL, searches continue from that point.
+ * Otherwise if @from is not %NULL, searches continue from next device on the global
+list.
*/
struct pci_dev *
pci_find_class(unsigned int class, const struct pci_dev *from)
@@ -370,7 +370,7 @@
*
* Adds the driver structure to the list of registered drivers
* Returns the number of pci devices which were claimed by the driver
- * during registration
+ * during registration.
*/
int
pci_register_driver(struct pci_driver *drv)
@@ -392,7 +392,7 @@
*
* Deletes the driver structure from the list of registered PCI drivers,
* gives it a chance to clean up and marks the devices for which it
- * was responsible as driverless
+ * was responsible as driverless.
*/
void
@@ -461,7 +461,7 @@
* @dev: the device to insert
* @bus: where to insert it
*
- * Add a new device to the device lists and notify userspace (/sbin/hotplug)
+ * Add a new device to the device lists and notify userspace (/sbin/hotplug).
*/
void
pci_insert_device(struct pci_dev *dev, struct pci_bus *bus)
@@ -500,7 +500,7 @@
* @dev: the device to remove
*
* Delete the device structure from the device lists and
- * notify userspace (/sbin/hotplug)
+ * notify userspace (/sbin/hotplug).
*/
void
pci_remove_device(struct pci_dev *dev)
@@ -532,7 +532,7 @@
* @dev: the device to query
*
* Returns the appropriate pci_driver structure or %NULL if there is no
- * registered driver for the device
+ * registered driver for the device.
*/
struct pci_driver *
pci_dev_driver(const struct pci_dev *dev)
@@ -590,7 +590,7 @@
* @dev: the PCI device to enable
*
* Enables bus-mastering on the device and calls pcibios_set_master()
- * to do the needed arch specific settings
+ * to do the needed arch specific settings.
*/
void
pci_set_master(struct pci_dev *dev)
@@ -940,7 +940,7 @@
* vendor,class,memory and IO-space addresses,IRQ lines etc.
* Called at initialisation of the PCI subsystem and by CardBus services.
* Returns 0 on success and -1 if unknown type of device (not normal, bridge
- * or CardBus)
+ * or CardBus).
*/
int pci_setup_device(struct pci_dev * dev)
{
Tim.
*/
-
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.4.0test13pre3ac1
On Mon, Dec 18, 2000 at 07:40:03PM +, Alan Cox wrote:
> o Teach kernel-doc about const(Jani Monoses)
Needs this (also cleans up kernel-doc macro handling and fixes some
regexps):
--- linux-2.4.0test13pre3-ac1/scripts/kernel-docMon Dec 18 20:46:11 2000
+++ linux-2.4.0-test13-pre3+/scripts/kernel-doc Mon Dec 18 16:56:36 2000
@@ -668,23 +668,42 @@
sub dump_function {
my $prototype = shift @_;
-$prototype =~ s/^const+ //;
-$prototype =~ s/^static+ //;
-$prototype =~ s/^extern+ //;
-$prototype =~ s/^inline+ //;
-$prototype =~ s/^__inline__+ //;
-$prototype =~ s/^#define+ //; #ak added
+$prototype =~ s/^static +//;
+$prototype =~ s/^extern +//;
+$prototype =~ s/^inline +//;
+$prototype =~ s/^__inline__ +//;
+$prototype =~ s/^#define +//; #ak added
+
+# Yes, this truly is vile. We are looking for:
+# 1. Return type (may be nothing if we're looking at a macro)
+# 2. Function name
+# 3. Function parameters.
+#
+# All the while we have to watch out for function pointer parameters
+# (which IIRC is what the two sections are for), C types (these
+# regexps don't even start to express all the possibilities), and
+# so on.
+#
+# If you mess with these regexps, it's a good idea to check that
+# the following functions' documentation still comes out right:
+# - parport_register_device (function pointer parameters)
+# - atomic_set (macro)
+# - pci_match_device (long return type)
if ($prototype =~ m/^()([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
$prototype =~ m/^(\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
$prototype =~ m/^(\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
$prototype =~ m/^(\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
$prototype =~ m/^(\w+\s+\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
+ $prototype =~ m/^(\w+\s+\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
+ $prototype =~ m/^(\w+\s+\w+\s+\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\(]*)\)/ ||
$prototype =~ m/^()([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
$prototype =~ m/^(\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
$prototype =~ m/^(\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
$prototype =~ m/^(\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
- $prototype =~ m/^(\w+\s+\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/) {
+ $prototype =~ m/^(\w+\s+\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
+ $prototype =~ m/^(\w+\s+\w+\s+\w+)\s+([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/ ||
+ $prototype =~ m/^(\w+\s+\w+\s+\w+\s*\*)\s*([a-zA-Z0-9_~:]+)\s*\(([^\{]*)\)/) {
$return_type = $1;
$function_name = $2;
$args = $3;
@@ -729,13 +748,13 @@
$param="...";
$parameters{"..."} = "variable arguments";
}
- if ($type eq "")
+ elsif ($type eq "" && $param eq "")
{
$type="";
$param="void";
$parameters{void} = "no arguments";
}
-if ($parameters{$param} eq "") {
+if ($type ne "" && $parameters{$param} eq "") {
$parameters{$param} = "-- undescribed --";
print STDERR "Warning($file:$lineno): Function parameter '$param' not
described in '$function_name'\n";
}
-
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: taskfs and kernfs
Alexander Viro writes: > On Sun, 5 Nov 2000, Dave Zarzycki wrote: >> On Sun, 5 Nov 2000, Alexander Viro wrote: >> >>> However, kernfs is _not_ procfs \setminus procfs-proper. It's our current >>> /proc/sys. >> >> Okay. I didn't realize that's what you had in mind when you wrote >> "kernfs." Mind if I ask why you didn't call it "sysctlfs" or "sysfs?" > > Check *BSD. Meanwhile, the FreeBSD people seem to be about to junk kernfs. One is supposed to use sysctl. (freebsd-hackers or freebsd-arch just this week) I didn't know penguins went dumpster diving in Satan's trash. - 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.4.0test13pre3ac1
On Mon, Dec 18, 2000 at 07:40:03PM +, Alan Cox wrote: > o Mark the parport fifo code as experimental (Tim Waugh) Needs this: --- linux-2.4.0test13pre3-ac1/drivers/parport/Config.in Mon Dec 18 20:45:54 2000 +++ linux-2.4.0-test13-pre3+/drivers/parport/Config.in Mon Dec 18 16:56:36 2000 @@ -12,8 +12,8 @@ if [ "$CONFIG_PARPORT" != "n" ]; then dep_tristate ' PC-style hardware' CONFIG_PARPORT_PC $CONFIG_PARPORT if [ "$CONFIG_PARPORT_PC" != "n" ]; then - bool 'Use FIFO/DMA if available (EXPERIMENTAL)' CONFIG_PARPORT_PC_FIFO if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then + bool 'Use FIFO/DMA if available (EXPERIMENTAL)' CONFIG_PARPORT_PC_FIFO bool 'SuperIO chipset support (EXPERIMENTAL)' CONFIG_PARPORT_PC_SUPERIO fi fi Tim. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test13-pre1 lockup: run_task_queue or tty_io are wrong
Linus Torvalds wrote: > On Sun, 17 Dec 2000, Jamie Lokier wrote: > > How about using a sentinel list entry representing the current position > > in run_task_queue's loop? > > Nope. > > There may be multiple concurrent run_task_queue's executing, so for now > I've applied Andrew Morton's patch that most closely gets the old > behaviour of having a private list. I wasn't clear. The sentinel is a local structure on the stack, and only exists while run_task_queue is executing. Another name for this is "deletion-safe pointer". It works very nicely with concurrent run_task_queues: each one inserts its own sentinel and skips over the others. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 18 Dec 2000, Andrea Arcangeli wrote: > On Mon, Dec 18, 2000 at 06:29:24PM -0200, Rik van Riel wrote: > > Wrong. Getblk won't deadlock, it will just sleep and another > > getblk will deadlock. OUCH. The only protection we have against this is the fact that atomic allocations are not allowed to eat up all memory in the system and that every thread can only have 1 getblk operation at a time, right? But even so, the deadlock is still theoretically possible and should probably be fixed, this sounds too much like a time bomb waiting to go off... ;( regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, Dec 18, 2000 at 06:29:24PM -0200, Rik van Riel wrote: > Wrong. Getblk won't deadlock, it will just sleep and another getblk will deadlock. 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 2.4.0test13pre3ac1
On Mon, Dec 18, 2000 at 10:17:17PM +0200, Jani Monoses wrote: > Tim Waugh pointed out this wasn't good as 'const' is part of the function > signature and he now has a better patch. I'll sync up with Alan. Tim. */ - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
> > cat /mnt/www/www.kernel.org/index.html > > can you do ls /mnt/www/www.kernel.org/ as well? I'm interested, I came > to conclusion that web filesystem is not possible... (If you can't do Yes, if the server supports webDAV or something similar. > listings, it is not really filesystem; you could do > > cat /mnt/www/www.kernel.org_index.html as well, and that's easy to > do.) > > > and the CorbaFS userspace server takes care of loading the webpage and > > returning it to the kernel client. And these new filesystems don't > > take up any extra space in the kernel, since they all talk to the same > > CorbaFS kernel module! Not to mention being able to implement the > > filesystem in any language you like, debug the implementation in > > userspace, etc. > > codafs can do pretty much the same. Yes, but codaFS is specific to filesystems. kORBit, of course, can do much much more, in a very uniform way. :) -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: /dev/random: really secure?
David Schwartz wrote: > The code does its best to estimate how much actual entropy it is gathering. A potential weakness. The entropy estimator can be manipulated by feeding data which looks random to the estimator, but which is in fact not random at all. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
ReiserFS now works with 2.4.0-test12 and test13-pre1,2,3
For the benefit of those who want to run 2.4.0-test12 and 2.4.0-test13-preX kernels with ReiserFS and who are not actively monitoring the reiserfs-list, the following information may be of interest. Reiserfs version 3.6.22 (only) now works with these latest kernels, but two additional patches for 2.4.0-test12 and a third patch for test13-preX are necessary. Reiserfs-3.6.22 is available at: ftp://ftp.namesys.com/pub/2.4/linux-2.4.0-test10-reiserfs-3.6.22-patch.gz The first two additional patches are available here: ftp://ftp.reiserfs.org/pub/2.4/beta/reiserfs-test12-patches.tar.gz This tar contains: readpage-uptodate.diff Linus's version (Test12 ll_rw_block thread) reiserfs-3622-test12.diff For 2.4.0-test13-pre1,2,3, the following Makefile patch is needed: ftp://ftp.reiserfs.org/pub/2.4/beta/test13-preX/reiserfs-Makefile-patch If you apply these patches in this order, you shouldn't get any rejects. (Apply the test13-preX patch first). Have fun, Steven - 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: Disabling interrupts in 2.4.x
It's a UP configured system.
-bmb-
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 18, 2000 3:18 PM
> To: Boerner, Brian
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Disabling interrupts in 2.4.x
>
>
> > The only thing I am sure of is that interrupts are simply
> not disabled.
>
> They are only disabled on the local CPU, they could still
> occur on other
> CPUs. This is not different from 2.2.
>
> >
> > I've also looked at some other scsi drivers that are
> disabling interrupts
> > and they appear to be making similar calls to spin_lock_irqsave.
> >
> > Does anyone have any suggestions for debugging this? Is
> there a call that
> > can be made to find out if interrupts are actually disabled?
>
> unsigned flag;
> asm volatile("pushfl ; popfl %0" : "=r" (flag));
> printk(KERN_DEBUG "local interrupts are %s\n", (flag &
> (1<<9)) ? "enabled" : "disabled");
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Sat, 16 Dec 2000, Mikulas Patocka wrote:
> > Not unless your driver is broken.
>
> ok_to_allocate:
> *** INTERRUPT
> spin_lock_irqsave(_alloc_lock, flags);
> /* if it's not a dma request, try non-dma first */
> if (!(gfp_mask & __GFP_DMA))
> RMQUEUE_TYPE(order, 0);
> RMQUEUE_TYPE(order, 1);
> spin_unlock_irqrestore(_alloc_lock, flags);
>
> nopage:
> return 0;
> }
Now read the code carefully and see how allocations can
end up here ... and when they can't...
> When interrupt comes here and eats page just freed by try_to_free_pages(),
> GFP_KERNEL allocation will fail => The kernel goes crazy, shoots
> processes, returns -ENOMEM to calls, maybe damages its structures.
> Deadlock in getblk, if memory is full of dirty file mapped pages.
Wrong. Getblk won't deadlock, it will just sleep and another
thread will continue later on. Killing processes will (in 2.4)
only happen when you run out of swap ... 2.4 will simply have
its processes loop in alloc_pages() until memory is available.
The "maybe damages its structures" is a sure indication of
you having a very vivid imagination ;)
> You actually do not need network flood to kill your box. Just imagine that
> kpiod is swapping files out too slowly, free memory is going lower and
> lower, every process screaming with "VM: do_try_to_free_pages failed" and
> the system is aproaching instant death.
Umm? Can you explain how this could happen?
> Besides, __get_free_pages just encourages people to write broken
> drivers because it tries to hide allocation bugs. If there would
> be something like
>
> if (current->flags & PF_MEMALLOC && !in_interrupt())
> panic("swapper fscked up!");
We have something a little bit like this in 2.4, though
it's just a printk and it doesn't print a backtrace. Now
that you mention it, though, printing a backtrace may be
a nice debugging option for missed higher-order allocations ;)
(but only useful if you get unreasonable amounts of them)
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Disabling interrupts in 2.4.x
> The only thing I am sure of is that interrupts are simply not disabled.
They are only disabled on the local CPU, they could still occur on other
CPUs. This is not different from 2.2.
>
> I've also looked at some other scsi drivers that are disabling interrupts
> and they appear to be making similar calls to spin_lock_irqsave.
>
> Does anyone have any suggestions for debugging this? Is there a call that
> can be made to find out if interrupts are actually disabled?
unsigned flag;
asm volatile("pushfl ; popfl %0" : "=r" (flag));
printk(KERN_DEBUG "local interrupts are %s\n", (flag & (1<<9)) ? "enabled" :
"disabled");
-Andi
-
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.4.0test13pre3ac1
On Mon, 18 Dec 2000, Alan Cox wrote: > o Teach kernel-doc about const(Jani Monoses) Tim Waugh pointed out this wasn't good as 'const' is part of the function signature and he now has a better patch. > o Add documentation to the PCI api(Jani Monoses) > o Fix inode.c documentation (Jani Monoses) For these I've sent Tim more cleaned up patches as I thought nobody picked them up from the list.Looks like I was wrong ;-) Jani. - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
Hi! > The cool thing is that the CorbaFS userspace server can implement any > kind of filesystem you want, as long as it follows the CorbaFS > interface! The current implementation exports the filesystem on the > host machine that it is running on, similar to NFS. But we also have > ideas for FTP or web filesystems, for example. Imagine being able to > mount the web CorbaFS onto /mnt/www and do a > > cat /mnt/www/www.kernel.org/index.html can you do ls /mnt/www/www.kernel.org/ as well? I'm interested, I came to conclusion that web filesystem is not possible... (If you can't do listings, it is not really filesystem; you could do cat /mnt/www/www.kernel.org_index.html as well, and that's easy to do.) > and the CorbaFS userspace server takes care of loading the webpage and > returning it to the kernel client. And these new filesystems don't > take up any extra space in the kernel, since they all talk to the same > CorbaFS kernel module! Not to mention being able to implement the > filesystem in any language you like, debug the implementation in > userspace, etc. codafs can do pretty much the same. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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/
Disabling interrupts in 2.4.x
I'm still trying to get the aacraid driver up and running on 2.4 and have
worked it down to this final problem. It appears that interrupts are not
being disabled properly using spin_lock_irqsave. I'm using 2.4.0-test11.
I make this call:
spin_lock_irqsave ( &(SpinLock->spin_lock), SpinLock->cpu_flags);
where SpinLock is of type pointer to an OS_SPINLOCK structure defined as:
typedef _OS_SPINLOCK {
spinlock_t spin_lock;
unsignedcpu_lock_count[NR_CPUS];
longcpu_flag;
longlockout_count;
} OS_SPINLOCK;
This is the same call that I was making in 2.2.x kernel and don't have any
problems.
I would expect this function to disable interrupts, but given the scale of
change between 2.2.x spinlock.h and 2.4.x spinlock.h I'm just not sure
anymore.
The only thing I am sure of is that interrupts are simply not disabled.
I've also looked at some other scsi drivers that are disabling interrupts
and they appear to be making similar calls to spin_lock_irqsave.
Does anyone have any suggestions for debugging this? Is there a call that
can be made to find out if interrupts are actually disabled?
Brian M. Boerner
System Software Developer
Adaptec, Inc.
Nashua, NH 03060
-
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/
User based routing?
Are there any patches floating around? Basically to allow for example a server to dial out to ISP's on behalf of users, and give them full control over that interface. I know about UML, and it's not quite suited. I've not found anything searching archives, but maybe it's out there. Thanks. - 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/
old binary works not with 2.2.18
Hi, I have an old 4GL application (from SCO3.2v4) that is a neat database tool. Under 2.2.17 with iBCS this works well: kees@renske1:~ > cat /proc/version Linux version 2.2.17 (root@renske1) (gcc version 2.95.2 19991024 (release)) #10 Wed Dec 6 20:16:39 CET 2000 kees@renske1:~ > sage sage : Screen language interpreter SCULPTOR 4GL + SQL Release 2.0b (30 May 1990) (C) 1984-1990 Microprocessor Developments Ltd. All rights reserved However under 2.2.18 I get: kees@schoen3:~ > cat /proc/version Linux version 2.2.18 (root@schoen3) (gcc version 2.95.2 19991024 (release)) #1 SMP Mon Dec 18 00:48:04 CET 2000 kees@schoen3:~ > sage Segmentation fault schoen3:~ # file /usr/SCULPTOR/bin/sage /usr/SCULPTOR/bin/sage: Microsoft a.out separate pure segmented word-swapped V2.3 V3.0 386 small model executable Hints? Kees - 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: CPU attachent and detachment in a running Linux system
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote: > Hi, > > >> I still wonder what you and other people think about the idea of an > >> interface where the parts of the kernel with per-cpu dependencies should > >> register two functions... > >Why not compile kernel with structeres big enough for 32 processors, > >and then just add CPUs up to the limit without changing anything? > > That's a good point and it would probably work for attachment of cpus, but > it won't work for detachment because there are some data structures that > need to be updated if a cpu gets detached. For example it would be nice > to flush the per-cpu cache of the detached cpu in the slabcache. Then one > has to think of pending tasklets for the detached cpu which should be > moved to another cpu and then there are a lot of per-cpu data structures > in the networking part of the kernel.. most of them seem to be for > statistics only but I think these structures should be updated in any > case. > So at least for detaching it would make sense to register functions which > will be called whenever a cpu gets detached. Plus userspace CPU monitors will need to know when the CPU arrangement has changed. - 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.4.0test13pre3ac1
This is mostly so people can see what I have merged in my tree and what has gone from it. The patch for the adventurous is in ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/.. 2.4.0test13pre3-ac1 adds o Handle TLB flush reruns caused by APIC rexmit (me) o Fix leak in link() syscall (Al Viro) o Fix ramfs deadlock (Al Viro) o Fix udf deadlock(Al Viro) o Improve parport docs(Tim Waugh) o Document some of the macros (Tim Waugh) o Fix ppa timing issues (Tim Waugh) o Mark the parport fifo code as experimental (Tim Waugh) o Resynch ppa changelog (Tim Waugh) | Tim please double check as I got offsets o Fix Yam driver for Linux 2.4test(Hans Grobler) o Fix AF_ROSE sockets for 2.4 (Hans Grobler) o Fix AF_NETROM sockets for 2.4 (Hans Grobler) o Tidy AF_AX25 sockets for 2.4(Hans Grobler) o Teach kernel-doc about const(Jani Monoses) o Add documentation to the PCI api(Jani Monoses) o Fix inode.c documentation (Jani Monoses) o Push Davicom support into the main tulip driver (Tobias Ringstrom) o First block of mkiss driver fixes (Hans Grobler) o Fix bug in VFAT short name handling (Nicolas Goutte) o Clean up the i810 driver(Tjeerd Mulder) o RCPCI45 PCI cleanup fixes (mark 2) (Rasmus Andersen) o Improve the ALSxxx sound driver documentation (Jonathan Woithe) o Fix ext2 modular build (Jeff Raubitschek) o Fix bug in scripts/Configure.in matching(Matthew Wilcox) o Revert accidental amifb change (Geert Uytterhoeven) o Fix ext2 file size limiting for large files (Andreas Dilger) o Clean up misleading indenting in partition code (JAmes Antill) o Update SiS video drivers(Can-Ru Yeou) o Yamaha audio doc fix(Pavel Roskin) o Fix ACPI driver wakeup races(David Woodhouse) o Remove bogus asserts in 8139too driver (Jeff Garzik) o Fix timeout problms with rocktports at 249 days o Update acenic patches (Jes Sorensen) o Fix i810 tco locking(me) o Fix media makefiles (me) o Fix drm makefiles (Peter Samuelson) 2.4.0test12-ac1 adds o ARM bootup/initd fixes (Russell King) o Fix ymf_sb setup bug(Pavel Roskin) o Correctly print names of md10+ (me) [Based on code from Roberto Ragusa] o Fix sound crashes in various drivers(Tjeerd Mulder) o Update epic100 to new pci api (Francois Romieu) o Fix IOC/SIOC ioctl problems in ac97 code(Dick Streefland) To merge o Fix Ruffian Alpha boot (Ivan Kokshaysky) o Bridge handling patches needed for Alpha(Ivan Kokshaysky / Richard Henderson) o FPU emulator source set for m68k(Geert Uytterhoeven) o Fix m68k build with rmw disabled(Geert Uytterhoeven) o Cleanup ramdisk namespace (Jeff Garzik) o Link correctly with ACPI on ACPI_INTERPRETER off o Ramdisk missing blkdev_put o Acenic update o Epic100 update o Support mixed pnp and legacy sb cards o Hopefully fix the bugs in the FAT and HPFS file systems that caused fs corruption o Fix cramfs vanishing data bug o Fix NLS config.in bug for SMB o Power management locking fixes o filemap posix compliance fix o Fix pte handling race o Remove unneeded inits to 0 in ide code(Bartlomiej Zolnierkiewicz) o IDE documentation fixes (Bartlomiej Zolnierkiewicz) Submitted to Linus o Add firestream ATM driver(Patrick van de Lageweg) o Add the powermac extras to the input and(Franz Sirl) keyboard drivers o Fix reference counting in ATM(Patrick van de Lageweg) o Update Changes to give correct modutils rev (Steven Cole) o Fix xconfig/menuconfig problems with config (Andrzej Krzysztofowicz) scripts in 2.4test o Fix kd_mksound declaration (Geert Uytterhoeven) o Fix warning in sim710 driver(Pavel Rabel) o Merge bttv 0.7.50
lvm 0.9 + fixes
Linus, could you include lvm 0.9 into 2.4.x? It adds snapshot persistence and it fixes a severe race condition during live extent-reduce. I ported lvm-0.9 to 2.4.0-test13-pre3 and then I included into it further fixes that are present in my local tree for a memory leak plus other kiobufs cleanups and minor things. I also #defined LVM_GET_INODE and undefined the LVM_HD_NAME so that we don't have to include the check.c lvm_hd_name_ptr ugliness. Patch is here: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test13-pre3/lvm-0.9-aa-1 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: Linus's include file strategy redux
On Mon, Dec 18, 2000 at 10:51:09AM -0500, Dana Lacoste wrote:
>
> Can we get a #3 going? I think it could really help both the cross-compile
> people and those who just want to make sure their modules are compiling in
> the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
> be 'properly' resolved by the distribution-creator as it should be, instead of
> linux-kernel or the 3rd party module mailing lists.
I use the following script (scripts/dep.linux from Comedi-0.7.53).
It could easily be improved to handle the /lib/modules/*/build/include
link. I've also developed (actually, "gathered") a lot of other stuff
for convenient non-kernel module compiling, including compatiblity
header files, Makefiles, etc. Good places to look for stuff include
comedi, RTAI, RTLinux, PCMCIA, and MTD.
Keep in mind that there is no "correct" environment except that
which the user specifies.
dave...
#!/bin/sh
if [ "$LINUXDIR" = "" ]
then
echo -n "Enter location of Linux source tree [/usr/src/linux]: "
read LINUXDIR
: ${LINUXDIR:=/usr/src/linux}
fi
if [ ! -f "$LINUXDIR/.config" ];then
echo Kernel source tree at $LINUXDIR is not configured
echo Fix before continuing
exit 1
fi
echo using LINUXDIR=$LINUXDIR
echo LINUXDIR=$LINUXDIR >.sourcedirs
. $LINUXDIR/.config
#
# check for a bad situation
#
if [ "$CONFIG_MODULES" = "n" ]
then
cat <.uts_version
if [ "$(uname -r)" != "$UTS_VERSION" ]
then
cat
Re: [OT] Re: Linus's include file strategy redux
On Sun, 17 Dec 2000, Peter Samuelson wrote: > > [[EMAIL PROTECTED]] > > One last question: WHY is the kernel's top-level Makefile handling > > this symlink? > > Where do you think it should be handled? 'make modules_install' seems > like the most logical place, to me. I think making the symlink should be handled outside the proper scope of the top-level Makefile, for reasons I have brought up earlier in this discussion; The Makefile is simply not equipped to know the full state of the system it is being run for outside the simple case of one single machine. s/WHY is/For which specific reasons is/ Anyway, the associated discussions cleared up nearly all the technical-related questions I had. The remaining questions relate toward policy-issues orthogontal to implementation details. I am still a little unclear on the nature of the problem this symlink is meant to solve. - 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: test13-pre3
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
> The appended patch fixes the following:
>
> 1) We cannot unlock the page in shmem_writepage on ooswap since
>page_launder will do this later.
>
> 2) We should set the inode number of SYSV segments to the (user)
>shmid and not the internal id.
And here additionally is the SYSV detach/destroy logic fixed which
(again) left destroyed shm segments hang around :-(
I also cleaned up the list of included files in ipc/shm.c
Greetings
Christoph
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.cMon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 20:07:21 2000
@@ -15,23 +15,13 @@
*
*/
-#include
-#include
#include
#include
-#include
-#include
#include
-#include
#include
#include
-#include
-#include
#include
-#include
-
#include
-#include
#include "util.h"
@@ -109,6 +99,7 @@
BUG();
shp->shm_atim = CURRENT_TIME;
shp->shm_lprid = current->pid;
+ shp->shm_nattch++;
shm_unlock(id);
}
@@ -123,21 +114,14 @@
*
* @shp: struct to free
*
- * It has to be called with shp and shm_ids.sem locked and will
- * release them
+ * It has to be called with shp and shm_ids.sem locked
*/
static void shm_destroy (struct shmid_kernel *shp)
{
- struct file * file = shp->shm_file;
-
- shp->shm_file = NULL;
shm_tot -= (shp->shm_segsz + PAGE_SIZE - 1) >> PAGE_SHIFT;
- shm_unlock (shp->id);
shm_rmid (shp->id);
+ fput (shp->shm_file);
kfree (shp);
- up (_ids.sem);
- /* put the file outside the critical path to prevent recursion */
- fput (file);
}
/*
@@ -158,10 +142,10 @@
BUG();
shp->shm_lprid = current->pid;
shp->shm_dtim = CURRENT_TIME;
- if(shp->shm_flags & SHM_DEST &&
- file_count (file) == 2) /* shp and the vma have the last
- references*/
- return shm_destroy (shp);
+ shp->shm_nattch--;
+ if(shp->shm_nattch == 0 &&
+ shp->shm_flags & SHM_DEST)
+ shm_destroy (shp);
shm_unlock(id);
up (_ids.sem);
@@ -176,7 +160,7 @@
}
static struct file_operations shm_file_operations = {
- mmap: shm_mmap
+ mmap: shm_mmap
};
static struct vm_operations_struct shm_vm_ops = {
@@ -218,9 +202,10 @@
shp->shm_atim = shp->shm_dtim = 0;
shp->shm_ctim = CURRENT_TIME;
shp->shm_segsz = size;
+ shp->shm_nattch = 0;
shp->id = shm_buildid(id,shp->shm_perm.seq);
shp->shm_file = file;
- file->f_dentry->d_inode->i_ino = id;
+ file->f_dentry->d_inode->i_ino = shp->id;
file->f_op = _file_operations;
shm_tot += numpages;
shm_unlock (id);
@@ -370,15 +355,13 @@
struct inode * inode;
shp = shm_get(i);
- if(shp == NULL || shp->shm_file == NULL)
+ if(shp == NULL)
continue;
inode = shp->shm_file->f_dentry->d_inode;
- down (>i_sem);
- *rss += inode->i_mapping->nrpages;
spin_lock (>u.shmem_i.lock);
+ *rss += inode->i_mapping->nrpages;
*swp += inode->u.shmem_i.swapped;
spin_unlock (>u.shmem_i.lock);
- up (>i_sem);
}
}
@@ -462,7 +445,7 @@
tbuf.shm_ctime = shp->shm_ctim;
tbuf.shm_cpid = shp->shm_cprid;
tbuf.shm_lpid = shp->shm_lprid;
- tbuf.shm_nattch = file_count (shp->shm_file) - 1;
+ tbuf.shm_nattch = shp->shm_nattch;
shm_unlock(shmid);
if(copy_shmid_to_user (buf, , version))
return -EFAULT;
@@ -512,13 +495,12 @@
goto out_up;
err = shm_checkid(shp, shmid);
if (err == 0) {
- if (file_count (shp->shm_file) == 1) {
+ if (shp->shm_nattch){
+ shp->shm_flags |= SHM_DEST;
+ /* Do not find it any more */
+ shp->shm_perm.key = IPC_PRIVATE;
+ } else
shm_destroy (shp);
- return 0;
- }
- shp->shm_flags |= SHM_DEST;
- /* Do not find it any more */
- shp->shm_perm.key = IPC_PRIVATE;
}
/* Unlock */
shm_unlock(shmid);
@@ -619,13 +601,23 @@
return -EACCES;
}
file = shp->shm_file;
- get_file (file);
+ shp->shm_nattch++;
shm_unlock(shmid);
down(>mm->mmap_sem);
user_addr = (void *) do_mmap (file, addr, file->f_dentry->d_inode->i_size,
prot, flags, 0);
ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking)
On Mon, Dec 18, 2000 at 10:11:14AM -0800, David S. Miller wrote: >From: Rusty Russell <[EMAIL PROTECTED]> >Date: Mon, 18 Dec 2000 14:15:52 +1100 > >Alexey is right, locking is screwed (explains some reports of >occasional failure during rmmod). > > Patch applied, thank you. > >I have a patch which compiles for non-linear skb mods to netfilter >(NAT uses linear packets still, but connection tracking and packet >filtering only linearize minimal requirements). Waiting for >DaveM's solution to ip_ct_gather_frags()... > > I feel it's best to just skb_clone() the skb arg to ip_defrag > and this will close the whole thing, I think. no. The clone()d skb will still have a skb->dev pointing to NULL. The problem occurs only for locally-generated outgoing packets, which need to be fragmented: - ip_build_xmit() discoveres it has to fragment - ip_build_xmit_slow() generates fragments and calls - NF_HOOK() for NF_IP_LOCAL_OUT - ip_conntrack_local() is called, which in turn calls - ip_conntrack_in(), which calls - ip_ct_gather_frags(), which calls - ip_defrag(), which calls [now we have two possible oops - caues] a ip_find(), which calls a ip_frag_create(), which initialises a timer with the function a ip_expire(), which dereferences qp->iif b ip_frag_queue(), which dereferences it in qp->iif= skb->dev->ifindex as andi kleen pointed out: > > Also is it sure that the backtrace involves ip_rcv ? A more likely > > guess is that it happens during the IP_LOCAL_OUT hook, when skb->dev > > isn't set yet, but conntrack already has to already reassemble fragments. > Actually, I do not understand how current code could even have worked > in the past. Once the SKB is passed to ip_defrag, it is nobody's > buisness to reference that SKB anymore. This ip_defrag call is (from mmh... we really don't do this. We use the return value of ip_defrag(), which is what ip_frag_reasm() returns (== the new datagram consisting out of all its fragments). > Alexey, what have I missed? I don't like the ip_fragment.c proposed > fix for this reason, what netfilter is doing with ip_defrag here looks > just wrong. Well, my conclusion is: - the defragmentation code in the ipv4 stack assumes that skb->dev points to a valid device. It does this primaryly to send icmp reassembly errors if a fragment reassembly timeout occurs - netfilter wants to use the ip_defrag for defragmentation, not only for incoming packets from the network at NF_IP_PRE_ROUTING, but also for locally-generated fragmented packets (at NF_IP_LOCAL_OUT). Unfortunately we don't have a valid skb->dev at this point. I don't think that there is any skb_clone()ing needed, nor this would solve the problem. The solution is a) netfilter conntrack (more exactly: ip_ct_gather_frags) sets skb->dev to something valid (skb->dst->dev). Dirty hack. b) make ip_defrag(), ... aware of the case where skb->dev == NULL. Sounds like a good idea, since it is only one if(skb->dev) clause. c) netfilter stops using ip_defrag() for this case. Bad idea, it had to reinvent the wheel :( > David S. Miller > [EMAIL PROTECTED] -- Live long and prosper - Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*) - 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 performance problem
Date: Mon, 18 Dec 2000 14:09:00 -0500 (EST) From: "Richard B. Johnson" <[EMAIL PROTECTED]> Well I just use free(), nothing more, nothing special, just like a typical data-base program. Free should just set a new break address after the reclaimed data falls below some watermarks it has established. Both malloc() and free(), use already allocated data-space for their work-space (last time I looked at library code). malloc and free maintain their free buffers pools using linked lists, thus a free() does two stores to the (2 * sizeof(void *)) bytes before or after that buffer. Thus the swapping. Use mmap()/munmap() directly and manage things totally yourself to get rid of this. Later, David S. Miller [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/
problem with wireless pcmcia modem with linux (Ricochet)
Hi Ive been working on getting the wireless modem from novatel work with my linux box. I see that all incoming ip packets larger than 450 bytes get corrupted ..the last two bytes (checksum) goes missing when it reaches the ppp driver.. if the packet is less than that (450 bytes ) everything is fine . Ive not been able to isolate the problem to the card or the serial driver The card works very well with windows and mac Im using kernel 2.2.16 with pcmcia version 3.1.8 thanks jayant jain please cc me at [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 performance problem
On Mon, 18 Dec 2000, David S. Miller wrote: >Date: Mon, 18 Dec 2000 13:54:56 -0500 (EST) >From: "Richard B. Johnson" <[EMAIL PROTECTED]> > >6/ Deallocates all the buffers by running down the linked-list. > > ... > >If the program deallocates all the buffers, as in (6) above, it will >take even up to 1 whole minute!! At this time, there is an enormous >amount of swap-file activity going on. > > How exactly are these buffers allocated/deallocated? Are you > absolutely certain that the deallocation process does not make loads > from or stores into the buffers as a free(3) implementation would? > > That would cause the pages to be sucked back from swap space. > Well I just use free(), nothing more, nothing special, just like a typical data-base program. Free should just set a new break address after the reclaimed data falls below some watermarks it has established. Both malloc() and free(), use already allocated data-space for their work-space (last time I looked at library code). Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 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: VM performance problem
Date:Mon, 18 Dec 2000 13:54:56 -0500 (EST) From: "Richard B. Johnson" <[EMAIL PROTECTED]> 6/ Deallocates all the buffers by running down the linked-list. ... If the program deallocates all the buffers, as in (6) above, it will take even up to 1 whole minute!! At this time, there is an enormous amount of swap-file activity going on. How exactly are these buffers allocated/deallocated? Are you absolutely certain that the deallocation process does not make loads from or stores into the buffers as a free(3) implementation would? That would cause the pages to be sucked back from swap space. Later, David S. Miller [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/
VM performance problem
I have some memory-checker software. I will put it on my server if anybody is interested. I have discovered a VM performance problem that somebody should look into. The code: 1/ Allocates PAGE_SIZE buffers (using ordinary malloc()) until the swap file starts being used (reading /proc --slow). These buffers are in a linked-list. 2/ Writes all these buffers to a known pattern. 3/ Does lots of XOR operations, etc., on the buffers. 4/ Reads all the buffers to see if any bits are bad. 5/ Reports any bad stuff. If anything is bad, executes an ioctl() to a dummy driver to get the physical address. 6/ Deallocates all the buffers by running down the linked-list. 7/ Continues to (1) above. Here is the performance problem observed. If I ^C out of the program, killing it outright, with the kernel freeing all the allocated data, everything is fine. There is little or no swap activity as a result of this. If the program deallocates all the buffers, as in (6) above, it will take even up to 1 whole minute!! At this time, there is an enormous amount of swap-file activity going on. Since many programs allocate/deallocate data by setting the break address via malloc(), this represents a severe performance penalty. Deallocating pages should not result in any swap-file activity! This activity should occur only when whatever got swapped out, needs to get swapped back in and nothing needs to get swapped back in during a deallocation! Since user's pages are not reordered (or should not be), there should be no swap activity during page deallocation. This problem is observed on 2.2.17, 2.4.0-test9, and 2.4.0-test12. Could a VM guru please comment? Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 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/
system locks HARD on KDE start
Hi, I'm trying to get kde2 running and i'm not positive if it's a KDE problem, or a kernel thing. Whenever I start kde, the kde startup gets so far and the system freezes. Sometimes it does it at "Loading the panel" sometimes it'll get to "100% KDE is up and running" and do it. When it does it the hard drive light stays on. I can't see if the kernel is oopsing because it's stuck in graphics mode. Alt-SysRq to sync/unmount disks doesn't seem to work, because i reset and all the drives go into fsck. I've tried the following combinations: kde 2.0 (final and pres)/qt 2.2.1/xfree 3.3.6/kernel 2.2.15pre18|2.2.18pre20 kde 2.0.1/qt 2.2.2/xfree 4.0.1|3.3.6/kernel 2.2.15pre18|2.2.18pre20 All are compiled from source. X runs fine with just tvm. glibc is 2.1.3. gcc is 2.95.2 I used to run libc5, and kde 2.0 would startup fine, but i had many SEGV/ABRTs making it unusable, which is why i upgraded to 2.1.3. libc5 is still around just for existing apps. Nothing fancy compiled in kernel..no I2C, USB, sound, or power management. Running PR440FX mobo with dual ppro 200s, SCSI drives (i've also tried a new hard drive), 384MB ram, Diamond Stealth 2000 Any help is appreciated, -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer [EMAIL PROTECTED] Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://www.asteroid-b612.orghttp://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. - 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/
Problem with UDMA 4 - deadlocking machine
Hello Last Saturday I've spent some time on testing deadlock which bites me for a long time on my BP6 SMP board (practically since I've started to use ATA66 controller). Before you will stop reading and saying I should buy a different board please try to continue for a few moments. (its a bit longer - but I think there are few interesting points) First I'll describe my hw configuration - BP6 128MB 2x400MHz CPU (usually running @92MHz FSB - ~560MHz) Cards: SBLive slot 2, TV-Phone98 slot 5, G400Max AGP Hard drives: 6GB Western on UDMA33 (contains only vfat partitions), CD-ROM Ricoh 9060A UDMA33, 30GB IBM UDMA66 hpt366 (contains only ext2 partitions). There are no shared interrupts in /proc/interrupts. hdparm gives me around 34MB/s for UDMA66 drive and 8MB/s for WD6GB drive. For testing I've used the following simple sequence: I've created 650MB file on UDMA66 drive and I've been copying this file to UDMA33 vfat partition. (while : ; do cp /ext2/my650 /vfat/ ; md5sum /vfat/my650 ; done) When this test was running correctly for 6 times I've considered it stable. Kernel used for testing has been CLEAN UNPATCHED 2.4.0-test12 (with SMP, and without SMP support) Here are some initial results: After reboot and running this on console - everything was OK starting the X server and not doing anything else in them (e.g. moving mouse) - again everything was OK. And now to the less positive part - as soon as I've turned on programs which are using SBLive or TV card the locking had begun. After a while I've came with conclusion it doesn't matter if it's just emu10k1 driver or bttv driver or both of them running at same time - simply when one or both of them were running I've been unable to copy the file from UDMA66 to UDMA33 (test usually occurred after 200MB has been copied). For the huge amount of tested environment I've used just fbtv and linux matrox framebuffer console with just bttv as this was usually to the fastest way to deadlock. For the testings I've flashed around 9 different BP6 bioses (always cleaning all the BIOS settings) - LP, NJ, QQbeta, QQ-2, and couple of RU bioses - usually I'm using ru with htp 1.26 Also I've been checking non-overclocked & overclocked setup with each BIOS. After few hours the clear result was: Linux kernel with SMP or without SMP ALWAYS locks during this test - it has never finished more then 1 copy of this file - and the crash is always complete deadlock - but the console says something about hdf: lost interrupt first - but I've already reported this and no one seems to care. (I'll repeat - I've used all known to me Bioses & correctly clocked CPU for this test and it had always failed) So I've came to conclusion that there could be several possible problems: UDMA 4 mode is not correctly programmed for hpt366 controller (as the only one who seems to understand the setting for this chipset is Andre itself, I afraid that he is the only one who could play with them and possible fix) UDMA 4 mode is incorrectly programmed and it doesn't take into account that some other interrupt services might lock the system bus for a while (again this is for Andre Hedrick probably) (I've also noticed few other peoples comlaing about some problems while copying huge files - and they didn't have BP6 board, so maybe its some more general problem) BP6 hpt366 is completely bad piece of hardware (I hope it's not that bad) Ok after this - I've also found some partial solution for this problem which is relatively easy - degrading hpt366 from UDMA 4 to UDMA 2 with 'hdparm -X66 /dev/hdf' - after issuing this command all my test had never failed (8 copies without any problems while playing TV and mp3 files with xmms) (btw is there some way I could turn it back to UDMA 4 mode ??) So hpt366 & linux could coexists peacefully they just can't use UDMA4 mode. I've also run this test with both drives on UDMA33 controllers - again without a single problem. So that's probably all I wanted to say - so maybe some advice for BP6 users - if they want to have stable system - they should probably not use UDMA 4 mode (-X66 for hpt366 or just ignore UDMA66 controller at all - especially if you are using devices which generates a lot of interrupts - like sound cards, tv card, network cards :) And strange note for the end - I had usually problems even to boot the machine when it has not been overclocked and it was running with 66MHz FSB speed - however this "hdf: lost interrupt" message has not lead to deadlock of machine (deadlock means for me that computer doesn't react even to Magic SysRq) - after a few messages about the lost interrupts the system has turned off DMA and was continuing with boot process however using computer with just 3MB/s throughput is not that funny (also there were no APIC error with 66 FSB). This boot problem has never happened to me while running with 92MHz FSB even though APIC errors makes console practically unusable. I think this letter is already
Re: Startup IPI (was: Re: test13-pre3)
On Mon, 18 Dec 2000, Petr Vandrovec wrote: > It is possible. But it is hard to track, as it works with serial console, > and it is not possible to paint characters to VGA screen, as vgacon uses > hardware panning instead of scrolling :-( And if it dies, shift-pageup > apparently does not work... And filling whole 32KB with some char > does not work, as it changes timing too much... Just disable the problematic printk()s for making tests (you may just undefine APIC_DEBUG in include/asm-i386/apic.h) -- we already know what is going to be printed here. ;-) > No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or > PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA... Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try if accessing one bus or another changes the behaviour. > Yes. I could understand if I had to place bigger udelay() after INIT IPI, > as this can cause some specific PIII initialization and Intel says that > there should not be any MESI traffic during this init (at least I understand Hmm, weird -- for integrated APICs an INIT IPI is about the same as shutdown apart from the fact an NMI won't wake up a CPU (that might actually be the local APIC not passing NMIs to the CPU in this case, though). > it that way). But after startup IPI it should just start executing code... > I tried to put 'wbinvd' here and there, but it did not make any change, > only udelay() between startup IPI cmd and first printk() did. Hmm, a startup IPI is rather fast so the code just after issuing it may somehow interact with the application's CPU trampoline. But try to disable CONFIG_X86_GOOD_APIC, yet (you may configure for classic Pentium, for example), and see if that changes anything (it shouldn't, but who knows...). > I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge, Just look at the board and search for an I/O APIC chip. ;-) > and VT82C686 (rev 22) ISA bridge. I tried to request documentation > of 694X from VIA, but I did not heard from them. They have probably > some secrets hidden in their hardware... They wan't to keep the competition from being bug-compatible, it would seem... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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] Linus elevator
On Mon, Dec 18 2000, Mark Hemment wrote: > Hi, > > Looking at the second loop in elevator_linus_merge(), it is possible for > requests to have their elevator_sequence go negative. This can cause a > v long latency before the request is finally serviced. > > Say, for example, a request (in the queue) is jumped in the first loop > in elevator_linus_merge() as "cmd != rw", even though its > elevator_sequence is zero. If it is found that the new request will > merge, the walking back over requests which were jumped makes no test for > an already zeroed elevator_sequence. Hence it zero values can occur. > > With high default values for read/wite_latency, this hardly ever occurs. > > A simple fix for this is to test for zero before decrementing (patch > below) in the second loop. The merge part was original deliberate, as not to account successful merges as much as a new request added (and thus an implied seek). But you did uncover a problem, btw this is also fixed in the blk-12 patch that also does better accounting to avoid indefinite starvation. > Alternatively, should testing in the first loop be modified? To stay with the original design, yes. -- * Jens Axboe <[EMAIL PROTECTED]> * 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/
[PATCH] Configure.help (CONFIG_ATALK/appletalk.o)
Axel, The following patch to the help section for appletalk.o: * Updates a reference URL to a permanent (non-employer dependent) location. The old URL has been redirecting here for a while. * Explains why you'd be crazy to not compile appletalk as a module. I attempted to align the word wrapping to account for the difference in text size. -Bill --- linux-2.4.0-test12/Documentation/Configure.help Mon Dec 18 12:56:47 2000 +++ linux/Documentation/Configure.help Mon Dec 18 13:05:49 2000 @@ -4138,11 +4138,10 @@ want to join the conversation, say Y. You will need to use the netatalk package so that your Linux box can act as a print and file server for Macs as well as access AppleTalk printers. Check out - http://threepio.hitchcock.org/cgi-bin/faq/netatalk/faq.pl on the WWW - for details. EtherTalk is the name used for AppleTalk over Ethernet - and the cheaper and slower LocalTalk is AppleTalk over a proprietary - Apple network using serial links. EtherTalk and LocalTalk are fully - supported by Linux. + http://www.zettabyte.net/netatalk/ on the WWW for details. EtherTalk + is the name used for AppleTalk over Ethernet and the cheaper and + slower LocalTalk is AppleTalk over a proprietary Apple network using + serial links. EtherTalk and LocalTalk are fully supported by Linux. General information about how to connect Linux, Windows machines and Macs is on the WWW at http://www.eats.com/linux_mac_win.html . The @@ -4153,8 +4152,10 @@ This driver is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module is called appletalk.o. If you want to compile it as a - module, say M here and read Documentation/modules.txt. I hear that - the GNU boycott of Apple is over, so even politically correct people + module, say M here and read Documentation/modules.txt. You almost + certainly want to compile it as a module so you can restart your + AppleTalk stack without rebooting your machine. I hear that the + GNU boycott of Apple is over, so even politically correct people are allowed to say Y here. AppleTalk-IP driver support - 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/
[final] Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
On Mon, 18 Dec 2000, Andreas Dilger wrote:
> If I could add one thing here (we have had a 2.2 patch like this for testing
> with ext3) - if you specify the rootfstype parameter don't use the "quiet"
> option to read_super, so you know why it couldn't mount a specific filesystem
> as root, and/or print rootfs type in the panic message.
Agree completely.
Here is the hopefully final version. Sorry, Linus, I thought the first
version was final :) Looks like I have missed a couple of very useful
things... Thanks to all who commented!
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 15:03:44 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n < 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,0);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(_systems_lock);
+fail:
panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
kdevname(ROOT_DEV));
mount_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: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
Tigran, you write:
> Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
> to do the same it did before + panic when rootfs= is given but failed to
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype parameter don't use the "quiet"
option to read_super, so you know why it couldn't mount a specific filesystem
as root, and/or print rootfs type in the panic message.
This is especially useful if you have something in LILO that you forgot about...
Cheers, Andreas
=
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 14:49:08 2000
@@ -1600,7 +1600,7 @@
if (*rootfs) {
fs_type = get_fs_type(rootfs);
if (fs_type) {
- sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,0);
if (sb)
goto mount_it;
}
@@ -1622,7 +1622,8 @@
}
read_unlock(_systems_lock);
fail:
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+ kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
--
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: 2.2.18 asm-alpha/system.h has a problem
In article <[EMAIL PROTECTED]>, Timur Tabi <[EMAIL PROTECTED]> wrote: >** Reply to message from Peter Samuelson <[EMAIL PROTECTED]> on Mon, 18 Dec >2000 09:03:00 -0600 (CST) >> Not a compiler bug, a source bug of assuming a C header file can be >> included by a C++ program. The right solution, as always, is to make a >> copy of the header (assuming you really do need it) and edit the copy >> as necessary. > >That just creates more maintenance problems. What if the kernel header file >changes? Then he'll have to change his copy as well. He'll forever need to >check changes in that kernel header file, or risk having an obscure bug that's >otherwise hard to track. No, in fact that is the desired behaviour. If the kernel include files change, chances are very big that the source of the utility (or library) needs adjustments as well. In fact if you simply recompile the old source with the new header files you might get unwanted and unexpected behaviour, whereas if you recompile with the older header defs you'll simply use an advertized api that might not be the latest but works Mike. -- RAND USR 16514 - 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: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote: > On Mon, 18 Dec 2000, Petr Vandrovec wrote: > > > No. Without udelay() before first printk() it just does not boot on my > > motherboard. There were two choices: either remove all printk() from > > these loops (define Dprintk to null), or add udelay(x), where x >= 200, > > before first printk. I sent patch twice to linux-kernel, and to > > [EMAIL PROTECTED], and nobody said anything against it. > > I see. But are you sure this is the right fix? You may be covering > the real problem with this arbitrary delay. It is possible. But it is hard to track, as it works with serial console, and it is not possible to paint characters to VGA screen, as vgacon uses hardware panning instead of scrolling :-( And if it dies, shift-pageup apparently does not work... And filling whole 32KB with some char does not work, as it changes timing too much... > > analyzer (or if I should come with motherboard), I'm willing to continue > > testing. But current idea is that inb/outb done by cursor positioning > > code is incompatible with something else done in secondary CPU startup. > > Have you tried putting explicit display adapter (other ISA) I/O accesses > after sending the IPI to see if they trigger the problem? IPIs are No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA... > > Without delay() both CPU die, and board does not react to anything except > > hard reset anymore (and sometime it does not react even to hard reset; lookup > > for my messages during last week). > > Now THAT is weird. It might mean a chipset bug. Still no idea how an > inter-APIC message might trigger it -- it completely bypasses MB Yes. I could understand if I had to place bigger udelay() after INIT IPI, as this can cause some specific PIII initialization and Intel says that there should not be any MESI traffic during this init (at least I understand it that way). But after startup IPI it should just start executing code... I tried to put 'wbinvd' here and there, but it did not make any change, only udelay() between startup IPI cmd and first printk() did. > chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's > 82093AA) or integrated? It appears there are vendors manufacturing I/O > APIC clones and this may imply new problems, sigh... I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge, and VT82C686 (rev 22) ISA bridge. I tried to request documentation of 694X from VIA, but I did not heard from them. They have probably some secrets hidden in their hardware... Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 asm-alpha/system.h has a problem
> programmer for a C++ programmer. All the C programmer needs to do is
> acknowledge that someone might want to use a C++ compiler on the code, and just
> make a few minor changes that have no negative affect at all.
All C++ folks need to do is to use
extern "C" {
#include "macrosforthestuffthecplusplusstandardspeoplegotwrong.h"
#include "cheaderfile"
#include "nowmakethemacrosgoaway.h"
}
where those redefine new private etc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18 asm-alpha/system.h has a problem
** Reply to message from Peter Samuelson <[EMAIL PROTECTED]> on Mon, 18 Dec 2000 09:03:00 -0600 (CST) > Not a compiler bug, a source bug of assuming a C header file can be > included by a C++ program. The right solution, as always, is to make a > copy of the header (assuming you really do need it) and edit the copy > as necessary. That just creates more maintenance problems. What if the kernel header file changes? Then he'll have to change his copy as well. He'll forever need to check changes in that kernel header file, or risk having an obscure bug that's otherwise hard to track. Yes, it's perfectly valid C, but so what? That doesn't mean that it's a good idea. It does no harm to make a minor change to the header file to allow a C++ compiler to digest it. I consider it to be a "professional courtesy" of a C programmer for a C++ programmer. All the C programmer needs to do is acknowledge that someone might want to use a C++ compiler on the code, and just make a few minor changes that have no negative affect at all. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - 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] Linus elevator
Hi,
Looking at the second loop in elevator_linus_merge(), it is possible for
requests to have their elevator_sequence go negative. This can cause a
v long latency before the request is finally serviced.
Say, for example, a request (in the queue) is jumped in the first loop
in elevator_linus_merge() as "cmd != rw", even though its
elevator_sequence is zero. If it is found that the new request will
merge, the walking back over requests which were jumped makes no test for
an already zeroed elevator_sequence. Hence it zero values can occur.
With high default values for read/wite_latency, this hardly ever occurs.
A simple fix for this is to test for zero before decrementing (patch
below) in the second loop.
Alternatively, should testing in the first loop be modified?
Mark
diff -u --recursive --new-file -X dontdiff linux-2.4.0-test12/drivers/block/elevator.c
markhe-2.4.0-test12/drivers/block/elevator.c
--- linux-2.4.0-test12/drivers/block/elevator.c Tue Dec 5 23:05:26 2000
+++ markhe-2.4.0-test12/drivers/block/elevator.cMon Dec 18 17:50:19 2000
@@ -90,6 +90,9 @@
if (ret != ELEVATOR_NO_MERGE && *req) {
while ((entry = entry->next) != >queue_head) {
struct request *tmp = blkdev_entry_to_request(entry);
+
+ if (!tmp->elevator_sequence)
+ continue;
tmp->elevator_sequence--;
}
}
-
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 3c59x and 3C905B
On Mon, 18 Dec 2000, Michael Illgner wrote: > Hi folks, > I have some trouble using a 3COM NIC905B and the 3c59x driver with kernel > 2.2.x > and 2.4.0.testx. First of all the card works fine with Windows or with linux > 2.2.18 > using the 3c90x driver supplied by 3COM. But with the 3c59x driver I get > transfer rates This kernel is a stock 2.2.17 with acl patches (doesn't change anything network-related). Bootup msg : 3c59x.c 16Aug00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905B Cyclone 100baseTx at 0x6c00, 00:10:5a:68:ea:ad, IRQ 11 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. MII transceiver found at address 0, status 786d. Enabling bus-master transmits and whole-frame receives. > below 10k/s or even lower. The card is connected to a 10/100 Hub (Netgear > DS104). You're sure that hub can handle full-fuplex mode ? Because that's what the card uses in your case. > Here are some informations > > Kernel version > > 2.2.18 SMP and 2.4.0.test12 SMP (latest kernel) but the problem seems > to be independent of the kernel version. > > > Banner message > > Dec 17 19:44:48 ganerc kernel: 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker > and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > Dec 17 19:44:48 ganerc kernel: See Documentation/networking/vortex.txt > Dec 17 19:44:48 ganerc kernel: eth0: 3Com PCI 3c905B Cyclone 100baseTx at > 0xdc00, 00:10:5a:d8:25:f1, IRQ 19 > Dec 17 19:44:48 ganerc kernel: Full duplex capable > Dec 17 19:44:48 ganerc kernel: 8K byte-wide RAM 5:3 Rx:Tx split, > autoselect/Autonegotiate interface. > Dec 17 19:44:48 ganerc kernel: MII transceiver found at address 24, status > 786d. > Dec 17 19:44:48 ganerc kernel: MII transceiver found at address 0, status > 786d. > Dec 17 19:44:48 ganerc kernel: Enabling bus-master transmits and > whole-frame receives. > Dec 17 19:44:48 ganerc kernel: eth0: using NWAY autonegotiation Ik hate everything that has the word 'auto' in it. Usually means problems. I suggest you start at that hub. The fact that you state that is is kernel independant makes me think it's not a kernel / driver bug, but that your network chokes on the autoconfig. Igmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Steeling TCP packets...
Hi, I am in the process of writing a kernel driver to support some client/server software. This software dealing mainly with packets that it sends/receives via tcp and udp. I can't really go into the architecture of that software, but for various performance reasons it has been decided we should move some of our server code into the kernel. The job of this code is mainly to route incoming client packets to the appropriate server and to route outgoing packets to the appropriate client connection. To improve the performance of the read-side we would like to grab packets early from the TCP stack. I have looked over the TCP code and have found spots in tcp_ofo_queue(), tcp_data_queue() and tcp_rcv_established() that queue incoming packets onto a sockets buffer with a call to __skb_queue_tail(>receive_queue, skb). I would like to wrap this function call with code that checks if it is one of our sockets and queue it up on our buffers rather than TCPs. The sockets themselves will never experience read() calls, but they will experience write() calls from our code. My question is what are the consequences of taking data at this point? It looks like the tcp code has handled all of the acknowledging by the time the queueing occurs, but I'm not totally sure of this. Since all data received from the client are in the form of 512 byte packets each sk_buf should contain a complete packet and thus out of order packets are not a concern. Any comments? -- phil email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
