Re: 2.4.0-test11 EXT2 corruption (closed)
On Mon, Dec 11, 2000 at 01:37:36AM +0100, Guest section DW wrote: > > I see lots of messages from you about corruption in 2.4.0-test11 > but we all know very well that 2.4.0-test11 corrupts things > and further evidence is not necessary. > Hopefully all, or at least the most significant, problems > have been solved now, so you should upgrade to the most > recent test kernel and see how things are there. > Thanks. test12-pre7 fixes this for me: it ran all night testing and no problems so far. -- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100 driver update for 2.4
At 03:16 11/12/2000, Ion Badulescu wrote: >On Mon, 11 Dec 2000, Udo A. Steinberg wrote: >Anton Altaparmakov wrote: > > > My card is an Ether Express Pro 100, lcpci says: Intel Corporation 82557 > > > [Ethernet Pro 100] (rev 04) > >So it's an i82558 A-step. That's interesting, the patch shouldn't have >made any difference on an i82558, at least according to the documentation. I'll give test12-pre7 a try without the patch and see if the messages reappear. - With the patch it the box has been running all night without a single no resources message from the EEPro. > > > and lspci -n gives: class 0200: 10b7:9004 > >Umm.. I don't think so. :) This a 3Com 3c900B. You probably got the wrong >entry, in case you have multiple cards in that box. Sorry. Slipped by one line (box has several network cards - only the eepro gives the no resources messages, the 3com's are fine). The right one line is: 0200: 8086:1229 (rev 04) Anton -- "Education is what remains after one has forgotten everything he learned in school." - Albert Einstein -- Anton Altaparmakov Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile) Christ's CollegeeMail: [EMAIL PROTECTED] / [EMAIL PROTECTED] Cambridge CB2 3BUICQ: 8561279 United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
AW: Got "VM: do_try_to_free_pages failed for xyz" in 2.2.18pre27
Hi Ryan, > This is notice that the do_try_to_free_pages bug is still present in the > latest 2.2 kernel, 2.2.18pre27. > > VM: do_try_to_free_pages failed for kjournald... > VM: do_try_to_free_pages failed for kjournald... > VM: do_try_to_free_pages failed for kjournald... > > The error also occurs for other processes running on the system. This was > a test with ext3. > > The bug triggers when the system is really hammered (high system, network, > and disk load), and requires a reboot to recover. In case you haven't done so after trying 2.2.18pre27 and finding the VM bug still present: grab and apply andreas VM-global patch, it should fix the problem. ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pr e25/VM-global-2.2.18pre25-7.bz2 Bye, Martin "you have moved your mouse, please reboot to make this change take effect" -- Martin Bene vox: +43-316-813824 simon media fax: +43-316-813824-6 Nikolaiplatz 4e-mail: [EMAIL PROTECTED] 8020 Graz, Austria -- finger [EMAIL PROTECTED] for PGP public key - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Trouble with 2.4.0-test12-pre8
Hi I've had some very peculiar problems with 2.4.0-test12-pre8 In particular I can't start linux in single user mode, it goes to level 5 when trying to init 1. There is also a problem building fs/smbfs/inode.c at line 166 Is there a fix or have I got something really screwed up? -- Regards Bill Maidment Computer Systems Consultant _ Maidment Enterprises Pty Ltd 42 Woy Woy Bay Road Woy Woy Bay NSW 2256 _ Home Phone 02 4342 6716 Work Phone 02 9927 3234 Mobile 0418 682 993 Home Email [EMAIL PROTECTED] Work Email [EMAIL PROTECTED] Web Page www.maidment.com.au _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: APM-Bios Hang at Boot-up 2.2.16 2.2.17 2.2.18pre26
Right Thanks. I did not realize I was not in text mode. I have somehow fixed the problem by doing something to the apm-bios settings. I disabled a bunch of stuff in the bios and the thing is working apparently ok now. Don't ask me what cause I really don't know. It's just working now. Thanks, anyway. This message should not now be in html format... I hope. - Original Message - From: "David Feuer" <[EMAIL PROTECTED]> To: "Eddy" <[EMAIL PROTECTED]> Sent: Sunday, December 10, 2000 8:55 PM Subject: Re: APM-Bios Hang at Boot-up 2.2.16 2.2.17 2.2.18pre26 > Note for next time: don't post HTML mail messages to linux-kernel. This > annoys many people. > > -- > This message has been brought to you by the letter alpha and the number pi. > Open Source: Think locally; act globally. > David Feuer > [EMAIL PROTECTED] > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No shared memory??
Yeah I just read that. Thanks for the info. Knew nothing about it being kicked out there. I usually only read looking for package locations of needed software to run the kernels. Now it looks like I should be reading more. Thanks for the blow to the head to get me thinking right again. :) BTW, I have that mounted now like the docs say but I still do not get any shared info. I've gotten a couple of other emails about it, one of which states that it ate up too much CPU time. What I'm wondering is, is it possible to get that info some other way? I realize walking the process tree is a pain in the ass and expensive CPU and time wise. Also, I'm not sure if that information would include each process's private memory space. The reason I'm asking is that taking the overall memory used, subtracting the cached and buffered memory may not always leave the right amount of shared memory. (If I show 26MB used total, 21MB which is cached and 1MB that's buffered is it a FACT that the remaining 4MB unaccounted for is actually and completely shared memory?) Any other information on this would be appreciated. TO THE KERNEL DEVELOPERS = BTW, I love the devfs stuff. REALLY makes s big difference. I'm developing my own flavor of linux and it's quickly being modified to use ONLY devfs entries. > > On Sun, 10 Dec 2000 12:11:14 David D.W. Downey wrote: > > > > OK, got a tiny little bug here. > > > > When running top, procinfo, or free I get 0 for Shared memory. Obviously > > this is incorrect. What has changed from the 2.2.x and the 2.4.x that > > would cause these apps to misreport this information. > > > > Have you mounted /dev/shm (shared memory) filesystem ? > Take a look at kernel documentation under linux/Documentation/Changes. > > -- > Juan Antonio Magallon Lacarta #> cd /pub > mailto:[EMAIL PROTECTED] #> more beer > > Linux werewolf 2.2.18-pre25-vm #4 SMP Fri Dec 8 01:59:48 CET 2000 i686 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Signal 11
Well, I just had a Signal 11 even with the patch. What can I do to help figure this out? Thanks, --Rainer -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Friday, December 08, 2000 11:07 PM To: David Woodhouse Cc: Andi Kleen; Rainer Mager; [EMAIL PROTECTED]; Mark Vojkovich Subject: Re: Signal 11 > > wrong with it. I've only seen this under 2.3.x/2.4 SMP kernels. I > > would say that this is definitely a kernel problem.=20 > > XFree86 3.9 and XFree86 4 were rock solid for a _long_ time on 2.[34] > kernels - even on my BP6=B9. The random crashes started to happen when = > I > upgraded my distribution=B2 - and are only seen by people using 2.4. So= > I > suspect that it's the combination of glibc and kernel which is triggeri= > ng > it. Have any of the folks seeing it checked if Ben LaHaise's fixes for the page table updating race help ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Trouble with 2.4.0-test12-pre8
Hello, > There is also a problem building fs/smbfs/inode.c at line 166 > > Is there a fix or have I got something really screwed up? If you are referring to 'next' is not a member of the structure? If so, known issue. Regards, -Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
warning during make modules
i'm compiling kernel 2.4.0-test11 uder RH7. i've changed the CC= line to use
kgcc, executed "make clean" and "make mrproper". "make menuconfig" and "make
dep" went smoothly. however during the "make modules" process, several
warning messages (shown below) appeared:
{standard input}: Assembler messages:
{standard input}:8: Warning: Ignoring changed section attributes for
.modinfo
pls kindly advise how can i resolve the warning messages, or can i can
safely igonre the warning messages?
thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
YUP- Almost 2.2.18
Alan, I was trying to re-install my VMware with the latest 2.2.18 kernel. It failed to try to re-compile the modules. What is the location of the directory of C header files that match your running kernel? [/usr/src/linux/include] The directory of kernel headers (version 2.2.17) does not match your running kernel (version 2.2.18). Consequently, even if the compilation of the module wassuccessful, the module would not load into the running kernel. --- Upon inspection of /usr/src/linux/include/linux/version.h it plainly says 2.2.17 I changed it to 2.2.18 and all is well. Johnny O -- === Never ask a geek why, just nod your head and slowly back away.=== +==++ | John O'Donnell (Sr. Systems Engineer, Net Admin, Webmaster, etc.) | | Voice FX Corporation (a subsidiary of Student Advantage) | | One Plymouth Meeting | E-Mail: [EMAIL PROTECTED] | | Suite 610| www.voicefx.com | | Plymouth Meeting, PA 19462 | www.campusdirect.com | +==++ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18 almost...
did we lose ip=autoconf. I see dhcp and arp transmitting infinitely. I was able to boot only after completely entering nfsroot= and ip= boot commands. 2.2.17 worked thusley. root=/dev/nfs ether=0,0,eth0 2.2.18-pre26 works only root=/dev/nfs nfsroot=192.168.50.11:/tftpboot/191.168.50.2,rsize=8192,wsize=8192 ip=192.168.50.2:192.168.50.11:::Eddys486:eth0:off ether=0,0,eth0 for some reason root=/dev/nfs ether=0,0,eth0 gives this result Dec 10 22:48:24 Eddys dhcpd: BOOTREQUEST from 00:50:ba:05:7b:fb via eth0 Dec 10 22:48:24 Eddys dhcpd: BOOTREPLY for 192.168.50.2 to eddys486 (00:50:ba:05:7b:fb) via eth0 Dec 10 22:48:26 Eddys dhcpd: BOOTREQUEST from 00:50:ba:05:7b:fb via eth0 Dec 10 22:48:26 Eddys dhcpd: BOOTREPLY for 192.168.50.2 to eddys486 (00:50:ba:05:7b:fb) via eth0 Dec 10 22:48:29 Eddys dhcpd: BOOTREQUEST from 00:50:ba:05:7b:fb via eth0 Dec 10 22:48:29 Eddys dhcpd: BOOTREPLY for 192.168.50.2 to eddys486 (00:50:ba:05:7b:fb) via eth0 Dec 10 22:48:36 Eddys dhcpd: BOOTREQUEST from 00:50:ba:05:7b:fb via eth0 Dec 10 22:48:36 Eddys dhcpd: BOOTREPLY for 192.168.50.2 to eddys486 (00:50:ba:05:7b:fb) via eth0 Dec 10 22:48:47 Eddys dhcpd: BOOTREQUEST from 00:50:ba:05:7b:fb via eth0 Dec 10 22:48:47 Eddys dhcpd: BOOTREPLY for 192.168.50.2 to eddys486 (00:50:ba:05:7b:fb) via eth0 and root=/dev/nfs ip=both ether=0,0,eth0 gives this result Dec 10 22:50:52 Eddys dhcpd: DHCPDISCOVER from 00:50:ba:05:7b:fb via eth0 Dec 10 22:50:52 Eddys dhcpd: DHCPOFFER on 192.168.50.2 to 00:50:ba:05:7b:fb via eth0 Dec 10 22:50:55 Eddys dhcpd: DHCPDISCOVER from 00:50:ba:05:7b:fb via eth0 Dec 10 22:50:55 Eddys dhcpd: DHCPOFFER on 192.168.50.2 to 00:50:ba:05:7b:fb via eth0 Dec 10 22:51:00 Eddys dhcpd: DHCPDISCOVER from 00:50:ba:05:7b:fb via eth0 Dec 10 22:51:00 Eddys dhcpd: DHCPOFFER on 192.168.50.2 to 00:50:ba:05:7b:fb via eth0 Dec 10 22:51:09 Eddys dhcpd: DHCPDISCOVER from 00:50:ba:05:7b:fb via eth0 Dec 10 22:51:09 Eddys dhcpd: DHCPOFFER on 192.168.50.2 to 00:50:ba:05:7b:fb via eth0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: warning during make modules
On Mon, 11 Dec 2000 17:15:53 +0800,
"Corisen" <[EMAIL PROTECTED]> wrote:
>i'm compiling kernel 2.4.0-test11 uder RH7. i've changed the CC= line to use
>kgcc, executed "make clean" and "make mrproper". "make menuconfig" and "make
>dep" went smoothly. however during the "make modules" process, several
>warning messages (shown below) appeared:
>
>{standard input}: Assembler messages:
>{standard input}:8: Warning: Ignoring changed section attributes for
>.modinfo
>
>pls kindly advise how can i resolve the warning messages, or can i can
>safely igonre the warning messages?
You can safely ignore the messages. But if they get too annoying,
upgrade to modutils >= 2.3.19 (current is 2.3.22) and apply this patch.
Index: 0-test12-pre7.1/include/linux/module.h
--- 0-test12-pre7.1/include/linux/module.h Thu, 07 Dec 2000 09:20:04 +1100 kaos
(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3.1.1 644)
+++ 0-test12-pre7.2(w)/include/linux/module.h Mon, 11 Dec 2000 20:26:22 +1100 kaos
+(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3.1.2 644)
@@ -247,12 +247,6 @@ static const struct gtype##_id * __modul
__attribute__ ((unused)) = name
#define MODULE_DEVICE_TABLE(type,name) \
MODULE_GENERIC_TABLE(type##_device,name)
-/* not put to .modinfo section to avoid section type conflicts */
-
-/* The attributes of a section are set the first time the section is
- seen; we want .modinfo to not be allocated. */
-
-__asm__(".section .modinfo\n\t.previous");
/* Define the module variable, and usage macros. */
extern struct module __this_module;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] test12-pre8 task queue fix batch
On Sun, 10 Dec 2000, Mohammad A. Haque wrote: > More fixes. Ignore previous. diff -urw linux-2.4.0-test12.old/drivers/atm/ambassador.c linux-2.4.0-test12/drivers/atm/ambassador.c --- linux-2.4.0-test12.old/drivers/atm/ambassador.c Fri Jul 7 00:37:24 2000 +++ linux-2.4.0-test12/drivers/atm/ambassador.c Sun Dec 10 19:44:09 2000 @@ -2397,7 +2397,7 @@ #ifdef FILL_RX_POOLS_IN_BH // initialise bottom half - dev->bh.next = 0; + INIT_LIST_HEAD(&dev->bh.list); dev->bh.sync = 0; dev->bh.routine = (void (*)(void *)) fill_rx_pools; dev->bh.data = dev; > (and so on) I don't think this is the right fix. First of all, if one needed to the INIT_LIST_HEAD, some new macro should be introduced (INIT_TASK or something), which takes care of the .list and .sync structures. So when something was about to change again in the future, you wouldn't have to go through all the files and fix them again. But: The INIT_LIST_HEAD is unnecessary and misleading at least, because tqueue->list is not a list head, it's there to allow for adding the struct tqueue onto a task_queue. So we have the task_queue, that's the list head - it needs to be initialized, and that's already done via DECLARE_TASK_QUEUE. Then we have tasks to be added to the list (struct tqueue), their .list members don't need to be initialized because they get set when the task is queued on a task_queue (in queue_task). So I think the correct fix is just to remove the offending lines. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
inline docs question
Hi, which functions DON'T need inline documentation in the kernel? Thanks, Jani. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre25, S3, AMD K6-2, and MTRR....
Steven Walter <[EMAIL PROTECTED]> writes: > On Sun, Dec 10, 2000 at 06:20:31PM +, David Wragg wrote: > > If I understood why the MTRR driver was doing something on the K6-2, > > then model-specific differences might make some sense. But currently, > > I don't see why there would be any difference between "MTRR disabled" > > and "MTRR enabled, but not used". > > If I'm not mistaken, X /does/ touch the MTRR's, which would explain why > it is X that crashes. Only in XFree86-4.x (I never distributed my MTRR patches for XFree86-3.x ;-). Which is why the XFree86 version was one of the things I wanted to confirm. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH-2] Re: NR_RESERVED_FILES broken in 2.4 too
On Sun, 10 Dec 2000, Tigran Aivazian wrote:
> On Sun, 10 Dec 2000, Szabolcs Szakacsits wrote:
> > - this comment from include/linux/fs.h should be deleted
> > #define NR_RESERVED_FILES 10 /* reserved for root */
> well, not really -- it is "reserved" right now too, it is just root is
> allowed to use up all the reserved entries in the beginning and then when
> the normal user uses up all the "non-reserved" ones (from slab
> cache) there would be nothing left for the root.
And what real functionality does this provide? Close to nada. This is
why I told you if you are right then it's usefuless. So I think this
is a bug that was introduced accidentaly overlooking NR_RESERVED_FILES
functionality when get_empty_filp was rewritten to use the slab.
> But let us not argue about the above definition of "reserved" -- that is
> not productive.
Agree, this is why I made the patch ;) Also, this stupid
misunderstanding and waste of time between us is a *very* typical
example of the result of the super inferior Linux kernel source code
management. No way to dig up who and why dropped the reserved file
functionality about three years ago. "Hidden", unexplained patches
slip in almost every patch-set. Some developers think they can save a
huge amount of time by this "model", they just ignore other developers
and support people who need to understand what, when, why and by who a
changes happened. And because of lack of enough information [look,
both of us have and I think understand the code, still we don't agree]
the end result is that, apparently by now too many times the ball is
dropped back to these developers who get buried by even more job. This
is just one sign Linux has a hard future and unfortunately there are
others In general Linux is still one of the best today but
without addressing and solving current development problems it will
not be true after a couple of years. Linux remains just another Unix
and lose in 1:100 to another OS. The source is with us but it should
be used properly
> Let's do something productive -- namely, take your idea to
> the next logical step. Since you have proven that the freelist mechanism
> or concept of "reserve file structures" is not 100% satisfactory as is
This is also a difference between us. You look the problem from a
theoretical point of you, saying it's not 100%, I consider it from
practical point of you and say it gives close to 0% functionality for
users.
> then how about removing the freelist altogether? I.e. what about serving
I'm fine with the current implementation and more interested in bug
fixes. There could be one reason against the patch, performance. The
patch below has the same fix and TUX will give exactly the same
numbers [get_empty_filp code remains ugly but at least fast].
Szaka
diff -ur linux-2.4.0-test12-pre7/fs/file_table.c linux/fs/file_table.c
--- linux-2.4.0-test12-pre7/fs/file_table.c Fri Dec 8 08:17:12 2000
+++ linux/fs/file_table.c Mon Dec 11 10:40:41 2000
@@ -57,7 +57,9 @@
/*
* Allocate a new one if we're below the limit.
*/
- if (files_stat.nr_files < files_stat.max_files) {
+ if ((files_stat.nr_files < files_stat.max_files) && (!current->euid ||
+NR_RESERVED_FILES - files_stat.nr_free_files <
+files_stat.max_files - files_stat.nr_files)) {
file_list_unlock();
f = kmem_cache_alloc(filp_cachep, SLAB_KERNEL);
file_list_lock();
diff -ur linux-2.4.0-test12-pre7/include/linux/fs.h linux/include/linux/fs.h
--- linux-2.4.0-test12-pre7/include/linux/fs.h Fri Dec 8 15:06:55 2000
+++ linux/include/linux/fs.hSun Dec 10 17:37:52 2000
@@ -57,7 +57,7 @@
extern int leases_enable, dir_notify_enable, lease_break_time;
#define NR_FILE 8192 /* this can well be larger on a larger system */
-#define NR_RESERVED_FILES 10 /* reserved for root */
+#define NR_RESERVED_FILES 128 /* reserved for root */
#define NR_SUPER 256
#define MAY_EXEC 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18 almost...
> did we lose ip=autoconf. I see dhcp and arp transmitting infinitely. I was > able to boot only after completely entering nfsroot= and ip= boot commands. > > 2.2.17 worked thusley. : I didn't try with 2.2.18 yet but looking at the source (ipconfig.c) seem that my patch wasn't accepted, you can give it a try : http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0213.html hope this help, luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Announce: RSBAC v1.1.0 released
Hi!
Rule Set Based Access Control (RSBAC) for Linux version 1.1.0 has been released.
Information and downloads are available from
http://www.rsbac.org
Amon Ott.
--
Name: rsbac
Version: 1.1.0
Kernelver: 2.2.17, 2.4.0-test10,11
Status:9 (UP), 7 (SMP)
Author:Amon Ott <[EMAIL PROTECTED]>
Maintainer:Amon Ott <[EMAIL PROTECTED]>
Description: Rule Set Based Access Control (RSBAC)
Date: 30-November-2000
Descfile-URL: http://www.rsbac.org/rsbac.desc
Download-URL: http://www.rsbac.org/download.htm
Homepage-URL: http://www.rsbac.org/
Manual-URL:http://www.rsbac.org/instadm.htm
What is RSBAC?
--
RSBAC is an open source security extension for current Linux kernels.
It is based on the Generalized Framework for Access Control (GFAC) by
Abrams and LaPadula and provides a flexible system of access control
based on several modules.
All security relevant system calls are extended by security
enforcement code. This code calls the central decision component, which
in turn calls all active decision modules and generates a combined decision.
This decision is then enforced by the system call extensions.
Decisions are based on the type of access (request type), the access target
and on the values
of attributes attached to the subject calling and to the target to be
accessed. Additional independent attributes can be used by individual modules,
e.g. the
privacy module (PM). All attributes are stored in fully protected
directories, one on each mounted device. Thus changes to attributes require
special system calls provided.
As all types of access decisions are based on general decision requests,
many different security policies can be implemented as a decision module. In
the current RSBAC version (1.1.0), eight modules are included:
MAC: Bell-LaPadula Mandatory Access Control (limited to 64 compartments)
FC: Functional Control. A simple role based model, restricting access
to security information to security officers and access to system
information to administrators.
SIM: Security Information Modification. Only security
administrators are allowed to modify data labeled as security information
PM: Privacy Model. Simone Fischer-Huebner's Privacy Model in its first
implementation. See our paper on PM implementation for the National
Information Systems Security Conference (NISSC 98)
MS: Malware Scan. Scan all files for malware on execution
(optionally on all file read accesses or on all TCP/UDP read accesses),
deny access if infected. Currently the Linux viruses Bliss.A and Bliss.B
and a handfull of others are detected. See our paper on malware detection
and avoidance for The Third Nordic Workshop on Secure IT Systems (Nordsec'98)
FF: File Flags. Provide and use flags for dirs and files,
currently execute_only (files), read_only (files and dirs), search_only
(dirs), secure_delete (files) and add_inherited (files and dirs).
Only security officers may modify these flags.
RC: Role Compatibility. Defines (up to) 64 roles and 64 types for each
target type (file, dir, dev, ipc, scd, process). For each role compatibility
to all types and to other roles can be set individually and with request
granularity.
AUTH: Authorization enforcement. Controls all CHANGE_OWNER
requests for process targets, only programs/processes with general setuid
allowance and those with a capability for the target user ID may setuid.
Capabilities are controlled by other programs/processes.
ACL: Access Control Lists. For every object there is an Access Control List,
defining which subjects may access this object with which request types.
Subjects can be of type user, RC role and ACL group. Objects are grouped
by their target type, but have individual ACLs. If there is no ACL entry for a
subject at an object, rights are inherited from parent objects, restricted by
an inheritance mask. Direct (user) and indirect (role, group) rights are
accumulated.
For each object type there is a default ACL on top of the normal hierarchy.
Group management has been added in version 1.0.9a.
The underlying models are described in the module description at RSBAC
homepage (http://www.rsbac.org).
A general goal of RSBAC has been to some day reach (obsolete) Orange Book
(TCSEC) B1 level. Now it is mostly targeting to be useful as secure and
multi-purposed networked system, with special interest in firewalls.
Changes against 1.0.9b:
-
- Port to 2.4.0-test11
- Interception of sys_mmap and sys_mprotect added. Now execution of
library code requires EXECUTE privilege on the library file, and
setting non-mmapped memory to EXEC mode requires EXECUTE on target
NONE.
- MAC Light option by Stanislav Ievlev added. See kernel config help or
modules.htm.
- Port to 2.4.0-test{[789]|10}, this means major changes to the lookup
and inheritance code - of course #ifdef'd
- Change string declarations to kmalloc.
Re: warning during make modules
Hi Keith,
Thanks for your reply. The below mentioned warning messages where displayed
while using modutils 2.3.22. Guess I need to apply the patch you mentioned
to removed all the anonying messages.
As I've not applied any patch before, pls advise where should I download the
patch and the instructions for patching pls.
Thanks.
- Original Message -
From: Keith Owens <[EMAIL PROTECTED]>
To: Corisen <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 5:27 PM
Subject: Re: warning during make modules
> On Mon, 11 Dec 2000 17:15:53 +0800,
> "Corisen" <[EMAIL PROTECTED]> wrote:
> >i'm compiling kernel 2.4.0-test11 uder RH7. i've changed the CC= line to
use
> >kgcc, executed "make clean" and "make mrproper". "make menuconfig" and
"make
> >dep" went smoothly. however during the "make modules" process, several
> >warning messages (shown below) appeared:
> >
> >{standard input}: Assembler messages:
> >{standard input}:8: Warning: Ignoring changed section attributes for
> >.modinfo
> >
> >pls kindly advise how can i resolve the warning messages, or can i can
> >safely igonre the warning messages?
>
> You can safely ignore the messages. But if they get too annoying,
> upgrade to modutils >= 2.3.19 (current is 2.3.22) and apply this patch.
>
> Index: 0-test12-pre7.1/include/linux/module.h
> --- 0-test12-pre7.1/include/linux/module.h Thu, 07 Dec 2000 09:20:04 +1100
kaos (linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3.1.1 644)
> +++ 0-test12-pre7.2(w)/include/linux/module.h Mon, 11 Dec 2000 20:26:22
+1100 kaos (linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3.1.2 644)
> @@ -247,12 +247,6 @@ static const struct gtype##_id * __modul
>__attribute__ ((unused)) = name
> #define MODULE_DEVICE_TABLE(type,name) \
>MODULE_GENERIC_TABLE(type##_device,name)
> -/* not put to .modinfo section to avoid section type conflicts */
> -
> -/* The attributes of a section are set the first time the section is
> - seen; we want .modinfo to not be allocated. */
> -
> -__asm__(".section .modinfo\n\t.previous");
>
> /* Define the module variable, and usage macros. */
> extern struct module __this_module;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] initrd vs. BLKFLSBUF
I'm posting this again hoping that it'll get incorporated into the kernel. I've tested the patch against 2.4.0-test12-pre8, and it's working fine. Thanks, Jeff [ [EMAIL PROTECTED] ] - Original Message - From: "Werner Almesberger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, November 20, 2000 11:21 AM Subject: [PATCH,RFC] initrd vs. BLKFLSBUF Hi Al, Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk that was obtained via initrd. I think the problem is that the effect of the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that seems to solve the problem. Since I'm not quite sure I understand the reference counting rules there, I would appreciate your comment. Thanks, - Werner -- cut here --- --- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000 +++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000 @@ -690,6 +690,7 @@ done: if (infile.f_op->release) infile.f_op->release(inode, &infile); + blkdev_put(out_inode->i_bdev, BDEV_FILE); set_fs(fs); return; free_inodes: /* free inodes on error */ -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] initrd vs. BLKFLSBUF
I'm posting this again hoping that it'll get incorporated into the kernel. I've tested the patch against 2.4.0-test12-pre8, and it's working fine. Thanks, Jeff [ [EMAIL PROTECTED] ] - Original Message - From: "Werner Almesberger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, November 20, 2000 11:21 AM Subject: [PATCH,RFC] initrd vs. BLKFLSBUF Hi Al, Jeff Chua reported a while ago that BLKFLSBUF returns EBUSY on a RAM disk that was obtained via initrd. I think the problem is that the effect of the blkdev_open(out_inode, ...) in drivers/block/rd.c:rd_load_image is not undone at the end. I've attached a patch for 2.4.0-test11-pre7 that seems to solve the problem. Since I'm not quite sure I understand the reference counting rules there, I would appreciate your comment. Thanks, - Werner -- cut here --- --- linux.orig/drivers/block/rd.c Mon Nov 20 02:07:47 2000 +++ linux/drivers/block/rd.c Mon Nov 20 04:03:42 2000 @@ -690,6 +690,7 @@ done: if (infile.f_op->release) infile.f_op->release(inode, &infile); + blkdev_put(out_inode->i_bdev, BDEV_FILE); set_fs(fs); return; free_inodes: /* free inodes on error */ -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: warning during make modules
On Mon, 11 Dec 2000 19:05:42 +0800,
"Corisen" <[EMAIL PROTECTED]> wrote:
>Thanks for your reply. The below mentioned warning messages where displayed
>while using modutils 2.3.22. Guess I need to apply the patch you mentioned
>to removed all the anonying messages.
>
>As I've not applied any patch before, pls advise where should I download the
>patch and the instructions for patching pls.
The patch is in the original email, reproduced below. It is against
linux-2.4.0-test12-pre7 but will fit -pre8 as well. The Kernel-HOWTO
(part of the howto package) has a section on patching the kernel.
Index: 0-test12-pre7.1/include/linux/module.h
--- 0-test12-pre7.1/include/linux/module.h Thu, 07 Dec 2000 09:20:04 +1100 kaos
(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3.1.1 644)
+++ 0-test12-pre7.2(w)/include/linux/module.h Mon, 11 Dec 2000 20:26:22 +1100 kaos
+(linux-2.4/W/33_module.h 1.1.2.1.2.1.2.1.2.1.1.3.1.2 644)
@@ -247,12 +247,6 @@ static const struct gtype##_id * __modul
__attribute__ ((unused)) = name
#define MODULE_DEVICE_TABLE(type,name) \
MODULE_GENERIC_TABLE(type##_device,name)
-/* not put to .modinfo section to avoid section type conflicts */
-
-/* The attributes of a section are set the first time the section is
- seen; we want .modinfo to not be allocated. */
-
-__asm__(".section .modinfo\n\t.previous");
/* Define the module variable, and usage macros. */
extern struct module __this_module;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11 EXT2 corruption (closed)
On Mon, 11 Dec 2000, Frank van Maarseveen wrote: > On Mon, Dec 11, 2000 at 01:37:36AM +0100, Guest section DW wrote: > > > > I see lots of messages from you about corruption in 2.4.0-test11 > > but we all know very well that 2.4.0-test11 corrupts things > > and further evidence is not necessary. > > Hopefully all, or at least the most significant, problems > > have been solved now, so you should upgrade to the most > > recent test kernel and see how things are there. > > > Thanks. test12-pre7 fixes this for me: it ran all night testing and > no problems so far. > I'm running test12-pre7 and had a bad lockup a couple of days ago. Or actually it wasnt a lockup it was a "klonk" in the harddrive when I started netscape then the machine rebooted. And I had a corruption in the $HOME/.netscape/cache directory. No logged messages or anything anywhere. The machine just rebooted and I had to manually fsck /home. Johan > -- > Frank > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
Dietmar Kling wrote: > > Ok guys i take your arguments... > (i really loved to hear them) > > and i'd like to continue them in a > private discussion( but i am > tired now ... :) ) > > but a last one i cannot resist... > > > but why are your ideas not widespread and > so successful like kde,gnome,windows? Please don't put KDE into the same bunch as gnome or windows. KDE is in fact *well designed*! In esp. 2.0 > maybe because they suck at some point? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18 almost...
> root=/dev/nfs ip=both ether=0,0,eth0 gives this result > > Dec 10 22:50:52 Eddys dhcpd: DHCPDISCOVER from 00:50:ba:05:7b:fb via eth0 > Dec 10 22:50:52 Eddys dhcpd: DHCPOFFER on 192.168.50.2 to 00:50:ba:05:7b:fb > via eth0 Those are DHCP. 'both' is the old keywords for rarp and bootp. It now behaves as it should do for compatibility. Try 'on' or 'all' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: inline docs question
> which functions DON'T need inline documentation in the kernel? A good guide initially is probably 'document those that are exported via EXPORT_SYM() only' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: INIT_LIST_HEAD marco audit
Thinko.
Question is... Adam Richter posted a patch for i2o_lan.c that does
this...
static struct tq_struct i2o_post_buckets_task = {
list: LIST_HEAD_INIT(i2o_post_buckets_task.list),
sync: 0,
routine: (void (*)(void *))i2o_lan_receive_post,
data: (void *) 0
};
If that's correct then is the only fix for structures similar to
tcic_task to type cast the routine?
Alan Cox wrote:
>
> > -static struct tq_struct tcic_task = {
> > - routine:tcic_bh
> > +DECLARE_TASK_QUEUE(tcic_task);
> > +struct tq_struct run_tcic_task = {
> > + routine:(void (*)(void *)) tcic_bh
> > };
>
> Why remove the 'static' ?
--
=
Mohammad A. Haque http://www.haque.net/
[EMAIL PROTECTED]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[EMAIL PROTECTED]
=
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Signal 11
On Mon, 11 Dec 2000, Rainer Mager wrote: > Well, I just had a Signal 11 even with the patch. What can I do to help > figure this out? Is init permanently running after you see a couple of these? -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 11 Dec 2000 14:38:52 Martin Dalecki wrote: > > Please don't put KDE into the same bunch as gnome or > windows. KDE is in fact *well designed*! In esp. 2.0 > That is why you need a supercomputer to run KDE at acceptable interactive speeds... -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux werewolf 2.2.18-vm #1 SMP Mon Dec 11 02:36:30 CET 2000 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: NTFS repair tools]
> You could just tell people the truth. Something far worse that DANGEROUS. > Like: > > CRIPPLED BY LEGAL DURESS > > Or as I come to understand: > > The processes that would normally have fixed this driver by now > are broken by the vigorous defense of Microsoft's IP. > It will trash your disk! maybe not right now .. > > I couldn't understand why I hadn't seen any real movement on this driver. > Now it makes sense. Perhaps others might enjoy this understanding. This one is a must !! Let's put it in the kernel conf. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
No Subject
Recently I had some thoughts on how to realise CPU attachment and detachment in a running Linux system (based on the 2.4 kernel). CPU attachment and detachment would make sense on an S/390 when there are several Linuxes running, each in its own logical partition. This way a CPU could be taken from one partition and be given to another partition (e.g. dependent on the current workload) on the fly without the need to reboot anything. Now the question is: how can this goal be achieved? Attachment of a new CPU: The idea is to synchronize all CPUs and then start the new CPU with a sigp. To synchronize n CPUs one can create n kernel threads and give them a high priority to make sure they will be executed soon (e.g. by setting p->policy to SCHED_RR and p->rt_priority to a very high value). As soon as all CPUs are in synchronized state (with interrupts disabled) the new CPU can be started. But before this can be done there are some other things left to do: First of all a new cpu_idle task needs to be created for the new CPU. Unfortunately there are several other parts in the kernel that need to be updated when a new CPU will be attached to the running system. For example the slabcache has a per-CPU cache for each of its caches. This implies that with the arrival of a new CPU for each of these caches a new per-CPU cache needs to be allocated. This is of course only one issue in the common part of the kernel that needs to be addressed. Considering this maybe it would be a good idea that each part of the kernel that has per-CPU data structures that need an update should register a function which will be called before a new CPU will be attached to the system. Then the attachment of a new CPU should work the following way: - synchronize all CPUs via kernel threads - create a new idle task - update all parts of the kernel that have per-CPU dependencies with the prior registered functions - and finally start the new CPU (out of one of the kernel threads). Detachment of a CPU: Detaching a CPU should work nearly the same way: - synchronize all CPUs via kernel threads - stop the selected CPU (out of a kernel thread) - update all parts of the kernel that have per-CPU dependencies with registered functions - and finally remove the cpu_idle task of the released CPU (and the kernel thread which ran on the released CPU until the CPU was stopped). Detaching a CPU is a bit more difficult than attaching a CPU because one has to think for example of pending tasklets on the to be stopped CPU. But these could simply be moved to another CPU. The general question is: what do all of you think of the idea of an interface where the parts of the kernel that have per-CPU dependencies should register two functions (one for attaching a CPU and one for detaching)? Any comments on this would be appreciated.. Best regards, Heiko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
CPU attachent and detachment in a running Linux system
Recently I had some thoughts on how to realise CPU attachment and detachment in a running Linux system (based on the 2.4 kernel). CPU attachment and detachment would make sense on an S/390 when there are several Linuxes running, each in its own logical partition. This way a CPU could be taken from one partition and be given to another partition (e.g. dependent on the current workload) on the fly without the need to reboot anything. Now the question is: how can this goal be achieved? Attachment of a new CPU: The idea is to synchronize all CPUs and then start the new CPU with a sigp. To synchronize n CPUs one can create n kernel threads and give them a high priority to make sure they will be executed soon (e.g. by setting p->policy to SCHED_RR and p->rt_priority to a very high value). As soon as all CPUs are in synchronized state (with interrupts disabled) the new CPU can be started. But before this can be done there are some other things left to do: First of all a new cpu_idle task needs to be created for the new CPU. Unfortunately there are several other parts in the kernel that need to be updated when a new CPU will be attached to the running system. For example the slabcache has a per-CPU cache for each of its caches. This implies that with the arrival of a new CPU for each of these caches a new per-CPU cache needs to be allocated. This is of course only one issue in the common part of the kernel that needs to be addressed. Considering this maybe it would be a good idea that each part of the kernel that has per-CPU data structures that need an update should register a function which will be called before a new CPU will be attached to the system. Then the attachment of a new CPU should work the following way: - synchronize all CPUs via kernel threads - create a new idle task - update all parts of the kernel that have per-CPU dependencies with the prior registered functions - and finally start the new CPU (out of one of the kernel threads). Detachment of a CPU: Detaching a CPU should work nearly the same way: - synchronize all CPUs via kernel threads - stop the selected CPU (out of a kernel thread) - update all parts of the kernel that have per-CPU dependencies with registered functions - and finally remove the cpu_idle task of the released CPU (and the kernel thread which ran on the released CPU until the CPU was stopped). Detaching a CPU is a bit more difficult than attaching a CPU because one has to think for example of pending tasklets on the to be stopped CPU. But these could simply be moved to another CPU. The general question is: what do all of you think of the idea of an interface where the parts of the kernel that have per-CPU dependencies should register two functions (one for attaching a CPU and one for detaching)? Any comments on this would be appreciated.. Best regards, Heiko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Signal 11
On Mon, 11 Dec 2000, Rainer Mager wrote: > Well, I just had a Signal 11 even with the patch. What can I do to help > figure this out? My troublesome box finally seems to be stable. It's been up for the last two days whilst under quite heavy loads without problems. Previously, it would be lucky to last an hour. The change? I disabled DRM & AGPGart. With them both disabled, I get no problems at all. No Sig11's, No Sig4's, No lockups. This box has a Voodoo3 3000 AGP.. 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) And is running on an MVP3 chipset 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] This box does display the same problem with IRQ routing that I've got on my Athlon box... PCI: Using IRQ router VIA [1106/0586] at 00:07.0 PCI: Assigned IRQ 11 for device 00:08.0 PCI: The same IRQ used for device 01:00.0 IRQ routing conflict in pirq table! Try 'pci=autoirq' (00:08:0 is an SBLive) A related problem ? As I mentioned in an earlier mail `autoirq' is an unknown option. The Athlon box has similar messages, but it happens with even more devices.. They both do the same with the various PCI options 'nobios' etc, and changing PnP OS in the BIOS makes no difference either. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No shared memory??
"David D.W. Downey" <[EMAIL PROTECTED]> writes: > When running top, procinfo, or free I get 0 for Shared memory. Obviously > this is incorrect. What has changed from the 2.2.x and the 2.4.x that > would cause these apps to misreport this information. Known 2.4 behaviour. It is simply to costly to calculate that. It will always show as 0. Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipchains log will show all flags
Hi,
This tiny patch extends ipchains logging. This way one can distinguish
(plain) connection attempts and (stealth) scans. E.g.
kernel: Packet log: input - lo PROTO=6 127.0.0.1:40326 127.0.0.1:80
L=40 S=0x00 I=5808 F=0x T=51 (#1)
vs.
L=40 S=0x00 I=5808 F=0x T=51 SYN ACK (#1)
and
L=40 S=0x00 I=5808 F=0x T=51 URG PSH SYN FIN (#1)
Some comments on the format have been considered. I dislike
bloating my logging with "URG ACK PSH RST SYN FIN " and like to see a
compact format (eg. "B=fsrpau"). Despite that iptables does it the
former way (linux-2.4.0-test11/net/ipv4/netfilter/ipt_LOG.c).
Please note that SYN is not any longer SYN && !ACK && !RST. This will
break log parser that look for connection initiation packets.
Besides ipchains(8) man page is wrong. FIN should be RST?
[!] -y, --syn
Only match TCP packets with the SYN bit set and the
ACK and FIN bits cleared. Such packets are used to
Could you please comment on the tradeoff between multiple printk()'s and
the printk("%s", "")?
Logging the FW Mark value was suggested by Roberto Nibali <[EMAIL PROTECTED]>
Could be included as printk(" M=%d", f->ipfw.fw_mark);
The patch is against 2.2.17's /net/ipv4/ip_fw.c
ipchains logging all flags Christian W. Zuckschwerdt <[EMAIL PROTECTED]>
--- linux-2.2.17-pristine/net/ipv4/ip_fw.c.orig Mon Nov 27 00:38:36 2000
+++ linux-2.2.17/net/ipv4/ip_fw.c Mon Dec 11 15:10:51 2000
@@ -41,6 +41,9 @@
* John McDonald <[EMAIL PROTECTED]>
* Thomas Lopatic <[EMAIL PROTECTED]>
* 21-Oct-1999: Applied count fix by Emanuele Caratti <[EMAIL PROTECTED]> --RR
+ * 11-Dec-2000: Added "URG ACK PSH RST SYN FIN" in log message.
+ * Please note SYN is no longer SYN && !ACK && !RST
+ * Christian W. Zuckschwerdt <[EMAIL PROTECTED]>
*/
/*
@@ -443,7 +443,24 @@
for (opti = 0; opti < (ip->ihl - sizeof(struct iphdr) / 4); opti++)
printk(" O=0x%8.8X", *opt++);
- printk(" %s(#%d)\n", syn ? "SYN " : /* "PENANCE" */ "", count);
+
+ if ((ip->protocol == IPPROTO_TCP) && !(ip->frag_off & htons(IP_OFFSET))) {
+ struct tcphdr *tcp=(struct tcphdr *)((__u32 *)ip+ip->ihl);
+ /* Max length: 36 " URG ACK PSH RST SYN FIN" */
+ if (tcp->urg)
+ printk(" URG");
+ if (tcp->ack)
+ printk(" ACK");
+ if (tcp->psh)
+ printk(" PSH");
+ if (tcp->rst)
+ printk(" RST");
+ if (tcp->syn)
+ printk(" SYN");
+ if (tcp->fin)
+ printk(" FIN");
+ }
+ printk(" (#%d) M=%d\n", count, f->ipfw.fw_mark);
}
/* function for checking chain labels for user space. */
--
cu.
:
Christian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] initrd vs. BLKFLSBUF
Jeff Chua wrote: > I'm posting this again hoping that it'll get incorporated into the kernel. It's already in Alan's tree (e.g. patch-2.4.0test11-ac1.bz2) and should find its way from there into Linus' tree soon (i.e. probably by test12). - Werner -- _ / Werner Almesberger, ICA, EPFL, CH [EMAIL PROTECTED] / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
> sigp. To synchronize n CPUs one can create n kernel threads and give > them a high priority to make sure they will be executed soon (e.g. by > setting p->policy to SCHED_RR and p->rt_priority to a very high > value). As soon as all CPUs are in synchronized state (with > interrupts disabled) the new CPU can be started. But before this can > be done there are some other things left to do: You dont IMHO need to use such a large hammer. We already do similar sequences for tlb invalidation on X86 for example. You can broadcast an interprocessor interrupt and have the other processors set a flag each. You spin until they are all captured, then when you clear the flag they all continue. You just need to watch two processors doing it at the same time 8) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Wait Queues
I am trying to modify a driver that worked great
on 2.2.16 to 2.4.0-x..
My old code was:
static struct wait_queue *roundrobin_wait;
static struct wait_queue *task_stop_wait; static struct
tq_struct roundrobin_task; static struct timer_list timeout_timer;
...
init_timer(&timeout_timer);
timeout_timer.function = Timer; timeout_timer.data = (unsigned
long)&timer_data; timeout_timer.expires = jiffies + 3*HZ;
void Timer(unsigned long ptr) {
struct clientdata *pTimerData = (struct clientdata *)
ptr;
if
(pTimerData->one_shot_queue_task){
// start the main round robin
queue_task(&roundrobin_task, &tq_scheduler);
pTimerData->one_shot_queue_task = FALSE; }
/* wake-up the task responsible
for the Timeout callbacks round-robin */
wake_up_interruptible(&roundrobin_wait);
/* re-schedule this Timer
function */
init_timer(&timeout_timer);
timeout_timer.function = Timer;
timeout_timer.data = (unsigned long)&timer_data;
timeout_timer.expires = jiffies + HZ/100;
add_timer(&timeout_timer); } void RoundRobin(void *ptr)
{ struct clientdata *data = (struct clientdata *)
ptr;
interruptible_sleep_on(&roundrobin_wait);
if
(data->queue) // data->queue set to NULL in
Stop() { /*
do whatever you want to do here ... */
OSALTimeoutCallback *pCallback =
data->callback;
pCallback->RoundRobinCallbacks(); }
/* re-register itself, if
needed */ roundrobin_task.routine = RoundRobin;
//main_round_robin; roundrobin_task.data = (void *)
&roundrobin_data; if
(data->queue) {
queue_task(&roundrobin_task,
data->queue); } else
{
wake_up_interruptible(&task_stop_wait);
} }
Carlo Pagano
Software Designer
Trisignal Communications, a division
of i-data Technology
(514) 832-3603
[EMAIL PROTECTED]
Re: kapm-idled : is this a bug?
[EMAIL PROTECTED] (Rik van Riel) writes: > On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote: > [snip whine] > > > I've consistently re-produced this on my Dell Latitude CS laptop. I'm > > wondering if this will reduce battery life since the CPU is constantly > > being loaded instead of properly idled. > > What do you suppose the 'idled' in 'kapm-idled' stands for? We know it was an attempt to stop people complaining about the fact that "kapm" was hogging the CPU. Looks like it doesn't work. At the time, I had a look at the kernel source, and came to the conclusion that there was no easy way for the cpu accounting in "do_process_times()" to automatically assign ticks from a particular process to the idle process. However, would it be possible for apm_cpu_idle() to periodically assign the values for per_cpu_*time for the kernel thread to the idle process? This isn't a performance critical part of the kernel, and would lead to less false reports (as above). -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 and aacraid patch
hi, I think you forgot some revert of the aaccraid patch, thing like that : #ifdef CONFIG_SCSI_AACRAID #include "aacraid/include/linit.h" #endif in drivers/scsci/hosts.c make no sense. revert patch attached PS: even if it doen't change anything actually it may help when need to apply the patch to don't have reject. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel --- linux/drivers/scsi/hosts.c.chmouMon Dec 11 12:19:25 2000 +++ linux/drivers/scsi/hosts.c Mon Dec 11 12:25:42 2000 @@ -131,10 +131,6 @@ #include "aha1740.h" #endif -#ifdef CONFIG_SCSI_AACRAID -#include "aacraid/include/linit.h" -#endif - #ifdef CONFIG_SCSI_AIC7XXX #include "aic7xxx.h" #endif @@ -492,9 +488,6 @@ #endif #ifdef CONFIG_SCSI_AHA1740 AHA1740, -#endif -#ifdef CONFIG_SCSI_AACRAID -AAC_HOST_TEMPLATE_ENTRY, #endif #ifdef CONFIG_SCSI_AIC7XXX AIC7XXX, --- linux/arch/i386/defconfig.chmou Mon Dec 11 12:19:23 2000 +++ linux/arch/i386/defconfig Mon Dec 11 12:21:41 2000 @@ -166,7 +166,6 @@ # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set -# CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_ADVANSYS is not set --- linux/MAINTAINERS.chmou Mon Dec 11 12:19:23 2000 +++ linux/MAINTAINERS Mon Dec 11 12:22:32 2000 @@ -93,12 +93,6 @@ L: [EMAIL PROTECTED] S: Maintained -AACRAID ADAPTEC RAID DRIVER -P: Brian M. Boerner -M: [EMAIL PROTECTED] -L: To Be Announced -S: Maintained - AD1816 SOUND DRIVER P: Thorsten Knabe M: Thorsten Knabe <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[minor patch] pci.h
Hi Martin
this patch makes computing of pci_resource_len a bit more
straightforward and hopefully still correct.Plus an aesthetic change in a
struct declaration :)
--- /usr/src/clean/linux/include/linux/pci.hMon Dec 11 16:49:19 2000
+++ pci.h Mon Dec 11 17:54:24 2000
@@ -432,8 +432,7 @@
int (*write_dword)(struct pci_dev *, int where, u32 val);
};
-struct pbus_set_ranges_data
-{
+struct pbus_set_ranges_data {
int found_vga;
unsigned long io_start, io_end;
unsigned long mem_start, mem_end;
@@ -636,9 +635,8 @@
#define pci_resource_end(dev,bar) ((dev)->resource[(bar)].end)
#define pci_resource_flags(dev,bar) ((dev)->resource[(bar)].flags)
#define pci_resource_len(dev,bar) \
- ((pci_resource_start((dev),(bar)) == 0 && \
- pci_resource_end((dev),(bar)) == \
- pci_resource_start((dev),(bar))) ? 0 :\
+ (!(pci_resource_start((dev),(bar)) || \
+ pci_resource_end((dev),(bar))) ? 0 :\
\
(pci_resource_end((dev),(bar)) - \
pci_resource_start((dev),(bar)) + 1))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
NFS: set_bit on an 'int' variable OK for 64-bit?
Hello, since test11, the NFS code uses the set_bit and related routines to manipulate the wb_flags member of the nfs_page struct (nfs_page.h). Unfortunately, wb_flags has still data type 'int'. This is a problem (at least) on the 64-bit S/390 architecture, as our ..._bit macros assume bit 0 is the least significant bit of a 'long', which means due to big-endian byte order that bit 0 resides in the 7th byte of the variable. As an int occupies only 4 bytes, however, set_bit(0, int) clobbers memory. Now the question is, who's correct? At all other places (I found, at least), the ..._bit macros are indeed used only on 'long' variables (or arrays). However, on the Alpha, the ..._bit routines assume bit 0 to be the least significant bit of an 'int'. Sparc64 on the other hand also uses 'long' :-/ What do you suggest we should do? Fix nfs_page to use a 'long' variable, or change our bitops macros to use ints? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS: set_bit on an 'int' variable OK for 64-bit?
> "Ulrich" == Ulrich Weigand <[EMAIL PROTECTED]> writes: Ulrich> Hello, Ulrich> since test11, the NFS code uses the set_bit and related Ulrich> routines to manipulate the wb_flags member of the nfs_page Ulrich> struct (nfs_page.h). Unfortunately, wb_flags has still data Ulrich> type 'int'. Ulrich> This is a problem (at least) on the 64-bit S/390 architecture, Ulrich> as our ..._bit macros assume bit 0 is the least significant Ulrich> bit of a 'long', which means due to big-endian byte order that Ulrich> bit 0 resides in the 7th byte of the variable. As an int Ulrich> occupies only 4 bytes, however, set_bit(0, int) clobbers Ulrich> memory. Ulrich> Now the question is, who's correct? You are, the bit macros should only be used on long's. It happens to work on little endian bitfield machines like the Alpha but thats the same as when we had the problem with bit operations on char * in the file system code a couple of years ago. The NFS code needs to be fixed for this then. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS: set_bit on an 'int' variable OK for 64-bit?
> since test11, the NFS code uses the set_bit and related routines > to manipulate the wb_flags member of the nfs_page struct (nfs_page.h). > Unfortunately, wb_flags has still data type 'int'. NFS is wrong. Rusty did a complete audit of the code and I've been feeding some stuff to Linus. That one may have been missed > What do you suggest we should do? Fix nfs_page to use a 'long' > variable, or change our bitops macros to use ints? Fix NFS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18-25 DELL Laptop Video Problems
On Mon, Dec 11, 2000 at 08:26:46AM +0100, Dominik Kubla wrote: > On Sun, Dec 10, 2000 at 03:50:16PM -0700, Jeff V. Merkey wrote: > > > > Can you enable both at the same time? It's an installer issue with laptops > > and I need tobe able to detect whatever is running. > > > > IIRC you can choose at boot time using a kernel parameter. Then this is the vga=271 stuff? Jeff > > Dominik > -- > Drug misuse is not a disease, it is a decision, like the decision to step > out in front of a moving car. You would call that not a disease but an > error of judgment. --Philip K. Dick. Author's Note, A SCANNER DARKLY, 1977 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 11 Dec 2000, Martin Dalecki wrote: > Please don't put KDE into the same bunch as gnome or > windows. KDE is in fact *well designed*! In esp. 2.0 'Tis funny, you know, because ISTR that the bloody thing got the same problems with the program sizes, API bloat and lack of orthogonality. Last time I've looked at their codebase was ~6 months ago and it was rather vomit-inducing. The fact that there is a holy war doesn't mean that one of the sides doesn't suck - usually both do... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit ( getting off topic)
- Original Message - From: J . A . Magallon <[EMAIL PROTECTED]> To: Martin Dalecki <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, December 11, 2000 8:47 AM Subject: Re: ANNOUNCE: Linux Kernel ORB: kORBit > > On Mon, 11 Dec 2000 14:38:52 Martin Dalecki wrote: > > > > Please don't put KDE into the same bunch as gnome or > > windows. KDE is in fact *well designed*! In esp. 2.0 > > > > That is why you need a supercomputer to run KDE at acceptable interactive > speeds... umm, does a pentium 166Mhz with 32MB of RAM qualify as a supercomputer? KDE 1.1.2 on Linux-Mandrake 7.1 here. I WILL try KDE 2.0.1 and let you know how it runs. Matthew D. Pitts [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cardbus pirq conflict
Hello,
I tried this patch against test12-pre7, and all that I get is
"cs: socket c7604800 timed out during reset. Try increasing
setup_delay."
Performing cardctl reset yields the same message. I think that
cardctl reset takes away the possibility that increasing
setup_delay would actually help.
The Oops on shutdown no longer occurs, so I believe that you
have fixed the race contition you descdibed. The Oops was
also occuring on apm resume, but that has ceased as well.
I will try testing some other cardbus cards later today, and will
also experiment with an unpatch test12-pre8
Cheers!
--Matt Galgoci
>
> Could you please test this stuff?
>
>
>
> --- linux-2.4.0-test12-pre7/include/linux/sched.h Thu Dec 7 22:05:21 2000
> +++ linux-akpm/include/linux/sched.h Sat Dec 9 01:36:19 2000
> @@ -152,6 +152,7 @@
> extern int schedule_task(struct tq_struct *task);
> extern void run_schedule_tasks(void);
> extern int start_context_thread(void);
> +extern int current_is_keventd(void);
>
> /*
> * The default fd array needs to be at least BITS_PER_LONG,
> --- linux-2.4.0-test12-pre7/include/linux/kernel.hThu Dec 7 22:05:21 2000
> +++ linux-akpm/include/linux/kernel.h Sat Dec 9 01:22:18 2000
> @@ -63,6 +63,8 @@
> extern int get_option(char **str, int *pint);
> extern char *get_options(char *str, int nints, int *ints);
> extern unsigned long memparse(char *ptr, char **retptr);
> +extern void dev_probe_lock(void);
> +extern void dev_probe_unlock(void);
>
> extern int session_of_pgrp(int pgrp);
>
> --- linux-2.4.0-test12-pre7/drivers/pci/pci.c Thu Dec 7 22:05:20 2000
> +++ linux-akpm/drivers/pci/pci.c Sat Dec 9 01:24:46 2000
> @@ -300,18 +300,25 @@
> pci_announce_device(struct pci_driver *drv, struct pci_dev *dev)
> {
> const struct pci_device_id *id;
> + int ret = 0;
>
> if (drv->id_table) {
> id = pci_match_device(drv->id_table, dev);
> - if (!id)
> - return 0;
> + if (!id) {
> + ret = 0;
> + goto out;
> + }
> } else
> id = NULL;
> +
> + dev_probe_lock();
> if (drv->probe(dev, id) >= 0) {
> dev->driver = drv;
> - return 1;
> + ret = 1;
> }
> - return 0;
> + dev_probe_unlock();
> +out:
> + return ret;
> }
>
> int
> @@ -360,9 +367,9 @@
> if (!hotplug_path[0])
> return;
>
> - sprintf(class_id, "PCI_CLASS=%X", pdev->class);
> - sprintf(id, "PCI_ID=%X/%X", pdev->vendor, pdev->device);
> - sprintf(sub_id, "PCI_SUBSYS_ID=%X/%X", pdev->subsystem_vendor,
>pdev->subsystem_device);
> + sprintf(class_id, "PCI_CLASS=%04X", pdev->class);
> + sprintf(id, "PCI_ID=%04X:%04X", pdev->vendor, pdev->device);
> + sprintf(sub_id, "PCI_SUBSYS_ID=%04X:%04X", pdev->subsystem_vendor,
>pdev->subsystem_device);
> sprintf(bus_id, "PCI_SLOT_NAME=%s", pdev->slot_name);
>
> i = 0;
> --- linux-2.4.0-test12-pre7/kernel/exit.c Thu Dec 7 22:05:21 2000
> +++ linux-akpm/kernel/exit.c Fri Dec 8 22:38:30 2000
> @@ -302,9 +302,9 @@
> {
> struct mm_struct * mm = tsk->mm;
>
> + mm_release();
> if (mm) {
> atomic_inc(&mm->mm_count);
> - mm_release();
> if (mm != tsk->active_mm) BUG();
> /* more a memory barrier than a real lock */
> task_lock(tsk);
> --- linux-2.4.0-test12-pre7/kernel/kmod.c Thu Dec 7 22:05:21 2000
> +++ linux-akpm/kernel/kmod.c Sat Dec 9 11:53:32 2000
> @@ -256,21 +256,6 @@
>
> #endif /* CONFIG_HOTPLUG */
>
> -
> -static int exec_helper (void *arg)
> -{
> - long ret;
> - void **params = (void **) arg;
> - char *path = (char *) params [0];
> - char **argv = (char **) params [1];
> - char **envp = (char **) params [2];
> -
> - ret = exec_usermodehelper (path, argv, envp);
> - if (ret < 0)
> - ret = -ret;
> - do_exit(ret);
> -}
> -
> struct subprocess_info {
> struct semaphore *sem;
> char *path;
> @@ -279,73 +264,36 @@
> int retval;
> };
>
> -/*
> - * This is a standalone child of keventd. It forks off another thread which
> - * is the desired usermode helper and then waits for the child to exit.
> - * We return the usermode process's exit code, or some -ve error code.
> - */
> static int call_usermodehelper(void *data)
> {
> struct subprocess_info *sub_info = data;
> - struct task_struct *curtask = current;
> - void *params [3] = { sub_info->path, sub_info->argv, sub_info->envp };
> - pid_t pid, pid2;
> - mm_segment_t fs;
> - int retval = 0;
> + int retval;
>
> - if (!curtask->fs->root) {
> - printk(KERN_ERR "call_usermodehelper[%s]: no root fs\n",
>sub_info->path);
> - retval = -EPERM;
> - goto up_and_out;
> - }
> - if ((pid = kernel_thread(exec_helper, (void *) params,
Re: ANNOUNCE: Linux Kernel ORB: kORBit
Alexander Viro wrote: > > On Mon, 11 Dec 2000, Martin Dalecki wrote: > > > Please don't put KDE into the same bunch as gnome or > > windows. KDE is in fact *well designed*! In esp. 2.0 > > 'Tis funny, you know, because ISTR that the bloody thing > got the same problems with the program sizes, API bloat and lack of > orthogonality. Last time I've looked at their codebase was ~6 months > ago and it was rather vomit-inducing. > > The fact that there is a holy war doesn't mean that one of the sides > doesn't suck - usually both do... I do not understand this "i saw it - yuck! - and now i want to kill it " point of view. As I tried to point out. Things evolve. And the evolution has the right do things wrong. Next evolution step will do it probably better. Al same as kernel development. With your attitude i'd have dropped linux 0.99 immediatly. Remember the code in certain parts? So what is your point? I accept only shiny little masterpieces of software? Thats not the way it works IMHO. Best Regards Dietmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CPU attachent and detachment in a running Linux system
Heiko, If I'm not mistaken, this sort of thing has been done by the beowulf folks. Matthew D. Pitts [EMAIL PROTECTED] - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 11, 2000 9:03 AM Subject: CPU attachent and detachment in a running Linux system Recently I had some thoughts on how to realise CPU attachment and detachment in a running Linux system (based on the 2.4 kernel). CPU attachment and detachment would make sense on an S/390 when there are several Linuxes running, each in its own logical partition. This way a CPU could be taken from one partition and be given to another partition (e.g. dependent on the current workload) on the fly without the need to reboot anything. Now the question is: how can this goal be achieved? Attachment of a new CPU: The idea is to synchronize all CPUs and then start the new CPU with a sigp. To synchronize n CPUs one can create n kernel threads and give them a high priority to make sure they will be executed soon (e.g. by setting p->policy to SCHED_RR and p->rt_priority to a very high value). As soon as all CPUs are in synchronized state (with interrupts disabled) the new CPU can be started. But before this can be done there are some other things left to do: First of all a new cpu_idle task needs to be created for the new CPU. Unfortunately there are several other parts in the kernel that need to be updated when a new CPU will be attached to the running system. For example the slabcache has a per-CPU cache for each of its caches. This implies that with the arrival of a new CPU for each of these caches a new per-CPU cache needs to be allocated. This is of course only one issue in the common part of the kernel that needs to be addressed. Considering this maybe it would be a good idea that each part of the kernel that has per-CPU data structures that need an update should register a function which will be called before a new CPU will be attached to the system. Then the attachment of a new CPU should work the following way: - synchronize all CPUs via kernel threads - create a new idle task - update all parts of the kernel that have per-CPU dependencies with the prior registered functions - and finally start the new CPU (out of one of the kernel threads). Detachment of a CPU: Detaching a CPU should work nearly the same way: - synchronize all CPUs via kernel threads - stop the selected CPU (out of a kernel thread) - update all parts of the kernel that have per-CPU dependencies with registered functions - and finally remove the cpu_idle task of the released CPU (and the kernel thread which ran on the released CPU until the CPU was stopped). Detaching a CPU is a bit more difficult than attaching a CPU because one has to think for example of pending tasklets on the to be stopped CPU. But these could simply be moved to another CPU. The general question is: what do all of you think of the idea of an interface where the parts of the kernel that have per-CPU dependencies should register two functions (one for attaching a CPU and one for detaching)? Any comments on this would be appreciated.. Best regards, Heiko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
Steven Cole <[EMAIL PROTECTED]> writes: [...] > In each case, the task and the tools used are the same. The only > difference was the kernel used. In both cases, 2.2.18 won by 3%. > Its comparing apples to apples and oranges to oranges. Granted 3% > isn't very much, but I would have guessed that 2.4.0 would have been > the winner. It wasn't, at least for this single processor machine. Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1 (according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with egcs for a fairer comparison. (2) The new VM was a performance regression for throughput. I think that it is important that the extent of the indisputable performance decreases be quantified and traced. For me there was a subjective performance peak around 2.3.48 IIRC, though it might have been before. Andrea Archangeli has a VM patch that seems to help in some cases. It would be interesting to run a series of (automated) tests on a lot of kernel versions, and to see how far performance is behind FreeBSD (or even NetBSD). [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
On 11 Dec 2000, John Fremlin wrote: > Two points: [snipped] Doing a 'make bzImage' is NOT VM-intensive. Using this as a test for the VM doesn't make any sense since it doesn't really excercise the VM in any way... If you want to measure, or even just bitch about, the VM, you should at least quote results from something that uses the VM ;) regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
> Doing a 'make bzImage' is NOT VM-intensive. Using this as a test > for the VM doesn't make any sense since it doesn't really excercise > the VM in any way... Its an interesting demo that 2.4 has some performance problems since 2.2 is slower than 2.0 although nowdays not much. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CPU attachent and detachment in a running Linux system
Heiko and Matthew - I'm pretty certain this is not something beowulfish, unless perhaps you are thinking in terms of mosix and some of the other batch/queueing systems. Beowulf after all is a set of distributed processors, not SMP (although an individual node maybe SMP). regards, Per Jessen, London On Mon, 11 Dec 2000 13:11:11 -0500, Matthew D. Pitts wrote: >Heiko, >If I'm not mistaken, this sort of thing has been done by the beowulf folks. > >Matthew D. Pitts >[EMAIL PROTECTED] > >- Original Message - >From: <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Monday, December 11, 2000 9:03 AM >Subject: CPU attachent and detachment in a running Linux system [snip] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test12-pre7 shutdowns and eepro100 woes
Hello all, test12-pre7 seems to randomly just power off my machine. CONFIG_APM=y and CONFIG_APM_REAL_MODE_POWER_OFF=y as well. Could this be what is making it power off the machine randomly? Has it been fixed in pre8? I wasn't doing much on the machine at the time.. it just happens sporadically. Also, regarding the eepro100 driver, are there any plans to fix support for the following chipset (given by lspci): 02:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2) Chipset Ethernet (rev 01) I have one of these at work and I will get the following messages: Dec 11 10:46:13 morpheus kernel: eepro100: cmd_wait for(0xff80) +timedout with(0xff80)! Dec 11 10:46:20 morpheus last message repeated 6 times (using eepro100 from 2.2.18pre27.. I guess it's not 2.2.18 proper) Thanks in advance, Tom ps. please reply to my e-mail address. Thanks! __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 11 Dec 2000, Dietmar Kling wrote: > I do not understand this > "i saw it - yuck! - and now i want to kill it " s/want to kill it/do not want to touch it/ > point of view. > As I tried to point out. Things evolve. And > the evolution has the right do things wrong. > Next evolution step will do it probably better. You do realize what "evolution" means? I'm not talking about the bugs in implementation. I'm talking about botched design. _That_ never gets fixed. Show me one example when that would happen and I might consider taking such possibility seriously. > Al same as kernel development. With your attitude > i'd have dropped linux 0.99 immediatly. > Remember the code in certain parts? And? It wasn't nearly that huge and what matters _much_ more it was not that tasteless. > So what is your point? > I accept only shiny little masterpieces of software? No. The larger it is - the harder it is to redesign. And both GNOME and KDE are _way_ past the size*severity_of_misdesign threshold. IOW, I simply don't believe that either project has sufficient manpower to fix their stuff. And that's orders of magnitude insufficient. As far as I can see they are also way past "it's easier to do from scratch than to fix" threshold. The same reason why I don't believe that NT will ever become decent OS, even if the full source would become available, yodda, yodda. Feel free to prove me wrong, but I would be very surprised to see it. And yes, the fact that UNIX was conceptually simple and relatively small helped it _big_ way. Small beasts adapt and propagate. Huge ones tend to become dead-ends. So much for evolution... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapm-idled : is this a bug?
very helpful. Technical merits and voter intent aside, this behavior is misleading and inconsistent with previous kernels. Tools like top or a CPU dock applet show a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled' seems like the wrong answer. stewart On Mon, 11 Dec 2000, Rik van Riel wrote: > On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote: > > [snip whine] > > > I've consistently re-produced this on my Dell Latitude CS laptop. I'm > > wondering if this will reduce battery life since the CPU is constantly > > being loaded instead of properly idled. > > What do you suppose the 'idled' in 'kapm-idled' stands for? > > Rik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
> You do realize what "evolution" means? I'm not talking about the bugs > in implementation. I'm talking about botched design. _That_ never gets > fixed. Show me one example when that would happen and I might consider > taking such possibility seriously. That's what I am talking about in my "mean" attitude. Some things must be carried until the dead end. When there's no place to move anymore than new things will evolve. < short thinking > As for your second point. Take libc5 and libc6. I really have no *deep* insight. But I believe redesigning it for Multithreading was mayor step. Regards Dietmar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: fatal lockup, BIOS/CMOS reset?
** Reply to message from "Jonathan Brugge" <[EMAIL PROTECTED]> on Sun, 10 Dec 2000 22:49:05 +0100 > I got a message about a bad CMOS and when I looked in my > BIOS-settings I saw they were totally reset... No HD's, date was 1/1/2000, > etc. The BIOS will do this at boot time if it detects that the checksum bytes in the CMOS are incorrect. That's probably what happened - somehow, one or more bytes in your CMOS got altered, and during the reboot the BIOS detected this and reset all CMOS bytes. The CMOS can be programmed using I/O ports 70h and 71h. Just a couple of bad I/O operations to those ports, and your CMOS is toast. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please direct the reply to the mailing list only. Don't send another copy to me. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapm-idled : is this a bug?
> Technical merits and voter intent aside, this behavior is misleading and > inconsistent with previous kernels. Tools like top or a CPU dock applet show the goal of kernel revision is *not* to remain consistent with old stuff. > a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled' > seems like the wrong answer. so don't run APM already. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapm-idled : is this a bug?
On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote: > > very helpful. > > Technical merits and voter intent aside, this behavior is misleading and > inconsistent with previous kernels. Tools like top or a CPU dock applet show > a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled' > seems like the wrong answer. > > stewart > Err.. Did you see the comment about shared memory info being permanently removed because (something about too CPU intensive to justify...)? It looks like we need to find another way to get kernel info rather than from /proc. We need to calculate stuff only when it's needed. Calculating stuff all the time, to make it available should somebody care to read it in the /proc file-system is wasteful. Maybe we need to have some kind of 'kernel ioctl' where a user-mode caller 'pays' for the CPU cycles necessary to obtain the info that the caller requests. A better idea might be to have the 'read' of a particular /proc file-system item, result in the calculation of the new values. That way, the read and calculation of new values gets charged to the reader. In any event, the continuous calculation of 'kernel stuff' that may be read once a week at most, is definitely a waste of CPU cycles. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove warning from drivers/net/hp100.c (240-test12-pre7)
On Sat, Dec 09, 2000 at 04:37:40PM -0600, Peter Samuelson wrote:
>
> [Pavel Machek]
> > I'd say that warning is more acceptable than #ifdef... In cases where
> > warnings can be eliminating without ifdefs, that's okay, but this...
>
> In this case it is dead weight in the object file -- and for machines
> that can least afford it (CONFIG_PCI=n is mostly for the low end,
> right?).
How about this patch? It moves the offending struct to the __init function
where it is used and inside an existing #ifdef CONFIG_PCI. This would be
up to the maintainer but since this is the only place the struct is used
I think it is acceptable to move it from the top of the file.
Comments?
--- linux-240-t12-pre8-clean/drivers/net/hp100.cSat Nov 4 23:27:07 2000
+++ linux/drivers/net/hp100.c Mon Dec 11 21:23:12 2000
@@ -265,13 +265,6 @@
#define HP100_EISA_IDS_SIZE(sizeof(hp100_eisa_ids)/sizeof(struct hp100_eisa_id))
-static struct hp100_pci_id hp100_pci_ids[] = {
- { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_J2585A },
- { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_J2585B },
- { PCI_VENDOR_ID_COMPEX, PCI_DEVICE_ID_COMPEX_ENET100VG4 },
- { PCI_VENDOR_ID_COMPEX2, PCI_DEVICE_ID_COMPEX2_100VG }
-};
-
#define HP100_PCI_IDS_SIZE (sizeof(hp100_pci_ids)/sizeof(struct hp100_pci_id))
static int hp100_rx_ratio = HP100_DEFAULT_RX_RATIO;
@@ -335,6 +328,13 @@
int ioaddr = 0;
#ifdef CONFIG_PCI
int pci_start_index = 0;
+
+ static struct hp100_pci_id hp100_pci_ids[] = {
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_J2585A },
+ { PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_J2585B },
+ { PCI_VENDOR_ID_COMPEX, PCI_DEVICE_ID_COMPEX_ENET100VG4 },
+ { PCI_VENDOR_ID_COMPEX2, PCI_DEVICE_ID_COMPEX2_100VG }
+ };
#endif
#ifdef HP100_DEBUG_B
--
Regards,
Rasmus([EMAIL PROTECTED])
It's a recession when your neighbour loses his job; it's a depression
when you lose yours. -- Harry S. Truman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Bad behavior of recv on already closed sockets.
Hello! > Looks like it tries to read on socket which is already closed from other > side. And it seems like recv did not return in this case. Is this OK, or > kernel bug? This smells like an unknown bug in kernel. It is unknown, hence there is no workaround (but upgrading to 2.4). It would be better to understand the issue f.e. trying to restore the history of this descriptor. > On the other side I see entries like this: > httpd 4260 root4u IPv4 12173018 TCP > 127.0.0.1:3994->127.0.0.1:5432 (CLOSE_WAIT) > > And again. There is no any corresponding postmaster process. Does anyone has > such expirience before? And what can be the reason of such strange things. And this is bug in the application, which forgot to close file. Descriptor leakage in httpd or it is blocked at some another job. But remembering about the first case, I am not so sure. What does httpd make this time? Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
Alan Cox wrote:
>
> > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> > for the VM doesn't make any sense since it doesn't really excercise
> > the VM in any way...
>
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower than 2.0 although nowdays not much.
Speaking about performance - could someone explain me why
md5checksumming on 10GB
partition is taking my whole 128MB memory and is permamently swaping out
every application off my memory to swap so the computer is very slow
during
this process???
Could I set somewhere in /proc that I do not wish to have 100MB disk
buffers ?
--
Zdenek Kabelac http://i.am/kabi/ [EMAIL PROTECTED] {debian.org; fi.muni.cz}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18 vanilla on SMP, latency
Same latencies as 2.2.16 and 2.2.17 vanilla, over 75 seconds to wait on an other screen! And top(1) on a serial VT510 freezes. Machine loaded with 2 setiathome and Doug Ledford's memtest. ASUS P2B-DS Dual PIII550 1024MB memory, only SCSI devices (no IDE!). Andrea Arcangeli's ..17pre6aa2, ..18pre17aa1 and ..18pre21aa2 reduced the latency <2 secs. Regards Mario Vanoni PS If necessary, cc, not in lkml! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cardbus pirq conflict
I goofed in the report below. I had switched to the i82365 pcmcia driver to see if it was affected by the pirq problems the night before, and forgotten to switch back to the yenta_socket. Switching back to the yenta_socket, plus andrewm's keventd patch allowed the collection of cardbus pcmcia cards to work. Apm suspend and shutting down the machine do not cause an Oops either. I do however still recieve a nasty message about a pirq table conflict, but it does not seem to affect the operation of the card. The pirq conflict message seems a little harsh though, and perhaps unnecessary. Thank you all. Cheer! --Matt Galgoci On Mon, Dec 11, 2000 at 12:48:16PM -0500, Matthew Galgoci wrote: > > Hello, > > I tried this patch against test12-pre7, and all that I get is > "cs: socket c7604800 timed out during reset. Try increasing > setup_delay." > > Performing cardctl reset yields the same message. I think that > cardctl reset takes away the possibility that increasing > setup_delay would actually help. > > The Oops on shutdown no longer occurs, so I believe that you > have fixed the race contition you descdibed. The Oops was > also occuring on apm resume, but that has ceased as well. > > I will try testing some other cardbus cards later today, and will > also experiment with an unpatch test12-pre8 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 + megaraid : success
Hi Alan, I've compiled a plain 2.2.18 kernel for the HP NetServer this afternoon, and guess what ? (ok, I know that you guessed) : the netraid card now works correctly. BTW, I noticed that the firmware and bios versions are improperly displayed (only garbage). According to the code, that's because the identification method differs between HP and others, so the HP method is disabled for now. but this one will be wrong too because the major number is taken from productInfo->FwVer[1]>>8 (which is an u8), instead of >>4. I hope that tomorrow I will have a bit of time to try to clarify this and make it display the right version, and properly identify an HP (fwver[0] seems not to be used on them). Cheers, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
In article <[EMAIL PROTECTED]> you wrote: >> Doing a 'make bzImage' is NOT VM-intensive. Using this as a test >> for the VM doesn't make any sense since it doesn't really excercise >> the VM in any way... > Its an interesting demo that 2.4 has some performance problems since 2.2 > is slower than 2.0 although nowdays not much. Seems to depend on the hardware used. On my test box, 2.4 is faster by 0.3s Greetings, Arjan van de Ven Machine: AMD Duron 700Mhz with 128Mb of 133Mhz Ram 2 IBM 15Gb ATA100 disks in RAID0 raid tested kernels: 2.2.18 + raid patch + latest IDE patch 2.4.0-test12pre7 compiling 2.2.18 with gcc 2.95.2 1st run 2nd 3rd kernel 2.2.18/raid/ide 3:28.9093:28.8193:28.840 kernel 2.4.0test12pre7 3:28:5203:28.5343:28.546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
On Mon, 11 Dec 2000, Jamie Lokier wrote: > Here are a few more: > > net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE, > net/gmac.c: PCI_CACHE_LINE_SIZE, 8); > scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n", For this one, this happens on Intel: - ONLY if PCI cache line size was configured to ZERO (i.e. not configured). AND - ONLY if user asked for this through the boot command line. Anyway, the driver WARNs user about if it shoe-horns some value as you can see above. Btw, there is a single case where using MWI is a workaround. Given that all known systems have a known PCI CACHE LINE SIZE for L2/L3, if POST software + O/S PCI driver are loose enough not to provide the RIGHT value of the PCI CACHE LINE LINE for devices that support it, what software drivers can do ? May-be, they should just refuse to attach the device, at least when this information _must_ be known in order to work-around a device problem. This will remove some ugly code for non-Intel plat-forms from the sym53c8xx source, by the way. Having to call some pdev_enable_device() to have the cache line size configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER, etc.. are configured prior to entering driver probe. Why should the cache line size be deferred to some call to some obscure mismaned thing ? [...] Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Mon, 11 Dec 2000, Dietmar Kling wrote: > > You do realize what "evolution" means? I'm not talking about the bugs > > in implementation. I'm talking about botched design. _That_ never gets > > fixed. Show me one example when that would happen and I might consider > > taking such possibility seriously. > > That's what I am talking about in my "mean" attitude. Some things > must be carried until the dead end. When there's no place to move > anymore than new things will evolve. Minix is still alive. > < short thinking > > As for your second point. Take libc5 and libc6. I really have no > *deep* insight. But I believe redesigning it for Multithreading > was mayor step. ... and libc6 was not a result of evolution of libc5 - they have a common ancestor, but they got several years of divergent evolution before the displacement had happened. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
hard lockups
I have a PC164 Alpha (500Mhz) and I get hard lock ups randomly when accessing the internet. It happens very frequently (like within a few minutes) with 2.4 kernels, but happens much more infrequently with 2.2 kernels. Also, I have to compile the kernel for generic alpha (NOT PC164) otherwise I get ide-probe errors on bootup. My network card is a 3com boomerang (I think? it uses 3c59x.o and it's PCI). Any ideas? --Ray Strode _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
On Mon, 11 Dec 2000, Alan Cox wrote: > > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test > > for the VM doesn't make any sense since it doesn't really excercise > > the VM in any way... > > Its an interesting demo that 2.4 has some performance problems > since 2.2 is slower than 2.0 although nowdays not much. Indeed, but blaming the VM subsystem for something which hardly touches the VM is a tad strange ... Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cardbus pirq conflict
On Mon, 11 Dec 2000, Matthew Galgoci wrote: > > I do however still recieve a nasty message about a pirq table > conflict, but it does not seem to affect the operation of the > card. It doesn't. > The pirq conflict message seems a little harsh though, and perhaps > unnecessary. It is a bit harsh, and while not unnecessary I'll have to do something about it. What is going on is that a lot of laptops appear to have a pirq routing table for PCI bus #1 (and sometimes #2), even though that bus does not actually exist in hardware at all. My suspicion is that the BIOS writers just re-use the same pirq table over and over again, and that it's just a remnant of the fact that some laptops have either a docking station bus or an AGP bus as bus #1. When Linux assigns bus #1 to the CardBus bridge, those bogus entries in the pirq routing table will show up as conflicts. They'll be ignored, but it's still a nasty message. The problem is that the message probably _should_ be printed for the real case of a misconfigured BIOS, if for no other reason than to try to track down what the h*ll is going on. My tentative fix for this would be to make Linux never assign bus #1 or #2 to a cardbus bridge, and start cardbus bridges at bus #8 or something like that. That way we'd still catch any strangeness in the pirq table, but we wouldn't get the message for this case which seems to be very common. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CPU attachent and detachment in a running Linux system
On Mon, 11 Dec 2000 15:03:47 [EMAIL PROTECTED] wrote: > > Recently I had some thoughts on how to realise CPU attachment and > detachment in a running Linux system (based on the 2.4 kernel). > > CPU attachment and detachment would make sense on an S/390 when there > are several Linuxes running, each in its own logical partition. This > way a CPU could be taken from one partition and be given to another > partition (e.g. dependent on the current workload) on the fly without > the need to reboot anything. > Perhaps the PSet project can help you, take a look at http://isunix.it.ilstu.edu/~thockin/pset/ I think it can be a good thing, now that linux has to manage with many CPUs. But i think it is discontinued. -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux werewolf 2.2.18-vm #1 SMP Mon Dec 11 02:36:30 CET 2000 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote: > On Mon, 11 Dec 2000, Jamie Lokier wrote: > > > Here are a few more: > > > > net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE, > > Acenic is at least setting it to the correct values, not hardcoding it. > > > net/gmac.c: PCI_CACHE_LINE_SIZE, 8); > > Ick. > > > scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n", > > **vomit** A BASTARD you are. Linux was born thanks to volunteers that spent thousands of hours on their free time for helping development. If you vomit on me, let me shit on you. > On the plus side, they made it arch independant. Shame it's incomplete. > If you look at the x86 path, its missing Pentium 4 support (x86==15). Most of the code in Linux was there years ago prior to the Pentium 4 that, by the way, looks like the buggiest thing that are ever existed. > It also screws up on Athlon where it should be set to 16, but gets 8. Same for this one. > I wouldn't be surprised if the other arch's were missing some definitions > too. The fact that this driver is a port of FreeBSD driver may be the > reason why SMP_CACHE_BYTES wasn't used instead, and the author opted > for that monster. But still, the whole thing is completely unnecessary. The driver is back to FreeBSD and is intended to go to other Free O/Ses as I will find time for. [...] Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
Hello Gerard! > Having to call some pdev_enable_device() to have the cache line size > configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER, > etc.. are configured prior to entering driver probe. Once upon a time, they used to be, but they no longer are. Unfortunately, there are lots of bogus devices which must be never assigned BARs nor routed interrupts. You need to call pci_enable_device() after you recognize the device as handled by your driver to get BARs and interrupts set up. Also, if your driver uses bus mastering, it should call pci_set_master(). > Why should the cache line size be deferred to some call to some obscure > mismaned thing ? See above. I'm also not joyfully jumping when I think of it, but consider it being a tax on being compatible with the rough world of buggy PCI devices. Anyway, it's still zillion times better than random drivers modifying such configuration registers in random manner, knowing nothing about the host bridge and other such stuff. (Side note: I'm not saying the method your driver uses was bad at the time it was designed, I'm only saying that it's wrong wrt. the rest of the kernel and it should be gone.) Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ CChheecckk yyoouurr dduupplleexx sswwiittcchh.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] aty128fb & >8bit
> Hello. I just noticed that in 2.2.18pre27 you can only use the aty128fb > driver at 8 bit, because of some missing bits to drivers/video/Config.in. > w/o this you can't use console at > 8 bit nor X. I would consider this to > be a good thing to squash for 2.2.18 final because 2.2.18 is the 1st release > in a while that works well on PPC, and lots of PPCs have a rage128. Also, this patch to make it compile as module. How did these get removed? I could have swore they used to work fine. Sorry for the attachment. This computer has evolution. Brad Douglas [EMAIL PROTECTED] http://www.linux-fbdev.org --- linux-2.2.18pre25/drivers/video/Makefile Mon Dec 11 12:05:55 2000 +++ linux/drivers/video/Makefile Thu Dec 7 15:26:03 2000 @@ -106,6 +106,10 @@ ifeq ($(CONFIG_FB_ATY128),y) L_OBJS += aty128fb.o +else + ifeq ($(CONFIG_FB_ATY128),m) + MX_OBJS += aty128fb.o + endif endif ifeq ($(CONFIG_FB_IGA),y)
Re: cardbus pirq conflict
Hi Linus! > My tentative fix for this would be to make Linux never assign bus #1 or #2 > to a cardbus bridge, and start cardbus bridges at bus #8 or something like > that. That way we'd still catch any strangeness in the pirq table, but we > wouldn't get the message for this case which seems to be very common. Agreed. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ CChheecckk yyoouurr dduupplleexx sswwiittcchh.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
On Sat, Dec 09, 2000 at 12:41:24AM -0500, Theodore Y. Ts'o wrote: > > There was is usual with these sorts of things, multiple problems I was > dealing with. The first was that I was trying to use cardmgr, and my > pcmcia config file was still trying to load epic_cb. Oops. David, you > might want to mention of this caveat in the README-2.4 file in the > pcmcia-cs package. I'm aware of the problem but I'm not actually sure what to present as the appropriate solution yet; in the new scheme, cardmgr should just ignore these cards and not load any module at all (as /sbin/hotplug should do that). But I haven't decided how cardmgr will deduce that. By the way, in my hands, PCMCIA serial cards do work ok with the 2.4 PCMCIA modules as of test12-pre7. So I'm not sure what's going on in Ted's situation, if the non-kernel PCMCIA is working: there should not be much different for 16-bit cards. I do seem to have some new problems with Cardbus cards that I wasn't having with earlier 2.4 releases but I haven't made any attempt to figure that out yet. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotplug mopup
> > - I don't think we can say that the kernel hotplug interface is > > complete until we have real, working, tested userspace tools. David, > > could you please summarise the state of play here? In particular, > > what still needs to be done? > > Well, for USB I would like to know which device major/minor entry a newly > plugged device is associated with. > > Like if I insert a new USB camera, I want to easy find out it is char 81.1 > (/dev/video1). Or if I plugin a USB storage device I want to easy find out > it is /dev/sda now. How might that relate to devfs integration? It addresses similar problems, and devfsd can call to userspace when such drivers (ones that show up through major/minor device nodes) appear. True, some folk who want to hotplug might want to not run devfs. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SysRq behavior
Hi! > I don't remember having the same problem months (6?) ago when > I built my first Kernel with this enabled (well, maybe I never > touched the key). > > When built into the Kernel, by only pressing the > PrintScreen/SysRq the current application is terminated (tested > on a console and GNU screen). Is this just me or I should > expect it? Probably bug. Happens for me, too, and it is pretty nasty. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: K6-2+ and MSR registers (PowerNOW)
Hi! > Bought myself this new CPU that is mainly available for laptops. > > I have Tyan S1590 board which BIOS won't POST if I set cpu speed (it's > 500Mhz chip) >300Mhz. This won't matter much in windows since I can there > use graphical utility which allows one to set whe CPU clock multiplier in > flight as 2.0 - 6.0. But since my machine is Linux like 98% of the time > I'd like to do same in linux. > > Things I have considered are. Do I need to recalculate BoGos? Do I need to > reserve the IO space to access it from user space. You should recalculate bogomips. Hell _may_ break loose if you don't, but it probably will not. > In the end it would be nice to do proc entry or user space program that > allows one to [sg]et cpu speed and other PowerNOW properties. Hmm, it would be nice if generic interface existed: my philips velo 1 can set cpu speed in range 2MHz .. 40MHz. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
Hi! > > This email is here to announce the availability of a port of ORBit (the > > GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from > > our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB > > allows you to write kernel extensions in CORBA and have the kernel call > > into them, or to call into the kernel through CORBA. This opens the door > > to a wide range of experiments/hacks: > > > > * We can now write device drivers in perl, and let them run on the iMAC > > across the hall from you. :) > > Why would you *ever* want to write a device driver in perl??? Well, why not? When I created driver for 3com homefree camera (USB), it had to do lots of parsing, so perl was ideal language. [Well, I was not able to make driver work; anyway it would be good driver to be written in perl.] Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
aic7xxx version status for 2.4.0test ?
Hi all, am I right that the aic7xx version in latest test is 5.2.1 ? Is there a reason why this is not up to date to Doug Ledfords 5.1.31 ? TIA With best regards Michael Meding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pdev_enable_device no longer used ?
On Mon, 11 Dec 2000, Martin Mares wrote: > Hello Gerard! > > > Having to call some pdev_enable_device() to have the cache line size > > configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER, > > etc.. are configured prior to entering driver probe. > > Once upon a time, they used to be, but they no longer are. Unfortunately, there > are lots of bogus devices which must be never assigned BARs nor routed > interrupts. Hmmm... Because of broken devices you move the burden to fine ones. Let me disagree here. > You need to call pci_enable_device() after you recognize the device > as handled by your driver to get BARs and interrupts set up. Also, if your > driver uses bus mastering, it should call pci_set_master(). I donnot see in what pci_enable_device() knows better than the tailored software driver about what is to enable for the device and what must not or should not. And, btw, when pci_enable_device() was born, it just shoe-horned latency timer 64 if it was lower that 16 and I didn't want to use so obviously loose in the first place interface. > > Why should the cache line size be deferred to some call to some obscure > > mismaned thing ? > > See above. I'm also not joyfully jumping when I think of it, but consider > it being a tax on being compatible with the rough world of buggy PCI devices. Blacklists are there to preserve simplicity and genericity for compliant devices and it has the advantage of showing in a single place what and how these devices are broken. On the other hand, I donnot see `pci_enable_device()' in latest 2.2 kernels. It seem to beleive that the millions Linux used around the world are rather 2.2 that 2.4. All these buggy PCI devices breaking millions of Linux 2.2 kernels should make some noise. What did I miss here? > Anyway, it's still zillion times better than random drivers modifying such > configuration registers in random manner, knowing nothing about the host > bridge and other such stuff. Making driver for Linux work has been a nightmare for years, especially PCI-SCSI, due to limitations and brokenness of related kernel services. > (Side note: I'm not saying the method your driver uses was bad at the time > it was designed, I'm only saying that it's wrong wrt. the rest of the kernel > and it should be gone.) The driver is not calling pci_enable_device() but is does not change anything by default for Intel (the only one I support personnaly) if it is provided with a correct configuration. I have used it on various Intel platforms, even without SDMS BIOS and the only configuration item I have seen missing sometimes has been the offending PCI cache line size. When the driver has been tinked (not by me) in order to run on non Intel platforms, I am been provided with various ugly PCI-related hacks that I have incorporated with appropriate #ifdef(s), since I couldn't even test them. If now, the PCI stuff is claimed to be cleaned up, then _all_ the hacks have to be removed definitely. As a result, the driver will not work anymore on Sparc64, neither on PPC and I am not sure it will still work on Alpha, in my opinion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx version status for 2.4.0test ?
>Hi all, > >am I right that the aic7xx version in latest test is 5.2.1 ? Is there a >reason why this is not up to date to Doug Ledfords 5.1.31 ? My hope is that the Adaptec sponsored driver will eventually become the driver embedded in 2.4.X kernels. This driver is currently in Alpha (Beta to be released later today) and can be found here: http://people.FreeBSD.org/~gibbs/linux/ I know the site hosting the driver is a little, well, ironic, for a Linux driver, but there is too much red tape involved to distribute the driver from Adaptec's own site while it is still evolving, and FreeBSD.org has excellent connectivity. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
On Mon, 11 Dec 2000, Alan Cox wrote: > > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test > > for the VM doesn't make any sense since it doesn't really excercise > > the VM in any way... > > Its an interesting demo that 2.4 has some performance problems since 2.2 > is slower than 2.0 although nowdays not much. How much of that is due to the fact that the 2.4.0 scheduler interrupts processes more often than 2.2.x? Is the better interactivity worth the slight drop in performance? Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx version status for 2.4.0test ? -- ignore last post
Hi all, sorry, next time I should at least do sanity checks on my own email. Of course 5.2.1 as in latest-test is newer than 5.1.something. Just did a quick look in the source and on Dougs site and mixed the version numbers up. Stupid me! Greetings, Michael Meding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
On Mon, Dec 11, 2000 at 04:38:11PM -0200, Rik van Riel wrote: > On 11 Dec 2000, John Fremlin wrote: > > > Two points: [snipped] > > > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test > for the VM doesn't make any sense since it doesn't really excercise > the VM in any way... Also, you should view the result of some hdd benchmarks because it's possible to get different values for 2.4 and 2.2 which is major point for a fair test (maybe 2.4 and 2.2 have got different default values and so on. try hdparm -tT /dev/hd? if you have got IDE disks). -- ---[ Gábor Lénárt ][ Vivendi Telecom Hungary ]---[ [EMAIL PROTECTED] ]--- U have 8 bit computer or chip of them and it's unused or to be sold? Call me! ---[ +36 30 2270823 ]> LGB <---[ Linux/UNIX/8bit 4ever ]- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
TESTING ALIAS _ IGNORE PLEASE
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
> How much of that is due to the fact that the 2.4.0 scheduler interrupts > processes more often than 2.2.x? Is the better interactivity worth the > slight drop in performance? What better interactivity ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SMBFS does not compile on test12-pre8
Yo All! I just tried to compile SMBFS in test12-pre8. Here is the error message I get: make[3]: Entering directory `/u3/local/src/linux-2.4.0-test12-pre8/fs/smbfs' gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i686 -DSMBFS_PARANOIA -c -o sock.o sock.c sock.c: In function `smb_data_ready': sock.c:166: structure has no member named `next' make[3]: *** [sock.o] Error 1 This has worked in the recent past. This is the failing line 166 in fs/smbfs/sock.c: job->cb.next = NULL; It looks like tq_struct has been changed so that the tq_struct->next member is now tq_struct->list.next. So can we just delete line 166 in fs/smbfs/sock.c? Or do we still need to initialize next by changing line 166 to: job->cb.list.next = NULL. Ideas? RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oops in test11, test11-ac4 and test12-pre4/7 - Repost with correctdecode
As Keith Owens pointed out klogd mangled the decode, I haev run it through ksymoops and got the following decode: ksymoops 2.3.4 on i686 2.4.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test11/ (default) -m /boot/System.map (specified) Unable to handle kernel paging request at virtual address d0892597 c022a366 *pde = 0ff1c063 Oops: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010297 eax: d0892597 ebx: ecx: d0892597 edx: fffe esi: edi: c7f4a2f1 ebp: c700bee8 esp: c700be9c ds: 0018 es: 0018 ss: 0018 Process cat (pid: 1275, stackpage=c700b000) Stack: d0892597 c7f4a2e3 c7b0caa0 0006 004e c023ef73 000a c022a568 c7f4a2e3 c023ef73 c700bedc c011e5dd c7f4a2e3 c023ef62 e010 e01f d0892597 c147f614 c7f4a2e3 c147f454 0008 c011e5fe Call Trace: [] [] [] [] [] [] [] [] [] [] [>EIP; c022a366<= Trace; d0892597 Trace; c023ef73 Trace; c022a568 Trace; c023ef73 Trace; c011e5dd Trace; c023ef62 Trace; d0892597 Trace; c011e5fe Trace; c023ef5c Trace; c011e654 Trace; c023ef5c Trace; c015185c Trace; c014f32f Trace; c0132346 Trace; c010a72b Code; c022a366 <_EIP>: Code; c022a366<= 0: 80 38 00 cmpb $0x0,(%eax) <= Code; c022a369 3: 74 07 je c <_EIP+0xc> c022a372 5: 40inc%eax Code; c022a36c 6: 4adec%edx Code; c022a36d 7: 83 fa ff cmp$0x,%edx Code; c022a370 a: 75 f4 jne0 <_EIP> Code; c022a372 c: 29 c8 sub%ecx,%eax Code; c022a374 e: 89 c6 mov%eax,%esi Code; c022a376 10: 8b 44 24 1c mov0x1c(%esp,1),%eax Also this is the relivent part of /proc/ioports before installing the modules: 0cf8-0cff: PCI conf1 4000-403f: Intel Corporation 82371AB PIIX4 ACPI 5000-501f: Intel Corporation 82371AB PIIX4 ACPI c000-cfff: PCI Bus #01 d000-d01f: Intel Corporation 82371AB PIIX4 USB d000-d01f : usb-uhci d400-d47f: Digital Equipment Corporation DECchip 21142/43 d400-d47f : eth0 d800-d81f: Creative Labs SB Live! EMU1 d800-d81f : EMU10K1 dc00-dc07: Creative Labs SB Live! e000-e07f: American Megatrends Inc. MegaRAID f000-f00f: Intel Corporation 82371AB PIIX4 IDE f000-f007 : ide0 f008-f00f : ide1 -- Tim Fletcher - Network manager .~. /V\ L I N U X [EMAIL PROTECTED]// \\ >Don't fear the penguin< [EMAIL PROTECTED] /( )\ irc: Night-Shade on quakenet ^^-^^ "A computer lets you make more mistakes faster than any invention in human history - with the possible exceptions of handguns and tequila." -Mitch Ratliffe, Technology Review April, 1992 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ANNOUNCE: Linux Kernel ORB: kORBit
Ben Ford wrote: > Why would you *ever* want to write a device driver in perl??? Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot S20 runs in userspace. Seems a safer place to do things. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch for stackguard compiler and 2.2.18
Here's an update for my patch to enable the just released 2.2.18 kernel to compile with any of the different versions of the StackGuard compiler. If anyone has any problems with it, please let me know, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg diff -Naur -X /home/greg/linux/dontdiff linux-2.2.18/Makefile linux-2.2.18-greg/Makefile --- linux-2.2.18/Makefile Sun Dec 10 16:49:41 2000 +++ linux-2.2.18-greg/Makefile Mon Dec 11 14:17:12 2000 @@ -97,6 +97,12 @@ CFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer +# if we have a StackGuard compiler, then we need to turn off the canary death handler +stuff +CFLAGS += $(shell if $(CC) -fno-canary-all-functions -S -o /dev/null -xc +/dev/null >/dev/null 2>&1; then echo "-fno-canary-all-functions"; fi) +HOSTCFLAGS += $(shell if $(CC) -fno-canary-all-functions -S -o /dev/null -xc +/dev/null >/dev/null 2>&1; then echo "-fno-canary-all-functions"; fi) +CFLAGS += $(shell if $(CC) -mno-terminator-canary -S -o /dev/null -xc +/dev/null >/dev/null 2>&1; then echo "-mno-terminator-canary"; fi) +HOSTCFLAGS += $(shell if $(CC) -mno-terminator-canary -S -o /dev/null -xc +/dev/null >/dev/null 2>&1; then echo "-mno-terminator-canary"; fi) + # use '-fno-strict-aliasing', but only if the compiler can take it CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi) diff -Naur -X /home/greg/linux/dontdiff linux-2.2.18/arch/i386/boot/compressed/Makefile linux-2.2.18-greg/arch/i386/boot/compressed/Makefile --- linux-2.2.18/arch/i386/boot/compressed/Makefile Tue Jan 4 10:12:11 2000 +++ linux-2.2.18-greg/arch/i386/boot/compressed/MakefileMon Dec 11 14:17:12 +2000 @@ -10,6 +10,11 @@ OBJECTS = $(HEAD) misc.o CFLAGS = -O2 -DSTDC_HEADERS + +# if we have a StackGuard compiler, then we need to turn off the canary death handler +stuff +CFLAGS += $(shell if $(CC) -fno-canary-all-functions -S -o /dev/null -xc /dev/null +>/dev/null 2>&1; then echo "-fno-canary-all-functions"; fi) +CFLAGS += $(shell if $(CC) -mno-terminator-canary -S -o /dev/null -xc /dev/null +>/dev/null 2>&1; then echo "-mno-terminator-canary"; fi) + ZLDFLAGS = -e startup_32 #
Re: pdev_enable_device no longer used ?
Date: Mon, 11 Dec 2000 22:30:59 +0100 (CET) From: Gérard Roudier <[EMAIL PROTECTED]> On Mon, 11 Dec 2000, David S. Miller wrote: > Really, in 2.4.x sparc64 requires PCI config space hackery no longer. Really? I was thinking about the pcivtophys() alias bus_dvma_to_mem() hackery used to retrieve the actual BAR address from the so-called pcidev bar cookies. Really :-) This conversation was about drivers making modifications to PCI config space areas which are being argued to be only modified by arch-specific PCI support layers. That is the context in which I made my statements. Interpreting physical BAR values is another issue altogether. Kernel wide interfaces for this may be easily added to include/asm/pci.h infrastructure, please just choose some sane name for it and I will compose a patch ok? :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.0-test12pre8/include/linux/module.h breaks sysklogd compilation
linux-2.4.0test12pre8/include/linux/module.h contains some kernel-specific declarations that now reference struct list_head, which which is only defined when __KERNEL__ is set. This causes sysklogd and probably any other user level program that needs to include to fail to compile. The following patch brackets the (unused) offending declarations in #ifdef __KERNEL__...#endif. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." Index: linux/include/linux/module.h === RCS file: /usr/src.repository/repository/linux/include/linux/module.h,v retrieving revision 1.2 diff -u -r1.2 module.h --- linux/include/linux/module.h2000/12/04 11:57:16 1.2 +++ linux/include/linux/module.h2000/12/11 22:54:20 @@ -168,6 +168,7 @@ * Keith Owens <[EMAIL PROTECTED]> 28 Oct 2000. */ +#ifdef __KERNEL__ #define HAVE_INTER_MODULE extern void inter_module_register(const char *, struct module *, const void *); extern void inter_module_unregister(const char *); @@ -183,6 +184,7 @@ }; extern int try_inc_mod_count(struct module *mod); +#endif #if defined(MODULE) && !defined(__GENKSYMS__)
Re: SysRq behavior
> Hi! > > > I don't remember having the same problem months (6?) ago when > > I built my first Kernel with this enabled (well, maybe I never > > touched the key). > > > > When built into the Kernel, by only pressing the > > PrintScreen/SysRq the current application is terminated (tested > > on a console and GNU screen). Is this just me or I should > > expect it? > > Probably bug. Happens for me, too, and it is pretty nasty. Just played with this bug. It doesn't kill a login shell but does any app running on it. I just went looking for where "Quit" is printed out. When I press SysRq Quit is printed on the command line. Any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UP 2.2.18 makes kernels 3% faster than UP 2.4.0-test12
Aaron Tiensivu wrote: >Rerun the 2.4.0 with kgcc to be fair. :) John Fremlin wrote: >Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1 >(according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with >egcs for a fairer comparison. (2) The new VM was a performance Ok, several people have said that kgcc makes a slightly better (faster) kernel than gcc. Here are some more results. 1 2 3 ave. 453 456 455 454.7 make bzImage for 2.4.0t12p7 running 2.4.0t12p7kgcc compare this to my previous test using test12-pre7 compiled with gcc: 460 458 454 457.3 make bzImage for 2.4.0t12p7 running 2.4.0t12p7gcc 2.4.0t12p7kgcc is shorthand for 2.4.0-test12-pre7k made with kgcc. 2.4.0t12p7gcc is shorthand for 2.4.0-test12-pre7 made with gcc. kgcc does indeed make a slightly faster (0.5%) kernel, but I think we're getting into the pregnant or dimpled chad thing at this point. To create a kgcc test12-pre7, I modified line 18 and 29 of the top level Makefile to be =kgcc. Of course, I then restored the Makefile to original, since I'm not testing how fast gcc vs kgcc compiles a bunch of code. I modified EXTRAVERSION to be -test12k so I could double check with uname -r to make sure I booted the correct kernel. Kgcc made a somewhat larger kernel than gcc. The same .config file was used for both kernels. 829034 Dec 7 20:46 vmlinuz-2.4.0-test12-pre7 854863 Dec 11 14:12 vmlinuz-2.4.0-test12-pre7k I have a SMP (dual P-III 733Mhz) machine at work, but it will be unavailable for testing for a few more days. I suspect that 2.4.0-test12 will do better than 2.2.18 with 2 CPUs. I'll know in a few days. Building kernels is something we do so frequently and this test is so easy to reproduce is why I performed it in the first place. I think it may be as good a test of real performance as some of the more formal benchmarks. Comments anyone? Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: INIT_LIST_HEAD marco audit
"Mohammad A. Haque" wrote:
>
> Thinko.
>
> Question is... Adam Richter posted a patch for i2o_lan.c that does
> this...
>
> static struct tq_struct i2o_post_buckets_task = {
> list: LIST_HEAD_INIT(i2o_post_buckets_task.list),
> sync: 0,
> routine: (void (*)(void *))i2o_lan_receive_post,
> data: (void *) 0
> };
>
Will someone plze compile, test, use and submit this?
--- linux-2.4.0-test12-pre7/include/linux/tqueue.h Mon Dec 11 13:21:04 2000
+++ linux/include/linux/tqueue.hTue Dec 12 10:03:51 2000
@@ -47,6 +47,16 @@
#define DECLARE_TASK_QUEUE(q) LIST_HEAD(q)
#define TQ_ACTIVE(q) (!list_empty(&q))
+#define INIT_TQ_STRUCT(routine, data) \
+ { list: LIST_HEAD_INIT(*(struct list_head *)0), \
+ sync: 0,\
+ routine: (routine), \
+ data: (data), \
+ }
+
+#define DECLARE_TQ_STRUCT(name, routine, data) \
+ struct tq_struct name = INIT_TQ_STRUCT(routine, data)
+
extern task_queue tq_timer, tq_immediate, tq_disk;
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
