[PATCH] Convert cciss to compat_ioctl

[Andi Kleen]

Convert the cciss driver to compat_ioctl.  This cleans up a lot 
of code.

I don't have such hardware thus this is only compile tested.

This requires the block device compat_ioctl patch I sent earlier.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

diff -u linux-2.6.11-rc1-bk4/drivers/block/cciss.c-o 
linux-2.6.11-rc1-bk4/drivers/block/cciss.c
--- linux-2.6.11-rc1-bk4/drivers/block/cciss.c-o2005-01-14 
10:12:17.0 +0100
+++ linux-2.6.11-rc1-bk4/drivers/block/cciss.c  2005-01-18 06:30:43.0 
+0100
@@ -146,11 +146,18 @@
 static void cciss_procinit(int i) {}
 #endif /* CONFIG_PROC_FS */
 
+#ifdef CONFIG_COMPAT
+static int cciss_compat_ioctl(struct file *f, unsigned cmd, unsigned long arg);
+#endif
+
 static struct block_device_operations cciss_fops  = {
.owner  = THIS_MODULE,
.open   = cciss_open, 
.release= cciss_release,
 .ioctl = cciss_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = cciss_compat_ioctl,
+#endif
.revalidate_disk= cciss_revalidate,
 };
 
@@ -477,80 +484,50 @@
 }
 
 #ifdef CONFIG_COMPAT
-/* for AMD 64 bit kernel compatibility with 32-bit userland ioctls */
-extern long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg);
-extern int
-register_ioctl32_conversion(unsigned int cmd, int (*handler)(unsigned int,
-  unsigned int, unsigned long, struct file *));
-extern int unregister_ioctl32_conversion(unsigned int cmd);
-
-static int cciss_ioctl32_passthru(unsigned int fd, unsigned cmd, unsigned long 
arg, struct file *file);
-static int cciss_ioctl32_big_passthru(unsigned int fd, unsigned cmd, unsigned 
long arg,
-   struct file *file);
-
-typedef int (*handler_type) (unsigned int, unsigned int, unsigned long, struct 
file *);
-
-static struct ioctl32_map {
-   unsigned int cmd;
-   handler_type handler;
-   int registered;
-} cciss_ioctl32_map[] = {
-   { CCISS_GETPCIINFO, (handler_type) sys_ioctl, 0 },
-   { CCISS_GETINTINFO, (handler_type) sys_ioctl, 0 },
-   { CCISS_SETINTINFO, (handler_type) sys_ioctl, 0 },
-   { CCISS_GETNODENAME,(handler_type) sys_ioctl, 0 },
-   { CCISS_SETNODENAME,(handler_type) sys_ioctl, 0 },
-   { CCISS_GETHEARTBEAT,   (handler_type) sys_ioctl, 0 },
-   { CCISS_GETBUSTYPES,(handler_type) sys_ioctl, 0 },
-   { CCISS_GETFIRMVER, (handler_type) sys_ioctl, 0 },
-   { CCISS_GETDRIVVER, (handler_type) sys_ioctl, 0 },
-   { CCISS_REVALIDVOLS,(handler_type) sys_ioctl, 0 },
-   { CCISS_PASSTHRU32, cciss_ioctl32_passthru, 0 },
-   { CCISS_DEREGDISK,  (handler_type) sys_ioctl, 0 },
-   { CCISS_REGNEWDISK, (handler_type) sys_ioctl, 0 },
-   { CCISS_REGNEWD,(handler_type) sys_ioctl, 0 },
-   { CCISS_RESCANDISK, (handler_type) sys_ioctl, 0 },
-   { CCISS_GETLUNINFO, (handler_type) sys_ioctl, 0 },
-   { CCISS_BIG_PASSTHRU32, cciss_ioctl32_big_passthru, 0 },
-};
-#define NCCISS_IOCTL32_ENTRIES (sizeof(cciss_ioctl32_map) / 
sizeof(cciss_ioctl32_map[0]))
-static void register_cciss_ioctl32(void)
-{
-   int i, rc;
 
-   for (i=0; i < NCCISS_IOCTL32_ENTRIES; i++) {
-   rc = register_ioctl32_conversion(
-   cciss_ioctl32_map[i].cmd,
-   cciss_ioctl32_map[i].handler);
-   if (rc != 0) {
-   printk(KERN_WARNING "cciss: failed to register "
-   "32 bit compatible ioctl 0x%08x\n",
-   cciss_ioctl32_map[i].cmd);
-   cciss_ioctl32_map[i].registered = 0;
-   } else
-   cciss_ioctl32_map[i].registered = 1;
-   }
-}
-static void unregister_cciss_ioctl32(void)
+static int do_ioctl(struct file *f, unsigned cmd, unsigned long arg)
 {
-   int i, rc;
+   int ret;
+   lock_kernel();
+   ret = cciss_ioctl(f->f_dentry->d_inode, f, cmd, arg);
+   unlock_kernel();
+   return ret;
+}
 
-   for (i=0; i < NCCISS_IOCTL32_ENTRIES; i++) {
-   if (!cciss_ioctl32_map[i].registered)
-   continue;
-   rc = unregister_ioctl32_conversion(
-   cciss_ioctl32_map[i].cmd);
-   if (rc == 0) {
-   cciss_ioctl32_map[i].registered = 0;
-   continue;
-   }
-   printk(KERN_WARNING "cciss: failed to unregister "
-   "32 bit compatible ioctl 0x%08x\n",
-   cciss_ioctl32_map[i].cmd);
+static int cciss_ioctl32_passthru(struct file *f, unsigned cmd, unsigned long 
arg);
+static int cciss_ioctl32_big_passthru(struct file *f, unsigned cmd, unsigned 
long arg);
+
+static long cciss_compat_ioctl(struct file *f, unsigned cmd, unsigned long arg)
+{
+   switch (cmd) { 
+   case CCISS_GETPCIINFO:
+   case CCISS_GETINTINFO:
+   case CCISS_SETINTINFO:
+   cas

[PATCH] Typo in arch/x86_64/Kconfig

[vlobanov]

Hi,

Here is a trivial patch to fix a typo in the arch/x86_64/Kconfig file.
Diffed against linux-2.6.11-rc1. Please apply.

Signed-off-by: Vadim Lobanov <[EMAIL PROTECTED]>

diff -Nru a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
--- a/arch/x86_64/Kconfig   2005-01-12 00:13:13.0 -0800
+++ b/arch/x86_64/Kconfig   2005-01-17 23:57:22.0 -0800
@@ -59,7 +59,7 @@
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized. For normal operation
  it is not recommended because it looks ugly and doesn't cooperate
- with klogd/syslogd or the X server. You should normally N here,
+ with klogd/syslogd or the X server. You should normally say N here,
  unless you want to debug such a crash.

 config HPET_TIMER
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Wait and retry mounting root device (revised)

[Andries Brouwer]

On Tue, Jan 18, 2005 at 02:54:24AM +, Daniel Drake wrote:

> Retry up to 20 times if mounting the root device fails.  This fixes booting
> from usb-storage devices, which no longer make their partitions immediately
> available.
> 
> This should allow booting from root=/dev/sda1 and root=8:1 style 
> parameters, whilst not breaking booting from RAID or initrd :)
> I have also cleaned up the mount_block_root() function a bit.

+   if (err == -EACCES && (flags | MS_RDONLY) == 0)
+   err = sys_mount(name, "/root", fs, flags | MS_RDONLY, data);
+

It is rather unlikely that (flags | MS_RDONLY) == 0 ...

I don't like the 20 - so arbitrary.
And since we are going to panic anyway, why not wait indefinitely?

Suppose we have kernel command line options
rootdev=, rootpttype=, root=, rootfstype=, rootwait=
telling the kernel what device is the root device,
what type of partition table it has,
on which partition the root filesystem lives,
what type of filesystem it has,
and whether we want to wait until it becomes available instead of panicking.

If we wait, possibly after the first failure to mount, do a printk
to tell the user: waiting for device to become available.

rootwait can have several values: for example, with a boot/root floppy combo,
we want the user to hit enter or so before accessing the device.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [request for inclusion] Realtime LSM

[Ingo Molnar]

* Jack O'Quin <[EMAIL PROTECTED]> wrote:

> In the absence of any documentation, I'm guessing about storing the
> nice value in the priority field of the sched_param struct.  But, I
> have not been able to figure out how to make that work.

the call you need is:

   setpriority(PRIO_PROCESS, tid, -20);

where 'tid' is the TID (pid) of the thread in question. There's no way i
know of to utilize the pthread_t ID to do this, so you'll have to figure
the TID out via gettid() - which needs to happen in the child context -
how hard would it be to attach the TID field to some per-thread Jack
structure? [while the purpose is still a quick hack.]

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Wait and retry mounting root device (revised)

[Andries Brouwer]

On Mon, Jan 17, 2005 at 04:02:15PM -0800, Randy.Dunlap wrote:
> Al Viro wrote:
> >On Tue, Jan 18, 2005 at 02:54:24AM +, Daniel Drake wrote:
> >
> >>Retry up to 20 times if mounting the root device fails.  This fixes 
> >>booting
> >>from usb-storage devices, which no longer make their partitions 
> >>immediately
> >>available.
> >
> >
> >Sigh...  So we can very well get device coming up in the middle of a loop
> >and get the actual attempts to mount the sucker in wrong order.  How 
> >nice...
> >
> >Folks, that's not a solution.  And kludges like that really have no
> >business being there - they only hide the problem and make it harder
> >to reproduce.
> 
> Is there a solution other than initrd/initramfs ?

On the one hand, I entirely agree with Al - this guessing business
is a bad kludge, and building complications on top of it makes
things worse.

On the other hand, we do already have the rootfstype= option,
so one can avoid trying things in the "wrong" order.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Wait and retry mounting root device (revised)

[Helge Hafting]

Randy.Dunlap wrote:
Al Viro wrote:
On Tue, Jan 18, 2005 at 02:54:24AM +, Daniel Drake wrote:
Retry up to 20 times if mounting the root device fails.  This fixes 
booting
from usb-storage devices, which no longer make their partitions 
immediately
available.

Sigh...  So we can very well get device coming up in the middle of a 
loop
and get the actual attempts to mount the sucker in wrong order.  How 
nice...

Folks, that's not a solution.  And kludges like that really have no
business being there - they only hide the problem and make it harder
to reproduce.

Is there a solution other than initrd/initramfs ?
There is a solution that seems obvious to me, so obvious that it ought to
be the first solution to try.  And it is guaranteed to not mess up raid 
or anything
else too.  So perhaps there is something wrong with it, or someone would 
have done this
already?  Here it is:

Apparently, USB devices doesn't appear immediately (after powerup?  after
USB bus initialization?)  We know this - therefore the USB block driver 
should know this.
The USB block driver should know that 10s (or whatever) hasn't yet 
passed, and simply
block any attempt to access block devices (or scan for them) knowing 
that it will
not work yet, but any device will be there after the pause. A root mount 
on USB will
then succeed at the _first_ try everytime, so no need for retries.

This solution is guaranteed to not mess up raid or anything else, 
because the fix is done
in the driver for the "odd" devices, not in the upper layer trying to 
use the device as a
root fs.

Surely someone must have thought of this before - is there any reason 
why this
won't work well?

The only thing I can think of is that partition scanning will cause a delay
on every system with USB block devices compiled-in, but this could be
postponed when root isn't on usb.
Partition scanning is moving to "early userspace" anyway, isn't it?  In 
the meantime,
people without USB root that don't want a bootup delay can use modular 
usb and load
the module later in some boot script.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Mon, Jan 17, 2005 at 05:46:35PM -0200, Marcelo Tosatti wrote:
> On Sun, Jan 16, 2005 at 12:35:30AM +0100, Mario Holbe wrote:
> > Could somebody please explain this to me? Is this intentional?
> No

Thanks :)

> Can you please turn readahead off (hdparm -a 0 /dev/hdg) and repeat the tests?
> The kernel is trying to read one block after EOD.

The same happens.

[EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null
9992366+0 records in
9992366+0 records out
5116091392 bytes transferred in 117,573365 seconds (43514034 bytes/sec)
[EMAIL PROTECTED]:~# hdparm -a 0 /dev/hdg

/dev/hdg:
 setting fs readahead to 0
 readahead=  0 (off)
[EMAIL PROTECTED]:~# mount -t ext3 -o ro /dev/hdg7 /mnt
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
[EMAIL PROTECTED]:~# umount /dev/hdg7
[EMAIL PROTECTED]:~# hdparm -a 0 /dev/hdg

/dev/hdg:
 setting fs readahead to 0
 readahead=  0 (off)
[EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null
attempt to access beyond end of device
22:07: rw=0, want=4996184, limit=4996183
dd: reading `/dev/hdg7': Input/output error
9992360+0 records in
9992360+0 records out
5116088320 bytes transferred in 100,455251 seconds (50929028 bytes/sec)
[EMAIL PROTECTED]:~#

> So maybe an off-by-one read-ahead?

Please also note dd's output: 9992366 vs. 9992360 records.

[EMAIL PROTECTED]:~# cat /proc/partitions
...
  34 74996183 hdg7 156620 6088613 19984760 368240 3 0 24 0 0 190720 
368240
...
[EMAIL PROTECTED]:~# bc
4996183 * 2
9992366
[EMAIL PROTECTED]:~# tune2fs -l /dev/hdg7
...
Block count:  1249045
...
[EMAIL PROTECTED]:~# bc
4096 * 1249045 / 512
9992360

The block device (the partition) is 4996183 kB or 9992366 sectors,
while the ext3 fs is 9992360 sectors. Exactly these 9992360 sectors
could be read by dd in the second pass.

[EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null bs=512
attempt to access beyond end of device
22:07: rw=0, want=4996184, limit=4996183
dd: reading `/dev/hdg7': Input/output error
9992360+0 records in
9992360+0 records out
5116088320 bytes transferred in 92,603241 seconds (55247400 bytes/sec)
[EMAIL PROTECTED]:~#

Fixing dd's blocksize to 512 doesn't help either.

> Also I suggest a dump_stack() to see where the read is coming
> from.

I have no idea, how and where to do a dump_stack().


regards
   Mario
-- 
() Ascii Ribbon Campaign
/\ Support plain text e-mail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Typo in arch/x86_64/Kconfig

[Andi Kleen]

vlobanov <[EMAIL PROTECTED]> writes:

> diff -Nru a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
> --- a/arch/x86_64/Kconfig 2005-01-12 00:13:13.0 -0800
> +++ b/arch/x86_64/Kconfig 2005-01-17 23:57:22.0 -0800
> @@ -59,7 +59,7 @@
> This is useful for kernel debugging when your machine crashes very
> early before the console code is initialized. For normal operation
> it is not recommended because it looks ugly and doesn't cooperate
> -   with klogd/syslogd or the X server. You should normally N here,
> +   with klogd/syslogd or the X server. You should normally say N here,
> unless you want to debug such a crash.

The help text is useless anyways because the option is not user selectable,
but always enabled. I just removed it completely. Thanks

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4 scheduler with O(1) scheduler

[selvakumar nagendran]

Hello linux-experts,
   From which kernel series onwards O(1) scheduler was
incorporated into linux? I want a 2.4.x kernel with
O(1) scheduler. But I downloaded 2.4.28 scheduler from
kernel.org. It was the latest one in the list in the
2.4.x series. But it misses O(1) scheduler. Where can
I get a 2.4.x kernel with O(1) scheduler?
I am intercepting syscalls in 2.4 kernel. But it
misses O(1) scheduler. so, for intercepting syscalls
and to achieve high performance I need 2.4 kernel with
O(1) scheduler.

Thanks,
selva



__ 
Do you Yahoo!? 
Yahoo! Mail - 250MB free storage. Do more. Manage less. 
http://info.mail.yahoo.com/mail_250
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: vgacon fixes to help font restauration in X11

[Egbert Eich]

Alan Cox writes:
 > On Llu, 2005-01-17 at 14:29, Egbert Eich wrote:
 > > OK, sounds promising. The changed Xserver pieces are in HEAD of the 
 > > X.Org tree. I'll see that I make the necessary adjustments to have
 > > a soft detection if you can give me a version number of the kernel
 > > which will have the new features.
 > 
 > Send a copy directly to [EMAIL PROTECTED] and [EMAIL PROTECTED] for merging.
 > It looks fine to me. You'll need to include a "Signed-off-by: .." line
 > to indicate you are submitting it and have the rights to do so. You can
 > tag it with "Approved-by: Alan Cox <[EMAIL PROTECTED]>".

Thanks, I will do that.
I have attached the patch for kernel version detection to the 
freedesktop.org bugzilla (#2277) assuming this feature will be
in the kernel starting with version 2.6.11.

 > 
 > If you mention you need to know what kernel merges it for the X11 check
 > I'm sure you'll get an answer.
 > 

OK, will do.

Thanks!
Egbert.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IBM Patents

[Bernhard Schauer]

> And almost all of them are pure software-patents and probably prior art.
> Thus they are - at least in Europe - not relevant and actually illegal
> if you believe in the current European patent law as defined by the
> European Patent Convention (see Â52(2) for details).

Hopefully nothing will change in future! Except the European Patent
Office should stop to give away software patents (even if they have no
legal basis).

regards

Bernhard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Instrumentation (was Re: 2.6.11-rc1-mm1)

[Thomas Gleixner]

On Mon, 2005-01-17 at 18:57 -0500, Karim Yaghmour wrote: 
> Thomas Gleixner wrote:
> > If we add another hardwired implementation then we do not have said
> > benefits.
> 
> Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
> and others actually made specific requests for changes in the code.
> What makes you think you're so special that you think you are
> entitled to stay on the side and handwave about concepts.

So the points you added to your todo list which were brought up by me
are worthless ?

I'm not handwaving. I started this RFC to move the discussion into a
general discussion about instrumentation. A couple of people are
seriosly interested to do this. If you are not interested then ignore
the thread, but you're way not in a position to tell me to shut up.

You turned this thread into your LTT prayer wheel.

Roman pointed out your unwillingness to create a common framework
before. But I have to disagree with him in one point. It's not amazing,
it's annoying.

> If there is a limitation with the code, please present actual
> snippets that need to be changed and suggest alternatives. That's
> what everyone else does on this list.

I pointed you to actually broken code and you accused me of throwing
mud.

> Save the bandwidth 

Please remove me from cc, it's a good start to save bandwidth.

> and start cleaning.

Yes, I did already start cleaning

cat ../broken-out/ltt* | patch -p1 -R

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86-64: int3 no longer causes SIGTRAP in 2.6.10

[Prasanna S Panchamukhi]

On Tue, Jan 18, 2005 at 02:47:08AM +0100, Andi Kleen wrote:
> Juho Snellman <[EMAIL PROTECTED]> writes:
> 
> > 2.6.10 changed the behaviour of the int3 instruction on x86-64. It
> > used to result in a SIGTRAP, now it's a SIGSEGV in both native and
> > 32-bit legacy modes. This was apparently caused by the kprobe port,
> > specifically this part:
> >
> > --- a/arch/x86_64/kernel/traps.c2004-12-24 13:36:17 -08:00
> > +++ b/arch/x86_64/kernel/traps.c2004-12-24 13:36:17 -08:00
> > @@ -862,8 +910,8 @@
> > set_intr_gate(0,÷_error);
> > set_intr_gate_ist(1,&debug,DEBUG_STACK);
> > set_intr_gate_ist(2,&nmi,NMI_STACK);
> > -   set_system_gate(3,&int3);   /* int3-5 can be called from all */
> > -   set_system_gate(4,&overflow);
> > +   set_intr_gate(3,&int3);
> > +   set_system_gate(4,&overflow);   /* int4-5 can be called from all */
> >
> > Was effectively disabling int3 a conscious decision, or just an
> > unintended side-effect? This breaks at least Steel Bank Common Lisp
> 
> It's a bug. Thanks for the report.
> 
> I'm not sure why it was even changed. Prasanna? 
> 
> I think it should be just changed back. If kprobes cannot 
> deal with traps for user space it needs to be fixed. e.g.
> by adding a user space check in kprobe_handler().
> 
Yes its a bug, we turn trap 3 into interrupt gates to ensure that it is not 
preemtable.

Thanks
Prasanna
> -Andi
> 
> Like this patch.
> 
> Index: linux/arch/x86_64/kernel/traps.c
> ===
> --- linux.orig/arch/x86_64/kernel/traps.c 2005-01-17 10:34:24.%N +0100
> +++ linux/arch/x86_64/kernel/traps.c  2005-01-18 02:42:02.%N +0100
> @@ -908,7 +908,7 @@
>   set_intr_gate(0,÷_error);
>   set_intr_gate_ist(1,&debug,DEBUG_STACK);
>   set_intr_gate_ist(2,&nmi,NMI_STACK);
> - set_intr_gate(3,&int3);
> + set_system_gate(3,&int3);
>   set_system_gate(4,&overflow);   /* int4-5 can be called from all */
>   set_system_gate(5,&bounds);
>   set_intr_gate(6,&invalid_op);
> Index: linux/arch/x86_64/kernel/kprobes.c
> ===
> --- linux.orig/arch/x86_64/kernel/kprobes.c   2005-01-04 12:12:39.%N +0100
> +++ linux/arch/x86_64/kernel/kprobes.c2005-01-18 02:46:05.%N +0100
> @@ -297,6 +297,8 @@
>   struct die_args *args = (struct die_args *)data;
>   switch (val) {
>   case DIE_INT3:
> + if (args->regs->cs & 3)
> + return NOTIFY_DONE;
>   if (kprobe_handler(args->regs))
>   return NOTIFY_STOP;
>   break;
> 
> 

-- 
Have a Nice Day!

Thanks & Regards
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Wait and retry mounting root device (revised)

[Andrew Morton]

Helge Hafting <[EMAIL PROTECTED]> wrote:
>
> The USB block driver should know that 10s (or whatever) hasn't yet 
>  passed, and simply
>  block any attempt to access block devices (or scan for them) knowing 
>  that it will
>  not work yet, but any device will be there after the pause. A root mount 
>  on USB will
>  then succeed at the _first_ try everytime, so no need for retries.

Maybe a simple delay somewhere in the boot sequence would suffice?  Boot
with `mount_delay=10'.

But it sure would be nice to simply get this stuff right somehow.  If the
USB block driver knows that discovery is still in progress it should wait
until it has completed.  (I suggested that before, but wasn't 100% convinced
by the answer).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: brought up 4 cpu's

[Mark Watts]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> > Thats your answer then. HyperThreading makes one cpu act as two (with a
> > suitable performance increase for some workloads)
>
> This doesn't explain why it stopped booting on his computer...

I guess he doesn't have the right workload for the performace increase 
then... ;)

Always the details...

Mark.

- -- 
Mark Watts
Senior Systems Engineer
QinetiQ Trusted Information Management
Trusted Solutions and Services group
GPG Public Key ID: 455420ED

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB7M/dBn4EFUVUIO0RAjFSAKD1u8t9LdF8FMxH/Gq1H0uMiazqqACgmtUw
Sv3wL71jbhuj/3ckw/J54Tk=
=O8Z7
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Mysterious Lag With SATA Maxtor 250GB 7200RPM 16MB Cache Under Linux using NFSv3 UDP

[Manu Abraham]

omes wrote:
I suddenly couldn't send to the mailinglist any longer.. I'm going back to 
2.4.28 for now. My 4GB of RAM support was already turned off.. Good luck 
further. Here is my mail:

On Monday 17 January 2005 22:34, you wrote:
omes wrote:
I have the same problem as you. At least our problems are much alike. I
got two Western digital hard disks. One 120GB 7200RPM 2MB Cache IDE, and
one 80GB 7200 2MB Cache IDE. I get high loads when reading large files
for some time, as well as when copying from one partition to another. All
my partitions are in ext3, and i'm running 2.6.10.
I have a similar problem. I am running 2.6.9 on FC3 not the stock
kernel, but a vanilla kernel.
I have 3 NFS shares mounted on this 2.6.9 machine (ASUS P4C800 ICH5
motherboard with 1024 MB RAM and sk98lin gigabit LOM (non-functional
since thesk98lin driver broke apart) so i use an additional 3Com 3C59x
100 Mbps adapter, with a nvidia VGA adapter, but no nvidia modules but
only VESAFB at 1024x768.
This is the same series as i got P4C800/P4P800.. 

Gabriel worte this in an earlier post:
"The performance issues (below) where due to a strange bug in the kernel
VM triggered by the motherboard BIOS. This affects Asus P4P800
motherboards(-MX and -VM tested) with more that 1 GB RAM. The built-in
I have exactly 1GB.
VGA can use 1-32 MB RAM for display but configured with less than 16 MB
of video RAM the board will behave EXTREMELY poor in linux (2.6.9 also
tested to behave like this).
I don't have 4GB support, nor do i have shared VGA. I have a nvidia(64M 
onboard, not shared) card using vesafb.
No X either.

There are several ways around this problem, I've just configured the
board with 16 MB of video RAM. Disabling support for 4 GB of RAM works
too but more memory is lost this way. Running FreeBSD is also an option
but we don't like that, don't we ? Memtest86 (1.11) doesn't seems
affected either - but it detects the memory as "single channel" while
memory is installed in dual channel configuration (also confirmed by BIOS).
If anybody knows what's going on please let me know. Loosing 15 MB of
RAM is not a big deal but I like linux bug-free, fast and stable.
I'm available to give more details or run some tests if anyone cares.
Regards,
Gabriel" (adapted)
As for the LOM, use this driver comes with the kernel: Device Drivers -> 
Networking support -> Ethernet (1000 Mbit) -> Marvell Yukon Chipset / 
SysKonnect SK-98xx Support

It was broken when i tried it out on 2.6.7 i think, and i stumbled upon 
the a post stating about incorrect VPD entries.. So i thought i would 
wait for things to cool down a bit.

Manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: x86-64: int3 no longer causes SIGTRAP in 2.6.10

[Andi Kleen]

> Yes its a bug, we turn trap 3 into interrupt gates to ensure that it is not 
> preemtable.

Is the patch ok for you?

-Andi

> > Like this patch.
> > 
> > Index: linux/arch/x86_64/kernel/traps.c
> > ===
> > --- linux.orig/arch/x86_64/kernel/traps.c   2005-01-17 10:34:24.%N +0100
> > +++ linux/arch/x86_64/kernel/traps.c2005-01-18 02:42:02.%N +0100
> > @@ -908,7 +908,7 @@
> > set_intr_gate(0,÷_error);
> > set_intr_gate_ist(1,&debug,DEBUG_STACK);
> > set_intr_gate_ist(2,&nmi,NMI_STACK);
> > -   set_intr_gate(3,&int3);
> > +   set_system_gate(3,&int3);
> > set_system_gate(4,&overflow);   /* int4-5 can be called from all */
> > set_system_gate(5,&bounds);
> > set_intr_gate(6,&invalid_op);
> > Index: linux/arch/x86_64/kernel/kprobes.c
> > ===
> > --- linux.orig/arch/x86_64/kernel/kprobes.c 2005-01-04 12:12:39.%N +0100
> > +++ linux/arch/x86_64/kernel/kprobes.c  2005-01-18 02:46:05.%N +0100
> > @@ -297,6 +297,8 @@
> > struct die_args *args = (struct die_args *)data;
> > switch (val) {
> > case DIE_INT3:
> > +   if (args->regs->cs & 3)
> > +   return NOTIFY_DONE;
> > if (kprobe_handler(args->regs))
> > return NOTIFY_STOP;
> > break;
> > 
> > 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Внж в Черногорье

[68cernis]

[cyrlat]

СТАБИЛЬНОСТЬ МОЖНО КУПИТЬ

Если у Вас, уже есть Второе гражданство, ВНЖ или ПМЖ в Европе, значит Вы уже 
подумали о гарантии спокойствия, безвизовом перемещении, льготном 
налогообложении и будущем ваших детей или просто напросто о запасном аэродроме.

Если Вы, еще не успели позаботится об этом, наша компания будет рада предложить 
Вам:

- программы быстрого получения ВНЖ в странах Европы
[Чехия, Черногория, Словакия, Болгария]
- регистрация компаний в Европе, предоставление услуг полного бухгалтерского 
сопровождения, номинальных директоров и учредителей.
- подбор объектов недвижимости и готового бизнеса с полным юридическим 
сопровождением
- программы получения ПМЖ
- программы получения второго Гражданства

Наши координаты:

E-mail: [EMAIL PROTECTED]  Tel: +420776074699,
Czech Republic Prague 1 Vaclavske nam. 37 CERNIS s.r.o.

Your mail is linux-kernel@vger.kernel.org

[/cyrlat]b6 get ready

RE: 2.4 scheduler with O(1) scheduler

[Massimo Cetra]

> Hello linux-experts,
>From which kernel series onwards O(1) scheduler was 
> incorporated into linux? I want a 2.4.x kernel with
> O(1) scheduler. But I downloaded 2.4.28 scheduler from 
> kernel.org. It was the latest one in the list in the 2.4.x 
> series. But it misses O(1) scheduler. Where can I get a 2.4.x 
> kernel with O(1) scheduler?

This is what you need.
http://www.plumlocosoft.com/kernel/

MAx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] AC'97 Audio support for Intel ICH7 - 2.6.11-rc1

[Takashi Iwai]

At Mon, 17 Jan 2005 09:37:17 -0800,
Gaston, Jason D wrote:
> 
> ICH6 and ICH7 both have AC'97 modem DID's.
> 
> ICH6 AC'97 modem DID = 266d
> ICH7 AC'97 modem DID = 27dd
> 
> Would you like me to create a patch adding both?

Not necessary, the patch would be easy to me, too :)

But, I'd like to confirm that the driver really works on these
chipsets before adding the IDs.


thanks,

Takashi

> Thanks,
> 
> Jason
> 
> 
> 
> >-Original Message-
> >From: Takashi Iwai [mailto:[EMAIL PROTECTED]
> >Sent: Monday, January 17, 2005 3:31 AM
> >To: Gaston, Jason D
> >Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
> >Subject: Re: [PATCH] AC'97 Audio support for Intel ICH7 - 2.6.11-rc1
> >
> >At Fri, 14 Jan 2005 11:21:34 -0800,
> >Jason Gaston wrote:
> >>
> >> This patch adds the ICH7 AC'97 DID the the intel8x0.c AC'97 audio driver.
> > This patch was build against 2.6.11-rc1.
> >> If acceptable, please apply.
> >>
> >> Thanks,
> >>
> >> Jason Gaston
> >>
> >> Signed-off-by:  Jason Gaston <[EMAIL PROTECTED]>
> >
> >Thanks, I applied the patch to ALSA tree.
> >
> >Does ICH7 have an ac97 modem, too?
> >If so, we miss the DID in the modem driver, too.
> >(Well, the entry for ICH6 is also missing.  Anyone can confirm such a
> > device?)
> >
> >
> >Takashi
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Support compat_ioctl for block devices

[Christoph Hellwig]

> +long compat_blkdev_ioctl(struct file *file, unsigned cmd, unsigned long arg)
> +{
> + struct block_device *bdev = file->f_dentry->d_inode->i_bdev;
> + struct gendisk *disk = bdev->bd_disk;
> + int ret = -ENOIOCTLCMD;
> + if (disk->fops->compat_ioctl) {
> + lock_kernel();
> + ret = disk->fops->compat_ioctl(file, cmd, arg);
> + unlock_kernel();
> + }
> + return ret;
> +}

 - please don't introduce a new API with the BKL held.
 - prototype isn't nice.  just passing the gendisk for block_device
   should be enough.

also this wants documentation in Documentation/filesystems/Locking
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IBM Patents

[Bernd Petrovitsch]

On Tue, 2005-01-18 at 09:37 +0100, Bernhard Schauer wrote:
> > And almost all of them are pure software-patents and probably prior art.
> > Thus they are - at least in Europe - not relevant and actually illegal
> > if you believe in the current European patent law as defined by the
> > European Patent Convention (see §52(2) for details).
> 
> Hopefully nothing will change in future! Except the European Patent

In terms of above statement, yes. It actually needs means to seriously
control the EPO and national POs - there absolutely no independent
justice (similar to other democratic systems) there.
Nevertheless the evil propaganda was working since years to get the
decision makers (read: law and politics folks with (almost) no knowledge
of "programming", "software" and/or copyright/author's rights) to
believe in "monopolies on ideas are good for small companies".
And there are other forces pushing in that direction but without prove
I won't speak about it 

> Office should stop to give away software patents (even if they have no
> legal basis).

>From a juristical point of view (and "they" are actually saying that)
they are "legal" (since they are granted) - even there are severe
concerns (read: there are not fulfilled in any way) about the
preconditions.
However the POs get more money from granted patents than from not
granted ones (for actually less work - for the patent proving person it
is more work to seriously explain a declined patent instead of - more or
less - simply accepting it) and the POs have absolutely no risk. Guess
what will happen .

Bernd, stopping now since it is quite off-topic here
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Support compat_ioctl for block devices

[Andi Kleen]

On Tue, Jan 18, 2005 at 09:19:27AM +, Christoph Hellwig wrote:
> > +long compat_blkdev_ioctl(struct file *file, unsigned cmd, unsigned long 
> > arg)
> > +{
> > +   struct block_device *bdev = file->f_dentry->d_inode->i_bdev;
> > +   struct gendisk *disk = bdev->bd_disk;
> > +   int ret = -ENOIOCTLCMD;
> > +   if (disk->fops->compat_ioctl) {
> > +   lock_kernel();
> > +   ret = disk->fops->compat_ioctl(file, cmd, arg);
> > +   unlock_kernel();
> > +   }
> > +   return ret;
> > +}
> 
>  - please don't introduce a new API with the BKL held.

Nope, I'm not going to audit zillions of low level functions for this.

>  - prototype isn't nice.  just passing the gendisk for block_device
>should be enough.

No, it isn't, the compat handler needs cmd and arg, and file is useful
when you pass it to an existing ioctl handler.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Support compat_ioctl for block devices

[Christoph Hellwig]

On Tue, Jan 18, 2005 at 10:31:58AM +0100, Andi Kleen wrote:
> >  - please don't introduce a new API with the BKL held.
> 
> Nope, I'm not going to audit zillions of low level functions for this.

So just stick a lock_kernel() unlock_kernel() into the handler, it's
not like there's more than a handfull of them.

> >  - prototype isn't nice.  just passing the gendisk for block_device
> >should be enough.
> 
> No, it isn't, the compat handler needs cmd and arg, and file is useful
> when you pass it to an existing ioctl handler.

cmd/arg is needed, file shouldn't.  If you care for the underlying handler
add a version that doesn't take the file * either.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] input: make some code static

[Adrian Bunk]

This patch makes some needlessly global code static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

diffstat output:
 drivers/input/evbug.c   |4 ++--
 drivers/input/gameport/emu10k1-gp.c |4 ++--
 drivers/input/gameport/fm801-gp.c   |4 ++--
 drivers/input/gameport/lightning.c  |4 ++--
 drivers/input/gameport/ns558.c  |4 ++--
 drivers/input/gameport/vortex.c |4 ++--
 drivers/input/input.c   |2 +-
 drivers/input/joystick/a3d.c|   10 +-
 drivers/input/joystick/adi.c|4 ++--
 drivers/input/joystick/analog.c |6 +++---
 drivers/input/joystick/cobra.c  |4 ++--
 drivers/input/joystick/db9.c|4 ++--
 drivers/input/joystick/gamecon.c|4 ++--
 drivers/input/joystick/gf2k.c   |4 ++--
 drivers/input/joystick/grip.c   |4 ++--
 drivers/input/joystick/guillemot.c  |4 ++--
 drivers/input/joystick/interact.c   |4 ++--
 drivers/input/joystick/magellan.c   |4 ++--
 drivers/input/joystick/sidewinder.c |4 ++--
 drivers/input/joystick/spaceball.c  |4 ++--
 drivers/input/joystick/spaceorb.c   |4 ++--
 drivers/input/joystick/stinger.c|4 ++--
 drivers/input/joystick/tmdc.c   |4 ++--
 drivers/input/joystick/turbografx.c |6 +++---
 drivers/input/joystick/warrior.c|4 ++--
 drivers/input/keyboard/atkbd.c  |4 ++--
 drivers/input/keyboard/lkkbd.c  |4 ++--
 drivers/input/keyboard/newtonkbd.c  |   12 ++--
 drivers/input/keyboard/sunkbd.c |4 ++--
 drivers/input/keyboard/xtkbd.c  |   12 ++--
 drivers/input/misc/uinput.c |2 +-
 drivers/input/mouse/alps.c  |4 ++--
 drivers/input/mouse/psmouse-base.c  |4 ++--
 drivers/input/mouse/sermouse.c  |4 ++--
 drivers/input/mouse/vsxxxaa.c   |4 ++--
 drivers/input/mousedev.c|2 +-
 drivers/input/serio/ct82c710.c  |4 ++--
 drivers/input/serio/parkbd.c|4 ++--
 drivers/input/serio/serio.c |2 +-
 drivers/input/serio/serio_raw.c |6 +++---
 drivers/input/touchscreen/gunze.c   |4 ++--
 drivers/input/tsdev.c   |2 +-
 drivers/input/misc/pcspkr.c |2 +-
 drivers/input/serio/i8042.c |   10 +-
 44 files changed, 99 insertions(+), 99 deletions(-)


--- linux-2.6.10-rc1-mm3-full/drivers/input/evbug.c.old 2004-11-07 
03:34:41.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/input/evbug.c 2004-11-07 
03:35:01.0 +0100
@@ -88,13 +88,13 @@
.id_table = evbug_ids,
 };
 
-int __init evbug_init(void)
+static int __init evbug_init(void)
 {
input_register_handler(&evbug_handler);
return 0;
 }
 
-void __exit evbug_exit(void)
+static void __exit evbug_exit(void)
 {
input_unregister_handler(&evbug_handler);
 }
--- linux-2.6.10-rc1-mm3-full/drivers/input/gameport/emu10k1-gp.c.old   
2004-11-07 03:35:11.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/input/gameport/emu10k1-gp.c   
2004-11-07 03:35:23.0 +0100
@@ -118,12 +118,12 @@
 .remove =   __devexit_p(emu_remove),
 };
 
-int __init emu_init(void)
+static int __init emu_init(void)
 {
return pci_module_init(&emu_driver);
 }
 
-void __exit emu_exit(void)
+static void __exit emu_exit(void)
 {
pci_unregister_driver(&emu_driver);
 }
--- linux-2.6.10-rc1-mm3-full/drivers/input/gameport/fm801-gp.c.old 
2004-11-07 03:35:52.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/input/gameport/fm801-gp.c 2004-11-07 
03:36:05.0 +0100
@@ -143,12 +143,12 @@
.remove =   __devexit_p(fm801_gp_remove),
 };
 
-int __init fm801_gp_init(void)
+static int __init fm801_gp_init(void)
 {
return pci_module_init(&fm801_gp_driver);
 }
 
-void __exit fm801_gp_exit(void)
+static void __exit fm801_gp_exit(void)
 {
pci_unregister_driver(&fm801_gp_driver);
 }
--- linux-2.6.10-rc1-mm3-full/drivers/input/gameport/lightning.c.old
2004-11-07 03:37:40.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/input/gameport/lightning.c
2004-11-07 03:37:56.0 +0100
@@ -53,13 +53,13 @@
 MODULE_DESCRIPTION("PDPI Lightning 4 gamecard driver");
 MODULE_LICENSE("GPL");
 
-struct l4 {
+static struct l4 {
struct gameport gameport;
unsigned char port;
char phys[32];
 } *l4_port[8];
 
-char l4_name[] = "PDPI Lightning 4";
+static char l4_name[] = "PDPI Lightning 4";
 
 /*
  * l4_wait_ready() waits for the L4 to become ready.
--- linux-2.6.10-rc1-mm3-full/drivers/input/gameport/ns558.c.old
2004-11-07 03:38:06.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/input/gameport/ns558.c2004-11-07 
03:38:23.0 +0100
@@ -261,7 +261,7 @@
 
 #endif
 
-int __init ns558_init(void)
+static int __init ns558_init(void)
 {
int i = 0;
 
@@ -276,7 +276,7 @@
return list_empty(&ns558_list) ? -ENODEV : 0;
 }
 
-void __exit ns558_exit(void)
+static void __exit n

[2.6 patch] drivers/block/umem.c: make two functions static

[Adrian Bunk]

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

diffstat output:
 drivers/block/umem.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

This patch was already sent on:
- 29 Nov 2004

--- linux-2.6.10-rc1-mm3-full/drivers/block/umem.c.old  2004-11-06 
20:19:51.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/block/umem.c  2004-11-06 
20:20:16.0 +0100
@@ -1181,7 +1181,7 @@
 
---
 */
 
-int __init mm_init(void)
+static int __init mm_init(void)
 {
int retval, i;
int err;
@@ -1232,7 +1232,7 @@
 -- mm_cleanup
 
---
 */
-void __exit mm_cleanup(void)
+static void __exit mm_cleanup(void)
 {
int i;
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/block/xd.c: make a variable static

[Adrian Bunk]

This patch makes a needlessly global variable static.


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>


---

This patch was already sent on:
- 29 Nov 2004

--- linux-2.6.10-rc1-mm3-full/drivers/block/xd.c.old2004-11-06 
20:20:25.0 +0100
+++ linux-2.6.10-rc1-mm3-full/drivers/block/xd.c2004-11-06 
20:21:01.0 +0100
@@ -67,7 +67,7 @@
 /* Above may need to be increased if a problem with the 2nd drive detection
(ST11M controller) or resetting a controller (WD) appears */
 
-XD_INFO xd_info[XD_MAXDRIVES];
+static XD_INFO xd_info[XD_MAXDRIVES];
 
 /* If you try this driver and find that your card is not detected by the 
driver at bootup, you need to add your BIOS
signature and details to the following list of signatures. A BIOS signature 
is a string embedded into the first

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announce loop-AES-v3.0b file/swap crypto package

[jerome etienne]

Hello,
i dont understand the current argument so would prefere not to enter it. 
But it triggered my curiosity about current loop-aes security.
3 years ago i published a paper describing how an attacker would be able 
to modify the content of the encrypted device without being detected.
http://off.net/~jme/loopdev_vul.html

i was just curious about the current state of loop-aes. Is it still 
vulnerable to this attack ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Support compat_ioctl for block devices

[Andi Kleen]

On Tue, Jan 18, 2005 at 09:36:45AM +, Christoph Hellwig wrote:
> On Tue, Jan 18, 2005 at 10:31:58AM +0100, Andi Kleen wrote:
> > >  - please don't introduce a new API with the BKL held.
> > 
> > Nope, I'm not going to audit zillions of low level functions for this.
> 
> So just stick a lock_kernel() unlock_kernel() into the handler, it's
> not like there's more than a handfull of them.

Hmm, possible, although it tends to be quite ugly (requiring
either gotos or wrappers). But ok.

> 
> > >  - prototype isn't nice.  just passing the gendisk for block_device
> > >should be enough.
> > 
> > No, it isn't, the compat handler needs cmd and arg, and file is useful
> > when you pass it to an existing ioctl handler.
> 
> cmd/arg is needed, file shouldn't.  If you care for the underlying handler
> add a version that doesn't take the file * either.

Sorry, that didn't make any sense.  

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] unexport xfrm_policy_delete

[Adrian Bunk]

I haven't found any way how xfrm_policy_delete could be called from 
modular code in 2.6.11-rc1-mm1.

Unless I'm wrong or a patch for a modular usage is pending, I'm 
therefore suggesting this patch for removing the EXPORT_SYMBOL.


Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.11-rc1-mm1-full/net/xfrm/xfrm_policy.c.old2005-01-18 
11:11:34.0 +0100
+++ linux-2.6.11-rc1-mm1-full/net/xfrm/xfrm_policy.c2005-01-18 
11:11:39.0 +0100
@@ -549,8 +549,6 @@
}
 }
 
-EXPORT_SYMBOL(xfrm_policy_delete);
-
 int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
 {
struct xfrm_policy *old_pol;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Some fixes for compat ioctl

[Michael S. Tsirkin]

Hi, Andi!

Quoting r. Andi Kleen ([EMAIL PROTECTED]) "[PATCH] Some fixes for compat ioctl":
> 
> While doing some compat_ioctl conversions I noticed a few issues
> in compat_sys_ioctl:
> 
> - It is not completely compatible to old ->ioctl because 
> the traditional common ioctls are not checked before it.

How is this different from what we have for compat_sys_ioctl
in 2.6.10? Or is this an old bug?

> I added
> a check for those.

Cant we just add them to fs/compat_ioctl.c instead, and be done?

> The main advantage is that the handler 
> now works the same as a traditional handler even when it returns
> -EINVAL


We still need the conversion functions in fs/compat_ioctl.c, I
think. If that is true, for some devices the handler only almost works
if it returns -EINVAL, and maybe its best not to encourage this.
I have another idea: maybe, lets move the unlocked_ioctl handler up so
that it, too, is required to return -NOIOCTLCMD?
I would argue it also may improve ioctl performance by a small margin,
since it is the unlocked_ioctl/compat_ioctl that do the "real" work.

I plan to send, separately, a patch that does this.
Please comment.

> 
> - The private socket ioctl check should only apply for sockets.

Its an old issue, isnt it? And probably better split in a separate
patch?

> - There was a security hook missing.  Drawback is that it uses
> the same hook now, and the LSM module cannot distingush between
> 32bit and 64bit clients. But it'll have to live with that for now.

It seems it is still missing for compat_ioctl. No?
I am sending a patch to fix this separately.

MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] compat_ioctl call seems to miss a security hook

[Michael S. Tsirkin]

Attached patch is against 2.6.11-rc1-bk5

Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Add a missing security hook for compatibility ioctl.

diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
--- linux-2.6.10-orig/fs/compat.c   2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat.c  2005-01-18 10:54:26.289478440 +0200
@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
if (!filp)
goto out;
 
+   /* RED-PEN how should LSM module know it's handling 32bit? */
+   error = security_file_ioctl(filp, cmd, arg);
+   if (error)
+   goto out_fput;
+
if (filp->f_op && filp->f_op->compat_ioctl) {
error = filp->f_op->compat_ioctl(filp, cmd, arg);
if (error != -ENOIOCTLCMD)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] socket ioctl fix (from Andi)

[Michael S. Tsirkin]

Attached patch is against 2.6.11-rc1-bk5.
It is split out from Andi's big patch.
It is really unchanged so I dont put a signed-off-by here.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

SIOCDEVPRIVATE ioctl command only applies to socket descriptors.

diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
--- linux-2.6.10-orig/fs/compat.c   2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat.c  2005-01-18 10:54:26.289478440 +0200
@@ -454,7 +460,8 @@ asmlinkage long compat_sys_ioctl(unsigne
}
up_read(&ioctl32_sem);
 
-   if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
+   if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
+   cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
error = siocdevprivate_ioctl(fd, cmd, arg);
} else {
static int count;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] make common ioctls apply for compat.

[Michael S. Tsirkin]

Attached patch is against 2.6.11-rc1-bk5
A piece is copied from Andi's patch, too. No idea if
his SOB should be here too. Here it is just in case.

Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

Make common ioctls apply for compat_ioctl.

diff -rup linux-2.6.10-orig/fs/compat_ioctl.c 
linux-2.6.10-ioctl-sym/fs/compat_ioctl.c
--- linux-2.6.10-orig/fs/compat_ioctl.c 2004-12-24 23:36:01.0 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat_ioctl.c2005-01-18 10:54:31.736650344 
+0200
@@ -3165,6 +3165,14 @@ static int do_ncp_setprivatedata(unsigne
 #endif
 
 #ifdef DECLARES
+HANDLE_IOCTL(FIOCLEX,NULL)
+HANDLE_IOCTL(FIONCLEX,NULL)
+HANDLE_IOCTL(FIONBIO,NULL)
+HANDLE_IOCTL(FIOASYNC,NULL)
+HANDLE_IOCTL(FIOQSIZE,NULL)
+HANDLE_IOCTL(FIBMAP,NULL)
+HANDLE_IOCTL(FIGETBSZ,NULL)
+HANDLE_IOCTL(FIONREAD,NULL)
 HANDLE_IOCTL(MEMREADOOB32, mtd_rw_oob)
 HANDLE_IOCTL(MEMWRITEOOB32, mtd_rw_oob)
 #ifdef CONFIG_NET
diff -rup linux-2.6.10-orig/fs/ioctl.c linux-2.6.10-ioctl-sym/fs/ioctl.c
--- linux-2.6.10-orig/fs/ioctl.c2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/ioctl.c   2005-01-18 10:51:55.690372984 +0200
@@ -77,7 +72,10 @@ static int file_ioctl(struct file *filp,
return do_ioctl(filp, cmd, arg);
 }
 
-
+/*
+ * When you add any new common ioctls to the switches above and below
+ * please update compat_ioctl.c too.
+ */
 asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
 {
struct file * filp;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] socket ioctl fix (from Andi)

[Christoph Hellwig]

On Tue, Jan 18, 2005 at 12:48:16PM +0200, Michael S. Tsirkin wrote:
> Attached patch is against 2.6.11-rc1-bk5.
> It is split out from Andi's big patch.
> It is really unchanged so I dont put a signed-off-by here.
> 
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> 
> SIOCDEVPRIVATE ioctl command only applies to socket descriptors.
> 
> diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
> --- linux-2.6.10-orig/fs/compat.c 2005-01-18 10:58:33.609880024 +0200
> +++ linux-2.6.10-ioctl-sym/fs/compat.c2005-01-18 10:54:26.289478440 
> +0200
> @@ -454,7 +460,8 @@ asmlinkage long compat_sys_ioctl(unsigne
>   }
>   up_read(&ioctl32_sem);
>  
> - if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
> + if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
> + cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
>   error = siocdevprivate_ioctl(fd, cmd, arg);

Maybe this should move into a new sock_compat_ioctl() instead?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Andries Brouwer]

On Mon, Jan 17, 2005 at 05:46:35PM -0200, Marcelo Tosatti wrote:
> On Sun, Jan 16, 2005 at 12:35:30AM +0100, Mario Holbe wrote:

> > mounting an ext2 (ext3 as well) filesystem seems to modify the
> > block device's EOF behaviour: before the mount the device returned
> > EOF, after the mount it doesn't anymore:
> > 
> > [on a fresh booted system]
> > [EMAIL PROTECTED]:~# uname -a
> > Linux darkside 2.4.27 #1 Sat Jan 15 17:07:20 CET 2005 i686 GNU/Linux
> > [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null
> > 9992366+0 records in
> > 9992366+0 records out
> > [EMAIL PROTECTED]:~# mount -t ext2 -o ro /dev/hdg7 /mnt
> > [EMAIL PROTECTED]:~# umount /dev/hdg7
> > [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null
> > attempt to access beyond end of device
> > 22:07: rw=0, want=4996184, limit=4996183
> > dd: reading `/dev/hdg7': Input/output error
> > 9992360+0 records in
> > 9992360+0 records out
> > [EMAIL PROTECTED]:~# bc
> > 1249045 * 4
> > 4996180
> > 1249045 * 4 * 2
> > 9992360
> > 
> > Could somebody please explain this to me? Is this intentional?
> 
> No
> 
> Its indeed strange.

I suppose that what happens is the following:
mounting sets the blocksize to 4096.
After reading 9992360 sectors, reading the next block means reading
the next 8 sectors and that fails because only 6 sectors are left.

Test that this is what happens using blockdev --getbsz.

If you want to restore the device to full size, use
blockdev --setbsz 512.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] reminder comment about register_ioctl32_conversion

[Michael S. Tsirkin]

This is just a split off from Andi's patch, so I didnt add my SOB here.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

Since its too early to deprecate (un)register_ioctl32_conversion,
add a comment for that time when we do.

diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
--- linux-2.6.10-orig/fs/compat.c   2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat.c  2005-01-18 10:54:26.289478440 +0200
@@ -447,6 +452,7 @@ asmlinkage long compat_sys_ioctl(unsigne
(!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl))
goto do_ioctl;
 
+   /* When register_ioctl32_conversion is gone remove this lock! -AK */
down_read(&ioctl32_sem);
for (t = ioctl32_hash_table[ioctl32_hash(cmd)]; t; t = t->next) {
if (t->cmd == cmd)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to burn DVDs

[Michal Schmidt]

Bill Davidsen wrote:
Nick Sanders wrote:
For me when running growisofs  with user permissions on 2.6.10 (ide-cd) it 
works perfectly 1st time but 2nd time fails with the error below. It works 
fine when run as root.

:-( unable to PREVENT MEDIA REMOVAL: Operation not permitted
As an aside audio cd burning with cdrecord works as long as the '-text' option 
isn't used, if it is the process hangs.

I reported a similar thing with cdrecord, writing a first session 
successfully using the -multi flag, but not being able to append to it 
or read the size with the "-msinfo" flag. I was totally blown off and 
told I didn't have permissions on the device, even though I was able to 
write to it.

I believe the true answer is that the SCSI command filter is blocking a 
command needed to perform the operation, probably a command to lock the 
door of the drive. In my case I have permissions to write the CD, just 
not to read the info needed to write additional sessions.

Hello,
Bill and Nick, could you try the attached patch that I sent to Jens 
Axboe yesterday? (You can see the mail with an explanation on
http://marc.theaimsgroup.com/?l=linux-kernel&m=110599420505734&w=2 )

Michal
--- linux-2.6.11-mm1/drivers/block/scsi_ioctl.c.orig	2005-01-17 20:42:40.0 +0100
+++ linux-2.6.11-mm1/drivers/block/scsi_ioctl.c	2005-01-17 20:43:14.0 +0100
@@ -197,9 +197,7 @@ static int verify_command(struct file *f
 	if (type & CMD_WRITE_SAFE) {
 		if (file->f_mode & FMODE_WRITE)
 			return 0;
-	}
-
-	if (!(type & CMD_WARNED)) {
+	} else if (!(type & CMD_WARNED)) {
 		cmd_type[cmd[0]] = CMD_WARNED;
 		printk(KERN_WARNING "scsi: unknown opcode 0x%02x\n", cmd[0]);
 	}

Re: [PATCH 2/5] socket ioctl fix (from Andi)

[Andi Kleen]

> > -   if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
> > +   if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
> > +   cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
> > error = siocdevprivate_ioctl(fd, cmd, arg);
> 
> Maybe this should move into a new sock_compat_ioctl() instead?
> 

Seems like overkill for 3 lines of code.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IBM Patents

[James Bruce]

I believe that IBM is simply responding to the recent study that "Linux 
violates more than 283 patents".  Regardless of the truth to that study, 
this is IBM's way of stating that the 60 that they hold will not be used 
against Linux or other open source projects.

Bernd Petrovitsch wrote:
On Mon, 2005-01-17 at 08:44 -0500, linux-os wrote:
Tue Jan 11 07:07:40 EST 2005
IBM has announced that it will provide free access to about
500 of its existing software patents to users and groups
No, they only promise now to not sue anyone given the following
criteria. No one knows what happens in 5 years.
Yes we do "know what happens"; From the first page of IBM's pledge:
  "... the commitment not to assert any of these 500 U.S. patents and 
all counterparts of these patents issued in other countries is 
*irrevocable* except that IBM reserves the right to terminate this 
patent pledge and commitment only with regard to any party who files a 
lawsuit asserting patents or other intellectual property rights against 
Open Source Software." (emphasis added)

They also state that the pledge is intended to be "legally binding". 
So, unless you plan on suing an open source developer over intellectual 
property you should be fine.  That includes five years from now.  It 
could however, have negative effects on Jeff Merkey's plans to buy a 
copy of the kernel code.

They have ca. 4 AFAIK. So 500 is 1,25 %.
And IBM is actually lobbying for patents so this is only a marketing
thing.
I wouldn't expect them to change overnight.  Patents have made IBM (and 
many other companies) a lot of money.  The ones who's interests are not 
served by patents are citizens and small companies.  Not surprisingly, 
they are the ones fighting the EU initiative.  Thus everyone is doing 
what's in their best interests, which is hardly unexpected.  I am of 
course hoping that citizens' interests win out in the EU.

However, given the patent system already present in the US, IBM's action 
is a step in the right direction.  It strikes me as a lot like how 
Copyleft used copyright law to effect the opposite of the intended 
result.  While "no software patents" is desirable, if there is a way to 
work within the existing system to get some freedom back for developers, 
I don't think that's a bad thing.

working on open source software.
http://www.ibm.com/news/us/
Many of these patents relate to interoperability, communications,
file-export protocols, and dynamic linking.
And almost all of them are pure software-patents and probably prior art.
Thus they are - at least in Europe - not relevant and actually illegal
if you believe in the current European patent law as defined by the
European Patent Convention (see §52(2) for details).
I'm can't comment on every patent in the list, but many of the ones 
regarding image processing (my area of expertise) are novel enough under 
the current legal system to stand up in court.  Even if only 1 in 10 of 
the patents are valid in the overall list, those that remain represent 
new things that can now be released as open source, without fear of 
reprisal.  I for one hope this grows and other companies see the benefit 
of adding patents to the list.  Given that the EU will quite possibly 
get software patents within the next year, this could quickly become 
important for all of us.

 - Jim Bruce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] symmetry between compat_ioctl and unlocked_ioctl

[Michael S. Tsirkin]

Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Make unlocked_ioctl and compat_ioctl behave symmetrically -
check them first thing, and always require returning ENOIOCTLCMD
on error from unlocked_ioctl, same as we do for compat_ioctl.
This also makes it possible to override *all* ioctl commands, and
hopefully may enable some speed ups on the data path.

diff -rup linux-2.6.10-orig/fs/ioctl.c linux-2.6.10-ioctl-sym/fs/ioctl.c
--- linux-2.6.10-orig/fs/ioctl.c2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/ioctl.c   2005-01-18 10:51:55.690372984 +0200
@@ -24,12 +24,7 @@ static long do_ioctl(struct file *filp, 
if (!filp->f_op)
goto out;
 
-   if (filp->f_op->unlocked_ioctl) {
-   error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
-   if (error == -ENOIOCTLCMD)
-   error = -EINVAL;
-   goto out;
-   } else if (filp->f_op->ioctl) {
+   if (filp->f_op->ioctl) {
lock_kernel();
error = filp->f_op->ioctl(filp->f_dentry->d_inode,
  filp, cmd, arg);
@@ -93,6 +91,12 @@ asmlinkage long sys_ioctl(unsigned int f
if (error)
goto out_fput;
 
+   if (filp->f_op && filp->f_op->unlocked_ioctl) {
+   error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
+   if (error != -ENOIOCTLCMD)
+   goto out_fput;
+   }
+
switch (cmd) {
case FIOCLEX:
set_close_on_exec(fd, 1);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [discuss] booting a kernel compiled with -mregparm=0

[Tigran Aivazian]

On Mon, 17 Jan 2005, H. Peter Anvin wrote:
Or does kdb not have a client at all?  (If so, I have no sympathy for it.)
Peter, it was very easy for you to call my emails "rants" and "not even 
funny" but the above statement is displaying complete ignorance of what 
kdb actually is :) So, instead of "patronizing" your fellow-hacker, please 
listen to what he has to say below:

I already solved this paricular problem. And the solution is (but don't 
tell me you knew it, for then why didn't you tell anyone) simply --- 
compile the kernel with -g and that includes enough debug information to 
be able to decode the stack content correctly. And yes, kdb does show the 
correct argument values now. No changes to kdb are necessary and no need 
to do the work with dwarf2 implementation etc etc.

However, this highlighted a more serious problem in the x86_64 kernel (or 
more likely in the kdb patch) --- the kernel compiled with -g panics when 
you try to return from kdb after hitting a breakpoint. This is a bug and 
I'll investigate to find out the reason why it panics. (I hope it is not 
an "assumption" of the x86_64 port that one must never compile the kernel 
with -g either...)

Kind regards
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IBM Patents

[Chris Lingard]

On Tuesday 18 January 2005 11:04, James Bruce wrote:
> I believe that IBM is simply responding to the recent study that "Linux
> violates more than 283 patents".  Regardless of the truth to that study,

The study said that it may violate patents; but that those patents may
not be enforceable due to prior art. Only a court of law; and only in
the USA could your statment be tested. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc1-mm1

[Masami Hiramatsu]

Hello,
I’m a developer of yet another kernel tracer, LKST. I and co-developers 
are very glad to hear that LTT was merged into -mm tree and to talk 
about the kernel tracer on this ML. Because we think that the kernel 
event tracer is useful to debug Linux systems, and to improve the kernel 
reliability.

Andi Kleen wrote:
Andrew Morton <[EMAIL PROTECTED]> writes:
- Added the Linux Trace Toolkit (and hence relayfs).  Mainly because I
 haven't yet taken as close a look at LTT as I should have.  Probably neither
 have you.

I think it would be better to have a standard set of kprobes instead
of all the ugly LTT hooks. kprobes could then log to relayfs or another
fast logging mechanism.
I agree.
I’m interested in kprobes. Currently, LKST can switch off and on each 
hook. But, even if a hook was disabled, there is a little overhead-time 
(one conditional-jump instruction should be executed). I think 
kprobes-based hooks can completely remove this overhead-time. Moreover, 
kprobes-based hooks can be inserted dynamically into the code-point 
specified by user. This feature is greatly useful for debugging. So, I 
have an idea to renew LKST to kprobes-based hooks.
Also, I’m developing a prototype implementation.


The problem relayfs has IMHO is that it is too complicated. It 
seems to either suffer from a overfull specification or second system
effect. There are lots of different options to do everything,
instead of a nice simple fast path that does one thing efficiently.
IMHO before merging it should go through a diet and only keep
the paths that are actually needed and dropping a lot of the current
baggage.

Preferably that would be only the fastest options (extremly simple
per CPU buffer with inlined fast path that drop data on buffer overflow), 
with leaving out anything more complicated. My ideal is something
like the old SGI ktrace which was an extremly simple mechanism
to do lockless per CPU logging of binary data efficiently and
reading that from a user daemon.
LKST’s logging buffer is (much) simpler than relayfs. It is just the 
linked-perCPU-buffer.

If you are interested in this, please try LKST.
--
Masami HIRAMATSU
Hitachi, Ltd., Systems Development Laboratory
E-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: XFS: inode with st_mode == 0

[Jan Kasprzak]

Christoph Hellwig wrote:
: I have a better patch than the one I gave you (attached below).  If you
: send me a mail with steps to reproduce your remaining problems I'll put
: this very high on my TODO list after christmas.  Btw, any chance you could
: try XFS CVS (which is at 2.6.9) + the patch below instead of plain 2.6.9,
: there have been various other fixes in the last months.
: 
Just FWIW, this patch (applied to 2.6.10) seems to fix the problem
for me. I was not able to reproduce it by running my test script for ~24 hours.

Thanks!

-Yenya

-- 
| Jan "Yenya" Kasprzak   |
| GPG: ID 1024/D3498839  Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while.  --Rob Pike <
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc1-mm1

[Andi Kleen]

On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
> Hello,
> 
> I?m a developer of yet another kernel tracer, LKST. I and co-developers 
> are very glad to hear that LTT was merged into -mm tree and to talk 
> about the kernel tracer on this ML. Because we think that the kernel 
> event tracer is useful to debug Linux systems, and to improve the kernel 
> reliability.

I haven't looked at your code, but I would suggest you also post
for review it so that it can be evaluated in the same way
as other more noisy proposals.

Perhaps Andrew can test both for some time in MM like he used
to do for the various schedulers.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 11:55:47AM +0100, Andries Brouwer wrote:
> I suppose that what happens is the following:
> mounting sets the blocksize to 4096.
> After reading 9992360 sectors, reading the next block means reading
> the next 8 sectors and that fails because only 6 sectors are left.
> Test that this is what happens using blockdev --getbsz.

Yes! This was the command I was looking for ;)

[EMAIL PROTECTED]:~# blockdev --getbsz /dev/hdg7
4096
[EMAIL PROTECTED]:~# blockdev --getbsz /dev/hdg6
1024
[EMAIL PROTECTED]:~# mount -t ext3 -o ro /dev/hdg6 /mnt
[EMAIL PROTECTED]:~# umount /dev/hdg6 
[EMAIL PROTECTED]:~# blockdev --getbsz /dev/hdg6
4096

> If you want to restore the device to full size, use
> blockdev --setbsz 512.

Does that in any way hurt, if a filesystem is just mounted?
I mean, what would happen, if I mount /dev/hdg7 and then
set the block size back to 1024? Would that perhaps corrupt
my filesystem or something like that?


Mario
-- 
 Oh well, config
 one actually wonders what force in the universe is holding it
 and makes it working
 chances and accidents :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [discuss] booting a kernel compiled with -mregparm=0

[Arjan van de Ven]

On Tue, 2005-01-18 at 11:25 +, Tigran Aivazian wrote:

> However, this highlighted a more serious problem in the x86_64 kernel (or 
> more likely in the kdb patch) --- the kernel compiled with -g panics when 
> you try to return from kdb after hitting a breakpoint. This is a bug and 
> I'll investigate to find out the reason why it panics. (I hope it is not 
> an "assumption" of the x86_64 port that one must never compile the kernel 
> with -g either...)

That is isn't; for example the Fedora Core 2 and 3 and the Red Hat
Enterprise Linux 4 kernels are compiled wit -g.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Marcelo Tosatti]

Hi Andries,

On Tue, Jan 18, 2005 at 11:55:47AM +0100, Andries Brouwer wrote:
> On Mon, Jan 17, 2005 at 05:46:35PM -0200, Marcelo Tosatti wrote:
> > On Sun, Jan 16, 2005 at 12:35:30AM +0100, Mario Holbe wrote:
> 
> > > mounting an ext2 (ext3 as well) filesystem seems to modify the
> > > block device's EOF behaviour: before the mount the device returned
> > > EOF, after the mount it doesn't anymore:
> > > 
> > > [on a fresh booted system]
> > > [EMAIL PROTECTED]:~# uname -a
> > > Linux darkside 2.4.27 #1 Sat Jan 15 17:07:20 CET 2005 i686 GNU/Linux
> > > [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null
> > > 9992366+0 records in
> > > 9992366+0 records out
> > > [EMAIL PROTECTED]:~# mount -t ext2 -o ro /dev/hdg7 /mnt
> > > [EMAIL PROTECTED]:~# umount /dev/hdg7
> > > [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null
> > > attempt to access beyond end of device
> > > 22:07: rw=0, want=4996184, limit=4996183
> > > dd: reading `/dev/hdg7': Input/output error
> > > 9992360+0 records in
> > > 9992360+0 records out
> > > [EMAIL PROTECTED]:~# bc
> > > 1249045 * 4
> > > 4996180
> > > 1249045 * 4 * 2
> > > 9992360
> > > 
> > > Could somebody please explain this to me? Is this intentional?
> > 
> > No
> > 
> > Its indeed strange.
> 
> I suppose that what happens is the following:
> mounting sets the blocksize to 4096.
> After reading 9992360 sectors, reading the next block means reading
> the next 8 sectors and that fails because only 6 sectors are left.

So this is either not a Linux error and not a disk error, its just that the
"use with filesystem" then "direct access" is a unfortunate combination.

What would be the correct fix for this for this, if any? 

v2.6 should suffer from the same issues?

> Test that this is what happens using blockdev --getbsz.
> 
> If you want to restore the device to full size, use
> blockdev --setbsz 512.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 06:45:26AM -0200, Marcelo Tosatti wrote:
> So this is either not a Linux error and not a disk error, its just that the
> "use with filesystem" then "direct access" is a unfortunate combination.
> What would be the correct fix for this for this, if any? 

Well, I personally think at least the EOF behaviour should be fixed
somehow.
I understand the point that the device's blocksize affects the device's
length... obviously a block device can only consist of full blocks,
not half a block or something like that.
However, if that's right, a block device's length should IMHO also be
affected by it's blocksize - thus, the block device should return an
EOF after the last block was read.

In my case this would mean, it should return an EOF if blocksize is
1024 and 4996183 blocks (9992366 sectors) are read or better, if the
4996184th block is attempted to read and it should return an EOF if
blocksize is 4096 and 1249045 blocks (9992360 sectors) are read or
better, if the 1249046th block is attempted to read.

Another approach could be to allow 'fractions of blocks' :)
Then, the device could have a blocksize of 4096 and consist of
1249045 full blocks and a 6/8 block. However, I'm not sure, if this
is possible at all.

> v2.6 should suffer from the same issues?

I don't know, but if it doesn't, one could just backport 2.6's
solution :)


Mario
-- 
Independence Day: Fortunately, the alien computer operating system works just
fine with the laptop. This proves an important point which Apple enthusiasts
have known for years. While the evil empire of Microsoft may dominate the
computers of Earth people, more advanced life forms clearly prefer Mac's.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PCI patches not being reviewed

[Matthew Wilcox]

On Mon, Jan 17, 2005 at 10:27:22PM -0800, Greg KH wrote:
> On Tue, Jan 18, 2005 at 02:20:31AM +, Matthew Wilcox wrote:
> > 
> > Greg, you're merging a lot of patches that aren't going through
> > the linux-pci mailing list for review.  Please redirect patches that
> > are sent to you directly so others can also review them.
> 
> I'm sorry, were there any that were recently applied that you feel
> needed more review?

Yes, the PCI Express bridge driver is quite buggy.  I also think it's
the wrong approach to take -- weren't you working on a generic way to
have multiple drivers attach to the same device?

> All major ones have been posted to linux-kernel
> first, which, according to the MAINTAINERS file, is the list for pci
> issues to be disccused on.  I'd be glad to change that entry, if you
> think it would help out any.

That would certainly help; I'm not sure how anyone has time to read
linux-kernel.  Here's a patch:

Index: linux-2.6/MAINTAINERS
===
RCS file: /var/cvs/linux-2.6/MAINTAINERS,v
retrieving revision 1.34
diff -u -p -r1.34 MAINTAINERS
--- linux-2.6/MAINTAINERS   12 Jan 2005 20:14:52 -  1.34
+++ linux-2.6/MAINTAINERS   18 Jan 2005 12:16:43 -
@@ -1745,7 +1745,7 @@ S:Maintained
 PCI SUBSYSTEM
 P: Greg Kroah-Hartman
 M: [EMAIL PROTECTED]
-L: linux-kernel@vger.kernel.org
+L: [EMAIL PROTECTED]
 S: Supported
 
 PCI HOTPLUG CORE

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hugepages demand paging V2 [1/8]: hugetlb fault handler

[Hirokazu Takahashi]

Hi,

> ChangeLog
>   * provide huge page fault handler and related things



> Index: linux-2.6.9/fs/hugetlbfs/inode.c
> ===
> --- linux-2.6.9.orig/fs/hugetlbfs/inode.c 2004-10-18 14:55:07.0 
> -0700
> +++ linux-2.6.9/fs/hugetlbfs/inode.c  2004-10-21 14:50:14.0 -0700
> @@ -79,10 +79,6 @@
>   if (!(vma->vm_flags & VM_WRITE) && len > inode->i_size)
>   goto out;
> 
> - ret = hugetlb_prefault(mapping, vma);
> - if (ret)
> - goto out;
> -
>   if (inode->i_size < len)
>   inode->i_size = len;
>  out:

hugetlbfs_file_mmap() may fail with a weird error, as it returns
uninitialized variable "ret".


Thanks.
Hirokazu Takahashi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Add compat_ioctl to frame buffer layer

[Andi Kleen]

Forward compat_ioctl through the frame buffer layer.

This is needed for a followup patch.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>


diff -u linux-2.6.11-rc1-bk4/drivers/video/fbmem.c-o 
linux-2.6.11-rc1-bk4/drivers/video/fbmem.c
--- linux-2.6.11-rc1-bk4/drivers/video/fbmem.c-o2005-01-14 
10:12:22.0 +0100
+++ linux-2.6.11-rc1-bk4/drivers/video/fbmem.c  2005-01-18 03:36:37.0 
+0100
@@ -868,6 +868,23 @@
}
 }
 
+#ifdef CONFIG_COMPAT
+static long
+fb_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+   int fbidx = iminor(file->f_dentry->d_inode);
+   struct fb_info *info = registered_fb[fbidx];
+   struct fb_ops *fb = info->fbops;
+   int ret;
+   if (fb->fb_compat_ioctl == NULL)
+   return -ENOIOCTLCMD;
+   lock_kernel();
+   ret = fb->fb_compat_ioctl(file, cmd, arg, info);
+   unlock_kernel();
+   return ret;
+}
+#endif
+
 static int 
 fb_mmap(struct file *file, struct vm_area_struct * vma)
 {
@@ -1009,6 +1026,9 @@
.read = fb_read,
.write =fb_write,
.ioctl =fb_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl = fb_compat_ioctl,
+#endif
.mmap = fb_mmap,
.open = fb_open,
.release =  fb_release,
diff -u linux-2.6.11-rc1-bk4/include/linux/fb.h-o 
linux-2.6.11-rc1-bk4/include/linux/fb.h
--- linux-2.6.11-rc1-bk4/include/linux/fb.h-o   2005-01-14 10:12:26.0 
+0100
+++ linux-2.6.11-rc1-bk4/include/linux/fb.h 2005-01-17 11:30:29.0 
+0100
@@ -584,6 +584,10 @@
int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int 
cmd,
unsigned long arg, struct fb_info *info);
 
+   /* Handle 32bit compat ioctl (optional) */
+   int (*fb_compat_ioctl)(struct file *f, unsigned cmd, unsigned long arg,
+  struct fb_info *info);
+
/* perform fb specific mmap */
int (*fb_mmap)(struct fb_info *info, struct file *file, struct 
vm_area_struct *vma);
 };
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4.28 Oops in fs/locks.c:time_out_leases()

[Frank van Maarseveen]

got an Oops the same time for 9 days, at the same EIP:

ksymoops 2.4.9 on i686 2.4.28-x97.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.28-x97/ (default)
 -m /boot/System.map-2.4.28-x97 (default)

kernel:  <1>Unable to handle kernel NULL pointer dereference at virtual address 
003c
kernel: c0153cb8
kernel: *pde = 
kernel: Oops: 
kernel: CPU:0
kernel: EIP:0010:[time_out_leases+24/128]Not tainted
kernel: EFLAGS: 00010202
kernel: eax: c1b42a14   ebx: 0010   ecx:    edx: c349139c
kernel: esi: c1b42ad0   edi: c06f6000   ebp: c06f7f0c   esp: c06f7f04
kernel: ds: 0018   es: 0018   ss: 0018
kernel: Process find (pid: 17476, stackpage=c06f7000)
kernel: Stack: c1b42a14 00018801 c06f7f38 c0153d79 c1b42a14   
c06f7f38 
kernel: c349139c  00018801 c1b42a14 c06f7f64 c014d8c7 
c1b42a14 
kernel:00018801   0004 c2f51898 00018800 c160f000 
080665cb 
kernel: Call Trace:[__get_lease+89/640] [open_namei+487/1376] 
[filp_open+47/80] [sys_open+61/160] [system_call+51/64]
kernel: Code: f6 43 2c 20 74 23 f6 43 2d 10 74 1d 8b 53 50 85 d2 75 1d 89 
Using defaults from ksymoops -t elf32-i386 -a i386


>>eax; c1b42a14 <_end+164147c/4347ac8>
>>edx; c349139c <_end+2f8fe04/4347ac8>
>>esi; c1b42ad0 <_end+1641538/4347ac8>
>>edi; c06f6000 <_end+1f4a68/4347ac8>
>>ebp; c06f7f0c <_end+1f6974/4347ac8>
>>esp; c06f7f04 <_end+1f696c/4347ac8>

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   f6 43 2c 20   testb  $0x20,0x2c(%ebx)
Code;  0004 Before first symbol
   4:   74 23 je 29 <_EIP+0x29>
Code;  0006 Before first symbol
   6:   f6 43 2d 10   testb  $0x10,0x2d(%ebx)
Code;  000a Before first symbol
   a:   74 1d je 29 <_EIP+0x29>
Code;  000c Before first symbol
   c:   8b 53 50  mov0x50(%ebx),%edx
Code;  000f Before first symbol
   f:   85 d2 test   %edx,%edx
Code;  0011 Before first symbol
  11:   75 1d jne30 <_EIP+0x30>
Code;  0013 Before first symbol
  13:   89 00 mov%eax,(%eax)


Details:
-   compiled with gcc version 3.3.4 (Debian 1:3.3.4-3)
-   only ext3 and NFSv3 mounts (and automounter). 
-   The "find" causing the oops appears to be started from cron.daily
and only touches local filesystems.
-   SMP kernel running on UP (pentium II)

-- 
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Convert sis fb driver to compat_ioctl

[Andi Kleen]

Convert the sis framebuffer driver to compat ioctl.

Requires generic framebuffer compat_ioctl patch I posted
earlier on l-k.

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

diff -u linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h-o 
linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h
--- linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h-o  2005-01-14 
10:12:22.0 +0100
+++ linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h2005-01-17 
11:27:41.0 +0100
@@ -527,10 +527,6 @@
int newrom;
int registered;
int warncount;
-#ifdef SIS_CONFIG_COMPAT
-   int ioctl32registered;
-   int ioctl32vblankregistered;
-#endif
 
int sisvga_engine;
int hwcursor_size;
diff -u linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c-o 
linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c
--- linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c-o 2005-01-14 
10:12:22.0 +0100
+++ linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c   2005-01-18 
05:27:29.0 +0100
@@ -2192,11 +2192,22 @@
break;
 
   default:
-   return -EINVAL;
+   return -ENOIOCTLCMD;
}
return 0;
 }
 
+#ifdef CONFIG_COMPAT
+static long sisfb_compat_ioctl(struct file *f, unsigned cmd, unsigned long 
arg, struct fb_info *info)
+{
+   int ret;
+   lock_kernel();
+   ret = sisfb_ioctl(NULL, f, cmd, arg, info);
+   unlock_kernel();
+   return ret;
+}
+#endif
+
 static int
 sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct fb_info *info)
 {
@@ -2258,7 +2269,10 @@
.fb_imageblit   = cfb_imageblit,
.fb_cursor  = soft_cursor,
.fb_sync= fbcon_sis_sync,
-   .fb_ioctl   = sisfb_ioctl
+   .fb_ioctl   = sisfb_ioctl,
+#ifdef CONFIG_COMPAT
+   .fb_compat_ioctl = sisfb_compat_ioctl,
+#endif
 };
 #endif
 
@@ -4791,10 +4805,6 @@
ivideo->pcifunc = PCI_FUNC(pdev->devfn);
ivideo->subsysvendor = pdev->subsystem_vendor;
ivideo->subsysdevice = pdev->subsystem_device;
-#ifdef SIS_CONFIG_COMPAT
-   ivideo->ioctl32registered = 0;
-   ivideo->ioctl32vblankregistered = 0;
-#endif
 
 #ifndef MODULE
if(sisfb_mode_idx == -1) {
@@ -5594,30 +5604,6 @@
ivideo->next = card_list;
card_list = ivideo;
 
-#ifdef SIS_CONFIG_COMPAT
-   {
-   int ret;
-   /* Our ioctls are all "32/64bit compatible" */
-   if(register_ioctl32_conversion(FBIOGET_VBLANK, NULL)) {
-  printk(KERN_ERR "sisfb: Error registering FBIOGET_VBLANK 
ioctl32 translation\n");
-   } else {
-  ivideo->ioctl32vblankregistered = 1;
-   }
-   ret =  register_ioctl32_conversion(FBIO_ALLOC, 
NULL);
-   ret |= register_ioctl32_conversion(FBIO_FREE,  
NULL);
-   ret |= register_ioctl32_conversion(SISFB_GET_INFO_SIZE,
NULL);
-   ret |= register_ioctl32_conversion(SISFB_GET_INFO, 
NULL);
-   ret |= register_ioctl32_conversion(SISFB_GET_TVPOSOFFSET,  
NULL);
-   ret |= register_ioctl32_conversion(SISFB_SET_TVPOSOFFSET,  
NULL);
-   ret |= register_ioctl32_conversion(SISFB_SET_LOCK, 
NULL);
-   ret |= register_ioctl32_conversion(SISFB_GET_VBRSTATUS,
NULL);
-   ret |= register_ioctl32_conversion(SISFB_GET_AUTOMAXIMIZE, 
NULL);
-   ret |= register_ioctl32_conversion(SISFB_SET_AUTOMAXIMIZE, 
NULL);
-   if(ret) printk(KERN_ERR "sisfb: Error registering ioctl32 
translations\n");
-   elseivideo->ioctl32registered = 1;
-   }
-#endif
-
printk(KERN_INFO "sisfb: 2D acceleration is %s, y-panning %s\n",
 ivideo->sisfb_accel ? "enabled" : "disabled",
 ivideo->sisfb_ypan  ?
@@ -5649,28 +5635,6 @@
struct fb_info*sis_fb_info = ivideo->memyselfandi;
int   registered = ivideo->registered;
 
-#ifdef SIS_CONFIG_COMPAT
-   if(ivideo->ioctl32vblankregistered) {
-   if(unregister_ioctl32_conversion(FBIOGET_VBLANK)) {
-   printk(KERN_ERR "sisfb: Error unregistering 
FBIOGET_VBLANK ioctl32 translation\n");
-   }
-   }
-   if(ivideo->ioctl32registered) {
-   int ret;
-   ret =  unregister_ioctl32_conversion(FBIO_ALLOC);
-   ret |= unregister_ioctl32_conversion(FBIO_FREE);
-   ret |= unregister_ioctl32_conversion(SISFB_GET_INFO_SIZE);
-   ret |= unregister_ioctl32_conversion(SISFB_GET_INFO);
-   ret |= unregister_ioctl32_conversion(SISFB_GET_TVPOSOFFSET);
-   ret |= unregister_ioctl32_conversion(SISFB_SET_TVPOSOFFSET);
-   ret |= unregister_ioctl32_conversion(SISFB_SET_LOCK);
-

Re: 2.4: "access beyond end of device" after ext2 mount

[Andries Brouwer]

On Tue, Jan 18, 2005 at 06:45:26AM -0200, Marcelo Tosatti wrote:

> > I suppose that what happens is the following:
> > mounting sets the blocksize to 4096.
> > After reading 9992360 sectors, reading the next block means reading
> > the next 8 sectors and that fails because only 6 sectors are left.
> 
> So this is either not a Linux error and not a disk error, its just that the
> "use with filesystem" then "direct access" is a unfortunate combination.

It is not a disk error, but I consider it a Linux error.

> What would be the correct fix for this for this, if any?

For 2.4 my reaction would be to say that it is a known property
of the system, possibly less fortunate, an unimportant flaw.
Of course a fix is possible if this is deemed important for some reason.

> v2.6 should suffer from the same issues?

I don't think so. But 2.6 details are rather different.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Andries Brouwer]

On Tue, Jan 18, 2005 at 12:47:01PM +0100, Mario Holbe wrote:

> > If you want to restore the device to full size, use
> > blockdev --setbsz 512.
> 
> Does that in any way hurt, if a filesystem is just mounted?

It is a bad idea to change the blocksize of a mounted filesystem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.
It does this by adding a new scheduling class called SCHED_ISO or
Isochronous scheduling which means "same time" scheduling. This class
does not require superuser privileges and is starvation free. The
scheduling class no. 4 was chosen since there are quite a few userspace
applications already supporting 3 and 4 for SCHED_BATCH and SCHED_ISO
respectively on non-mainline kernels. As a way of immediately providing
support for current userspace apps, any unprivileged user starting an
application requesting SCHED_RR or SCHED_FIFO will be demoted to
SCHED_ISO. This may or may not be worth removing later.
The SCHED_ISO class runs as SCHED_RR effectively at a priority just
above all SCHED_NORMAL tasks and below all true real time tasks. Once a
cpu usage limit is exceeded by tasks of this class (per cpu), SCHED_ISO
tasks will then run as SCHED_NORMAL until the cpu usage drops to 90% of
the cpu limit.
By default the cpu limit is set to 70% which literature suggests should
provide good real time behaviour for most applications without gross
unfairness. This cpu limit is calculated as a decaying average over 5
seconds. These limits are configurable with the tunables
/proc/sys/kernel/iso_cpu
/proc/sys/kernel/iso_period
iso_cpu can be set to 100 which would allow all unprivileged users
access to unrestricted SCHED_RR behaviour. OSX provides a similar class
to SCHED_ISO and uses 90% as its cpu limit.
The sysrq-n combination which converts all user real-time tasks to
SCHED_NORMAL also will affect SCHED_ISO tasks.
Currently the round robin interval is set to 10ms which is a cache
friendly timeslice. It may be worth making this configurable or smaller,
and it would also be possible to implement SCHED_ISO of a FIFO nature as
well.
For testing, the userspace tool schedtool available here:
http://freequaos.host.sk/schedtool/
can be used as a wrapper to start SCHED_ISO tasks
schedtool -I -e xmms
for example
Patch also available here:
http://ck.kolivas.org/patches/SCHED_ISO/
Comments and testing welcome.
Signed-off-by: Con Kolivas <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc1/include/linux/init_task.h
===
--- linux-2.6.11-rc1.orig/include/linux/init_task.h	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/include/linux/init_task.h	2005-01-16 22:45:23.0 +1100
@@ -80,6 +80,7 @@
 	.mm		= NULL,		\
 	.active_mm	= &init_mm,	\
 	.run_list	= LIST_HEAD_INIT(tsk.run_list),			\
+	.iso_list	= LIST_HEAD_INIT(tsk.iso_list),			\
 	.time_slice	= HZ,		\
 	.tasks		= LIST_HEAD_INIT(tsk.tasks),			\
 	.ptrace_children= LIST_HEAD_INIT(tsk.ptrace_children),		\
Index: linux-2.6.11-rc1/include/linux/sched.h
===
--- linux-2.6.11-rc1.orig/include/linux/sched.h	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/include/linux/sched.h	2005-01-18 22:48:05.0 +1100
@@ -130,6 +130,18 @@
 #define SCHED_NORMAL		0
 #define SCHED_FIFO		1
 #define SCHED_RR		2
+/* policy 3 reserved for SCHED_BATCH */
+#define SCHED_ISO		4
+
+extern int iso_cpu, iso_period;
+
+#define SCHED_RANGE(policy)	((policy) == SCHED_NORMAL || \
+(policy) == SCHED_FIFO || \
+(policy) == SCHED_RR || \
+(policy) == SCHED_ISO)
+
+#define SCHED_RT(policy)	((policy) == SCHED_FIFO || \
+(policy) == SCHED_RR)
 
 struct sched_param {
 	int sched_priority;
@@ -359,6 +371,7 @@
 #define MAX_PRIO		(MAX_RT_PRIO + 40)
 
 #define rt_task(p)		(unlikely((p)->prio < MAX_RT_PRIO))
+#define iso_task(p)		(unlikely((p)->policy == SCHED_ISO))
 
 /*
  * Some day this will be a full-fledged user tracking system..
@@ -536,6 +549,7 @@
 
 	int prio, static_prio;
 	struct list_head run_list;
+	struct list_head iso_list;
 	prio_array_t *array;
 
 	unsigned long sleep_avg;
Index: linux-2.6.11-rc1/include/linux/sysctl.h
===
--- linux-2.6.11-rc1.orig/include/linux/sysctl.h	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/include/linux/sysctl.h	2005-01-16 22:45:23.0 +1100
@@ -135,6 +135,8 @@
 	KERN_HZ_TIMER=65,	/* int: hz timer on or off */
 	KERN_UNKNOWN_NMI_PANIC=66, /* int: unknown nmi panic flag */
 	KERN_BOOTLOADER_TYPE=67, /* int: boot loader type */
+	KERN_ISO_CPU=68,	/* int: cpu% allowed by SCHED_ISO class */
+	KERN_ISO_PERIOD=69,	/* int: seconds over which SCHED_ISO cpu is decayed */
 };
 
 
Index: linux-2.6.11-rc1/kernel/sched.c
===
--- linux-2.6.11-rc1.orig/kernel/sched.c	2005-01-16 22:43:47.0 +1100
+++ linux-2.6.11-rc1/kernel/sched.c	2005-01-18 22:48:47.0 +1100
@@ -149,9 +149,6 @@
 	(JIFFIES_TO_NS(MAX_SLEEP_AVG * \
 		(MAX_BONUS / 2 + DELTA((p)) + 1) / MAX_BONUS - 1))
 
-#define TASK_PREEMPTS_CURR(p, rq) \
-	((p)->prio < (rq)->

Re: [discuss] booting a kernel compiled with -mregparm=0

[Tigran Aivazian]

On Tue, 18 Jan 2005, Tigran Aivazian wrote:
I already solved this paricular problem. And the solution is (but don't tell 
me you knew it, for then why didn't you tell anyone) simply --- compile the 
kernel with -g and that includes enough debug information to be able to 
decode the stack content correctly. And yes, kdb does show the correct 
argument values now. No changes to kdb are necessary and no need to do the 
work with dwarf2 implementation etc etc.
actually I am very surprized that it worked (because looking at the code I 
concluded that it should NOT). So I need to retest in all cases to make 
sure this is not a coincidence but a solid fact...

Kind regards
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 0/3] kallsyms: Add gate page and all symbols support

[Keith Owens]

On Tue, 18 Jan 2005 18:52:55 +1100, 
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>On Tue, 2004-12-28 at 22:17 +0100, Sam Ravnborg wrote:
>
>> > 2 Add in_gate_area_no_task() for use from places where no task is valid.
>
>Can you back that out ? Or at least explain why you need to add this
>"no_task" thing and not just use "current" where no task is available ?

kallsyms is used to look up a symbol for any task, e.g. to do a
backtrace with symbol lookup of all running tasks, not just the current
one.  None of the kallsym interfaces allow you to specify which task
you are making the query against, and the change to do so is too messy
and intrusive for far too little return.  The no_task variant asks "is
this a possible gate address for any task?", at the small risk of
getting false positives in kallsyms lookup.

> - Since you unconditionally #define in_gate_area() to use
>in_gate_area_no_task(), what is the point of having in_gate_area() at
>all ? Which rather means, what is the point of adding that "_no_task"
>version and not just change in_gate_area to not take a task ?

x86-64 needs both variants.  in_gate_area() is sometimes called in a
context where you know the required task (mm/memory.c), sometimes when
any task is implied (kernel/kallsyms.c).  x86-64 makes it more
complicated by using different gate pages depending on whether the
specified task is in 32 bit emulation mode or not.

> - I dislike the fact that you now define the prototype of the function
>in the __HAVE_ARCH_GATE_AREA case. I want my arch .h to be the one doing
>so, since i want to inline it

Maybe.  I dislike copying definitions to multiple asm headers.  If you
think that the win of inlining the ppc64 version of these functions
outweighs the header duplication then send a patch.  Don't forget to
duplicate the definition in include/asm-x86_64 as well.

>(to nothing in the ppc64 case since the
>vDSO I'm implementing doesn't need any special treatement of the gate
>area, it's a normal VMA added to the mm's at exec time).

Added to specific task's mm or to all tasks?  If the gate VMA varies
according to the task then you have to support the kallsyms "is this a
possible gate address for any task?" question, like x86-64.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Wait and retry mounting root device (revised)

[Helge Hafting]

Andrew Morton wrote:
Helge Hafting <[EMAIL PROTECTED]> wrote:
 

The USB block driver should know that 10s (or whatever) hasn't yet 
passed, and simply
block any attempt to access block devices (or scan for them) knowing 
that it will
not work yet, but any device will be there after the pause. A root mount 
on USB will
then succeed at the _first_ try everytime, so no need for retries.
   

Maybe a simple delay somewhere in the boot sequence would suffice?  Boot
with `mount_delay=10'.
 

Certainly the simplest solution, and it also solves a related
but rare problem: People booting linux from ROM long before
the disks have time to spin up.
There seems to be a disadvantage in that one must specify
this pause manually, but the admin have to select the root fs
somewhere anyway (lilo.conf) and may specify the delay at
the same time.
But it sure would be nice to simply get this stuff right somehow.  If the
USB block driver knows that discovery is still in progress it should wait
until it has completed.  (I suggested that before, but wasn't 100% convinced
by the answer).
 

Sure, if the USB core can know, then it should use the knowledge.
Or utilize a simple timeout if all it knows is that "common
storage devices appear on the bus up to 10s after powerup/reset".
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: User space out of memory approach

[Edjard Souza Mota]

Hi,
 
> If my system needs the OOM killer, it's usurally unresponsive to most
> userspace applications. A normal daemon would be swapped out before the
> runaway dhcpd grows larger than the web cache. It would have to be a mlocked
> RT task started from early userspace. It would be difficult to set up (unless
> you upgrade your distro), and almost nobody will feel like tweaking it to
> take the benefit (OOM == -ECANNOTHAPPEN).

Please correct me if I got it wrong: as deamon in this case is not a normal one,
since it never gets rate for its own safety, then it needs an RT lock whenever
system boots. 

> What about creating a linked list of (stackable) algorhithms which can be
> extended by loading modules and resorted using {proc,sys}fs? It will avoid
> the extra process, the extra CPU time (and task switches) to frequently
> update the list and I think it will decrease the typical amount of used
> memory, too.

Wouldn't this bring the (set of ) ranking algorithm(s) back to the kernel? This
is exactly what we're trying to avoid. The way we see the potential for doing 
this is that kernel shouldn't  worry about users decision on which process to 
kill but rather take her/his option into account. The computation of such a
decision could be at user space (protected as you suggested above).

We'll think about it, although I'm not sure if there would be such a decrease 
in memory concumption.

br

Edjard


-- 
"In a world without fences ... who needs Gates?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [discuss] booting a kernel compiled with -mregparm=0

[Tigran Aivazian]

Sorry, it was a "red herring", namely my module's Makefile still had 
"-mregparm=0" in CFLAGS, so that is why kdb showed it's arguments 
correctly (and then paniced on the way out).

So we still have to deal with DWARF2 data then... Ok, will look into it.
Kind regards
Tigran
On Tue, 18 Jan 2005, Tigran Aivazian wrote:
On Tue, 18 Jan 2005, Tigran Aivazian wrote:
I already solved this paricular problem. And the solution is (but don't 
tell me you knew it, for then why didn't you tell anyone) simply --- 
compile the kernel with -g and that includes enough debug information to be 
able to decode the stack content correctly. And yes, kdb does show the 
correct argument values now. No changes to kdb are necessary and no need to 
do the work with dwarf2 implementation etc etc.
actually I am very surprized that it worked (because looking at the code I 
concluded that it should NOT). So I need to retest in all cases to make sure 
this is not a coincidence but a solid fact...

Kind regards
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lock-ups in AHCI (?)

[Grega Bremec]

Hello, list.

NOTE: I am not subscribed, so please CC me in any of your replies.

I recently set up a machine featuring an Intel ICH6 desktop board
with two 200GB Seagates (ST3200822AS) in mirrored volume, AHCI mode,
with linux kernel 2.6.10 and ext3.

After a relatively small amount of I/O (for example, compiling ISC
bind), I get lock-ups (keyboard LEDs do not respond, SysRq works :)).

Timed vmstat dumps snapshot during a couple of bonnie++ tests are
available upon request, and it's evident from those that I/O was
rather bursty with regard to interactivity, and most all lock-ups
happened during rewrite phase, in second consecutive test run, when
cached memory was usually at around 1.75GB.

If I only let bonnie++ do one test and then exit() before re-running,
I was able to perform numerous tests if the thing survived the first
one, of course, as cache size went down to ~12MB after exit().

Setting chunk size and/or buffered i/o had marginal, if any, effect
on the success of the test.

The usual stack trace after a lock-up looks like this:

Pid: 1399, comm:   kmirrord/0
EIP: 0060:[] CPU: 0
EIP is at __read_lock_failed+0x5/0x14
 EFLAGS: 0297Not tainted  (2.6.10-sk98-4k-p0f-smp)
 EAX: c23a959c EBX: c23a959c ECX: c23a9580 EDX: c0a21000
 ESI: 000134b3 EDI: c23a958c EBP:  DS: 007b ES: 007b
 CR0: 8005003b CR2: 0809b890 CR3: 32159000 CR4: 06d0
  [] _read_lock+0x15/0x20
  [] rh_dec+0x27/0xe0
  [] mirror_end_io+0x32/0x40
  [] clone_endio+0x7c/0x130
  [] write_callback+0x0/0x80
  [] bio_endio+0x55/-x80
  [] write_callback+0x67/0x80
  [] dec_count+0x57/0x80
  [] endio+0x5d/0x80
  [] bio_endio+0x55/0x80
  [] __end_that_request_first+0x1c7/0x240
  [] scsi_end_request+0x3b/0x100
  [] scsu_io_completion+0x10e/0x4e0
  [] sd_rw_intr+0x81/0x280
  [] scsi_finish_command+0x7f/0xe0
  [] scsi_softirq+0xc8/0xf0
  [] __do_softirq+0xbd/0xd0
  [] do_softirq+0x4a/0x60
  ===
  [] irq_exit+0x39/0x40
  [] do_IRQ+0x63/0xb0
  [] common_interrupt+0x1a/0x20
  [] audit_log+0x3b/0x41
  [] _spin_unlock_irq+0x9/0x20
  [] __rh_alloc+0xfa/0x100
  [] rh_inc+0xac/0xb0
  [] rh_inc_pending+0x33/0x40
  [] do_writes+0xe6/0x1d0
  [] do_mirror+0x85/0x90
  [] do_work+0x38/0x70
  [] worker_thread+0x1d0/0x270
  [] do_work+0x0/0x70
  [] default_wake_function+0x0/0x20
  [] default_wake_function+0x0/0x20
  [] worker_thread+0x0/0x270
  [] kthread+0xba/0xc0
  [] kthread+0x0/0xc0
  [] kernel_thread_helper+0x5/0x10

I was able to obtain the former one directly, with no previous action,
whereas a couple of other stack traces were only possible after a SAK,
yet with the exception of below, they were always identical.

Sometimes, a __wake_up_common and a __mod_timer would appear just below
scsi_io_completion, an audit_log was sometimes missing below
common_interrupt, but I suppose that's really far too far down the stack
to be of significance.

Board data:
Product number: D925XCV Desktop Board
BIOS Version: CV92510A.86A.0249.2004.0819.1259
Board version: AAC57587-404

I had to patch from a beta sk98 driver to get support for Marvell
Gbit card on the board. No other patches were added to the kernel.

The ICH6 controller is in AHCI mode and the AHCI driver is the only
low-level SCSI driver included in the kernel (NOTE: I have no idea
how the QLogic driver came in :)):

CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_SATA=y
CONFIG_SCSI_SATA_AHCI=y
CONFIG_SCSI_ATA_PIIX=m
CONFIG_SCSI_QLA2XXX=y

Another interesting thing - when I start the dmraid up, I usually
(in 999 out of 1000 cases) get the following error messages from the
kernel:

attempt to access beyond end of device
sda: rw=0, want=390725760, limit=390721968
attempt to access beyond end of device
sda: rw=0, want=390725888, limit=390721968
attempt to access beyond end of device
sda: rw=0, want=390726016, limit=390721968
attempt to access beyond end of device
sda: rw=0, want=390726144, limit=390721968
attempt to access beyond end of device
sdb: rw=1, want=390725760, limit=390721968
attempt to access beyond end of device
sdb: rw=1, want=390725888, limit=390721968
attempt to access beyond end of device
sdb: rw=1, want=390726016, limit=390721968
attempt to access beyond end of device
sdb: rw=1, want=390726144, limit=390721968
attempt to access beyond end of device
...

Nothing b0rks though. Is this something to worry about?

Let me know if I can provide any additional information, or if
anybody is interested in those vmstat dumps. I'll retry with whatever
state the 2.6.11 AHCI driver is in in the mean time.

With kind regards,
-- 
Grega Bremec
gregab at p0f dot net


pgpDibLK2JC7p.pgp
Description: PGP signature

Re: 2.4: "access beyond end of device" after ext2 mount

[Marcelo Tosatti]

On Tue, Jan 18, 2005 at 01:37:08PM +0100, Andries Brouwer wrote:
> On Tue, Jan 18, 2005 at 06:45:26AM -0200, Marcelo Tosatti wrote:
> 
> > > I suppose that what happens is the following:
> > > mounting sets the blocksize to 4096.
> > > After reading 9992360 sectors, reading the next block means reading
> > > the next 8 sectors and that fails because only 6 sectors are left.
> > 
> > So this is either not a Linux error and not a disk error, its just that the
> > "use with filesystem" then "direct access" is a unfortunate combination.
> 
> It is not a disk error, but I consider it a Linux error.

OK.

> > What would be the correct fix for this for this, if any?
> 
> For 2.4 my reaction would be to say that it is a known property
> of the system, possibly less fortunate, an unimportant flaw.

This seems to be harmless, so, better do nothing about it.

> Of course a fix is possible if this is deemed important for some reason.
> 
> > v2.6 should suffer from the same issues?
> 
> I don't think so. But 2.6 details are rather different.

OK!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix audit control message checks

[Stephen Smalley]

On Sat, 2005-01-15 at 15:07, Serge E. Hallyn wrote:
> The audit control messages are sent over netlink.  Permission checks
> are done on the process receiving the message, which may not be the
> same as the process sending the message.  This patch switches the
> netlink_send security hooks to calculate the effective capabilities
> based on the sender.  Then audit_receive_msg performs capability checks
> based on that.
> 
> It also introduces the CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL capabilities,
> and replaces the previous CAP_SYS_ADMIN checks in audit code with the
> appropriate checks.
> 
> Please apply.
> 
> Changelog:
>   1/15/2005: Simplified dummy_netlink_send given that dummy now
>   keeps track of capabilities.
>   1/14/2005: Many fixes based on feedback from [EMAIL PROTECTED]
>   list.
>   1/14/2005: Removed the netlink_msg_type helper function.
>   1/07/2005: Swith to using CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL.
> 
> thanks,
> -serge
> 
> Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>

Signed-off-by:  Stephen Smalley <[EMAIL PROTECTED]>

-- 
Stephen Smalley <[EMAIL PROTECTED]>
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4: "access beyond end of device" after ext2 mount

[Piszcz, Justin Michael]

Normally, this problem associated with drives over 32GB or 127GB on a
controller that cannot support it.  It was not discussed here, I was
wondering if that is the problem, if it is not, what type of Hard Drive
is giving you these problems?

Thanks.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marcelo Tosatti
Sent: Tuesday, January 18, 2005 5:20 AM
To: Andries Brouwer
Cc: Mario Holbe; linux-kernel@vger.kernel.org
Subject: Re: 2.4: "access beyond end of device" after ext2 mount

On Tue, Jan 18, 2005 at 01:37:08PM +0100, Andries Brouwer wrote:
> On Tue, Jan 18, 2005 at 06:45:26AM -0200, Marcelo Tosatti wrote:
> 
> > > I suppose that what happens is the following:
> > > mounting sets the blocksize to 4096.
> > > After reading 9992360 sectors, reading the next block means
reading
> > > the next 8 sectors and that fails because only 6 sectors are left.
> > 
> > So this is either not a Linux error and not a disk error, its just
that the
> > "use with filesystem" then "direct access" is a unfortunate
combination.
> 
> It is not a disk error, but I consider it a Linux error.

OK.

> > What would be the correct fix for this for this, if any?
> 
> For 2.4 my reaction would be to say that it is a known property
> of the system, possibly less fortunate, an unimportant flaw.

This seems to be harmless, so, better do nothing about it.

> Of course a fix is possible if this is deemed important for some
reason.
> 
> > v2.6 should suffer from the same issues?
> 
> I don't think so. But 2.6 details are rather different.

OK!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 08:42:08AM -0500, Piszcz, Justin Michael wrote:
> Normally, this problem associated with drives over 32GB or 127GB on a
> controller that cannot support it.  It was not discussed here, I was
> wondering if that is the problem, if it is not, what type of Hard Drive
> is giving you these problems?

This does not depend on the type of the hard disk for sure.

[EMAIL PROTECTED]:/dev/shm# dd if=/dev/zero of=foo bs=1024 count=10001
10001+0 records in
10001+0 records out
10241024 bytes transferred in 0,062195 seconds (164659895 bytes/sec)
[EMAIL PROTECTED]:/dev/shm# losetup /dev/loop0 foo
loop: loaded (max 8 devices)
[EMAIL PROTECTED]:/dev/shm# mke2fs -b 4096 /dev/loop0
...
[EMAIL PROTECTED]:/dev/shm# blockdev --getbsz /dev/loop0
1024
[EMAIL PROTECTED]:/dev/shm# dd if=/dev/loop0 of=/dev/null
20002+0 records in
20002+0 records out
10241024 bytes transferred in 0,248255 seconds (41252031 bytes/sec)
[EMAIL PROTECTED]:/dev/shm# mount -o ro /dev/loop0 /mnt
[EMAIL PROTECTED]:/dev/shm# umount /dev/loop0
[EMAIL PROTECTED]:/dev/shm# blockdev --getbsz /dev/loop0
4096
[EMAIL PROTECTED]:/dev/shm# dd if=/dev/loop0 of=/dev/null
attempt to access beyond end of device
07:00: rw=0, want=10004, limit=10001
dd: reading `/dev/loop0': Input/output error
2+0 records in
2+0 records out
1024 bytes transferred in 0,185949 seconds (55068833 bytes/sec)

Of course you could reproduce it much more simple without all
the ext2 stuff using blockdev --setbsz :)


Mario
-- 
() Ascii Ribbon Campaign
/\ Support plain text e-mail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4: "access beyond end of device" after ext2 mount

[Piszcz, Justin Michael]

Okay but what hard drive model and IDE Chipset/Controller are you using?

Thanks!

-Original Message-
From: Mario Holbe [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 18, 2005 9:02 AM
To: Piszcz, Justin Michael
Cc: Marcelo Tosatti; Andries Brouwer; linux-kernel@vger.kernel.org
Subject: Re: 2.4: "access beyond end of device" after ext2 mount

On Tue, Jan 18, 2005 at 08:42:08AM -0500, Piszcz, Justin Michael wrote:
> Normally, this problem associated with drives over 32GB or 127GB on a
> controller that cannot support it.  It was not discussed here, I was
> wondering if that is the problem, if it is not, what type of Hard
Drive
> is giving you these problems?

This does not depend on the type of the hard disk for sure.

[EMAIL PROTECTED]:/dev/shm# dd if=/dev/zero of=foo bs=1024 count=10001
10001+0 records in
10001+0 records out
10241024 bytes transferred in 0,062195 seconds (164659895 bytes/sec)
[EMAIL PROTECTED]:/dev/shm# losetup /dev/loop0 foo
loop: loaded (max 8 devices)
[EMAIL PROTECTED]:/dev/shm# mke2fs -b 4096 /dev/loop0
...
[EMAIL PROTECTED]:/dev/shm# blockdev --getbsz /dev/loop0
1024
[EMAIL PROTECTED]:/dev/shm# dd if=/dev/loop0 of=/dev/null
20002+0 records in
20002+0 records out
10241024 bytes transferred in 0,248255 seconds (41252031 bytes/sec)
[EMAIL PROTECTED]:/dev/shm# mount -o ro /dev/loop0 /mnt
[EMAIL PROTECTED]:/dev/shm# umount /dev/loop0
[EMAIL PROTECTED]:/dev/shm# blockdev --getbsz /dev/loop0
4096
[EMAIL PROTECTED]:/dev/shm# dd if=/dev/loop0 of=/dev/null
attempt to access beyond end of device
07:00: rw=0, want=10004, limit=10001
dd: reading `/dev/loop0': Input/output error
2+0 records in
2+0 records out
1024 bytes transferred in 0,185949 seconds (55068833 bytes/sec)

Of course you could reproduce it much more simple without all
the ext2 stuff using blockdev --setbsz :)


Mario
-- 
() Ascii Ribbon Campaign
/\ Support plain text e-mail
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Convert sis fb driver to compat_ioctl

[Thomas Winischhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andi Kleen wrote:
| Convert the sis framebuffer driver to compat ioctl.
|
| Requires generic framebuffer compat_ioctl patch I posted
| earlier on l-k.
|
| Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Thomas Winischhofer <[EMAIL PROTECTED]>
|
| diff -u linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h-o
linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h
| --- linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h-o2005-01-14
10:12:22.0 +0100
| +++ linux-2.6.11-rc1-bk4/drivers/video/sis/sis.h  2005-01-17
11:27:41.0 +0100
| @@ -527,10 +527,6 @@
|   int newrom;
|   int registered;
|   int warncount;
| -#ifdef SIS_CONFIG_COMPAT
| - int ioctl32registered;
| - int ioctl32vblankregistered;
| -#endif
|
|   int sisvga_engine;
|   int hwcursor_size;
| diff -u linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c-o
linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c
| --- linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c-o   2005-01-14
10:12:22.0 +0100
| +++ linux-2.6.11-rc1-bk4/drivers/video/sis/sis_main.c 2005-01-18
05:27:29.0 +0100
| @@ -2192,11 +2192,22 @@
|   break;
|
|  default:
| - return -EINVAL;
| + return -ENOIOCTLCMD;
|   }
|   return 0;
|  }
|
| +#ifdef CONFIG_COMPAT
| +static long sisfb_compat_ioctl(struct file *f, unsigned cmd, unsigned
long arg, struct fb_info *info)
| +{
| + int ret;
| + lock_kernel();
| + ret = sisfb_ioctl(NULL, f, cmd, arg, info);
| + unlock_kernel();
| + return ret;
| +}
| +#endif
| +
|  static int
|  sisfb_get_fix(struct fb_fix_screeninfo *fix, int con, struct fb_info
*info)
|  {
| @@ -2258,7 +2269,10 @@
|   .fb_imageblit   = cfb_imageblit,
|   .fb_cursor  = soft_cursor,
|   .fb_sync= fbcon_sis_sync,
| - .fb_ioctl   = sisfb_ioctl
| + .fb_ioctl   = sisfb_ioctl,
| +#ifdef CONFIG_COMPAT
| + .fb_compat_ioctl = sisfb_compat_ioctl,
| +#endif
|  };
|  #endif
|
| @@ -4791,10 +4805,6 @@
|   ivideo->pcifunc = PCI_FUNC(pdev->devfn);
|   ivideo->subsysvendor = pdev->subsystem_vendor;
|   ivideo->subsysdevice = pdev->subsystem_device;
| -#ifdef SIS_CONFIG_COMPAT
| - ivideo->ioctl32registered = 0;
| - ivideo->ioctl32vblankregistered = 0;
| -#endif
|
|  #ifndef MODULE
|   if(sisfb_mode_idx == -1) {
| @@ -5594,30 +5604,6 @@
|   ivideo->next = card_list;
|   card_list = ivideo;
|
| -#ifdef SIS_CONFIG_COMPAT
| - {
| - int ret;
| - /* Our ioctls are all "32/64bit compatible" */
| - if(register_ioctl32_conversion(FBIOGET_VBLANK, NULL)) {
| -printk(KERN_ERR "sisfb: Error registering FBIOGET_VBLANK 
ioctl32
translation\n");
| - } else {
| -ivideo->ioctl32vblankregistered = 1;
| - }
| - ret =  register_ioctl32_conversion(FBIO_ALLOC, 
NULL);
| - ret |= register_ioctl32_conversion(FBIO_FREE,  
NULL);
| - ret |= register_ioctl32_conversion(SISFB_GET_INFO_SIZE,
NULL);
| - ret |= register_ioctl32_conversion(SISFB_GET_INFO, 
NULL);
| - ret |= register_ioctl32_conversion(SISFB_GET_TVPOSOFFSET,  
NULL);
| - ret |= register_ioctl32_conversion(SISFB_SET_TVPOSOFFSET,  
NULL);
| - ret |= register_ioctl32_conversion(SISFB_SET_LOCK, 
NULL);
| - ret |= register_ioctl32_conversion(SISFB_GET_VBRSTATUS,
NULL);
| - ret |= register_ioctl32_conversion(SISFB_GET_AUTOMAXIMIZE, 
NULL);
| - ret |= register_ioctl32_conversion(SISFB_SET_AUTOMAXIMIZE, 
NULL);
| - if(ret) printk(KERN_ERR "sisfb: Error registering ioctl32
translations\n");
| - elseivideo->ioctl32registered = 1;
| - }
| -#endif
| -
|   printk(KERN_INFO "sisfb: 2D acceleration is %s, y-panning %s\n",
|ivideo->sisfb_accel ? "enabled" : "disabled",
|ivideo->sisfb_ypan  ?
| @@ -5649,28 +5635,6 @@
|   struct fb_info*sis_fb_info = ivideo->memyselfandi;
|   int   registered = ivideo->registered;
|
| -#ifdef SIS_CONFIG_COMPAT
| - if(ivideo->ioctl32vblankregistered) {
| - if(unregister_ioctl32_conversion(FBIOGET_VBLANK)) {
| - printk(KERN_ERR "sisfb: Error unregistering 
FBIOGET_VBLANK ioctl32
translation\n");
| - }
| - }
| - if(ivideo->ioctl32registered) {
| - int ret;
| - ret =  unregister_ioctl32_conversion(FBIO_ALLOC);
| - ret |= unregister_ioctl32_conversion(FBIO_FREE);
| - ret |= unregister_ioctl32_conversion(SISFB_GET_INFO_SIZE);
| - ret |= unregister_ioctl32_conversion(SISFB_GET_INFO);
| - ret |= unregister

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 09:05:05AM -0500, Piszcz, Justin Michael wrote:
> Okay but what hard drive model and IDE Chipset/Controller are you using?

VIA vt82c686b onboard
PDC20269 (Promise U133TX2) on PCI

hda: WDC WD400EB-00CPF0, ATA DISK drive
hdc: IC35L080AVVA07-0, ATA DISK drive
hdd: HL-DT-ST DVDRAM GSA-4082B, ATAPI CD/DVD-ROM drive
hdg: SAMSUNG SP1614N, ATA DISK drive

hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(100)
hdc: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=159560/16/63, UDMA(100)
hdg: 312581808 sectors (160042 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)

However, it doesn't matter :)


Mario
-- 
 talk softly and carry a keen sword
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

What Would Cause This :

[Patrick]

dmesg produces the following : 

oom-killer: gfp_mask=0xd0
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
HighMem per-cpu:
cpu 0 hot: low 30, high 90, batch 15
cpu 0 cold: low 0, high 30, batch 15

Free pages:4012kB (240kB HighMem)
Active:41408 inactive:239841 dirty:0 writeback:0 unstable:0 free:1003
slab:4559 mapped:281415 pagetables:1654
DMA free:68kB min:68kB low:84kB high:100kB active:4984kB
inactive:5812kB present:16384kB pages_scanned:11351 all_unreclaimable?
no
protections[]: 0 0 0
Normal free:3704kB min:3756kB low:4692kB high:5632kB active:31768kB
inactive:826028kB present:901120kB pages_scanned:269506
all_unreclaimable? no
protections[]: 0 0 0
HighMem free:240kB min:252kB low:312kB high:376kB active:128880kB
inactive:127524kB present:261632kB pages_scanned:8619
all_unreclaimable? no
protections[]: 0 0 0
DMA: 1*4kB 0*8kB 4*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 0*4096kB = 68kB
Normal: 44*4kB 5*8kB 10*16kB 4*32kB 2*64kB 0*128kB 2*256kB 1*512kB
0*1024kB 1*2048kB 0*4096kB = 3704kB
HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 240kB
Swap cache: add 593035, delete 592831, find 18378/27962, race 0+0
Out of Memory: Killed process 6814 (rsync).
oom-killer: gfp_mask=0x1d2
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
HighMem per-cpu:
cpu 0 hot: low 30, high 90, batch 15
cpu 0 cold: low 0, high 30, batch 15

Free pages:4956kB (240kB HighMem)
Active:177148 inactive:103619 dirty:0 writeback:0 unstable:0 free:1239
slab:4480 mapped:281242 pagetables:1758
DMA free:68kB min:68kB low:84kB high:100kB active:5844kB
inactive:4948kB present:16384kB pages_scanned:54179 all_unreclaimable?
yes
protections[]: 0 0 0
Normal free:4648kB min:3756kB low:4692kB high:5632kB active:571716kB
inactive:284548kB present:901120kB pages_scanned:146374
all_unreclaimable? no
protections[]: 0 0 0
HighMem free:240kB min:252kB low:312kB high:376kB active:131032kB
inactive:124980kB present:261632kB pages_scanned:143172
all_unreclaimable? no
protections[]: 0 0 0
DMA: 1*4kB 2*8kB 3*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 0*4096kB = 68kB
Normal: 302*4kB 0*8kB 9*16kB 3*32kB 2*64kB 0*128kB 2*256kB 1*512kB
0*1024kB 1*2048kB 0*4096kB = 4648kB
HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 240kB
Swap cache: add 602170, delete 601966, find 22886/33368, race 0+7
Out of Memory: Killed process 14106 (silc).

Patrick
-- 


--
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Sytse Wielinga]

Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...?

Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.10-ck5

[Con Kolivas]

These are patches designed to improve system responsiveness. It is 
configurable to any workload but the default ck* patch is aimed at the 
desktop and ck*-server is available with more emphasis on serverspace.

http://ck.kolivas.org/patches/2.6/2.6.10/2.6.10-ck5/
web:
http://kernel.kolivas.org
all patches:
http://ck.kolivas.org/patches/
This is a maintenance release concentrating on getting a stable and 
hopefully last 2.6.10 release.

A lot of instability manifested by processes stuck in D was caused by 
the early adoption of cfq-timeslices with priority support. This project 
is very exciting, but is not yet suitable for a stable patchset.

Note that gamers are reporting very good audio performance with 
staircase10.3 and higher even on cedega/wineX games.

Removed:
-inc_total_scanned.diff
-2.6.10-capabilities_fix.diff
-linux-2.6.7-CAN-2004-1056.patch
-linux-2.6.9-smbfs.patch
-2.6.10-mm1-brk-locked.patch
-random-poolsize-int-overflow.diff
-rlimit-memlock-dos.diff
-scsi-int-overflow-information-leak.diff
-moxa-int-overflow.diff
All rolled up with -as patchset
-cfq-ts-20.diff
-isobatch_ionice.diff
-rt_ionice.diff
-cfq_writeprio_on.diff
The cfq timeslices patch and related changes
Added:
+patch-2.6.10-as2
The nifty -as patchset containing security and obvious fixes.
+s10.3_s10.4.diff
+s10.4_s10.5.diff
Updated staircase code.
Full patchlist:
patch-2.6.10-as2
2.6.10_to_staircase9.2.diff
schedrange.diff
schedbatch2.6.diff
schediso2.8.diff
mwII.diff
1g_lowmem1_i386.diff
defaultcfq.diff
2.6.10-mingoll.diff
cddvd-cmdfilter-drop.patch
vm-pageout-throttling.patch
nvidia_6111-6629_compat2.diff
fix-ll-resume.diff
s9.2_s9.3.diff
i2.8_i2.9.diff
s9.3_s9.4.diff
i2.9_i2.10.diff
b2.6_b2.7.diff
s9.4_s10.diff
s10_test1.diff
s10_s10.1.diff
s10.1_s10.2.diff
s10.2_s10.3.diff
1504_vmscan-writeback-pages.patch
s10.3_s10.4.diff
s10.4_s10.5.diff
2610ck5-version.diff
and available in patches/ separately:
supermount-ng208-10ck5.diff
Cheers,
Con


signature.asc
Description: OpenPGP digital signature

RE: 2.4: "access beyond end of device" after ext2 mount

[Piszcz, Justin Michael]

Is the problem with the drive on the promise board or the drive on the
VIA chipset?

(from google)
Soyo SY-7VBA133U VIA 694T SY-7VBA133U : ComputerHQ.com3
... Main Specifications. Product Description, SOYO Socket 370
SY-7VBA133U - mainboard -
ATX - Pro133T. ... Audio Output, Sound card - VIA VT82C686B - 16-bit -
stereo. ...

I have the -EXACT- same chipset on an older Soyo Motherboard and have
the same problem you are having, the motherboard did not support drives
over 32GB or it was because I had the 32GB clip (pins on the back of the
hard drive) shorted.  Did you check your HDD manual to see if you have
the 32GB clip enabled?  If so, you need to disable this.

Justin.


-Original Message-
From: Mario Holbe [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 18, 2005 9:15 AM
To: Piszcz, Justin Michael
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4: "access beyond end of device" after ext2 mount

On Tue, Jan 18, 2005 at 09:05:05AM -0500, Piszcz, Justin Michael wrote:
> Okay but what hard drive model and IDE Chipset/Controller are you
using?

VIA vt82c686b onboard
PDC20269 (Promise U133TX2) on PCI

hda: WDC WD400EB-00CPF0, ATA DISK drive
hdc: IC35L080AVVA07-0, ATA DISK drive
hdd: HL-DT-ST DVDRAM GSA-4082B, ATAPI CD/DVD-ROM drive
hdg: SAMSUNG SP1614N, ATA DISK drive

hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63,
UDMA(100)
hdc: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=159560/16/63,
UDMA(100)
hdg: 312581808 sectors (160042 MB) w/8192KiB Cache, CHS=19457/255/63,
UDMA(100)

However, it doesn't matter :)


Mario
-- 
 talk softly and carry a keen sword
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: What Would Cause This :

[Piszcz, Justin Michael]

Looks like you ran out memory and the OOM-killer began killing
processes.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrick
Sent: Tuesday, January 18, 2005 9:17 AM
To: linux-kernel@vger.kernel.org
Subject: What Would Cause This :

dmesg produces the following : 

oom-killer: gfp_mask=0xd0
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
HighMem per-cpu:
cpu 0 hot: low 30, high 90, batch 15
cpu 0 cold: low 0, high 30, batch 15

Free pages:4012kB (240kB HighMem)
Active:41408 inactive:239841 dirty:0 writeback:0 unstable:0 free:1003
slab:4559 mapped:281415 pagetables:1654
DMA free:68kB min:68kB low:84kB high:100kB active:4984kB
inactive:5812kB present:16384kB pages_scanned:11351 all_unreclaimable?
no
protections[]: 0 0 0
Normal free:3704kB min:3756kB low:4692kB high:5632kB active:31768kB
inactive:826028kB present:901120kB pages_scanned:269506
all_unreclaimable? no
protections[]: 0 0 0
HighMem free:240kB min:252kB low:312kB high:376kB active:128880kB
inactive:127524kB present:261632kB pages_scanned:8619
all_unreclaimable? no
protections[]: 0 0 0
DMA: 1*4kB 0*8kB 4*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 0*4096kB = 68kB
Normal: 44*4kB 5*8kB 10*16kB 4*32kB 2*64kB 0*128kB 2*256kB 1*512kB
0*1024kB 1*2048kB 0*4096kB = 3704kB
HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 240kB
Swap cache: add 593035, delete 592831, find 18378/27962, race 0+0
Out of Memory: Killed process 6814 (rsync).
oom-killer: gfp_mask=0x1d2
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
HighMem per-cpu:
cpu 0 hot: low 30, high 90, batch 15
cpu 0 cold: low 0, high 30, batch 15

Free pages:4956kB (240kB HighMem)
Active:177148 inactive:103619 dirty:0 writeback:0 unstable:0 free:1239
slab:4480 mapped:281242 pagetables:1758
DMA free:68kB min:68kB low:84kB high:100kB active:5844kB
inactive:4948kB present:16384kB pages_scanned:54179 all_unreclaimable?
yes
protections[]: 0 0 0
Normal free:4648kB min:3756kB low:4692kB high:5632kB active:571716kB
inactive:284548kB present:901120kB pages_scanned:146374
all_unreclaimable? no
protections[]: 0 0 0
HighMem free:240kB min:252kB low:312kB high:376kB active:131032kB
inactive:124980kB present:261632kB pages_scanned:143172
all_unreclaimable? no
protections[]: 0 0 0
DMA: 1*4kB 2*8kB 3*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 0*4096kB = 68kB
Normal: 302*4kB 0*8kB 9*16kB 3*32kB 2*64kB 0*128kB 2*256kB 1*512kB
0*1024kB 1*2048kB 0*4096kB = 4648kB
HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 1*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 240kB
Swap cache: add 602170, delete 601966, find 22886/33368, race 0+7
Out of Memory: Killed process 14106 (silc).

Patrick
-- 


--
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Lkst-develop] Re: 2.6.11-rc1-mm1

[Masami Hiramatsu]

Hi,
Andi Kleen wrote:
On Tue, Jan 18, 2005 at 08:19:18PM +0900, Masami Hiramatsu wrote:
Hello,
I?m a developer of yet another kernel tracer, LKST. I and co-developers 
are very glad to hear that LTT was merged into -mm tree and to talk 
about the kernel tracer on this ML. Because we think that the kernel 
event tracer is useful to debug Linux systems, and to improve the kernel 
reliability.

I haven't looked at your code, but I would suggest you also post
for review it so that it can be evaluated in the same way
as other more noisy proposals.
Perhaps Andrew can test both for some time in MM like he used
to do for the various schedulers.
Thanks to your advice.
The latest release package of LKST baesd on linux-2.6.9 can be 
downloaded from
http://sourceforge.net/projects/lkst/

I'll release the LKST based on the latest kernel as soon as possible.
Regards,
--
Masami HIRAMATSU
Hitachi, Ltd., Systems Development Laboratory
E-mail: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Con Kolivas wrote:
This patch for 2.6.11-rc1 provides a method of providing real time
scheduling to unprivileged users which increasingly is desired for
multimedia workloads.
I should have mentioned. Many thanks to Alex Nyberg for generous 
debugging help.

Cheers,
Con


signature.asc
Description: OpenPGP digital signature

[PATCH 0/2] Remove input_call_hotplug

[Hannes Reinecke]

Hi all,
the input subsystem is using call_usermodehelper directly, which breaks 
all sorts of assertions especially when using udev.
And it's definitely going to fail once someone is trying to use netlink 
messages for hotplug event delivery.

To remedy this I've implemented a new sysfs class 'input_device' which 
is a representation of 'struct input_dev'. So each device listed in 
'/proc/bus/input/devices' gets a class device associated with it.
And we'll get proper hotplug events for each input_device which can be 
handled by udev accordingly.

Drawback is that a new event type (the said 'input_device') is added, so 
that hotplug scripts and udev might need to be adapted to handle it 
properly. And each device driver needs to be touched to write something 
meaningful as the class_id. A fallback is provided, but by neccessity is 
not very informative.

Patch 1/2 implements the core changes to drivers/input/input.c
Patch 2/2 provides proper device names for input drivers.
Patches are relative to bk://kernel.bkbits.net/vojtech/input
Comments are welcome.
Please CC me directly as I'm not on this list.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG   S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg  http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] Remove input_call_hotplug

[Hannes Reinecke]

This patch implements the core changes in drivers/input/input.c.
A new sysfs class 'input_device' is added as a representation of
struct input_dev.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG   S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg  http://www.suse.de
= drivers/input/input.c 1.48 vs edited =
--- 1.48/drivers/input/input.c	2004-11-18 11:50:15 +01:00
+++ edited/drivers/input/input.c	2005-01-18 10:50:31 +01:00
@@ -48,6 +48,8 @@
 
 static struct input_handler *input_table[8];
 
+static int input_device_num;
+
 #ifdef CONFIG_PROC_FS
 static struct proc_dir_entry *proc_bus_input_dir;
 DECLARE_WAIT_QUEUE_HEAD(input_devices_poll_wait);
@@ -332,52 +334,27 @@
 			SPRINTF_BIT_A(bit, name, max); \
 	} while (0)
 
-static void input_call_hotplug(char *verb, struct input_dev *dev)
+static int __input_hotplug(struct input_dev *dev, char **envp, int num_envp,
+			   char *buffer, int buffer_size)
 {
-	char *argv[3], **envp, *buf, *scratch;
-	int i = 0, j, value;
+	char *scratch;
+	int i = 0, j;
+	scratch = buffer;
 
-	if (!hotplug_path[0]) {
-		printk(KERN_ERR "input.c: calling hotplug without a hotplug agent defined\n");
-		return;
-	}
-	if (in_interrupt()) {
-		printk(KERN_ERR "input.c: calling hotplug from interrupt\n");
-		return;
-	}
-	if (!current->fs->root) {
-		printk(KERN_WARNING "input.c: calling hotplug without valid filesystem\n");
-		return;
-	}
-	if (!(envp = (char **) kmalloc(20 * sizeof(char *), GFP_KERNEL))) {
-		printk(KERN_ERR "input.c: not enough memory allocating hotplug environment\n");
-		return;
-	}
-	if (!(buf = kmalloc(1024, GFP_KERNEL))) {
-		kfree (envp);
-		printk(KERN_ERR "input.c: not enough memory allocating hotplug environment\n");
-		return;
-	}
-
-	argv[0] = hotplug_path;
-	argv[1] = "input";
-	argv[2] = NULL;
-
-	envp[i++] = "HOME=/";
-	envp[i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
-
-	scratch = buf;
-
-	envp[i++] = scratch;
-	scratch += sprintf(scratch, "ACTION=%s", verb) + 1;
+	if (!dev)
+		return -ENODEV;
 
 	envp[i++] = scratch;
 	scratch += sprintf(scratch, "PRODUCT=%x/%x/%x/%x",
 		dev->id.bustype, dev->id.vendor, dev->id.product, dev->id.version) + 1;
 
+#ifdef INPUT_DEBUG
+	printk(KERN_DEBUG "%s: PRODUCT %x/%x/%x/%x\n", __FUNCTION__,
+	   dev->id.bustype, dev->id.vendor, dev->id.product, dev->id.version);
+#endif
 	if (dev->name) {
 		envp[i++] = scratch;
-		scratch += sprintf(scratch, "NAME=%s", dev->name) + 1;
+		scratch += sprintf(scratch, "NAME=\"%s\"", dev->name) + 1;
 	}
 
 	if (dev->phys) {
@@ -396,23 +373,120 @@
 
 	envp[i++] = NULL;
 
+	return 0;
+}
+
+int input_hotplug(struct class_device *cdev, char **envp, int num_envp,
+		  char *buffer, int buffer_size)
+{
+	struct input_dev *dev;
+
+	if (!cdev)
+		return -ENODEV;
 #ifdef INPUT_DEBUG
-	printk(KERN_DEBUG "input.c: calling %s %s [%s %s %s %s %s]\n",
-		argv[0], argv[1], envp[0], envp[1], envp[2], envp[3], envp[4]);
+	printk(KERN_DEBUG "%s: entered for dev %p\n", __FUNCTION__, 
+	   &cdev->dev);
 #endif
 
-	value = call_usermodehelper(argv [0], argv, envp, 0);
+	dev = container_of(cdev,struct input_dev,cdev);
 
-	kfree(buf);
-	kfree(envp);
+	return __input_hotplug(dev, envp, num_envp, buffer, buffer_size);
+}
 
-#ifdef INPUT_DEBUG
-	if (value != 0)
-		printk(KERN_DEBUG "input.c: hotplug returned %d\n", value);
 #endif
+
+#define INPUT_ATTR_BIT_B(bit, max) \
+	do { \
+		for (i = NBITS(max) - 1; i >= 0; i--) \
+			if (dev->bit[i]) break; \
+		for (; i >= 0; i--) \
+			len += sprintf(buf + len, "%lx ", dev->bit[i]); \
+		if (len) len += sprintf(buf + len, "\n"); \
+	} while (0)
+
+#define INPUT_ATTR_BIT_B2(bit, max, ev) \
+	do { \
+		if (test_bit(ev, dev->evbit)) \
+			INPUT_ATTR_BIT_B(bit, max); \
+	} while (0)
+
+
+static ssize_t input_class_show_ev(struct class_device *class_dev, char *buf)
+{
+	struct input_dev *dev = container_of(class_dev, struct input_dev,cdev);
+	int i, len = 0;
+
+	INPUT_ATTR_BIT_B(evbit, EV_MAX);
+	return len;
 }
 
-#endif
+#define INPUT_CLASS_ATTR_BIT(_name,_bit) \
+static ssize_t input_class_show_##_bit(struct class_device *class_dev, \
+   char *buf) \
+{ \
+	struct input_dev *dev = container_of(class_dev,struct input_dev,cdev); \
+int i, len = 0; \
+\
+	INPUT_ATTR_BIT_B2(_bit##bit, _name##_MAX, EV_##_name); \
+	return len; \
+}
+
+INPUT_CLASS_ATTR_BIT(KEY,key)
+INPUT_CLASS_ATTR_BIT(REL,rel)
+INPUT_CLASS_ATTR_BIT(ABS,abs)
+INPUT_CLASS_ATTR_BIT(MSC,msc)
+INPUT_CLASS_ATTR_BIT(LED,led)
+INPUT_CLASS_ATTR_BIT(SND,snd)
+INPUT_CLASS_ATTR_BIT(FF,ff)
+
+static ssize_t input_class_show_phys(struct class_device *class_dev, char *buf)
+{
+	struct input_dev *dev = container_of(class_dev,struct input_dev,cdev);
+
+	return sprintf(buf, "%s\n", dev->phys ? dev->phys : "(none)" );
+}
+
+static ssize_t input_class_show_name(struct class_device *class_dev, char *buf)
+{
+	struct input_dev *dev = container_of(class_dev,struct input_de

[PATCH 2/2] Remove input_call_hotplug

[Hannes Reinecke]

Implement proper class names for input drivers.
Cheers,
Hannes
--
Dr. Hannes Reinecke [EMAIL PROTECTED]
SuSE Linux AG   S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg  http://www.suse.de
= drivers/char/sonypi.c 1.33 vs edited =
--- 1.33/drivers/char/sonypi.c	2005-01-08 06:44:09 +01:00
+++ edited/drivers/char/sonypi.c	2005-01-18 15:26:04 +01:00
@@ -826,6 +826,7 @@
 		sprintf(sonypi_device.input_jog_dev.name, SONYPI_JOG_INPUTNAME);
 		sonypi_device.input_jog_dev.id.bustype = BUS_ISA;
 		sonypi_device.input_jog_dev.id.vendor = PCI_VENDOR_ID_SONY;
+		sprintf(sonypi_device.jog_dev.cdev.class_id,"sonypi-jogdial");
 
 		input_register_device(&sonypi_device.input_jog_dev);
 		printk(KERN_INFO "%s input method installed.\n",
@@ -847,6 +848,7 @@
 		sprintf(sonypi_device.input_key_dev.name, SONYPI_KEY_INPUTNAME);
 		sonypi_device.input_key_dev.id.bustype = BUS_ISA;
 		sonypi_device.input_key_dev.id.vendor = PCI_VENDOR_ID_SONY;
+		sprintf(sonypi_device.input_key_dev.cdev.class_id,"sonypi-keys");
 
 		input_register_device(&sonypi_device.input_key_dev);
 		printk(KERN_INFO "%s input method installed.\n",
= drivers/input/joystick/a3d.c 1.12 vs edited =
--- 1.12/drivers/input/joystick/a3d.c	2004-05-10 03:34:07 +02:00
+++ edited/drivers/input/joystick/a3d.c	2005-01-18 11:35:53 +01:00
@@ -69,6 +69,8 @@
 	char adcphys[32];
 };
 
+static int a3d_num;
+
 /*
  * a3d_read_packet() reads an Assassin 3D packet.
  */
@@ -365,6 +367,7 @@
 	a3d->dev.id.vendor = GAMEPORT_ID_VENDOR_MADCATZ;
 	a3d->dev.id.product = a3d->mode;
 	a3d->dev.id.version = 0x0100;
+	sprintf(a3d->dev.cdev.class_id,"a3d-%d",a3d_num++);
 
 	input_register_device(&a3d->dev);
 	printk(KERN_INFO "input: %s on %s\n", a3d_names[a3d->mode], a3d->phys);
= drivers/input/joystick/adi.c 1.17 vs edited =
--- 1.17/drivers/input/joystick/adi.c	2004-06-11 23:04:03 +02:00
+++ edited/drivers/input/joystick/adi.c	2005-01-18 11:35:53 +01:00
@@ -134,6 +134,8 @@
 	int used;
 };
 
+static int adi_num;
+
 /*
  * adi_read_packet() reads a Logitech ADI packet.
  */
@@ -424,6 +426,7 @@
 	adi->dev.id.vendor = GAMEPORT_ID_VENDOR_LOGITECH;
 	adi->dev.id.product = adi->id;
 	adi->dev.id.version = 0x0100;
+	sprintf(adi->dev.cdev.class_id,"adi%d",adi_num++);
 
 	adi->dev.private = port;
 	adi->dev.evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
= drivers/input/joystick/amijoy.c 1.15 vs edited =
--- 1.15/drivers/input/joystick/amijoy.c	2004-10-20 10:12:05 +02:00
+++ edited/drivers/input/joystick/amijoy.c	2005-01-18 11:35:53 +01:00
@@ -137,6 +137,7 @@
 			amijoy_dev[i].id.vendor = 0x0001;
 			amijoy_dev[i].id.product = 0x0003;
 			amijoy_dev[i].id.version = 0x0100;
+			sprintf(amijoy[i].cdev.class_id,"amijoy%d",i);
 
 			amijoy_dev[i].private = amijoy_used + i;
 
= drivers/input/joystick/analog.c 1.26 vs edited =
--- 1.26/drivers/input/joystick/analog.c	2004-10-20 10:12:06 +02:00
+++ edited/drivers/input/joystick/analog.c	2005-01-18 11:35:53 +01:00
@@ -136,6 +136,8 @@
 	int axtime;
 };
 
+static int analog_num;
+
 /*
  * Time macros.
  */
@@ -445,6 +447,7 @@
 	analog->dev.id.vendor = GAMEPORT_ID_VENDOR_ANALOG;
 	analog->dev.id.product = analog->mask >> 4;
 	analog->dev.id.version = 0x0100;
+	sprintf(analog->dev.cdev.class_id,"analog%d", analog_num++);
 
 	analog->dev.open = analog_open;
 	analog->dev.close = analog_close;
= drivers/input/joystick/cobra.c 1.12 vs edited =
--- 1.12/drivers/input/joystick/cobra.c	2004-05-10 03:34:07 +02:00
+++ edited/drivers/input/joystick/cobra.c	2005-01-18 11:35:53 +01:00
@@ -205,6 +205,7 @@
 			cobra->dev[i].id.vendor = GAMEPORT_ID_VENDOR_CREATIVE;
 			cobra->dev[i].id.product = 0x0008;
 			cobra->dev[i].id.version = 0x0100;
+			sprintf(cobra->dev[i].cdev.class_id,"cobra%d", i);
 
 			cobra->dev[i].evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
 			cobra->dev[i].absbit[0] = BIT(ABS_X) | BIT(ABS_Y);
= drivers/input/joystick/db9.c 1.14 vs edited =
--- 1.14/drivers/input/joystick/db9.c	2004-10-20 10:12:06 +02:00
+++ edited/drivers/input/joystick/db9.c	2005-01-18 11:35:53 +01:00
@@ -597,6 +597,7 @@
 		db9->dev[i].id.vendor = 0x0002;
 		db9->dev[i].id.product = config[1];
 		db9->dev[i].id.version = 0x0100;
+		sprintf(db9->dev[i].cdev.class_id,"db9-%d",i);
 
 		db9->dev[i].evbit[0] = BIT(EV_KEY) | BIT(EV_ABS);
 		for (j = 0; j < db9_buttons[db9->mode]; j++)
= drivers/input/joystick/gamecon.c 1.20 vs edited =
--- 1.20/drivers/input/joystick/gamecon.c	2004-10-21 11:59:08 +02:00
+++ edited/drivers/input/joystick/gamecon.c	2005-01-18 11:35:53 +01:00
@@ -646,6 +646,7 @@
 gc->dev[i].id.vendor = 0x0001;
 gc->dev[i].id.product = config[i + 1];
 gc->dev[i].id.version = 0x0100;
+		sprintf(gc->dev[i].cdev.class_id, "gamecon%d",i);
 	}
 
 	parport_release(gc->pd);
= drivers/input/joystick/gf2k.c 1.16 vs edited =
--- 1.16/drivers/input/joystick/gf2k.c	2004-06-11 23:04:03 +

Re: 2.4: "access beyond end of device" after ext2 mount

[Andries Brouwer]

On Tue, Jan 18, 2005 at 09:24:03AM -0500, Piszcz, Justin Michael wrote:

> Is the problem with the drive on the promise board or the drive on the
> VIA chipset?

Oh, please - no FUD. There is no problem, and we understand in detail
what happens and why it happens. There is no need for any speculation.
There is no relation to disk hardware or indeed any hardware.

> Did you check your HDD manual to see if you have
> the 32GB clip enabled?  If so, you need to disable this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: 2.4: "access beyond end of device" after ext2 mount

[Piszcz, Justin Michael]

Not trying to spread FUD, I am just explaining I had the same issue and
that was the resolution.

-Original Message-
From: Andries Brouwer [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 18, 2005 10:04 AM
To: Piszcz, Justin Michael
Cc: Mario Holbe; linux-kernel@vger.kernel.org
Subject: Re: 2.4: "access beyond end of device" after ext2 mount

On Tue, Jan 18, 2005 at 09:24:03AM -0500, Piszcz, Justin Michael wrote:

> Is the problem with the drive on the promise board or the drive on the
> VIA chipset?

Oh, please - no FUD. There is no problem, and we understand in detail
what happens and why it happens. There is no need for any speculation.
There is no relation to disk hardware or indeed any hardware.

> Did you check your HDD manual to see if you have
> the 32GB clip enabled?  If so, you need to disable this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/2] mm: Reimplementation of alloc_percpu

[Ravikiran G Thirumalai]

On Tue, Jan 18, 2005 at 12:30:32PM +1100, Rusty Russell wrote:
> On Tue, 2005-01-18 at 00:06 +0530, Ravikiran G Thirumalai wrote:
> > ...
> > The allocator can be easily modified to use __per_cpu_offset[] table at a 
> > later
> > stage by: 
> > 1. Allocating ALIGN(__per_cpu_end - __per_cpu_start, PAGE_SIZE) for the
> >static percpu areas and populating __per_cpu_offset[] offset table
> > 2. Making PCPU_BLKSIZE same as the static per cpu area size above
> > 3. Serving dynamic percpu requests from modules etc from blocks by
> >returning ret -= __per_cpu_offset[0] from a percpu block.  This way
> >modules need not have a limit on static percpu areas.
> 
> Unfortunately ia64 breaks (3).  They have pinned TLB entries covering
> 64k, which they put the static per-cpu data into.  This is used for
> local_inc, etc, and David Mosberger loved that trick (this is why my
> version allocated from that first reserved block for modules' static
> per-cpu vars).

Hmmm... then if we change (1) to allocate PERCPU_ENOUGH_ROOM, then the math
will work out?  We will still have a limit on static per-cpu areas in
modules, but alloc_percpu can use the same __per_cpu_offset table[].
Will this work?

But, what I am concerned is about arches like x86_64 which currently
do not maintain the relation:
__per_cpu_offset[n] = __per_cpu_offset[0] + static_percpu_size * n  ---> (A)
correct me if I am wrong, but both our methods for alloc_percpu to use
per_cpu_offset depend on the static per-cpu areas being virtually
contiguous (with relation (A) above being maintained).
If arches cannot sew up node local pages to form a virtually contiguous
block, maybe because setup_per_cpu_areas happens early during boot, 
then we will have a problem.

So a common solution could be:
Declare a dynamic percpu offset table 'alloc_percpu_offset' or
something like that, make it a static per-cpu variable.  Then, the 
blocks can be of any uniform size, we just have to fill
alloc_percpu_offset and use
(RELOC_HIDE(ptr, per_cpu(alloc_percpu_offset, cpu
to get to to the cpu local versions.  I think dereference speeds can be 
fast with this method too since we use __per_cpu_offset[] indirectly.
Of course this is not needed if all arches can do node local allocation
and maintain relation (A) for static per-cpu areas.

Thanks,
Kiran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] pci: Block config access during BIST (resend)

[Brian King]

Andi Kleen wrote:
As Brian said the device he was working with would just not answer,
leading to a bus abort.  This would get  on a PC.
You could simulate this if you want, although I think a EBUSY or EIO
is better.
Alan - are you satisfied with the most recent patch, or would you prefer 
the patch not returning failure return codes and just bit bucketing 
writes and returning all ff's on reads? Either way works for me.

--
Brian King
eServer Storage I/O
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 03:17:07PM +0100, Sytse Wielinga wrote:
> Why not just use dd if=/dev/xxx `blockdev --getbsz /dev/xxx` ...?

because it doesn't work, as I've demonstrated in
Message-ID: <[EMAIL PROTECTED]>

> [EMAIL PROTECTED]:~# dd if=/dev/hdg7 of=/dev/null bs=512
> attempt to access beyond end of device
> 22:07: rw=0, want=4996184, limit=4996183
> dd: reading `/dev/hdg7': Input/output error
> 9992360+0 records in
> 9992360+0 records out
> 5116088320 bytes transferred in 92,603241 seconds (55247400 bytes/sec)
> [EMAIL PROTECTED]:~#
> 
> Fixing dd's blocksize to 512 doesn't help either.


-- 
*axiom* welcher sensorische input bewirkte die output-aktion,
den irc-chatter mit dem nick "dus" des irc-servers
mittels eines kills zu verweisen?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 09:24:03AM -0500, Piszcz, Justin Michael wrote:
> Is the problem with the drive on the promise board or the drive on the
> VIA chipset?

The problem is with each drive on each controller. The problem is even
with no drive on no controller - as I've shown to you with my loop
example, because it does have exactly nothing to do with drives or
controllers at all but just with block devices and their block size.

> the same problem you are having, the motherboard did not support drives
> over 32GB or it was because I had the 32GB clip (pins on the back of the

I'm quite sure my board supports drives bigger than 32G and also drives
biggern than 128G.

> hard drive) shorted.  Did you check your HDD manual to see if you have
> the 32GB clip enabled?  If so, you need to disable this.

And I'm horribly sure, that I don't have 32GB clipping enabled on
my 40, 80 or 160G drives :)

However - it has nothing to do with drives at all. Just with block
devices and block sizes. It's no physical problem but a logical one
and you can reproduce it on any drive you like just by creating
partitions big enough to force mke2fs to allocate (2048|4096) blocks
(or by creating small ones and force mke2fs manually) and with an
absolute size being a multiple of 1024 but none of (2048|4096).


Mario
-- 
 Oh well, config
 one actually wonders what force in the universe is holding it
 and makes it working
 chances and accidents :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ppc32 2.6.x builds for ppc m8xx arch.

[Bryan O'Donoghue]

Greetings list.
I'm curious about something which looks like an error in the mpc8xx 
build of the latest 2.6.11-rc1 kernel.

Firstly, I have a 2.4.28-rc1 which builds just fine for this arch, 
however from an almost totally similar kernel config as was used in the 
2.4, and with the same compiler, the 2.6 build gives a (bad insturction 
?) error when attempting to execute the resulting zImage.elf from a 2.6 
build.


Looking at the difference between the 2.4 and the 2.6 build arguments.
powerpc-linux-gcc -D__KERNEL__ 
-I/home/kernels/2.4.28-pre/vanilla/linux-2.4.28-rc3/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer 
-I/home/kernels/2.4.28-pre/vanilla/linux-2.4.28-rc3/arch/ppc 
-fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized 
-mmultiple -mstring -mcpu=860 -nostdinc -iwithprefix include 
-DKBUILD_BASENAME=uart -c -o uart.o uart.c

powerpc-linux-gcc -m32 -Wp,-MD,scripts/mod/.empty.o.d -nostdinc -isystem 
/usr/local/powerpc/lib/gcc/powerpc-linux/3.4.2/include -D__KERNEL__ 
-Iinclude -Iarch/ppc -Wall -Wstrict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer 
-Iarch/ppc -msoft-float -pipe -ffixed-r2 -mmultiple -mstring 
-Wdeclaration-after-statement -DKBUILD_BASENAME=empty 
-DKBUILD_MODNAME=empty -c -o scripts/mod/.tmp_empty.o scripts/mod/empty.c
scripts/mod/mk_elfconfig ppc < scripts/mod/empty.o > scripts/mod/elfconfig.h

I notice that for a start -m32 has appeared out of nowhere and 
furthermore -mcpu=860 has gone away.

Is this actually correct ? I have specified that the arch should be 8xx 
in menuconfig.

My build command is make ARCH=ppc CROSS_COMPILE=powerpc-linux- V=1
yet still shouldn't mcpu=860, be present in the 2.6 compile arguments?
It _is_ the case that the 2.4.x in question had some modification 
initially by the PCB vendor to make Linux talk to specific settings for 
their hardware, but, I've found these differences between the vanilla 
2.4.27 and the vendor modified 2.4.27.. and can reliably get 2.4.x 
booting on this PCB, however 2.6.x won't work.

After applying a 2.6 version of the patches that should be applied to a 
2.4.x, I get a boot error... what I'd like to be able to do is verify 
that the above 2.6 compile arguments are _not_ the source of the boot 
error, so that I can focus on finding the difference between the 2.4 
build and 2.6 build in terms of necessary patching to make things boot.

So essentially, I'd like to ask the list if the specified compile 
arguments above are correct for the targetted architecture "mpc860", so 
that I can rule it out of my boot error, or perhaps fix said compile 
arguments and send a patch ?

[EMAIL PROTECTED]:~# powerpc-linux-gcc -v 

Reading specs from /usr/local/powerpc/lib/gcc/powerpc-linux/3.4.2/specs
Configured with: ../configure --target=powerpc-linux 
--prefix=/usr/local/powerpc 
--with-as=/usr/local/powerpc/bin/powerpc-linux-as 
--with-ld=/usr/local/powerpc/bin/powerpc-linux-ld 
--enable-languages=c,c++,java --enable-long-long --with-newlib 
--with-headers=/root/crossbuild/gcc-3.4.x/toolchain_powerpc/powerpc-linux-uclibc/sys-include 
--with-libs=/root/crossbuild/gcc-3.4.x/toolchain_powerpc/powerpc-linux-uclibc/lib 
--with-ecos --disable-werror --enable-threads=posix : (reconfigured) 
../configure --target=powerpc-linux --prefix=/usr/local/powerpc 
--with-as=/usr/local/powerpc/bin/powerpc-linux-as 
--with-ld=/usr/local/powerpc/bin/powerpc-linux-ld --enable-languages=c 
--enable-long-long --with-newlib 
--with-headers=/root/crossbuild/gcc-3.4.x/toolchain_powerpc/powerpc-linux-uclibc/sys-include 
--with-libs=/root/crossbuild/gcc-3.4.x/toolchain_powerpc/powerpc-linux-uclibc/lib 
--with-ecos --disable-werror --enable-threads=posix
Thread model: posix
gcc version 3.4.2

Best
Bryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc1-mm1

[Roman Zippel]

Hi,

On Mon, 17 Jan 2005, Karim Yaghmour wrote:

> With that said, I hope we've agreed that we'll have a callback for
> letting relayfs clients know that they need to write the begining of
> the buffer event. There won't be any associated reserve. Conversly,
> I hope it is not too much to ask to have an end-of-buffer callback.

There of course has to be some kind of end marker, but that's less 
critical as it's not the active buffer anymore.

> Roman, of all people I've been more than happy to change my stuff following
> your recommendations. Do I have to list how far down relayfs has been
> stripped down?

Sorry, you missunderstood me. At the moment I'm only secondarily 
interested in the API details, primarily I want to work out the details of 
what exactly relayfs/ltt are supposed to do. One main question here I 
can't answer yet, why you insist on multiple relayfs modes.
This is what I basically have in mind for the relay_write function:

cpu = get_cpu();
buffer = relay_get_buffer(chan, cpu);
while(1) {
offset = local_add_return(buffer->offset, length);
if (likely(offset + length <= buffer->size))
break;
buffer = relay_switch_buffer(chan, buffer, offset);
}
memcpy(buffer->data + offset, data, length);
put_cpu();

ltt_log_event should only be a few lines more (for writing header and 
event data).
What I'd like to know now are the reasons why you need more than this.
It's not the amount of data and any timing requirements have to be done by 
the caller. During processing you either take the events in the order they 
were recorded (often that's good enough) or you sort them which is not 
that difficult.

> You ask what compromises can be found from both sides to obtain a
> single implementation. I have looked at this, and given how
> stripped down it has become, anything less from relayfs will make
> it useless for LTT. IOW, I would have to reimplement a buffering
> scheme within LTT outside of relayfs.

I know you don't want to touch the topic of kernel debugging, but its 
requirements greatly overlap with what you want to do with ltt, e.g. one 
needs very often information about scheduling events as many kernel 
processes rely more and more on kernel threads. The only real requirement 
for kernel debugging is low runtime overhead, which you certainly like to 
have as well. So what exactly are these requirements and why can't there 
be no reasonable alternative?

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] ppc32: platform_device conversion from OCP

[Kumar Gala]

Linus,

I would like to try to get these patches into 2.6.11.  They add 
infrastructure for all ppc sub-archs to use platform_devices instead of 
OCP.  Additionally, I've converted the 85xx sub-arch and gianfar enet 
driver (used by 85xx) over to using platform_device and the new 
infrastructure.

The sooner these get in the easier it will be to convert the other 
sub-archs and drivers to platform_device and remove OCP.

- kumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] ppc32: platform_device conversion from OCP

[Kumar Gala]

System platform_device description, discovery and management:

On most embedded PPC systems we either have a core CPU and chipset 
(MPC10x, TSI10x, Marvell, etc.) or a system-on-chip device (4xx, 8xx, 
82xx, 85xx, etc.).  Some of these sub-archs have been using the On Chip 
Peripheral (OCP) driver model.  The functionality that OCP provide has 
been replaced by the generic driver model and platform_device.  Also, some 
of these device may exist across a number of architectures (PPC, MIPS, 
ARM) such that some information that is shared between the architecture 
and driver needs to exist outside of either.

The ppc_sys changes add a standard way for PowerPC systems to describe the 
devices and systems that exist in the sub-arch.  Additionally, we are able 
to discover which system we are and manage which devices are actually 
registered and any platform specific fixups that may be needed.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
diff -Nru a/arch/ppc/syslib/Makefile b/arch/ppc/syslib/Makefile
--- a/arch/ppc/syslib/Makefile  2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/syslib/Makefile  2005-01-17 22:31:44 -06:00
@@ -92,7 +92,8 @@
 obj-$(CONFIG_MPC10X_OPENPIC)   += open_pic.o
 obj-$(CONFIG_40x)  += dcr.o
 obj-$(CONFIG_BOOKE)+= dcr.o
-obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o
+obj-$(CONFIG_85xx) += open_pic.o ppc85xx_common.o ppc85xx_setup.o \
+   ppc_sys.o
 ifeq ($(CONFIG_85xx),y)
 obj-$(CONFIG_PCI)  += indirect_pci.o pci_auto.o
 endif
diff -Nru a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- /dev/null   Wed Dec 31 16:00:00 196900
+++ b/arch/ppc/syslib/ppc_sys.c 2005-01-17 22:31:44 -06:00
@@ -0,0 +1,103 @@
+/*
+ * arch/ppc/syslib/ppc_sys.c
+ *
+ * PPC System library functions
+ *
+ * Maintainer: Kumar Gala <[EMAIL PROTECTED]>
+ *
+ * Copyright 2005 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+
+int (*ppc_sys_device_fixup) (struct platform_device * pdev);
+
+static int ppc_sys_inited;
+
+void __init identify_ppc_sys_by_id(u32 id)
+{
+   unsigned int i = 0;
+   while (1) {
+   if ((ppc_sys_specs[i].mask & id) == ppc_sys_specs[i].value)
+   break;
+   i++;
+   }
+
+   cur_ppc_sys_spec = &ppc_sys_specs[i];
+
+   return;
+}
+
+void __init identify_ppc_sys_by_name(char *name)
+{
+   /* TODO */
+   return;
+}
+
+/* Update all memory resources by paddr, call before platform_device_register 
*/
+void __init
+ppc_sys_fixup_mem_resource(struct platform_device *pdev, phys_addr_t paddr)
+{
+   int i;
+   for (i = 0; i < pdev->num_resources; i++) {
+   struct resource *r = &pdev->resource[i];
+   if ((r->flags & IORESOURCE_MEM) == IORESOURCE_MEM) {
+   r->start += paddr;
+   r->end += paddr;
+   }
+   }
+}
+
+/* Get platform_data pointer out of platform device, call before 
platform_device_register */
+void *__init ppc_sys_get_pdata(enum ppc_sys_devices dev)
+{
+   return ppc_sys_platform_devices[dev].dev.platform_data;
+}
+
+void ppc_sys_device_remove(enum ppc_sys_devices dev)
+{
+   unsigned int i;
+
+   if (ppc_sys_inited) {
+   platform_device_unregister(&ppc_sys_platform_devices[dev]);
+   } else {
+   if (cur_ppc_sys_spec == NULL)
+   return;
+   for (i = 0; i < cur_ppc_sys_spec->num_devices; i++)
+   if (cur_ppc_sys_spec->device_list[i] == dev)
+   cur_ppc_sys_spec->device_list[i] = -1;
+   }
+}
+
+static int __init ppc_sys_init(void)
+{
+   unsigned int i, dev_id, ret = 0;
+
+   BUG_ON(cur_ppc_sys_spec == NULL);
+
+   for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+   dev_id = cur_ppc_sys_spec->device_list[i];
+   if (dev_id != -1) {
+   if (ppc_sys_device_fixup != NULL)
+   ppc_sys_device_fixup(&ppc_sys_platform_devices
+[dev_id]);
+   if (platform_device_register
+   (&ppc_sys_platform_devices[dev_id])) {
+   ret = 1;
+   printk(KERN_ERR
+  "unable to register device %d\n",
+  dev_id);
+   }
+   }
+   }
+
+   ppc_sys_inited = 1;
+   return ret;
+}
+
+subsys_initcall(ppc_sys_init);
diff -Nru a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
--- /dev/null   Wed Dec 31 16:00:00 1

[PATCH 3/4] ppc32: platform_device conversion from OCP

[Kumar Gala]

Convert MPC8540 ADS, MPC8560 ADS, MPC8555 CDS and SBC8560 reference boards 
from using OCP to platform_device.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
diff -Nru a/arch/ppc/platforms/85xx/mpc8540_ads.c 
b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c 2005-01-17 22:31:44 -06:00
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -48,50 +49,11 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
-#include 
 #include 
 
-struct ocp_gfar_data mpc85xx_tsec1_def = {
-   .interruptTransmit = MPC85xx_IRQ_TSEC1_TX,
-   .interruptError = MPC85xx_IRQ_TSEC1_ERROR,
-   .interruptReceive = MPC85xx_IRQ_TSEC1_RX,
-   .interruptPHY = MPC85xx_IRQ_EXT5,
-   .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
-   | GFAR_HAS_RMON
-   | GFAR_HAS_PHY_INTR | GFAR_HAS_COALESCE),
-   .phyid = 0,
-   .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_tsec2_def = {
-   .interruptTransmit = MPC85xx_IRQ_TSEC2_TX,
-   .interruptError = MPC85xx_IRQ_TSEC2_ERROR,
-   .interruptReceive = MPC85xx_IRQ_TSEC2_RX,
-   .interruptPHY = MPC85xx_IRQ_EXT5,
-   .flags = (GFAR_HAS_GIGABIT | GFAR_HAS_MULTI_INTR
-   | GFAR_HAS_RMON
-   | GFAR_HAS_PHY_INTR | GFAR_HAS_COALESCE),
-   .phyid = 1,
-   .phyregidx = 0,
-};
-
-struct ocp_gfar_data mpc85xx_fec_def = {
-   .interruptTransmit = MPC85xx_IRQ_FEC,
-   .interruptError = MPC85xx_IRQ_FEC,
-   .interruptReceive = MPC85xx_IRQ_FEC,
-   .interruptPHY = MPC85xx_IRQ_EXT5,
-   .flags = 0,
-   .phyid = 3,
-   .phyregidx = 0,
-};
-
-struct ocp_fs_i2c_data mpc85xx_i2c1_def = {
-   .flags = FS_I2C_SEPARATE_DFSRR,
-};
-
 /* 
  *
  * Setup the architecture
@@ -100,10 +62,9 @@
 static void __init
 mpc8540ads_setup_arch(void)
 {
-   struct ocp_def *def;
-   struct ocp_gfar_data *einfo;
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
+   struct gianfar_platform_data *pdata;
 
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -130,23 +91,30 @@
invalidate_tlbcam_entry(NUM_TLBCAMS - 1);
 #endif
 
-   def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 0);
-   if (def) {
-   einfo = (struct ocp_gfar_data *) def->additions;
-   memcpy(einfo->mac_addr, binfo->bi_enetaddr, 6);
-   }
-
-   def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 1);
-   if (def) {
-   einfo = (struct ocp_gfar_data *) def->additions;
-   memcpy(einfo->mac_addr, binfo->bi_enet1addr, 6);
-   }
-
-   def = ocp_get_one_device(OCP_VENDOR_FREESCALE, OCP_FUNC_GFAR, 2);
-   if (def) {
-   einfo = (struct ocp_gfar_data *) def->additions;
-   memcpy(einfo->mac_addr, binfo->bi_enet2addr, 6);
-   }
+   /* setup the board related information for the enet controllers */
+   pdata = (struct gianfar_platform_data *) 
ppc_sys_get_pdata(MPC85xx_TSEC1);
+   pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+   pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+   pdata->phyid = 0;
+   /* fixup phy address */
+   pdata->phy_reg_addr += binfo->bi_immr_base;
+   memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
+
+   pdata = (struct gianfar_platform_data *) 
ppc_sys_get_pdata(MPC85xx_TSEC2);
+   pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+   pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+   pdata->phyid = 1;
+   /* fixup phy address */
+   pdata->phy_reg_addr += binfo->bi_immr_base;
+   memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
+
+   pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_FEC);
+   pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
+   pdata->interruptPHY = MPC85xx_IRQ_EXT5;
+   pdata->phyid = 3;
+   /* fixup phy address */
+   pdata->phy_reg_addr += binfo->bi_immr_base;
+   memcpy(pdata->mac_addr, binfo->bi_enet2addr, 6);
 
 #ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
@@ -158,8 +126,6 @@
 #else
ROOT_DEV = Root_HDA1;
 #endif
-
-   ocp_for_each_device(mpc85xx_update_paddr_ocp, &(binfo->bi_immr_base));
 }
 
 /*  */
@@ -205,6 +171,8 @@
*(char *) (r7 + KERNELBASE) = 0;
strcpy(cmd_line, (char *) (r6 + KERNELBASE));
}
+
+   identify_ppc_sys_by_id(mfspr(SVR));
 
/* setup the PowerPC module struct */
ppc_md.setup_arch = mpc8540ads_setup_arch;
diff -Nru a/arch/ppc/platforms/85xx/mpc8555_cds.h 
b/arch/ppc/platforms/85xx/mpc8555_cds.h
--- a/arch/ppc/platforms/85xx/mpc8555_cds.h 2005-01-17 22:31:44 -06:00
+++ b/

[PATCH 2/4] ppc32: platform_device conversion from OCP

[Kumar Gala]

Infrastructure changes to MPC85xx sub-arch from OCP to platform_device:

* Described all devices available on current MPC85xx CPUs (mem & irq) 
* Added cpu descriptions for the MPC8540, MPC8541, MPC8541, MPC8555, 
MPC8555E, and MPC8560. 
* Removed OCP usage from MPC85xx sub-arch

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig
--- a/arch/ppc/Kconfig  2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/Kconfig  2005-01-17 22:31:44 -06:00
@@ -678,7 +678,7 @@
 
 config CPM2
bool
-   depends on 8260 || MPC8560
+   depends on 8260 || MPC8560 || MPC8555
default y
help
  The CPM2 (Communications Processor Module) is a coprocessor on
diff -Nru a/arch/ppc/platforms/85xx/Kconfig b/arch/ppc/platforms/85xx/Kconfig
--- a/arch/ppc/platforms/85xx/Kconfig   2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/Kconfig   2005-01-17 22:31:44 -06:00
@@ -62,11 +62,6 @@
depends on MPC8555_CDS
default y
 
-config FSL_OCP
-   bool
-   depends on 85xx
-   default y
-
 config PPC_GEN550
bool
depends on MPC8540 || SBC8560 || MPC8555
diff -Nru a/arch/ppc/platforms/85xx/Makefile b/arch/ppc/platforms/85xx/Makefile
--- a/arch/ppc/platforms/85xx/Makefile  2005-01-17 22:31:44 -06:00
+++ b/arch/ppc/platforms/85xx/Makefile  2005-01-17 22:31:44 -06:00
@@ -1,12 +1,9 @@
 #
 # Makefile for the PowerPC 85xx linux kernel.
 #
+obj-$(CONFIG_85xx) += mpc85xx_sys.o mpc85xx_devices.o
 
 obj-$(CONFIG_MPC8540_ADS)  += mpc85xx_ads_common.o mpc8540_ads.o
 obj-$(CONFIG_MPC8555_CDS)  += mpc85xx_cds_common.o
 obj-$(CONFIG_MPC8560_ADS)  += mpc85xx_ads_common.o mpc8560_ads.o
 obj-$(CONFIG_SBC8560)  += sbc85xx.o sbc8560.o
-
-obj-$(CONFIG_MPC8540)  += mpc8540.o
-obj-$(CONFIG_MPC8555)  += mpc8555.o
-obj-$(CONFIG_MPC8560)  += mpc8560.o
diff -Nru a/arch/ppc/platforms/85xx/mpc8540.c 
b/arch/ppc/platforms/85xx/mpc8540.c
--- a/arch/ppc/platforms/85xx/mpc8540.c 2005-01-17 22:31:44 -06:00
+++ /dev/null   Wed Dec 31 16:00:00 196900
@@ -1,97 +0,0 @@
-/*
- * arch/ppc/platforms/85xx/mpc8540.c
- *
- * MPC8540 I/O descriptions
- *
- * Maintainer: Kumar Gala <[EMAIL PROTECTED]>
- *
- * Copyright 2004 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-/* These should be defined in platform code */
-extern struct ocp_gfar_data mpc85xx_tsec1_def;
-extern struct ocp_gfar_data mpc85xx_tsec2_def;
-extern struct ocp_gfar_data mpc85xx_fec_def;
-extern struct ocp_mpc_i2c_data mpc85xx_i2c1_def;
-
-/* We use offsets for paddr since we do not know at compile time
- * what CCSRBAR is, platform code should fix this up in
- * setup_arch
- *
- * Only the first IRQ is given even if a device has
- * multiple lines associated with ita
- */
-struct ocp_def core_ocp[] = {
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_IIC,
-  .index= 0,
-  .paddr= MPC85xx_IIC1_OFFSET,
-  .irq  = MPC85xx_IRQ_IIC1,
-  .pm   = OCP_CPM_NA,
-  .additions= &mpc85xx_i2c1_def,
-},
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_16550,
-  .index= 0,
-  .paddr= MPC85xx_UART0_OFFSET,
-  .irq  = MPC85xx_IRQ_DUART,
-  .pm   = OCP_CPM_NA,
-},
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_16550,
-  .index= 1,
-  .paddr= MPC85xx_UART1_OFFSET,
-  .irq  = MPC85xx_IRQ_DUART,
-  .pm   = OCP_CPM_NA,
-},
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_GFAR,
-  .index= 0,
-  .paddr= MPC85xx_ENET1_OFFSET,
-  .irq  = MPC85xx_IRQ_TSEC1_TX,
-  .pm   = OCP_CPM_NA,
-  .additions= &mpc85xx_tsec1_def,
-},
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_GFAR,
-  .index= 1,
-  .paddr= MPC85xx_ENET2_OFFSET,
-  .irq  = MPC85xx_IRQ_TSEC2_TX,
-  .pm   = OCP_CPM_NA,
-  .additions= &mpc85xx_tsec2_def,
-},
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_GFAR,
-  .index= 2,
-  .paddr= MPC85xx_ENET3_OFFSET,
-  .irq  = MPC85xx_IRQ_FEC,
-  .pm   = OCP_CPM_NA,
-  .additions= &mpc85xx_fec_def,
-},
-{ .vendor   = OCP_VENDOR_FREESCALE,
-  .function = OCP_FUNC_DMA,
-   

[PATCH 4/4] ppc32: platform_device conversion from OCP

[Kumar Gala]

Convert gianfar ethernet driver from using an OCP to platform_device.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
diff -Nru a/drivers/net/gianfar.c b/drivers/net/gianfar.c
--- a/drivers/net/gianfar.c 2005-01-17 22:31:44 -06:00
+++ b/drivers/net/gianfar.c 2005-01-17 22:31:44 -06:00
@@ -26,7 +26,7 @@
  *  controllers on the Freescale 8540/8560 integrated processors,
  *  as well as the Fast Ethernet Controller on the 8540.  
  *  
- *  The driver is initialized through OCP.  Structures which
+ *  The driver is initialized through platform_device.  Structures which
  *  define the configuration needed by the board are defined in a
  *  board structure in arch/ppc/platforms (though I do not
  *  discount the possibility that other architectures could one
@@ -85,6 +85,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -130,8 +131,8 @@
 static void adjust_link(struct net_device *dev);
 static void init_registers(struct net_device *dev);
 static int init_phy(struct net_device *dev);
-static int gfar_probe(struct ocp_device *ocpdev);
-static void gfar_remove(struct ocp_device *ocpdev);
+static int gfar_probe(struct device *device);
+static int gfar_remove(struct device *device);
 void free_skb_resources(struct gfar_private *priv);
 static void gfar_set_multi(struct net_device *dev);
 static void gfar_set_hash_for_addr(struct net_device *dev, u8 *addr);
@@ -148,45 +149,27 @@
 MODULE_DESCRIPTION("Gianfar Ethernet Driver");
 MODULE_LICENSE("GPL");
 
-/* Called by the ocp code to initialize device data structures
- * required for bringing up the device
- * returns 0 on success */
-static int gfar_probe(struct ocp_device *ocpdev)
+static int gfar_probe(struct device *device)
 {
u32 tempval;
-   struct ocp_device *mdiodev;
struct net_device *dev = NULL;
struct gfar_private *priv = NULL;
-   struct ocp_gfar_data *einfo;
+   struct platform_device *pdev = to_platform_device(device);
+   struct gianfar_platform_data *einfo;
+   struct resource *r;
int idx;
int err = 0;
int dev_ethtool_ops = 0;
 
-   einfo = (struct ocp_gfar_data *) ocpdev->def->additions;
+   einfo = (struct gianfar_platform_data *) pdev->dev.platform_data;
 
if (einfo == NULL) {
printk(KERN_ERR "gfar %d: Missing additional data!\n",
-  ocpdev->def->index);
+  pdev->id);
 
return -ENODEV;
}
-
-   /* get a pointer to the register memory which can
-* configure the PHYs.  If it's different from this set,
-* get the device which has those regs */
-   if ((einfo->phyregidx >= 0) && 
-   (einfo->phyregidx != ocpdev->def->index)) {
-   mdiodev = ocp_find_device(OCP_ANY_ID,
- OCP_FUNC_GFAR, einfo->phyregidx);
-
-   /* If the device which holds the MDIO regs isn't
-* up, wait for it to come up */
-   if (mdiodev == NULL)
-   return -EAGAIN;
-   } else {
-   mdiodev = ocpdev;
-   }
-
+   
/* Create an ethernet device instance */
dev = alloc_etherdev(sizeof (*priv));
 
@@ -198,9 +181,19 @@
/* Set the info in the priv to the current info */
priv->einfo = einfo;
 
+   /* fill out IRQ fields */
+   if (einfo->device_flags & FSL_GIANFAR_DEV_HAS_MULTI_INTR) {
+   priv->interruptTransmit = platform_get_irq_byname(pdev, "tx");
+   priv->interruptReceive = platform_get_irq_byname(pdev, "rx");
+   priv->interruptError = platform_get_irq_byname(pdev, "error");
+   } else {
+   priv->interruptTransmit = platform_get_irq(pdev, 0);
+   }
+
/* get a pointer to the register memory */
+   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->regs = (struct gfar *)
-   ioremap(ocpdev->def->paddr, sizeof (struct gfar));
+   ioremap(r->start, sizeof (struct gfar));
 
if (priv->regs == NULL) {
err = -ENOMEM;
@@ -209,7 +202,7 @@
 
/* Set the PHY base address */
priv->phyregs = (struct gfar *)
-   ioremap(mdiodev->def->paddr, sizeof (struct gfar));
+   ioremap(einfo->phy_reg_addr, sizeof (struct gfar));
 
if (priv->phyregs == NULL) {
err = -ENOMEM;
@@ -218,7 +211,7 @@
 
spin_lock_init(&priv->lock);
 
-   ocp_set_drvdata(ocpdev, dev);
+   dev_set_drvdata(device, dev);
 
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
@@ -255,7 +248,7 @@
dev->base_addr = (unsigned long) (priv->regs);
 
SET_MODULE_OWNER(dev);
-   SET_NETDEV_DEV(dev, &ocpdev->dev);
+   SET_NETDEV_DEV(dev, device);
 
/* Fill in the dev structure */
dev->open = gfar_enet_open;
@@ -274,1

Re: 2.4: "access beyond end of device" after ext2 mount

[Mario Holbe]

On Tue, Jan 18, 2005 at 10:07:27AM -0500, Piszcz, Justin Michael wrote:
> Not trying to spread FUD, I am just explaining I had the same issue and
> that was the resolution.

Well, *if* the reason of your issue was the same as the reason of
my issue (what could be, but must not be), you were in the lucky
position that after unclipping your drive your partition's size
was a multiple of 1024 *and* (2048|4096) while before it wasn't.
Chances of that are about 1:(1|3) - not that bad at all :)


Mario
-- 
It is practically impossible to teach good programming style to students
that have had prior exposure to BASIC: as potential programmers they are
mentally mutilated beyond hope of regeneration.  -- Dijkstra
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announce loop-AES-v3.0b file/swap crypto package

[Jari Ruusu]

Fruhwirth Clemens wrote:
> Nothing about kernel crypto is backdoored. If Ruusu thinks different, he
> should show me source code. Till then, treat it as FUD.

I have been submitting fix for this weakness to mainline mount (part of
util-linux package) since 2001, about 2 or 3 times a year. Refusing to fix
it for *years* counts as intentional backdoor.

You call it whatever you want. I call it backdoor.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Announce loop-AES-v3.0b file/swap crypto package

[Jari Ruusu]

jerome etienne wrote:
> 3 years ago i published a paper describing how an attacker would be able
> to modify the content of the encrypted device without being detected.
> http://off.net/~jme/loopdev_vul.html
> 
> i was just curious about the current state of loop-aes. Is it still
> vulnerable to this attack ?

Quote from loop-AES README file
"
Loop device encrypts data but does not authenticate ciphertext. In other
words, it delivers data privacy, but does not guarantee that data has not
been tampered with. Admins setting up encrypted file systems should ensure
that neither ciphertext, nor tools used to access ciphertext (kernel +
kernel modules, mount, losetup, and other utilities) can be trojaned or
tampered.
"

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas]

Cal wrote:
Con Kolivas wrote:
Comments and testing welcome.

There's a collection of test summaries from jack_test3.2 runs at

Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. 
The discrepancies between consecutive runs (with same parameters) is 
puzzling.  Also recorded were tests with SCHED_FIFO and SCHED_RR.

Before drawing any hardball conclusions, verification of the results 
would be nice. At first glance, it does seem that we still have that 
fateful gap between "harm minimisation" (policy) and "zero tolerance" 
(audio reality requirement).
Thanks.
SCHED_ISO
/proc/sys/kernel/iso_cpu . . .: 70
/proc/sys/kernel/iso_period . : 5
XRUN Count  . . . . . . . . . :   110
vs
SCHED_FIFO
XRUN Count  . . . . . . . . . :   114
XRUN Count  . . . . . . . . . :   187
vs
SCHED_RR
XRUN Count  . . . . . . . . . : 0
XRUN Count  . . . . . . . . . : 0
Something funny going on here... You had more xruns with SCHED_FIFO than 
the default SCHED_ISO settings, and had none with SCHED_RR. Even in the 
absence of the SCHED_ISO results, the other results dont make a lot of 
sense.

Con
P.S. If you're running on SMP it may be worth booting on UP or using cpu 
affinity (schedtool -a 0x1 will bind you to 1st cpu only) and see what 
effect that is having. There are some interesting things that can 
adversely affect latency on SMP.


signature.asc
Description: OpenPGP digital signature

Re: [ck] [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Cal]

Con Kolivas wrote:
Comments and testing welcome.
There's a collection of test summaries from jack_test3.2 runs at

Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. 
The discrepancies between consecutive runs (with same parameters) is 
puzzling.  Also recorded were tests with SCHED_FIFO and SCHED_RR.

Before drawing any hardball conclusions, verification of the results 
would be nice. At first glance, it does seem that we still have that 
fateful gap between "harm minimisation" (policy) and "zero tolerance" 
(audio reality requirement).

cheers, Cal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Remove input_call_hotplug

[Dmitry Torokhov]

Hi,

On Tue, 18 Jan 2005 15:59:35 +0100, Hannes Reinecke <[EMAIL PROTECTED]> wrote:
> Implement proper class names for input drivers.
> 

This patch probably should probably use atomic_inc in case we ever
have non-serialized probe functions.

But the real question is whether we really need class devices have
unique names or we could do with inputX thus leaving individual
drivers intact and only modifying the input core. As far as I
understand userspace should be concerned only with device
capabilities, not particular name, besides, it gets PRODUCT string
which has all needed data encoded.

What do you think?

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/