On Sun, Nov 19, 2000 at 07:00:41PM -0800, Dan Hollis wrote:
> On Mon, 20 Nov 2000, David Woodhouse wrote:
> > On Sun, 19 Nov 2000, Dan Hollis wrote:
> > > Writeprotect the flashbios with the motherboard jumper, and remove the
> > > cmos battery.
> > > Checkmate. :-)
> > Only if you run your kernel
On 19 Nov 2000, Gerd Knorr wrote:
> Some generic way to make module args available as kernel args too
> would be nice. Or at least some simple one-liner I could put next to
> the MODULE_PARM() macro...
Well, I did a patch that does automagically convert MODULE_PARAM
stuff to __setup() functions
David Ford <[EMAIL PROTECTED]> wrote:
>> Please turn this off.
>>
>My vcard size is the same or smaller than the average signature. Using mime,
you
>have the option of easily filtering vcards. Signatures aren't as easily
>identified for filtering.
I think the complaint was due not to the siz
On Sun, 19 Nov 2000, Rogier Wolff wrote:
> Someone wrote:
> > > > So change the CMOS-settings so that the BIOS changes the boot order
> > > > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > > > to keep playing Tic-Tac-Toe?
> > > Writeprotect the flashbios with the motherboa
On Mon, 20 Nov 2000, David Woodhouse wrote:
> On Sun, 19 Nov 2000, Dan Hollis wrote:
> > Writeprotect the flashbios with the motherboard jumper, and remove the
> > cmos battery.
> > Checkmate. :-)
> Only if you run your kernel XIP from the flash. If you load it into RAM,
> it's still possible for
Gerd Knorr wrote:
> Why? What is the point in compiling bttv statically into the kernel?
Well, I see the modules vs. static flame war is already in progress ;-)
My reason for wanting static kernels is that I usually build many, very
different versions of the same kernel, among which I frequentl
On Sun, 19 Nov 2000, Dan Hollis wrote:
> Writeprotect the flashbios with the motherboard jumper, and remove the
> cmos battery.
>
> Checkmate. :-)
Only if you run your kernel XIP from the flash. If you load it into RAM,
it's still possible for an attacker to modify it. You can load new code
into
On Sun, 19 Nov 2000 20:03:52 +0100 (CET),
Gerd Knorr <[EMAIL PROTECTED]> wrote:
>On Mon, 20 Nov 2000, Keith Owens wrote:
>> On my list for 2.5. If foo is declared as MODULE_PARM in object bar
>> then you will be able to boot with bar.foo=27 or even foo=27 as long as
>> variable foo is unique amo
Alexander Viro wrote:
> On Sun, 19 Nov 2000, Christer Weinigel wrote:
>
> > In article <[EMAIL PROTECTED]> you write:
> > >On Sun, 19 Nov 2000, Alexander Viro wrote:
> > >> On Sun, 19 Nov 2000, David Lang wrote:
> > >> > there is a rootkit kernel module out there that, if loaded onto your
> > >>
Christer Weinigel wrote:
> In article <[EMAIL PROTECTED]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto your
> >> > system, can make it almost impossible to detect that yo
Someone wrote:
> > > So change the CMOS-settings so that the BIOS changes the boot order
> > > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > > to keep playing Tic-Tac-Toe?
> >
> > Writeprotect the flashbios with the motherboard jumper, and remove the
> > cmos battery.
T
On Mon, 20 Nov 2000, Keith Owens wrote:
> On 19 Nov 2000 12:56:17 GMT,
> [EMAIL PROTECTED] (Gerd Knorr) wrote:
> >Some generic way to make module args available as kernel args too
> >would be nice. Or at least some simple one-liner I could put next to
> >the MODULE_PARM() macro...
>
> On my li
On Sun, 19 Nov 2000, David Lang wrote:
> there is a rootkit kernel module out there that, if loaded onto your
> system, can make it almost impossible to detect that your system has been
> compramised. with module support disabled this isn't possible.
Wrong. I've seen messages on bugtraq saying
> > So change the CMOS-settings so that the BIOS changes the boot order
> > from A, C, CD-ROM to C first instead. *grin* How long do you want
> > to keep playing Tic-Tac-Toe?
>
> Writeprotect the flashbios with the motherboard jumper, and remove the
> cmos battery.
>
> Checkmate. :-)
You can
Christer Weinigel wrote:
> >Kernel on writeprotected floppy disk...
>
> So change the CMOS-settings so that the BIOS changes the boot order
> from A, C, CD-ROM to C first instead. *grin* How long do you want
> to keep playing Tic-Tac-Toe?
>
> Of course, using capabilities and totally disabling
> Why not? /me has nearly everything compiled as modules.
Some people have extensive sh, awk and sed scripts to manage their systems, some
have compiled programs.
> > There is an introduced security weakness by using kernels.
>
> ??? Guess you mean "by using modules"? Which weakness? Other
On Sun, 19 Nov 2000, Alexander Viro wrote:
> > >Kernel on writeprotected floppy disk...
> Cute. And when (not if) we get hit by new bug in the net/*/* you will drive
> to the location of said router to upgrade the thing.
No, post/email a floppy to tech who swaps the floppy and reboots router.
-D
On Sun, 19 Nov 2000, Christer Weinigel wrote:
> In article <[EMAIL PROTECTED]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto your
> >> > system, can make it almost impossib
On Sun, 19 Nov 2000, Christer Weinigel wrote:
> In article <[EMAIL PROTECTED]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto your
> >> > system, can make it almost impos
In article <[EMAIL PROTECTED]> you write:
>On Sun, 19 Nov 2000, Alexander Viro wrote:
>> On Sun, 19 Nov 2000, David Lang wrote:
>> > there is a rootkit kernel module out there that, if loaded onto your
>> > system, can make it almost impossible to detect that your system has been
>> > compramised.
On Sun, 19 Nov 2000, Alexander Viro wrote:
> On Sun, 19 Nov 2000, David Lang wrote:
> > there is a rootkit kernel module out there that, if loaded onto your
> > system, can make it almost impossible to detect that your system has been
> > compramised. with module support disabled this isn't possib
On Sun, 19 Nov 2000 07:16:52 -0800 (PST),
David Lang <[EMAIL PROTECTED]> wrote:
>there is a rootkit kernel module out there that, if loaded onto your
>system, can make it almost impossible to detect that your system has been
>compramised. with module support disabled this isn't possible.
Wrong.
On Sun, 19 Nov 2000, David Lang wrote:
> there is a rootkit kernel module out there that, if loaded onto your
> system, can make it almost impossible to detect that your system has been
> compramised. with module support disabled this isn't possible.
Yes, it is. Easily. If you've got root you
0 [EMAIL PROTECTED] wrote:
> Date: 19 Nov 2000 12:56:17 GMT
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Newsgroups: lists.linux.kernel
> Subject: Re: BTTV detection broken in 2.4.0-test11-pre5
>
> > > Why? What is the point in compiling bttv statically into t
On 19 Nov 2000 12:56:17 GMT,
[EMAIL PROTECTED] (Gerd Knorr) wrote:
>Some generic way to make module args available as kernel args too
>would be nice. Or at least some simple one-liner I could put next to
>the MODULE_PARM() macro...
On my list for 2.5. If foo is declared as MODULE_PARM in objec
> > Why? What is the point in compiling bttv statically into the kernel?
> > Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> > No problem to compile the driver as module and configure it with
> > /etc/modules.conf ...
>
> Huh?
>
> Some systems are built without module sup
Gerd Knorr wrote:
> Why? What is the point in compiling bttv statically into the kernel?
> Unlike filesystems/ide/scsi/... you don't need it to get the box up.
> No problem to compile the driver as module and configure it with
> /etc/modules.conf ...
Huh?
Some systems are built without module
Werner Almesberger wrote:
> Gerd Knorr wrote:
> > It simply did'nt work correctly and often used to misdetect
> > random bt848 cards as either MIRO or Hauppauge (which where the first
> > available cards).
>
> Well, this means there's yet another mandatory __setup parameter :-(
Why? What is the
Gerd Knorr wrote:
> It simply did'nt work correctly and often used to misdetect
> random bt848 cards as either MIRO or Hauppauge (which where the first
> available cards).
Well, this means there's yet another mandatory __setup parameter :-(
Should it be called bttv_card or bt484_card (i.e. are t
Werner Almesberger wrote:
> The BTTV driver 0.7.48 doesn't detect my old Hauppauge card anymore.
Yes. I've taken out the detection heuristics for bt848 cards. The code
is very old, from the days where only 2-3 different bt848 cards where
available. It simply did'nt work correctly and often use
type to 2 in 2.4.0-test11-pre5, the
card is properly initialized and works.
Not sure what the correct fix is. Maybe to fall back to vendor/device
ID if there's no subsystem information ?
- Werner
-- cut here ---
# lspci -v -
I think the definition of ISAPNP_DEVICE in
linux-2.4.0-test11-pre5/include/linux/isapnp.h is unnecessarily complex.
Here is a proposed patch.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California
I installed the latest kernel ( 2.4.0-test11-pre5
). On boot with new kernel, system hangup before booting is
completed.
I don't know where, but I think this occurs when
system is attempt to mount filesystems.
Now I use kernel 2.4.0-test-10 and it work
fine.
Regards.
Sergey.
[EMAIL PROTECTED] (Dan Aloni) writes:
> Is there a special reason why dev->name is not a pointer?
One of the changes in 2.3 was to change dev->name from a pointer to the
char array. A little bit painful (in terms of the number of changes,
rather than the complexity).
The reason for this is that
Date: Thu, 16 Nov 2000 02:16:32 +0100 (CET)
From: willy tarreau <[EMAIL PROTECTED]>
I also had to move the #include
out of the #ifdef __sparc__/#endif because
copy_{from|to}_user were left undefined (see
simple patch below).
Applied, thanks.
Later,
David S. Miller
[EMAIL PROT
linux-2.4.0-test11-pre5/drivers/net/hamradio/baycomm_epp.c and
linux-2.4.0-test11-pre5/drivers/net/hamradio/soundmodem.h refer to
current_cpu.x86_capability, which has changed from an integer to
an array, causing compile errors in these files. Here is a proposed
patch. Thomas, will you
Hello !
(thanks Dave for the quick patch)
I also had to move the #include
out of the #ifdef __sparc__/#endif because
copy_{from|to}_user were left undefined (see
simple patch below).
Regards,
Willy
--- drivers/net/sunhme.c-orig Wed Nov 15 12:56:33
2000
+++ drivers/net/sunhme.cWed N
This is a better fix:
--- drivers/net/sunhme.c.~1~Sun Nov 12 02:23:30 2000
+++ drivers/net/sunhme.cWed Nov 15 16:34:44 2000
@@ -1600,6 +1600,10 @@
HMD(("happy_meal_init: old[%08x] bursts<",
hme_read32(hp, gregs + GREG_CFG)));
+#ifndef __sparc__
+ /* It is
linux-2.4.0-test11-pre5/drivers/net/sunhme.c fails to compile
on x86 because it uses the undefined symbols DMA_BURST{BITS,8,16,32,64},
which are not defined anywhere in include/asm-i386/*.h. For sparc,
these symbols are defined in include/asm-sparc/dma.h, so I copied them
in sunhme.c and
>> Actually, I know of at least one other shipping commercial
>> product (Sitraka's JProbe Java Profiler) that will require
>> patching because of this change. It seems unwise to be
>> changing field names in commonly used /proc files like
>> cpuinfo at this point in time.
>
> The problem with "
On 15 Nov 00 at 12:12, H. Peter Anvin wrote:
> Also, if a piece of software needs raw CPUID information (unlike the
> "cooked" one provided by recent kernels) it should use
> /dev/cpu/*/cpuid.
There are two problems, first breaking procfs field name for no good reason
(you can name x86 features
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
>
>
> > However, since at least AMD Athlon actually advertises MCA, I would
> > like to verify that the code works on these processors before
> > submitting it to Linus.
>
> The Athlon MCA is basical
Followup to: <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED] (Rogier Wolff)
In newsgroup: linux.dev.kernel
>
> H. Peter Anvin wrote:
> > crash; I don't expect anyone to actually see an #MF exception in real
> > life. I'm trying to get confirmation from AMD that the code should
> > be correct
H. Peter Anvin wrote:
> crash; I don't expect anyone to actually see an #MF exception in real
> life. I'm trying to get confirmation from AMD that the code should
> be correct even for Athlon.
Peter,
Would it be an idea to invite people to lower the voltage on their
CPUs a bit, to try and tri
> However, since at least AMD Athlon actually advertises MCA, I would
> like to verify that the code works on these processors before
> submitting it to Linus.
The Athlon MCA is basically the same architecture-wise as Pentium Pro/II
But there are some differences.. Until AMD make document 21656
Michel LESPINASSE wrote:
>
> On Wed, Nov 15, 2000 at 12:12:15PM -0800, H. Peter Anvin wrote:
> > Also, if a piece of software needs raw CPUID information (unlike the
> > "cooked" one provided by recent kernels) it should use
> > /dev/cpu/*/cpuid.
>
> Is it also OK to use the cpuid opcode in user
On Wed, Nov 15, 2000 at 12:12:15PM -0800, H. Peter Anvin wrote:
> Also, if a piece of software needs raw CPUID information (unlike the
> "cooked" one provided by recent kernels) it should use
> /dev/cpu/*/cpuid.
Is it also OK to use the cpuid opcode in userspace ? (after checking
for its presence
Followup to: <[EMAIL PROTECTED]>
By author:Scott Murray <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK,
> > I'll release patch for vmware, as I cannot stop kernel developers
> > from changing field names :-)
>
> Act
Hi friends,
I noticed a slight bug in my CPUID 2.4.0-test11-pre5, and when I
unwound it, found some interesting things.
This relates to the Machine Check Architecture code (bluesmoke.c),
which in the previous code was conditionalized on running on an Intel
CPU. It appears that that shouldn&#
On Wed, 15 Nov 2000, Petr Vandrovec wrote:
> On 15 Nov 00 at 1:59, Tigran Aivazian wrote:
>
> > You probably noticed this already but I just wanted to bring it to your
> > attention that /usr/bin/vmware-config.pl script needs updating since the
> > flags in /proc/cpuinfo is now called "features"
On 15 Nov 00 at 17:47, Petr Vandrovec wrote:
> On 15 Nov 00 at 1:59, Tigran Aivazian wrote:
>
> > You probably noticed this already but I just wanted to bring it to your
> > attention that /usr/bin/vmware-config.pl script needs updating since the
> > flags in /proc/cpuinfo is now called "features
On 15 Nov 00 at 1:59, Tigran Aivazian wrote:
> You probably noticed this already but I just wanted to bring it to your
> attention that /usr/bin/vmware-config.pl script needs updating since the
> flags in /proc/cpuinfo is now called "features" so it otherwise fails
> complaining that my 2xP6 has
On Wed, 15 Nov 2000, Tigran Aivazian wrote:
> On Wed, 15 Nov 2000, Tigran Aivazian wrote:
>
> > Hi Keith,
> >
> > Here is some fixes related to x86 capabilities changes in test11-pre5.
> > Against your latest patch (test11-pre5) from oss.sgi. Teste
On Wed, 15 Nov 2000, Tigran Aivazian wrote:
> Hi Keith,
>
> Here is some fixes related to x86 capabilities changes in test11-pre5.
> Against your latest patch (test11-pre5) from oss.sgi. Tested under
> test11-pre5 on SMP.
>
small (but important!) typo fixed, thanks to George
Hi guys,
The test11-pre5 seems to be unusable:
o starting up vim(1) takes many seconds instead of the usual <<1 second
o trying to strace vim takes even longer
o trying to ltrace vim panics the kernel but kdb is also unusable -- can't
decode stack traces etc. Perhaps I'll go
Hi Keith,
Here is some fixes related to x86 capabilities changes in test11-pre5.
Against your latest patch (test11-pre5) from oss.sgi. Tested under
test11-pre5 on SMP.
Regards,
Tigran
--- arch/i386/kernel/traps.c.0 Wed Nov 15 11:20:34 2000
+++ arch/i386/kernel/traps.cWed Nov 15 11:28:20
Hi Petr,
You probably noticed this already but I just wanted to bring it to your
attention that /usr/bin/vmware-config.pl script needs updating since the
flags in /proc/cpuinfo is now called "features" so it otherwise fails
complaining that my 2xP6 has no tsc. Trivial change but still worthy of
p
Date: Wed, 15 Nov 2000 02:59:36 +0200 (IST)
From: Dan Aloni <[EMAIL PROTECTED]>
On Tue, 14 Nov 2000, David S. Miller wrote:
> Then the compiler will start warning us :-)
I've also noticed that routing_ioctl() in arch/mips64/kernel/ioctl32.c
assumes the 16. Are those two platfo
On Tue, 14 Nov 2000, David S. Miller wrote:
>Date: Wed, 15 Nov 2000 02:25:38 +0200 (IST)
>From: Dan Aloni <[EMAIL PROTECTED]>
>
>Agreed. BTW, after grepping for IFNAMSIZ references I've noticed
>some architectures (sparc64, mips64) define IFNAMSIZ for
>themsleves, for ex
Date:Wed, 15 Nov 2000 02:25:38 +0200 (IST)
From: Dan Aloni <[EMAIL PROTECTED]>
Agreed. BTW, after grepping for IFNAMSIZ references I've noticed
some architectures (sparc64, mips64) define IFNAMSIZ for
themsleves, for example, arch/sparc64/kernel/ioctl32.c, which
defines
On Tue, 14 Nov 2000, Linus Torvalds wrote:
> On Wed, 15 Nov 2000, Dan Aloni wrote:
> >
> > summery: dev_3c501.name shouldn't be NULL, or we get oops
>
> Note that these days "name" is not a pointer at all, but an array, and as
> such cannot be NULL any more. Not initializing it will just cause i
In article <[EMAIL PROTECTED]>,
Dan Aloni <[EMAIL PROTECTED]> wrote:
>On Tue, 14 Nov 2000, Jeff Garzik wrote:
>
>> Dan Aloni wrote:
>> >
>> > reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
>> > net_init.c:register_netdev(&dev_3c501), which calls strchr(),
>> > {and might also,w
On Wed, 15 Nov 2000, Dan Aloni wrote:
>
> summery: dev_3c501.name shouldn't be NULL, or we get oops
Note that these days "name" is not a pointer at all, but an array, and as
such cannot be NULL any more. Not initializing it will just cause it to be
empty (ie is the same as initializing it to ""
Dan Aloni wrote:
>
> On Tue, 14 Nov 2000, Jeff Garzik wrote:
>
> > Dan Aloni wrote:
> > >
> > > reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
> > > net_init.c:register_netdev(&dev_3c501), which calls strchr(),
> > > {and might also,which might} dereference dev_3c501.name.
> >
On Tue, 14 Nov 2000, Jeff Garzik wrote:
> Dan Aloni wrote:
> >
> > reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
> > net_init.c:register_netdev(&dev_3c501), which calls strchr(),
> > {and might also,which might} dereference dev_3c501.name.
>
> There is no dereferencing involv
On Tue, 14 Nov 2000, Linus Torvalds wrote:
> - pre5:
> - Rasmus Andersen: add proper "" for sound drivers
Rasmus spotted gus_midi.c not 100% correctly... (anyway thanks Rasmus)
--- linux-240t10p5/drivers/sound/gus_midi.c Wed Nov 15 00:06:14 2000
+++ linux/drivers/sound/gus_midi.c W
Dan Aloni wrote:
>
> against: test11-pre5
> summery: dev_3c501.name shouldn't be NULL, or we get oops
> reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
> net_init.c:register_netdev(&dev_3c501), which calls strchr(),
> {and might also,which m
>>>>> "Linus" == Linus Torvalds <[EMAIL PROTECTED]> writes:
Linus> More drivers.
Linus> The x86 capabilities cleanup is here.
Hi Linus
Looks like you missed the acenic bugfix patch. Here is an uptodate
version relative to pre5.
Jes
--- linux-2.4.0-test11
against: test11-pre5
summery: dev_3c501.name shouldn't be NULL, or we get oops
reason: Correct me if I'm wrong, but 3c501.c:init_module() calls
net_init.c:register_netdev(&dev_3c501), which calls strchr(),
{and might also,which might} dereference dev_3c501.name.
--- linux/drive
More drivers.
The x86 capabilities cleanup is here.
Linus
- pre5:
- Rasmus Andersen: add proper "" for sound drivers
- David Miller: sparc64 and networking updates
- David Trcka: MOXA numbering starts from 0, not 1.
- Jeff Garzik: sysctl.h standalone
70 matches
Mail list logo
