On Fre, 25 Feb 2005, Andrew Morton wrote:
> Doh. This works.
True. Thanks.
Best wishes
Norbert
---
Norbert Preining Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-
Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> On Don, 24 Feb 2005, Andrew Morton wrote:
> > Norbert, does this make the warnings go away?
>
> Unfortunately no, still the very same error.
Doh. This works.
--- 25/arch/i386/mm/ioremap.c~iounmap-isa-special-case 2005-02-25
01:38:51.
On Don, 24 Feb 2005, Andrew Morton wrote:
> Norbert, does this make the warnings go away?
Unfortunately no, still the very same error.
I checked double, the patch is in and new compiled and new booted
kernel!
Best wishes
Norbert
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Thu, 24 Feb 2005, Andrew Morton wrote:
> >
> > Although a better fix might be to make __iounmap() behave symmetrically:
> >
> >if ((long)addr >= phys_to_virt(0xA) &&
> >(long)addr < phys_to_virt(0x10))
> >
On Thu, 24 Feb 2005, Andrew Morton wrote:
>
> Although a better fix might be to make __iounmap() behave symmetrically:
>
> if ((long)addr >= phys_to_virt(0xA) &&
> (long)addr < phys_to_virt(0x10))
> return;
>
> but that's not quite right, becau
Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> On Don, 24 Feb 2005, Andrew Morton wrote:
> > What does the stack backtrace from iounmap-debugging.patch say?
>
> iounmap: bad address c00fffd9
> [] trap_init+0x30/0x190
> [] start_kernel+0x47/0x1c0
ah hah.
trap_init() does:
void __iomem
On Don, 24 Feb 2005, Andrew Morton wrote:
> What does the stack backtrace from iounmap-debugging.patch say?
iounmap: bad address c00fffd9
[] trap_init+0x30/0x190
[] start_kernel+0x47/0x1c0
Best wishes
Norbert
---
Nor
Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> On Die, 25 Jan 2005, Andrew Morton wrote:
> > Norbert Preining <[EMAIL PROTECTED]> wrote:
> > >
> > > ACPI: DSDT (v001 ACER IBIS 0x20020930 MSFT 0x010e) @ 0x
> > > Built 1 zonelists
> > > __iounmap: bad address c00fffd9
>
>
Hi Andrew!
On Die, 25 Jan 2005, Andrew Morton wrote:
> Norbert Preining <[EMAIL PROTECTED]> wrote:
> >
> > ACPI: DSDT (v001 ACER IBIS 0x20020930 MSFT 0x010e) @ 0x
> > Built 1 zonelists
> > __iounmap: bad address c00fffd9
I still have this with 2.6.11-rc4-mm1 and the patch you
; suggestion.
>
> Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
> Index: linux-2.6.11-rc2-mm1-modules/security/seclvl.c
> ===============
> --- linux-2.6.11-rc2-mm1-modules.orig/security/seclvl.c 2005-02-03
> 14:55:44.79
* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> This is the sixth in a series of eight patches to the BSD Secure
> Levels LSM. It makes several trivial changes to make the code
> consistent.
These are inconsistent with CodingStyle. I'd drop this, and go the
other way (patch is smaller) ala Linden
* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> [...]. This occurs because the bd_release function will
> bd_release(bdev) and set inode->i_security to NULL on the close(fd1).
> Hence, we want to place the control at the level of the file struct,
> not the inode.
This is basically what I was refer
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> On Tue, 08 Feb 2005 11:24:50 CST, Michael Halcrow said:
>
> > While the program is waiting for a keystroke, mount the block device.
> > Enter a keystroke. The result without the patch is 1, which is a
> > security violation. This occurs because th
On Tue, 08 Feb 2005 11:24:50 CST, Michael Halcrow said:
> While the program is waiting for a keystroke, mount the block device.
> Enter a keystroke. The result without the patch is 1, which is a
> security violation. This occurs because the bd_release function will
> bd_release(bdev) and set ino
On Mon, Feb 07, 2005 at 02:26:03PM -0800, Chris Wright wrote:
> * Michael Halcrow ([EMAIL PROTECTED]) wrote:
> > This is the third in a series of eight patches to the BSD Secure
> > Levels LSM. It moves the claim on the block device from the inode
> > struct to the file struct in order to address
>The attack is to hardlink some tempfile name to some file you want
>over-written. This usually involves just a little bit of work, such as
>recognizing that a given root cronjob uses an unsafe predictable filename
>in /tmp (look at the Bugtraq or Full-Disclosure archives, there's plenty).
>Then y
On Mon, 07 Feb 2005 18:20:36 PST, Chris Wright said:
> * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > open("/tmp/sh-thd-1107848098", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE,
0600) = 3
>
> O_EXCL
>
> > Wow - if my /tmp was on the same partition, and I'd hard-linked that
> > file to /etc/p
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> open("/tmp/sh-thd-1107848098", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL|O_LARGEFILE,
> 0600) = 3
O_EXCL
> Wow - if my /tmp was on the same partition, and I'd hard-linked that
> file to /etc/passwd, it would be toast now if root had run it.
So, in fact, it
On Tue, 08 Feb 2005 01:48:40 GMT, David Wagner said:
> How would /etc/passwd get clobbered? Are you thinking that a tmp
> cleaner run by cron might delete /tmp/whatever (i.e., delete the hardlink
> you created above)? But deleting /tmp/whatever is safe; it doesn't affect
> /etc/passwd. I'm gues
>For those systems that have everything on one big partition, you can often
>do stuff like:
>
>ln /etc/passwd /tmp/
>
>and wait for /etc/passwd to get clobbered by a cron job run by root...
How would /etc/passwd get clobbered? Are you thinking that a tmp
cleaner run by cron might delete /tmp/what
On Mon, 07 Feb 2005 14:26:03 PST, Chris Wright said:
> * Michael Halcrow ([EMAIL PROTECTED]) wrote:
> > This is the third in a series of eight patches to the BSD Secure
> > Levels LSM. It moves the claim on the block device from the inode
> > struct to the file struct in order to address a potenti
On Mon, 07 Feb 2005 14:26:03 PST, Chris Wright said:
> Hard links still point to same inode, what's the issue that this
> addresses?
For those systems that have everything on one big partition, you can often
do stuff like:
ln /etc/passwd /tmp/
and wait for /etc/passwd to get clobbered by a cron
* Michael Halcrow ([EMAIL PROTECTED]) wrote:
> This is the third in a series of eight patches to the BSD Secure
> Levels LSM. It moves the claim on the block device from the inode
> struct to the file struct in order to address a potential
> circumvention of the control via hard links to block dev
On Mon, 2005-02-07 at 12:30 -0500, Robert Love wrote:
> Well, I don't share the hatred for ioctl, at least compared to another
> type unsafe interface like write().
>
> But John and I are open to doing whatever is the consensus. If there is
> an agreed alternative, and that is the requirement for
This is the fourth in a series of eight patches to the BSD Secure
Levels LSM. It adds a check for a memory allocation failure
condition. Thanks to Vesa-Matti J Kari for pointing out this problem.
Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm1-modules/se
This is the eighth in a series of eight patches to the BSD Secure
Levels LSM. It removes the ptrace check because it is redundant with
the check made in kernel/ptrace.c. Thanks for Brad Spengler for this
suggestion.
Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
Index: linux-2.6.11-r
This is the sixth in a series of eight patches to the BSD Secure
Levels LSM. It makes several trivial changes to make the code
consistent.
Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm1-modules/security/se
This is the seventh in a series of eight patches to the BSD Secure
Levels LSM. It makes several trivial changes to comments in order to
make the code look more pretty.
Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm1-modules/security/se
linux-2.6.11-rc2-mm1-modules/security/seclvl.c
===
--- linux-2.6.11-rc2-mm1-modules.orig/security/seclvl.c 2005-02-03
15:39:35.786556648 -0600
+++ linux-2.6.11-rc2-mm1-modules/security/seclvl.c 2005-02-03
15:41:46.043754544
.
Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm1-modules/security/seclvl.c
===
--- linux-2.6.11-rc2-mm1-modules.orig/security/seclvl.c 2005-02-03
15:36:43.925683472 -0600
+++ linux-2.6.11-rc2-mm1-m
TED]>
Index: linux-2.6.11-rc2-mm1-modules/security/seclvl.c
===
--- linux-2.6.11-rc2-mm1-modules.orig/security/seclvl.c 2005-02-03
15:14:54.907684456 -0600
+++ linux-2.6.11-rc2-mm1-modules/security/seclvl.c 2005-02-03
This is the first in a series of eight patches to the BSD Secure
Levels LSM. It overhauls the printk mechanism in order to reduce the
unnecessary usage of the .text area. Thanks to Brad Spengler for the
suggestion.
Signed off by: Michael Halcrow <[EMAIL PROTECTED]>
Index: linux-2.6.11-r
On Mon, 2005-02-07 at 12:57 +0100, Ingo Molnar wrote:
Hello, Ingo.
> > Also ioctl is not an acceptable interface for adding new core
> > functionality.
>
> seconded. Robert?
Well, I don't share the hatred for ioctl, at least compared to another
type unsafe interface like write().
But John and
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > inotify.patch
> > inotify
> Also ioctl is not an acceptable interface for adding new core
> functionality.
seconded. Robert?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
On Thu, 27 Jan 2005, Evgeniy Polyakov wrote:
> On Thu, 27 Jan 2005 10:19:51 -0500
> Bill Davidsen <[EMAIL PROTECTED]> wrote:
>
> > Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >>It seems noone who reviewed the Supe
--- Andreas Gruenbacher <[EMAIL PROTECTED]> escribió:
> Hello again,
>
> this looks like a good candidate. Could you please
> try if it fixes the
> problem?
The Oops went away with this one.
> Thanks,
Your welcome.
Cheers,
Albert
__
Hello again,
this looks like a good candidate. Could you please try if it fixes the
problem?
Thanks,
--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX GMBH
--- Begin Message ---
This pattern from 2.4 times doesn't work very well anymore :(
Signed-off-by: Andreas Gruenbacher <[EMA
--- Andreas Gruenbacher <[EMAIL PROTECTED]> escribió:
> Hello,
>
> here is a fix for a NULL pointer access problem with
> NFSv2 that isn't in
> 2.6.11-rc2-mm1, but it can't explain this NULL
> inode->i_op.
>
> -- Andreas.
Hi,
Yes, that patch se
Hello,
here is a fix for a NULL pointer access problem with NFSv2 that isn't in
2.6.11-rc2-mm1, but it can't explain this NULL inode->i_op.
-- Andreas.
--- Begin Message ---
Hello,
this patch has an NFSv2 problem that I haven't tripped over until today. The
fix is this:
--- Andrew Morton <[EMAIL PROTECTED]> escribió:
> Can you tell us which filesystem is being bad? Add
> this:
>
> if (!inode->i_op)
> printk("%s is naughty\n", inode->i_sb->s_id);
>
> It's probably NFS - there has been some work done in
> there in -mm.
0:a is naughty
Cheer
Albert Herranz <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm getting a kernel Oops while booting 2.6.11-rc2-mm1
> on a diskless (nfsroot based) embedded ppc system.
> Vanilla 2.6.11-rc2 works Ok.
>
> [...]
> VFS: Mounted root (nfs filesystem) readonly.
>
Hi,
I'm getting a kernel Oops while booting 2.6.11-rc2-mm1
on a diskless (nfsroot based) embedded ppc system.
Vanilla 2.6.11-rc2 works Ok.
[...]
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 112k init
INIT: version 2.86 booting
Oops: kernel access of bad area
On Tue, Jan 25, 2005 at 01:03:39AM +0100, Sytse Wielinga wrote:
> Hi Andrew,
>
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > fuse-transfer-readdir-data-through-device.patch
> > fuse: transfer readdir data through device
> It is great that this is fixed, don't remove it, bu
On Wed, 26 Jan 2005 15:22:52 -0500
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> >
> > Chip driver provides access methods to the attached logical devices.
> > It probes and activates them, if appropriate module is
> > >As I personally like for my ls to keep on working, and I assume
> > >others will, too, I would appreciate it if you could add a
> > >warning to your announcements the following one or two weeks or
> > >so, so that people can remove this patch if they don't want to
> > >update their libs.
> >
On Thu, 27 Jan 2005 10:19:51 -0500
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> >
> >>It seems noone who reviewed the SuperIO patches noticed that there are
> >>now two modules "scx200"
On Thu, Jan 27, 2005 at 10:45:09AM -0500, Bill Davidsen wrote:
> Sytse Wielinga wrote:
> >It is great that this is fixed, don't remove it, but it does require the fuse
> >libs to be updated at the same time, or opening dirs for listings will break
> >like this:
> >
> >open(".", O_RDONLY|O_NONBLOCK|
Sytse Wielinga wrote:
Hi Andrew,
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through device
It is great that this is fixed, don't remove it, but it does require the
fuse
libs to be updated at the same t
Evgeniy Polyakov wrote:
On Mon, 24 Jan 2005 18:54:49 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
It seems noone who reviewed the SuperIO patches noticed that there are
now two modules "scx200" in the kernel...
They are almost mutually exlusive(SuperIO contains more advanced),
so I do not see a
is?
>
> http://lkml.org/lkml/2005/1/3/136
Hmm, it seems that this is included in 2.6.11-rc2-mm1, at least AFAIS.
Best wishes
Norbert
---
Norbert Preining Technische Universität Wien
s
On Thu, 2005-01-27 at 11:20 +0100, Adrian Bunk wrote:
> On Wed, Jan 26, 2005 at 10:27:43PM +0300, Evgeniy Polyakov wrote:
> >...
> > I greatly appreciate your comments, and they were addressed.
> > Part of exported symbols are unexported, patch is just waiting to be sent,
>
> Ah, sorry. I only saw
On Wed, Jan 26, 2005 at 10:27:43PM +0300, Evgeniy Polyakov wrote:
>...
> I greatly appreciate your comments, and they were addressed.
> Part of exported symbols are unexported, patch is just waiting to be sent,
Ah, sorry. I only saw that the patch I sent two months ago still
applies completely (e
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>> - Lots of updates and fixes all over the place.
>> - On my test box there is no flashing cursor on the vga console. Known bug,
>> please don't report it.
>> Binary searching shows that the bug was introduced by
>> cleanup-vc-a
On Mit, 26 Jan 2005, Len Brown wrote:
> > Can you please add this?
> >
> > --- 25/arch/i386/mm/ioremap.c~iounmap-debugging 2005-01-25
> > 10:26:29.448809152 -0800
> > +++ 25-akpm/arch/i386/mm/ioremap.c 2005-01-25 10:27:07.054092280
> > -0800
> > @@ -233,7 +233,8 @@ void iounmap(volatile void
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't
On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > <[EMAIL PROTECTED]> wrote:
> >
On Wed, 26 Jan 2005 20:39:36 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> > <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > >
On Wed, 26 Jan 2005 19:19:41 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
> >...
> > Btw, where was comments about w1, kernel connector and acrypto?
> > They were presented several times in lkml and all are completely new
> > sub
[Voluntarily skipping a large part of the discussion so as to stop
wasting everyone's time and focus on the one technical point I am
interested in.]
Hi Evgeniy,
> As I saw from different documentation - logical devices itself are the
> same.
>
> And it is the same for superio standard.
>
> For
On Wed, Jan 26, 2005 at 01:12:34PM +, Russell King wrote:
> On Wed, Jan 26, 2005 at 10:14:34AM +, Christoph Hellwig wrote:
> > That's simply not true. The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> >
> > If no one replies i
On Wed, 26 Jan 2005 20:20:27 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> [Voluntarily skipping a large part of the discussion so as to stop
> wasting everyone's time and focus on the one technical point I am
> interested in.]
>
> Hi Evgeniy,
>
> > As I saw from different documentation - logi
On Tue, 2005-01-25 at 13:28, Andrew Morton wrote:
> Norbert Preining <[EMAIL PROTECTED]> wrote:
> >
> > ACPI: DSDT (v001 ACER IBIS 0x20020930 MSFT 0x010e) @
> 0x
> > Built 1 zonelists
> > __iounmap: bad address c00fffd9
>
> Can you please add this?
>
> --- 25/arch/i386/mm/iore
Hi,
This small patch fixes a compilation warning due to a
duplicate definition of MMCR0_PMXE.
The definition comes in perfctr-ppc.patch, but was
recently introduced too in Linus tree.
Cheers,
Albert
__
Renovamos el Correo Yahoo!: ¡
On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
>
> Chip driver provides access methods to the attached logical devices.
> It probes and activates them, if appropriate module is loaded.
>
> Your example again is not suitable for superio case.
>
> With superio you
On Wed, 26 Jan 2005 13:26:38 -0500
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > > > > > Since each logical device does not know who use it, it can not be,
> > > > > > for example, removed optimally.
> > > > > > You need to run through whole superio device set to find those one
> > > > > > that
On Wed, Jan 26, 2005 at 01:59:17PM +0300, Evgeniy Polyakov wrote:
> On Wed, 2005-01-26 at 10:14 +, Christoph Hellwig wrote:
> > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > I have one rule - if noone answers that it means noone objects,
> > > or it is not interesting
On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
>...
> Btw, where was comments about w1, kernel connector and acrypto?
> They were presented several times in lkml and all are completely new
> subsystems.
> Should I stop developing just because I did not get comments?
>...
I sent
On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > >
On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > <[EMAIL PROTECTED]> wrote:
> >
On Wed, 2005-01-26 at 09:00 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 13:59:17 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-01-26 at 10:14 +, Christoph Hellwig wrote:
> > > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > > I have one ru
On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Each superio chip has the same logical devices inside.
> > >
On Wed, 2005-01-26 at 15:34 +0100, Jean Delvare wrote:
> Hi Evgeniy,
>
> > I presented the code.
> > Several times in special mail list.
>
> That's true. Except that the second time (at least) you didn't find
> anyone to review it. Also note that your patches are about superio, gpio
> and now acc
On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
>
> > Each superio chip has the same logical devices inside.
> > With your approach we will have following schema:
> >
> > bus:
> > superio1 - voltage, tem
On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> Each superio chip has the same logical devices inside.
> With your approach we will have following schema:
>
> bus:
> superio1 - voltage, temp, gpio, rtc, wdt, acb
> superio2 - voltage, temp, gpio, rtc, wdt, acb
> s
On Wed, 2005-01-26 at 08:46 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 11:25:02 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> >
> > > > > I have a slightly different concern - the superio is a completely new
> > > > >
On Wed, 2005-01-26 at 08:32 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 11:31:07 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-01-25 at 22:42 +, Christoph Hellwig wrote:
> > > > Yes, and it is better than removing module whose structures are in use.
> > > > Super
Hi Evgeniy,
> I presented the code.
> Several times in special mail list.
That's true. Except that the second time (at least) you didn't find
anyone to review it. Also note that your patches are about superio, gpio
and now access bus. The list is dedicated to hardware monitoring. This
is no exac
On Wed, 26 Jan 2005 13:59:17 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2005-01-26 at 10:14 +, Christoph Hellwig wrote:
> > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > I have one rule - if noone answers that it means noone objects,
> > > or it is no
On Wed, 26 Jan 2005 11:25:02 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
>
> > > > I have a slightly different concern - the superio is a completely new
> > > > subsystem and it should be integtrated with the driver model
> > > > (
On Wed, 26 Jan 2005 11:31:07 +0300, Evgeniy Polyakov
<[EMAIL PROTECTED]> wrote:
> On Tue, 2005-01-25 at 22:42 +, Christoph Hellwig wrote:
> > > Yes, and it is better than removing module whose structures are in use.
> > > SuperIO core is asynchronous in it's nature, one can use logical device
>
On Wed, Jan 26, 2005 at 10:14:34AM +, Christoph Hellwig wrote:
> That's simply not true. The amount of patches submitted is extremly
> huge and the reviewers don't have time to look at everythning.
>
> If no one replies it simply means no one has looked at it in enough
> detail to comment yet
On Wed, 2005-01-26 at 10:14 +, Christoph Hellwig wrote:
> On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > I have one rule - if noone answers that it means noone objects,
> > or it is not interesting for anyone, and thus noone objects.
>
> That's simply not true. The amou
On Wed, 2005-01-26 at 10:55 +0100, Jean Delvare wrote:
> Hi Evgeniy,
>
> > > So I suspect that this update at least was never reviewed by anyone (on
> > > the sensors list at least).
> >
> > I have one rule - if noone answers that it means noone objects,
> > or it is not interesting for anyone, an
On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> I have one rule - if noone answers that it means noone objects,
> or it is not interesting for anyone, and thus noone objects.
That's simply not true. The amount of patches submitted is extremly
huge and the reviewers don't have
Hi Evgeniy,
> > So I suspect that this update at least was never reviewed by anyone (on
> > the sensors list at least).
>
> I have one rule - if noone answers that it means noone objects,
> or it is not interesting for anyone, and thus noone objects.
Broken rule IMHO. This might be fine for your
On Tue, 2005-01-25 at 22:42 +, Christoph Hellwig wrote:
> > Zeroing can be found easily - the whole structure is NULL pointer,
> > and will always panic if accessed(from running superio code),
> > but redzoning is only happen on borders,
> > and can catch writes over the boards, which is rare
On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> > > I have a slightly different concern - the superio is a completely new
> > > subsystem and it should be integtrated with the driver model
> > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > the abstractio
On Tuesday 25 January 2005 16:14, Evgeniy Polyakov wrote:
> On Tue, 25 Jan 2005 11:11:42 -0500
> Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> > <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2005-01-25 at 14:23 +, Christoph Hellwig wrote:
>
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console. Known bug,
> please don't
On Wed, 26 January 2005 00:17:34 +0300, Evgeniy Polyakov wrote:
>
> That will catch only simple cases - for the whole picture you need
> to run graph generator from all allowed code pathes, but that
> will require knowledge of the tested system, so it will not and
> actually can not be absolutely
On Tue, Jan 25, 2005 at 07:12:55PM +, Marcos D. Marado Torres wrote:
> This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still
> happens.
http://bugme.osdl.org/show_bug.cgi?id=4041
Look at that bug report (especially toward the bottom) for the latest
information.
-Barry K. Nat
> Thanks for tracking that down. It was intended that such things would not
> be possible because getting into that code in the first place should be
> ruled out while exiting. That removes the requirement for any special case
> check in the common path. But, it was done too late since it hadn't
> Zeroing can be found easily - the whole structure is NULL pointer,
> and will always panic if accessed(from running superio code),
> but redzoning is only happen on borders,
> and can catch writes over the boards, which is rarely in this case.
As I mentioned the redzoning was a brainfar on my
On Tue, 25 Jan 2005 22:40:51 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Evgeniy & all,
>
> > > 1* This was 5 months ago. I'd expect Evgeniy's code to have
> > > significantly evolved since, so an additional review now would
> > > certainly be welcome.
> >
> > superio core was not changed
Thanks for tracking that down. It was intended that such things would not
be possible because getting into that code in the first place should be
ruled out while exiting. That removes the requirement for any special case
check in the common path. But, it was done too late since it hadn't
occurre
Hi Evgeniy & all,
> > 1* This was 5 months ago. I'd expect Evgeniy's code to have
> > significantly evolved since, so an additional review now would
> > certainly be welcome.
>
> superio core was not changed much, all related changes were posted
> into lm_sensors mail list and discussed.
Well,
On Tue, 25 Jan 2005, Matt Mackall wrote:
> On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
> > I'm having trouble booting here, were those random-* patches tested?
> >
> > EIP is at __add_entropy_words+0xc5/0x1c0
> > eax: 002d ebx: 000f ecx: 007b edx: f5e5
>
On Tue, 25 Jan 2005 19:59:18 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> > As previously mentioned, these patches have had that, on the sensors
> > mailing list. Lots of review and comments went into them there, and
> > the code was reworked quite a lot based on it.
>
> That's r
On Tue, 25 Jan 2005 19:21:10 +0100
J_rn Engel <[EMAIL PROTECTED]> wrote:
> On Tue, 25 January 2005 19:04:47 +0300, Evgeniy Polyakov wrote:
> > On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
> >
> > > Ugh, now think about that:
> > >
> > > CPU0 CPU1
> > > place1: place2
On Tue, 25 Jan 2005 11:11:42 -0500
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-01-25 at 14:23 +, Christoph Hellwig wrote:
> > > > > +static void pc8736x_fini(void)
> > > > > +{
> > > > > + sc_de
1 - 100 of 187 matches
Mail list logo
