Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregistertable
Richard Gooch wrote: > David S. Miller writes: > > Matt D. Robinson writes: > > > > This allows people to make proprietary implementations of TCP under > > > > Linux. And we don't want this just as we don't want to add a way to > > > > allow someone to do a proprietary Linux VM. > > > > > > And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't > > > do that (in a supportable way)? Are you saying Linux is, "do it my > > > way, or it's the highway"? > > Pardon my cynicism, but this reads more like "I'm an ACME Inc. and I > want to sell a proprietary TCP stack for Linux, please change Linux to > make this possible/easy". I doubt there are many Joe Users out there > who want to replace their TCP stack. I bet they would be much happier > to see patches go in which improve the performance of the generic > kernel. Performance Improvements != Innovation. If the maintainers of the Linux kernel only want evolution, not revolution, then that's fine, but it should be a bit more clear to everyone. Let's say someone wanted to come in and completely restructure devfs. And let's say 75% of the people out there loved it, but you didn't. Are you willing to stand in the way of allowing the new code to come into the kernel for sake of your exclusive opinion? And if you are willing to promote the changes, what does the community say if they don't like it? And is this thought process consistent among all maintainers? Mr. Yarroll has a great patch, one that offers some help to all kinds of developers. I worry now that it'll either not be accepted or it'll end up changing enough that developers using it will have a hard time taking advantage of its benefits. > But I'm sure there are plenty of ACME Inc.'s out there who would love > to sell a replacement TCP stack. And suck users down a proprietary > solution path. But I don't see why the Linux community should help the > ACME's of this world. And Linux is doing very nicely in the corporate > world, so we needn't to lose any sleep over what our current policies > do for our acceptance levels. > > If it bothers you that Linux caters more the the users and less to the > vendors, then use another OS. We don't mind. The door is over there. > Please don't slam it on your way out. I'm sorry, I normally wouldn't respond, but there are so many points to make. I don't mean to make this into a OSS religious war, but I'm curious: 1) Why would you limit people's ability to use solutions that are not open source? I mean, you don't do it in user space, so why bother doing it in the kernel? Doesn't the eventual goal of opening up solutions to everyone also provide room for companies to make a profit, if it does nothing to hurt the kernel's eventual dominance over other kernels? And if not, why not? 2) Why won't Linux take FreeBSD OSL'd code into the kernel without also requiring a dual license which also allows for the GNU GPL? I mean, the FreeBSD license is OSL certified, right? Or is it so important to use GPL over other OSL's that you'd rather styme innovation for the sake of purity? 3) Why take the position that if you don't like it, go to some other OS? What if I like Linux? Does that mean I have to give up all thought of using Linux because I want a proprietary solution for one or two things? Doesn't that seem completely counterintuitive to being "open"? 4) Why are Linux kernel developers turning into a community of gatekeepers who are increasingly less "open" about changes to the product? Is it really these days only what Linus wants? By that I mean, does he really control the majority of changes, or just those things he has time to look at or really cares about? All those other tree components are now maintained, some loosely, some in a draconian fashion. If someone isn't flexible, how is innovation maintained? > > If Joe's TCP is opensource, they are more than welcome to publish > > such changes. > > Yep. And then we can all benefit. And if it's released under the FreeBSD OSL, it won't be placed into the Linux kernel (at least according to one rather important maintainer). So Linux users as a whole won't benefit. And that's a real shame. Just my opinion. I just get the feeling that some of the maintainers are taking a "I'd rather cut off my nose to spite my face" stand on their beliefs rather than considering how the Linux kernel can evolve to help everyone -- even those that want to make money. The kernel can allow for both, but they (meaning the maintainers) just choose not to permit it. Maybe they just want some more of those RedHat stock options ... > Regards, > > Richard See ya, --Matt P.S. I guess the next thing on the list for the Linux kernel is to create WHQL-like process for drivers before the code can end up in newer kernel revisions. Then I'll really know things have
2.2.20 pre2 compilation broken
hi, here is the message: ld -m elf_i386 -T /mnt/hda3/linux-2.2.19/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ fs/filesystems.a \ net/network.a \ drivers/block/block.a drivers/char/char.o drivers/misc/misc.a drivers/net/net.a drivers/cdrom/cdrom.a drivers/sound/sounddrivers.o drivers/pci/pci.a drivers/video/video.a \ /mnt/hda3/linux-2.2.19/arch/i386/lib/lib.a /mnt/hda3/linux-2.2.19/lib/lib.a /mnt/hda3/linux-2.2.19/arch/i386/lib/lib.a \ --end-group \ -o vmlinux fs/filesystems.a(reiserfs.o): In function `ip_check_balance': reiserfs.o(.text+0x9dde): undefined reference to `memset' make: *** [vmlinux] Error 1 Regards, = S.KIEU _ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: I/O system call never returns if file desc is closedin the
On 7 Jun 2001, Florian Weimer wrote: > Matthias Urlichs <[EMAIL PROTECTED]> writes: > > > Select is defined as to return, with the appropriate bit set, if/when > > a nonblocking read/write on the file descriptor won't block. You'd get > > EBADF in this case, therefore causing the select to return would be a > > Good Thing. > > How do you avoid race conditions if more than one thread is creating > file descriptors? I think you can only do that under very special > circumstances, and it definitely requires some synchronization. The same way as you do it for many threads doing any allocations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On 6 Jun 2001, Eric W. Biederman wrote: > Mike Galbraith <[EMAIL PROTECTED]> writes: > > > > If you could confirm this by calling swapoff sometime other than at > > > reboot time. That might help. Say by running top on the console. > > > > The thing goes comatose here too. SCHED_RR vmstat doesn't run, console > > switch is nogo... > > > > After running his memory hog, swapoff took 18 seconds. I hacked a > > bleeder valve for dead swap pages, and it dropped to 4 seconds.. still > > utterly comatose for those 4 seconds though. > > At the top of the while(1) loop in try_to_unuse what happens if you put in. > if (need_resched) schedule(); > It should be outside all of the locks. It might just be a matter of everything > serializing on the SMP locks, and the kernel refusing to preempt itself. That did it. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: I/O system call never returns if file desc is closed in the
Matthias Urlichs <[EMAIL PROTECTED]> writes: > Select is defined as to return, with the appropriate bit set, if/when > a nonblocking read/write on the file descriptor won't block. You'd get > EBADF in this case, therefore causing the select to return would be a > Good Thing. How do you avoid race conditions if more than one thread is creating file descriptors? I think you can only do that under very special circumstances, and it definitely requires some synchronization. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
FLAME Protection ON WARNING -- Do not read if you are humor impaired. Euro-centric here? The US is mm/dd/yy or mm/dd/ Many countries/religions/peoples have different base years, and calendars... It happens to have a US format in the current kernel... so what... Convert it in the user processes... And no... I can't even buy A4 paper. Let's see In one evening ... Get American attributes out of Temperature Time Date And replace with European standards. Next week... change all comments to Esperanto. A year from now everything gets converted to Chinese with a 12 year horoscope date cycle. Then The great Hindu hack Followed by the Orthodox date change ... Others follow suit It reaches its zenith in the great Inca knot display that only obscure researchers can read and is then destroyed in when the Knot Printer tangles up the legs of every computer user on the planet. MEANWHILE... M$ developed a bug free product while all the linux hackers were rewriting the comments and I/O FLAME Protection OFF! José Luis Domingo López wrote: > > On Wednesday, 06 June 2001, at 18:06:56 +0200, > Chris Boot wrote: > > > Hi, > > > > > Please, don't. > > > > > > Use kelvins *0.1, and use them consistently everywhere. This is what > > > ACPI does, and it is probably right. > > > > I'm sorry, by I don't feel like adding 273 to every number I get just to > > find the temperature of something. What I would do is give configuration > > > What about keeping times with format similar to "06 June 2001, at 18:06:56 > +0200" instead of using miliseconds from 01 Jan 1970 ? ;) > > If there is a universally-accepted measure for temperatures, we should use > it, and let user space applications make the conversions for us. > > Just my 0.02 (eurocents :) > > -- > José Luis Domingo López > Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) > > jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias > jdomingo AT internautas DOT org => Spam at your own risk > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forcibly unmap pages in driver?
Just an update to my situation... I've implemented my idea of clearing the associated PTE's when I need to free the DMA buffer, then re-filling them in nopage(). This seems to work fine; if the user process tries anything fishy, it gets a SIGBUS instead of accessing the old mapping. I encountered two difficulties with the implementation: 1) zap_page_range(), flush_cache_range(), and flush_tlb_range() are not exported to drivers. I basically copied the guts of zap_page_range() into my driver, which seems to work OK on x86, but I know it will have trouble with architectures that require special treatment of PTE manipulation... 2) the state of mm->mmap_sem is unknown when my file_operations->release() function is called. If release() is called when the last FD closes, then mm->mmap_sem is not taken. But if release() is called from do_munmap, then mmap_sem has already been taken. So, it is risky to mess with vma's inside of release()... Regards, Dan > >> Later, the program calls the ioctl() again to set a smaller > >> buffer size, or closes the file descriptor. At this point > >> I'd like to shrink the buffer or free it completely. But I > >> can't assume that the program will be nice and munmap() the > >> region for me > > > Look at drivers/char/drm, for example. At mmap time they allocate a > > vm_ops to the address space. With that you catch changes to the vma > > structure initiated by a user mmap, munmap, etc. You could also > > dynamically map the pages in using the nopage method (optional). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
xircom_cb problems
> The patch does only one thing: it instructs the card not to negotiate > full-duplex modes, because (for undocumented and yet unexplained > reasons) > full-duplex modes don't work well on this card. > > If you had problems before, then their cause is most likely elsewhere. > 1-second ping time is definitely wrong. Well, I compiled the driver from 2.4.4-ac11, 2.4.5-ac3, and 2.4.5-ac9 all with the exact same source from 2.4.5-ac9, and my problems are 100% repeatable on my hardware. At home where I have a 10Mb half-duplex hub connection all of the drivers work properly. At work where I have a 10/100Mb full-duplex switch connection the drivers work exactly as I described before: 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep 2.4.5-ac3 -- seems to work but pings are >1 second (yes really a full second) 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" over and over when trying to pull an IP address via dhcp using pump or dhcpcd. Interestingly manually setting an IP address seems to work fine with this driver. > The thing is, I don't really see any significant differences between > the > 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, > some > power management stuff, and the half-duplex stuff. None of them should > affect the core functionality directly.. I looked at this before posting, and generally agree, but the results are 100% reproducable on my machine as listed above, so they must be having some affect. My current working system is 2.4.5-ac9 with the driver source from 2.4.4-ac11 recomiled for it and it's working great (minor resume problems aside). > Please do me a favor: comment out the call to set_half_duplex() (in > xircom_up), recompile and see if it makes a difference. I'll do this tomorrow morning when I get in and report back. Thanks for the help, I'd really like to see this card get stable as we have it in a lot of our laptops here at work. > > One other note, the version in 2.4.4-ac11 is listed as 1.33 while > the > > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > > significant problems with the newer version? The 1.33 sure seems to > work > > better for me. > > The CVS version is almost irrelevant, I guess Arjan simply rebuild his > repository. And you would be correct as Arjan confirmed in a follow up messages, sorry about that, it just looked strange. Thanks for the help, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
Alexander Viro wrote:
>
> On Thu, 7 Jun 2001, Edgar Toernig wrote:
>
> > Alexander Viro wrote:
> > > ...
> > > dir = open("/usr/local", O_DIRECTORY);
> > > /* error handling */
> > > new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
> >
> > Do you really want to start using fds instead of strings for tree
> > modifying commands (link, unlink, symlink, rename, mount and umount)?
> > Even if it were possible in the new_mount case it wouldn't have the
> > atomic lookup+act nature of the old mount. And then, _I_ would
> > prefer a uniform interface for tree management commands - strings.
>
> You have exactly the same atomicity warranties. That is to say, none.
> Mountpoint can be renamed between the lookup and mounting.
Ok. I thought, mounting is an atomic operation (though normally not
required). Hmm... but looking at your last batch of VFS patches sent
to lkml you consider mount a more used call in the future ;-) Maybe
it would be better to have some more strict rules for mount if ie each
login performs a dozen of them...
> Moreover, even after mount(2) you can rename() parent of mountpoint. On
> all Unices I've seen (well, aside of v7 which didn't have rename(2)).
> So if you rely on anything of that kind - you are screwed. Portably
> screwed, at that.
I thought more about a rename of ie "/usr/local" between the open and
the new_mount call. I guess, an unlink("/usr/local") after the open
will let the new_mount fail. Btw, what happens in this case of two
concurrent mounts?
fd1=open("/foo")
fd2=open("/foo")
new_mount(fd1...)
new_mount(fd2...) // or vice versa, first fd2 then fd1
>[...] but even if your argument makes sense, it only makes sense for
> "dir" argument. "device" is nothing but a filesystem-specific option.
Sure. I only meant the "dir" argument.
Maybe I've just an uneasy feeling about such a change because it exposes
and depends on internal implementation details of the kernel (the dcache).
On other systems it's normally not possible to associate a unique name
with a file descriptor. Newer Linux versions may support this for
directories due to the dcache (not sure if this is really always the case).
And this calling convention for new_mount would be the first one that
makes this visible in userspace. And it would depend on this feature.
This may limit future changes of the kernel VFS implementation (maybe
someone really adds some kind of hardlinked directories or something
else that makes it impossible to get a unique name for a dir fd).
Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On 06 Jun 2001 20:34:49 -0400, Mike A. Harris wrote: > On Wed, 6 Jun 2001, Derek Glidden wrote: > > >> Derek> overwhelmed. On the system I'm using to write this, with > >> Derek> 512MB of RAM and 512MB of swap, I run two copies of this > >> > >> Please see the following message on the kernel mailing list, > >> > >> 3086:Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap > >> Message-Id: <[EMAIL PROTECTED]> > > > >Yes, I'm aware of this. > > > >However, I still believe that my original problem report is a BUG. No > >matter how much swap I have, or don't have, and how much is or isn't > >being used, running "swapoff" and forcing the VM subsystem to reclaim > >unused swap should NOT cause my machine to feign death for several > >minutes. > > > >I can easily take 256MB out of this machine, and then I *will* have > >twice as much swap as RAM and I can still cause the exact same > >behaviour. > > > >It's a bug, and no number of times saying "You need twice as much swap > >as RAM" will change that fact. > > Precicely. Saying 8x RAM doesn't change it either. Sometime > next week I'm going to purposefully put a new 60Gb disk in on a > separate controller as pure swap on top of 256Mb of RAM. My > guess is after bootup, and login, I'll have 48Gb of stuff in > swap "just in case". Mike and others, I am getting tired of your comments. Sheesh. The various developers who actually work on the VM have already acknowledged the issues and are exploring fixes, including at least one patch that already exists. It seems clear that the uproar from the people who are having trouble with the new VM's handling of swap space have been heard and folks are going to fix these problems. It may not happen today or tomorrow, but soon. What the heck else do you want? Making enflammatory remarks about the current situation does nothing to help get the problems fixed, it just wastes our time and bandwidth. So please, if you have new facts that you want to offer that will help us characterize and understand these VM issues better or discover new problems, feel free to share them. But if you just want to rant, I, for one, would rather you didn't. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel oops when burning CDs
Tachino wrote: > At Mon, 4 Jun 2001 22:43:30 +0100 (BST), > Alan Cox wrote: > > > > > I get an ooops and immediate kernel panic when I break (CTRL-C) cdrecord. I > > > can reproduce it anytime. I use 2.4.5-ac series. Obviously, Linus' 2.4.5 is > > > fine. > > > I know, I know. I was supposed to make a serios oops report, BUT I wasn't > > > > Write down the EIP and the call trace then look them up in System.map. Also > > include the hardware details. The -ac tree has a newer version of the scsi > > generic code. It fixes some oopses but in your case it apparently added a new > > failure case > > Oops occures in SG driver. This patch fixes the problem. [patch snipped. It looks fine] Tachino, Thanks for the patch. Alan Cox has incorporated it in lk 2.4.5-ac9 . The problem only occurs when the sg driver is built in. [I do my testing with sg built as a module.] Currently sg version 3.1.18 is in the ac tree while the previous version (3.1.17) is in the main branch. The code that oopsed is there to temporarily bump the sg module count to inhibit rmmod (and/or autoclean) until all SCSI commands on that device are finished. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement: swap = RAM x 2.5 ??
On Wed, Jun 06, 2001 at 12:42:03PM -0600, Eric W. Biederman wrote: > Jeff Garzik <[EMAIL PROTECTED]> writes: > > I'm sorry but this is a regression, plain and simple. > > > > Previous versons of Linux have worked great on diskless workstations > > with NO swap. > > > > Swap is "extra space to be used if we have it" and nothing else. > > Given the slow speed of disks to use them efficiently when you are using > swap some additional rules apply. > > In the worse case when swapping is being used you get: > Virtual Memory = RAM + (swap - RAM). > > That cannot be improved. You can increase your likely hood that that > case won't come up, but that is a different matter entirely. I believe you are taking the right approach to the problem, which is not to complain about that we need 2*RAM, but to try and figure out _why_ we need 2*RAM. As far as I can make out, any pages that at one time got swapped out, will remain in swap. It is even there when there are no more references to the page, but will be reclaimed lazily (i.e. when we need to swap something new out). I'm assuming the reason we need SWAP > RAM is because once swap is filled only the subset of VM users that occupy this space are candidates for further swapping. I'm assuming this probably has a significant impact on long-running processes that have more chance of being pushed into swap at some point. The advantage of this is that when we need to remove a clean page that is already in swap we can simply discard the copy in ram, paying only a swap-in penalty. Dirty pages will have to be re-written, but we don't need to find a place to put them, swap is already reserved. If we wanted reclaim swap pages that were swapped into ram, we need to find a place to swap to, swap the page out, and eventually swap it back in. Obviously a lot more expensive. However, we must have pushed the page into swap because it was not 'pageable'. i.e. it got dirtied, and there is no underlying file to write it back to, shm, private mmap, or dirty heap. So there is infact a high likelyhood that the page will not be clean when we have to swap it out again. Now if we would reclaim not just dead swap pages, but also pages that have been swapped in but are dirtied, the 'additional cost' only involves finding a place to swap to. The nice thing is that with fewer used swap pages as a result of agressive reclaiming of swapped but in the mean time swapped back in and dirtied pages it should become a lot easier to find a free spot (until we are really overcommitted). I don't know how feasable it is to tell from a given swap page, whether there is a dirtied copy present in ram, but we could drop the swap reference when the copy in ram is modified, turning the swap page into a dead page and letting the regular reclamation pick it up. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Thu, 7 Jun 2001, Edgar Toernig wrote:
> Alexander Viro wrote:
> > ...
> > dir = open("/usr/local", O_DIRECTORY);
> > /* error handling */
> > new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
>
> Do you really want to start using fds instead of strings for tree
> modifying commands (link, unlink, symlink, rename, mount and umount)?
> Even if it were possible in the new_mount case it wouldn't have the
> atomic lookup+act nature of the old mount. And then, _I_ would
> prefer a uniform interface for tree management commands - strings.
You have exactly the same atomicity warranties. That is to say, none.
Mountpoint can be renamed between the lookup and mounting.
Moreover, even after mount(2) you can rename() parent of mountpoint. On
all Unices I've seen (well, aside of v7 which didn't have rename(2)).
So if you rely on anything of that kind - you are screwed. Portably
screwed, at that.
I would argue that mount(2) is seriously different from rename(2) and
friends, but even if your argument makes sense, it only makes sense for
"dir" argument. "device" is nothing but a filesystem-specific option.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
Alexander Viro wrote:
> ...
> dir = open("/usr/local", O_DIRECTORY);
> /* error handling */
> new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */
Do you really want to start using fds instead of strings for tree
modifying commands (link, unlink, symlink, rename, mount and umount)?
Even if it were possible in the new_mount case it wouldn't have the
atomic lookup+act nature of the old mount. And then, _I_ would
prefer a uniform interface for tree management commands - strings.
Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
SHM/TMPFS broken on s390x in 2.4.5
HY HY I tried 2.4.5-ac8 which includes the newest s390-Patches from IBM and I found out, that it is possible to access shared memory but when you free it, the machine crashs. The output on console seems to come from __swap_free in swapfile.c: It was a mixture of swap_free: Trying to free nonexistent swap-page swap_free: offset exceeds max If you need detailed order of those messages I could reproduce a crash for you. ;-) I reproduced it with 2.4.5 and 2.4.5-ac8 but I never tested 2.4.4, but having a quick look at the code it saw that shm changed from 2.4.3 to 2.4.4. 2.4.3 runs very stable on my architecture. For everything else 2.4.5-ac8 seems to run quite fine on zSerie. BYtE Oli +++LINUX++ +++Manchmal stehe ich sogar nachts auf und installiere mir eins+++ ++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Richard Gooch wrote: > > David S. Miller writes: > > > > Matt D. Robinson writes: > > > > This allows people to make proprietary implementations of TCP under > > > > Linux. And we don't want this just as we don't want to add a way to > > > > allow someone to do a proprietary Linux VM. > > > > > > And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't > > > do that (in a supportable way)? Are you saying Linux is, "do it my > > > way, or it's the highway"? > > Pardon my cynicism, but this reads more like "I'm an ACME Inc. and I > want to sell a proprietary TCP stack for Linux, please change Linux to > make this possible/easy". I doubt there are many Joe Users out there > who want to replace their TCP stack. I bet they would be much happier > to see patches go in which improve the performance of the generic > kernel. Maybe Joe's TCP slows things down by 200% for the average user, so it will never go into the kernel proper. However, it has one vital feature that Bob needs that the faster (normal) stack can't offer. Bob gains if he can make the choice. If the 200% slower and - some sum of $$ makes him choose Joes TCP, so be it. Joes TCP could be open source, or written by the devil himself, and the technical decision can still be made by Bob. Now, if there are legal issues with a proprietary loadable module, that may be another topic of discussion altogether. Is there any restriction on what kind of module you can load? For instance, suppose I write an ethernet driver that has a built in TCP/IP stack in it somehow? This may not be smart, but it is technically possible... > If it bothers you that Linux caters more the the users and less to the > vendors, then use another OS. We don't mind. The door is over there. > Please don't slam it on your way out. Don't spite potential users just in the hope that you might be able to spite a few companies too. There is no need for Joe's TCP to be non-open-source...a modular TCP stack might be a really good option for making $$ though support fees... If there is a need to keep certain (proprietary) code out of the kernel, let lawyers & public pressure do it, not overly broad technical restrictions. > > > If Joe's TCP is opensource, they are more than welcome to publish > > such changes. > > Yep. And then we can all benefit. Agreed. Ben -- Ben Greear <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, android wrote: >associated with that mindset that made Microsoft such a [fill in the blank]. >As for the 2.4 VM problem, what are you doing with your machine that's >making it use up so much memory? I have several processes running >on mine all the time, including a slew in X, and I have yet to see >significant swap activity. Try _compiling_ XFree86. Watch the machine nosedive. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
irqtune in kernel 2.4
Hi. I will try to keep this as informative as possible, just in case I've missed something. First off, I've already searched all the kernel archives I could, google, I've looked around on IRC for help in four different networks, I've emailed the debian hwtools package maintainer (who misdirected me to use /dev/irq to do what I wanted to do), and the irqtune author (I have not yet recieved a reply), and come up with absolutely no way to get this to work. Problem: Irqtune is not working under any 2.4 kernel I've tried as it did in kernel 2.2.x, in fact it is not doing anything at all, despite the fact it says it's working fine. The symptoms of it not working are that whenever my hard disk writes, all serial and ethernet operations stop. As you can imagine, this generates quite a bit of packet loss, which is unacceptable, especially if I have to be writing/reading at the same time the modem is going. Description of my configuration: Kernel: 2.4.5-ac7 irqtune: Debian unstable, using irqtune 0.6 from the hwtools package hdparm: version v3.9 from the debian unstable hwtools package Hardware: IBM PS/1 486 dx 50 with 16MB of ram, a add on ISA card which provides a 16550A uart for the external zoom 56K faxmodem, a NE2000 compatible ethernet card irqtune -e 7 10 output: irqtune: version is 0.6 irqtune: kernel version 0.0.0 probe: irqtune must be invoked via the full path -- OK probe: /sbin in $PATH -- YES probe: insmod found in $PATH (/sbin) -- OK probe: insmod simple execution -- OK probe: insmod has version (2.4.6) -- YES probe: rmmod found in insmod directory -- OK probe: insmod version supports command line options -- OK probe: insmod version (2.4.6) compatible with kernel version (0.0.0) -- OK probe: insmod version should be 2.1.34 (or better) -- OK probe: insmod and kernel compatible with CONFIG_MODVERSIONS -- OK probe: irqtune_mod loading will be tried -- OK probe: kernel version irqtune built under (1.0.0) matches current system -- NO probe: kernel IRQ handling is compatible -- OK probe: kernel has module support (CONFIG_MODULES) -- OK probe: kernel has symbols -- OK probe: kernel is using versions (CONFIG_MODVERSIONS) -- NO probe: kernel symbols are checksummed (CONFIG_MODVERSIONS) -- NO probe: kernel has /proc/interrupts -- OK irqtune: setting system IRQ priority to 7/10 irqtune: trying command -- insmod -x -o irqtune_mod -f /usr/lib/hwtools/irqtune_mod.o priority=7,10 Warning: kernel-module version mismatch /usr/lib/hwtools/irqtune_mod.o was compiled for kernel version 1.0.0 while this kernel is version 2.4.5-ac7 irqtune: trying command -- rmmod irqtune_mod tblread: SYNTAX 'ERR: 0' I00/P01:34152281 XT-PIC timer I01/P02: 2 XT-PIC keyboard I02/P03: 0 XT-PIC cascade I03/P11: 1 XT-PIC serial I07/P00: 5957335 XT-PIC serial I10/P03: 202481 XT-PIC NE2000 I13/P06: 0 XT-PIC fpu I14/P07: 8104967 XT-PIC ide0 I15/P08: 0 XT-PIC ide1 irqtune: complete As you can imagine I'm slightly perturbed. I think the syntax error is OK, it's likely barfing on the new 'cpu 0' part of /proc/interrupts... However the misdetection of the kernel version is making we worry, as well as the fact that although it SAYS it has done something, in fact the problems I have been having since I upgraded to 2.4.x continue. (hard disk reads/writes cause all serial/eth0 operations to generate massive PL) hdparm /dev/hda output: /dev/hda: multcount= 0 (off) I/O support = 0 (default 16-bit) unmaskirq= 1 (on) using_dma= 0 (off) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 4956/16/63, sectors = 4996476, start = 0 As you can see, I've enabled unmaskirq, as it has been reported to help in my situation... It does in fact, although I wish I had a way to get irqtune working again. Note that DMA is NOT available on this old system, and I will actually go back to a 2.2.x kernel rather than spend money on a dma compatible controller if irqtune or another solution cannot be found. I will accept any ideas anyone has to offer. If irqtune is obsolete, please say so. If there is an in kernel solution PLEASE say so. (/dev/irq is used for smp systems. This is a single cpu system) If there is NO present solution, please tell me that too. :) I am quite willing to downgrade my system to kernel 2.2 if this can't be fixed somehow, kernel 2.2.x works just fine on my old 486, although kernel 2.4.x tends to simply do some things better. (It's VM, although some report it to do strange things, manages memory better in many cases on my 486 - less disk thrashing when it swaps things, runs obese perl scripts etc.) The fact I'd be missing out on reiserfs in the kernel makes me sad though, I really do like that filesystem. Anyway, please reply to the list with ideas, I'll see them. Timothy
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Dr S.M. Huen wrote: >> For large memory boxes, this is ridiculous. Should I have 8GB of swap? >> > >Do I understand you correctly? >ECC grade SDRAM for your 8GB server costs £335 per GB as 512MB sticks even >at today's silly prices (Crucial). Ultra160 SCSI costs £8.93/GB as 73GB >drives. Linux is all about technical correctness, and doing the job properly. It isn't about "there is a bug in the kernel, but that is ok because a 8Gb swapfile only costs $2" Why are half the people here trying to hide behind this diskspace is cheap argument? If we rely on that, then Linux sucks shit. The problem IMHO is widely acknowledged by those who matter as an official BUG, and that is that. It is also acknowledged widely by those who can fix the problem that it will be fixed in time. So technically speaking - the kernel has a widely known bug/misfeature, which is acknowledged by core kernel developers as needing fixing, and that it will get fixed at some point. Saying it is a nonissue due to the cost of hardware resources is just plain Microsoft attitude and holds absolutely zero technical merit. It *IS* an issue, because it is making Linux suck, and is causing REAL WORLD PROBLEMS. The use 2x RAM is nothing more than a bandaid workaround, so don't claim that it is the proper fix due to big wallet size. I have 2.2 doing a software build that takes 40 minutes with 256Mb of RAM, and 1G of swap. The same build on 2.4 takes 60 minutes. That is 4x RAM for swap. Lowering the swap down to 2x RAM makes no difference in the numbers, down to 1x RAM the 2.4 build slows down horrendously, and droping the swap to 20Mb makes it die completely in 2.4. 2.4 is fine for a firewall, or certain other applications, but regardless of the amount of SWAP, I'll take the 40minute build using 2.2 over the 60minute build using 2.4 anyday. This is the real world. And no cost isn't an issue to me. Putting another 80Gb drive in this box for swap isn't going to help the work get done any faster. -- Mike A. Harris - Linux advocate - Open Source advocate Opinions and viewpoints expressed are solely my own. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2 yenta_socket problems on ThinkPad 240
I upgraded my IBM ThinkPad 240 (Type 2609-31U) from Red Hat 7.0 to Red Hat 7.1, which uses the 2.4.2 kernel and the kernel PCMCIA drivers. Before the upgrade, all my CardBus and PCMCIA devices were working fine. Now the yenta_socket module seems to be causing problems, and none of the cards work. Before doing 'modprobe yenta_socket', the PCI stuff looks OK: % ls -l /proc/bus/pci total 0 dr-xr-xr-x2 rootroot0 Jun 1 12:52 00 -r--r--r--1 rootroot0 Jun 1 12:52 devices % ls /proc/bus/pci/00 00.0 07.0 07.1 07.2 07.3 09.0 0a.0 0b.0 0c.0 and lspci -vvv gives normal-looking output (which I can send if it's useful). After the 'modprobe yenta_socket': % ls -l /proc/bus/pci total 0 dr-xr-xr-x2 rootroot0 Jun 1 12:44 00 dr-xr-xr-x2 rootroot0 Jun 1 12:44 00 -r--r--r--1 rootroot0 Jun 1 12:44 devices Note the two directories with the same name. % ls -l /proc/bus/pci/00 total 0 -rw-r--r--1 rootroot0 Jun 1 12:48 00.0 % lspci -vvv pcilib: Cannot open /proc/bus/pci/00/0c.0 Has anyone seen similar behavior? Is there any way to force yenta_socket to assign the cardbus to be bus 01 rather than 00? Thanks! Eric Smith - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RTL8139, IRQ sharing, etc.
On Fri, 01 Jun 2001, Matthias Andree wrote: > Not sure if it's related to IRQ sharing or another initialization issue. Looks like IRQ sharing is still in the play. Yesterday, I purchased a pair of used 3C905TXs, replaced the RTL 8139 by the 3C905, and got complaints by the 3C905 about "eth0: Interrupt posted but not delivered -- IRQ blocked by another device?" (Linux 2.2.19). The other card on the same IRQ is a Brooktree 878. I then swapped the Bt878 and the 3C900 (not 3C905!) and got no more complaints, now, the Bt878 can keep its IRQ to itself, and the two 3Com cards share the IRQ. Seems both NICs are fine. TV is also fine. Strange. Might the BT 878 PCI AND the NVidia AGP card be the culprits? Cheers, Matthias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Matt D. Robinson writes: > > This allows people to make proprietary implementations of TCP under > > Linux. And we don't want this just as we don't want to add a way to > > allow someone to do a proprietary Linux VM. > > And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't > do that (in a supportable way)? Are you saying Linux is, "do it my > way, or it's the highway"? If Joe's TCP is opensource, they are more than welcome to publish such changes. The loadable module functionality allows proprietary binary-only drivers for devices, not binary-only proprietary reimplementations of core parts of the kernel. Ask Linus himself if you do not believe me and you think my position stinks. He's the person you have to convince in the end. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
> On Wed, 6 Jun 2001, Kipp Cannon wrote: > > > If the kernel tells me the temperature is 1 (one) what should that mean? > > If it's spitting out 0.1* as people are claiming the > > ACPI stuff does then 1 means 10 kelvin or 1 dekakelvin, not a > > > > decikelvin as other people are saying they would prefer to see used. Or > > are people being braindamaged and by "0.1*K" they mean that ACPI spits out > > 10*? Which would then mean that everyone does agree > > afterall that the unit should be a decikelvin although they don't > > necessarily know what multiplication means :-). > > I do believe that by 0.1*K everyone means a basic unit of 0.1 K, i.e. with > an int of 1 meaning 0.1 Kelvin, analogically 0.01*K meaning an int of 1 > means 0.01 Kelvin - hence the proper names of deci and centi-Kelvins. > > Perosnally I believe we should take normal (32 bit) ints (perhaps more on > 64bit architectures?) and encode using 0.001*K (i.e. miliKelvins), One question here which has been bugging me all through this thread, is there any hardware that actually measures to that precision and accuracy ?? certanally 0.1K intervals, but 0.01 ?, and at 0.001K intervals ? is this going ott ? and what use would people have with measureing system temp to 0.01K precision ? --i would assume that the accuracy of the temp sensors is less than that... well, there are my two cents ... > I do believe space is not an issue here and this leaves us the most > precision and logical system - Farenhait is screwed, and > Celsius/Centigrade are not to good since don't begin at absolute zero. > Farenhait is irritating, yes, and the brits that suggested it are becoming a dying bread, although still large in number, things more so use Celsius nowerdays. btw, the kelvin scale is a centigrade scale, like wise, so is the celsius scale ... Thanks,, Dave > Anyway just my two cents. > > Maciej. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
"David S. Miller" wrote: > > La Monte H.P. Yarroll writes: > > Matt D. Robinson writes: > > > Is there any way to add in the capability to _replace_ TCP with > > > your own, so you can use your own layer? > > ABSOLUTELY NOT! > > And I will never in my lifetime allow such a facility to be added to > the Linux kernel. Who's to say you will always own the stack in the Linux kernel, or have the right to make such a statement? > This allows people to make proprietary implementations of TCP under > Linux. And we don't want this just as we don't want to add a way to > allow someone to do a proprietary Linux VM. And if as Joe User I don't want Linux TCP, but Joe's TCP, they can't do that (in a supportable way)? Are you saying Linux is, "do it my way, or it's the highway"? Seems rather Microsoft-ish of an attitude, if you ask me. I think this is EXACTLY the reason why you run into companies like Caldera and Microsoft saying that Linux stifles innovation. You say, "Oh, we allow you to do whatever you want", and when someone really does want to do that in a way that works for open source and for proprietary/high-security developers, you slam the door in their face. Quite a shame. Take it easy, --Matt > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi_scan fix (for usb)
Recently I reported for 2.4.3 and 2.4.5 a failure to detect
a USB CF card reader caused by the occurrence of a Unit Attention
at boot time. An ugly solution is to remove this "error" in
usb/storage/transport.c, but since this is perfectly normal
SCSI behaviour, and can in principle occur with all kinds of
hosts and drivers, it is probably better to test for Unit Attention
is scan_scsis. (In the good old days we did TEST UNIT READY there,
but not anymore.)
No doubt the actual test will have to become more complicated,
but I just wrote the minimum required to make my hardware work.
The things other than in scsi_scan.c are just minor polishing.
For example, sd.c printed an "extended sense code" that was in
reality the sense key. I started adding ASC and ASCQ, but we
already have a function for that in constants.c.
Andries
diff -u --recursive --new-file ../linux-2.4.5/linux/drivers/scsi/constants.c
./linux/drivers/scsi/constants.c
--- ../linux-2.4.5/linux/drivers/scsi/constants.c Mon Jan 15 22:08:15 2001
+++ ./linux/drivers/scsi/constants.cThu Jun 7 00:36:41 2001
@@ -689,7 +689,7 @@
kdev_t dev)
{
int i, s;
-int sense_class, valid, code;
+int sense_class, valid, code, info;
const char * error = NULL;
sense_class = (sense_buffer[0] >> 4) & 0x07;
@@ -701,11 +701,14 @@
if(s > SCSI_SENSE_BUFFERSIZE)
s = SCSI_SENSE_BUFFERSIZE;
- if (!valid)
- printk("[valid=0] ");
- printk("Info fld=0x%x, ", (int)((sense_buffer[3] << 24) |
- (sense_buffer[4] << 16) | (sense_buffer[5] << 8) |
- sense_buffer[6]));
+ info = ((sense_buffer[3] << 24) | (sense_buffer[4] << 16) |
+ (sense_buffer[5] << 8) | sense_buffer[6]);
+ if (info || !valid) {
+ printk("Info fld=0x%x", info);
+ if (!valid) /* info data not according to standard */
+ printk(" (nonstd)");
+ printk(", ");
+ }
if (sense_buffer[2] & 0x80)
printk( "FMK ");/* current command has read a filemark */
if (sense_buffer[2] & 0x40)
diff -u --recursive --new-file ../linux-2.4.5/linux/drivers/scsi/scsi_scan.c
./linux/drivers/scsi/scsi_scan.c
--- ../linux-2.4.5/linux/drivers/scsi/scsi_scan.c Sun Apr 8 19:10:01 2001
+++ ./linux/drivers/scsi/scsi_scan.cThu Jun 7 00:10:27 2001
@@ -328,8 +328,8 @@
}
/*
-* We need to increment the counter for this one device so we can track when
-* things are quiet.
+* We need to increment the counter for this one device so we can track
+* when things are quiet.
*/
if (hardcoded == 1) {
Scsi_Device *oldSDpnt = SDpnt;
@@ -485,8 +485,8 @@
SDpnt->type = -1;
/*
-* Assume that the device will have handshaking problems, and then fix this
-* field later if it turns out it doesn't
+* Assume that the device will have handshaking problems, and then fix
+* this field later if it turns out it doesn't
*/
SDpnt->borken = 1;
SDpnt->was_reset = 0;
@@ -524,9 +524,21 @@
SCSI_LOG_SCAN_BUS(3, printk("scsi: INQUIRY %s with code 0x%x\n",
SRpnt->sr_result ? "failed" : "successful", SRpnt->sr_result));
+ /*
+* Now that we don't do TEST_UNIT_READY anymore, we must be prepared
+* for media change conditions here, so cannot require zero result.
+*/
if (SRpnt->sr_result) {
- scsi_release_request(SRpnt);
- return 0; /* assume no peripheral if any sort of error */
+ if ((driver_byte(SRpnt->sr_result) & DRIVER_SENSE) != 0 &&
+ (SRpnt->sr_sense_buffer[2] & 0xf) == UNIT_ATTENTION &&
+ SRpnt->sr_sense_buffer[12] == 0x28 &&
+ SRpnt->sr_sense_buffer[13] == 0) {
+ /* not-ready to ready transition - good */
+ } else {
+ /* assume no peripheral if any other sort of error */
+ scsi_release_request(SRpnt);
+ return 0;
+ }
}
/*
diff -u --recursive --new-file ../linux-2.4.5/linux/drivers/scsi/sd.c
./linux/drivers/scsi/sd.c
--- ../linux-2.4.5/linux/drivers/scsi/sd.c Fri May 25 18:54:50 2001
+++ ./linux/drivers/scsi/sd.c Wed Jun 6 23:58:46 2001
@@ -861,8 +861,7 @@
driver_byte(the_result)
);
if (driver_byte(the_result) & DRIVER_SENSE)
- printk("%s : extended sense code = %1x \n",
- nbuff, SRpnt->sr_sense_buffer[2] & 0xf);
+ print_req_sense("sd", SRpnt);
else
printk("%s : sense not available. \n", nbuff);
diff -u --recursive --new-file ../linux-2.4.5/linux/drivers/usb/storage/debug.c
Re: Break 2.4 VM in five easy steps
[EMAIL PROTECTED] (Alexander Viro) wrote on 06.06.01 in
<[EMAIL PROTECTED]>:
> On Wed, 6 Jun 2001, Sean Hunter wrote:
>
> > This is completely bogus. I am not saying that I can't afford the swap.
> > What I am saying is that it is completely broken to require this amount
> > of swap given the boundaries of efficient use.
>
> Funny. I can count many ways in which 4.3BSD, SunOS{3,4} and post-4.4 BSD
> systems I've used were broken, but I've never thought that swap==2*RAM rule
> was one of them.
As a "will break without" rule, I'd consider a kernel with that property
completely unsuitable for production use. I certainly don't remember
thinking of that as more than a recommendation back when I used commercial
Unices (SysVsomething).
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Wed, 6 Jun 2001, Kipp Cannon wrote: > If the kernel tells me the temperature is 1 (one) what should that mean? > If it's spitting out 0.1* as people are claiming the > ACPI stuff does then 1 means 10 kelvin or 1 dekakelvin, not a > > decikelvin as other people are saying they would prefer to see used. Or > are people being braindamaged and by "0.1*K" they mean that ACPI spits out > 10*? Which would then mean that everyone does agree > afterall that the unit should be a decikelvin although they don't > necessarily know what multiplication means :-). I do believe that by 0.1*K everyone means a basic unit of 0.1 K, i.e. with an int of 1 meaning 0.1 Kelvin, analogically 0.01*K meaning an int of 1 means 0.01 Kelvin - hence the proper names of deci and centi-Kelvins. Perosnally I believe we should take normal (32 bit) ints (perhaps more on 64bit architectures?) and encode using 0.001*K (i.e. miliKelvins), I do believe space is not an issue here and this leaves us the most precision and logical system - Farenhait is screwed, and Celsius/Centigrade are not to good since don't begin at absolute zero. Anyway just my two cents. Maciej. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NFS caching issues on 2.4
> " " == Phil Oester <[EMAIL PROTECTED]> writes: > I've stumbled upon a wierd NFS caching issue on 2.4 which does > not seem to exist in 2.2. Our www docroot is NFS mounted on a > NetApp 760. We have a cron job which make changes to the > index.html every 5 minutes. > Recently, we upgraded all the web servers to 2.4 and noticed > that there were big delays in seeing these 5 minute updates. > Yet, an ls -l in the nfs directory on each of the servers > clearly shows the new timestamp. However, a cat of the file > shows that it is the old version (sometimes up to 1 hour old). > I was using NFSv3, so decided to try NFSv2, but got the same > results. > I reverted to 2.2.19 on the boxes (which are RedHat 7.1 > incidentally), and these problems went away. > Any ideas why this is happening? The main suspect would be if you're mmapping the file while the cron job updates your file on the server. This would means that the cache invalidation breaks (see all the conditions in invalidate_inode_pages()). Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
At 11:27 pm +0100 6/6/2001, android wrote: >> >I'd be happy to write a new routine in assembly >> >>I sincerely hope you're joking. >> >>It's the algorithm that needs fixing, not the implementation of that >>algorithm. Writing in assembler? Hope you're proficient at writing in >>x86, PPC, 68k, MIPS (several varieties), ARM, SPARC, and whatever other >>architectures we support these days. And you darn well better hope every >>other kernel hacker is as proficient as that, to be able to read it. >As for the algorithm, I'm sure that >whatever method is used to handle page swapping, it has to comply with >the kernel's memory management scheme already in place. That's why I would >need the details so that I wouldn't create more problems than already present. Have you actually been following this thread? The algorithm has been discussed and at least one alternative brought forward. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) The key to knowledge is not to rely on people to teach you it. GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
In article <002e01c0eead$03c6d890$[EMAIL PROTECTED]> you wrote: >> 2.4.5-ac9 >> o Fix xircom_cb problems with some cisco kit (Ion Badulescu) > One other note, the version in 2.4.4-ac11 is listed as 1.33 while the > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > significant problems with the newer version? The 1.33 sure seems to work > better for me. It went backwards because I switched from my local CVS repository to the tulip driver one. I appologize for the driver not working as well as expected, and will try to find a way to make it work for everyone . Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] New life for Serial mice
> > It would be nice if we had > > > > 1) A seperate serial directory under drivers. > > > > 2) A nice structure that input devices and the tty layer can use. It is > >just a waste to go threw the tty layer for input devices. It would also > >make serial driver writing easier if the api is designed right :-) > > I am planning some day (don't know when yet though) to convert the 16x50 > driver over to the serial_core stuff. I ported it over to my tree. I will have to figure out how to incorporate the input serial stuff without breaking all the input drivers we have. In CVS we have alot of them. This will make life so much easier since all I will have to do is change one file for changes I make to the tty layer. I have improved andrew mortons console patch to work with multiple consoles and for different types of console devices. Instead of altering all the console drivers I'm planning on intergrating the locking into the tty layer. That patch is needed for serial devices as well as video terminals. Your work might help speed up devleopement. > NB, Ted Tytso mentioned something at the 2.5 conference about integrating > some of the serial layer with the tty layer. What does he have in mind? I like to keep my VT changes in sync with what he has in mind. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On 06 Jun 2001 15:27:57 -0700, android wrote: > >I sincerely hope you're joking. > > I realize that assembly is platform-specific. Being that I use the IA32 class > machine, that's what I would write for. Others who use other platforms could > do the deed for their native language. no, look at the code. it is not going to benefit from assembly (assuming you can even implement it cleanly in assembly). its basically an iteration of other function calls. doing a new implementation in assembly for each platform is not feasible, anyhow. this is the sort of thing that needs to be uniform. this really has nothing to do with the "iron" of the computer -- its a loop to check and free swap pages. assembly will not provide benefit. -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
hi, I have a problem with kswapd, it takes suddenly 98 % CPU and crash my server I dono why, I have a linux kernel 2.2.17 debian distro if anyone can help me ... thx ;) Antoine - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FW: Kernel 2.4.4 fails to boot
Hi Chaps, I cannot get a newly compiled 2.4.4 kernel to boot. I've searched several archives but have not found a suitable answer. Can someone please point me to a suitable FAQ ? Fails at: Loading linux ... Uncompressing Linux... Ok, booting kernel. Same result with kernel versions 2.4.2 and 2.4.3. Thanks and sorry for asking what must be a common question. Clive - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
> >I'd be happy to write a new routine in assembly > >I sincerely hope you're joking. > >It's the algorithm that needs fixing, not the implementation of that >algorithm. Writing in assembler? Hope you're proficient at writing in >x86, PPC, 68k, MIPS (several varieties), ARM, SPARC, and whatever other >architectures we support these days. And you darn well better hope every >other kernel hacker is as proficient as that, to be able to read it. I realize that assembly is platform-specific. Being that I use the IA32 class machine, that's what I would write for. Others who use other platforms could do the deed for their native language. As for the algorithm, I'm sure that whatever method is used to handle page swapping, it has to comply with the kernel's memory management scheme already in place. That's why I would need the details so that I wouldn't create more problems than already present. Being that most users are on the IA32 platform, I'm sure they wouldn't reject an assembly solution to this problem. As for kernel acceptance, that's an issue for the political eggheads. Not my forte. :-) -- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
>I'd be happy to write a new routine in assembly I sincerely hope you're joking. It's the algorithm that needs fixing, not the implementation of that algorithm. Writing in assembler? Hope you're proficient at writing in x86, PPC, 68k, MIPS (several varieties), ARM, SPARC, and whatever other architectures we support these days. And you darn well better hope every other kernel hacker is as proficient as that, to be able to read it. IOW, no chance. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) The key to knowledge is not to rely on people to teach you it. GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sockreg2.4.5-05 inet[6]_create() register/unregister table
Thanks! I'm glad you like our code. This patch does allow you to override TCP with a new implementation for new connections and then back out safely to the old TCP later. I think the feature you are asking for (replace TCP for EXISTING connections) is quite dangerous. You COULD grub around in existing sock structures and replace the proto_ops, but that would not be enough. We are talking about a stateful protocol here--your "TCP2" module would have to safely extract the state of the existing TCP connections and replace the control functions all as an atomic operation...and then undo that at the end. What was the application you had in mind? The applications we have been playing with do not suffer greatly from having to start new connections. Matt D. Robinson writes: > Is there any way to add in the capability to _replace_ TCP with > your own, so you can use your own layer? I guess you could > inet_unregister_protosw() of the IPPROTO_TCP, but does that > address outstanding connections? I don't believe so ... > > It would be nice if your patch offered that capability. Nice > work, BTW -- not enough compliments go out on lkml these days. :) > > --Matt > > "La Monte H.P. Yarroll" wrote: > > > > Here is the register/unregister inet[6]_create() table patch revised > > for 2.4.5. We thank Dave Miller for his helpful feedback on earlier > > versions of this patch. > > > > DESCRIPTION > > This patch adds a mechanism for registering new IP transport protocols > > for the socket() system call. It replaces the hard-coded switch > > tables in inet_create() and inet6_create() with explicit data > > structures. > > > > The new calls are: > > voidinet_register_protosw(struct inet_protosw *p); > > voidinet_unregister_protosw(struct inet_protosw *p); > > voidinet6_register_protosw(struct inet_protosw *p); > > voidinet6_unregister_protosw(struct inet_protosw *p); > > > > This is the first of a series of proposed changes to support IP > > transport modules. > > > > MOTIVATION > > As part of the effort to create the Linux Kernel implementation of > > SCTP , we seek to make it > > possible to load a new IP transport protocol as a kernel module. > > > > It is already possible to register new address families. It is even > > possible to register new transport protocols with IP. However, in > > order to be able to open a socket with a new transport protocol, you > > must replace the whole AF_INET address family. > > > > In addition to SCTP, there are other protocols which could find it > > useful to be in a kernel module. For example, TCP extensions like TCP > > framing and TCP over satellite, multicast protocols, and RTP/ROHC > > (robust header compression). In general, support for IP transport > > modules makes transport layer experimentation easier. > > > > CHANGES SINCE sockreg2.4.3-04 > > We noticed that inet6_protocol_base went away in 2.4.5, so we changed > > our v6 initialization to parallel the inet6_protocol initialization. > > We now call inet6_register_protosw() from *v6_init() instead of having > > a static array of struct protosw's. Since other protocols depend on > > raw sockets (e.g. ICMP, IGMP, NDISC) we still register rawv6_protosw > > in inet6_init(). > > > > piggy (La Monte H.P. Yarroll) > > Karl O. Knutson > > > > PATCH FOLLOWS > > diff -u -r linux-2.4.5/include/asm-alpha/socket.h linux/include/asm-alpha/socket.h > > --- linux-2.4.5/include/asm-alpha/socket.h Sat Feb 3 13:26:44 2001 > > +++ linux/include/asm-alpha/socket.hMon Jun 4 11:11:30 2001 > > @@ -66,6 +66,7 @@ > > /* level. For writing rarp and */ > > /* other similar things on the */ > > /* user level. */ > > +#defineSOCK_MAX(SOCK_PACKET+1) > > #endif > > > > #endif /* _ASM_SOCKET_H */ > > diff -u -r linux-2.4.5/include/asm-arm/socket.h linux/include/asm-arm/socket.h > > --- linux-2.4.5/include/asm-arm/socket.hSat Feb 3 13:26:44 2001 > > +++ linux/include/asm-arm/socket.h Mon Jun 4 11:11:30 2001 > > @@ -58,6 +58,7 @@ > > /* level. For writing rarp and */ > > /* other similar things on the */ > > /* user level. */ > > +#defineSOCK_MAX(SOCK_PACKET+1) > > #endif > > > > #endif /* _ASM_SOCKET_H */ > > diff -u -r linux-2.4.5/include/asm-cris/socket.h linux/include/asm-cris/socket.h > > --- linux-2.4.5/include/asm-cris/socket.h Fri Apr 6 12:51:19 2001 > > +++ linux/include/asm-cris/socket.h Mon Jun 4 11:11:30 2001 > > @@ -59,6 +59,7 @@ > > /* level. For writing rarp and */ > > /* other similar
Re: Break 2.4 VM in five easy steps
"Eric W. Biederman" wrote: > The hard rule will always be that to cover all pathological cases swap > must be greater than RAM. Because in the worse case all RAM will be > in thes swap cache. That this is more than just the worse case in 2.4 > is problematic. I.e. In the worst case: > Virtual Memory = RAM + (swap - RAM). Hmmmso my 512M laptop only really has 256M? Um...I regularlly run more than 256M of programs. I don't want it to swap -- its a special, weird condition if I do start swapping. I don't want to waste 1G of HD (5%) for something I never want to use. IRIX runs just fine with swap You can't improve the worst case. We can improve the worst case that > many people are facing. --- Other OS's don't have this pathological 'worst case' scenario. Even my Windows [vm]box seems to operate fine with swap It's worth complaining about. It is also worth digging into and find > out what the real problem is. I have a hunch that this hole > conversation on swap sizes being irritating is hiding the real > problem. --- Okay, admission of ignorance. When we speak of "swap space", is this term inclusive of both demand paging space and swap-out-entire-programs space or one or another? -linda -- The above thoughts and | They may have nothing to do with writings are my own. | the opinions of my employer. :-) L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler <[EMAIL PROTECTED]> wrote: >> 2.4.5-ac9 > >> o Fix xircom_cb problems with some cisco kit (Ion Badulescu) > > I'm not sure what this is supposed to fix, but it makes my Xircom > RBEM56G-100 almost useless on my network at the office. Actually, I can't > quite blame just this patch, it only makes the problem worse, the driver > from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely > works at all, it seems to think the link is not there, at least not enough > to pull an IP address. The patch does only one thing: it instructs the card not to negotiate full-duplex modes, because (for undocumented and yet unexplained reasons) full-duplex modes don't work well on this card. If you had problems before, then their cause is most likely elsewhere. 1-second ping time is definitely wrong. > The last driver that worked moderately well for me was the one from > 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything > worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco > 6509. I must admist that I haven't tested every version in between. The thing is, I don't really see any significant differences between the 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, some power management stuff, and the half-duplex stuff. None of them should affect the core functionality directly.. Please do me a favor: comment out the call to set_half_duplex() (in xircom_up), recompile and see if it makes a difference. > One other note, the version in 2.4.4-ac11 is listed as 1.33 while the > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > significant problems with the newer version? The 1.33 sure seems to work > better for me. The CVS version is almost irrelevant, I guess Arjan simply rebuild his repository. Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On 06.06 Pavel Machek wrote: > > ACPI is already using 0.1*K, so everything should use that to be > consistent. > Pavel Which is the data type for temperature ? Would not it be better to use 0.01*K ? So you get the full accuracy of a short. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Reap dead swap cache earlier v2
Hi,
As suggested by Linus, I've cleaned the reapswap code to be contained
inside an inline function. (yes, the if statement is really ugly)
Tested and against 2.4.6pre1.
--- linux.orig/mm/vmscan.c Wed Jun 6 18:16:45 2001
+++ linux/mm/vmscan.c Wed Jun 6 18:28:26 2001
@@ -407,6 +407,27 @@
memory_pressure++;
return page;
}
+/*
+ * Check for dead swap cache pages and clean them, forcing
+ * those pages to be freed earlier.
+ */
+static inline int clean_dead_swap_page (struct page* page)
+{
+ int ret = 0;
+ if (!TryLockPage (page)) {
+ if (PageSwapCache(page) && PageDirty(page) &&
+ (page_count(page) - !!page->buffers) == 1 &&
+ swap_count(page) == 1) {
+ ClearPageDirty(page);
+ ClearPageReferenced(page);
+ page->age = 0;
+ ret = 1;
+ }
+ UnlockPage(page);
+ }
+ return ret;
+}
+
/**
* page_launder - clean dirty inactive pages, move to inactive_clean list
@@ -456,6 +477,12 @@
continue;
}
+ /*
+* Check for dead swap cache pages
+* before doing any other checks.
+*/
+ clean_dead_swap_page(page);
+
/* Page is or was in use? Move it to the active list. */
if (PageReferenced(page) || page->age > 0 ||
page->zone->free_pages > page->zone->pages_high ||
@@ -666,6 +693,15 @@
printk("VM: refill_inactive, wrong page on list.\n");
list_del(page_lru);
nr_active_pages--;
+ continue;
+ }
+
+ /*
+* Special case for dead swap cache pages.
+*/
+ if (clean_dead_swap_page(page)) {
+ deactivate_page_nolock(page);
+ nr_deactivated++;
continue;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] timer vector printed inconsistently
When trying to debug a recent problem with some interrupt routing,
I found the output to be confusing... The TIMER vector is
printed with %d, but when the APIC tables are printed, the vector
is printed using %02X. This was particularly confusing in this case
because the TIMER vector was 49d (0x31) and vector 0x49 was
assigned to a different APIC pin.
The following patch causes the TIMER vector to be printed the same
way as the vectors in the APIC table (See line 786 of my io_apic.c)
I'm not a subscriber of the kernel mailing list, so please CC my on
any replies.
--- arch/i386/kernel/io_apic.c.orig Tue Jun 5 17:30:12 2001
+++ arch/i386/kernel/io_apic.c Tue Jun 5 17:34:38 2001
@@ -1489,7 +1489,7 @@
pin1 = find_isa_irq_pin(0, mp_INT);
pin2 = find_isa_irq_pin(0, mp_ExtINT);
- printk(KERN_INFO "..TIMER: vector=%d pin1=%d pin2=%d\n", vector, pin1, pin2);
+ printk(KERN_INFO "..TIMER: vector=%02X pin1=%d pin2=%d\n", vector, pin1, pin2);
if (pin1 != -1) {
/*
--
Philip Pokorny, Senior Engineer
http://www.penguincomputing.com
Penguin Computing - The World's Most Reliable Linux Systems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Hi, It seems that a lot of people are agreeing that the unit should be a multiple of 1 kelvin but to my eyes there are two camps and I just want to make sure that everyone's being clear with their notation. If the kernel tells me the temperature is 1 (one) what should that mean? If it's spitting out 0.1* as people are claiming the ACPI stuff does then 1 means 10 kelvin or 1 dekakelvin, not a decikelvin as other people are saying they would prefer to see used. Or are people being braindamaged and by "0.1*K" they mean that ACPI spits out 10*? Which would then mean that everyone does agree afterall that the unit should be a decikelvin although they don't necessarily know what multiplication means :-). -Kipp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
>Is anybody interested in making "swapoff()" better? Please speak up.. > > Linus I'd be happy to write a new routine in assembly, if I had a clue as to how the VM algorithm works in Linux. What should swapoff do if all physical memory is in use? How does the swapping algorithm balance against cache memory? Can someone point me to where I can find the exact details of the VM mechanism in Linux? Thanks! -- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
pcap_setfilter: to dump the unread packets
Hi, I am using libpcap 0.6 on Linux to capture packets from the interface. In my application I am using pcap_setfilter to modify the filter for capturing packets from the interface. But after filter has been modified the libpcap retains the packets that libpcap had got using the old filter (ie before pcap_setfilter is called) This filtering is done using a socket. So in pcap_setfilter is there any way we can "dump" all the 'unread' packets captured using the old filter which are present in the socket's buffer ? thanks a lot Ashley _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 01:20:53PM -0700, James Simmons wrote: > Never noticed it until now. Very nice patch :-) I have to agree as well. > It would be nice if we had > > 1) A seperate serial directory under drivers. > > 2) A nice structure that input devices and the tty layer can use. It is >just a waste to go threw the tty layer for input devices. It would also >make serial driver writing easier if the api is designed right :-) I am planning some day (don't know when yet though) to convert the 16x50 driver over to the serial_core stuff. NB, Ted Tytso mentioned something at the 2.5 conference about integrating some of the serial layer with the tty layer. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
In article <[EMAIL PROTECTED]>, Harald Welte <[EMAIL PROTECTED]> wrote: > >Is there any way to read out the compile-time HZ value of the kernel? In 2.4.x, you'll get it on the stack as one of the ELF auxilliary entries (AT_CLKTCK). Strictly speaking that's the "frequency at which 'times()' counts", ie the kernel CLOCKS_PER_SEC, not HZ. But from a user perspective the two should hopefully always be the same (if any of the /proc fields etc should really use CLOCKS_PER_SEC, not HZ). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Wed, Jun 06, 2001 at 08:59:51PM +0200, Tomas Telensky wrote: > > On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote: > > > > Hi! > > > > > > > > Is there any way to read out the compile-time HZ value of the kernel? > > > > > > Why simply #include ? > > > > because the include file doesn't say anything about the HZ value of > > the currently running kernel, but only about some kernel source somewhere > > on your harddrive? > > This _SHOULD_ correspond on each linux instalation. But if you would > distribute a binary to other people it's a problem. I my initial mail I wrote that I'm talking about user-mode-linux. So for example you compile a program, copy it into your user-mode-linux filesystem, and it won't work anymore. (recompiling is also not an option, who has a kernel source installed inside his user-mode-linux root filesystem). and what happens if you recompile your kernel with a different HZ (because of tc's TBF or something)... then you would have to recompile your userspace application afterwards? nah. That's not a solution. I'd say: - Either change all sysctl variables to be HZ-independent, or - Create a sane way to read HZ from the running kernel. Everything else is broken, from my point of view. > Tomas -- 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Followup to: <[EMAIL PROTECTED]> By author:Peter Svensson <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Kelvin (decikelvin?) is probably a good unit to use in the kernel. If you > want something else you convert it in the programs you use to interact > with the kernel. This is a usespace issue, I think. > Decikelvins is a good bet if we feel that fitting into 16 bits is a necessary, or the width of things is limited. Otherwise I would go for millikelvins on the general principle that creating interfaces too narrow is really painful. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
In article <[EMAIL PROTECTED]>, Derek Glidden <[EMAIL PROTECTED]> wrote: > >After reading the messages to this list for the last couple of weeks and >playing around on my machine, I'm convinced that the VM system in 2.4 is >still severely broken. Now, this may well be true, but what you actually demonstrated is that "swapoff()" is extremely (and I mean _EXTREMELY_) inefficient, to the point that it can certainly be called broken. It got worse in 2.4.x not so much due to any generic VM worseness, as due to the fact that the much more persistent swap cache behaviour in 2.4.x just exposes the fundamental inefficiencies of "swapoff()" more clearly. I don't think the swapoff() algorithm itself has changed, it's just that the algorithm was always exponential, I think (and because of the persistent swap cache, the "n" in the algorithm became much bigger). So this is really a separate problem from the general VM balancing issues. Go and look at the "try_to_unuse()" logic, and wince. I'd love to have somebody look a bit more at swap-off. It may well be, for example, that swap-off does not correctly notice dead swap-pages at all - somebody should verify that it doesn't try to read in and "try_to_unuse()" dead swap entries. That would make the inefficiency show up even more clearly. (Quick look gives the following: right now try_to_unuse() in mm/swapfile.c does something like lock_page(page); if (PageSwapCache(page)) delete_from_swap_cache_nolock(page); UnlockPage(page); read_lock(_lock); for_each_task(p) unuse_process(p->mm, entry, page); read_unlock(_lock); shmem_unuse(entry, page); /* Now get rid of the extra reference to the temporary page we've been using. */ page_cache_release(page); and we should trivially notice that if the page count is 1, it cannot be mapped in any process, so we should maybe add something like lock_page(page); if (PageSwapCache(page)) delete_from_swap_cache_nolock(page); UnlockPage(page); + if (page_count(page) == 1) + goto nothing_to_do; read_lock(_lock); for_each_task(p) unuse_process(p->mm, entry, page); read_unlock(_lock); shmem_unuse(entry, page); + + nothing_to_do: + /* Now get rid of the extra reference to the temporary page we've been using. */ page_cache_release(page); which should (assuming I got the page count thing right - I'v eobviously not tested the above change) make sure that we don't spend tons of time on dead swap pages. Somebody interested in trying the above add? And looking for other more obvious bandaid fixes. It won't "fix" swapoff per se, but it might make it bearable and bring it to the 2.2.x levels. The _real_ fix is to really make "swapoff()" work the other way around - go through each process and look for swap entries in the page tables _first_, and bring all entries for that device in sanely, and after everything is brought in just drop all the swap cache pages for that device. The current swapoff() thing is really a quick hack that has lived on since early 1992 with quick hacks to make it work with the big VM changes that have happened since. That would make swapoff be O(n) in VM size (and you can easily do some further micro-optimizations at that time by avoiding shared mappings with backing store and other things that cannot have swap info involved) Is anybody interested in making "swapoff()" better? Please speak up.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NFS caching issues on 2.4
I've stumbled upon a wierd NFS caching issue on 2.4 which does not seem to exist in 2.2. Our www docroot is NFS mounted on a NetApp 760. We have a cron job which make changes to the index.html every 5 minutes. Recently, we upgraded all the web servers to 2.4 and noticed that there were big delays in seeing these 5 minute updates. Yet, an ls -l in the nfs directory on each of the servers clearly shows the new timestamp. However, a cat of the file shows that it is the old version (sometimes up to 1 hour old). I was using NFSv3, so decided to try NFSv2, but got the same results. I reverted to 2.2.19 on the boxes (which are RedHat 7.1 incidentally), and these problems went away. Any ideas why this is happening? -Phil Oester - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Promise ATARAID
Working with 2.4.5-ac8, a "_" was omitted in the Config.in file's rule for the Promise ATARAID card. The following will fix that. --- drivers/ide/Config.in.orig Tue Jun 5 17:46:08 2001 +++ drivers/ide/Config.in Tue Jun 5 17:46:19 2001 @@ -180,6 +180,6 @@ define_bool CONFIG_BLK_DEV_IDE_MODES n fi -dep_tristate 'Support Promise software RAID' CONFIG_BLKDEV_ATARAID $CONFIG_BLK_DEV_IDE $CONFIG_EXPERIMENTAL +dep_tristate 'Support Promise software RAID' CONFIG_BLK_DEV_ATARAID +$CONFIG_BLK_DEV_IDE $CONFIG_EXPERIMENTAL endmenu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac8 hardlocks when going to standby
On Wed, Jun 06, 2001 at 07:03:09PM +0200, Remi Turk wrote:
>
> By applying the following patch (lookalike)?
>
> arch/i386/kernel/apm.c:send_event():
>
> case APM_SYS_SUSPEND:
> case APM_CRITICAL_SUSPEND:
> case APM_USER_SUSPEND:
> + case APM_USER_STANDBY:
> + case APM_SYS_STANDBY:
> /* map all suspends to ACPI D3 */
> if (pm_send_all(PM_SUSPEND, (void
> *)3)) {
Well, I tried this one (did I understand correctly wat
you meant???) and it didn't make any difference.
--
Linux 2.4.6-pre1 #1 Wed Jun 6 18:25:37 CEST 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wednesday 06 June 2001 20:27, Eric W. Biederman wrote: > The hard rule will always be that to cover all pathological cases > swap must be greater than RAM. Because in the worse case all RAM > will be in thes swap cache. Could you explain in very simple terms how the worst case comes about? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
Hi! > > Please, don't. > > > > Use kelvins *0.1, and use them consistently everywhere. This is what > > ACPI does, and it is probably right. > > I'm sorry, by I don't feel like adding 273 to every number I get just to > find the temperature of something. What I would do is give configuration > options to choose the default (Celsius/centigrade, Kelvin, or [shudder] > Fahrenheit) then, when you need to print or output a temperature, send it > off to a common converter function so you don't repeat core all over the > place. No. Sorry. Create nice tool to display info for you. We are talking about output from kernel. It *must not* be configurable. Or do you want your programs to read 58 from /proc/acpi/thermal/1/status and then reading /proc/units to see if it is celsius or farenhait. ACPI is already using 0.1*K, so everything should use that to be consistent. Pavel -- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
es1371 compile issue in 2.4.5-ac9
Try to reproduce one problem and find another... I rebuilt from clean source and patch for 2.4.5-ac9 and neglected to add in anything using the joystick. (Which I should have done since this thing has most of the games (I mean "X test utilities") on it.) This should be pretty straightforward to fix, if it has not been already... Chokes on link. .config attached. make[1]: Leaving directory `/usr/src/linux/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pcmcia/pcmcia.o drivers/pnp/pnp.o drivers/video/video.o \ net/network.o \ /usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a /usr/src/linux/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/sound/sounddrivers.o: In function `es1371_probe': drivers/sound/sounddrivers.o(.text+0x5e5d): undefined reference to `gameport_register_port' drivers/sound/sounddrivers.o: In function `es1371_remove': drivers/sound/sounddrivers.o(.text+0x5f71): undefined reference to `gameport_unregister_port' make: *** [vmlinux] Error 1 [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." # # Automatically generated by make menuconfig: don't edit # # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set CONFIG_M586TSC=y # CONFIG_M686 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_1GB=y # CONFIG_2GB is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_QUIRKS=y # CONFIG_PCI_OPTIMIZE is not set CONFIG_PCI_OLD_PROC=y # CONFIG_MCA is not set # CONFIG_VISWS is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_BINFMT_JAVA is not set # CONFIG_PARPORT is not set # CONFIG_APM is not set # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_IDE=y # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_VIA82C586 is not set # CONFIG_BLK_DEV_CMD646 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_PARIDE_PARPORT=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_FIREWALL=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set CONFIG_IP_FIREWALL=y # CONFIG_IP_FIREWALL_NETLINK is not set # CONFIG_IP_TRANSPARENT_PROXY is not set # CONFIG_IP_MASQUERADE is not set # CONFIG_IP_ROUTER is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set CONFIG_IP_ALIAS=y # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_RARP is not set CONFIG_SKB_LARGE=y # CONFIG_IPV6 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_BRIDGE is not set # CONFIG_LLC is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # CONFIG_CPU_IS_SLOW is not set # # QoS
RE: Problem: NIC doesn't work anymore Winbond 89C940
Hi, I have the same problem with my network card Winbond 89C940 on a linksys etherPCI lan card II. The kernel recommends ne2k-pci for winbond, It's detected by the kernel but I get the "bogus packet size" error and it does not send any info! my kernel is 2.4.5 and RH7.1 is the system. which driver did you use? Thanks in advance Ali >From: David Raufeisen <[EMAIL PROTECTED]> >Reply-To: David Raufeisen <[EMAIL PROTECTED]> >To: Jonathan Brugge <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: Problem: NIC doesn't work anymore, SIOCIFADDR-errors >Date: Wed, 14 Feb 2001 06:36:20 -0800 > >Are you using the net-tools from debian? There was a broken one causing >these >errors the last few days, is fixed now. > >On Wednesday, 14 February 2001, at 15:17:09 (+0100), >Jonathan Brugge wrote: > > > Here's the output from dmesg, after deleting some unimportant stuff like > > sound and graphics-init. I don't see any errors that have something to __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] New life for Serial mice
> > > hmmm. I just looked over this, and drivers/char/joystick/ser*.[ch]. > > > > > > Bad trend. > > > > > > Serial needs to be treated just like parport: the basic hardware code, > > > then on top of that, a selection of drivers, all peers: dumb serial > > > port, serial mouse, joystick, etc. > > > > Agreed. Completely. > > I suggest that if someone is thinking about this that they look at > serial_core.c in the ARM patch hunk. >(ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/) > > Note that you shouldn't apply the whole patch - it probably won't compile > for anything but ARM atm. Never noticed it until now. Very nice patch :-) I have to agree as well. It would be nice if we had 1) A seperate serial directory under drivers. 2) A nice structure that input devices and the tty layer can use. It is just a waste to go threw the tty layer for input devices. It would also make serial driver writing easier if the api is designed right :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: kHTTPd hangs 2.4.5 boot when moduled
Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > package RH7.0 has...2.4.2 and on needs... > util-linux 2.10m 2.10o > modutils2.3.21 2.4.2 > e2fsprogs 1.181.19 Which compiler do you use? The default compiler from 7.0 is known to produce buggy kernels, and Linus didn't include the kgcc detection. Could you check that kgcc is used for compiling? Just replace '$(CROSS_COMPILE)gcc' in /usr/src/linux/Makefile with '$(CROSS_COMPILE)kgcc' Or upgrade to the gcc compiler from 7.1? -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID's
On Tue, Jun 05, 2001 at 12:50:55PM -0700, android wrote: > Is there a way to recycle unused PID's without rebooting the kernel? > So instead of the next available PID always getting larger and larger, > just reset it to use the first unused PID after 1. Is this possible? It already works like that. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
> Kernel is worldwide, should not use anlo-saxon shifted units. Use the > International System of Units (SI) > http://physics.nist.gov/cuu/Units/units.html Hmmm... I don't see bogomips on this list! :-) Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isolating process..
On Tue, Jun 05, 2001 at 12:37:55PM +0300, Bohdan Vlasyuk wrote: > Is it possible by any means to isolate any given process, so that > it'll be unable to crash system. Suppose all the process needs is > stdin, stdout, and CPU time. Can Linux guarantee that given process > won't hurt system stability ? Let us soppose that we have ideal CPU > without mistakes. How can I limit CPU time/Mem Usage for given > process? You just gave a nice description what an OS kernel should do :) > Please, supply ANY suggestions. > > My ideas: > > create some user, and decrease his ulimits up to miminum of 1 process, > 0 core size, appropriate memory/ etc. That's indeed the way to do it. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ethernet and pointopoint
> > From: Adam [mailto:[EMAIL PROTECTED]] > > Is there reason why I can't set pointopoint for ethernet? I have > > If your network cards & their drivers (both hosts) support full duplex > operation, just enable it, and you're done. did you read my email? The patch below has detailed description of the problem and suggested solution. Still I'm not quite sure if that's the "the way it should be"(tm), so I'm hoping on more feedback on the issue itself. http://www.eax.com/patches/linux-kernel-dev2-diff -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Sun, 3 Jun 2001, Adrian Cox wrote: > Marc Lehmann wrote: > > > > Aren't PCI delayed transaction supposed to be handled by the pci master > > (e.g. my northbridge), not by the (software) driver for my pdc(?) I would > > also be surprised if my pdc actually used that feature, not to speak of > > the fact that the promise + harddisk worked fine in another computer (the > > data corruption was easily detectable, one couldn't even write 500megs > > without altered bytes). > > > Wrong way round. You're right that the pci master is supposed to handle > delayed transactions, but during data transfer the pdc is the pci master > and the northbridge is the PCI target. Wrong in my opinion, at least as it is worded. :) PCI delayed transactions are not a PCI master issue at all, for the reason it is not possible for a PCI master to distiguish between a transaction which is delayed by the target and a simple retry requested by the target. Btw, a PCI master that is unable to properly retry a transaction (could the transaction be handled by the target as a delayed transaction on not) would not allow a system to work for a long time. I would expect system breakage within seconds in such situation. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
Mike Galbraith wrote: > > Can you try the patch below to see if it helps? If you watch > with vmstat, you should see swap shrinking after your test. > Let is shrink a while and then see how long swapoff takes. > Under a normal load, it'll munch a handfull of them at least > once a second and keep them from getting annoying. (theory;) Hi Mike, I'll give that patch a spin this evening after work when I have time to patch and recompile the kernel. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
'SIG: sigpending lied' on 2.2.14 (Cobalt Networks)
I have been seeing 'SIG: sigpending lied' when I change the current->blocked value to ignore 'non shutdown' signals. The messages does not show up on 2.2.16. Searching with google I found a lot of problems being reported but no solutions... Is this a 2.2.14 "feature"? I ask because we have clients that still rely on the Cobalt build of 2.2.14. Here is the long explonation... I have a driver for a device that processes a steady stream of commands to a PCI device. The calls come in on an ioctl and are send to the device. While the command is being processed the user space process sleeps (in the kernel). To prevent this sleep from waking up on non threatening signals (like thread debugging) I added this code... #define SHUTDOWN_SIGS \ (sigmask(SIGKILL) | sigmask(SIGINT) | sigmask(SIGQUIT)) spin_lock_irqsave(>sigmask_lock, irqflags); sigset = current->blocked; siginitsetinv(>blocked, SHUTDOWN_SIGS & ~sigset.sig[0]); recalc_sigpending(current); spin_unlock_irqrestore(>sigmask_lock, irqflags); It is executed before I put the task on a wait queue and set it's state to TASK_INTERRUPTIBLE. After the command is finished the h/w interrupt will wake up the waitqueue and the task will be set to TASK_RUNNING again. Finally the following is done to restore the signal state. spin_lock_irqsave(>sigmask_lock, irqflags); current->blocked = sigset; recalc_sigpending(current); spin_unlock_irqrestore(>sigmask_lock, irqflags); When I comment out these two blocks, or when I switch to 2.2.16 my problem goes away. Thanks for reading this far, Bart. -- WebSig: http://www.jukie.net/~bart/sig/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
Mike Galbraith <[EMAIL PROTECTED]> writes: > On 6 Jun 2001, Eric W. Biederman wrote: > > > Derek Glidden <[EMAIL PROTECTED]> writes: > > > > > > > The problem I reported is not that 2.4 uses huge amounts of swap but > > > that trying to recover that swap off of disk under 2.4 can leave the > > > machine in an entirely unresponsive state, while 2.2 handles identical > > > situations gracefully. > > > > > > > The interesting thing from other reports is that it appears to be kswapd > > using up CPU resources. Not the swapout code at all. So it appears > > to be a fundamental VM issue. And calling swapoff is just a good way > > to trigger it. > > > > If you could confirm this by calling swapoff sometime other than at > > reboot time. That might help. Say by running top on the console. > > The thing goes comatose here too. SCHED_RR vmstat doesn't run, console > switch is nogo... > > After running his memory hog, swapoff took 18 seconds. I hacked a > bleeder valve for dead swap pages, and it dropped to 4 seconds.. still > utterly comatose for those 4 seconds though. At the top of the while(1) loop in try_to_unuse what happens if you put in. if (need_resched) schedule(); It should be outside all of the locks. It might just be a matter of everything serializing on the SMP locks, and the kernel refusing to preempt itself. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
At 18:06 +0200 2001-06-06, Chris Boot wrote: >I'm sorry, by I don't feel like adding 273 to every number I get just to >find the temperature of something. That's much easier than subtracting 32 and multiplying by 5/9. ;-) > What I would do is give configuration >options to choose the default (Celsius/centigrade, Kelvin, or [shudder] >Fahrenheit) The kernel output should not be configurable. You have tools for printing the information; they can do the calculation for you. Personally I'd like to see cK (centi-Kelvin). -- Matthias Urlichs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
"Eric W. Biederman" wrote:
>
> Derek Glidden <[EMAIL PROTECTED]> writes:
>
> > The problem I reported is not that 2.4 uses huge amounts of swap but
> > that trying to recover that swap off of disk under 2.4 can leave the
> > machine in an entirely unresponsive state, while 2.2 handles identical
> > situations gracefully.
> >
>
> The interesting thing from other reports is that it appears to be kswapd
> using up CPU resources. Not the swapout code at all. So it appears
> to be a fundamental VM issue. And calling swapoff is just a good way
> to trigger it.
>
> If you could confirm this by calling swapoff sometime other than at
> reboot time. That might help. Say by running top on the console.
That's exactly what my original test was doing. I think it was Jeffrey
Baker complaining about "swapoff" at reboot. See my original post that
started this thread and follow the "five easy steps." :) I'm sucking
down a lot of swap, although not all that's available which is something
I am specifically trying to avoid - I wanted to stress the VM/swap
recovery procedure, not "out of RAM and swap" memory pressure - and then
running 'swapoff' from an xterm or a console.
The problem with being able to see what's eating up CPU resources is
that the whole machine stops responding for me to tell. consoles stop
updating, the X display freezes, keyboard input is locked out, etc. As
far as anyone can tell, for several minutes, the whole machine is locked
up. (except, strangely enough, the machine will still respond to ping)
I've tried running 'top' to see what task is taking up all the CPU time,
but the system hangs before it shows anything meaningful. I have been
able to tell that it hits 100% "system" utilization very quickly though.
I did notice that the first thing sys_swapoff() does is call
lock_kernel() ... so if sys_swapoff() takes a long time, I imagine
things will get very unresponsive quickly. (But I'm not intimately
familiar with the various kernel locks, so I don't know what
granularity/atomicity/whatever lock_kernel() enforces.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On 06.06 john slee wrote: > > On Wed, Jun 06, 2001 at 02:27:22PM +0200, David N. Welton wrote: > > Perusing the kernel sources while investigating watchdog drivers, I > > notice that in some places, Fahrenheit is used, and in some places, > > Celsius. It would seem logical to me to have a global config option, > > so that you *know* that you talk devices either in F or C. > > celsius is probably a sensible default - lots of the world uses it now. > Problem is decimals and floating point... I suppose kernel people would prefer whatever, but suited to get full intXX_t range, say ºC/10. And if you do not want signs, centi-kelvin is the better choice:xxx.xx, five digits, a short goes to 655-273=382 ºC- -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ide speeds
Hi, A little test-question. I am getting some strange timings... Hardware: PIIX4: 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 64 I/O ports at ffa0 [size=16] and a Creative 52mx CD-ROM (managed with kernel ide, master on IDE1) and a Yamaha 8424 CDRW (also IDE, with ide-scsi+sg). Software: 2.4.5-ac9+andre-ide-patch Test: read a big file (634Mb) to disk. The copy takes nearly 9 minutes from the 52x Creative and 3.5 from the 24x Yamaha. ??? Can it be soft ? The difference between ide-scsi and native ide ? Or just the Creative hardware is s... ? -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On 6 Jun 2001, Eric W. Biederman wrote: > Derek Glidden <[EMAIL PROTECTED]> writes: > > > > The problem I reported is not that 2.4 uses huge amounts of swap but > > that trying to recover that swap off of disk under 2.4 can leave the > > machine in an entirely unresponsive state, while 2.2 handles identical > > situations gracefully. > > > > The interesting thing from other reports is that it appears to be kswapd > using up CPU resources. Not the swapout code at all. So it appears > to be a fundamental VM issue. And calling swapoff is just a good way > to trigger it. > > If you could confirm this by calling swapoff sometime other than at > reboot time. That might help. Say by running top on the console. The thing goes comatose here too. SCHED_RR vmstat doesn't run, console switch is nogo... After running his memory hog, swapoff took 18 seconds. I hacked a bleeder valve for dead swap pages, and it dropped to 4 seconds.. still utterly comatose for those 4 seconds though. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
>Furthermore, I am not demanding anything, much less "priority fixing" >for this bug. Its my personal opinion that this is the most critical bug >in the 2.4 series, and if I had the time and skill, this is what I would >be working on. Because I don't have the time and skill, I am perfectly >happy to wait until those that do fix the problem. To say it isn't a >problem because I can buy more disk is nonsense, and its that sort of >thinking that leads to constant need to upgrade hardware in the >proprietary OS world. > >Sean This would reflect the Microsoft way of programming: If there's a bug in the system, don't fix it, but upgrade your hardware. Why do you think the requirements for Windows is so great? Most of their code is very inefficient. I'm sure they programmed their kernel in Visual Basic. The worst part is that they get paid to do this! I program in Linux because I don't want to be associated with that mindset that made Microsoft such a [fill in the blank]. As for the 2.4 VM problem, what are you doing with your machine that's making it use up so much memory? I have several processes running on mine all the time, including a slew in X, and I have yet to see significant swap activity. -- Ted P.S. My faithful Timex Sinclair from the 80's never had swap :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On 6 Jun 2001, David N. Welton wrote: > > [ please CC replies to me ] > > Perusing the kernel sources while investigating watchdog drivers, I > notice that in some places, Fahrenheit is used, and in some places, > Celsius. It would seem logical to me to have a global config option, > so that you *know* that you talk devices either in F or C. > > I searched the archives for discussions regarding this, but didn't > find anything, apologies if I missed something. If something is done, Celsius should be default (as the US is brain-dead like that; nearly everywhere else uses Celsius as the standard) and fahrenheit as an option. I wrote a patch for the 'sensors' utility in lm_sensors that did just that; supplied fahrenheit conversion for the sensors via a commandline option. Perhaps there could be a config option in the kernel (or a proc entry/ioctl?) that controls this. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
> On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote: > > > Hi! > > > > > > Is there any way to read out the compile-time HZ value of the kernel? > > > > Why simply #include ? > > because the include file doesn't say anything about the HZ value of > the currently running kernel, but only about some kernel source somewhere > on your harddrive? This _SHOULD_ correspond on each linux instalation. But if you would distribute a binary to other people it's a problem. (note that I'm running an rc script, which sets the symlink /usr/src/linux properly at boottime ... this should be everywhere) There is also one way how to guess HZ - calibrate :-))) Recently I've done more difficult thing - I not only guess the HZ value, I also guess the time when the tick comes. But it uses a bit of statistics and may be inaccurate on loaded systems. And you need TSC :-) Tomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Tue, 5 Jun 2001, Derek Glidden wrote:
> After reading the messages to this list for the last couple of weeks and
> playing around on my machine, I'm convinced that the VM system in 2.4 is
> still severely broken.
...
Hi,
Can you try the patch below to see if it helps? If you watch
with vmstat, you should see swap shrinking after your test.
Let is shrink a while and then see how long swapoff takes.
Under a normal load, it'll munch a handfull of them at least
once a second and keep them from getting annoying. (theory;)
-Mike
--- linux-2.4.5.ac5/mm/vmscan.c.org Sat Jun 2 07:37:16 2001
+++ linux-2.4.5.ac5/mm/vmscan.c Wed Jun 6 18:29:02 2001
@@ -1005,6 +1005,53 @@
return ret;
}
+int deadswap_reclaim(unsigned int priority)
+{
+ struct list_head * page_lru;
+ struct page * page;
+ int maxscan = nr_active_pages >> priority;
+ int nr_reclaim = 0;
+
+ /* Take the lock while messing with the list... */
+ spin_lock(_lru_lock);
+ while (maxscan-- > 0 && (page_lru = active_list.prev) != _list) {
+ page = list_entry(page_lru, struct page, lru);
+
+ /* Wrong page on list?! (list corruption, should not happen) */
+ if (!PageActive(page)) {
+ printk("VM: refill_inactive, wrong page on list.\n");
+ list_del(page_lru);
+ nr_active_pages--;
+ continue;
+ }
+
+ if (PageSwapCache(page) &&
+ (page_count(page) - !!page->buffers) == 1 &&
+ swap_count(page) == 1) {
+ if (page->buffers || TryLockPage(page)) {
+ ClearPageReferenced(page);
+ ClearPageDirty(page);
+ page->age = 0;
+ deactivate_page_nolock(page);
+ } else {
+ page_cache_get(page);
+ spin_unlock(_lru_lock);
+ delete_from_swap_cache_nolock(page);
+ spin_lock(_lru_lock);
+ UnlockPage(page);
+ page_cache_release(page);
+ }
+ nr_reclaim++;
+ continue;
+ }
+ list_del(page_lru);
+ list_add(page_lru, _list);
+ }
+ spin_unlock(_lru_lock);
+
+ return nr_reclaim;
+}
+
DECLARE_WAIT_QUEUE_HEAD(kreclaimd_wait);
/*
* Kreclaimd will move pages from the inactive_clean list to the
@@ -1027,7 +1074,7 @@
* We sleep until someone wakes us up from
* page_alloc.c::__alloc_pages().
*/
- interruptible_sleep_on(_wait);
+ interruptible_sleep_on_timeout(_wait, HZ);
/*
* Move some pages from the inactive_clean lists to
@@ -1051,6 +1098,7 @@
}
pgdat = pgdat->node_next;
} while (pgdat);
+ deadswap_reclaim(4);
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
Derek Glidden <[EMAIL PROTECTED]> writes: > The problem I reported is not that 2.4 uses huge amounts of swap but > that trying to recover that swap off of disk under 2.4 can leave the > machine in an entirely unresponsive state, while 2.2 handles identical > situations gracefully. > The interesting thing from other reports is that it appears to be kswapd using up CPU resources. Not the swapout code at all. So it appears to be a fundamental VM issue. And calling swapoff is just a good way to trigger it. If you could confirm this by calling swapoff sometime other than at reboot time. That might help. Say by running top on the console. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 06 Jun 2001, Dr S.M. Huen wrote: > The whole screaming match is about whether a drastic degradation on using > swap with less than the 2*RAM swap specified by the developers should lead > one to conclude that a kernel is "broken". I would argue that any system that performs substantially worse with swap==1xRAM than a system with swap==0xRAM is fundamentally broken. it seems that w/ todays 2.4.x kernel, people running programs totalling LESS THAN their physical dram are having swap problems. they should not even be using 1 byte of swap. the whole point of swapping pages is to give you more memory to execute programs. if I want to execute 140MB of programs+kernel on a system with 128 MB of ram, I should be able to do the job effectively with ANY amount of "total memory" exceeding 140MB. not some hokey 128MB RAM + 256MB swap just because the kernel it too fscked up to deal with a small swap file. -- /*** ** Mark Salisbury | Mercury Computer Systems** ***/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
"Eric W. Biederman" wrote:
>
> > Or are you saying that if someone is unhappy with a particular
> > situation, they should just keep their mouth shut and accept it?
>
> It's worth complaining about. It is also worth digging into and find
> out what the real problem is. I have a hunch that this hole
> conversation on swap sizes being irritating is hiding the real
> problem.
I totally agree with this, and want to reiterate that the original
problem I posted has /nothing/ to do with the "swap == 2*RAM" issue.
The problem I reported is not that 2.4 uses huge amounts of swap but
that trying to recover that swap off of disk under 2.4 can leave the
machine in an entirely unresponsive state, while 2.2 handles identical
situations gracefully.
I'm annoyed by 2.4's "requirement" of too much swap, but I consider that
less a bug and more a severe design flaw.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement: swap = RAM x 2.5 ??
Jeff Garzik <[EMAIL PROTECTED]> writes: > I'm sorry but this is a regression, plain and simple. > > Previous versons of Linux have worked great on diskless workstations > with NO swap. > > Swap is "extra space to be used if we have it" and nothing else. Given the slow speed of disks to use them efficiently when you are using swap some additional rules apply. In the worse case when swapping is being used you get: Virtual Memory = RAM + (swap - RAM). That cannot be improved. You can increase your likely hood that that case won't come up, but that is a different matter entirely. I suspect in practice that we are suffering more from lazy reclamation of swap pages than from a more aggressive swap cache. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ethernet and pointopoint
> From: Adam [mailto:[EMAIL PROTECTED]] > Is there reason why I can't set pointopoint for ethernet? I have If your network cards & their drivers (both hosts) support full duplex operation, just enable it, and you're done. V. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
On Wed, Jun 06, 2001 at 08:09:33PM +0200, Tomas Telensky wrote: > > Hi! > > > > Is there any way to read out the compile-time HZ value of the kernel? > > Why simply #include ? because the include file doesn't say anything about the HZ value of the currently running kernel, but only about some kernel source somewhere on your harddrive? > Tomas -- 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA's Southbridge bug: Latest (pseudo-)patch
On Wed, 6 Jun 2001, Marc Lehmann wrote: > I *do* hate silent data corruption :() An "integrity loopback" device would certainly detect silent corruption. Eg a loopback which CRC's all blocks read/written and screams loudly if the CRC fails. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ethernet and pointopoint
hello, Is there reason why I can't set pointopoint for ethernet? I have to computers (and two 100mbps ethernet cards) connected via null-modem ethernet cable (with no hub in between). So since there's no way to have more than two hosts talking to each other for all intended purposes it IS a pointopoint link. looking at net/core/dev.c:dev_change_flags() I see that I can't pass IFF_POINTOPOINT to it via ioctl, and it will be just sillently dropped, with no error reported back to ifconfig. -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Kurt Roeckx wrote: > On Wed, Jun 06, 2001 at 10:57:57AM +0100, Dr S.M. Huen wrote: > > On Wed, 6 Jun 2001, Sean Hunter wrote: > > > > > > > > For large memory boxes, this is ridiculous. Should I have 8GB of swap? > > > > > > > Do I understand you correctly? > > ECC grade SDRAM for your 8GB server costs £335 per GB as 512MB sticks even > > at today's silly prices (Crucial). Ultra160 SCSI costs £8.93/GB as 73GB > > drives. > > Maybe you really should reread the statements people made about > this before. > I think you might do with a more careful quoting or reading of the thread yourself before casting such aspersions. I did not recommend swap use. I argued that it was not reasonable to reject a 2*RAM swap requirement on cost grounds. There are those who do not think this argument adequate because of grounds other than hardware cost (e.g. retrofitting existing farms, laptops with zillions of OSes etc.) > > That swap = 2 * RAM is just a guideline, you really should look > at what applications you run, and how memory they use. If you > choise your RAM so that all application can always be in memory > at all time, there is no need for swap. If they can't be, the > rule might help you. > I think the whole argument of the thread is against you here. It seems that if you do NOT provide 2*RAM you get into trouble much earlier than you expect (a few argue that even if you do you get trouble). If it were just a guideline that gracefully degraded your performance the other lot wouldn't be screaming. The whole screaming match is about whether a drastic degradation on using swap with less than the 2*RAM swap specified by the developers should lead one to conclude that a kernel is "broken". To conclude, this is not a hypothetical argument about whether to operate completely in core. There's not a person on LKML who doesn't know running in RAM is better than running swapping. It is one where users do swap but allocate a size smaller than that recommended and are adversely affected. It is about whether a kernel that reacts this way could be regarded as stable. Answe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
Derek Glidden <[EMAIL PROTECTED]> writes: > John Alvord wrote: > > > > On Wed, 06 Jun 2001 11:31:28 -0400, Derek Glidden > > <[EMAIL PROTECTED]> wrote: > > > > > > > >I'm beginning to be amazed at the Linux VM hackers' attitudes regarding > > >this problem. I expect this sort of behaviour from academics - ignoring > > >real actual problems being reported by real actual people really and > > >actually experiencing and reporting them because "technically" or > > >"theoretically" they "shouldn't be an issue" or because "the "literature > > >[documentation] says otherwise - but not from this group. > > > > There have been multiple comments that a fix for the problem is > > forthcoming. Is there some reason you have to keep talking about it? > > Because there have been many more comments that "The rule for 2.4 is > 'swap == 2*RAM' and that's the way it is" and "disk space is cheap - > just add more" than there have been "this is going to be fixed" which is > extremely discouraging and doesn't instill me with all sorts of > confidence that this problem is being taken seriously. The hard rule will always be that to cover all pathological cases swap must be greater than RAM. Because in the worse case all RAM will be in thes swap cache. That this is more than just the worse case in 2.4 is problematic. I.e. In the worst case: Virtual Memory = RAM + (swap - RAM). You can't improve the worst case. We can improve the worst case that many people are facing. > Or are you saying that if someone is unhappy with a particular > situation, they should just keep their mouth shut and accept it? It's worth complaining about. It is also worth digging into and find out what the real problem is. I have a hunch that this hole conversation on swap sizes being irritating is hiding the real problem. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wednesday, 06 June 2001, at 10:19:30 +0200, Xavier Bestel wrote: > On 05 Jun 2001 23:19:08 -0400, Derek Glidden wrote: > > On Wed, Jun 06, 2001 at 12:16:30PM +1000, Andrew Morton wrote: > [...] > Did you try to put twice as much swap as you have RAM ? (e.g. add a 512M > swapfile to your box) > I'm not a kernel guru, neither I can even try to understand how an operating system's memory management is designed or behaves. But I've some questions and thoughs: 1. Is swap=2xRAM a desing issue, or just a recommendation to get best results _based_ on current VM subsystem status ? 2. Wouldn't performance drop quickly when VM starts to swap processes/pages to disk, instead of keeping them on RAM ?. Maybe having a couple of GB worth of processes on disk is not very wyse. 3. Shouldn't an ideal VM manage swap space as an extension of system's RAM (of course, taking into account that RAM is much faster than HD, and nothing should be on swap if there is room enough on RAM ?. 4. Wouldn't you say that "adding more swap" (maybe 2xRAM is a recommendation, maybe a temporary fix, maybe a design decission) is the M$-way of fixing things ?. If there is a _real_ need for more swap to get a well baheving system, let's add swap. But we shouldn't hide inner desing and/or implementation problems under the "cheap multigigabyte disks" argument. 5. AFAIK, kernel developers are well aware of current 2.4.x problems in some areas. I don't think insisting on certain problems without providing ideas, testing, support, and limiting to just blaming the authors is the best way to go. Maybe kernel hackers are the most interested of all in fixing all these issues ASAP. Just some thoughts from someone unable to write C code and help fix this mess ;). -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to know HZ from userspace?
> Hi! > > Is there any way to read out the compile-time HZ value of the kernel? Why simply #include ? Tomas > > I had a brief look at /proc/* and didn't find anything. > > The background, why it is needed: > > There are certain settings, for example the icmp rate limiting values, > which can be set using sysctl. Those setting are basically derived from > HZ values (1*HZ, for example). > > If you now want to set those values from a userspace program / script in > a portable manner, you need to be able to find out of HZ of the currently > running kernel. > > -- > 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] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Wed, 6 Jun 2001, Jeff Garzik wrote: > There are two things you can do here, one is easy: use linker tricks to > make sure that an application built on alpha -- with 64-bit pointers -- > uses no more than the lower 32 bits of each pointer for addressing. > This should fix a ton of applications which cast pointer values to ints > and similar garbage. Note we are only writing of executing an OSF/1 netscape binary. The binary is built with the -taso option on OSF/1 and is linked fine with respect to 31-bit pointers. It fails when mmap()ping shared libraries after applying my patch that went to -ac series recently. Since OSF/1 shared libraries are PIC, there should be no problem to mmap() them into the low 2GB provided mmap() know we want it. And mmap() has already all needed bits in place -- it's the ECOFF support on Alpha/Linux that does not set the personality as it should. > The other option, hacking gcc to output "32-bit alpha" binary code, is a > tougher job. > > I had mentioned this to Richard Henderson a while back, when I was > wondering how easy it is to implement -taso under Linux, and IIRC he > seemed to think that linker tricks were much easier. It might be unavoidable to prevent shared libraries from being mmap()ped outside the 31-bit address space unless we hint the dynamic linker somehow. Implementing the -taso option is trivial -- all it actually does on OSF/1 is mapping program's segments into low 2GB of memory (we may do it by selecting a different linker script) and setting the "31-bit address space flag" in the program's header so that the dynamic linker mmap()s shared libraries appropriately as well. We do have all the bits in place already as well. Note that personally I'm strongly against the -taso approach -- it's a hack to be meant as an excuse for fixing broken programs. But fixing programs is not that difficult (though it might be boring and time-consuming). I've already did a conversion of a moderately sized DOS program to *nix. The program was twisted by far and near pointers and casts to ints and longs (depending on the pointer type) scattered over the source. It took me about two weeks worth of full-time work (assuming eight hours per day; the actual time elapsed was longer, but I was only doing it in my free time) to make the program working on i386/Linux, another week to port it to Alpha/Linux (i.e. make it 64-bit clean) and yet another day to make it work on SPARC/Solaris (i.e. make it endianness-clean). The program was checked to be running fine on MIPS/Ultrix and Alpha/OSF/1 afterwards as well. Therefore I see no point in keeping programs broken. If a vendor is not willing to fix a non-open-sourced broken program, then maybe the program is just not worth attention. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
On Wednesday, 06 June 2001, at 18:06:56 +0200, Chris Boot wrote: > Hi, > > > Please, don't. > > > > Use kelvins *0.1, and use them consistently everywhere. This is what > > ACPI does, and it is probably right. > > I'm sorry, by I don't feel like adding 273 to every number I get just to > find the temperature of something. What I would do is give configuration > What about keeping times with format similar to "06 June 2001, at 18:06:56 +0200" instead of using miliseconds from 01 Jan 1970 ? ;) If there is a universally-accepted measure for temperatures, we should use it, and let user space applications make the conversions for us. Just my 0.02 (eurocents :) -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patches sound driver locking issue
Frank Davis wrote: > > Hello all, > I have attached patches against the following sound drivers to fix the locking >issues mentioned in Alan's release notes for 2.4.5-ac9 . Please CC me on your >comments to the code (I can address the issues quicker). Thanks. Do these patches have the same problems that your es1371 patch did? Let's make sure that is fixed first, and is solid. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
> 2.4.5-ac9 > o Fix xircom_cb problems with some cisco kit (Ion Badulescu) I'm not sure what this is supposed to fix, but it makes my Xircom RBEM56G-100 almost useless on my network at the office. Actually, I can't quite blame just this patch, it only makes the problem worse, the driver from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely works at all, it seems to think the link is not there, at least not enough to pull an IP address. The last driver that worked moderately well for me was the one from 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco 6509. I must admist that I haven't tested every version in between. One other note, the version in 2.4.4-ac11 is listed as 1.33 while the version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there significant problems with the newer version? The 1.33 sure seems to work better for me. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, Jun 06, 2001 at 10:57:57AM +0100, Dr S.M. Huen wrote: > On Wed, 6 Jun 2001, Sean Hunter wrote: > > > > > For large memory boxes, this is ridiculous. Should I have 8GB of swap? > > > > Do I understand you correctly? > ECC grade SDRAM for your 8GB server costs £335 per GB as 512MB sticks even > at today's silly prices (Crucial). Ultra160 SCSI costs £8.93/GB as 73GB > drives. Maybe you really should reread the statements people made about this before. One of them being, that if you're not using swap in 2.2, it won't need any in 2.4 either. 2.4 will use more swap in case it does use it. It now works more like other UNIX variants where the rule is that swap = 2 * RAM. That swap = 2 * RAM is just a guideline, you really should look at what applications you run, and how memory they use. If you choise your RAM so that all application can always be in memory at all time, there is no need for swap. If they can't be, the rule might help you. I think someone said that the swap should be large enough to hold all application that are running on swapspace, that is, in case you want to use swap. Disk maybe be alot cheaper than RAM, but it's also alot slower. Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 07:01:58PM +0200, Vojtech Pavlik wrote: > On Wed, Jun 06, 2001 at 12:31:28PM -0400, Jeff Garzik wrote: > > hmmm. I just looked over this, and drivers/char/joystick/ser*.[ch]. > > > > Bad trend. > > > > Serial needs to be treated just like parport: the basic hardware code, > > then on top of that, a selection of drivers, all peers: dumb serial > > port, serial mouse, joystick, etc. > > Agreed. Completely. I suggest that if someone is thinking about this that they look at serial_core.c in the ARM patch hunk. (ftp.arm.linux.org.uk/pub/armlinux/source/kernel-patches/v2.4/) Note that you shouldn't apply the whole patch - it probably won't compile for anything but ARM atm. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, Jun 06, 2001 at 06:48:32AM -0400, Alexander Viro wrote:
> On Wed, 6 Jun 2001, Sean Hunter wrote:
>
> > This is completely bogus. I am not saying that I can't afford the swap.
> > What I am saying is that it is completely broken to require this amount
> > of swap given the boundaries of efficient use.
>
> Funny. I can count many ways in which 4.3BSD, SunOS{3,4} and post-4.4 BSD
> systems I've used were broken, but I've never thought that swap==2*RAM rule
> was one of them.
>
> Not that being more kind on swap would be a bad thing, but that rule for
> amount of swap is pretty common. ISTR similar for (very old) SCO, so it's
> not just BSD world. How are modern Missed'em'V variants in that respect, BTW?
Although I don't have any swap-trouble myself, what I think
most people are having problems with is not that Linux
doesn't have the "you-dont-need-2xRAM-size-swap-if-you-swap-at-all
feature", but that it lost it in 2.4.
--
Linux 2.4.5-ac9 #5 Wed Jun 6 18:30:24 CEST 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
patches sound driver locking issue
Hello all,
I have attached patches against the following sound drivers to fix the locking
issues mentioned in Alan's release notes for 2.4.5-ac9 . Please CC me on your comments
to the code (I can address the issues quicker). Thanks.
drivers/sound/esssolo1.c
drivers/sound/maestro.c
drivers/sound/maestro3.c
drivers/sound/cmpci.c
Regards,
Frank
--- drivers/sound/cmpci.c.old Tue Jun 5 21:21:39 2001
+++ drivers/sound/cmpci.c Tue Jun 5 23:20:41 2001
@@ -312,6 +312,7 @@
/* spdif frame counter */
int spdif_counter;
+ struct semaphore sem;
};
/* flags used for capability */
@@ -1653,7 +1654,7 @@
static ssize_t cm_read(struct file *file, char *buffer, size_t count, loff_t *ppos)
{
struct cm_state *s = (struct cm_state *)file->private_data;
- ssize_t ret;
+ ssize_t ret = 0;
unsigned long flags;
unsigned swptr;
int cnt;
@@ -1663,11 +1664,11 @@
return -ESPIPE;
if (s->dma_adc.mapped)
return -ENXIO;
- if (!s->dma_adc.ready && (ret = prog_dmabuf(s, 1)))
- return ret;
if (!access_ok(VERIFY_WRITE, buffer, count))
return -EFAULT;
- ret = 0;
+ down(>sem);
+ if (!s->dma_adc.ready && (ret = prog_dmabuf(s, 1)))
+ goto out;
#if 0
spin_lock_irqsave(>lock, flags);
cm_update_ptr(s);
@@ -1684,8 +1685,12 @@
cnt = count;
if (cnt <= 0) {
start_adc(s);
- if (file->f_flags & O_NONBLOCK)
- return ret ? ret : -EAGAIN;
+ if (file->f_flags & O_NONBLOCK)a
+ {
+ if(!ret) ret = -EAGAIN;
+ goto out;
+ }
+ up(>sem);
if (!interruptible_sleep_on_timeout(>dma_adc.wait, HZ)) {
printk(KERN_DEBUG "cm: read: chip lockup? dmasz %u
fragsz %u count %i hwptr %u swptr %u\n",
s->dma_adc.dmasize, s->dma_adc.fragsize,
s->dma_adc.count,
@@ -1698,12 +1703,24 @@
s->dma_adc.count = s->dma_adc.hwptr = s->dma_adc.swptr
= 0;
spin_unlock_irqrestore(>lock, flags);
}
- if (signal_pending(current))
- return ret ? ret : -ERESTARTSYS;
+ if (signal_pending(current))
+ {
+ if(!ret) ret = -ERESTARTSYS;
+ goto out;
+ }
+ down(>sem);
+ if (s->dma_adc.mapped)
+ {
+ ret = -ENXIO;
+ goto out;
+ }
continue;
}
if (copy_to_user(buffer, s->dma_adc.rawbuf + swptr, cnt))
- return ret ? ret : -EFAULT;
+ {
+ if(!ret) ret = -EFAULT;
+ goto out;
+ }
swptr = (swptr + cnt) % s->dma_adc.dmasize;
spin_lock_irqsave(>lock, flags);
s->dma_adc.swptr = swptr;
@@ -1714,6 +1731,8 @@
start_adc_unlocked(s);
spin_unlock_irqrestore(>lock, flags);
}
+out:
+ up(>sem);
return ret;
}
@@ -1730,18 +1749,20 @@
return -ESPIPE;
if (s->dma_dac.mapped)
return -ENXIO;
- if (!s->dma_dac.ready && (ret = prog_dmabuf(s, 0)))
- return ret;
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;
if (s->status & DO_DUAL_DAC) {
if (s->dma_adc.mapped)
return -ENXIO;
- if (!s->dma_adc.ready && (ret = prog_dmabuf(s, 1)))
- return ret;
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;
+ down(>sem);
+ if (!s->dma_adc.ready && (ret = prog_dmabuf(s, 1)))
+ goto out;
}
+ down(>sem);
+ if (!s->dma_dac.ready && (ret = prog_dmabuf(s, 0)))
+ goto out;
ret = 0;
#if 0
spin_lock_irqsave(>lock, flags);
@@ -1776,7 +1797,11 @@
if (cnt <= 0) {
start_dac(s);
if (file->f_flags & O_NONBLOCK)
- return ret ? ret : -EAGAIN;
+ {
+if(!ret) ret = -EAGAIN;
+goto out;
+ }
+ up(>sem);
if (!interruptible_sleep_on_timeout(>dma_dac.wait, HZ)) {
Re: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 09:17:56AM -0700, James Simmons wrote: > Is it possible to move serio.c and serport.c up into drivers/char. I'm > finding many drivers that use this and it is a mess to have to enable > joysticks just to use other types of devices like touchscreens. Possible it indeed is. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement: swap = RAM x 2.5 ??
In article <[EMAIL PROTECTED]>, Richard Gooch <[EMAIL PROTECTED]> wrote: > > Swap is "extra space to be used if we have it" and nothing else. > > Sure. But Linux still works without swap. It's just that if you *do* > have swap, it works best with 2* RAM. There is a large difference between saying Linux works best with 2*RAM, and Linux requires 2*RAM. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
> "Peter" == Peter Svensson <[EMAIL PROTECTED]> writes: Peter> Kelvin (decikelvin?) is probably a good unit to use in the Peter> kernel. If you want something else you convert it in the Peter> programs you use to interact with the kernel. This is a Peter> usespace issue, I think. How about BogoDegrees? Sorry, I will go and shoot myself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [driver] New life for Serial mice
On Wed, Jun 06, 2001 at 12:31:28PM -0400, Jeff Garzik wrote: > hmmm. I just looked over this, and drivers/char/joystick/ser*.[ch]. > > Bad trend. > > Serial needs to be treated just like parport: the basic hardware code, > then on top of that, a selection of drivers, all peers: dumb serial > port, serial mouse, joystick, etc. Agreed. Completely. And proposed a couple times before. But not in my power. So I used a N_MOUSE line discipline instead - the best tap into the serial/tty stack I found. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
