* Re: lk maintainers
From: Denis Vlasenko @ 2002-12-18 10:49 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212171118520.8420-100000@montezuma.mastecende.com>
On 17 December 2002 21:55, Zwane Mwaikambo wrote:
> On Tue, 17 Dec 2002, Denis Vlasenko wrote:
> > Martin Dalecki <martin@dalecki.de> [11 mar 2002]
> > IDE subsystem maintainer for 2.5
> > (mail Vojtech Pavlik <vojtech@suse.cz> too)
>
> Should this entry still be there?
It was true as of 11 March 2002 ;)
I imagine Martin reading this one day and think
"whee, they did not erase me from the history...".
He would be pleased.
> > Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
> > Send kernel configuration bug reports and suggestions to me.
> > Also I'll be more than happy to accept help enties for kernel
> > config options (Configure.help).
>
> Can't say i've seen this fellow in a while either.
If 'lk maintainers' will get excessively long, I'll start pruning.
Do you think I should do it now?
--
vda
^ permalink raw reply
* Re: converting cap_set_pg() to for_each_task_pid()
From: Greg KH @ 2002-12-18 6:05 UTC (permalink / raw)
To: William Lee Irwin III, chris, linux-kernel
In-Reply-To: <20021218055742.GE12812@holomorphy.com>
On Tue, Dec 17, 2002 at 09:57:42PM -0800, William Lee Irwin III wrote:
> I have a pending patch that converts cap_set_pg() to the
> for_each_task_pid() API. Could you review this, and if it
> pass, include it in your tree?
This is functionally the same, right?
And if so, why do the change, is this now faster somehow?
thanks,
greg k-h
^ permalink raw reply
* about mangling skb content
From: Haitao Yu @ 2002-12-18 6:10 UTC (permalink / raw)
To: netfilter-devel
hi,
Is there a function to mangle the content in skb, no matter it's tcp or udp packet? Just like ip_nat_mangle_tcp_packet() function.
Haitao Yu
yuht@th-dascom.com.cn
2002-12-18
^ permalink raw reply
* Re: converting cap_set_pg() to for_each_task_pid()
From: William Lee Irwin III @ 2002-12-18 6:17 UTC (permalink / raw)
To: Greg KH; +Cc: chris, linux-kernel
In-Reply-To: <20021218060551.GM28629@kroah.com>
On Tue, Dec 17, 2002 at 09:57:42PM -0800, William Lee Irwin III wrote:
>> I have a pending patch that converts cap_set_pg() to the
>> for_each_task_pid() API. Could you review this, and if it
>> pass, include it in your tree?
On Tue, Dec 17, 2002 at 10:05:51PM -0800, Greg KH wrote:
> This is functionally the same, right?
> And if so, why do the change, is this now faster somehow?
It is functionally equivalent. The motivation is not so much
performance as API conversion. I am personally taking it upon
myself to deprecate for_each_process() and do_each_thread() and
update the mergeably correctible callers. The deprecation motives
are both efficiency and correctness related.
It should improve performance in whatever sense performance is
interesting from the point of view of this function; however,
it is not motivated by that fact (and performance is not of interest
with respect to most security functions). It is API conversion.
Thanks,
Bill
^ permalink raw reply
* Show de Lançamento CD Fator Cinco
From: Rock shows Produções Artísticas @ 2002-12-18 6:13 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/html, Size: 1033 bytes --]
^ permalink raw reply
* Re: Printer error (errata)
From: Ray Olszewski @ 2002-12-18 6:15 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <3DFFEF39.10801@myfreei.com>
You did not provide some of the information I asked for (namely, the
contents of /etc/resolv.conf), but from what you did provide, the likely
source of the lprm problem is an inconsistency between your lpr setup and
/etc/hosts . As you report below, your /etc/hosts file only identifies the
machine as localhost.localdomain and not also as just localhost.
Consequently, the resolver cannot associate localhost with your machine, as
is illustrated by the ping failure you also report.
Probably you can fix the lprm problem by editing the entry (yeah, I know it
says "Do not remove", but this is editing, not removing) so it reads:
127.0.0.1 localhost.localdomain localhost
Do that and see if lprm now works. If not, tell us what the problem now
loks like.
As to the underlying problem ... by "Additional attempts to print", do you
mean trying to print different files? Preferably something nice and easy,
like a short text file (/etc/hosts itself will do for a test)? Does "lpq"
show anything significant? If you power-cycle the printer, does it now
start to print? DId the printer successfully print other files prior to
failing with the final page of the MapQuest one?
At 10:44 PM 12/17/02 -0500, Bill Pleasants wrote:
[...]
>>More immediately, how does your system do name-to-address resolution?
>>Does it rely on /etc/hosts? If so, what are the contents of that file? Or
>>does it use a nameserver? If so, is it accessable? And what are the
>>contents of the /etc/resolv.conf file?
>
>I have some notion of what name-to-address resolution is for the internet
>but not what it is for the Linux OS. /etc/hosts contains:
> "# Do not remove the following line, or various programs
> # that require network functionality will fail.
> 127.0.0.1 localhost.localdomain
>
>>
>>Does the message really say "local host" rather than "localhost"? What
>>result do you get if (from the command line) you try "ping localhost"?
>
>This is cut and paste:
> "[bill@localhost bill]$ lprm
> Get_local_host: 'localhost' IP address not available!"
>
> "[bill@localhost bill]$ ping localhost
> ping: unknown host localhost"
[...]
>>Finally, as to your immediate problem ... if the third page of a epecific
>>document continues to fail to print, while other docs print fine (do
>>they? you haven't said), i'd suspect something odd about the specific
>>document. Generically, you need to investigate how general the printing
>>problem is before we can tackle it systematically.
>
>I did not retain the file I first tried to print. Additional attempts to
>print have produced no response from the printer. Thank you for your
>offer to help.
[...]
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: How do I see all my partitions?
From: Ray Olszewski @ 2002-12-18 6:21 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <5.1.0.14.0.20021217222210.00b5fdd8@mail.comcast.net>
At 10:23 PM 12/17/02 -0500, Chris wrote:
>Hi, I'm a new Red Hat user and want to mount
>my winxp partition. How do I display all the
>partitions, Win/Dos/Linux, in one place so I can
>give mount the correct partition name?
To look at all the partitions on one physical disk, you use "fdisk" pointed
to the physical device for the drive. or example, if your drive is the IDE
primary master, use "fdisk /dev/hda". Once in fdisk, choose "p" to "print"
(actually, to display onscreen) the list of partitions and their associated
device names. Then "q" to quit without saving. You'll need to be root to
run fdisk.
If you have several hard disks, you need to do each separately, following
this pattern
IDE primary master /dev/hda
IDE primary slave /dev/hdb
IDE secondary master /dev/hdc
IDE secondary slave /dev/hdd
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* 351785
From: Haitao Yu @ 2002-12-18 6:24 UTC (permalink / raw)
To: netfilter-devel
hi,
Is there a function to mangle the content in skb, no matter it's tcp or udp packet? Just like ip_nat_mangle_tcp_packet() function.
Haitao Yu
yuht@th-dascom.com.cn
2002-12-18
^ permalink raw reply
* amd flash problem
From: Pichai Raghavan @ 2002-12-18 6:56 UTC (permalink / raw)
To: linux-mtd
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi All,
I am using the 2.4.2 MTD driver code on my board that has AMD
flash. I am noticing a bug in the write code. AMD flash driver
makes use of unlock bypass mode for doing bulk write; when
issuing
the start and end of the unlock bypass commands;it does not
check
if the flash state is READY.(function cfi_amdstd_write() in
cfi_cmdset_0002.c) In the meanwhile if the flash driver is doing
an erase or write in the context of another process and has got
scheduled out, then the flash gets into a unknown state.
This seems to be causing a problem when write to multiple
partitions are written. Has this problem been fixed in later
kernels? (Had a glance at 2.4.17 code and there also the same
code
is there)
Thanks
Raghav
[-- Attachment #2: Type: message/rfc822, Size: 2163 bytes --]
From: Mail Delivery System <Mailer-Daemon@pentafluge.infradead.org>
To: ragh_avan@rediffmail.com
Subject: Mail delivery failed: returning message to sender
Message-ID: <E18NvQO-0003sx-00@pentafluge.infradead.org>
This message was created automatically by mail delivery software (Exim).
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
lists-mtd@lists.infradead.org
unknown local-part "lists-mtd" in domain "lists.infradead.org"
------ This is a copy of the message, including all the headers. ------
Return-path: <ragh_avan@rediffmail.com>
Received: from webmail31.rediffmail.com ([202.54.124.130] helo=rediffmail.com)
by pentafluge.infradead.org with smtp (Exim 3.22 #1 (Red Hat Linux))
id 18NvQO-0003sv-00
for <lists-mtd@lists.infradead.org>; Mon, 16 Dec 2002 13:36:48 +0000
Received: (qmail 2799 invoked by uid 510); 16 Dec 2002 14:06:31 -0000
Date: 16 Dec 2002 14:06:31 -0000
Message-ID: <20021216140631.2798.qmail@webmail31.rediffmail.com>
Received: from unknown (164.164.83.140) by rediffmail.com via HTTP; 16 dec 2002 14:06:31 -0000
MIME-Version: 1.0
From: "Pichai Raghavan" <ragh_avan@rediffmail.com>
Reply-To: "Pichai Raghavan" <ragh_avan@rediffmail.com>
To: lists-mtd@lists.infradead.org
Subject: AMD CFI driver problem
Content-type: text/plain;
format=flowed
Content-Disposition: inline
Hi All,
I am using the 2.4.2 MTD driver code on my board that has AMD
flash. I am noticing a bug in the write code. AMD flash driver
makes use of unlock bypass mode for doing bulk write; when issuing
the start and end of the unlock bypass commands;it does not check
if the flash state is READY.(function cfi_amdstd_write() in
cfi_cmdset_0002.c) In the meanwhile if the flash driver is doing
an erase or write in the context of another process and has got
scheduled out, then the flash gets into a unknown state.
This seems to be causing a problem when write to multiple
partitions are written. Has this problem been fixed in later
kernels? (Had a glance at 2.4.17 code and there also the same code
is there)
Thanks
Raghav
^ permalink raw reply
* Re: [ANNOUNCE] Intel PRO/100 software developer manual released
From: Greg KH @ 2002-12-18 6:34 UTC (permalink / raw)
To: Feldman, Scott; +Cc: linux-kernel, netdev, LOSTeam
In-Reply-To: <288F9BF66CD9D5118DF400508B68C44604758F6C@orsmsx113.jf.intel.com>
On Tue, Dec 17, 2002 at 02:03:50PM -0800, Feldman, Scott wrote:
>
> Available at https://sourceforge.net/projects/e1000.
Yeah! Thank you for doing this, I know it must not have been an easy
thing to accomplish. Hopefully, Linux will be better off because of it.
thanks,
greg k-h
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 6:38 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212172043540.1749-100000@home.transmeta.com>
On Tue, 17 Dec 2002, Linus Torvalds wrote:
>
> Which is ok for a regular fast system call (ebp will get restored
> immediately), but it is NOT ok for the system call restart case, since in
> that case we want %ebp to contain the old stack pointer, not the sixth
> argument.
I came up with an absolutely wonderfully _disgusting_ solution for this.
The thing to realize on how to solve this is that since "sysenter" loses
track of EIP, there's really no real reason to try to return directly
after the "sysenter" instruction anyway. The return point is really
totally arbitrary, after all.
Now, couple this with the fact that system call restarting will always
just subtract two from the "return point" aka saved EIP value (that's the
size of an "int 0x80" instruction), and what you can do is to make the
kernel point the sysexit return point not at just past the "sysenter", but
instead make it point to just past a totally unrelated 2-byte jump
instruction.
With that in mind, I made the sysentry trampoline look like this:
static const char sysent[] = {
0x51, /* push %ecx */
0x52, /* push %edx */
0x55, /* push %ebp */
0x89, 0xe5, /* movl %esp,%ebp */
0x0f, 0x34, /* sysenter */
/* System call restart point is here! (SYSENTER_RETURN - 2) */
0xeb, 0xfa, /* jmp to "movl %esp,%ebp" */
/* System call normal return point is here! (SYSENTER_RETURN in entry.S) */
0x5d, /* pop %ebp */
0x5a, /* pop %edx */
0x59, /* pop %ecx */
0xc3 /* ret */
};
which does the right thing for a "restarted" system call (ie when it
restarts, it won't re-do just the sysenter instruction, it will really
restart at the backwards jump, and thus re-start the "movl %esp,%ebp"
too).
Which means that now the kernel can happily trash %ebp as part of the
sixth argument setup, since system call restarting will re-initialize it
to point to the user-level stack that we need in %ebp because otherwise it
gets totally lost.
I'm a disgusting pig, and proud of it to boot.
Linus
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: jsoe0708 @ 2002-12-18 6:30 UTC (permalink / raw)
To: grundler, Ryan Bradetich; +Cc: Ed Schaller, parisc-linux
In-Reply-To: <20021217181901.GA2254@dsl2.external.hp.com>
Hi Grant,
>
>On Tue, Dec 17, 2002 at 04:14:10PM +0100, jsoe0708@tiscali.be wrote:
>> >I will try to revert tulip driver and advise you.
>> Well I find some minutes to do this reverse and it works.
>> Still have to find the bug ?
>
>Unfortunately yes.
>But since the diff is small, it's alot easier.
>
>I'm most suspicious about the added checks for length field in eeprom.
>But I'll review the diff again and tinker with it today or tomorrow.
>I added that thinking that code only gets executed when there is no
>phy table (eg built-in). But the add-on cards do have a phy table.
>
(well it seems I do mistake when sent following info)
[also because diff is small]
In eeprom.c I also suspect:
line 193: if (ee_data[27] =3D=3D 0 || ee_data[ee_data[27]] =3D=3D 0) {
which I only reverse into:
if (ee_data[27] =3D=3D 0) {
and it works. Unforunately I do not have enough doc to actulay fix the pb=
.
May be Ryan could still help us?
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* vm86 IRQ bugfix
From: William Lee Irwin III @ 2002-12-18 6:39 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
vm86 does broken tasklist scanning for matching task_struct pointers,
which is oopsable. This registers a notifier for it to GC vm86 IRQ's in
release_thread() and removes the broken tasklist scanning.
This bugfix is in 2.4.x and has been in 2.5.x-dj for an extended period
of time.
arch/i386/kernel/process.c | 3 +++
arch/i386/kernel/vm86.c | 30 ------------------------------
include/asm-i386/irq.h | 1 +
3 files changed, 4 insertions(+), 30 deletions(-)
diff -urpN wli-2.5.51-bk1-5/arch/i386/kernel/process.c wli-2.5.51-bk1-6/arch/i386/kernel/process.c
--- wli-2.5.51-bk1-5/arch/i386/kernel/process.c 2002-12-09 18:45:39.000000000 -0800
+++ wli-2.5.51-bk1-6/arch/i386/kernel/process.c 2002-12-11 18:33:21.000000000 -0800
@@ -44,6 +44,7 @@
#include <asm/ldt.h>
#include <asm/processor.h>
#include <asm/i387.h>
+#include <asm/irq.h>
#include <asm/desc.h>
#ifdef CONFIG_MATH_EMULATION
#include <asm/math_emu.h>
@@ -269,6 +270,8 @@ void release_thread(struct task_struct *
BUG();
}
}
+
+ release_x86_irqs(dead_task);
}
/*
diff -urpN wli-2.5.51-bk1-5/arch/i386/kernel/vm86.c wli-2.5.51-bk1-6/arch/i386/kernel/vm86.c
--- wli-2.5.51-bk1-5/arch/i386/kernel/vm86.c 2002-12-09 18:45:43.000000000 -0800
+++ wli-2.5.51-bk1-6/arch/i386/kernel/vm86.c 2002-12-11 18:33:21.000000000 -0800
@@ -708,23 +708,6 @@ static inline void free_vm86_irq(int irq
spin_unlock_irqrestore(&irqbits_lock, flags);
}
-static inline int task_valid(struct task_struct *tsk)
-{
- struct task_struct *g, *p;
- int ret = 0;
-
- read_lock(&tasklist_lock);
- do_each_thread(g, p)
- if ((p == tsk) && (p->sig)) {
- ret = 1;
- goto out;
- }
- while_each_thread(g, p);
-out:
- read_unlock(&tasklist_lock);
- return ret;
-}
-
void release_x86_irqs(struct task_struct *task)
{
int i;
@@ -733,17 +716,6 @@ void release_x86_irqs(struct task_struct
free_vm86_irq(i);
}
-static inline void handle_irq_zombies(void)
-{
- int i;
- for (i=3; i<16; i++) {
- if (vm86_irqs[i].tsk) {
- if (task_valid(vm86_irqs[i].tsk)) continue;
- free_vm86_irq(i);
- }
- }
-}
-
static inline int get_and_reset_irq(int irqnumber)
{
int bit;
@@ -772,7 +744,6 @@ static int do_vm86_irq_handling(int subf
case VM86_REQUEST_IRQ: {
int sig = irqnumber >> 8;
int irq = irqnumber & 255;
- handle_irq_zombies();
if (!capable(CAP_SYS_ADMIN)) return -EPERM;
if (!((1 << sig) & ALLOWED_SIGS)) return -EPERM;
if ( (irq<3) || (irq>15) ) return -EPERM;
@@ -784,7 +755,6 @@ static int do_vm86_irq_handling(int subf
return irq;
}
case VM86_FREE_IRQ: {
- handle_irq_zombies();
if ( (irqnumber<3) || (irqnumber>15) ) return -EPERM;
if (!vm86_irqs[irqnumber].tsk) return 0;
if (vm86_irqs[irqnumber].tsk != current) return -EPERM;
diff -urpN wli-2.5.51-bk1-5/include/asm-i386/irq.h wli-2.5.51-bk1-6/include/asm-i386/irq.h
--- wli-2.5.51-bk1-5/include/asm-i386/irq.h 2002-12-09 18:45:44.000000000 -0800
+++ wli-2.5.51-bk1-6/include/asm-i386/irq.h 2002-12-11 18:33:21.000000000 -0800
@@ -23,6 +23,7 @@ static __inline__ int irq_cannonicalize(
extern void disable_irq(unsigned int);
extern void disable_irq_nosync(unsigned int);
extern void enable_irq(unsigned int);
+extern void release_x86_irqs(struct task_struct *);
#ifdef CONFIG_X86_LOCAL_APIC
#define ARCH_HAS_NMI_WATCHDOG /* See include/linux/nmi.h */
^ permalink raw reply
* bk-current __secpath_destroy link error
From: john slee @ 2002-12-18 6:51 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]
some lines obviously wrapped. .config attached.
make -f scripts/Makefile.build obj=init
Generating include/linux/compile.h (updated)
gcc -Wp,-MD,init/.version.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -malign-functions=4
-Iarch/i386/mach-generic -fomit-frame-pointer -nostdinc -iwithprefix
include -DKBUILD_BASENAME=version -DKBUILD_MODNAME=version -c -o
init/version.o init/version.c
ld -m elf_i386 -r -o init/built-in.o init/main.o init/version.o
init/do_mounts.o init/initramfs.o
ld -m elf_i386 -e stext -T arch/i386/vmlinux.lds.s
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/built-in.o
--start-group usr/built-in.o arch/i386/kernel/built-in.o
arch/i386/mm/built-in.o arch/i386/mach-generic/built-in.o
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
security/built-in.o crypto/built-in.o lib/lib.a arch/i386/lib/lib.a
drivers/built-in.o sound/built-in.o arch/i386/pci/built-in.o
net/built-in.o --end-group -o .tmp_vmlinux1
net/built-in.o: In function `__kfree_skb':
net/built-in.o(.text+0x3818): undefined reference to `__secpath_destroy'
make: *** [.tmp_vmlinux1] Error 1
--
toyota power: http://indigoid.net/
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 13071 bytes --]
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_SWAP=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
#
# General setup
#
CONFIG_NET=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set
#
# ACPI Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_HT_ONLY is not set
CONFIG_ACPI_BOOT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_SCx200 is not set
CONFIG_PCI_NAMES=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
#
# PCI Hotplug Support
#
#
# Executable file formats
#
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
# CONFIG_PARPORT is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_LBD is not set
#
# ATA/ATAPI/MFM/RLL device support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
# CONFIG_IDEDMA_PCI_AUTO is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NFORCE is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_BLK_DEV_IDE_MODES=y
#
# SCSI device support
#
# CONFIG_SCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
# CONFIG_INET is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_XFRM_USER is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC is not set
# CONFIG_DECNET is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices (depends on LLC=y)
#
# CONFIG_NET_FC is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
# CONFIG_SERIO is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_INPUT_MOUSE=y
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
#
# Non-8250 serial port support
#
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_AMD_RNG is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_AGP3 is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
# CONFIG_HPFS_FS is not set
# CONFIG_PROC_FS is not set
# CONFIG_DEVPTS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_XFS_FS is not set
#
# Network File Systems
#
# CONFIG_EXPORTFS is not set
CONFIG_FS_MBCACHE=y
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not set
#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
#
# USB Host Controller Drivers
#
# CONFIG_USB_EHCI_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_UHCI_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
#
# SCSI support is needed for USB Storage
#
#
# USB Human Interface Devices (HID)
#
# CONFIG_USB_HID is not set
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set
#
# USB Imaging devices
#
# CONFIG_USB_SCANNER is not set
#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
#
# Video4Linux support is needed for USB Multimedia device support
#
#
# USB Network adaptors
#
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_USBNET is not set
#
# USB port drivers
#
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_TIGL is not set
# CONFIG_USB_LCD is not set
#
# Bluetooth support
#
# CONFIG_BT is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_KALLSYMS=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
#
# Security options
#
CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
#
# Cryptographic options
#
# CONFIG_CRYPTO is not set
#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_X86_BIOS_REBOOT=y
^ permalink raw reply
* Re: bk-current __secpath_destroy link error
From: john slee @ 2002-12-18 6:55 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021218065154.GA18508@higherplane.net>
On Wed, Dec 18, 2002 at 05:51:54PM +1100, john slee wrote:
> some lines obviously wrapped. .config attached.
apologies, seems i didn't search archives enough before posting :-(
lesson learned,
j.
--
toyota power: http://indigoid.net/
^ permalink raw reply
* Re: lk maintainers
From: Zwane Mwaikambo @ 2002-12-18 7:29 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: linux-kernel
In-Reply-To: <200212180600.gBI60js21347@Port.imtp.ilyichevsk.odessa.ua>
On Wed, 18 Dec 2002, Denis Vlasenko wrote:
> > > Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
> > > Send kernel configuration bug reports and suggestions to me.
> > > Also I'll be more than happy to accept help enties for kernel
> > > config options (Configure.help).
> >
> > Can't say i've seen this fellow in a while either.
>
> If 'lk maintainers' will get excessively long, I'll start pruning.
> Do you think I should do it now?
If it's supposed to be current information and to be used by bug
reporters, then by all means, chop away ;)
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: PLEASE HELP ME!!
From: Dirk Mueller @ 2002-12-18 7:21 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <3DFFD0A7.2090803@ciudad.com.ar>
On Mit, 18 Dez 2002, lrodrigo wrote:
> How i can solve this problem??
>
> PLEASE, HELP ME.......
There is no problem, its debug output. Use a newer reiserfsck when you're
annoyed by it.
--
Dirk (received 170 mails today)
^ permalink raw reply
* Re: lk maintainers
From: Andre Hedrick @ 2002-12-18 7:29 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: Zwane Mwaikambo, linux-kernel
In-Reply-To: <200212180600.gBI60js21347@Port.imtp.ilyichevsk.odessa.ua>
On Wed, 18 Dec 2002, Denis Vlasenko wrote:
> On 17 December 2002 21:55, Zwane Mwaikambo wrote:
> > On Tue, 17 Dec 2002, Denis Vlasenko wrote:
> > > Martin Dalecki <martin@dalecki.de> [11 mar 2002]
> > > IDE subsystem maintainer for 2.5
> > > (mail Vojtech Pavlik <vojtech@suse.cz> too)
> >
> > Should this entry still be there?
>
> It was true as of 11 March 2002 ;)
> I imagine Martin reading this one day and think
> "whee, they did not erase me from the history...".
> He would be pleased.
Please leave as a reminder to me and anyone else about what can happen if
civility (sp) is lost.
He had good intentions, and was as bull-headed as me.
What one admires and hates in the same thought.
I wish I had time to look at what he did, and invite him back to express
his ideas again for the next round in 2.7. It would be foolish to not
consider some of the changes and ideas as positive.
The difference is the knowledge base, and having proven in the past it can
be done, but the rules are freaking ugly.
And they just got worse!
One of the issues we will now be faced once the chipsets are fully modular
is the issue of OEMS refusing to continue to open spec their hardware.
This is the gamble Linux took, lets hope I and others managed to make a
big enough cannon ball splash to scare them into not going down that path.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
Martin D. Come on back the water is warm!
^ permalink raw reply
* Re: Domain transition -- enabling user_r in eklogin
From: Russell Coker @ 2002-12-18 7:45 UTC (permalink / raw)
To: Brian May; +Cc: SELinux
In-Reply-To: <20021218012830.GC31462@snoopy.apana.org.au>
On Wed, 18 Dec 2002 02:28, Brian May wrote:
> On Tue, Dec 17, 2002 at 07:28:56PM -0500, forrest whitcher wrote:
> > I'll look into adding kerberos auth to newrole(1) to save retypings of
> > password next.
>
> Interesting idea, it would be good not to have to type in your password
> each time.
Which is something you could easily achieve through PAM configuration if that
is what you desire, without any kerberos issues etc.
> However, I have to wonder if this is such a good idea...
>
> At the very least you would need to have a strict policy that only
> allows very trusted programs to access the ticket or to run a program
> (eg. newrole) that has access to this ticket.
As newrole can't be ptraced etc it should be safe to be trusted with the
ticket. But it doesn't make sense IMHO to be doing such things.
> If there is any weakness in this strict policy, and for instance program
> X finds it can run newrole indirectly via, say bash, and automatically
> get sysadm_r priviliges, you loose any benifit SE-Linux could provide.
No.
Programs in domains such as user_netscape_t and user_irc_t will not be allowed
to run newrole at all.
Newrole will still only allow transitions to roles that are permitted (so if a
user is not permitted sysadm_r then they still can't get it).
Daemons will still run in separate domains to protect against each other and
against regular system users.
Allowing role transitions without password loses you some of the benefits of
SE Linux, but not even most of them.
Also I think that in most situations where a user could be tricked into
running newrole then it's game-over anyway.
> Some sort of tool for analysing policy might be good here, for instance
> so you can ask questions like "Can Mozilla access the Kerberos ticket
> either directly or indirectly by loading another program first?".
I think that Trent is working on such tools. But this is a simple case that
can be addressed by grep:
grep allow.*netscape.*process.transition policy.conf
Shows that user_netscape_t can only transition to user_lpr_t (and similar
transitions for sysadm_netscape_t and httpd_admin_netscape_t).
grep allow.*_lpr_t.*process.transition policy.conf
Shows that user_lpr_t etc can't transition to any domain.
So netscape is safe in this regard.
> I am not yet sure how good SE-Linux will be at solving this type of
> problem, without duplicating a lot of domains, for instance
> a set of domains for programs with Kerberos ticket access, and
> a duplicate set for programs without Kerberos ticket access).
What exactly is "ticket access" and how does it conceptually differ from read
access to /etc/shadow? Couldn't we just treat ticket access in the same way
as access to /etc/shadow?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* mapping back to 36 bit physical
From: Claudia Salzberg @ 2002-12-18 8:07 UTC (permalink / raw)
To: linuxppc-embedded
Greetings.
How does one go about aquiring the 36-bit physical address on a 440XX if
you have the corresponding va from an ioremap (when your driver is not
the one that did the ioremap so that you don't have the pa saved)? I see
that ioremap does support 36-bit I/O mapping but _va and _pa only play
with unsigned long's. So does iopa. So do the virt_to_* 's I was able
to find. Also, does anyone have plans for incorporating memory access
hooks above 4GB address space?
Thanks,
Claudia Salzberg
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [ANNOUNCE] Intel PRO/100 software developer manual released
From: James Morris @ 2002-12-18 8:34 UTC (permalink / raw)
To: Feldman, Scott; +Cc: linux-kernel, netdev, LOSTeam
In-Reply-To: <288F9BF66CD9D5118DF400508B68C44604758F6C@orsmsx113.jf.intel.com>
On Tue, 17 Dec 2002, Feldman, Scott wrote:
> The manual is intended to support the maintenance of the e100 driver (or the
> best driver for the PRO/100 networking hardware ;-). The manual covers the
> 82557, 82558, 82559, 82550, and 82551 Ethernet controllers.
Hi Scott,
This looks great. Any chance of releasing documentation on the crypto
hardware which resides on the PRO/100 S? We're currently looking at
adding support for hardware crypto (including IPsec offload) to the
kernel, and it would be good to include the requirements and capabilities
of this card in the design process.
- James
--
James Morris
<jmorris@intercode.com.au>
^ permalink raw reply
* [BK PATCH] USB changes for 2.5.52
From: Greg KH @ 2002-12-18 8:35 UTC (permalink / raw)
To: torvalds; +Cc: linux-usb-devel, linux-kernel
Please pull from: bk://linuxusb.bkbits.net/linus-2.5
thanks,
greg k-h
drivers/usb/core/hcd.c | 5
drivers/usb/core/hub.c | 61 +++++++----
drivers/usb/core/inode.c | 5
drivers/usb/host/ehci-dbg.c | 37 ++++++-
drivers/usb/host/ehci-hcd.c | 161 +++++++++++++++----------------
drivers/usb/host/ehci-hub.c | 2
drivers/usb/host/ehci-mem.c | 5
drivers/usb/host/ehci-q.c | 189 ++++++++++++++++++-------------------
drivers/usb/host/ehci-sched.c | 26 +----
drivers/usb/host/ehci.h | 3
drivers/usb/media/ibmcam.c | 14 +-
drivers/usb/media/konicawc.c | 2
drivers/usb/media/pwc-ctrl.c | 12 +-
drivers/usb/media/pwc-if.c | 9 -
drivers/usb/media/pwc-ioctl.h | 13 ++
drivers/usb/media/pwc-uncompress.h | 4
drivers/usb/media/pwc.h | 4
drivers/usb/media/ultracam.c | 2
drivers/usb/media/usbvideo.c | 32 +++---
drivers/usb/media/usbvideo.h | 36 +++----
drivers/usb/misc/speedtouch.c | 45 ++++----
drivers/usb/misc/usblcd.c | 2
drivers/usb/net/usbnet.c | 168 +++++++++++++++++---------------
drivers/usb/serial/belkin_sa.c | 1
drivers/usb/serial/bus.c | 5
drivers/usb/serial/cyberjack.c | 1
drivers/usb/serial/generic.c | 1
drivers/usb/serial/io_tables.h | 4
drivers/usb/serial/io_ti.c | 2
drivers/usb/serial/keyspan.h | 4
drivers/usb/serial/keyspan_pda.c | 3
drivers/usb/serial/kl5kusb105.c | 1
drivers/usb/serial/mct_u232.c | 1
drivers/usb/serial/omninet.c | 1
drivers/usb/serial/usb-serial.h | 4
drivers/usb/serial/visor.c | 2
drivers/usb/serial/whiteheat.c | 4
drivers/usb/storage/transport.c | 46 ++++-----
drivers/usb/storage/usb.c | 20 ++-
39 files changed, 522 insertions(+), 415 deletions(-)
-----
ChangeSet@1.894, 2002-12-18 00:18:53-08:00, david-b@pacbell.net
[PATCH] ehci, more small fixes
- some access to urb->hcpriv and urb->status needed to be
locked using urb->lock
- paranoia: don't depend on two values being in lock-step.
drivers/usb/host/ehci-q.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
------
ChangeSet@1.893, 2002-12-18 00:12:02-08:00, greg@kroah.com
[PATCH] USB: warn users that they should not be using the usbdevfs name.
drivers/usb/core/inode.c | 5 +++++
1 files changed, 5 insertions(+)
------
ChangeSet@1.883.3.16, 2002-12-17 22:38:44-08:00, greg@kroah.com
[PATCH] USB: whiteheat: fix some gcc 3.2 warning messages
drivers/usb/serial/whiteheat.c | 2 ++
1 files changed, 2 insertions(+)
------
ChangeSet@1.883.3.15, 2002-12-17 22:22:16-08:00, david-b@pacbell.net
[PATCH] hub driver uses dev_info(), less log clutter
This patch converts most common hub diagnostics to use the
device model diagnostic macros ... not all, someone should
reduce the number of err() strings for "bogus hub" cases,
and ideally streamline some of the dozen or so "here's what's
special about this new hub" dbg() messages.
So the messages become more useful: they id the port (and
implicitly the device) involved, using a kernel-wide standard
convention. Size overhead is smaller too.
For folk running with USB debugging enabled, it also cuts
the useless chatter on connections by deleting the per-poll
success messages and a partial dup message when things change.
And it deletes a newish diagnostic on a (non-hub) unlink path.
It also makes Pete's new debounce message use the right
port number -- one-based, not zero-based.
My main issue with this patch is that it doesn't change
more messages, but it seems reasonable to merge it anyway.
drivers/usb/core/hcd.c | 5 +---
drivers/usb/core/hub.c | 61 ++++++++++++++++++++++++++++---------------------
2 files changed, 38 insertions(+), 28 deletions(-)
------
ChangeSet@1.883.3.14, 2002-12-17 21:57:17-08:00, oliver@neukum.name
[PATCH] USB: proper error return for usblcd
unknown ioctls return -ENOTTY and nothing else.
drivers/usb/misc/usblcd.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
------
ChangeSet@1.883.3.13, 2002-12-17 21:51:57-08:00, oliver@neukum.name
[PATCH] USB: fix an unlinking race in speedtouch driver
checking for -EINPROGRESS is wrong.
drivers/usb/misc/speedtouch.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
------
ChangeSet@1.883.3.12, 2002-12-17 21:51:12-08:00, oliver@neukum.name
[PATCH] USB: speedtouch: eliminate sleep_on
drivers/usb/misc/speedtouch.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletion(-)
------
ChangeSet@1.883.3.11, 2002-12-17 21:49:24-08:00, oliver@neukum.name
[PATCH] USB: clean kernel thread exit for speedtouch
this makes sure that the kernel thread is dead and gone on module unload.
- use a completion to wait for the kernel thread's death
drivers/usb/misc/speedtouch.c | 18 +++++-------------
1 files changed, 5 insertions(+), 13 deletions(-)
------
ChangeSet@1.883.3.10, 2002-12-17 20:40:12-08:00, stern@rowland.harvard.edu
[PATCH] USB: usb-storage bugfix
Don't try to dereference the interrupt endpoint if it doesn't exist.
drivers/usb/storage/usb.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
------
ChangeSet@1.883.3.9, 2002-12-16 18:13:47-08:00, greg@kroah.com
[PATCH] USB: usbserial: Add a short_name field to work better with sysfs.
This cleans up the bus/usb-serial/drivers/ directory
drivers/usb/serial/belkin_sa.c | 1 +
drivers/usb/serial/bus.c | 5 ++++-
drivers/usb/serial/cyberjack.c | 1 +
drivers/usb/serial/generic.c | 1 +
drivers/usb/serial/io_tables.h | 4 ++++
drivers/usb/serial/io_ti.c | 2 ++
drivers/usb/serial/keyspan.h | 4 ++++
drivers/usb/serial/keyspan_pda.c | 3 +++
drivers/usb/serial/kl5kusb105.c | 1 +
drivers/usb/serial/mct_u232.c | 1 +
drivers/usb/serial/omninet.c | 1 +
drivers/usb/serial/usb-serial.h | 4 ++++
drivers/usb/serial/visor.c | 2 ++
drivers/usb/serial/whiteheat.c | 2 ++
14 files changed, 31 insertions(+), 1 deletion(-)
------
ChangeSet@1.883.3.8, 2002-12-16 16:35:58-08:00, oliver@oenone.homelinux.org
[PATCH] USB: speedtouch driver memory allocation deadlock fix
drivers/usb/misc/speedtouch.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
------
ChangeSet@1.883.3.7, 2002-12-16 10:49:56-08:00, mdharm-usb@one-eyed-alien.net
[PATCH] usb-storage: fixup interpret_urb_result()
This patch fixes interpret_urb_result in two major ways:
(1) Uses a switch() instead of nested if() statements
(2) Handle -EREMOTEIO to indicate a short scatter-gather transfer
drivers/usb/storage/transport.c | 46 ++++++++++++++++++++--------------------
1 files changed, 24 insertions(+), 22 deletions(-)
------
ChangeSet@1.883.3.6, 2002-12-16 10:45:26-08:00, nemosoft@smcc.demon.nl
[PATCH] USB: PWC 8.10 for 2.5.51
Well, two patches in one... These patches will bring the PWC (Philips
Webcam) driver in both 2.4.20 and 2.5.51 up to version 8.10. Functionally,
the two branches are the same (about 70% of the code is shared), but the
differences in kernel architecture are too large to handle with a few
#ifdefs.
This patch fixes the following (this are only the differences between 8.9
and 8.10):
* Fixed ID for QuickCam Notebook pro
* Added GREALSIZE ioctl() call
* Fixed bug in case PWCX was not loaded and invalid size was set
drivers/usb/media/pwc-ctrl.c | 12 ++++++++++--
drivers/usb/media/pwc-if.c | 9 ++++-----
drivers/usb/media/pwc-ioctl.h | 13 +++++++++++--
drivers/usb/media/pwc-uncompress.h | 4 ++--
drivers/usb/media/pwc.h | 4 ++--
5 files changed, 29 insertions(+), 13 deletions(-)
------
ChangeSet@1.883.3.5, 2002-12-16 10:35:48-08:00, spse@secret.org.uk
[PATCH] 2.5.51 More typedef removal from usbvideo
This patch against 2.5.51 removes the remaining typedefs from usbvideo
typedef enum { .. } ScanState_t -> enum ScanState
typedef enum { .. } ParseState_t -> enum ParseState
typedef enum { .. } FrameState_t -> enum FrameState
typedef enum { .. } Deinterlace_t -> enum Deinterlace
typedef struct { .. } usbvideo_t -> struct usbvideo
drivers/usb/media/ibmcam.c | 14 +++++++-------
drivers/usb/media/konicawc.c | 2 +-
drivers/usb/media/ultracam.c | 2 +-
drivers/usb/media/usbvideo.c | 32 ++++++++++++++++----------------
drivers/usb/media/usbvideo.h | 36 ++++++++++++++++++------------------
5 files changed, 43 insertions(+), 43 deletions(-)
------
ChangeSet@1.883.3.4, 2002-12-16 10:31:59-08:00, david-b@pacbell.net
[PATCH] ehci misc patches
small fixes flushed by the hunt for bigger game:
- terminate td lists with dummy, not list end marker
- use alt_next only for real short control reads
- un-halt async qhs before scheduling
- deletes unused debug code, pointless assignments
- surely nobody ever sees that memleak
- terminate two related "while" loops the same way
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/host/ehci-q.c | 36 +++++++++++-------------------------
2 files changed, 12 insertions(+), 26 deletions(-)
------
ChangeSet@1.883.3.3, 2002-12-16 10:31:41-08:00, david-b@pacbell.net
[PATCH] usbnet: zaurus, oops, etc
This patch:
- Removes Pavel's Zaurus-private crc32 code; the base patch
was from Pavel.
- Addresses two issues Toby Milne reported against the Zaurus:
(a) if skbs had extra framing added (z, net1080, gl620a),
the original size (now too small) was used on tx;
(b) added FLAG_FRAMING_Z so rx packets had enough space
- Removes an oops from the driver model conversion (saved
the wrong pointer). Disconnecting wasn't healthy.
- Forward-ports some ethtool support from the 2.4 version:
PDAs are always connected, so report them that way.
- Stubs in some PXA-250 support for non-Zaurus PDAs.
This is currently commented out; so far those PDAs
only run Linux for bleeding edge developers.
- Minor cleanups.
drivers/usb/net/usbnet.c | 168 ++++++++++++++++++++++++-----------------------
1 files changed, 89 insertions(+), 79 deletions(-)
------
ChangeSet@1.883.3.2, 2002-12-16 10:31:24-08:00, david-b@pacbell.net
[PATCH] ehci-hcd (2/2): rest of tasklet remove
This is the rest of the work to remove the tasklet: the non-syntax
portions which affect work scheduling. It's not quite davem's version;
it's got locking updates, which among other things prevent a hang when
the timer kicks in.
This scheduling change is split out from the other parts in case more
problems like that unlink race (fixed in my previous patch) show up.
It doesn't fix (or help fix) any ehci bugs, but simpler code is fine.
drivers/usb/host/ehci-hcd.c | 56 +++++++++++++++++++++++-------------------
drivers/usb/host/ehci-sched.c | 2 -
drivers/usb/host/ehci.h | 3 --
3 files changed, 32 insertions(+), 29 deletions(-)
------
ChangeSet@1.883.3.1, 2002-12-16 10:31:05-08:00, david-b@pacbell.net
[PATCH] ehci-hcd (1/2): portability (2.4), tasklet,
This should be innocuous; I expect most folk won't notice anything
better (or worse) from this patch unless they're using Intel EHCI.
removing tasklet
- parts of davem's patch (passing pt_regs down)
- remove 'max_completions'
- update cleanup after hc died
- fix an urb unlink oops (null ptr) that happens more often this way
talking to hardware
- fixes for some short read issues (may still be others)
* use qtd->hw_alt_next to stop qh processing after short reads
* detect/report short reads differently
- longer reset timeout (it was excessively short, broke Intel)
other
- simpler diagnostics portability to 2.4: wrap dev_err() etc
- urb unlink wait and non-wait unlink codepaths share most code
- don't try ehci_stop() in interrupt context (bug from hcd layer)
- minor stuff, including
* some "after hc died" paths were wrong
* verbose debug messages compile again
* don't break error irq count
drivers/usb/host/ehci-dbg.c | 37 ++++++++--
drivers/usb/host/ehci-hcd.c | 103 +++++++++++++----------------
drivers/usb/host/ehci-hub.c | 2
drivers/usb/host/ehci-mem.c | 5 +
drivers/usb/host/ehci-q.c | 147 ++++++++++++++++++++++--------------------
drivers/usb/host/ehci-sched.c | 24 ++----
6 files changed, 173 insertions(+), 145 deletions(-)
------
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Kai Henningsen @ 2002-12-18 7:20 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171157050.1095-100000@home.transmeta.com>
torvalds@transmeta.com (Linus Torvalds) wrote on 17.12.02 in <Pine.LNX.4.44.0212171157050.1095-100000@home.transmeta.com>:
> On Tue, 17 Dec 2002, Richard B. Johnson wrote:
> >
> > You can call intersegment with a full pointer. I don't know how
> > expensive that is.
>
> It's so expensive as to not be worth it, it's cheaper to load a register
> or something, i eyou can do
>
> pushl $0xfffff000
> call *(%esp)
>
> faster than doing a far call.
Hmm ...
How expensive would it be to have a special virtual DSO built into ld.so
which exported this (and any other future entry points), to be linked
against like any other DSO? That way, the *actual* interface would only be
between the kernel and ld.so.
MfG Kai
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Kai Henningsen @ 2002-12-18 7:41 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171132530.1095-100000@home.transmeta.com>
torvalds@transmeta.com (Linus Torvalds) wrote on 17.12.02 in <Pine.LNX.4.44.0212171132530.1095-100000@home.transmeta.com>:
> On Tue, 17 Dec 2002, H. Peter Anvin wrote:
> >
> > Let's see... it works fine on UP and on *most* SMP, and on the ones
> > where it doesn't work you just fill in a system call into the vsyscall
> > slot. It just means that gettimeofday() needs a different vsyscall slot.
>
> The thing is, gettimeofday() isn't _that_ special. It's just not worth a
> vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
> Just because we can?
It's special enough that while programming under DOS, I had my own special
routine which just took the BIOS ticker from low memory for a lot of
things - even to decide if calling the actual time-of-day syscall was
useful or if I should expect to get the same value back as last time.
That was a *serious* performance improvement. (Of course, DOS syscalls are
S-L-O-W ...)
These days, the equivalent does call gettimeofday(). It's still probably
the most-used syscall by far. (Hmm - maybe I can get some numbers for
that? Must see if I get time today.) And *that* is why optimizing this one
call makes sense.
> This is especially true since the people who _really_ might care about
> gettimeofday() are exactly the people who wouldn't be able to use the fast
> user-space-only version.
Say what? Why wouldn't I be able to use it? Right now, I know of no SMP
installation that's even in the planning ...
> How much do you think gettimeofday() really matters on a desktop? Sure, X
Why desktop? We use the same kind of thing in the server, and it's much
more important there. Client performance is uninteresting - clients mostly
wait anyway.
> The people who really call for gettimeofday() as a performance thing seem
> to be database people who want it as a timestamp. But those are the same
Not database, but otherwise on the nail.
> people who also want NUMA machines which don't necessarily have
> synchronized clocks.
Nope, no interest in those. SMP *might* become interesting, but I don't
think we'd ever want to care about weird stuff like NUMA ... at least not
for the next five years or so.
We don't shovel nearly as much data around as the database guys.
MfG Kai
^ permalink raw reply
* Re: Am I burning my Compaq 700EA ?
From: Vittorio Ballestra @ 2002-12-18 8:41 UTC (permalink / raw)
To: Frederic.Parrenin-uJC2I/HWIrG1lNqXp+/2b1AUjnlXr6A1
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1040197383.2035.6.camel-EOLtR9nHC0w7VkuvlHBOUdBf7emC4R2pl6ge6I993lI@public.gmane.org>
Alle 08:43, mercoledì 18 dicembre 2002, hai scritto:
> Hi Vittorio,
>
>
> I am not an acpi expert, but I had a similar problem with my laptop.
>
> > Second:
> > /proc/acpi/thermal_zone is there but empty. Is it Ok ? If not someone
> > knows how to fix it ? (I'm a bit worried 'bout this).
>
> For me, it was the battery and ac_adaptatot that were empty. It came
> from a buggy implementation of acpi in the Bios : my dsdt table was
> wrong. A nice gye has of the acpi-devel list looked at my
> /proc/acpi/dsdt file, and he gave me a patch to have acpi fully working.
>
Thank you for your hint. I'll try to disassemble the DSDT table and understand
it, but it will take a long time as I don't have much spare time for it...
hope in the meanwhile I'm not going to cook my compaq... or some other good
guy will give me a hand...
> For your thermal zone, try to charge your CPU and look if the fan work
> correctly. (What is your processor ? Pentium 4 ?)
>
Fan is working (running mplayer or recompiling the kernel will make it work).
Don't know how well though ...
Throttling works (manual changing the throttling state will do, don't know if
it will change automatically).
My processor is an AMD Athlon 4 1500+
> > Third:
> > acpid is not working (I've not applied the apcpid.patch, thought it was
> > integrated ...). Is this a real problem or the only side-effect is that
> > power button will not work ?
>
> If you try to start acpid, do you have an error message ?
no, but buttons are not working. I didn't want to recompile only because I've
forgotten to apply the acpid.patch that's why I asked if it was important ...
>
> Regards.
>
> Frederic
>
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Acpi-devel mailing list
> > Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.